Introductie van typeveiligheid in uw JavaScript-project? Denk nog eens na

Introductie van typeveiligheid in uw JavaScript-project? Denk nog eens na

Update - 1 februari 2017

Ik heb verschillende tegenargumenten gehoord met betrekking tot typeveiligheid in JavaScript sinds ik dit artikel voor het eerst publiceerde, en hoewel ik nog steeds van mening ben dat voor veel projecten geen getypte JavaScript-superset nodig is, geef ik toe dat ik te haastig was met het publiceren van dit artikel artikel. Enkele geschikte use-cases hebben vervolgens mijn aandacht getrokken:

  • Glimmer, de low-level rendering-engine achter Ember, is geschreven in TypeScript om monomorfe oproepsites te promoten, wat de prestaties ten goede komt wanneer deze wordt uitgevoerd door V8 en mogelijk andere JavaScript-engines
  • Visual Studio Code profiteert van TypeScript vanwege de enorme omvang van het project; gezien het feit dat het wordt gedistribueerd als een desktop-applicatie, is het naar mijn mening een verstandige optie om één codebase te hebben in plaats van individuele pakketten af ​​te stemmen tijdens het bouwen
  • Sect (weliswaar een eigen project, dus er is hier potentiële bias!) Is geschreven in TypeScript, zodat consumenten grote, modulaire games voor het web kunnen schrijven en tegelijkertijd runtime-fouten als gevolg van spelfouten en andere problemen die optreden als gevolg van JavaScript's dynamische aard

Ik heb me bovendien gerealiseerd dat het schrijven van kleinere bibliotheken in TypeScript en het publiceren ervan met de typedefinities die tijdens de build zijn gegenereerd, tegelijkertijd hun naadloze integratie met getypte en traditionele JavaScript-projecten mogelijk maakt, waardoor ontwikkelaars een ruimere technologische keuze hebben.

Niettemin, voor het nageslacht, hier is het originele artikel in zijn geheel.

Vandaag kwam ik een artikel tegen over de lancering van JS ++, waarin wordt beweerd "het gebrek aan typeveiligheid van JavaScript te verhelpen". Grappig genoeg hebben we al TypeScript, ST-JS en Scala.js, die ontwikkelaars helpen om uiteindelijk hetzelfde doel te bereiken.

Voordat ik met deze tirade begin, wil ik drie belangrijke punten naar voren halen:

  • Ik heb eerder een tutorial geschreven over het opzetten van een eenvoudig TypeScript-project. Ik zie de hypocrisie, maar mijn mening is veranderd sinds ik het meer dan een jaar geleden publiceerde
  • Sterk typen en statisch typen zijn essentiële paradigma's. De eerste biedt transparantie over de entiteiten die in de code worden weergegeven, hun relaties en de functionaliteit die ze kunnen verwachten te bieden, terwijl de laatste een belangrijk vangnet is tijdens het compileren in complexe systemen. Ik kom uit een C # -achtergrond, dus ik heb hier uit eerste hand ervaring mee
  • Ik hou ook van JavaScript, gezien de inherente tekortkomingen, waarvan er vele zijn verholpen met ECMAScript 6 en 7

Dus waarom ben ik over het algemeen tegen statisch typen in JavaScript?

Wat JavaScript tot zo'n krachtige taal maakt, is voornamelijk de zwak getypeerde aard ervan; het is triviaal om vertakkingen van logica te implementeren via typedwang, en het is zo gemakkelijk om objectinstanties van een willekeurig type te creëren. Bovendien zorgt het gebrek aan compilatie (tenzij men een transpiler of bouwtool zoals Babel gebruikt) voor een ongelooflijk snelle ontwikkeling, zolang de code niet tot bizar gedrag leidt. Naar mijn mening is dit wat het zo krachtig maakt voor frontend en eenvoudige backend (bijv. IoT) ontwikkeling.

Persoonlijk ben ik van mening dat als men een systeem ontwikkelt dat zo complex is dat het typeveiligheid vereist, men een taal moet gebruiken die dit in de kern ondersteunt; het schrijven van een begeleidingssysteem, dat complexe wiskundige bewerkingen met zich meebrengt, in JavaScript is krankzinnig.

Mijn grootste zorg met deze JavaScript-tools en supersets is dat ze compileren naar, nou ja, JavaScript; deze programma's draaien dus in een dynamische context, waardoor dezelfde bijwerkingen nog steeds kunnen optreden. TypeScript kan bijvoorbeeld statisch worden getypt (dwz type-informatie wordt verzameld en geanalyseerd tijdens het compileren), maar men moet er volledig op kunnen vertrouwen dat de resulterende code nog steeds zal werken zoals verwacht. Ja, natuurlijk worden zelfs statisch getypeerde talen meestal gecompileerd tot een taal op een lager niveau, die dan typisch wordt geïnterpreteerd, maar deze doeltalen zijn zeker ontworpen met typen als een eersteklas burger; Zo implementeert de JIT-compiler van Microsoft voor .NET nog steeds runtime-typecontrole van de tussenliggende taal voordat deze compileert naar native code.

Bovendien ben ik nog steeds van mening dat JavaScript moet worden gebruikt als aanvulling op HTML- en CSS-oplossingen, bijvoorbeeld door klassen aan elementen toe te voegen, HTTP-aanroepen te doen naar backend-services, enz. Terwijl het web volwassen is geworden in termen van frameworks voor authoring grotere, UI-gebaseerde applicaties (Ter info, ik heb ook grotere apps geschreven met React.js en vanilla JS; ik hou van beide), ik geef er de voorkeur aan om mijn JS zo licht mogelijk te houden. Ik begrijp dat dit in werkelijkheid niet altijd een mogelijkheid is, maar als backend-systemen dienen als de bronwaarheid voor fundamentele bedrijfslogica, dan wordt frontend-code lichter en minder redundant; Welke voordelen levert een typesysteem in dit opzicht op?

In navolging van mijn punt van de grootte van frontend-software, omvat mijn huidige werk het schrijven van geconcentreerde webapplicaties voor elke zorg van het overkoepelende systeem; In tegenstelling tot één grote applicatie van één pagina voor onze winkel, die een productlijstweergave, een productdetailsweergave en een aankooptrajectweergave bevat, hebben we daarvoor respectieve door Node.js ondersteunde apps. Dit is duidelijk een best practice in termen van losse koppeling en veerkracht, maar vanuit een codeperspectief kan men zich hierdoor gemakkelijker concentreren op de implementatie van een deel van onze frontend.

Mijn laatste argument is dit; is JavaScript echt zo moeilijk te leren? Zoals ik al eerder heb gezegd, is ECMAScript 5 zelf een gebrekkige taal; de verschillende functie-aanroeppatronen en hoe ze het 'this'-sleutelwoord beïnvloeden en het gebrek aan block scoping, kunnen het bijvoorbeeld moeilijk maken voor beginners. Met ECMAScript 6, plus de overvloed aan verbazingwekkende bronnen die er zijn, is het echter gemakkelijk te overwinnen en u bewust te zijn van deze problemen. Waarom sla je niet gewoon de middelste man over en leer je de taal direct?

Ik sluit af met te zeggen dat ik een fan ben van alle typemethoden, maar sommige passen meer bij bepaalde scenario's dan andere. Als JavaScript het beste werkt voor de meeste frontend-software, gezien de alomtegenwoordigheid ervan binnen ontwikkelteams en hun projecten, dan heeft het zeker geen superset nodig. Bovendien is er een vrachtwagenlading talen die inherent typeveilig zijn, dus stop met het opnieuw uitvinden van het wiel!