Hvornår skal jeg bruge TypeScript?

Sidste sommer måtte vi konvertere en enorm kodebase (18.000+ linjer med kode) fra JavaScript til TypeScript. Jeg lærte meget om styrker og svagheder ved hver, og når det giver mening at bruge den ene over den anden.

Denne artikel er nu tilgængelig på japansk og kinesisk.

Når det giver mening at bruge TypeScript

Når du har en stor codebase

Når din codebase er enorm, og mere end en person arbejder på projektet, kan et typesystem hjælpe dig med at undgå mange almindelige fejl. Dette gælder især for applikationer med en side.

Hver gang en udvikler kan indføre brudende ændringer, er det generelt godt at have en slags sikkerhedsmekanisme.

TypeScript-transpilleren afslører de mest åbenlyse fejl - selvom det ikke magisk fjerner behovet for fejlretning.

Hvis din codebase ikke er så stor, giver det sandsynligvis ikke mening at gøre den større ved at tilføje typebetegnelser. Jeg har konverteret 180+ filer fra JavaScript til TypeScript, og i de fleste tilfælde tilføjede det ca. 30% til den samlede kodestørrelse.

Når dit teams udviklere allerede er vant til statisk typede sprog

Hvis du eller størstedelen af ​​teamet kommer fra et stærkt skrevet sprog som C # eller Java, og ikke ønsker at gå all-in på JavaScript, er TypeScript et godt alternativ.

Selvom jeg anbefaler at lære Javascript grundigt, er der intet, der forhindrer dig i at bruge TypeScript uden at kende JavaScript. Faktisk blev TypeScript oprettet af den samme fyr, der lavede C #, så syntaksen er ens.

I mit firma havde vi et team af C # -udviklere, der kodede et sofistikeret desktop-program i C # og WPF (som dybest set er et frontend-udviklingsværktøj til desktop-verdenen). De blev derefter bedt om at deltage i et webprojekt som full stack-udviklere. Så i kort rækkefølge var de i stand til at lære TypeScript til frontend og derefter udnytte deres C #-viden til backend.

TypeScript kan fungere som erstatning for Babel

Det gamle Microsoft plejede at tage standardværktøjer - for eksempel Java - og tilføje proprietære ikke-standardfunktioner til dem - i dette tilfælde resulterede det i J ++. Derefter forsøgte de at tvinge udviklere til at vælge mellem de to.

TypeScript er nøjagtig den samme tilgang - denne gang for JavaScript. Forresten er dette ikke Microsofts første fork af JavaScript. I 1996 gaffede de JavaScript for at oprette JScript.

Selvom det er en mindre almindelig brugssag, er det teknisk muligt at transpilere ES6-kode til ES5 ved hjælp af TypeScript-trans Player. Dette er muligt, fordi ES6 i det væsentlige er et undersæt af TypeScript, og TypeScript-transpilleren genererer ES5-kode.

Typescript's transpiller genererer ret læsbar Javascript (EcmaScript 5) kode som output. Det var en af ​​grundene til, at Angular 2-teamet valgte TypeScript frem for Googles eget Dart-sprog.

TypeScript har også nogle seje funktioner, der ikke er i ES6, som enums og muligheden for at initialisere medlemsvariabler i en konstruktør. Jeg er ikke en stor fan af arv, men jeg finder det nyttigt at have de offentlige, private, beskyttede og abstrakte nøgleord i klasser. TypeScript har dem, og ES6 ikke.

Vores C # -udviklere syntes, det var super forbløffende at kunne skrive en lambda-funktion som kroppen til en metode - hvilket eliminerede hovedpine forbundet med dette nøgleord.

Når et bibliotek eller en framework anbefaler TypeScript

Hvis du bruger Angular 2 eller et andet bibliotek, der anbefaler TypeScript, skal du vælge det. Se på, hvad disse udviklere har at sige efter at have brugt Angular 2 i seks måneder.

Bare ved, at - selvom TypeScript kan bruge alle JavaScript-biblioteker ud af boksen - hvis du vil have gode syntaksfejl, skal du tilføje typedefinitionerne for disse biblioteker eksternt. Heldigvis har de pæne fyre hos DefinitelyTyped bygget en community-driven repo med værktøj til netop det. Men dette er stadig et ekstra trin, når du opretter dit projekt

(På en sidebemærkning: Tjek TSX for alle jSX-fans.)

Når du virkelig føler behov for hastighed

Dette kan komme som et chok for dig, men TypeScript-koden kan i nogle situationer fungere bedre end JavaScript. Lad mig forklare.

I vores JavaScript-kode havde vi mange typer kontrol. Det var en MedTech-app, så selv en lille fejl kunne bogstaveligt talt være fatal, hvis den ikke blev behandlet ordentligt. Så mange funktioner havde udsagn som:

if(typeof name !== ‘string) throw ‘Name should be string’

Med TypeScript kunne vi fjerne mange af disse typekontrol alt sammen.

Dette viste især sin virkning i dele af koden, hvor vi tidligere havde en præstationsflaskehals, fordi vi var i stand til at springe over en masse unødvendig kontrol af runtime-typen.

Så hvornår har du det bedre uden Typescript?

Når du ikke har råd til en ekstra transportskat

Der er ingen planer om at understøtte TypeScript indbygget i browserne. Chrome gjorde nogle eksperimenter, men senere annullerede support. Jeg formoder, at dette har noget at gøre med unødvendige runtime-omkostninger.

Hvis nogen vil have træningshjul, kan de installere dem. Men cykler bør ikke komme med permanente træningshjul. Dette betyder, at du altid bliver nødt til at transpilere din TypeScript-kode, før du kører den i en browser.

For standard ES6 er det en helt anden historie. Når ES6 understøttes af de fleste browsere, bliver den aktuelle transponering af ES6 til ES5 unødvendig (opdatering: ja faktisk!).

ES6 er den største ændring af JavaScript-sproget, og jeg tror, ​​at de fleste programmører bare vil nøjes med det. Men de modige få, der ønsker at prøve den næste version af JavaScript's eksperimentelle funktioner eller de funktioner, der endnu ikke er implementeret i alle browsere - de bliver nødt til at transpilere alligevel.

Uden transpilation ændrer du bare filen og opdaterer din browser. Det er det. Ingen overvågning, transpilering efter behov eller byggesystem er nødvendig.

Hvis du vælger TypeScript, vil du ende med at foretage ekstra bogføring for typedefinitionerne til dine Javascript-biblioteker og -rammer (ved at bruge DefinitelyTyped eller skrive dine egne typekommentarer). Det er noget, du ikke behøver at gøre for et rent JavaScript-projekt.

Når du vil undgå underlige fejlsøgningssager

Sourcemaps gør det lettere at debugge Typescript, men status quo er ikke perfekt. Der er virkelig irriterende og forvirrende kantsager.

Der er også nogle problemer med fejlfinding af "dette" nøgleord og egenskaber, der er knyttet til det (tip: "_ dette fungerer i de fleste tilfælde). Det skyldes, at Sourcemaps i øjeblikket ikke har en god understøttelse af variabler - selvom dette kan ændre sig i fremtiden.

Når du vil undgå potentielle sanktioner

I vores projekt havde vi mere end 9.000 linjer med god gammel ES5 JavaScript, der leverede ren hestekraft til et 3D WebGL-lærred. Vi holdt det sådan.

TypeScript-transpilleren (ligesom Babel) har funktioner, der kræver generering af ekstra kode (arv, enum, generiske, async / afventer osv.). Uanset hvor god din transpiller er, kan den ikke overgå optimeringerne for en god programmør. Så vi besluttede at holde det i almindelig ES5 for at gøre det nemmere at debugge og implementere (ingen overførsel overhovedet).

Når det er sagt, er præstationsstraffen sandsynligvis ubetydelig sammenlignet med fordelene ved et typesystem og mere moderne syntaks for de fleste projekter. Men der er tilfælde, hvor millisekunder og endda mikrosekunder betyder noget, og i disse tilfælde anbefales ikke transpilering af nogen art (selv med Babel, CoffeeScript, Dart osv.).

Bemærk, at Typescript ikke tilføjer nogen ekstra kode til runtime-typekontrol. Al typekontrol sker på transpileringstidspunktet, og typekommentarerne fjernes fra den genererede Javascript-kode.

Når du vil maksimere dit teams agility

Det er hurtigere at oprette noget i JavaScript. Manglen på et typesystem giver mulighed for smidighed og let at skifte ting. Det gør det også lettere at bryde ting, så sørg for at vide, hvad du laver.

Javascript er mere fleksibelt. Husk, at et af de vigtigste anvendelsestilfælde for et typesystem er at gøre det svært at bryde ting. Hvis Typescript er Windows, er Javascript Linux.

I JavaScript Land får du ikke træningshjulene til et typesystem, og computeren antager, at du ved hvad du laver, men giver dig mulighed for at køre meget hurtigere og manøvrere lettere.

Dette er især vigtigt at bemærke, hvis du stadig er i prototypefasen. I så fald spild ikke din tid med TypeScript. JavaScript er så meget mere fleksibelt.

Husk, at TypeScript er et supersæt af JavaScript. Dette betyder, at du nemt kan konvertere JavaScript til TypeScript senere, hvis du har brug for det.

Min præference på JavaScript VS TypeScript

Der er generelt ikke et bedste sprog. Men for hvert enkelt projekt er der sandsynligvis et objektivt bedste sprog og bibliotek og ramme og database og operativsystem, og ... du får billedet.

For vores projekt var det fornuftigt at bruge TypeScript. Jeg forsøgte at refakte nogle af mine hobbyprojekter til TypeScript, men det var ikke besværet værd.

Jeg kan personligt lide 5things om TypeScript:

  1. Det er fuldt kompatibelt med ES6. Det er virkelig rart at se Microsoft spille fair med de andre browsere. Vores økosystem kan drage fordel af en stærk rival til Google, Mozilla og Apple. Microsoft bruger seriøs energi på det - såsom at skrive Visual Studio-kode fra bunden ved hjælp af TypeScript på Google Chrome på alle platforme.
  2. Typesystemet er valgfrit. Kommer fra en C- og Java-baggrund, fandt jeg manglen på typesystem i JavaScript befriende. Men jeg hadede at miste tid, da jeg stødte på dumme bugs i løbet af løbetiden. TypeScript giver mig mulighed for at undgå mange almindelige fejl, så jeg kan fokusere min tid på at rette de virkelige vanskelige. Det er en god balance. Jeg kan lide det. Det er min smag. Jeg bruger typer, når jeg kan, fordi det giver mig ro i sindet. Men det er mig. Hvis jeg bruger TypeScript, vil jeg ikke begrænse mig til dets ES6-funktioner.
  3. JavaScript-koden, der kommer ud af TypeScript-spiller, er meget læselig. Jeg er ikke fan af Sourcemaps, så jeg foretager det meste af min fejlretning på det genererede JavaScript. Det er helt fantastisk. Jeg kan helt forstå, hvorfor Angular 2 valgte TypeScript frem for Dart.
  4. TypeScript's udviklingserfaring er fantastisk. VS-kode er meget smart, når man beskæftiger sig med JavaScript (nogle kan hævde, at det er den smarteste JS IDE). Men TypeScript skubber grænserne til et helt nyt niveau. Autofuldførelses- og refactoring-funktionerne i VSCode fungerer meget mere præcist, og det er ikke fordi IDE er super smart. Det er alt takket være TypeScript.
  5. Typebemærkningerne er som en grundlæggende dokumentation. De erklærer den type data, som hver funktion forventer, deres resultater og forskellige andre hints kan lide readonly, publiceller privateattributter. Efter min erfaring, forsøger jeg at omlægge en JavaScript-kode til TypeScript, ender jeg normalt med renere kode med pænere struktur. Faktisk har skrivning af TypeScript forbedret, hvordan jeg skriver almindelig JavaScript.

Typescript er ikke svaret på alt. Du kan stadig skrive frygtelig kode i den.

TypeScript-hadere vil hade enten på grund af frygt for forandring eller fordi de kender nogen, der kender nogen, der er bange for det. Livet fortsætter, og TypeScript introducerer alligevel nye funktioner til samfundet.

Men ligesom React er TypeScript en af ​​de indflydelsesrige teknologier, der skubber grænserne for vores webudvikling.

Uanset om du bruger TypeScript eller ej, skader det ikke at prøve det for at udvikle dine egne meninger om det. Det har en indlæringskurve, men hvis du allerede kender JavaScript, vil det være glat.

Her er en online real-time TS-spiller med nogle eksempler, der giver dig mulighed for at sammenligne TypeScript-kode med den tilsvarende JavaScript-kode.

Her er en hurtig vejledning og en meget flot guide, men jeg er mere en slags sprogreference. Hvis du kan lide video, her er et kursus fra Udemy.

John Papa har en kort artikel om ES5 og TypeScript.

Der er en interessant undersøgelse, der viser alt lige, et typesystem reducerer fejl med 15%.

Åh, og hvis du har lyst til at gå på en sidemission, så læs hvorfor programmering er det bedste job nogensinde.