allan ebdrup bloghoved ny

TypeScript slår Dart og CoffeScript

TypeScript er Microsofts bud på hvad der skal til for at bygge store webapplikationer (og Node.js applikationer). TypeScript gør basalt set at du kan programmere i den næste version af JavaScript, allerede i dag. Selv om standardiseringsarbejdet ikke er færdigt.

Dvs. du får blandt andet:

  • Valgfrie stærke typer
  • Klasser, interfaces og andet objektorienteret guf

Det gør at der kan laves bedre statisk kodeanalyse. Det betyder at når TypeScript kompileren kompilerer koden, kan den fange kodefejl, der ellers først ville dukke op når koden køres. Udviklingsværktøjer kan også lave bedre refaktorering af kode, bedre IntelliSense og så videre.

TypeScript compileren er Open Source og kompilerer TypeScript-kode til standard JavaScript, der kan køre i alle browsere.

SourceMap er også en del af TypeScript.
Det betyder at når du bruger udviklingsværktøjerne i browseren, kan du debugge din kode som den ser ud i TypeScript, i stedet for at skulle sidde og se på den JavaScript-kode som TypeScript kompileren genererer.

TypeScript er en udvidelse af JavaScript. Det har den kæmpe fordel, at du kan tage din eksisterende JavaScript applikation, fuldstændig uden ændringer og kalde den TypeScript. Så kan du gradvist indføre elementer fra TypeScript. Det er en simpel idé og helt rigtigt tænkt.

I forhold til Dart og CoffeScript kan jeg godt lide at TypeScript holder sig til den fremtidige standard for JavaScript. Teoretisk kan du på sigt køre din TypeScript i browseren, uden kompilering.

Det har dog den ulempe, at du risikerer at TypeScript ændrer sig, hvis standardiseringsarbejdet pludselig trækker JavaScript i en anden retning. Anders Hejlsberg har udtalt, at hvis det sker, så følger TypeScript med standarden.

En anden ulempe der er ved både TypeScript, Dart og CoffeScript, er at de skal kompileres. Det er lidt pudsigt at løsninger, der hævder at gøre udvikling af store applikationer nemmere, indfører en ulempe der kun bliver større, jo større din kodebase er. Det har været en kæmpe fordel, at der ikke er behov for up-front kompilering, på de Node.js projekter og store webapplikationer som jeg har arbejdet på.

Når jeg ser på sprog-kampen mellem TypeScript, Dart, CoffeScript og alle de andre muligheder der er, så vinder den simpleste idé. For mig er der ingen tvivl om at det er TypeScript. Personligt vil jeg dog vælge den aller simpleste løsning af dem alle: At bruge JavaScript som det ser ud i dag.

Hvad vælger du?

Kommentarer (16)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
David Rechnagel Udsen

TypeScript gør basalt set at du kan programmere i den næste version af JavaScript, allerede i dag. Selv om standardiseringsarbejdet ikke er færdigt.

Dette er en sandhed med modifikationer. Det er rigtigt at TypeScripts klasse-syntaks er den samme som er foreslået til ECMAScript 6-standarden, men typer er ikke foreslået til JavaScript endnu. Så hvis du bruger TypeScripts typer (hvilket, jeg gætter, er hovedpointen), så kan ikke køres som JavaScript i den nærmeste fremtid.

Derudover, så selvom det ligner forslagene, så er det slet ikke til at sige, om forslagene vil forblive sådan, da de jo - som sagt - blot er forslag. Det vil være naivt at tro at fremtidens JavaScript kommer til at ligne TypeScript i dag.

Men ingen af delene løser det fundamentale problem med JavaScript: At det ikke er designet til det bliver brugt til i dag. Det er trist når man skal bruge en tredje-parts-bibliotek til et VM-sprog, for at være sikker på at det faktisk virker på alle platforme der understøtter sproget. Det er også ret nedern at man bruger så meget tid med JavaScript på, at arbejde sig uden om JavaScripts egne mangler.

På nær dem med Stockholmssyndrom overfor JavaScript, så er der sikkert flere der godt kunne tænke sig et alternativ der var lækkert at kode i, og som faktisk også var hurtigere, fordi det ikke bare var oversat til JavaScript alligevel.

  • 7
  • 2
Troels Henriksen

En anden ulempe der er ved både TypeScript, Dart og CoffeScript, er at de skal kompileres. Det er lidt pudsigt at løsninger, der hævder at gøre udvikling af store applikationer nemmere, indfører en ulempe der kun bliver større, jo større din kodebase er. Det har været en kæmpe fordel, at der ikke er behov for up-front kompilering, på de Node.js projekter og store webapplikationer som jeg har arbejdet på.

Er det så stor en ulempe? Det virker som om mange rigtig store systemer er baseret på oversatte sprog, og jeg har selv aldrig haft problemer med at skulle køre en oversætter. Og uden en oversætter, hvornår ville du så lave typetjek?

  • 6
  • 0
Allan Ebdrup

På nær dem med Stockholmssyndrom overfor JavaScript, så er der sikkert flere der godt kunne tænke sig et alternativ der var lækkert at kode i, og som faktisk også var hurtigere, fordi det ikke bare var oversat til JavaScript alligevel.


Jeg må så være en af dem med Stockholmssyndrom.

Det er faktisk så udpræget at jeg bevist har tilrettelagt min karrierevej så jeg kunne kode i JavaScript dagen lang.

Og jeg er så hårdt ramt at jeg slet ikke har lyst til at skifte til noget andet selv om jeg kunne.

Jeg er blevet så forvirret at jeg faktisk aldrig har været gladere for noget andet arbejde, end det jeg har nu hvor jeg arbejder med JavaScript dagen lang.

Jeg er så rundforvirret at jeg faktisk nyder de super simple løsninger jeg kan lave med JavaScript, hvor jeg før ville have rynket på næsen og sagt "Det må man da ikke".

Jeg er blevet helt forblændet af den kæmpe community og alt det Open Source der er omkring JavaScript.

Jeg er så skør, at fordi jeg ikke en eneste gang har oplevet at performance i JavaScript var et problem i praksis, så forestiller jeg mig at det er et mindre vigtigt problem.

Og jeg er så fortvivlenede vildledt, at jeg i ikke køber argumentet om at man ikke kan bygge store applikationer i JavaScript, bare fordi jeg selv har gjort det, og dem der siger at man ikke kan, enten slet ikke har prøvet det, eller ikke har struktureret deres kode ordentligt, skrevet test til den, lintet den, eller, gud forbyde det, kun brugt jQuere og intet andet rammeværk.

Jeg er så naiv at jeg faktisk tror på de folk på mit team der før kodede C# og nu kode Node.js, når de siger at de er vildt glade for det.

Og jeg er så tosset at jeg faktisk synes at det er fantastisk at vi for første gang i IT-historien har en programmeringssprog, der har runtimes på stort set alt hvad der kan kravle og gå af hardware og OS'es. Og at selve sproget er stort set 100% identisk i alle implementationer.

Og jeg formår på mærkligste vis at være imponeret over at de største IT-firmaer i verden konkurrer om at lave den hurtigste runtime til dette sprog.

Og jeg er så sindsyg at jeg tror at det er en god ting at alle skal være enige om fremtidige standarder, så vi kan fortsætte med at køre vores kode overalt.

  • 9
  • 0
Jonas Nyrup

Hvis man ser interviewet med Lars Bak og Anders Hejlsberg fra GOTO er de begge enige om, at JavaScript i sin nuværende form er grimt. TypeScript og Dart er så to forskellige forsøg på at løse samme problem.

TypeScript er en groft sagt en præprocessor til JavaScript, der tilføjer struktur og genkendelighed til koden samtidig med at en masse fejl kan fanges før runtime. Outputtet er alm. JavaScript. Det må betragtes som den nemme løsning, da man gradvist kan blande JavaScript og TypeScript i sine projekter.

Dart tilbyder også klasser og valgfrie typer og eksisterende JavaScript-koden kan også blandes med Dart http://news.dartlang.org/2012/09/use-javascript-code-in-your-dart-apps.html
Forskellen er så at Dart kører i en VM, der allerede nu kører hurtigere end deres egen V8 på nogle benchmarks. Alternativt kan det kompileres til alm. JavaScript-kode, så browsere uden Dart VM kan køre det.

De umiddelbare forskelle kan komme frem til er:
Dart kan køres i en VM, der skulle være hurtigere.
TypeScript allerede nu godt med integrerer Visual Studio.

  • 2
  • 0
Allan Ebdrup

Er det så stor en ulempe? Det virker som om mange rigtig store systemer er baseret på oversatte sprog, og jeg har selv aldrig haft problemer med at skulle køre en oversætter. Og uden en oversætter, hvornår ville du så lave typetjek?


Ja på papiret så lyder det ikke så slemt, men i praksis har jeg oplevet på store projekter, kan kompilereingstiden godt blive lang. Det er der selvfølgelig diverse løsninger på, hvor du kun kompilerer dele af koden eller lignenede. Men alt i alt indfører det kompleksitet som skal håndteres og det er ikke altid lige elegant.
Den fantastiske simple løsning der er i browseren, lader dig fx lave ting som live edit:

http://www.youtube.com/watch?v=wCVwdvufTds

Man kan selvfølgelig godt lave noget tilsvarende med TypeScript et al. Så det håber jeg at de gør. Med almindelig JavaScript virker det out-of-thebox.

  • 0
  • 0
Allan Ebdrup

Dart tilbyder også klasser og valgfrie typer og eksisterende JavaScript-koden kan også blandes med Dart http://news.dartlang.org/2012/09/use-javascript-code-in-your-dart-apps.html


Der er kæmpe forskel på at lave specille interop kald til JavaScript, og at TypeScript bare er ekstra sprog-features lagt oven på JavaScript. Darts interop ser mildest talt uelegant ud. Findes der nogen der bruger det i praksis, ræk hånden op!

Og du glemte at TypeScript ligger sig op af standardiseringsarbejdet. Du kommer aldrig til at køre Dart i nogen anden browser end Chrome. Det gør du måske med en fremtidig variant af TypeScript.

  • 0
  • 0
Anders Hessellund Jensen

TypeScript og CoffeeScript er sammenlignelige størrelser. Begge forsøger at udvide JavaScript med lidt lækrere syntax. TypeScript tilfører derudover statiske typer. Af de to tror jeg mest på TypeScript - jeg ser meget stor værdi i de statiske typer.

Dart er en helt anden størrelse. Dart VM'en er en helt ny runtime - den er mere sammenlignelig med Microsofts CLR og JVM'en. Jeg tror Google har større planer med Dart end blot at erstatte JavaScript i browseren. Dart er langt mere ambitiøst end blot at fikse JavaScript. Jeg tror Google går efter at få Dart ind i Chrome OS, i Android, i browseren og som server-side programmeringssprog til erstatning for JVM'en og Microsofts .NET.

Hvorvidt Google lykkedes med Dart eller ej er svært at spå om. Jeg tror bestemt de har en chance - ikke mindst fordi JAVA-platformen i dag ejes af Oracle, og jeg tror ikke at Oracle kan levere varen, hvilket giver plads til et andet alternativ til Microsofts .NET-platform.

Derfor er det i min verden lidt hurtigt at konkludere, at TypeScript slår dart. Jeg er enig i, at som erstatning for JavaScript, så vil jeg langt hellere kode TypeScript end jeg vil kode Dart - men jeg tror, at Googles planer med Dart er meget mere end blot en erstatning for JavaScript.

  • 5
  • 0
Allan Ebdrup

Og uden en oversætter, hvornår ville du så lave typetjek?


Typecheck er faktisk mest værdifuld for mig når jeg får feedback i mit IDE mens jeg sidder og skriver koden. Det kan Webstorm allerede i dag, hvis du bruger JSDoc til at dokumentere dine JavaScript funktioner. Man kunne vel kalde det typecheck-on-demand, i stedet for en egentligt kompilering. Og når nu kompileringen alligevel ikke foretages af performance hensyn, kan man lige så godt undvære den.

  • 0
  • 0
Allan Ebdrup
  • 0
  • 0
Jacob Nordfalk

Lige meget hvor fint MS eventuelt holder sig til standarden vil det, skulle TypeScript blive udbredt, simpelt hen være for fristende for det firma at gøre hvad de plejer: Udelukke folk der ikke bruger Windows.

Vi så det jo med .NET og MS Office-format. Selvom MS nu kan kalde dem ECMA-standarder er der ikke en kinamands chance i helvede for at folk der ikke bruger WINDOWS har nogen som helst nytte af disse, for MS har ingen reel intereesse i at lade folk vælge platform frit.

Ja, ha ha ha ha .NET er en 'standard', men er gør det at nogen at de .NET-programmer der udvikles faktisk fungerer på Linux eller Mac?? Overhovedet ikke! Og grunden? At Miguel de Icaza står stort set alene med arbejdet med at implementere støttebibliotekerne.

Jeg kan ikke sige det bedre end Miguel selv:

The majority of the Web is powered by Unix.

Developers use MacOS and Linux workstations to write the bulk of the code, and deploy to Linux servers.

But TypeScript only delivers half of the value in using a strongly typed language to Unix developers: strong typing. Intellisense, code completion and refactoring are tools that are only available to Visual Studio Professional users on Windows.

(http://tirania.org/blog/archive/2012/Oct-01.html)

Dermed må man desværre dømme TypeScript ude på forhånd fordi det er ikke nok at noget er open source og 'i teorien' virker eller at en standard 'i teorien' kan implementeres af andre. Det handler mere om, at firmaet der står bag en teknologi har nogen reel interesse i, og villig til at investere midler i, at der er en fungerende implementation og værktøjer der virker på alle platforme.

Og den interesse har MS altså bare ikke, og MS' troværdighedsniveau på det her punkt ligger naturligt nok laaaangt under under nulpunktet i forhold til alle andre.

Andre ville komme med et ordentligt plugin til platformuafhængige værktøjer som Eclipse eller Netbeans.

Jeg ved så ikke hvilken forskruet humor de har hos MS, men de har gudhjælpemig har lavet TypeScript plugins til.... vi og emacs!

Det er sku' som at forslå at man skal grave et hul med en teske!

  • 13
  • 5
Casper Bang

Jeg synes du slår et meget stort brød op, på meget lidt. Lad os se om et års tid, om ikke TypeScript bliver Microsoft's svar på GWT. Modsat Microsoft, er Google i stand til at tiltrække interesse på tværs at platforme. Der er oceaner af udviklere der flygter bare de hører ordet Microsoft, og så skal der altså mere til end blot at klistre en Apache licens på.

Det var GWT der skulle til for at Google kom frem til konklussionen om at det ikke er nok blot med en bedre syntaks, semantikken skal også forbedres. Mon ikke også Microsoft kommer på bedre tanker når de har bokset lidt rundt alene i eget ringhjørne, for det vil de unægteligt komme til.

  • 7
  • 1
Allan Ebdrup

Jeg synes du slår et meget stort brød op, på meget lidt. Lad os se om et års tid, om ikke TypeScript bliver Microsoft's svar på GWT. Modsat Microsoft, er Google i stand til at tiltrække interesse på tværs at platforme. Der er oceaner af udviklere der flygter bare de hører ordet Microsoft.


Kommunikation er en svær ting. Det jeg mener er, at jeg synes at ideen bag TypeScript allerede har slået Dart og CoffeScript fordi den bare er bedre.

Om den får success ved jeg ikke. Men du har nok ret i at der er mange der vil flygte fordi der står Miscosoft på projektet. (Som Jacob ovenover)

Personligt spår jeg hverken TypeScript, Dart eller CoffeScript nogen kæmpe fremtid, de vil fortsat være nicheprodukter fuldstændig som GWT. Jeg tror på at standardiseringsarbejdet med JavaScript er vejen frem.

Det var GWT der skulle til for at Google kom frem til konklussionen om at det ikke er nok blot med en bedre syntaks, semantikken skal også forbedres. Mon ikke også Microsoft kommer på bedre tanker når de har bokset lidt rundt alene i eget ringhjørne, for det vil de unægteligt komme til.


Jeg har meget svært ved at se ligheder mellem GWT og TypeScript.

GWT er bare helt igennem en dårlig idé, der smider alt de gode dynamiske ved JavaScript væk. Når udgangspunktet er "JavaScript er bare noget værre crap der skal gemmes så langt væk som muligt", men man stadig compiler til det, så har man allered tabt. Men GWT er heldigvis gået i glemmebogen for de fleste.

  • 3
  • 4
Peter Frandsen

Fra http://www.dartlang.org/articles/why-not-bytecode/ :

If you're writing JavaScript, your "compile step" is just refreshing the browser. Dart must be equally simple to use. We want to make development in the browser a great experience. Not only do we want to keep the fast 'edit-refresh-view' cycle that JavaScript developers love, but we also want to introduce web developers to the powerful live editing features that Smalltalk developers pioneered. Sure, you may minify or do other obfuscation when you deploy, but your core iteration loop is fast and easy because the engine for your language runs it directly from source.

You may ask, "but doesn't Dart require an explicit compile step to compile to JavaScript for running in the browser?" Well, yes, but we're talking specifically about the native Dart VM here. And we are working to make the Dart-to-JavaScript side of things as nice of a development experience as we can. Iteration time matters.

  • 3
  • 0
Allan Ebdrup

Ja det vil virke i Chrome. Men du faar dit compile step naar du vil checke i alle andre browsere. Processen skulle helst virke i alle browsere.
Men super godt at de taenker paa det. Jeg vil haabe for dem der skal bruge det, at TypeScript faar noget tilsvarende.
Man burde kunne lave noget intelligent, der virker naar man udvikler, selvom der er et compilestep

  • 0
  • 0
Torben Mogensen Blogger

Ja på papiret så lyder det ikke så slemt, men i praksis har jeg oplevet på store projekter, kan kompilereingstiden godt blive lang.

Tiden brugt til oversættelse bør ikke være væsentligt længere end den tid, der bliver brugt til indlæsning af koden. Specielt ikke, hvis koden hentes over Internettet. Hvis oversættelsestid er en begrænsning, så har du enten en dårlig oversætter eller et dårligt system til håndtering af genoversættelse af moduler, sådan at du skal genoversætte det hele, hver gang et enkelt modul ændres.

Hvis du slår den højeste grad af optimering til, kan oversættelsen tage længere tid end indlæsning, men det bør man ikke gøre undtagen i de sidste faser af udviklingen. Og den ekstra tid bliver brugt på noget, du ikke får i fortolkede systemer: Optimering.

  • 8
  • 0
Log ind eller Opret konto for at kommentere
IT Company Rank
maximize minimize