Video: Googles Lars Bak sviner Javascript og drømmer om en Dart-chip

Jeg synes nu stadig at Tomatjuice ville have været et bedre navn til V8-motoren.

Det er lidt synd for Lars at Microsoft, af alle, bare har fået en basalt set bedre idé med Typescript end Googles Dart. Gad vide hvor lang tid han skal bruge på at tænke over tingene, før Dart-håndklædet kastes i ringen?

Det er lidt synd for Lars at Microsoft, af alle, bare har fået en basalt set bedre idé med Typescript end Googles Dart. Gad vide hvor lang tid han skal bruge på at tænke over tingene, før Dart-håndklædet kastes i ringen?

Pudsigt, jeg synes det er synd for Microsoft, at de ikke har mere fantasi end at kopiere Coffeescript eller tage et subset (cross-compilation) af Google's Dart. Man skulle tro de efterhånden havde dårlige erfaringer med at kopiere, VBscript blev f.eks. heller aldrig til noget.

Det er lidt synd for Lars at Microsoft, af alle, bare har fået en basalt set bedre idé med Typescript end Googles Dart. Gad vide hvor lang tid han skal bruge på at tænke over tingene, før Dart-håndklædet kastes i ringen?

Det skal du ikke regne med. TypeScript er ikke en langsigtet løsning. JavaScript er stadig - til trods for ting som V8-motoren - meget langsomt. Og kun ved at lave et nyt og bedre formaliseret sprog kan dette løses.

Så jeg håber sandelig ikke at Bak kaster håndklædet i ringen.

Det skal du ikke regne med. TypeScript er ikke en langsigtet løsning.

TypeScript er netop den langsigtede løsning. Dart vil for altid være et Google only projekt. Hvor TypeScript er en implementation af næste version af JavaScript som standardiseringsarbejdet indtil videre er nået frem til. Dvs. TypeScript kommer i browseren på sigt. Det kommer Dart aldrig.

JavaScript er stadig - til trods for ting som V8-motoren - meget langsomt. Og kun ved at lave et nyt og bedre formaliseret sprog kan dette løses.

Hvad er det der er langsomt i JavaScript? Personligt har jeg været overrasket over hvor vilde ting man kan bygge i JavaScript, ting som jeg troede var umuligt, kunne sagtens lade sig gøre.

Og de Node.js backends jeg er med til at bygge performer røven ud af bukserne.

Så jeg håber sandelig ikke at Bak kaster håndklædet i ringen.

Det tror jeg heller ikke han gør, men det er spildte kræfter.

Hvad er det der er langsomt i JavaScript? Personligt har jeg været overrasket over hvor vilde ting man kan bygge i JavaScript, ting som jeg troede var umuligt, kunne sagtens lade sig gøre.

Alting kan lade sig gøre i alle sprog. Men som eksempel, så er Dart-VM'en, til trods for at den er langt mere primitiv end V8, 20% hurtigere i en række typiske benchmarks (det var i hvert fald hvad Dart-manden præsenterede til GOTO). Dette er til trods for at Dart stadigvæk ikke er et synderligt ydelsescentrisk sprog.

Og de Node.js backends jeg er med til at bygge performer røven ud af bukserne.

Det er bare fordi Node.js er en nem wrapper rundt om epoll()-systemkaldet. Tag et andet sprog, strukturér din kode asynkront omkring epoll(), og du vil få lignende ydelse. (Måske kunne man endda vælge et sprog hvor ens kode ikke ligner et mellemstadie fra en oversætter. Jeg synes at Node.js-programmer ofte ser ud som om de er skrevet med manuel continuation-passing-style.)

TypeScript er netop den langsigtede løsning. Dart vil for altid være et Google only projekt.

Altså til forskel fra Microsoft, så udvikler Google jo gerne værktøjer og runtimes på kryds af platforme. Omvendt så lavede Microsoft jo kun til MSIE, selv om JavaScript var de-facto standard. Det er der jo egentlig ikke noget viddere nyt i; Microsoft ønsker at promovere og supportere deres platform (Windows) imens Google bare vil have browseroplvelsen så god som muligt, så mange steder som muligt.

Hvor TypeScript er en implementation af næste version af JavaScript som standardiseringsarbejdet indtil videre er nået frem til. Dvs. TypeScript kommer i browseren på sigt. Det kommer Dart aldrig.

Hvis TypeScript var en early-draft implementation af en kommende standard ville det være interesant, men jeg synes du bør komme med dokumentation for denne påstand. Der er [http://wiki.ecmascript.org/doku.php?id=harmony:proposals](ikke noget hos Ecma) der mig bekendt afslører dette.

Hvad er det der er langsomt i JavaScript? Personligt har jeg været overrasket over hvor vilde ting man kan bygge i JavaScript, ting som jeg troede var umuligt, kunne sagtens lade sig gøre.

Du er godt hjulpet af Moore's lov og dygtige VM specialister. Faktum er jo bare at JavaScript ikke er lavet til dét det bruges til i dag. Prøv du f.eks. at lægge 0.1 kr til 0.2 kr og se hvordan du på ingen måder kan få 0.3 kr i et JavaScript program p.g.a. mangel af en base10 type og fordi IEEE-754 semantik er eneste mulighed.

VBScript bliver da brugt en hel del rundt omkring - f.eks. til loginscripts.

Du blander VBScript sammen med VBA (Visual Basic for Applications) som blev brugt som scripting sprog uden for browseren før Microsoft kom med deres PowerShell.

TypeScript er netop den langsigtede løsning. Dart vil for altid være et Google only projekt. Hvor TypeScript er en implementation af næste version af JavaScript som standardiseringsarbejdet indtil videre er nået frem til. Dvs. TypeScript kommer i browseren på sigt. Det kommer Dart aldrig.

Ja, vi koder vist også stadig alle sammen i FORTRAN og ALGOL64. Før eller siden vil web-applikationer blive så avanceret, at JavaScript ikke vil kunne klare de påkrævende hastigheder, fordi det bare ikke kan blive hurtigt nok. (Du kan ikke lave det samme trick i browseren som i Node.js.)

Og her hjælper TypeScript ikke. Hejlsberg sagde selv at formålet med TypeScript var ikke at gøre JavaScript hurtigere eller at rette fundamentale problemer i JavaScript. Det var bare at gøre alting mere uigennemskueligt, da der nu er endnu flere lag af oversættelse fra din kode til maskinkode.

Hvad er det der er langsomt i JavaScript? Personligt har jeg været overrasket over hvor vilde ting man kan bygge i JavaScript, ting som jeg troede var umuligt, kunne sagtens lade sig gøre.

Jeg har også været overrasket. Men som Bak selv pointere, så er der en øvre grænse når et sprog er designet så dårligt som JavaScript. Eller om det er overhovedet er designet er jo et godt spørgsmål.

Og de Node.js backends jeg er med til at bygge performer røven ud af bukserne.

Jeg tror også du får lignede køretider ved andre sprog, dog uden at din kode skal ligne lort (altså JavaScript).

Det tror jeg heller ikke han gør, men det er spildte kræfter.

Ja, at prøve at rette op på groteske fejl er spild af tid.

Alting kan lade sig gøre i alle sprog.

Ikke i praksis.

Men som eksempel, så er Dart-VM'en, til trods for at den er langt mere primitiv end V8, 20% hurtigere i en række typiske benchmarks (det var i hvert fald hvad Dart-manden præsenterede til GOTO). Dette er til trods for at Dart stadigvæk ikke er et synderligt ydelsescentrisk sprog.

Det er jo et fedt, når Dart alligevel skal kompileres til JavaScript for at køre i alle andre browsere end Chrome. Og hvornår har du sidst siddet med et problem hvor du sagde: "Bare JavaScript var 20% hurtigere, kunne det her lade sig gøre". Performance problemer i klienten skyldes som regel ALT andet en JavaScript, fx redraws, for mange http kald, langsomme CSS regler, latency osv.

Hvis TypeScript var en early-draft implementation af en kommende standard ville det være interesant, men jeg synes du bør komme med dokumentation for denne påstand. Der er [http://wiki.ecmascript.org/doku.php?id=harmony:proposals](ikke noget hos Ecma) der mig bekendt afslører dette.

Du kan fx se den her video hvor Hejlsberg taler om hvordan de har rettet i TypeScript fordi standarden ændrede sig, og hvor han siger direkte at hvis standarden ændrer sig så skal TypeScript følge med.

http://channel9.msdn.com/Shows/Going+Deep/Anders-Hejlsberg-and-Lars-Bak-...

Du er godt hjulpet af Moore's lov og dygtige VM specialister. Faktum er jo bare at JavaScript ikke er lavet til dét det bruges til i dag.

Det ændrer stadig ikke på at det ikke giver mening at prøve at løse et performance problem der ikke eksisterer i praksis.

Prøv du f.eks. at lægge 0.1 kr til 0.2 kr og se hvordan du på ingen måder kan få 0.3 kr i et JavaScript program p.g.a. mangel af en base10 type og fordi IEEE-754 semantik er eneste mulighed.

Lige meget hvordan du vælger ar repræsentere din tal med bits vil der være tilsvarende problemer. Så hvis du skal lave præcise beregninger, skal du under alle omstændigheder tage højde for hvordan dine tal er repræsenteret og tage højde for det i koden. Dette er ikke et JavaScript-only problem.

Lige meget hvordan du vælger ar repræsentere din tal med bits vil der være tilsvarende problemer. Så hvis du skal lave præcise beregninger, skal du under alle omstændigheder tage højde for hvordan dine tal er repræsenteret og tage højde for det i koden. Dette er ikke et JavaScript-only problem.

Med en rational-tal repræsentation (altså en brøk) vil du have ubegrænset præcision af vilkårligt store (rationale) tal.

Det er jo et fedt, når Dart alligevel skal kompileres til JavaScript for at køre i alle andre browsere end Chrome.

Hvis du havde læst op på lektien, så ville du vide at Dart først lige er udkommet i sin første standardiserede version, og var derfor ikke engang implementeret i Chrome (dog i Chromium). Det er derfor først nu at du skal forestille dig at andre browsere vil implementere Dart. Og tanken er ikke så absurd som du godt kunne tænke dig den var.

Og hvornår har du sidst siddet med et problem hvor du sagde: "Bare JavaScript var 20% hurtigere, kunne det her lade sig gøre".

Sjældent. Jeg undgår JavaScript så meget jeg kan, da det er et ulideligt grimt sprog. Så nu prøver jeg at programmere gode gammeldags statiske sider.

Performance problemer i klienten skyldes som regel ALT andet en JavaScript, fx redraws, for mange http kald, langsomme CSS regler, latency osv.

CSS er i øvrigt et andet gøglersprog, som godt kunne bruge en erstatning. Heldigvis har W3C dog tænkt så langt, at man kan bruge andre sprog end CSS og JavaScript i browseren med type=-attributten.

JavaScript er (ligesom Lars Bak siger om Dart), et programmeringssprog i udvikling - EcmaScript 5 retter op på en masse mangler i JavaScript, og EcmaScript.Next (ES6), endnu flere.

At brokke sig over JavaScripts syntax er en ulideligt overbrugt cliché. Hvert sprog har sin syntax - JavaScripts er ikke fantastisk. Heldigvis har vi CoffeeScript (og andre preprocessorer), der søder syntaksen en del. Ydermere har een af Mozillas interns for nyligt kodet macros til JavaScript (som vi kender dem fra Scheme), der gør det muligt at definere ny syntax.

JavaScript performance er et ligeså gennemtygget emne. Moderne JIT compilere gør et utroligt arbejde for at forbedre JavaScripts performance og med moderne processorer, WebGL, GPU acceleration, parallel computing (River Trail) og asynkrone workers er JavaScript blevet et sprog med utrolige muligheder.

Vi har altså en hurtig og yderst alsidig platform at arbejde med og med diverse preprocessorer er JavaScript i sandhed blevet "Assembly language of the web", eller rettere: "C for the Web". Hvor er Darts use-case? Hvad tilbyder det, som JavaScript ikke gør? Hvorfor har vi brug for Dart, når der allerede sker så meget på JavaScript fronten for at forbedre hvad vi allerede har?

• Crockford, formulerer omtrentlig min opfattelse af Dart.

• Brendan Eich beskriver ligeledes de bekymringer som browser-vendors har mht. et nyt scripting sprog i browseren (Og det er en generelt spændende diskussion).

Edit:

Hvis du havde læst op på lektien, så ville du vide at Dart først lige er udkommet i sin første standardiserede version, og var derfor ikke engang implementeret i Chrome (dog i Chromium). Det er derfor først nu at du skal forestille dig at andre browsere vil implementere Dart. Og tanken er ikke så absurd som du godt kunne tænke dig den var.

Jo, absurd - Se Brendan Eichs tråd på HN.

Jo, absurd - Se Brendan Eichs tråd på HN.

Lige så absurd som at nogen overhovedet ville bruge ARM-arkitekturen til noget. Ak ja, at kalde JavaScript Webbens assemblersprog er at stille sig tilfreds med en klodset byggesten, som sagtens kunne være bedre.

Vi kan vel argumenterer for at vi igennem 20-30 år - bl.a. pga. Microsoft og IBM - har stillet os tilfreds med en klodset byggesten, nemlig x86. Det er ikke uden grund at x86 er den sidste CISC-arkitektur.

I lang tid var andre arkitekturer - heribland ARM - anset som en drøm at få til at true x86s dominans, og man anså dem som hobbysprog. Det samme kan JavaScripts dominans velsagtens sammenlignes med.

For nu hvor ARM-arkitekturen har vist at det giver mening at have andre byggesten, når forholdene ændre sig (fra skrivebordsdatamat til tavledatamat/datafon), så har man accepteret to byggesten. Og selv Microsoft har gidet kodet dele af Windows NT-kernen om til ARM.

Og selvom at JavaScript nok næppe vil blive slået af tronen i morgen eller om 3-5 år, så vil den før eller siden. Og så uden tvivl af noget bedre.

Faktisk, nu hvor vi er ved det, så er HTML (med HTML5) og CSS også noget lort.

Hvad hjælper det at svare på min indlæg, uden nogle konkrete forslag eller mangler ved JavaScript/HTML5 og CSS?

JavaScripts dominans vil fortsætte så længe det er et sprog i udvikling - og det er det. Jeg har endnu ikke blevet præsenteret for et modent alternativ til JavaScript.

Hvad hjælper det at svare på min indlæg, uden nogle konkrete forslag eller mangler ved JavaScript/HTML5 og CSS?

Jeg har endnu ikke personligt brugt nok tid på tænke på disse ting, men jeg skal nok komme tilbage til dig når jeg har. Men eftersom at have brugt både JavaScript, HTML(5) og CSS i mange år, så må jeg erkende at de alle sammen er ret dårligt designet.

JavaScripts dominans vil fortsætte så længe det er et sprog i udvikling - og det er det. Jeg har endnu ikke blevet præsenteret for et modent alternativ til JavaScript.

Men JavaScript skal vel stadig kunne understøtte tidligere versioner af JavaScript, ikke? Jeg tvivler på at ECMAScript vil være lige så modige som Python-udviklerne og gøre Python 3.0 inkompatibelt med Python 2.x.

Så selv hvis gammel JavaScript var tilladt i ny JavaScript, ville det så stadig gøre det samme? Vil det forblive tilladt? Og så videre.

For at undgå alle disse spørgsmål, sørger man får at JavaScript forbliver bagud kompatibelt, så det bliver en ren x86/Windows-fest. Uha, sikke en fest. Det skal derfor stadig være tilladt at misbruge typerne på en måde, der gør oversættelsen langsommere. Bare se på alt det gøgl som V8-motoren skal igennem for at gøre JavaScript nogenlunde brugbart.

Men nok om det, jeg nyder personligt godt af at skrive små befalingspogrammer til mig selv. Preprocessing kunne måske hjælpe, hvis du så samtidigt kunne fortælle den fortolker, at dette JavaScript er preprocesseret. Men så opnår vi vel en de facto splittelse af sproget alligevel. Sikke et helvede!

Hvis du havde læst op på lektien, så ville du vide at Dart først lige er udkommet i sin første standardiserede version, og var derfor ikke engang implementeret i Chrome (dog i Chromium). Det er derfor først nu at du skal forestille dig at andre browsere vil implementere Dart. Og tanken er ikke så absurd som du godt kunne tænke dig den var.

Hvad får dig til at tro at jeg ikke ved det?

http://en.wikipedia.org/wiki/Dart_(programming_language)

Microsoft's JavaScript team has stated that:

"Some examples, like Dart, portend that JavaScript has fundamental flaws and to support these scenarios requires a 'clean break' from JavaScript in both syntax and runtime. We disagree with this point of view."[8]

Apple engineer Oliver Hunt, working on the WebKit project (which powers both Safari and Google's own Chrome browser) has stated:

Adding an additional web facing language (that isn't standardized) doesn't seem beneficial to the project, if anything it seems harmful (cf. VBScript in IE).[9] [...] Adding direct and exposed support for a non-standard language [Dart] is hostile to the open-web by skipping any form [of] 'consensus' driven language development that might happen, and foisting whatever language we want on the web instead. This implicitly puts any browser that supports additional proprietary extensions in the same position as a browser supporting something like VBScript, and has the same effect: breaking the open web by making content that only works effectively in a single product.[10]

Mozilla's Brendan Eich, who developed the JavaScript language, has stated:[11]

I guarantee you that Apple and Microsoft (and Opera and Mozilla, but the first two are enough) will never embed the Dart VM. So 'Works best in Chrome' and even 'Works only in Chrome' are new norms promulgated intentionally by Google. We see more of this fragmentation every day. As a user of Chrome and Firefox (and Safari), I find it painful to experience, never mind the political bad taste.

Douglas Crockford, when asked about Dart during his Programming Style and Your Brain lecture, replied[12]:

So, I've thought for a long time ... if I could take a clean sheet of paper and write [a new language] that retains all the goodness of [Javascript] ... I would not have come up with anything like Dart.

Hvad er det du ved som ingen andre ved, det gør at ideen om Dart i alle browsere ikke er absurd?

Hvorfor findes der ikke et native script sprog til .NET? (Microsoft har trukket sig ud af f.eks. IronScript) Hvorfor handler det altid om lidt syntaktisk sukker oven på javascript?

At folk der har skabt en karriere oven på Javascript ikke kan se fordelen i at lave bedre sprog end Javascript, er ikke så mærkelig. Der findes også purister som hader f.eks. Coffescript fordi det ikke er ægte Javscript.

Hvorfor findes der ikke et native script sprog til .NET? (Microsoft har trukket sig ud af f.eks. IronScript) Hvorfor handler det altid om lidt syntaktisk sukker oven på javascript?

At folk der har skabt en karriere oven på Javascript ikke kan se fordelen i at lave bedre sprog end Javascript, er ikke så mærkelig. Der findes også purister som hader f.eks. Coffescript fordi det ikke er ægte Javscript.

JScript .NET ?

Nok fordi det ved et .net sprog ligesom Dart ville være begrænset til én browser, modsat TypeScript som stadig kører i alle browsere hvor JavaScript virker.

Ideelt kunne man nok skifte til noget bedre end JavaScript, men TypeScript er den realistiske løsning p.t. En typestærk afløsning for JavaScript ville være dejligt, men det skal hverken være MS eller Google der som de eneste står bag.

Nok fordi det ved et .net sprog ligesom Dart ville være begrænset til én browser, modsat TypeScript som stadig kører i alle browsere hvor JavaScript virker.

Jeg er ikke den store fan af Dart, men jeg må påpege at det kan køre på lige så mange browsere som TypeScript.

At folk der har skabt en karriere oven på Javascript ikke kan se fordelen i at lave bedre sprog end Javascript, er ikke så mærkelig. Der findes også purister som hader f.eks. Coffescript fordi det ikke er ægte Javscript.

Tvært imod. Når man arbejder med JavaScript hver dag, vil man netop gerne have det forbedret. Men det vigtigste er nu engang at det der bliver lavet er understøttet i alle browsere.

En af grundene til at JavaScript er så super fedt at arbejde med, er alle de steder det kan bruges. Du kan bygge ting med det, som alle i hele verden har mulighed for at bruge.

Jeg hader ikke CoffeScript (og Dart) fordi det ikke er ægte JavaScript, hvis det ikke skulle kompileres ville jeg kigge mere på det. Men jeg har ikke tænkt mig at indføre kompleksitet og kompilering for at løse et problem jeg ikke har.

At bygge applikationer i browseren er svært, men det er ikke pga JavaScript. Det er pga helheden, med asynkrone kald, events, HTML, DOM, CSS og så videre.

Tiltag som Twitter bootstrap, AngularJS, Backbone osv. løser mange flere reele udfordringer end CoffeScript og specielt Dart nogensinde vil.

Men JavaScript skal vel stadig kunne understøtte tidligere versioner af JavaScript, ikke? Jeg tvivler på at ECMAScript vil være lige så modige som Python-udviklerne og gøre Python 3.0 inkompatibelt med Python 2.x.

ECMAScript 5 introducerede JavaScript strict mode, der fjerner bagudkompatibilitet for en række ting. Fremtidige JavaScript standarder vil blive baserede på den nuværende strikse standard. Det taget i betragtning, giver din argumentation ikke så meget mening.

Jeg er ikke den store fan af Dart, men jeg må påpege at det kan køre på lige så mange browsere som TypeScript.

Kører Dart i alle browsere? (uden at installere et nyt plugin)

Per: Dart kan ligesom TypeScript også fortolkes til Javascript.

Dart tillader tilgengæld ikke at udvide eksisterende javascript projekter eller benytte standard javascript libraries såsom JQuery (omend man vist er igang med at porte det til Dart) hvilket er en af de store forskelle i forhold til TypeScript.

Jeg kan godt lide visionen bag Dart - javascript er i bund og grund et håbløst sprog, men jeg tror desværre aldrig at det lykkedes dem at få VM's indbygget i alle de større browsere hvorved vi stadig ender med at det bliver afviklet som javascript i alle andre browsere end Chrome og så ryger ideen desværre lidt. Med Microsofts introduktion af TypeScript er der ikke meget der tyder på at de har i sinde at støtte op om Dart - det skyldes formentlig udelukkende at Google står bag, der går for meget politik i det.

Elsker iøvrigt disse topDatamat videoer og fedt at Lars Bak stiller op til den slags ;-)

... du er fandeme fræk i den Hawaii-skjorte!