Wählen Sie Ihr eigenes JavaScript-Abenteuer

Die Tatsache, dass JavaScript (JS) de facto zur zweiten Programmiersprache für jeden Entwickler von Webanwendungen geworden ist, ist schon bemerkenswert. Das ist ziemlich beeindruckend, wenn man bedenkt der Name selbst gewählt wurde, um sich an der Programmiersprache Java zu orientieren, obwohl er sich grundlegend von ihr unterscheidet. Letztes Jahr habe ich geschrieben, dass der Erfolg von PHP auf seine Entwicklung zurückzuführen istund man könnte sicherlich behaupten, dass die einzige andere Sprache, die eine ähnliche, wenn nicht sogar größere Entwicklung durchgemacht hat, JS ist. Aber wie geht man an diesen riesigen Stapel von Optionen heran? Ich habe mich inspirieren lassen von diesem mittlerweile legendären Artikelinspirieren lassen, den ich damals las und mich darüber freute, wie komplex die Dinge geworden waren. In diesem Artikel werden wir die Ursprünge, Vorteile und Nachteile dessen, was dieses komplexe Ökosystem ausgemacht hat, durchgehen.

Ursprünge

Back To The BeginningDie Einschränkungen von Vanilla JS wurden durch die erste große Bibliotheksveröffentlichung abgedeckt: jQuery. Heutzutage ist jQuery eher das Ziel von Witzen, weil die Probleme, die es gelöst hat, nativ in der Sprache enthalten sind, aber es ist wahrscheinlich erwähnenswert, dass jQuery im Jahr 2025 immer noch einen Marktanteil von 90 % auf Websites hat. Die Komplexität von modernen Front-End-Frameworks wie Vue und React wird durch die Einfachheit von jQuery für unkompliziertere Applications völlig ausgeglichen.

Node dreht das Drehbuch um

Ryan Dahl hat 2009 wirklich alles verändert. Zu diesem Zeitpunkt waren die V8-Engine von Google im Chrome-Browser, JScript im Internet Explorer und SpiderMonkey in Firefox die größten Laufzeit-Engines, die für ihre jeweiligen Browser verwendet wurden. In einem wahren Moment der Innovation stellte Ryan die Frage: "Was wäre, wenn man die V8-Engine herausnehmen und stattdessen auf einem Server laufen lassen würde? Und so kam es, Node geboren, nicht ahnend, dass jeder künftige Entwickler später verwirrt sein würde, wie genau wie Sie beschreiben was es eigentlich ist für Leute. Ist es ein Framework? Nein. Ist es JavaScript? Nein. "Eine Laufzeit- und Peripherie-Toolchain" ist die richtige Antwort.

Paket-Management

Watch that node_modules directory grow!Sobald Sie eine serverseitige Sprache haben, ist der nächste logische Schritt ein Paketverwaltungssystem. Der Node-Paketmanager (npm) war jahrelang das Standardwerkzeug, aber wie wir bereits gesehen haben, steht das JavaScript-Ökosystem selten lange still. Nicht zufrieden mit der Leistung, die mit der Auflösung von Abhängigkeiten geboten wurde, schuf Facebook Yarn im Jahr 2016. Mit Yarn wurden eine neue Sperrdatei und vor allem das Offline-Caching eingeführt. Die verbesserte Leistung könnte man mit der Entwicklung von PHP7 als Antwort auf HHVM; npm hat daraufhin seine Leistungsgeschwindigkeit erheblich verbessert und die Probleme angegangen, die zur Entwicklung von Yarn geführt haben. Daher ist das uralte "Es kommt auf Ihre Vorlieben an" die realistische Antwort auf die Frage "Was soll ich verwenden?"

I ES6ed alle Ihre gemeinsamen Module

JavaScript verfügte ursprünglich nicht über ein modulares System, das den Export von Dateien und Eigenschaften/Funktionen ermöglichte. Mit dem Aufkommen von Node und der beträchtlichen Skalierung von Web-Applikationen, die sowohl im Front- als auch im Back-End mit nativen Betriebssystem-Applikationen konkurrieren können, musste dieses Problem angegangen werden. Dies geschah in Form von CommonJSeinem Standard, der Importe mit Hilfe der require() Hilfsfunktion erlaubt.

Wie wir an anderer Stelle gesehen haben, ist JavaScript voll von Entwicklern, die versuchen, bestehende Probleme zu lösen, und eines dieser Probleme war Node, das Exporte mit CommonJS ermöglicht. Daher wäre die dauerhafte Lösung: Wie bekommen wir natives Importieren/Exportieren in JavaScript? Im Jahr 2015 hat ECMAScript genau dies mit der Hinzufügung von ESM (ECMAScript Modules).

Nach einem Muster, das Ihnen wahrscheinlich schon aufgefallen ist, haben Sie also zwei verschiedene Methoden zur Skalierung von Applications. "Welche soll ich verwenden?", fragen Sie. Auch hier lautet die Antwort technisch gesehen "welche Methode für Sie geeignet ist", aber das ist nicht ganz richtig. Für neue Projekte wird die Verwendung von ESM empfohlen, da es nativ ist und Unterstützung für Tree-Shaking und statische Analyse bietet.

TypeScript als Retter in der Not

A Saviour Is BornDas Problem mit JavaScript in der Browser-Engine oder Node ist, dass es sich um eine schwach typisierte Sprache handelt, die so ziemlich alles ausführen kann, was Sie versuchen. Diejenigen, die aus der Welt von Java, C# und anderen kompilierten Sprachen kommen, würden sich wahrscheinlich entsetzt über die Fähigkeit der JS-Entwickler aufregen, Berge von verrücktem, unsinnigem Code zu schreiben (und das haben sie auch: Ich erinnere mich noch genau an ein Frontend-Tool, bei dem alle Argumente für die Haupt-Hilfsfunktion nur Variablen in Form einzelner Buchstaben waren, die das Produkt buchstabierten, das ungenannt bleiben soll). JS hat immer jemanden, der sich um seine Grenzen kümmert, und in diesem speziellen Fall war es Microsoft.

Microsoft entwickelte eine Obermenge von JavaScript, die ein starkes Typisierungssystem in Form von sowohl eines Compilers und einer Laufzeitumgebung (die mit npx aufgerufen werden kann). Die Akzeptanz von TypeScript war ziemlich phänomenal, vor allem, wenn die Anforderungen an die Anwendung wahrscheinlich schnell skalieren werden. Hier bei Vonagewurde unser eigenes Node SDK wurde komplett umgeschrieben von Chuck Reeves für Version 3 komplett neu geschrieben und auf TypeScript portiert.

Verwirrung kompilieren

Die Einführung von npm als Paketmanager schuf ein einzigartiges Problem für Frontend-Entwickler: ein neuer Ordner namens node_modules existierte in Projekten, aber wie sollte man diese Abhängigkeiten in den Frontend-Code einbinden? Vor npm, Bower die Frontend-Abhängigkeiten behandelt. Mit npm wurde es jedoch weitgehend überflüssig. Wird in Verbindung mit npm verwendet, Grunt und Gulp als Task-Runner verwendet werden, meist in Verbindung mit Werkzeugen wie Babel verwendet, um JavaScript auf eine niedrigere Ebene zu transpilieren.

Die einheitliche Kompilierlösung kam in Form von Webpackdas ein gesamtes Frontend in eine einheitliche JS-Datei kompiliert, die auf einem Asset-System basiert. Alle CSS-Dateien, JS-Quelldateien oder solche aus der Paketverwaltung, Bilddateien, Sie nennen es. Wenn Sie den Typescript-Compiler benötigen, können Sie ihn einbinden, und Sie haben einen leistungsstarken Builder. Es gibt allerdings immer ein "aber"...

Ich habe in Agenturen und kommerziellen Unternehmen viel mit Webpack gearbeitet, und ich kann Ihnen sagen, dass mit großer Leistung auch große Komplexität einhergeht. Es bei jedem Build laufen zu lassen, ist zeitaufwändig, und die Anzahl der Male, in denen es aufgrund von Konfigurationsproblemen umkippte, brachte mich regelmäßig zum Weinen. Also, ganz im Sinne des Artikels: Raten Sie mal, was dann passierte? Richtig, jemand kam daher und baute etwas anderes. Der Autor der VueJS-Bibliothek (für mich persönlich ist Vue das einzige Frontend-JS-Framework, mit dem ich jemals gerne gearbeitet habe, aber das ist ein Thema für einen anderen Tag) Evan You erstellte Vite, einen Compiler und Server, der von Grund auf neu geschrieben wurde und überragende Benchmarks aufweist. Es wurde schnell übernommen von Remix, Laravel, Nuxt, und Astrowas ein ziemlich hochkarätiges Portfolio ist.

Laufzeit-Evolution: Deno und Bun.sh

The Journey Never EndsDies ist der Teil, in dem ich wirklich die Entwicklung von JS genossen. Wo Node den Stapel der Webanwendungen auf den Kopf stellte, hatte die Zeit Pläne, neue Probleme zu schaffen. Im Jahr 2009 steckten Serverless- und Cloud Native-Berechnungen noch in den Kinderschuhen. Im Jahr 2016 hatten DevOps-Ingenieure hohe Erwartungen an die Leistung, wenn sie ganze Funktionsabschlüsse in Node über die Rechenlaufzeiten von Cloud-Plattformen schickten. In dieser Phase gab es zwei Probleme: die Leistung bei Millionen von Ereignissen in der Ereignisschleife für Hochverfügbarkeitsanwendungen und das Node-Paketsystem (das inzwischen auch für alles im Frontend zuständig war), das in eine Abhängigkeitshölle von meme-ähnlichen Ausmaßen geriet.

Das erste Problem wurde vom ursprünglichen Schöpfer von Node angegangen. Im Jahr 2018, kündigte Ryan Denoan, und zwei Jahre später erfolgte die Produktionsfreigabe von Deno .. Deno konnte natürlich nicht "nur" die Abhängigkeitshölle lösen, die über Nacht aus npm entstanden war, aber es wurden verschiedene Mechanismen eingeführt, die alle Anwender der Laufzeitumgebung standardisieren würden:

• Typescript-Unterstützung von Anfang an, also ein Anstoß zu robusterem Code.

• Standardmäßig werden nur ESM-Module verwendet, d. h. kein Mix-and-Match zwischen ESM und CommonJS.

• Abschaffung eines Standard-Paketmanagers. Mit der Paketerfassung allein über URLs wurde die Laufzeit standardisiert, um zu vermeiden, dass sie eng an ein Verwaltungstool (d. h. npm) gekoppelt ist.

• Eine schlankere API. Ein Hauptproblem von Node war, dass kleine Teile des Codes "effektiv zum Kern" wurden. Die Aufnahme der wichtigsten Bibliotheken in eine Standardbibliothek und die Kürzung der überflüssigen Teile war ein kluger Schachzug, der möglicherweise verhindern konnte, dass Dinge wie ein paar Codezeilen, die das Internet zerstören.

Wäre die Schlussfolgerung also nicht, dass alle nach Deno ziehen sollten? Nun, nein. Denn dann..:

Bun.sh wurde im Jahr 2021 eingeführt.. Ich muss zugeben, dass ich überrascht war, dass eine weitere serverseitige Laufzeitumgebung veröffentlicht wurde. Was ist hier passiert?

Nun, Deno war eine Neuinterpretation von Node durch seinen Schöpfer, mit einigen Architekturentscheidungen, um die Tooling- und Ökosystemprobleme, die nach Node kamen, direkt zu stoppen. Bun, jedoch ging wirklich in die Stadt: es gestartet, um die optionale 3rd-Party-Tooling wesentlich zur Ausführung von Server-seitigen JS zu entfernen. Das bedeutete:

• Standardmäßige TypeScript-Unterstützung, wie bei Deno

• Ein eingebauter Testläufer

• Ein eingebauter Paketmanager

• Ein eingebauter Transpiler

• Ein eingebauter Bundler (z. B. Vite oder Ruby-Bundler)

Diese wurden alle gebaut in Zigentwickelt, was vergleichbar ist mit neuen Low-Level-Programmiersprachen, die C oder C++ ersetzt haben, wie z. B. Rust. "Welche soll ich denn nun wählen?" höre ich Sie wieder einmal fragen. Die Wahrheit ist, dass es keine richtige Antwort gibt. Jeder, der sich für eine Variante entscheidet, liegt in einem anderen Aspekt falsch, und das ist eben Full-Stack-JS für Sie.

Schlussfolgerung

Ich hoffe, Sie haben das riesige, ausufernde Abenteuer genossen, das die Entwicklung von JS ist. Die Sache ist, es gibt keine richtige oder falsche Antwort, wenn es um die Auswahl von Stacks und Tools kommt. Ich bin nicht einmal zu Astrooder Svelteoder Remix, oder Nuxt, oder Nächste. Ich bin nur ein bescheidener Entwickler, der versucht, Software zu liefern. Bei der Fülle der verfügbaren Laufzeiten und Werkzeuge ist das, was ich tun kann Ich kann nur Vorschläge machen, mit welchen Werkzeugen ich an Artikeln arbeiten kann, die Vonage-APIs verwenden. Treten Sie unserer florierenden Entwickler-Community auf Slackund folgen Sie uns auf X (früher Twitter), oder abonnieren Sie unseren Entwickler-Newsletter. Bleiben Sie in Verbindung, teilen Sie Ihre Fortschritte mit anderen und halten Sie sich über die neuesten Nachrichten, Tipps und Veranstaltungen für Entwickler auf dem Laufenden!