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

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.

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.

Læs også: Nyt i Chrome 10: 66% hurtigere JavaScript og sandkasse til Flash

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.

»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.

Læs også: Microsoft kritiserer Googles Dart-sprog: Vi foretrækker Javascript

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

Læs også: Googles Dart skuffer udviklerne: ’Putter Java tilbage i Javascript’

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.

Læs også: Derfor elsker sprognørden Dart: Alt hvad man kunne håbe på

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.

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.

Tips og korrekturforslag til denne historie sendes til tip@version2.dk
Kommentarer (17)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Baldur Norddahl

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.

  • 2
  • 0
Christian Hedemann Olsen

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
  • 0
Torben Mogensen Blogger

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).

  • 1
  • 0
Torben Mogensen Blogger

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.

  • 1
  • 0
Christian Nobel

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.

  • 0
  • 1
David Rechnagel Udsen

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.

  • 4
  • 0
Troels Henriksen

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.

  • 0
  • 0
Baldur Norddahl

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.

  • 1
  • 0
Robert Larsen

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:

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.

  • 1
  • 0
Palle Simonsen

@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" ;)

  • 0
  • 0
Anders Kreinøe

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

  • 0
  • 0
Baldur Norddahl

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.

  • 1
  • 0
Jesper Louis Andersen

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!

  • 2
  • 0
Baldur Norddahl

Her er lidt info om hvorfor der ikke er en bytecode vm:
http://www.dartlang.org/articles/why-not-bytecode/

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.

  • 0
  • 0
Log ind eller Opret konto for at kommentere