I disse dager foregår det en ganske opphetet debatt i JavaScript-miljøet, etter et nytt forslag i TC39-komitéen om å splitte JavaScript-språket i to.
TC39 er de som har ansvaret for å ta forslag om ny funksjonalitet i JavaScript fra idé til godkjenning.
Bakgrunnen for forslaget er en bekymring for at nye JavaScript-funksjoner øker risikoen for sikkerhetsproblemer i nettlesere.
Derfor foreslås det å dele språket i to – JS0 og JSSugar:
- JS0: Språket som implementeres av JavaScript-motorene
- JSSugar: Utvidet JavaScript-syntaks, som byggeverktøyene kompilerer til JS0
"Dreper Vanilla"
For å støtte all JavaScript-funksjonalitet, vil utviklere altså måtte bruke byggeverktøy som TypeScript-kompilatoren, Babel, WebPack og andre for å kompilere til JS0 som forstås av for eksempel nettleseren.
Forslaget har ikke blitt spesielt godt mottatt – blant annet mener NullVoxPopuli, en kjent utvikler i Ember-miljøet, at forslaget vil drepe "vanilla" JavaScript:
This presentation to TC39 has me *worried* for the future of JavaScript.
— NullVoxPopuli (@nullvoxpopuli) October 5, 2024
I
Do not
like this phrasing.
Let's dive in 👇
(1/35) pic.twitter.com/oWMDhc0WGw
Google er pådriver
Forslaget ble presentert av utviklere fra Google, Mozilla, Apple, Moddable og Sony – men det skal være Google som er den største pådriveren.
De som står bak forslaget argumenterer for at det finnes mange forskjellige JavaScript-motorer, og det å holde alle disse oppdatert med alt mulig av ny funksjonalitet i JavaScript-språket blir vanskeligere og vanskeligere.
Allerede i dag brukes polyfills for å gjøre det mulig for utviklere å ta i bruk ny JavaScript-funksjonalitet før alle nettlesere støtter det. Det fungerer ved at byggeverktøyene kompilerer/transpilerer inn støtte for den nye funksjonaliteten.
Forslaget om JSSugar + JS0 innebærer altså at dette blir den vanlige måten å gjøre ting på.
Ny funksjonalitet i JavaScript kan ifølge forslaget være en del av JavaScript-standarden, men altså ikke noe JavaScript-motorer (som V8) håndterer direkte. Utviklere skal istedet forvente at byggeverktøy og polyfills vil implementere funksjonaliteten automatisk for deg ved å skrive det om til JS0-kode.
Sånn fiksa Microsoft mye raskere VSCode-oppstart
JavaScript før og etter
Slik fungerer det i dag:
Mens forslaget er å heller gjøre det på denne måten:
Alt JavaScript-motorene trenger å forholde seg til er JS0. Mens utviklerne forholder seg til alt som er mulig å gjøre i JSSugar, JS0 og TypeScript.
– Ikke glem at nettsider fortsatt er HTML, JS, CSS!
Mange kritikere
Ved å begrense funksjonaliteten til JS0 kan de som utvikler nettlesere fokusere på å optimalisere ytelse og sikkerhet til dette "kjernespråket".
Samtidig vil man kunne oppnå raskere innovasjon i JavaScript, siden man gjennom JSSugar kan rulle ut ny JS-funksjonalitet som utviklere automatisk får tilgang til gjennom støtte i byggeverktøyene de bruker. De trenger ikke vente på at nettlesere skal få støtten innebygget, slik man må i dag.
Kritikere mener JS Sugar vil gjøre byggeverktøy obligatorisk for alle webutviklere, noe som vil øke kompleksiteten og kanskje gjøre det vanskelig for nybegynnere å lære JavaScript.
– Byggeverktøy et krav? RIP Vanilla JS, skriver NullVoxPopuli på X.
Også andre er bekymret:
The proposal to split JS into 2 separate langs (js-sugar/js0), and force devs to compile all of the JS we write is insane, and shows just how out of touch the people maintaining the engines are from everyday devs. I want LESS required tooling. We're not all building frameworks.
— Matt Beck (@mattbeck) October 16, 2024
Noen er positive
Andre er mer positive:
– Jeg tror dette kan bidra til å få ting til å gå raskere, siden forslag kan håndteres raskere og noen funksjoner kan implementeres raskere ved hjelp av byggeverktøy, uten å introdusere risikoer eller ødelegge web-en, skriver utvikleren Nils Riedemann i et blogginnlegg.
Han mener det også vil forhindre at språket eser ut – ved at man holder bare det grunnleggende i JavaScript i JS0, og at byggeverktøyene heller transpilerer inn mer "sære" ting for de utviklerne som trenger det.