- Ein Google-Ingenieur hat dem offiziellen Standardisierungsgremium einen Vorschlag vorgestellt, JavaScript in zwei Sprachen aufzuteilen
- Vorgeschlagen wird eine Aufteilung in einen Kern, der in Runtime-Engines implementiert wird, und eine Variante mit mehr Funktionen, die auf Tools angewiesen ist, die diesen Kern kompilieren
- Die Präsentation fand Anfang dieses Monats auf dem Emca-TC39-Treffen statt
- TC39 ist das Gremium von Ecma International, das die JavaScript-(offiziell ECMAScript-)Spezifikation weiterentwickelt
- Die Präsentation wurde von Googles Shu-yu Guo gehalten; die Folien wurden gemeinsam mit Mitautoren von Mozilla, Apple, Moddable und Sony erstellt
- Shu-yu ist auf JIT, VM, Compiler und Standardisierung spezialisiert
- Argumente der Autoren
- Neue Sprachfunktionen verschlechtern fast immer die Sicherheit und wirken sich neutral oder negativ auf die Performance aus
- Die Stabilität verschlechtert sich mitunter ebenfalls, und die Funktionalität von Apps verbessert sich nur dann, wenn Entwickler die neuen Funktionen tatsächlich nutzen
- JavaScript-VMs (virtuelle Maschinen) sind durch den Druck auf hohe Geschwindigkeit bereits sehr komplex geworden, was die Sicherheit beeinträchtigt. Das wirkt besonders problematisch, wenn neue Funktionen nicht übernommen werden
- Sicherheitslücken und die „Komplexitätskosten“ der Runtime betreffen Milliarden von Nutzungen, während der Nutzen tatsächlich auf Entwickler und Anwendungen beschränkt ist, die diese Komplexität ausnutzen. Deshalb sollte die Basistechnologie von JavaScript einfach bleiben
- Obwohl mehrere Organisationen beteiligt sind, scheint diese Initiative in gewissem Maß von Google vorangetrieben zu werden
- Eine der Folien enthält den Haftungsausschluss: „Diese mögliche Lösung ist die von Google bevorzugte Lösung und nicht zwingend die Lösung anderer Implementierer“
- Die vorgeschlagene Lösung
- Es geht nicht darum, bestehende Funktionen zurückzunehmen, sondern den Ansatz künftig so zu ändern, dass die meisten neuen Funktionen nicht in der Engine, sondern in Tools implementiert werden
- Die in der Engine implementierte Sprache wird „JS0“ genannt, die in Tools implementierte Sprache „JSSugar“
- Das ist eine Idee, die besonders gut zu JavaScript passt, weil viele Entwickler faktisch in TypeScript programmieren und auf Compiler wie Babel, Webpack und den TypeScript-Compiler angewiesen sind
- Falls der Vorschlag angenommen wird, würden künftige Syntaxfunktionen an JSSugar gehen, während nur APIs und funktionale Features in JS0 landen
- Kompatible Engines müssten nur JS0 unterstützen
- Die Last würde auf Tool-Implementierer verlagert, damit diese JSSugar unterstützen
- Als Nebeneffekt müssten sich Tool-Implementierer stärker am Standardisierungsprozess beteiligen, und es könnte nötig werden, eine neue technische Gruppe zu bilden
- Der Vorschlag ist bereits umstritten
- Manche Entwickler fordern, JavaScript-Tools keinen offiziellen Status zu geben, und viele JavaScript-Entwickler möchten weniger von solchen Tools abhängig sein
- Zwar gibt es breite Einigkeit darüber, Sicherheit, Performance und Stabilität zu priorisieren, doch das Konzept, JavaScript von Zwischentools abhängig zu machen, ist unpopulär
- Ein Entwickler sagte sogar: „RIP Vanilla JS“
Meinung von GN⁺
- Dieser Vorschlag könnte große Veränderungen im JavaScript-Entwicklungsökosystem auslösen. Es gibt Bedenken, dass Entwickler für neue Syntaxfunktionen stärker auf Compiler angewiesen wären
- Das Ziel selbst, die Komplexität der Runtime-Engine zu verringern und Sicherheit sowie Performance zu verbessern, ist jedoch positiv. Langfristig könnte das der Weiterentwicklung von JavaScript helfen
- Eine andere Sprache mit einem ähnlichen Ansatz ist Dart. Dart bietet entwicklerfreundliche Syntax und wird zugleich zu JavaScript kompiliert, um im Browser zu laufen
- Bei einer Annahme dieses Vorschlags müssten verschiedene Faktoren sorgfältig berücksichtigt werden, darunter die Kompatibilität mit bestehendem Code, die Developer Experience und die Tool-Unterstützung. Außerdem wäre ein Prozess nötig, der die Meinungen der Community umfassend einbezieht
- Da JavaScript die grundlegende Sprache der Webentwicklung ist, dürften die lebhafte Diskussion und die Weiterentwicklung auch künftig anhalten
4 Kommentare
Es scheint, als wollten sie eine weitere Ebene hinzufügen und dort Inhalte ergänzen, die der DX zugutekommen.
Schon JSX hat ein Ökosystem hervorgebracht, das Transpiling voraussetzt, daher halte ich das für eine realitätsferne Ansicht. Es wirkt, als würde man denken, NodeJS sei alles.
Ich bin mir nicht sicher, ob ich es genau richtig verstanden habe, aber das wirkt ein bisschen ähnlich wie BOOST bei C++. Falls Googles Vorschlag angenommen wird und bestehende Bibliotheken in JSSugar integriert werden, was würde dann hineinkommen? Babel?
Hacker-News-Kommentare
Die HotSpot-VM von Java hat anderen Sprachen großen Erfolg gebracht. Für JavaScript wäre ein ähnlicher Ansatz sinnvoll: auf eine Kernsprache zielen und syntaktischen Zucker vorab kompilieren
Es ist besser, sich auf WebAssembly zu konzentrieren. JavaScript sollte für Skripting verwendet werden, andere Sprachen für größere Anwendungen
Als jemand, der VanillaJS bevorzugt, bin ich unzufrieden mit erzwungenen Änderungen an Sprachfunktionen. Der Fokus sollte auf der Verbesserung von APIs liegen, damit Web-Apps nativen Apps ebenbürtig werden
Ich widerspreche der Behauptung, es gebe keine Anwendungsfälle für BigInt. Auch wenn Googles Frontend-Entwickler es nicht verwenden, nutzen andere JS-Entwickler es durchaus. Der Fokus sollte auf der Weiterentwicklung der Sprache liegen
JavaScript und Wasm hätten getrennt werden sollen. Stattdessen wurde Wasm zu einem Bürger zweiter Klasse gemacht, ohne Zugriff auf Web-APIs
Die vorgeschlagene Lösung behebt das grundlegende Problem nicht und macht abhängig von Tools. JavaScript sollte auf eine neue Sprache umgestellt werden, um Performance-Probleme und Komplexität zu reduzieren
Probleme entstehen durch die Entkopplung von TC39 und der Entwickler-Community. TypeScript-Tools sind nicht standardisiert, und es gibt keine Pläne, sie nach Rust zu portieren
Aufgrund von Wartungsproblemen bei Googles V8-Engine werden Änderungen an JavaScript vorgeschlagen. Sicherheitsprobleme und die Kosten der Komplexität wirken sich auf die Nutzer aus. Statt C++ sollte eine andere Sprache ausprobiert werden