Chrome krijgt geen Dart maar wel pointer events

Google heeft besloten om zijn javascript-alternatief Dart niet te implementeren in Chrome. In plaats daarvan moet Dart-code worden omgezet naar javascript, zoals dat nu ook al gebeurt. Wel wil Google de pointer events-api van Microsoft ondersteunen.

Google kwam in 2011 met zijn javascript-alternatief Dart, en lange tijd leek het bedrijf van plan te zijn om Dart te implementeren in Chrome om zo javascript als populairste webscriptingtaal naar de kroon te steken. Google heeft nu echter besloten om de taal niet op te nemen in Chrome. Naar eigen zeggen heeft het internetbedrijf daartoe besloten omdat dat het beste is 'voor onze gebruikers en voor het web, en niet enkel voor Google Chrome'.

Gebruikers van de Dart-taal zullen daarom code moeten blijven omzetten naar javascript om die binnen een webbrowser te kunnen draaien. Dart is opensource en is volgens Google eenvoudiger te leren dan javascript. Hoewel de taal voor clients kan worden gebruikt, kan hij ook worden gebruikt om serversoftware te programmeren, net als javascript via node.js.

Tegelijkertijd heeft Google wel besloten om de Pointer Events-api van Microsoft te implementeren in Chrome. De pointer events-api is momenteel alleen beschikbaar in de IE10-browser die in Windows 8 en Windows Phone 8 is te vinden. Via de technologie kan in een browser gebruikersinput afgehandeld worden die afkomstig is van de muis, een touchscreen of het toetsenbord. Bovendien zou de api door een hoge mate van abstractie in staat zijn om toekomstige invoermethodes te verwerken. Firefox heeft ook aangegeven te werken aan ondersteuning voor de pointer events-api.

Reacties (70)

[Anoniem: 601896]

Het is jammer om te zien, dat Google als grote techspeler ook steeds vaker open- source oplossingen links laat liggen. Dart was een prima mooie simpele te leren open-source taal, en ook rijk aan functionaliteit.

Gelukkig is de Pointer Events api van Microsoft wel open-source en een w3c standaard. Dus is het goed dat google die gewoon adopteert, in plaats van een extra standaard de wereld in te slingeren.

[Reactie gewijzigd door Anoniem: 601896 op 24 juli 2024 09:56]

[Lethalis]

Tsja, eerst de AngularJS 2.0 shocker (totaal niet backwards compatible) en nu Dart.

Ik blijf voorlopig een beetje uit de buurt van Google spul

[simplicidad]

Eerlijk ik heb ook mijn reservaties bij Google technologie omdat ze er een broertje dood aan hebben om de zaken snel te begraven.

Echter met angular 2.0 slaan ze een compleet andere weg in met atscript wat eigenlijk een superset is van typescript en waar er ook een collaboratie is met Microsoft.

Ik ben vrij kritisch als het over Microsoft en Google gaat, maar ik vind het knap dat men nu meer de weg van het samenwerken opzoekt dan terug een nieuwe standaard te introduceren.

Als we iets zouden moeten doen is dergelijk gedrag te belonen. Als Backbone fan ga ik toch eens naar angular 2 kijken.

[Martinspire]

Atscript wordt al vervangen door Typescript sinds de laatste ng-conf.

[Macshack]

Uhm heb je hier een link voor? Want ik kan nergens vinden dat het 1 het andere gaat vervangen. Zover ik weet is AtScript een superset van Typescript. Maar dat typescript, atscript gaat vervangen heb ik nog nergens gelezen of gehoord. Bedoel je dat Google geen AtScript meer gaat gebruiken voor hun ontwikkeling van AngularJS 2.0?

[bartw84]

TypeScript en AtScript gaan inderdaad "fusioneren".
Linkje: http://techcrunch.com/201...-has-not-frozen-over-yet/

[YopY]

Tsja, eerst de AngularJS 2.0 shocker (totaal niet backwards compatible)

FUD; Angular 2.0 is nog lang niet uit, en de komende 1.x versies voegen allerlei functies toe die ze ook voor 2.0 gepland hebben, waardoor ook uiteindelijk de overstap van 1.x naar 2.x eenvoudiger gaat worden.

[Galeton]

Beetje kort door de bocht. Google innoveert er een eind op los en probeert op een breed front de concurrentie aan te gaan op alles wat met technologie te maken heeft. Soms werkt het (Chrome) en soms niet (hoeveel sociale media platformen hebben ze geprobeerd?).

Ik ben zelf niet zo bekend met programmeren, maar het kan nooit verkeerd zijn om het scala aan te gebruiken talen te verbreden. Uiteraard wel mits ze compatible zijn anders krijg je het gezeik van silverlight vs flash vs html5.

[Martinspire]

Het is niet bepaald alsof ze een keuze hebben bij Google om pointerevents niet toe te staan. Waarom? Omdat het onderdeel is van de HTML5 standaard en ze daar dus aan willen voldoen.

[Anoniem: 457607]

Die keuze hebben ze wel degelijk. En technisch gezien is het geen HTML5 standaard, maar een JS events standaard.

[Rob Wu]

Standaarden worden niet blind gevolgd, ook al is er veel vraag (bijv. van ontwikkelaars) naar een bepaalde feature.

Recent werd bijvoorbeeld besloten om de toBlob methode van een <canvas> niet te implementeren, omdat de implementatie niet de gewenste toegevoegde waarde had vanuit het perspectief van de browserontwikkelaars (https://code.google.com/p/chromium/issues/detail?id=67587). In plaats van de bestaande standaard te implementeren wordt er nu gewerkt aan een voorstel van een nieuwe standaard).

Soms wijkt de gespecificeerde standaard af van de praktijk, en wordt de specificatie bewerkt zodat het aansluit bij de de facto standaard (voorbeeld).

[84hannes]

edit:
Je hebt je bericht aangepast, ik terk mijn kritiek terug

[Reactie gewijzigd door 84hannes op 24 juli 2024 09:56]

[i-chat]

dat is zeker niet jammer om te zien, google heeft dart zelf opgezet als een soort eigen standaard om te pushen ... als ze dit hadden doorgezet, dan was chrome een soort IE6 geworden, met allemaal dingetjes die 'eigen standaard' boven alles stellen.

ik ben heel blij dat google heeft ingezien dat het beter is voor het web als zaken compatible blijven en webontwikkelaars niet weer alles in 10 versies en 50 talen moeten programmeren omdat de ene browser net even anders omgaat met code dan de ander.

ze hebben hier dus gekozen voor ons en niet voor wat goed is voor google en daar mogen we blij mee zijn, misschien wordt dart ooit nog eens de nieuwe defacto standaard, maar nu iig nog even niet..

[batjes]

Google heeft dik een jaar geprobeerd de Pointer Events API te laten vallen.

Apple heeft iets van "We wachten wel tot Google met Pointer Events 2.0 komt en daar hun goedkeuring over geeft.

Google doet moeilijk alleen omdat dit van het IE team af komt, Google gooit wederom politiek boven alles. De enige reden dat Google het nu implementeerd is omdat gebruikers moeilijk deden.

Ik vind dit nogal sneu van Google, op zo'n manier (over de rug van je gebruikers) politiek spelen. Net zo kinderachtig als Mozilla in de jaren 90.

[SuperDre]

tja, er zijn zoveel mooie simpele te leren talen, maar dat is all in the eye of the beholder......

[Lethalis]

Bye bye Dart.

Het wordt tijd dat JavaScript op het niveau van Typescript gaat komen qua features. Gewoon 1 standaard. Klaar.

[PhantomPotato]

De overhead van Java is niet erg goed, in Dart is deze veel beter. Ik dacht dat Notch een port in Java van Doom in Dart/WebGL had laten zien die veel slechter draaide in Java. Ik vond Dart zelf ook veel beter werken persoonlijk.

[Ramon]

Dart wordt gecompileerd naar JavaScript dus de performance is hetzelfde.

[ATS]

Dat hoeft natuurlijk helemaal niet. Als Dart gecompileerd wordt naar inefficiënte code, dan is het resultaat ook inefficient. Net zoals twee oplossingen voor hetzelfde probleem geschreven in dezelfde taal niet even efficiënt hoeven te zijn.

[SuperDre]

Dus ligt het probleem niet bij de taal zelf.........

[ATS]

Het probleem kan dan natuurlijk weldegelijk liggen in de taal Dart in dit geval. Op het moment dat Dart bepaalde structuren zou gebruiken die het in de weg staan om efficiënte code te genereren, dan is dat een probleem van de taal Dart. Ik wil niet zeggen dat dat zo is overigens.

Vergelijk het Microsoft die in haar STL implementatie altijd range-checked iterators gebruikte. Als je je aan hun "taal" hield, dan werden iteraties ineens significant trager. Dus mensen gingen trucs gebruiken om daar omheen te komen als ze over een vector wilden itereren om toch gewoon een pointer te krijgen die je wél snel kan ophogen en dereferencen. Stel nu dat Dart dat soort "handigheidjes" ingebouwd heeft in haar taal (nogmaals: ik heb geen idee, ik doe C++ en geen web development), dan levert dat gecompileerd altijd tragere code op dan e.e.a. direct "low level" schrijven in Javascript.

[gast128]

Ik ken Dart niet, maar ik weet dat voor php ook zoiets is geprobeerd. Uiteindelijk bleek php een onhandige container te hebben die optimalisaties in de weg stonden. Verder begrijp ik niet helemaal waarom script talen altijd type loos zijn. Is dat om het simpel te houden (hoewel je checking van compile time naar run time verplaatst en het eventueel lastiger krijgt met optimalisaties)?

(wb jouw STL opmerking: MS heeft daar veel gezeik om gekregen en voor release builds staat het inmiddels default weer uit. Je kon er geloof ik wel omheen werken, maar dan moest je de DLL's zelf bouwen. Ondanks dat STL templated is, zijn sommige zaken toch exported).

[ATS]

Ja, die presentatie ken ik. Ik heb ook mooie voorbeelden gezien van Stepanov over STL met daarin opmerkingen over de MS implementatie ervan Terecht dat MS dat uitgezet heeft.

Voor wie het niet weet: Stepanov is de oorspronkelijke ontwerper van de C++ STL.

[borft]

Afgezien van het feit dat java en javascript iets compleet anders zijn (wat niet echt de indruk wekt dat je weet waar je het over hebt), lijkt me dat overhead eigenlijk nooit goed is Dat gezegd hebbende, is er blijkbaar geen implementatie van Dart, maar wordt het omgezet (gecompileerd) naar javascript, en draait het dus binnen de javascript interpreter. Dit betekent dat alle overhead van de javascript interpreter ook van toepassing is op Dart. Lijjkt me dat je argumentatie dus kant nog wal raakt.

Google lijkt zelf ook te impliceren dat het voordeel van Dart hem niet in performance zit, maar in het feit dat de taal makkelijker te leren is dan javascript.

PS
Wat is in godsnaam een port in Java van Doom in Dart/WebGL? is het nu geschreven in Java? of in Javascript? of in Dart? of in WebGL?

[Jegorex]

PhantomPotato heeft het over een Doom level renderer geschreven in Dart en WebGL
https://github.com/xNotch/dark

[jeroen7s]

java <> javascript

[PhantomPotato]

Ik bedoel natuurlijk JavaScript. Ik ben niet veel bezig met webcoding laat staan Javascript.

[Qws]

Dus? Het is een hele grote verschil. En Javascript word op veel meer fronten gebruikt dan alleen voor webcoding.

[PhantomPotato]

Enige keer dat ik ooit met Javascript heb gewerkt was voor webcodig, anders is bijna elke taal beter voor wat ik doe. Ik gebruik C++ and moet soms met C# werken maar ik haat library gebruik

[jan874]

Overhead kan niet goed of slecht zijn.
Wat je wel kunt zeggen: "er is veel overhead". Over het algemeen is overhead slecht voor de performance

[i-chat]

god wanneer leren mensen het nu eens javaSCRIPT is iets heel anders dan java.

javascript is zoiets als een .bat file alleen maar text die wat simpele dingetjes in de browser doet... java is een programeertal die net als bijv .NET gecompiled / semi-compiled (bytecode) wordt en die door een runtime enviroment wordt verwerkt.

[Martinspire]

"Simpele dingetjes"
Zeker een tijd niets op internet gedaan? Javascript begint een knappe taal te worden anders.

[Jarrichvdv]

JavaScript is krachtig, maar het een "knappe taal" noemen is wat vergezocht.

[anargeek]

God wanneer leren mensen nu eens dat javascript niet meer alleen visuele effectjes zijn in een webpagina maar ook volwaardige server-side code kan draaien. Wij draaien een site met 6 miljoen bezoekers per maand volledig op javascript, voor en achterkant

[Qws]

Javascript is net zo krachtig als Java of C#.

Alleen Java of C# verplichten OOP, terwijl Javascript je veel meer vrijheid geeft.

[Left]

Ecmascript 6 zit eraan te komen: http://www.2ality.com/2014/12/es6-oop.html
Dat komt al een heel eind in de richting.

[HerrPino]

In de richting misschien. Maar het wordt er niet veel beter op eerder rommeliger. Het oude javascript moet namelijk blijven werken. Hierdoor worden ze beperkt in wat ze aanpakken en hoe ze dat doen. Javascript heeft gewoon een aantal eigenaardigheden, die je als js ontwikkelaar op een gegeven moment leert kennen. Maar er zijn gewoon net even teveel momentjes waarop je zegt WTF?!

[SuperDre]

achja, dat WTF heb ik zowat met elke taal waar ik inmiddels mee gewerkt heb, er is GEEN taal die perfect is...

[R4gnax]

In de richting misschien. Maar het wordt er niet veel beter op eerder rommeliger. Het oude javascript moet namelijk blijven werken.

Het "use strict" directive verbergt breaking changes achter een opt-in switch. Backwards compat is dus niet echt geen probleem als je het zo aanpakt.

[Enai]

Situation: there are 19 competing standards...

[melgers]

Er staat toch niet dat google met Dart stopt? Er staat dat er geen native dart runtime/vm in chrome komt. Dat is denk ook de juiste beslissing. Wat mij betreft blijft Dart dan ook gewoon een alternatief als TypeScript of CoffeeScript. Waarschijnlijk tot Ecmascript 6 er is inderdaad zoals al aangegeven.

Voor wie er zin in heeft zou ik aanraden eens naar de AngularDart vs AngularJS implementaties te kijken en daar zelf conclusies uit te trekken.

[SuperDre]

maarja, waar zou je dart dan nog rechtstreeks voor gebruiken?

[Verwijderd]

Ik snap niet zo goed dat dit als doodsteek voor Dart wordt gezien. Coffeescript is toch ook niet dood?

[YopY]

Ik denk dat een van de problemen is dat nu het gepositioneerd wordt als een compiles-naar-JS taal, ipv een daadwerkelijke JS vervanger met betere performance. Een van de hoofdredenen waarom Dart toentertijd uitgevonden was, is dat de taal beter te optimaliseren is in de interpreter.

Wat je ipv daarvan nu krijgt zijn projecten als ASM.js of Strong mode, waarbij de features die het snel draaien van JS code - nl dynamische objecten e.d. - uitgezet worden.

[wjvds]

Dart was ooit de enige nieuwe web-scripting taal die kans had om native geimplementeerd te worden in browsers, omdat Google daarop aanstuurde. Nu Google daar vanaf ziet, heeft Dart geen groot concurrentievoordeel meer t.o.v. CoffeeScript/TypeScript.

[sys64738]

Dit viel wel te verwachten. Gebruikelijke Google verhaal.

Twee jaar geleden op Devoxx was het Dart voor Dart na. En vorig jaar complete radiostilte. Zelfde verhaal als het jaar daarvoor met Angular. Enorme hype creeren en daarna er heel abrupt mee kappen.

Begrijp me niet verkeerd. Het is allemaal heel leuk spul (Dart ook wel) maar je kunt er geen peil op trekken en daarom staan grote bedrijven niet echt in de rij om het te gaan gebruiken.

[BugBoy]

AngularJS is absoluut niet dood. Google is hier zelf erg actief mee bezig en ook de community is dat. Eind oktober was er nog de ngEurope conferentie die helemaal in het teken stond van AngularJS.

Google heeft dan wel aangekondigd dat v2 van AngularJS niet backwards compatible zal zijn (en behoorlijk verschilt). Maar v1 wordt nog heel actief ondersteund, dus het is echt niet zo dat Google het helemaal laat vallen.

PS: Je nick is top. Groetjes van poke 53280,0

[Reactie gewijzigd door BugBoy op 24 juli 2024 09:56]

[damylen]

Ondertussen hebben ze aangegeven dat je v1 en v2 kan combineren en dat v2 in typescript ontwikkeld wordt

[PolarBear]

Eindelijk bredere ondersteuning voor de Pointer Events-api. Veruit superieur aan de bestaande API. Overigens was het vorig jaar nog anders: http://arstechnica.com/in...ec-stick-with-apple-tech/

[HooksForFeet]

Dat is wat ik ook dacht. Nog geen jaar geleden vond Google nog dat werken aan pointer events zinloos was omdat Apple het niet zou ondersteunen, omdat het voor performance issues zou zorgen in Webkit en blink, en het zou concepten als pull to refresh onmogelijk maken.

Een paar maanden later (zonder ontwikkeling, want daar waren ze tenslotte mee gestopt) en ineens zijn al die onoverkomelijke zaken geen issue meer? Vreemd verhaal.

[batjes]

Omdat dit een politiek spel is. Heeft weinig met limitaties in de engine te maken. Daarnaast als de engine moeite heeft met pointer events....... dan is er wat mis met je engine.

[vali]

Betekend dit dat chrome eindelijk normaal gaat werken met touchscreens? Vind de browser namelijk super traag reageren op mijn surface pro 3 als ik het vergelijk met IE11.

[batjes]

staat los van deze pointer events.

[Reactie gewijzigd door batjes op 24 juli 2024 09:56]

[Gamebuster]

Ik geef Google gelijk; Als ze wel Dart erin zouden zetten, krijg je websites als "Wij gebruiken Dart. Gebruik Google Chrome om onze website te bezoeken.".

Ja je hebt die conversie-laag, maar genoeg idioten die daar geen moeite in gaan steken als dat niet nodig is voor Chrome.

Die Dart-to-JS conversie is trouwens prima te doen.

[Reactie gewijzigd door Gamebuster op 24 juli 2024 09:56]

[Verwijderd]

Ontwikkeling van Chromium is redelijk open en veel discussies en redenaties van het Chromium team zijn goed te volgen. Zo is ook de aankondiging voor het weer opnemen van Pointer Events hier te lezen:

https://groups.google.com...pic/blink-dev/ODWmcKNQl0I

Quote:
Last year we announced that, despite our involvement in the Pointer Events standard, we were going to focus on incremental improvements to existing APIs (like Touch Events), rather than implement Pointer Events in Chromium. Since then we’ve received a steady stream of feedback from web developers, framework authors, and other browser vendors indicating that they see Pointer Events as a highly valuable addition to the platform. Since we’re committed to a web platform which evolves collaboratively through open discussion and data from real-world development, we need to take this feedback very seriously.

During this same period, many of our outstanding technical concerns with the API have made progress towards being addressed. Enabling rich touch effects which interact with scrolling now has an official avenue for exploration within the W3C, and improvements to touch-action richness are planned within the PEWG. Mouse event compatibility issues with existing models for touch are being addressed (and planned for a future version of the PE spec). The PEWG has been responsive to feedback and we enjoy the productive and collaborative relationship we have with the the other members including representative from the IE, jQuery, Mozilla and Opera teams.

Pointer Events offers some technical advantages over the existing use of Touch Events and Mouse Events. Most notably, pointer event listeners never block scrolling, and so replacing all touch event handlers with pointer event handlers will address the main longstanding source of scroll-start jank we see on Android (irrespective of whatever scheduler improvements we’re able to make to better prioritize input handling).

Als mensen eens wat beter hun best zouden doen om de daadwerkelijke feiten en overwegingen op te zoeken zouden heel wat van de commentaren van mensen op dit artikel overbodig zijn.

De strategie van het Chromium team is heel duidelijk: Het web platform even sterk maken als de mobiele app platformen. Om dat te bereiken moet het web platform op open standaarden gebaseerd zijn. Ook moet er ook een vereenvoudigingsslag plaats vinden met name om de performance en footprints van browsers beter te krijgen.

Google heeft in het geval van Pointer events vorig jaar een verkeerde beslissing genomen, daar komen ze nu na feedback van de community en verbeteringen van de Pointer Events API op terug. Google neemt uit belang voor de vereenvoudiging van het web platform Dart (hun eigen product) niet op in Chrome.

Kortom ze leven hun principes met deze twee besluiten na en die principes zijn in het belang van een sterk web platform.

[Seyaku]

Erg jammer, had stiekem wel gehoopt dat Dart de nieuwe standaard zou worden. Heb er een tijdje meer gewerkt en is echt een verademing ten opzichte van Javascript.

[Verwijderd]

Dart blijft een super mooie taal, ik zie niet in waarom dit een doodsteek is voor dart. Voor development kan je nog steeds dartium gebruiken, die wel de dart vm ondersteunt en dit is erg fijn voor debugging.

Ik raad iedereen hier aan dart een kans te geven, probeer bijvoorbeeld eens wat voorbeelden in deze dart playground:
http://dev.dart-pad.appspot.com/