Derfor skal du bruge Typescript

Illustration: Version2
Typescript har succes, hvor andre Javascript-overbygninger har fejlet. Det handler om at gå med på det underliggende sprogs præmisser og gøre programmørerne mere produktive, mener amerikansk udvikler.

De fleste sprog, som kan kompileres eller ‘transpiles’, som det også kaldes, til Javascript, har ikke haft meget succes. Hvem taler længere om Google Web Toolkit, Coffeescript og Dart?

Men sådan er det ikke med Typescript, et sprog, der debuterede på scenen i lille Danmark, og som nationens stolthed, Microsofts sprogdesigner Anders Hejlsberg, har sat sit fingeraftryk på.

TJ VanToll fra firmaet Nativescript var skeptisk overfor Typescript, da sproget kom til verden. Men den skepsis er nu forvandlet til begejstring, fortæller han veloplagt overfor publikum på Goto-konferencen, der i denne uge løber af stablen i København.

Både Typescript og Dart debuterede på tidligere Goto-konferencer, så det er altså et passende forum at tage snakken i.

TJ VanToll fra firmaet Nativescript har en god forklaring på, hvorfor Typescript sejrede, hvor andre sprog måtte give fortabt. Han gav et indlæg på Goto-konferencen i denne uge. Illus.: TJ VanToll

TJ VanToll gør ærligt og redeligt opmærksom på, at han er ‘evangelist’ for Nativescript, et firma, der har et tæt forhold til Typescript. Den stilling handler også om markedsføring, så helt uhildet er han altså ikke.

Men han har tre gode bud på, hvorfor Typescript har sejlet konkurrenterne agterud.

Og at det rent faktisk er sket, viser han med grafer fra Googles tendens-tjeneste, der giver ham ret, i en overbevisende grad.

Typescript er gået støt frem, mens konkurrenterne spiser støv.

Alle hader Javascript

Men hvorfor overhovedet skifte Javascript ud med noget andet?

Javascript er hadet af de fleste udviklere, mener TJ VanToll. De ‘gode’ elementer i sproget fylder meget lidt, i forhold til helheden, lyder synspunktet.

Næsten alle moderne sprog er prøvet oversat til Javascript i en eller anden grad, og store virksomheder har brugt anseelige summer i forsøgene.

Coffeescript og Dart oplevede en vis popularitet tilbage i 2012, men siden gik det ned af bakke. TJ VanToll synes, at det første sprog minder for meget om Ruby, og at det er det, der begrænsede webudviklernes interesse. Dart, som stammer fra Google, er ligesom Typescript også af dansk herkomst. Det minder en del om sprog som Java og C#.

I den første udgave af Dart blev et simpelt Hej Verden-eksempel kompileret til astronomiske 17.000 linjers Javascript. Selvom det gik bedre med senere optimeringer, blev indtrykket hængende.

Dertil kom, at datiden opfattede situationen som om, at Google ville benytte sin dominerende position med Chrome til at favorisere sit eget sprog via en speciel virtuel maskine til Dart - noget, som mindede om Microsofts taktik med Internet Explorer i tidligere tider.

Dart slog ikke an hos webudviklerne. I stedet har det fundet en rolle i Googles mobiludviklingsmiljø Flutter.

Læs også: Her kommer Flutter - Googles nye mobil-system fra Aarhus

Også i 2012 skrev TJ VanToll et blogindlæg, hvor han jordede Typescript. ‘Javascript skal være rent, som Gud ønskede det,’ lød den sjove formulering.

Derfor skal du bruge Typescript

TJ VanTolls firma havde netop valgt Typescript som platform til dets open source mobiludviklingsmiljø, der kan afvikles på begge de to store platforme.

»Vi risikerer en masse ved at bygge vores kerne oven på Typescript,« var hans daværende vurdering over for firmaet.

Men det var klokkeklart forkert, lyder tilståelsen.

Der var flere grunde til at Typescript fik luft under vingerne. Biblioteket Angular 2 gav sproget vind i ryggen, da det valgte at bygge på Typescript i 2015. Microsoft udsendte open source-værktøjet Visual Studio Code, som er gratis og platformsuafhængigt, og kommer med god understøttelse af Typescript.

Det populære chatsystem Slack bygger nu på Typescript, og biblioteket Vue.js vil også skifte. Et andet populært bibliotek, React.js, understøtter også sproget.

Men hvorfor tog TJ VanToll fejl tilbage i 2012? Han peger på tre årsager:

Typescript bygger oven på Javascript, i stedet for at erstatte det, og sprogets bagmænd er gået med i komiteen, der udvikler Javascript.

Den næste grund er typer. De er valgfrie og det nedsætter indlæringskurven. Udviklere med Javascript-baggrund er sjældent glade for typer, og det samme gælder dem, som er blevet skræmt af f.eks. tidligere Javas tunge type-system.

Den sidste årsag er værktøjer, som eksempelvis Visual Studio Code og web-IDE’et Typescript Playground, der ved hjælp af typeinferens kan ‘autocomplete’ koden og browse funktioner i store biblioteker som Jquery, med nem adgang til dokumentation, som det kendes fra typestærke sprog og tunge IDE'er.

Webassembly er mest til spil

Man skal bruge Typescript, hvis man har store kodebaser og arbejder sammen med et udviklerhold, mener TJ VanToll. Og hvis det er svært at rekruttere frontend-udviklere, kan backend-folk med erfaring i Java eller C# snildt finde sig hjemme i Typescript.

På Version2's spørgsmål, om ikke Webassembly-teknologien kommer til at fjerne behovet for ‘transpiling’, svaret TJ VanToll:

»Jeg har hørt tale om Webassembly i årevis og jeg har endnu ikke set en praktisk situation, hvor det bliver anvendt. Det kommer nok til at spille en større rolle i forbindelse med f.eks. spil, hvor ydelse er kritisk, men til de fleste forretningsapplikationer er Javascripts ydelse ikke et problem. Det er vigtigere at være produktiv, og Typescript gør netop det. De fleste udviklere vil godt give køb på lidt ydelse, hvis det betyder, at de kan få tingene gjort lidt hurtigere.«

Læs også: Webassembly kan blive webbets næste revolution og sætte Javascript på porten

Tips og korrekturforslag til denne historie sendes til tip@version2.dk
Følg forløbet
Kommentarer (31)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Allan Ebdrup

Jeg har lavet et eneste blogindlæg her på version2 med en profeti i titlen, og så viser det sig at være rigtigt ramt.
I må på forhånd undskylde selvfedmen, jeg bliver nød til at fremhæve mit eget blogindlæg her på version2 fra 2012 med titlen "TypeScript slår Dart og CoffeScript"

https://www.version2.dk/blog/typescript-slaar-dart-og-coffescript-48409

Typescripts grundidé med at "spille sammen" med JavaScript er stadig bare bedre end de andre bud.

  • 17
  • 1
Christoffer Thomsen

Dart slog ikke an hos webudviklerne, og sproget kan ikke længere kompileres til Javascript.

Det er ikke sandt; Dart har stadig en JavaScript-oversætter, og Dart anvendes stadig til udvikling af webapplikationer – på samme måde som TypeScript – ved at oversætte Dart til JavaScript. Til gengæld droppede Google for flere år siden planerne om at inkludere en Dart-fortolker i Chrome.

  • 2
  • 0
Magnus Jørgensen

Jeg har nu ikke så meget imod javascript.
Det kan være svært at gennemskue context, men det kan løses ved at organisere koden.

Jeg har lidt svært ved at se hvad typescript gør som webassembly ikke kan løse bedre.

https://webassembly.org/

Typescript virker lidt som en B løsning i forhold til webassembly. Hvem ville ikke hellere programmere i C# end typescript?

  • 3
  • 1
Rene Madsen

Typescript virker lidt som en B løsning i forhold til webassembly. Hvem ville ikke hellere programmere i C# end typescript?

Jeg vil langt hellere kode i TypeScript end C#. Men det er jo en smagssag og hvilken baggrund man kommer med og hvilken opgave man skal løse.

Så handler det vel også langt hen af vejen om, hvad er der mest tilslutning til på nettet i forhold til fremtidsudsigter for den applikation man er i gang med at skrive.

  • 2
  • 0
Palle Simonsen

Her er en artikel der sandsynliggør, at et avanceret typesystem ikke garanterer fejlfire programmer - snarere tværtimod:

https://medium.com/javascript-scene/the-shocking-secret-about-static-typ...

Personlig foretrækker jeg enkeltheden og det noget lavere antal kodelinjer i Javascript end den meget gluecode jeg kan se jeg skal bruge i kombinationen Typescript+Angular

  • 4
  • 2
Jonas Høgh

Her er en artikel der sandsynliggør, at et avanceret typesystem ikke garanterer fejlfire programmer - snarere tværtimod:

https://medium.com/javascript-scene/the-shocking-secret-about-static-typ...


Jeg har svært ved at tro på at man kan få noget pålideligt resultat ud af github-søgninger. Det er ikke engang defineret hvad der menes med metrikken "bug density", som samtlige konklusioner baseres på.

  • 1
  • 3
Rene Madsen

Interessant. Hvorfor ville du foretrække Typescript frem for C#?

Da jeg bruger TypeScript i sammenhæng med Angular, så jeg kan jeg debugge/rette koden imens resultatet er i browseren on the fly.
Med en baggrund fra primært web, så er det for tung en oplevelse at skrive C# og skulle kompile og så se resultatet, frem for on the fly.

Det er blot min oplevelse og det kan være blevet meget bedre.

  • 4
  • 0
Palle Simonsen

Det er ikke engang defineret hvad der menes med metrikken "bug density", som samtlige konklusioner baseres på.

https://www.zyxware.com/articles/4134/how-to-calculate-the-defect-densit...

Mao der er i følge data fra artiklen ca. 5 gange så mange fejl i et gennemsnitligt Java program som i et gennemsnitlig Clojure program.

Java er et populært kompileret proceduralt objektorienteret sprog med et kompliceret typesystem, komplekse frameworks og anvendt af relativ mange 'commodity programmers' hvor Clojure, der reelt er LISP, er et dynamisk, funktionelt sprog med dynamiske typer, der anvendes af betydelig færre, men mere specialiserede udviklere. Begge anvender JVM runtime.

En del af principperne i Javascript minder om principper i LISP. Typescript tilfører Javascript en del syntakssukker bl.a. lånt fra Java.

  • 3
  • 0
Jonas Høgh

Hvordan ved du at den definition også er den, der er brugt i "studiet"? Og er det en god måde at måle det på, fx hvis Java-programmer skal bruge 10 gange flere linier på at implementere samme funktionalitet som tilsvarende Clojure-programmer? Selv hvis vi antager at vi har et rimeligt mål for kvaliteten af et program, giver det så mening at tilskrive forskellen på kvaliteten mellem Java og Clojure alene til statiske kontra dynamiske typer, når der er så mange andre fundamentale forskelle mellem de to sprog?

Dette skal i øvrigt ikke ses som et forsvar for Java, jeg ville også langt hellere bruge Clojure.

  • 3
  • 0
Palle Simonsen

Hvordan ved du at den definition også er den, der er brugt i "studiet"?

Et gæt :)

Og er det en god måde at måle det på, fx hvis Java-programmer skal bruge 10 gange flere linier på at implementere samme funktionalitet som tilsvarende Clojure-programmer?

Hvis det nu er 5 gange så meget kode passer pengene. Så har man her et udtryk for en af omkostningerne ved at bruge et programmeringssprog der kræver flere linjer per. Functionpoint, Usecasepoint, Storypoint eller hvad.

Men man skal altid være forsigtig med analogierne - Clojure f.eks. er pænere og mere tilgivende end Javascript, der rummer en række fælder såsom hvornår man skal bruge '==' eller '===' sammenligning

  • 1
  • 0
Jonas Høgh

Hvis det nu er 5 gange så meget kode passer pengene. Så har man her et udtryk for en af omkostningerne ved at bruge et programmeringssprog der kræver flere linjer per. Functionpoint, Usecasepoint, Storypoint eller hvad.


Hvis jeg har et Java-program på 500 linier, med 0,1 fejl per linie, og et tilsvarende Clojure-program på 100 linier, med 0,02 fejl per linie, så er der 50 fejl i Java-programmet, og 2 fejl i Clojure-programmet, så det gør faktisk forskellen endnu større i Clojures favør.

Men hvis jeg læser kommentarerne på https://labs.ig.com/static-typing-promise synes jeg det antydes ret kraftigt at metrikken IKKE er normaliseret per kodelinie. Og så ved vi i virkeligheden ikke ret meget, indtil vi som minimum finder en måde at måle den gennemsnitlige kompleksitet for et github repository i det pågældende sprog.

  • 3
  • 0
Sune Marcher

Hvis det nu er 5 gange så meget kode passer pengene. Så har man her et udtryk for en af omkostningerne ved at bruge et programmeringssprog der kræver flere linjer per. Functionpoint, Usecasepoint, Storypoint eller hvad.


Men har man nu også reelt set det? Eller har man i virkeligheden bevist at højt specialiserede udviklere er dygtigere til at skrive kode? :-)

Java er et ret udbredt sprog, ikke mindst til elendige enterprise løsninger der er outsourced til de billigst mulige klamphuggere...

  • 8
  • 1
Magnus Jørgensen

Da jeg bruger TypeScript i sammenhæng med Angular, så jeg kan jeg debugge/rette koden imens resultatet er i browseren on the fly.

Ja, det er rigtigt.
Så hvis der kom værktøjer til debugging af C# kode i browseren ville det være bedre?
Webassembly er trods alt ret nyt, så mange af disse ting er stadigvæk eksperimentielle og umodne.
Min pointe er bare at alle disse transpilere til Javascript er dårlige løsninger som webassembly løser bedre. Jeg kan nemt sætte mig ind i hvorfor nogle ikke kan lide Javascripts format, så jeg kan også forstå hvorfor Typescript er blevet populært. Men jeg må indrømme at jeg ikke kan se pointen hvis webassembly bliver bliver populært og understøttet i alle browsere.

  • 0
  • 0
Jonas Høgh

Min pointe er bare at alle disse transpilere til Javascript er dårlige løsninger som webassembly løser bedre. Jeg kan nemt sætte mig ind i hvorfor nogle ikke kan lide Javascripts format, så jeg kan også forstå hvorfor Typescript er blevet populært. Men jeg må indrømme at jeg ikke kan se pointen hvis webassembly bliver bliver populært og understøttet i alle browsere.


Helt sikkert, men det kan jo ikke stå alene. Hvis det skal blive en god oplevelse at oversætte sprog X til webassembly, skal økosystemet også være stort nok til at der findes biblioteker til at tale med browserens APIer, som minder om måden man ville gøre det i sprog X. Så vidt jeg ved er webassembly p.t. endnu ikke designet til sprog med garbage collection, så jeg tror ikke Blazor bliver produktionsklar lige med det første. Og jeg tvivler på at webassembly kommer til at overtage verden alene fordi folk vil elske at skrive deres webapps i C++ eller Rust.

  • 0
  • 0
Sune Marcher

Min pointe er bare at alle disse transpilere til Javascript er dårlige løsninger som webassembly løser bedre.


Gør det nu også det?

Med WebAssembly får du en fixed chunk hukommelse, og kan ikke direkte manipulere DOM'en - så den slags skal løses med noget message passing til JavaScript.

WebAssembly virker interessant til visse typer af opgaver, men jeg er ikke sikker på at det er bedste match til hovedparten af logikken i en webapp.

  • 2
  • 1
Henrik Hansen
  1. Derfor kommer din næste smartphone til at køre Windows Phone
  2. Derfor er Silverlight fremtidens interaktive streaming-platform
  3. Derfor vil XPS-dokumenter snart udkonkurerre PDF-formatet
  4. Derfor skal du bygge din næste virksomhed på Windows Small Business Server
  5. Derfor vil Microsoft InfoPath altid være en integreret del af Officepakken
  6. Derfor er Windows CE fremtidens embedded OS
  7. Derfor er Orchard fremtidens open source CMS
  8. Derfor er MSN Messenger verdens bedste Messaging App.
  9. Derfor er dine kritiske forretningsdata sikret i Access/Jet
  10. Derfor er der Windows Home Server på din næste NAS
  11. Derfor er Zune og WMA-formatet fremtidens musikplatform
  12. Derfor skal dit næste website skrives i Word
  13. Derfor skal dit næste website udvikles i Microsoft Frontpage
  14. Derfor skal dit næste website udvikles med Expression Web
  15. Derfor skal dit næste website udvikles med WebMatrix
  16. Derfor kommer Groove streaming service til at udfordre Spotify
  17. Derfor vil The Microsoft Network erstatte Internettet
  18. Derfor er IronRuby fremtidens open source Rails-platform
  19. Derfor er Visual Studio Team Rooms det bedste samarbejds-værktøj for dine udviklere.
  20. Derfor er Microsoft Bob din nye personlige assistent
  21. Derfor er Sharepoint-udviklere de lykkeligste i verden
  22. Derfor er Atlas fremtidens web-framework for web-applikationer
  23. Derfor er Visual Source Safe det bedste VCS på markedet
  24. Derfor bliver Yammer den næste folkekære sociale medie
  25. Derfor kommer Bing til at give Google kamp til stregen
  • 3
  • 7
Magnus Jørgensen
  • 0
  • 0
Rasmus Schultz

Jeg elsker TypeScript, så misforstå mig nu ikke, men...

Der er ét kæmpe problem med TypeScript: det er JavaScript.

Problemet er, at TypeScript bare vokser og vokser - der er ingen grænse for, hvad man kan (eller bliver nødt til at) opfinde af nye, farverige type-koncepter, for at understøtte alle de sindssyge ting, man kan slippe afsted med i JavaScript.

Type-systemet i TypeScript er imponerende - men omvendt, lad os være ærlige: der var ingen ved deres fulde fem, der ville sidde og opfinde så kompliceret et type-system, hvis de skulle designe et fra bunden af.

TypeScript lider således temmelig hårdt af "symptomatisk design" - altså er man reaktiv, og forsøger at understøtte de mønstre, der bruges i JavaScript, så det kan type-hintes.

Og det er på den ene side fremragende - eftersom vi ikke umiddelbart har nogen udsigt til, at kunne slippe af med JavaScript.

Men det er på den anden side set et plaster på såret. Det fører ikke til et egentligt nyt sprog - blot til en stor og indviklet (for mange desideret overvældende) løsning på krav som JavaScript ikke tilfredsstiller.

Jeg har således meget håb for WebAssembly som en platform der kan bane vejen for et bredere udvalg af sprog i fremtiden - sprog som er designet fra bunden af, efter en linie hvor man stiler efter et simplere og mere elegant sprog.

  • 3
  • 0
Tania Andersen Editor

Hej Henrik - det er god humor - du får en thumbs up fra mig (journalisten, der har skrevet denne artikel) :-)

Jeg kender en journalist, der i sin tid skrev nr. 3 på din liste. Så din implicitte kritik er ikke forkert, som jeg ser det.

I forb. med denne artikel er det kilden, TJ VanToll, som kommer med den dom, som overskriften afspejler. Det er altså ikke V2 eller mig som journalist, der har det synspunkt, der fremføres.

Men jeg ser også en kritik af 'dovne' overskrifter i dit indlæg. Og den kritik er berettiget og giver stof til eftertanke, mener jeg. Tak for dit indlæg.

Mvh Tania/V2

  • 1
  • 0
Kim Johannsen

Det kommer nok til at spille en større rolle i forbindelse med f.eks. spil, hvor ydelse er kritisk, men til de fleste forretningsapplikationer er Javascripts ydelse ikke et problem

Det er netop denne indstilling jeg er så træt af. Utallige simple apps på fx. mit nyere Samsung smart-TV derhjemme har slemme framerate issues, tager mere end 20 sekunder at starte op og reaktionstiden er ofte mere end 1-2 sekunder, til trods for at der sidder en moderne ARM-cpu i TV'et. Det eneste disse apps skal gøre er at vise nogle billeder som previews af udsendelser og derudover vise en video stream. Man kan ikke konstant afhænge af Moore's lov og forvente at hardware bliver hurtigere. Og hvis den gør hjælper det ofte ikke, for det gør at flere udviklere bruger den bedre hardware som undskyldning for at skrive dårligere optimeret software.

Det er de færreste udviklere i min hverdag der ved hvad cache-misses er, hvad bekostningen af .ToList() i C# fx har på garbage collectoren og at man i en accessor/getter i fx JavaScript aldrig skal konstruere arrays og objekter hver gang, til trods for det ofte er de mest typiske syndere jeg ser i daglig kode. Forstå din CPU, kend din GC, så er du allerede nået langt.

Jeg kan finde utallige eksempler på at det ikke kun på daglig basis er spil der afhænger af optimeret software. Fx mobile enheder er et godt eksempel. Her har overflødig CPU-beregninger konsekvensen af at brugerens mobil holder mindre på strømmen, hvilket igen er et stort problem med mange telefoner idag.

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