- Der aktuelle Trend, Node.js-Tools in schnelleren Sprachen wie Rust, Zig oder Go neu zu schreiben, ist besorgniserregend, und hier werden die sachlichen Bedenken dazu zusammengefasst
[Performance]
- Das Potenzial, JavaScript-Tools schneller zu machen, scheint noch längst nicht ausgeschöpft zu sein
- Bei ESLint, Tailwind und anderen gibt es viele Bereiche, die sich leicht verbessern lassen
- Im Browser ist JavaScript für die meisten Workloads „schnell genug“
- Warum also versucht man bei CLI-Tools, JavaScript aufzugeben?
Umfassende Neuschreibungen
- Lange Zeit war das JavaScript-Tooling-Ökosystem darauf fokussiert, dass Dinge überhaupt funktionieren
- Jetzt sind die APIs größtenteils stabilisiert, und alle wollen „dasselbe, nur schneller“
- Neue Tools können schneller sein, weil sie von Anfang an mit Blick auf Performance geschrieben werden und weil die API bereits feststeht, was Entwicklungszeit spart
- Wenn etwas von A nach B umgeschrieben wird und dadurch schneller wird, ist es leicht zu behaupten, B sei schneller als A
- Aber der eigentliche Grund kann auch die Neuschreibung selbst sein (weil man beim zweiten Mal mehr weiß und stärker auf Performance achtet)
Bytecode und JIT
- Im Browser nimmt man es als selbstverständlich hin, doch dort profitiert man von Bytecode-Cache und JIT (Just-In-Time-Compiler)
- Wenn JavaScript korrekt gecacht wird, muss der Browser den Quellcode nicht erneut in Bytecode parsen und kompilieren
- Häufig ausgeführte Funktionen werden zusätzlich in Maschinencode optimiert (JIT)
- Node.js-Skripte profitieren dagegen bislang überhaupt nicht vom Bytecode-Cache
- Inzwischen kann aber auch Node einen Compile-Cache verwenden (durch Setzen der Umgebungsvariable
NODE_COMPILE_CACHE)
- JIT bringt bei Einmal-Skripten nur begrenzt Vorteile, weil Funktionen mehrfach ausgeführt werden müssen, um „heiß“ zu werden
- In Pinafore sollte eine JavaScript-basierte blurhash-Bibliothek durch eine Rust-(Wasm)-Version ersetzt werden, aber ab der fünften Iteration verschwand der Performance-Unterschied
- Man könnte erwägen, Node-Skripte mit Tools wie Porffor AOT zu kompilieren
- Die Nutzung von Wasm bringt im Vergleich zu rein nativen Tools einen Performance-Nachteil mit sich
[Beitragshürden und Debugging]
- Das ist der Hauptgrund für die Skepsis gegenüber der Bewegung „alles nativ neu schreiben“
- JavaScript ist eine populäre Sprache wegen ihres nachsichtigen Typsystems, der leichten Erlernbarkeit und der Unterstützung im Browser
- Im JavaScript-Ökosystem haben über lange Zeit sowohl Bibliotheksautorinnen und -autoren als auch Nutzerinnen und Nutzer JavaScript verwendet
- Das hilft dabei, die Hürden für Beiträge niedrig zu halten
- Wenn JavaScript-Bibliotheksautorinnen und -autoren jedoch andere Sprachen verwenden, geht dieser Vorteil verloren
- Außerdem lassen sich JavaScript-Abhängigkeiten lokal sehr einfach patchen (direkt in
node_modules)
- Bei in nativen Sprachen geschriebenen Abhängigkeiten muss man dagegen den Quellcode direkt auschecken und kompilieren
- Beim Debugging von JavaScript-Bibliotheken kann man vertraute Browser-Developer-Tools oder den Node.js-Debugger verwenden
- Debugging in Wasm ist nicht unmöglich, erfordert aber ein anderes technisches Skillset
[Fazit]
- Es ist gut, dass eine neue Generation von Tools für das JavaScript-Ökosystem entsteht
- Bestehende Tools sind offenbar sehr langsam und dürften von Konkurrenz profitieren
- Aber JavaScript selbst ist nicht grundsätzlich langsam, und es gibt noch Spielraum für Verbesserungen
- Wenn man sich die jüngsten Verbesserungen in den Chromium-Developer-Tools ansieht, hat man das Gefühl, dass noch ein langer Weg vor uns liegt
- Es gibt Bedenken, wie eine Welt aussehen würde, in der nur noch Rust- und Zig-Entwicklerinnen und -Entwickler das Sagen haben
- Durchschnittliche JavaScript-Entwicklerinnen und -Entwickler könnten sich machtlos fühlen, wenn sie auf Bugs in Build-Tools stoßen
- Das könnte jungen Webentwicklerinnen und Webentwicklern eine erlernte Hilflosigkeit beibringen
- Man begibt sich damit auf unbekanntes Terrain, das unbeabsichtigte Folgen haben könnte
- Gleichzeitig gibt es andere Wege, die weniger riskant sind und fast zum gleichen Ergebnis führen können
- Dennoch gibt es derzeit keine Anzeichen dafür, dass sich dieser Trend abschwächt
Meinung von GN⁺
- Eine Neuschreibung in Rust, Zig oder ähnlichen Sprachen ist nicht immer die beste Lösung. In JavaScript selbst scheint es noch mehr Spielraum für Verbesserungen zu geben, etwa durch Compile-Cache
- Es ist fraglich, ob es für Einsteiger wirklich gut ist, mit komplexen Problemen wie Segfaults konfrontiert zu werden. Das könnte eher Hilflosigkeit fördern
- Man sollte hinterfragen, ob mehr Geschwindigkeit wirklich die richtige Richtung ist, wenn dafür die Vorteile des über lange Zeit mit JavaScript aufgebauten Ökosystems geopfert werden müssen, etwa das freie Patchen zwischen Bibliotheken oder vertraute Debugging-Umgebungen
- Auch die Verbesserung bestehender JavaScript-Bibliotheken sollte weiter vorangetrieben werden. Das Potenzial von JavaScript ist noch nicht vollständig ausgelotet
- Auch wenn sich der Trend kaum aufhalten lässt, braucht es zu dieser Richtung mehr ernsthafte Diskussion und Reflexion auf Community-Ebene
15 Kommentare
Die Arbeitsweise eines kleinen Ladens und die eines großen Marktes können sich durchaus unterscheiden.
Ich halte es für gesünder, weniger die Veränderung an sich kritisch zu sehen, sondern darüber nachzudenken, was dieses Phänomen bedeutet. Es mag so wirken, als könne man so etwas aus Geschmack oder wegen eines Trends ändern, aber Unternehmen treffen solche Entscheidungen normalerweise nicht so.
Sind Python oder JavaScript selbst langsam? Nicht unbedingt.
Sind häufig genutzte Tools, die mit Python oder JavaScript entwickelt wurden, langsam? Meiner Meinung nach ja.
Ich nutze mehrere stromsparende Geräte, und es gibt wirklich viele Tools, die zum Verzweifeln langsam sind..
Auch in der Python-Community wiederholt sich fast genau dasselbe Repertoire an Argumenten.
JavaScript ist nicht in JavaScript geschrieben, aber die meisten JavaScript-Entwickler kümmert das nicht. Für "Anfänger" und "junge Webentwickler" ist es kein Problem, dass JavaScript nicht in JavaScript geschrieben ist, aber dass es plötzlich ein Problem sein soll, wenn JavaScript-Entwicklungswerkzeuge nicht in JavaScript geschrieben sind, ist argumentativ nicht besonders stimmig. Tatsächlich gibt es unter beiden Gruppen nur eine sehr kleine Minderheit von Entwicklern, die sich überhaupt darum schert.
Selbst wenn man nicht bestreitet, dass man mit ausreichender Optimierung auf nahezu ähnliche Geschwindigkeiten kommen kann: Lohnt sich das wirklich?
Es ist einfach der Übergang von einer Zeit, in der es wirtschaftlicher war, Entwicklungswerkzeuge nicht in C++, sondern in JavaScript zu schreiben, zu einer Zeit, in der es wirtschaftlicher ist, sie in Rust statt in JavaScript zu schreiben.
Den Trend wird man nicht umkehren, indem man mit noch höheren Kosten eine Bewegung startet, JavaScript auf Biegen und Brechen zu optimieren, sondern indem man es ermöglicht, effiziente JavaScript-Werkzeuge auch mit geringeren Entwicklungskosten zu bauen. (Das mag ähnlich klingen, aber der Unterschied liegt darin, worauf man die Anstrengungen verwendet.)
Ich stimme zu. Ich denke, wir müssen Wirtschaftlichkeit stärker aus der Perspektive der Tool-Nutzer neu definieren.
Bisher war Wirtschaftlichkeit wohl eher ein Maßstab, der die Tool-Entwickler statt der Tool-Nutzer berücksichtigt hat. Es fühlt sich so an, als seien die Ineffizienzen und Performance-Probleme, die Tool-Nutzer erleben müssen, im Vergleich eher nachrangig behandelt worden. Ich persönlich nutze uv und vite gerne, und wenn möglich, würde ich Tools wie pip oder create-react-app lieber vermeiden.
Ich finde es schwer, dem zuzustimmen, weil ich denke, dass CLI-Tools ohne Runtime lauffähig sein sollten.
Wenn man fragt, ob man nicht eine eigenständig ausführbare WASM-Datei erstellen kann: Wie im Artikel gesagt, würde es dabei wahrscheinlich Performance-Einbußen geben.
So wie es nicht üblich ist, CLIs in Java zu schreiben, sehe ich das bei JavaScript genauso.
Es wirkt, als würde der Autor fälschlicherweise annehmen, dass für die Entwicklung von SPAs und von JavaScript-Tools dieselbe Sprache, nämlich JavaScript, verwendet wird und deshalb auch die sonstigen erforderlichen Fähigkeiten gleich seien. Ich denke, dass für JavaScript-Tools Kompetenzen in den Bereichen Systemprogrammierung und Compilerbau nötig sind.
> Im JavaScript-Ökosystem haben lange Zeit sowohl Bibliotheksautoren als auch Nutzer JavaScript verwendet.
> Das hat geholfen, die Hürde für Beiträge zu senken.
> Wenn JavaScript-Bibliotheksautoren jedoch eine andere Sprache verwenden, fällt dieser Vorteil weg.
Selbst wenn die Sprache dieselbe ist, unterscheiden sich die Laufzeitumgebungen zwischen Browser und NodeJS, und nur Menschen, die diese Kluft überbrücken können, werden zu JavaScript-Tools beitragen können. Da die Laufzeitumgebungen verschieden sind, sollte man das nicht eher als unterschiedliche Ökosysteme betrachten?
> Wenn der durchschnittliche JavaScript-Entwickler auf einen Bug in einem Build-Tool stößt, kann er sich hilflos fühlen.
> Das könnte jungen Webentwicklern eine erlernte Hilflosigkeit beibringen.
Auch das ist meiner Meinung nach eine Stelle, an der überschätzt wird, wie viele Menschen die Grenze zwischen SPA-Entwicklung und der Entwicklung von JavaScript-Tools überschreiten können. Von Frontend-Entwicklern Wissen auf dem Niveau der Systemprogrammierung zu verlangen, ist unrealistisch. Verstehen Tool-Nutzer nicht letztlich nur oberflächliche Fehlermeldungen oder Symptome? Ich denke nicht, dass das ein Problem ist, das sich allein dadurch lösen lässt, dass man die Sprache kennt.
Es wirkt so, als würden hier Tools und Bibliotheken durcheinandergebracht. Bei Bibliotheken kann ich dem bis zu einem gewissen Grad zustimmen, aber bei Tools bin ich eher skeptisch..
Entwickler anderer Sprachen sind doch auch daran gewöhnt, dass Tools nativ geschrieben sind.
Meiner persönlichen Ansicht nach gilt: Wenn ein Tool oder eine Bibliothek in JavaScript geschrieben ist, können Entwickler, die mit JavaScript vertraut sind, sie debuggen und bei Bedarf dazu beitragen. Wird es oder sie jedoch in Rust neu geschrieben, können am Open-Source-Beitrag am Ende nur noch Rust-Entwickler mitwirken. Da die Zahl der JavaScript-Entwickler im Vergleich zu Rust überwältigend größer ist, kann es für das Open-Source-Ökosystem vorteilhafter sein, wenn Tools oder Bibliotheken in JavaScript geschrieben werden.
Ich denke, dass JavaScript durch die Fragmentierung seiner Laufzeitumgebungen zwischen Browser und NodeJS geprägt ist und daher ein einfacher Vergleich der Zahl der Sprachbenutzer als Argument nur begrenzt aussagekräftig ist. Zwischen Backend-Spring-Entwicklern und JDK-Entwicklern sowie zwischen React-/Angular-/Vue-Entwicklern und JavaScript-Tool-Entwicklern bestehen unterschiedliche Interessen und Positionen; es handelt sich um eine Beziehung zwischen Konsumenten und Produzenten.
Wenn es darum geht, die Performance und Usability von JavaScript-Tools zu verbessern, halte ich es persönlich für eine durchaus mögliche Option, auch die Implementierungssprache als Mittel zum Zweck zu wechseln.
Ich halte es für schwierig, Verbraucher und Produzenten von Entwicklungstools klar voneinander zu trennen. Wenn ein Unternehmen wächst, werden Toolchains oft an die eigenen Regeln angepasst oder durch zusätzliche Plugins erweitert. In solchen Fällen ist es meiner Meinung nach schon ein großer Vorteil, einfach dieselbe Sprache zu verwenden.
Oft interessieren sich die Nutzer eines Tools auch für Verbesserungen oder die Implementierung des Tools selbst und leisten dann ganz natürlich Beiträge dazu.
Ich denke, dass Menschen, die sich für Toolchain-Anpassungen interessieren oder diese Arbeit übernehmen, über die Rolle des Konsumenten hinausgehen und eher als Prosumer oder sogar als Produzenten agieren. Bei Plugins bewegen sie sich, so sehe ich das, innerhalb der Plugin-Konventionen zwischen Produzent und Konsument. In einer solchen Situation stimme ich auch zu, dass die Verwendung derselben Sprache technisch wie auch in den Kommunikationskosten hilfreicher ist, als ein separates Konfigurationsdateiformat oder Erweiterungspunkte bereitzustellen.
Allerdings halte ich weder die Performance-Probleme von JavaScript-Tools noch die durch JIT verursachte Verzögerung von NodeJS für etwas, das im Entscheidungsbereich der Konsumenten liegt. Denn die Akteure, die eine solche Architektur und Betriebsspezifikation geschaffen haben, sind die Tool-Produzenten und die Entwickler der Runtime.
Ich bezweifle, dass der große JavaScript-Markt automatisch bedeutet, dass es mehr Entwickler gibt, die zu Compiler-/Transpiler-Codebasen beitragen können. Bibliotheks-Frameworks und grundlegende Tools sind meiner Meinung nach völlig unterschiedliche Bereiche.
Aber vielleicht ist schon das Umschreiben selbst der Grund, warum es schneller wird -> Im Rückblick ist das wirklich ein treffender Punkt ...
Ich kann die Aussage dieser Person gut nachvollziehen, gerade weil sie sehr selektiv ist.
Gleichzeitig finde ich aber, dass es aus Sicht des technischen Fortschritts ein sehr wichtiger Faktor ist, dass es neben JS auch verschiedene andere Lösungsansätze gibt, und ich denke, dass daher auch die gegenteilige Position respektiert werden sollte!
Hacker-News-Kommentare
Es gibt die Ansicht, dass JavaScript von Natur aus langsam ist. Viele Ingenieure haben versucht, es schneller zu machen, aber es bleibt dennoch langsamer als statisch typisierte Sprachen. Für große Programme eignen sich Sprachen mit klaren Typen besser.
JavaScript ist nicht leicht zu lernen und hat ein komplexes Prototypen- und Typsystem. TypeScript gleicht das zwar aus, bleibt aber dennoch komplex.
Schon ein Sprachwechsel kann die Performance deutlich verbessern. Als ein bestehendes System von JS und PHP auf Go umgestellt wurde, wurde eine Leistungssteigerung um das 8- bis 10-Fache erlebt.
Die Bedeutung der Parallelverarbeitung wird unterschätzt. Rust eignet sich für das Schreiben parallelen Codes, JS dagegen nicht.
JavaScript ist inzwischen etwa so schnell wie Java und 2- bis 4-mal langsamer als C++. Wer mehr Performance will, muss die Komfortzone verlassen.
Programme in Rust, Zig und Go lassen sich leicht anhand des Quellcodes nachvollziehen und kompilieren. Das Erlernen neuer Sprachen beeinflusst, wie man Probleme löst.
Man sei der Meinung, dass die Möglichkeiten zur Leistungssteigerung bei JavaScript-Tools noch nicht ausgeschöpft sind. Es ist effizienter, auf einer besseren Grundlage aufzubauen.
Rspack ist eine in Rust geschriebene, kompatible Neufassung von Webpack und bietet eine 5- bis 10-fache Performance-Steigerung. Es kann Webpack leicht ersetzen.
Lokale Änderungen an JavaScript-Abhängigkeiten sind einfach, aber bei Rust gibt es weniger Bugs, sodass seltener Anpassungen nötig sind. Rust ist schwer zu lernen, macht einen aber auch in anderen Sprachen zu einem besseren Programmierer.