Introduktion til typesikkerhed til dit JavaScript-projekt? Tænk igen

Vi introducerer typesikkerhed til dit JavaScript-projekt? Tænk igen

Opdatering - 1. februar 2017

Jeg har hørt forskellige modargumenter vedrørende typesikkerhed i JavaScript, siden jeg først offentliggjorde denne artikel, og selvom jeg stadig mener, at mange projekter ikke kræver brug af et maskinskrevet JavaScript-supersæt, indrømmer jeg, at jeg var for hurtig til at offentliggøre dette artikel. Nogle passende brugssager har efterfølgende fanget min opmærksomhed:

  • Glimmer, den lave gengivelsesmotor bag Ember, er skrevet i TypeScript for at promovere monomorfe opkaldssider, hvilket hjælper ydeevnen, når den udføres af V8 og potentielt andre JavaScript-motorer
  • Visual Studio Code drager fordel af TypeScript på grund af projektets store størrelse; i betragtning af at det distribueres som en desktopapplikation, er det efter min mening en fornuftig mulighed at have en codebase i stedet for at afstemme individuelle pakker ved byggetid
  • Sect (ganske vist et eget projekt, så der er potentiel bias her!) Er skrevet i TypeScript, så forbrugerne kan skrive store, modulære spil til internettet, samtidig med at de pålideligt reducerer runtime-fejl som skyldes stavefejl og andre problemer, der opstår som et resultat af JavaScript dynamisk natur

Jeg har desuden indset, at skrivning af mindre biblioteker i TypeScript og udgivelse af dem med de typedefinitioner, der genereres ved byggetid, samtidig muliggør deres problemfri integration med typede og traditionelle JavaScript-projekter, hvilket giver udviklere et bredere teknologisk valg.

Ikke desto mindre er der for eftertiden skyld den originale artikel i sin helhed.

I dag stødte jeg på en artikel om lanceringen af ​​JS ++, der hævder at "rette JavaScript's manglende typesikkerhed." Sjovt nok har vi allerede TypeScript, ST-JS og Scala.js, som hjælper udviklere med i sidste ende at nå det samme mål.

Inden jeg starter i denne tirade, tillad mig at fremhæve tre vigtige punkter:

  • Jeg har tidligere skrevet en tutorial om oprettelse af et simpelt TypeScript-projekt. Jeg ser hykleriet, men mine meninger er ændret, siden jeg offentliggjorde det for over et år siden
  • Stærk typing og statisk typing er vitale paradigmer. Førstnævnte giver gennemsigtighed over de enheder, der er repræsenteret i ens kode, deres forhold og den funktionalitet, de kan forventes at levere, mens sidstnævnte er et vigtigt kompileringstidsnet i komplekse systemer. Jeg kommer fra en C # baggrund, så jeg har førstehånds erfaring med dette
  • Jeg elsker også JavaScript på grund af dets iboende fejl, hvoraf mange er blevet behandlet med ECMAScript 6 og 7

Så hvorfor er jeg generelt imod statisk skrivning i JavaScript?

Overvejende hvad der gør JavaScript til et så stærkt sprog er dens svagt typede natur; det er trivielt at implementere grene af logik via typen tvang, og det er så let at oprette objektforekomster af en vilkårlig type. Desuden gør manglen på kompilering (medmindre man bruger et transpiller eller build-værktøj som f.eks. Babel) udvikling utrolig hurtig, så længe koden ikke resulterer i nogen bizar opførsel. Efter min mening er det dette, der gør det så kraftigt til frontend og enkel backend (f.eks. IoT) udvikling.

Jeg mener personligt, at hvis man udvikler et system, der er så komplekst, at det kræver typesikkerhed, skal man bruge et sprog, der understøtter det i sin kerne; at skrive et vejledningssystem, der involverer komplekse matematiske operationer, i JavaScript er sindssygt.

Min største bekymring med disse JavaScript-værktøjer og supersæt er, at de kompilerer til, ja, JavaScript; disse programmer kører derfor i en dynamisk sammenhæng, og de samme bivirkninger kan derfor stadig forekomme. TypeScript kan for eksempel være statisk skrevet (dvs. typeoplysninger indsamles og analyseres ved kompileringstid), men man skal have fuld tillid til, at den resulterende kode stadig kører som forventet. Ja, selvfølgelig er selv statisk typede sprog normalt kompileret til et lavere niveau sprog, som derefter typisk fortolkes, men disse målsprog blev helt sikkert designet med at skrive som en førsteklasses borger; som et eksempel implementerer Microsofts JIT-kompilator til .NET stadig runtime-typekontrol af dets mellemliggende sprog, før den kompileres til native-kode.

Desuden er jeg stadig i tankegangen, når jeg foretager frontend-udvikling, at JavaScript skal bruges til at supplere HTML- og CSS-løsninger, f.eks. Tilføje klasser til elementer, foretage HTTP-opkald til backend-tjenester osv. Mens internettet er modnet med hensyn til rammer til forfatterskab større UI-baserede applikationer (FYI, jeg har skrevet større apps med React.js og vanilje JS også; jeg elsker begge dele), jeg foretrækker at holde min JS så lys som muligt. Jeg forstår, at dette ikke altid er en mulighed i virkeligheden, men hvis backend-systemer fungerer som kildesandheden for grundlæggende forretningslogik, bliver frontend-koden lettere og mindre overflødig; i denne henseende, hvilke fordele vil et typesystem medføre?

Efter min pointe om størrelsen af ​​frontend-software indebærer mit nuværende arbejde at skrive koncentrerede webapplikationer til hver bekymring i det overordnede system; i modsætning til en stor enkelt-sideapplikation til vores butik, som indeholder en produktlistevisning, en produktdetaljevisning og en købsvisning, har vi respektive Node.js-backede apps til dem. Dette er åbenbart en bedste praksis med hensyn til løs kobling og modstandsdygtighed, men fra et kodeperspektiv tillader det lettere at fokusere på implementeringen af ​​et område af vores frontend.

Mit sidste argument er dette; er JavaScript virkelig så svært at lære? Som jeg har sagt før, er ECMAScript 5 i sig selv et fejlbehæftet sprog; de forskellige funktionsopkaldsmønstre, og hvordan de påvirker nøgleordet `dette` og mangel på blokafgrænsning, kan for eksempel gøre det vanskeligt for begyndere. Men med ECMAScript 6 plus den overflod af fantastiske ressourcer derude er det let at overvinde og være opmærksom på disse problemer. Hvorfor ikke bare springe mellemmanden over og lære sproget direkte?

Jeg lukker ved at sige, at jeg er fan af alle skrivemetoder, men nogle passer mere til visse scenarier end andre. Hvis JavaScript fungerer bedst for størstedelen af ​​frontend-software i betragtning af dets allestedsnærværelse inden for udviklingsteams og deres projekter, har det bestemt ikke brug for et superset. Derudover er der en lastbil med sprog, der i sagens natur er typesikre, så stop med at genopfinde hjulet!