Dansk Google-udvikler: Derfor er Dart bedre end Javascript til store web-apps

15. marts 2012 kl. 06:5917
Googles Javascript-alternativ Dart er ikke sluppet for kritik fra webudviklerne. Men der er gode grunde til at overveje sproget, siger en af de danske udviklere, der står bag sproget.
Artiklen er ældre end 30 dage
Manglende links i teksten kan sandsynligvis findes i bunden af artiklen.

Trænger denne verden til et nyt programmeringssprog, der erstatter det så berømte Javascript, til udvikling af store web-applikationer?

Ja, mener Google, der i efteråret 2011 sendte et bud på netop sådan et sprog på gaden med navnet Dart.

Dart er udviklet af Googles danske udviklingsafdeling i Aarhus, som også står bag browseren Chromes Javascript-motor, V8.

Formålet med sproget er rydde ud i nogle af de problemer, der indimellem gør Javascript mindre velegnet til udvikling af store webapplikationer. Den slags, der skal erstatte de programmer, der tidligere har hørt til på harddisken på en pc.

Artiklen fortsætter efter annoncen

»En stor del af den funktionalitet, man er vant til at have på desktop-pc'en, flytter nu ud i cloud'en. Men hidtil har man været tvunget til at udvikle i et sprog (Javascript, red.), som ikke er designet til at udvikle store webapplikationer, der kan konkurrere med dem, vi kender fra desktoppen,« siger softwareudvikler hos Google, Kasper Lund, til Version2.

Dart er dog ikke kommet på gaden uden at møde kritik.

Den har blandt andet gået på, at det virker meningsløst at lancere et nyt sprog som alternativ til Javascript, hvis ikke de store browserproducenter som Microsoft og Mozilla har tænkt sig at understøtte sproget.

Sprogets syntaks er også blevet kritiseret for at være for lidt nyskabende og for Java-inspireret.

Artiklen fortsætter efter annoncen

Men samtidig finder man dog også fortalere for Dart, der roser sprogets ambition om at være et bedre Javascript end Javascript til udvikling af store webapplikationer.

For netop her har Javascript ofte sin allerstørste akilleshæl, mener Google.

Ifølge Kasper Lund har Javascript populært sagt for let ved at tilgive fejl fra programmørens side. Og det kan gøre det svært at holde koden i stramme tøjler, når kodebasen svulmer op under store projekter.

»Det helt basale eksempel er der, hvor udvikleren laver en slåfejl og skriver navnet på en variabel forkert. I Dart får du feedback med det samme, mens det i Javascript først får konsekvenser langt senere,« siger Kasper Lund.

Artiklen fortsætter efter annoncen

De danske Google-udviklere har kort fortalt skabt Dart som en mellemting mellem de gammeldags, statisk oversatte og stærkt typede sprog com C og C++ og nyere dynamiske og svagt typede sprog som Javascript.

Det betyder blandt andet, at udvikleren får stillet værktøjer til statisk kodeanalyse til rådighed under udviklingen af Dart-programmer. Dermed kan potentielle problemer opdages og rettes før afviklingstidspunktet.

Men Dart arbejder også med såkaldt optionel typeannotering, som giver udvikleren mulighed for at annotere kildekoden med typer.

»Nogle gange er typen så oplagt, at man ikke gider at skrive den på i kildekoden. Men andre gange kan det være vigtigt at skrive typerne ind som en checkbar dokumentation, der hjælper andre programmører, når de skal læse koden,« siger Kasper Lund.

Det lyder som en blanding af gammeldags, statiske sprog og nye dynamiske sprog. Kan I forstå, at der er programmører i hver deres grøft, der kritiserer Dart for ikke rigtigt at være nogen af delene?

»Det er vigtigt for os, at vi finder en god mellemting mellem de statiske og stringente sprog, som meget ofte er besværlige at arbejde med, og så den anden grøft med Javascript, som i virkeligheden tillader alting. Så vi har valgt en pragmatisk tilgang, som gør, at du stadig har fornemmelsen af et letvægtsprogrammeringssprog, men med nogle af de værktøjer, som giver dig en bedre fornemmelse af, hvordan programmer opfører sig, når det kører,« siger Kasper Lund til Version2.

Ingen nyskabende syntaks

Kritikken af sprogets syntaks er ikke gået Google forbi. Men udviklerne i Aarhus har heller ikke haft nogen trang til at opfinde den dybe tallerken, fortæller Kasper Lund.

»Folk sagde 'det er da en kedelig syntaks', da vi lancerede Dart. Men det er vi faktisk meget godt tilfredse med. På syntaksniveau skal sproget ikke være nyskabende, men løse nogle basale problemer. Målet er at tillade folk hurtigt at skrive applikationer, som kan skalere og danne grundlaget for de næste rykind af webapplikationer,« siger han.

Til kritikken om, de store konkurrerende browsere ikke understøtter Dart, siger Kasper Lund:

»Svaret er, at Dart kan oversættes til Javascript, der kan køre i samtlige moderne browsere. Det er altid svært at få folk til at bruge noget, som ikke er bredt tilgængeligt, men det er jo et spørgsmål om hønen og ægget.«

Kasper Lund fortæller mere om Dart til udviklerkonferencen Goto i København 21.-23. maj 2012.

»Det er altid spændende at lancere et nyt programmeringssprog, og tanken med at holde et oplæg om Dart er at give folk et indblik i, hvordan fremtidens applikationsplatform tager sig ud ifølge Google. Men vi gør det også for at få feedback fra den voksende skare af Dart-entusiaster, som vi lærer meget af,« siger Kasper Lund til Version2.

Dart er et open source-projekt, og den virtuelle maskine bag - Dart VM - er udviklet i C++.

Version2 er mediepartner på udviklerkonferencen Goto Copenhagen 2012, hvor du kan høre Kasper Lund og en lang række andre spændende talere. Konferencen finder sted i København 21.-23. maj 2012, og du kan læse mere og melde dig til her.

17 kommentarer.  Hop til debatten
Denne artikel er gratis...

...men det er dyrt at lave god journalistik. Derfor beder vi dig overveje at tegne abonnement på Version2.

Digitaliseringen buldrer derudaf, og it-folkene tegner fremtidens Danmark. Derfor er det vigtigere end nogensinde med et kvalificeret bud på, hvordan it bedst kan være med til at udvikle det danske samfund og erhvervsliv.

Og der har aldrig været mere akut brug for en kritisk vagthund, der råber op, når der tages forkerte it-beslutninger.

Den rolle har Version2 indtaget siden 2006 - og det bliver vi ved med.

Debatten
Log ind eller opret en bruger for at deltage i debatten.
settingsDebatindstillinger
16
15. marts 2012 kl. 19:25

Når vi snakker om at køre andre sprog end Javascript i en browserplatform, så er der kun 2 veje: Enten laver du en bytecode-baseret VM og laver den idealiseret nok til at den ligner moderne arkitekturer (LLVM nærmer sig, men er stadig langt derfra). Eller også så lader du simpelthen kode eksekvere i en sandkasse på den native arkitektur - som NaCL i chrome gør det.

Jeg tror ikke der er nogen anden vej. Jeg spår umiddelbart at Dart får det svært. Nok er det et teknisk bedre sprog end Javascript, men det afgørende er om det er så meget bedre at det kan få folk til at skifte. Der er kun en måde at finde ud af det: Prøv!

8
15. marts 2012 kl. 10:34

I den ideelle verden ville vi naturligvis have en standardiseret virtuel maskine kørende i browseren, en maskine som var fleksibel nok til at understøtte mange forskellige sprog på fornuftig vis (og selv med de mangler som Torben insinuerer ovenfor, så ville JVMen være OK til formålet). I praksis håber jeg selv på at der efterhånden opstår en delmængde af Javascript som alle browsere kan oversætte på en effektiv måde, og som man kan bruge som målsprog for ens oversættere, da jeg finder det usandsynligt at browserproducenterne skulle kunne blive enige om noget så politisk som portabel mellemkode.

9
15. marts 2012 kl. 10:50

JVM er uegnet fordi den er for kompleks. Der medfølger et stort bibliotek som indeholder tusindvis af "native" kald til C kode. Det er primært derfor at Sun/Oracle har haft svært ved at stoppe fremkomsten af nye sikkerhedshuller i Java.

En neutral VM vil ikke indeholde et kæmpe bibliotek rettet imod et bestemt sprog. Hvad skal en Standard ML oversætter med Java Collections? Til hvilken nytte er tusinder af imperative og objektorienterede funktioner for en Haskell oversætter?

JVM er komplet uegnet til sprog med manuel hukommelsesallokering, for eksempel C og C++.

Det bedste bud er indtil videre Native Client.

6
15. marts 2012 kl. 10:02

Måske lidt OT, men findes der et rigtig godt IDE til udvikling af Javascript.

Som jeg ser det, så roder man lidt i blinde med Javascript, hvor jeg godt kunne savne et stærkt IDE, hvor der er code completion etc, og hvor man kunne testekøre sine scripts for at se hvordan de reagerer, på samme måde som straffen kommer prompte hvis man prøver at compilere/køre et program i f.eks. Lazarus.

14
15. marts 2012 kl. 16:36

Webstorm skulle vaere god.

11
15. marts 2012 kl. 11:23

@Christian: Aptana er gratis, ganske god, integrerer til firebug og GIT og virker rimelig ens på de forskellige platforme. Til udvikling og debugning er Chrome Developer tools eller Firebug uvurderlige. (Tryk F12 i Chrome ;).

@Artiklen: Jeg kom tidligere til at rose Dart, hvilket jeg har fortrudt. Javascript har nogle antipatterns og så slår nogle sig, fordi de ikke accepterer, at Javascript er et funktionelt sprog med prototype klassesystem forklædt i en C / Java lignende syntaks. Men hvis man accepterer de præmisser er Javascript din ven og så klarer men sig lige pludselig med færre kodelinjer pr. opgave.

For afslutningsvi at citerer RPDUP: "Strong typing is for people with weak memories" ;)

10
15. marts 2012 kl. 11:10

Jeg bruger Vim til alt, også JavaScript. JavaScript har ikke stærke typer, så Vim kan ikke fortælle mig, hvilke metoder, som der rent faktisk er på et objekt, men kender til gengæld til alle navne, brugt i min kode, og dem kan jeg så autocomplete på. I praksis fungerer det fint. Man kan så eksekvere og unit teste sin kode med Node.js. Jeg udfører følgende i en Linux shell:

  1. watch -n 0.5 --color expresso

'watch' udfører en kommando med jævne mellemrum, i mit eksempel to gange i sekundet. 'expresso' er et unit testing framework til Node.js.

Så når jeg gemmer en JavaScript fil får jeg umiddelbart efter at vide, om mine tests stadig fungerer.

2
15. marts 2012 kl. 09:00

Hvis en så central del af måden at lave hjemmesider, skal blive et fælles projekt mellem mange browsere, skal det ikke styres af en enkelt producent, men af fx. W3C. Jeg er sikker på at Google har alle mulige gode intentioner om at drive webteknologien fremad, men det skal nok til en standardiseringsorganisation før der virkeligt kunne ske noget.

1
15. marts 2012 kl. 08:44

Hvorfor opfinde et nyt sprog? Man kan bare kode i Java via Googles eget Google Web Toolkit (GWT) som oversætter Java til Javascript. Jeg kunne godt tænke mig svar fra Dart lejren for hvad det er Dart tilføjer i forhold til alle mulige andre sprog, som også kan oversættes til Javascript.

Hvis nu man synes Java alligevel er lidt for "kedelige syntax" så kan man nu også bruge GWT sammen med Scala.

Det vi har brug for er ikke et nyt sprog, for vi bliver alligevel aldrig enige om hvad det bedste sprog er. Vi har derimod brug for en fælles VM så man kan udvikle nye sprog uden at gå via Javascript.

7
15. marts 2012 kl. 10:21

Hvorfor opfinde et nyt sprog? Man kan bare kode i Java via Googles eget Google Web Toolkit (GWT) som oversætter Java til Javascript. Jeg kunne godt tænke mig svar fra Dart lejren for hvad det er Dart tilføjer i forhold til alle mulige andre sprog, som også kan oversættes til Javascript.

JavaScript er super langsomt at oversætte. Intet sprog har som JavaScript fået opmærksomhed til at blive optimeret, og det er stadig ikke særlig hurtigt i forhold til andre kendte sprog, fordi oversætterne skal tage sig af ting som manglende specifikationer, dårlige datatype-modeller o.lign.

Idéen med Dart er at faktisk at lave en specifikation der er hurtig, hvor en del af det syntaktiske sukker i JavaScript er fjernet, så det kan oversættes hurtigere.

Nogle vil argumentere for at vi bare kan specificere JavaScript bedre, etc., men det har intet hold i praktisk. Der er ingen måde at definere hvilken version af JavaScript man bruger fordi det aldrig var tanken, en lang bedre løsning er at introducere et nyt sprog.

Folk gider ikke bruge Python 3.0 fordi det ændre nogle fundementalle paradigmer. Så har vi Python splittet op i to lejre; 2.7-folkene og 3.0-folkene. Ville det ikke bare være en bedre løsning at lave to sprog?

Vi har ikke brug for færre sprog, vi har brug for flere sprog. Flere sprog i stedet for versionsnumre.

3
15. marts 2012 kl. 09:19

Det vi har brug for er ikke et nyt sprog, for vi bliver alligevel aldrig enige om hvad det bedste sprog er. Vi har derimod brug for en fælles VM så man kan udvikle nye sprog uden at gå via Javascript.

Enig. Der er på grund af manglen på en god VM, der understøttes af alle browsere, nogle, der bruger Javascript som VM. Javascript er bare ikke specielt godt til dette formål (alt for dynamisk), og JVM er ikke meget bedre (dur kun til Java-lignende sprog).

4
15. marts 2012 kl. 09:23

Du kan da kører både Ruby og Python på JVM, dem ville jeg da ikke kategorisere som Java lignene sprog.

5
15. marts 2012 kl. 09:36

Du kan da kører både Ruby og Python på JVM, dem ville jeg da ikke kategorisere som Java lignene sprog.

De er da begge objektorienterede og imperative, har begge nulpointere i alle sammensatte datatyper, og bruger begge automatisk lagerstyring. At sige at Ruby og Python ikke ligner Java vidner om snæver erfaring med programmeringssprog.

Dertil kommer, at oversættelsen af disse sprog til JVM har krævet tricks for at omgå JVM's antagelser om data og typer. Da JVM er Turingkomplet, kan man selvfølgelig oversætte alle sprog til JVM. Men det gør det ikke nødvendigvis egnet til formålet, på samme måde som Javascript heller ikke er det, selv om f.eks. der findes en oversætter for Standard ML, der genererer Javascript.

12
15. marts 2012 kl. 11:28

I forhold til sammenligningen af ruby/python med java vil jeg stadig mene det afhænger af indgangsvinklen. Alene forskellen mellem et statisk types sprog, og dynamisk typisk sprog, synes jeg gør kodningen tilpas forskellig, til at jeg ikke ville sige at sprogne minder om hinanden. At de stadig deler rigtig mange ting er korrekt, men vi er vist nærmere ude i et spørgsmål om hvor meget, og på hvilke punkter sprog skal adskille sig, for at kunne kalde sig væsentligt forskellige fra hinanden.

Men i den sammenhæng kunne det da være interresant at diskuttere hvor forskellige sprog der skal være understøtet i en eventuelt ny VM til web applikationer. Hvis vi skal have en virtuel maskine, udviklet fra bunden, med support for alle typer sprog, adskilt på alle parameter, bliver det så ikke i lidt for stort projekt?

I forhold til det funktionelle kan det da heller ikke være helt umuligt, Scala, omend det også er object orienteret, er da et funktionelt sprog. Clojure er et andet bud på et funktionelt sprog til JVM.

Med hensyn til de dynamiske sprog på JVM, så gætter jeg på at du med "har krævet tricks for at omgå JVM's antagelser om data og typer" mener den nødvendige generering af 'synthetic types' interfaces til parametre og returtyper for at tilfredstille byte kodens methodinvoke. Et problem som er blevet addreseret med invokedynamic. Hvis det var andre problemer du tænkte på, så fyr endlig løs :D

13
15. marts 2012 kl. 11:46

Hvis vi skal have en virtuel maskine, udviklet fra bunden, med support for alle typer sprog, adskilt på alle parameter, bliver det så ikke i lidt for stort projekt?

Nej det bliver et mindre og nemmere projekt... fordi du ikke fristes til at tilføje alt muligt irrelevant der kun virker for et bestemt sprog.

Jeg ender altid med at fortælle om Native Client i tråde der omhandler Dart. Det er et meget misforstået koncept men det er faktisk genialt.

Ideen er at bruge rå maskinekode som "bytecode". Dermed er der åbnet op for at alle sprog kan køre med fuld hastighed.

Sikkerhed er indbygget således at dit maskinekode-program ikke har fuld adgang til maskinen. Du kan kun manipulere maskinen igennem et API som giver præcis de samme muligheder som man har med Javascript.

Ulempen er at websiderne er nødt til at indeholde versioner til de mest gængse CPU'er. En udgave til 32 bit x86, en anden til 64 bit og en tredie til ARM og så videre. Der findes to svar på dette: 1) Klienten kan om nødvendigt simulere en anden CPU, 2) serveren kan levere en LLVM udgave. LLVM er dog ikke 100% platformsuafhængig da man i LLVM bytekode laver antagelser omkring ordbredde. Det kan løses ved at have LLVM filer for 32 og 64 bit samt most significant/least significant bit ordering (i alt 4 filer).

Det lyder måske af meget men i praksis har man jo bare oversætteren til automatisk at lave de versioner der er brug for.

17
17. marts 2012 kl. 14:36

Her er lidt info om hvorfor der ikke er en bytecode vm:
<a href="http://www.dartlang.org/articles/why-not-bytecode/">http://www.dartlang…;

Jeg bemærker to ting i artiklen på dartlang.org. For det første henviser de til NaCl.

Det andet er at deres eksempler med JVM og Scala misser en vigtig pointe. De konkluderer at man bør bruge Dart sproget som "VM". Men Scala kan IKKE oversættes til Java. Scala oversættes til Java bytekode ved at bruge tricks, som ikke kan udtrykkes i Java-sproget. Det har medført at Scala-GWT projektet har måtte opfinde en variant af Java kaldet jRibble http://scalagwt.github.com/jribble. Det er nemlig sådan at GWT ikke kan oversætte bytekode men kræver Java kildekode, så derfor går Scala-GWT omvejen over jRibble som så oversættes af GWT til JavaScript.

Man har naturligvis tilsvarende problemer når man vil bruge Dart eller JavaScript som "VM" for et sprog, som virker fundamentalt anderledes. Alt den snak om problemer med bytekode er der også hvis man oversætter til kildekode og i nogle tilfælde, som eksemplet med jRibble, er det endnu mere begrænsende.

Guderne vide at GWT laver nogle meget kreative krumspring når de oversætter Java til JavaScript. Og der er stadig massere af ting der ikke virker, som reflektion og dynamisk indlæsning af klasser.

Jeg har ikke noget imod at nogle arbejder på et sprog som Dart. Men jeg synes Google burde presse lidt mere på med at få udbredt NaCl. Når det er klaret, så er banen ryddet for alle mulige sprog, inklusiv Dart.