Wat Microsoft's ES Type Syntax-voorstel betekent voor JavaScript

0
99

JavaScript zou binnenkort zijn eigen typesyntaxis kunnen hebben als een voorstel dat eerder dit jaar door Microsoft en andere ontwikkelaars is ingediend, onderdeel wordt van de ECMAScript-standaard. Het initiatief is van plan om “types als opmerkingen” ondersteuning voor de JavaScript-taal, waardoor ontwikkelaars code kunnen annoteren met type-informatie die door andere ecosysteemcomponenten zal worden gebruikt.

De syntaxis

De voorgestelde syntaxis ziet er als volgt uit:

functie sayAge(naam: string, leeftijd: nummer) { console.log(`${name} is ${leeftijd} jaar oud.`); }   sayAge("JavaScript", 26"

Het zal bekend zijn bij iedereen die eerder TypeScript heeft gebruikt, de getypte superset van JavaScript van Microsoft. TypeScript is wijdverbreid in de industrie gebruikt; dit nieuwe voorstel is bedoeld om enkele van zijn voordelen naar de bredere JavaScript-wereld te brengen.

Wat is niet het voorstel?

Als het wordt goedgekeurd, kunt u met dit voorstel perfect geldig JavaScript schrijven met de typeannotaties die hierboven worden weergegeven. Het wordt geaccepteerd door JavaScript-runtimes zoals webbrowsers, Node.js en Deno die de ES-standaard respecteren.

Het voorstel breidt de JavaScript-taal echter niet uit. Uw typeannotaties zullen precies dat zijn: inerte metadata die geen effect hebben op de JavaScript-compiler of de runtime van uw code. Een functie-aanroep zoals de volgende zou tijdens runtime werken:

functie sayAge(naam: string, leeftijd: nummer) { console.log(`${name} is ${leeftijd} jaar oud.`); }   //"leeftijd" is een tekenreeks terwijl het een getal zou moeten zijn, maar dit is nog steeds toegestaan, zeg Age("JavaScript", "twenty");;

Het idee is om een ​​nieuw type syntaxis aan te bieden die officieel wordt ondersteund, maar volledig wordt genegeerd door engines. De enige wijziging voor implementaties betreft het herkennen en verwijderen van typeannotaties waar ze ook worden gebruikt.

Het voorstel zou trachten ondersteuning te bieden voor het annoteren van de soorten parameters, variabelen en klasse-eigenschappen. Het zou ook kijken naar het toevoegen van een interface-trefwoord, assertion-operators zoals ! en als, en een ? modifier om typen als optioneel te markeren. Het is de bedoeling dat al deze elementen TypeScript spiegelen; zoals bij elk voorstel van fase 0, kan het uiteindelijke resultaat anders werken.

Wat is het punt?

Als typeannotaties uw programma niet zullen veranderen, is de voor de hand liggende vraag of ze het waard zijn om te hebben. In het voorstel wordt “ja” vanwege het vermogen van de syntaxis om iteratietijden te verkorten en de last rond moderne JavaScript-toolchains te verminderen.

Het schrijven van typeveilige code vereist momenteel dat u TypeScript gebruikt, een andere taalsmaak die afhankelijkheden aan uw project toevoegt en een handmatige compilatie vereist. Die code kan dan andere tools passeren, zoals een modulebundelaar en transpiler voordat uw definitieve JavaScript wordt geproduceerd voor distributie. Het komt neer op een complexe toolchain met meerdere bewegende delen.

Hoewel JavaScript een inherent losjes getypte taal is, worden de voordelen van sterk typen nu algemeen erkend door de gemeenschap. Dit blijkt uit het momentum rond het TypeScript-project. Statisch typen was ook de duidelijke leider in de “ontbrekende functie” vraag.

Door een typesyntaxis aan JavaScript zelf toe te voegen, krijgt u enkele voordelen van TypeScript zonder uw code te hoeven compileren. Dit vereenvoudigt het opzetten en onderhouden van projecten terwijl JavaScript wordt ontwikkeld om beter af te stemmen op moderne ontwikkelingspraktijken.

In de afgelopen jaren is meer code begonnen terug te migreren naar een “pure JavaScript” nadering. De achteruitgang van legacy-browsers maakt transpilatie minder nodig dan het ooit was – de meeste moderne implementaties bieden volledige ondersteuning voor functies zoals klassen, pijlfuncties, block-scoped variabelen en async/wait. JavaScript heeft zelfs een volwaardig modulesysteem dat in verschillende engines werkt, ook in browsers.

Slechts een paar jaar geleden was er een lange toolchain nodig om deze functies in uw code te kunnen schrijven met vertrouwen dat het zou werken op gebruikers’ apparaten. Tegenwoordig kunnen ontwikkelaars die bouwprocessen veilig opzij zetten en terugkeren naar het originele JavaScript-model van het verwijzen naar bestanden met <script> tags.

Types zijn een van de weinige overgebleven gebieden van het JavaScript-ecosysteem die niet worden ondergebracht door de taal zelf. Houd van ze of haat ze, het valt niet te ontkennen dat typen een integraal onderdeel zijn geworden van JavaScript-ontwikkeling voor veel teams en projecten. Het syntaxisvoorstel erkent dit feit formeel. Het probeert JavaScript een zekere mate van typeondersteuning te bieden zonder bestaande code te breken of prestatiebepalende runtime-typecontroles af te dwingen.

Wat moeten typen eigenlijk doen?

De rol van een “type” varieert tussen talen. De gemeenschappelijke demoninator ligt in het vermogen van een type om het type gegevens uit te drukken dat een bepaalde variabele zal bevatten. Aanvullende betekenissen, mogelijkheden en gedragingen worden vervolgens op die basis gelaagd.

In statisch getypeerde gecompileerde talen zoals C# en Java worden typen afgedwongen tijdens het compileren. Het is onmogelijk om een ​​programma te compileren als je type-incompatibiliteiten in je code hebt. In geïnterpreteerde talen met optionele sterke typering, waarvan PHP een voorbeeld is, worden typen afgedwongen tijdens runtime – het programma geeft een fout wanneer het type van een waarde niet compatibel is met de context waarin het wordt gebruikt.

Een actief debat binnen de JavaScript-gemeenschap was hoe ver de taak van een ingebouwd type systeem zou moeten reiken. Dit voorstel beperkt zijn rol tot het meest fundamentele element, een eenvoudige documentatie van het verwachte type van een waarde. Dit komt goed overeen met de positie van TypeScript als een uitwisbare typesyntaxis die tijdens runtime wordt genegeerd.

Het doel van dit model is om ontwikkelaars direct feedback te geven over mogelijke bugs terwijl ze code schrijven. U kunt informatie krijgen over typeproblemen als u regelmatig JavaScript in een compatibele IDE schrijft. Als u wilt, kunt u ook een ondersteunend hulpmiddel gebruiken, zoals TypeScript, een statische analyser of een bundelaar om uw bron on-demand te controleren. Dit kan een implementatie in uw CI-pipelines blokkeren wanneer er een typeprobleem is.

Het huidige gevoel is dat deze mogelijkheden voldoende zijn om JavaScript af te stemmen op de meest voorkomende behoeften van ontwikkelaars. Functies die in andere talen worden gevonden, zoals introspectie en reflectie, zijn niet vaak nodig binnen het JavaScript-ecosysteem, deels omdat ontwikkelaars gewend zijn geraakt aan de manier van wissen van TypeScript.

Het bestaande alternatief: Docblocks

Het is vermeldenswaard dat er al iets bestaat dat lijkt op de voorgestelde syntaxis voor gewiste annotaties: bekende JSDoc-tags worden vaak gebruikt om typedetails toe te voegen aan gewone JavaScript-code:

/** * @param name {string} * @ param leeftijd {nummer} */functie sayAge(naam, leeftijd) { console.log(`${name} is ${leeftijd} jaar oud.`); }

JSDoc-opmerkingen worden ondersteund door verschillende populaire tools. Ze zijn echter geen gestandaardiseerd onderdeel van de taal en ze vereisen dat u details van de bewerking van uw code door elkaar haalt – de verwachte typen – met de mensgerichte documentatie die de rest van het docblock omvat.

De syntaxis van JSDoc is ook erg uitgebreid. Naast de vereiste tagnamen, vereist het meestal herhaling van elementen die al in uw code bestaan, zoals de parameternamen in het bovenstaande voorbeeld. Als u een parameter in de handtekening van de functie wijzigt, moet u niet vergeten om ook de JSDoc-tag te wijzigen.

Het nieuwe syntaxisvoorstel kan functioneel equivalent zijn aan docblocks, maar het biedt een veel meer gestroomlijnde ervaring. Types staan ​​naast hun doelen als onderdeel van je bron, in plaats van in een docblock dat je apart moet schrijven en onderhouden.

Wat is de volgende stap?

Het TypeScript-team van Microsoft en co-auteurs, waaronder Bloomberg, Igwalia en verschillende onafhankelijke bijdragers, hebben het Stage 0-voorstel ingediend in de plenaire vergadering van de TC39 in maart 2022. Het voorstel is sindsdien in fase 1 gevorderd. Acceptatie is echter nog ver weg, met implementatie in motoren die mogelijk pas 'jaren' zal aankomen.

De overkoepelende doelstelling van dit voorstel is om breng JavaScript's lange staart van niet-getypte code in evenwicht met de huidige vraag naar een meer statisch getypte ontwikkelingservaring. Het gebruik van een gewiste, volledig optionele syntaxis garandeert achterwaartse compatibiliteit, maar wekt het vooruitzicht dat het niet effectief zal zijn in het aanmoedigen van adoptie en het consolideren van het ecosysteem. Het debat hierover lijkt te groeien met nieuwe meningen en perspectieven naarmate het voorstel vordert in het standaardtraject.

LEES VOLGENDE

  • › Spotify deblokkeren
  • › De 2022-update van Windows 11 is er, de tabbladen van de bestandsverkenner binnenkort
  • › De PowerShell-versie op Windows 11 controleren
  • › Hoe installeer ik Windows 11's 2022 Update (22H2)
  • › Snapshots maken in VLC
  • › PowerShell bijwerken op Windows 11