Google bouwt nieuwe ide genaamd Spark als Chrome-app

Google is bezig met het ontwikkelen van een ide genaamd Spark als Chrome-app. Met de ide moet het mogelijk zijn om Chrome-apps zelf te ontwikkelen. Spark is geschreven in Dart, Googles Javascript-vervanger en is nog lang niet klaar voor release.

Google heeft de ide in Chromium ingebouwd, zo schrijft The Next Web. De ontwikkelomgeving is ontdekt door de Franse Google-medewerker François Beaufort en is bedoeld om Chrome Apps mee te bouwen. Het project is openbaar gemaakt op GitHub, waardoor iedereen de ide al kan installeren.

Beaufort merkt ook op dat Spark is gebouwd in Dart en dat deze een gui-widgetbibliotheek bevat die aangedreven wordt door Polymer. Dart is een objectgeoriënteerde taal in C-stijl bedoeld om uiteindelijk Javascript te vervangen. Die taal wordt op dit moment nog nergens native ondersteund, maar er is een tool dart2js om Dart-code naar Javascript om te zetten. Polymer is Googles bibliotheek voor interfaceonderdelen, specifiek bedoeld voor webapplicaties, maar deze library bevindt zich nog in een pre-alphastadium.

Chrome Apps zijn apps geschreven in html, Javascript en css of geschreven in C/C++, als gebruik wordt gemaakt van de Native Client. Die apps werken buiten de browser en kunnen bovendien gebruikmaken van specifieke Chrome-api's die niet beschikbaar zijn voor normale websites. Ook kunnen ze goed integreren met het native-besturingssysteem waarop Google Chrome werkt.

Het is onduidelijk of Google deze nieuw Chrome-app-ide echt zal gaan ondersteunen en regelmatig updaten of dat het wordt gebruikt als een proof of concept om te laten zien wat er mogelijk is met de verschillende gebruikte technologieën. Mocht dat eerste het geval zijn, dan kan het hiermee een stuk eenvoudiger worden om voor Chromebooks apps te ontwikkelen. Google wilde niet reageren op wat zijn plannen zijn.

Reacties (56)

[Lexis]

Google wil met Dart JavaScript vervangen. Ik hoop echter dat ze niet op een gegeven moment stoppen met JavaScript ondersteuning in de browser, al denk ik dat dat wel heel gek moet lopen wil dat gebeuren.

Ik lees dat Dart ook als JavaScript kan worden gecompileerd. (wikipedia). Het komt over op mij als een hogere programmeertaal en Framework in 1.
Interessant. Maar vooralsnog is alleen Google er echt mee bezig.

[Verwijderd]

Het lijkt alsof er niemand echt blij is met de huidige staat van JavaScript en er zijn verschillende initiatieven voor verbetering.

TypeScript (Microsoft)
Een superset van Javascript die optionele types introduceert. Het compileert naar plain old Javascript. Geen andere syntax, geen performance verbeteringen.

CoffeeScript (community)
Javascript met een vriendelijkere syntax en enkele verbeteringen zoals list comprehensions. Compileert naar JavaScript. Geen performance verbeteringen.

ECMA script 6
Oftewel volgende javascript standaard. Weinig ambitieus en de fundamentele fouten van Javascript worden niet aangepakt ('this' en 'that', undefined ipv fouten, modulariteit, etc). Specificatie nog niet definitief en onbekend of snelheidswinst verwacht wordt.

asm.js (Mozilla)
Een subset van Javascript die gericht is op snelheid en compatibiliteit met huidige clients. Belooft een grote snelheidswinst, maar legt het probleem bij de ontwikkelaars.

dart (google)
Een nieuwe taal die performance-winst geeft als de client ook een dart-virtualmachine heeft. Zo niet, wordt er naar JS gecompileerd en is de snelheidswinst beperkt. Gericht op zowel client als server side programmeren. Alle fundamentele 'eigenaardigheden' van JavaScript spelen niet langer een rol voor de programmeur en je krijgt optional typing, concurrency, libraries, classes, etc etc.

Reken er maar niet op dat Javascript in de komende 20 jaar zal verdwijnen. Je hebt altijd te maken met oude websites of programmeurs die nog steeds JavaScript zullen gebruiken. Alle bovenstaande technieken kunnen bovendien naast elkaar bestaan. Ik geef Dart en CoffeeScript de grootste kans om een doorslaand succes te zijn. CoffeeScript is al vrij populair plus laagdrempelig en Dart maakt het grootste verschil voor ontwikkelaars. Het zijn de twee uiteinden van het spectrum die beide hun plaats hebben.

[johnkeates]

Iedereen haat JavaScript, iedereen haat HTML, en eigelijk vooral om dat het voor niemand specifiek doet wat ze graag hadden willen hebben. Maar, is dat niet juist het punt? Een taal die op elk platform hetzelfde doet, en nergens specifiek iets meer/minder kan?

Elk bedrijf heeft een leuk plan hoe het 'beter' kan, maar het is altijd een plan dat vooral in hun eigen voordeel werkt, met hun eigen concepten werkt, met hun eigen idee werkt, en door henzelf beheerd wordt. Dan maakt het niet uit of Microsoft of Google het bedenkt, het is altijd een slecht idee als een bedrijf een overkoepelende standaard gaat proberen te pushen.

Laat het W3C dat maar doen, en ECMA de scripting eigenschappen van JavaScript bepalen, die hebben er namelijk zelf totaal geen baat bij als een bepaald platform beter werkt dan een ander, en iedereen kan z'n eigen implementatie maken.

[Niosus]

Ik zie niet echt wat het probleem is met bedrijven die een oplossing bedenken voor problemen die ze hebben. Google heeft waarschijnlijk een beter beeld op de staat en limieten van het internet dan eender welke andere organisatie. Ze zagen wat er mis wat met browsers... poef! Op een paar jaar tijd is Chrome de meest gebruikte browser. Dat is niet marketing geweest. Dat is weten wat belangrijk is. Snelheid en simpliciteit misten en dat hebben ze opgelost. SPDY is nog zo een voorbeeld dat eindelijk wat aan het aanslaan is. HTTP1.1 is hopeloos verouderd en is nooit gemaakt voor moderne websites/webapps. SPDY pakt dat probleem aan op een backwards compatible manier. Zo zijn er nog Google projecten die openstaande problemen aanpakken met de expertise dat ze hebben.

Dart is gewoon het vervolg. Javascript is een ramp om complexe applicaties in te schrijven en dat weet Google ook goed genoeg. Het is voor hun een economische optie om een nieuwe programmeertaal te ontwikkelen die hun applicaties sneller en schaalbaarder maakt. Op dit moment is er enkel support in Chromium maar ik zie niet echt een reden waarom andere browser dit niet zouden ondersteunen zoals ze met SPDY hebben gedaan.

Google lost het probleem inderdaad op met een focus op zichzelf... Maar Google komt gewoon alle problemen tegen die jij ook tegen komt. Als het goed genoeg is om schaalbare applicaties in te maken voor Google, dan ben je 99% zeker dat het ook goed genoeg gaat zijn voor een willekeurig ander project.

Het is een symbiose. Met de ondersteuning van 3rd party developers door de source open te maken krijgen ze goede wil en gaat de ontwikkeling sneller (zie Android). Als voordeel gaan hun webapps beter werken en kunnen ze nieuwe features inbouwen. Wij krijgen datzelfde voordeel. Het is een WIN WIN scenario. Wil je het niet gebruiken, so be it. Het is een programmeertaal, meer niet. Er verandert niets aan de gewone Javascript syntax en ondersteuning.

[Verwijderd]

ik zie niet echt een reden waarom andere browser dit niet zouden ondersteunen

Toch zijn er redenen, maar deze zijn vooral politiek. Microsoft heeft aangegeven nog erg in het verbeteren van JavaScript te geloven. Ik denk dat ze daarmee vooral hun eigen TypeScript bedoelen. De filosofie van Apple is minimalistisch en een extra VM past er niet in. Mozilla zit ook een beetje op die lijn.

Om eerlijk te zijn: een extra VM implementeren is ook een hoop werk dat ook onderhouden moet worden. Misschien, over een jaar of twee, is Dart volwassen en gestandaardiseerd. Dan zijn er webapps die 'normaal' werken op IE en Firefox, maar vliegen op Chrome. Dan is Hacker News node.js vergeten en hebben ze het onder hun Latte Frappuccino's over Dart-startups. Dan pas zullen ze het gaan implementeren.

Misschien ook helemaal niet en werkt iedereen in asm,js of zo en gaan we daar mee verder.

[Niosus]

Ja goed, het is extra werk. Natuurlijk is het extra werk. De vraag is of het dat extra werk waard is. Ik zou Dart al gebruiken puur voor de betere structuur van de taal en ik denk dat veel anderen er ook zo over denken. Als genoeg developers het gebruiken dan gaat het na een tijd wel gewoon de moeite waard zijn voor Mozilla, Apple of Microsoft om het te ondersteunen. Het kan goed zijn dat dit niet gebeurd en dat er een andere taal "de toekomst" wordt, maar Google zet tenminste hun voet neer en gaan verder dan de rest waardoor ze verbeteringen kunnen doorvoeren die anders gewoon niet mogelijk zijn.

Er zal altijd politiek zijn, maar een goede technologie die veel gebruikt wordt zal altijd winnen. Het kan een tijdje duren en dat zal ook zeker het geval zijn hier, maar binnen 5 jaar zie ik Dart (of een soortgelijk concept) een volwaardige taal zijn die een logische keuze is voor iedereen die net wat meer dan wat DOM manipulaties met jQuery wil doen.

[Verwijderd]

Het is zeker waar dat HTML (een markup taal) nu gebruikt wordt voor toepassingen (web applicaties) waar het nooit voor bedoeld was. Het is ook waar dat JavaScript ontwikkeld werd voor niet-professionele programmeurs, terwijl het nu veelal het domein van ontwikkel-teams is.

En geloof me, er zijn een hoop manieren om een taal op ieder platform hetzelfde te laten doen. Het is vooral belangrijk dat het niet op alle platformen zuigt.

Als de omstandigheden of mogelijkheden wijzigen, is het helemaal geen slecht idee om alternatieven te ontwikkelen. Anders zaten we met z'n allen nog FORTRAN via ponskaarten op mainframes in te voeren.

Er is in principe helemaal niets mis met een bedrijf dat initiatieven ontwikkelt. Helemaal niet als ze de intentie hebben om het tot open en vrije standaard te maken. Vergeet niet dat jouw geliefde JavaScript door het bedrijf Netscape is ontwikkeld. De internet-protocollen door het Amerikaanse leger en commerciele software verkopers leveren de belangrijkste input op de HTML specificatie.

Er kunnen goede redenen zijn om het ontwerp niet door een standaarden commissie te laten doen. "A camel is a horse designed by a committee." Zie hier de motivatie van Google:
https://www.dartlang.org/...esigned-by-standards-body
Ik neem aan dat Microsoft en Mozilla er ongeveer hetzelfde over dachten. Op niet al te lange termijn zullen ze volwassen genoeg zijn om aan de community en het standaarden comite over te dragen.

edit: mijn reactie was een beetje aanmatigend richting johnkeates. Kleine wijziging en je m'excuse.

[Reactie gewijzigd door Verwijderd op 26 juli 2024 23:01]

[johnkeates]

Ja, dat is natuurlijk zo, maar ik denk ook dat als dingen als DART en Script naar JavaScript compilers een prima oplossing vormen.

Voor HTML zijn we nu doodleuk bezig het W3C te passeren en HTML5 gewoon door het bedrijfsleven te laten pushen.

Uiteindelijk zal als HTML5 van W3C klaar is, en de commerciële doorgevoerde versie (via Trident, WebKit [incl. Google's fork], Gecko) vast een HTML 5.0.1 of iets dergelijks uit komen, waarin een complete versie gespecificeerd wordt.

Natuurlijk blijft het doctype hetzelfde gezien fabrikanten steeds meer een rolling release pushen... maar het gaat om een stabiel referentie kader. Een plek waar je een basis voor wat je gaat implementeren kan vinden.

Voor JavaScript/ECMAScript precies hetzelfde. Leuk dat er wat 'beters' is, maar dit is er, en dit is er nu. En het werkt voor 99% van de clients. Het zou leuk zijn als je python in de browser kon draaien. Of Dart. Of wat er ook maar uitgevonden wordt. Maar dat is pas echt praktisch als het overal ondersteund wordt!

Daarom denk ik dat een aanpak van taal compilers en optionele VM's een goed begin is, en dat er van de 4 of 5 mogelijkheden gewoon net zo lang kandidaten afsterven tot dat er een over blijft die universeel geaccepteerd wordt.

Zolang het geen rechtenfeestje wordt zoals de MPEG-LA er van maakt in het geval van video is er nog best kans dat de komende 10 jaar iets dergelijks gebeurt voor client side scripting.

Natuurlijk zal je zien dat Microsoft met een geïntegreerde oplossing wil komen zodat je EF6 en MVC5 en "JS2" o.i.d. in Visual Studio even als dependenties aanvinkt en los gaat met je applicatie, wat het dan weer moeilijk als niet onmogelijk maakt om het buiten mvc.net en VS te gebruiken (JS2 even als voorbeeld van hoe Microsoft het doet). Google zal dan vooral hun eigen browser meteen van hun eigen client side scripting engine voorzien, waar MS en Mozilla dan niks mee gaan doen. Mozilla gaat gewoon verder op de ingeslagen weg (het probleem bij de devvers leggen) en dan wachten we gewoon een paar jaar tot dat de MS-mannen inzien dat ze niet erg universeel bezig zijn en hun skillset in een vendor-lock-in brengen, de Google-fans merken dat niet-google webapps minder goed performen dan wel-google-webapps en dan misschien even aan een andere browser gaan ruiken, en Mozilla, tsja, die verandert gewoon niet heel veel

Daarna krijgen we als we geluk hebben een nieuwe volledige vervanging van JavaScript (bijv. WebScript om even wat te verzinnen) die ondertussen door een of andere NGO non-profit organisatie in elkaar gezet is, met het beste van wat de grote bedrijven te bieden hadden, en pusht het als open mogelijkheid.

Mozilla zal hem meteen gaan implementeren, een open-source WebKit extensie zal op basis van die implementatie geforkt en gebouwd worden voor Safari en Chrome (en Opera), en Internet Explorer gaat zoals gebruikelijk eerst even een tijdje achterlopen (2 of 3 major versies) waarnaar opeens een subset beschikbaar komt en dan op eens 90% geïmplementeerd is op acceptabel niveau.

Op dat moment zijn opkomende frameworks zoals Meteor druk bezig zichzelf te forken en om te bouwen voor WebScript support, misschien dat RequireJS een detectie maakt voor engine selectie zodat je uniform voor de juiste engine de juiste code krijgt, en dan heb je misschien nog zo'n 5 jaar overlap waarna de eerste major releases die JavaScript niet meer actief ondersteunen uit gaan komen en nieuwe applicaties niet meer in JavaScript gebouwd worden.

Kortom: met een beetje geluk krijgen we over ±15 jaar een vervanger voor JavaScript, die over ±20 geaccepteerd wordt door de grote commerciële conglomeraten.

[Verwijderd]

En toch is het geen ramp als het scenario zich zo voltrekt als je nu schetst. Alle 'alternatieven' die ik noemde, zullen het op alle clients prima doen. Voor de eindgebruiker: "it just works".

Iedereen is zich ervan bewust dat we niet terug moeten naar een situatie waar websites bezoekers weg stuurden als ze de verkeerde browser hadden. Er zullen bepaalde features niet door oudere browsers ondersteund worden, maar dat lijkt me een natuurlijk proces.

Dit pragmatische geeft bijvoorbeeld in dat Dart ontwikkeld is en men zich niet bezig houdt met Python naar de browser te brengen (hoewel ik dat liever had gewild). Dart is mede ontwikkeld om efficiente JS te genereren.

Verder mogen de verschillende talen, platformen, programmeurs, bloggers, bedrijven en tweakers het uitvechten. Als er een of meerdere winnaars uitkomen, wint de eindgebruiker er ook bij.

[Niosus]

Kortom: met een beetje geluk krijgen we over ±15 jaar een vervanger voor JavaScript, die over ±20 geaccepteerd wordt door de grote commerciële conglomeraten.

Heh... Kan jij 15-20 jaar in de toekomst kijken en op het internet dan nog wel? 20 jaar geleden was het internet iets waar de meeste geeks over lazen in tijdschriften. 15 jaar geleden zaten we in het hoogtepunt van de MSIE/Netscape oorlog.

Verder dan een jaar of 5 kijken (2-3 IE versies) heeft geen zin. Je weet niet welke trends opkomen, welke nieuwe diensten en platforms uitgevonden worden. Werken we binnen 20 jaar nog wel met browsers? Je kan echt niet zo ver extrapoleren. Wat wel "mogelijk" is is kijken naar problemen die we vandaag hebben, kijken hoe veel "drang" er is om een oplossing te vinden en kijken hoe ver we staan om zo ruwweg een idee te krijgen voor de komende paar jaar.

Kijk bijvoorbeeld naar responsive images. Gigantisch probleem dat vooral het laatste jaar enorm is gegroeid. Op dit moment staan we nog nergens, maar quasi elk groot tech bedrijf moet al gekeken hebben naar oplossingen als ze een responsive design hebben. Met zo een grote interesse zou het mij verbazen als we tegen eind 2014 nog altijd niet echt een richting weten om uit te gaan. Ik verwacht dus binnen 2-3 jaar de eerste implementaties te zien afhankelijk van hoe lang we nog moeten zoeken achter een goede oplossing.

Terug naar Dart: Het opkomen met "de oplossing" is al gebeurd, maar we zitten nu in de implementatiefase. De vraag naar Dart ( of iets gelijkaardig) bestaat maar het is niet zo kritisch als bijvoorbeeld de responsive images. De komende 1-2 jaar zullen kritisch zijn om te zien of Dart een goed platform biedt. Als het goed blijkt te zijn gaat de switch voor grote webapps echt geen 10+ jaar duren.

Dart gaat javascript trouwens niet vervangen, net zoals C# C nooit gaat vervangen. Het zijn andere talen met een andere scope en andere bagage. Dart is bedoeld om webapps of heel interactieve websites mee te bouwen. Javascript is bedoeld om wat simpele interacties met de pagina te doen.

[HerrPino]

TypeScript is eigenlijk gewoon ECMA6 met een paar kleine toevoegingen zoals strong typing. Iets wat onze JS guru eerst vervloekte, maar nu zalig vind aangezien hij minder fouten maakt (de compiler detecteerd er al veel) en de IDE hem daadwerkelijk nuttige intellisense kan geven. Bij ons is alles nu herschreven naar .ts files.

Dart is gewoon waardeloos. Op het moment dat ECMA6 uitkomt is het ook compleet nutteloos.

Wat ze eens zouden moeten aanpakken in Javascript zijn de vele bugs (lees voor de grap eens: http://it-ebooks.info/book/274/ en dan appendix B, ... en A of http://wtfjs.com/)

[Reactie gewijzigd door HerrPino op 26 juli 2024 23:01]

[Kalief]

Niet zozeer bugs maar eerder onverwacht gedrag. Kwestie van wennen.

[Herko_ter_Horst]

Onverwacht gedrag = definitie van bug.

[Verwijderd]

Je bent NaCl vergeten. Dat is ook een goede kandidaat om javascript mee overbodig te maken. Zo kun je bijvoorbeeld je favoriete scripttaal naar NaCl compileren.

[Verwijderd]

twop: Ik was het niet vergeten, maar ik zie het niet zozeer als 'verbetering' maar meer als 'alternatief'.

Er is geen mogelijkheid om Native Client apps in andere browsers te draaien, bijv door JavaScript te genereren. Dit betekent dat er een andere doelgroep bereikt wordt: alleen Chrome.

Ik voorspel dat in de praktijk PNaCl vooral gebruikt wordt om Chromebooks te bereiken. Zie het als het applicatieplatform van de Chromebooks. Met name voor educatieve apps, aangezien ze vooral daar te vinden zijn.

Geen JavaScript genereren is simpelweg een te grote drempel om te overwinnen. Het idee is geweldig: native code zonder prestatieverlies op een browser uitvoeren. Denk aan 3D games, etc etc. Toch gaan IE, Mozilla, e.d. niet mee.

[Verwijderd]

Het idee is geweldig: native code zonder prestatieverlies op een browser uitvoeren. Denk aan 3D games, etc etc. Toch gaan IE, Mozilla, e.d. niet mee.

Ja dat moet dan maar eens een keer veranderen.
Kijk naar het argument van Jay Sullivan (wikipedia):

Mozilla's vice president of products, Jay Sullivan, said that Mozilla has no intention of running native code inside the browser, as "These native apps are just little black boxes in a webpage. [...] We really believe in HTML, and this is where we want to focus."

Alsof asm.js geen black box is...

[Verwijderd]

Daarom CoffeeScript !

[Verwijderd]

Doe eens volwassen.

[Lexis]

Het meeste wat ik met JavaScript doe, doe ik vooral met jQuery. Ik heb dat ook redelijk goed bestudeerd.
Om nu alles met snippets te doen houd ik niet van, schrijf het liever zelf, of wil het op zijn minst begrijpen Vaak is er meer dan je op het eerste gezicht ziet. Daarbij, als je het niet echt begrijpt is een snippet ook niet te modificeren.

Dank je voor deze post, ik ga toch eens doorlezen. Vooral CoffeeScript spreekt me aan als ik de omschrijving lees.

[Verwijderd]

Leuk dat je er iets aan hebt: ik heb het zo neutraal mogelijk proberen te houden.

Zelf laat ik CoffeeScript voorlopig aan me voorbij gaan. De syntax is wel helderder en het introduceert wat handige constructies, zoals "list comprehensions" (hallelujah, wat mis ik die omdat ik van Python kom).
Aan de andere kant van de medaille: je behoudt de matige performance en eigenaardigheden van JS. Er is een extra compilatie-stap nodig hetgeen debuggen ook moeilijker maakt. Tot slot denk ik dat het vooral naast (eenvoudigere) javascriptjes gebruikt blijkt worden, waardoor je jezelf op twee talen focust.

Hier is een interesante discussie gevoerd over Coffeescript: http://procbits.com/2012/...elopers-hate-coffeescript

Zelf ga ik eerst aan de slag met Javascript voor een applicatie, in combinatie met Angular. Als Dart (en ik) iets verder zijn, is dat ook een overweging waard. Ze zijn al aardig ver met Angular.dart en zeker als Dart een volwassen server-taal met framework is, zou het heel interessant zijn. Dan zijn we denk ik wel zeker een half jaar verder.

[Rafe]

Leestip: de gelekte Google memo over Dart (toen nog Dash) uit 2010:

The “evolve Javascript” option is relatively low risk, but even in the best case it will take years and will be limited by fundamental problems in the language (like the existence of a single Number primitive). Javascript has historical baggage that cannot be solved without a clean break. Thus, although it’s low risk, it’s also relatively low reward.

The “clean break” option is extremely high risk--it will be a huge challenge to convince other browser vendors to rally around a new language--but is the only way to escape the historic problems with Javascript. Thus, its high risk is matched by the potential for a very high reward--a classic leapfrog strategy.
[..]
The only solution is to execute the two strategies in parallel.

Interessant genoeg werd daar ook nog de Brightly cloud IDE aangehaald, wat min of meer hetzelfde lijkt te zijn als Spark. Sterker nog: "We expect Brightly itself to be the first application written in Dash" maar sinds 2011 is het nogal stil geweest omtrent dit project.

[Bad_Karma]

Ik heb het opgezocht en ide betekent dus Integrated Development Environment. Had wel even vermeld mogen worden voor mensen die wel geïnteresseerd zijn in de artikelen op Tweakers.net, maar niet alles afweten van software ontwikkeling.

[Verwijderd]

Het staat in het artikel erbij hoor. Muis over "ide" en je ziet waar de afkorting voor staat.

Ik vind deze manier van afkortingen uitleggen voldoende voor leken, en niet storend voor ingewijden.

[Reactie gewijzigd door Verwijderd op 26 juli 2024 23:01]

[Bad_Karma]

Muis over? Maar ik lees dit bericht van mijn mobiele telefoon.

[jrfloor]

IDE is een dusdanig ingeburgerd begrip in de IT dat het niet nodig is om dat bij ieder vermelding uit te leggen want de aannname is dat er hiet heel wat ingewijden zijn. Dat je mobiel niet de uitleg die in html is verborgen kan lezen is een gebrek aan of de mobiele browser of de site of mischien wel allebij. Ik zou echter ook niet al te veel moeite doen om voor mobiele gebruikers dit soort informatie zichtbaar te maken. Meestal ben je op zoek naar wat je kan weglaten voor mobiele gebruikers. Ze doen het niet om je te pesten....waarschijnlijk

[Bad_Karma]

Ik ben 15 jaar werkzaam in de IT, maar ik kende de term IDE niet.

Misschien dat dit meer ingeburgerd is in de software-ontwikkeling dan in de IT algemeen.

[Verwijderd]

IT moet zich ook bezig houden met de migratie naar Linux. Is goed voor de Europese economie.

[notsonewbie]

" Ik zou echter ook niet al te veel moeite doen om voor mobiele gebruikers dit soort informatie zichtbaar te maken. Meestal ben je op zoek naar wat je kan weglaten voor mobiele gebruikers."

Die opvatting snap ik, echter deze is achterhaalde informatie anno 2012 al.

Is niet al meer dan de helft (ook-) via tablets en phones aan het surfen?

Een simpele (wel responsive webdesigned) wordpress website met dropmenu navigatie toont ook in de ene browser wel de dropmenu's en op andere alleen de kop, zeg maar de bovenste menu entry.

[Reactie gewijzigd door notsonewbie op 26 juli 2024 23:01]

[cornedor]

Ik moet hierbij wel denken aan Brackets om een of andere reden. Heeft iemand een idee of het meer kan dan alleen tekst editen, in de screenshot staan niet echt interesante features.

[Ventieldopje]

Moest ik ook gelijk aan denken, ook omdat deze grotendeels in Javascript is geschreven. Vind het jammer van Google dat ze nou weer het wiel opnieuw proberen uit te vinden, of dat in ieder geval zo laten lijken.

Brackets is een heerlijke open-source IDE waar ze veel makkelijker Chrome App support voor in hadden kunnen bouwen dan zelf maar een look-a-like te bouwen. Misschien dat het iets met rechten te maken heeft?

[Verwijderd]

Maar Spark is dus juist in Dart geschreven.

[Ventieldopje]

Wat dus in principe gewoon een fork van Javascript is (Dart kun je omzetten naar Javascript).

Niks weerdhoud Google er van om Brackets te forken en te herschrijven naar Dart als hun dat beter lijkt.

[OddesE]

Wat dus in principe gewoon een fork van Javascript is (Dart kun je omzetten naar Javascript).

Dan is C dus ook een fork van Javascript (C kun je ook omzetten naar Javascript).

Maar goed we weten allemaal dat dat niet zo is. C stamt uit +/- 1970, terwijl Javascript pas in 1995 verscheen.

[Ventieldopje]

Je weet zelf dat dat ook wel weer wat vergezocht is.

Influenced by JavaScript, Java, Smalltalk, Erlang, Strongtalk, C#[2]

The goal of Dart is "ultimately to replace JavaScript as the lingua franca of web development on the open web platform".

- Wikipedia: [url]http://en.wikipedia.org/wiki/Dart_(programming_language)/url]

Dan nog, je gaan mijn punt voorbij

[Reactie gewijzigd door Ventieldopje op 26 juli 2024 23:01]

[Huismus]

'Een fork' wat jij zei in je eerste comment is iets heeeeeel anders dan 'beinvloed door',

Dart wordt door Google gepositioneerd als een vervanger van Javascript. Een fork van javascript kan zo ver ik weet niet eens: als je het over Javascript hebt, dan heb je het over de taal, niet of een implementatie van die taal. Je kunt zeker wel Chromes V8 forken, en dat zullen ze vast ook gedaan hebben (ik weet niet of het dan nog forken heet). Maar er zijn veel meer implementaties van Javascript: Mozilla's Spidermonkey bijvoorbeeld.
http://en.wikipedia.org/w...engine#JavaScript_engines

[cornedor]

Brackets heeft een vrij soepele licentie, daarnaast hadden ze ook bijv. CodeMirror (MIT) of Ace (BSD) kunnen gebruiken. Heb even snel in de github gebladerd maar ben geen van bijde tegen gekomen, lijkt er op dat de hele editor in Dart is gemaakt.

[ruben]

Dit is beetje kip-ei verhaal. Dit is een Chrome-app om Chrome-apps te maken. En omdat er die er nog niet was is die geschreven in Dart i.c.m. Polymer. Nu kun je met deze IDE dus makkelijker Chrome-apps maken, omdat het verschillende libraries etc bevat om nieuwe Chrome-apps te maken.

Thats it. Maar ik snap niet waarom het niet web-based had gekunt, zoals bijvoorbeeld http://icecoder.net.

Chrome was just de browser, en niets anders dan de browser, met html/js apps. Nu is het een compleet OS met steeds meer rompslomp eromheen.

[Verwijderd]

Chrome Apps zijn nog steeds browserapps, alleen via de store nestelen zich permanent in de cache en als "bookmark".

[Verwijderd]

Haha, grappig ik las de titel. Ik dacht ook... ze moeten brackets uitbrengen voor Google Chrome OS. Dat zou een boost geven!!!

Brackets beste WEB Editor. Echter moet je geen website's willen ontwikkelen op Windows...

OSX en Linux hebben iets waarbij bepaalde tools veel fijner werken. Een Terminal!
Ben ook fan van MEAN stack.. niet echt van Dart.
-Mangoose, Express, AngularJS, NodeJS.

[cornedor]

Er wordt aan gewerkt om Brackets in de browser te krijgen. Dus nog even en dan gaan we zien of die boost er komt ;-)

[Stackprotector]

Die editor is een 1-op-1 met Sublime Text? Of gebruikt Sublime Text ook weer een bekende set-up?

[JoeyPrr]

Dit is inderdaad de bekende set-up die vrijwel iedere editor / ide gebruikt.

[Reactie gewijzigd door JoeyPrr op 26 juli 2024 23:01]

[Angelo2510]

Dus je kan Spark gebruiken als evt vervanger voor sublime text? Als in ook om webpagina's te maken/ bewerken? Inclusief PHP?

[cornedor]

Je zou Spark daar idd voor kunnen gebruiken, als ik het zo lees is deze editor toch meer gericht op het maken van chrome apps, ik denk dat je op dit moment beter kunt kiezen voor een editor als PHPStrorm, Brackets oid als je sublime wilt vervangen.

[H!GHGuY]

Slim van ze. Of hoe een soon-to-be-ex-CEO ooit zei: "Developers, Developers, Developers..."
Dit past ook prima binnen hun ChromeOS strategie om alles binnen de browser mogelijk te maken.

[HerrPino]

ChromeOS strategie om alles binnen de browser mogelijk te maken.

Om vervolgens een OS over te houden, waar dan weer een browser zonder allerlei toeters en bellen binnen gebouwd kan worden. ... ECHT FANTASTISCH!! ... niet echt eigenlijk.

Vraag me af hoe positief men zou zijn als men binnen Ultra-Edit of Excel (ik noem maar 2 applicaties) een compleet OS op zou bouwen. Een browser blijft een browser.

[Reactie gewijzigd door HerrPino op 26 juli 2024 23:01]

[jrfloor]

Daar hebben we toch VI en Emacs voor?

[H!GHGuY]

Je kan het idioot vinden maar eigenlijk is ChromeOS desktop-virtualisatie.
Low-end, low-power hardware met alles in de cloud. Als concept voor veel toepassingen prima.

Alleen jammer dat het Google's cloud moet zijn.

[Verwijderd]

Hoezo? Je kan je webapps toch gewoon ergens anders hosten? Het is echt niet gebonden aan Google's cloud.. dat zou wat zijn. Dan zou het nooit van de grond af komen.

[_Thanatos_]

Ik hoop voor ze dat de IDE dan na verloop van tijd niet messed up of functioneel in de war raakt na flink gebruikt te zijn, want op F5 drukken is in essentie een reboot.

Waarom zeg ik dit: omdat Google Maps hier vaak last van heeft, vooral te merken als ik "My Maps" onderdelen aan het muteren ben - ik moet dan af en toe op F5 drukken omdat de GUI dan niet meer snapt wat er gaande is.

[gimbal]

Ok maar dat is een fout in Maps, niet in de gebruikte technologie.

[BtM909]

Ik ben benieuwd hoe een product als Cloud9 hier bijvoorbeeld op gaat reageren. Zij zijn al een behoorlijk volwaardige cloud IDE en het zou voor hen relatief simpel zijn om de omgeving ook te bootstrap-ready voor Chrome Apps te maken

[BrutalDave]

Spark. Dat klinkt alsof het een tegenhanger moet zijn van Microsoft DreamSpark.

[cappie]

Wel een donkere interface voor je code, maar dan nog wel zo'n lelijke witte folder browser... erg grappig, maar niet echt bruikbaar 's avonds.. is er al iets bekend over wanneer er designers naar gaan kijken?