Ich habe Entwickler gesehen, die schon lange mit C arbeiten und immer noch mit MFC (Microsoft Foundation Classes) entwickeln. Der Grund ist einfach: Es gibt keine echten Alternativen zum Erstellen von Benutzeroberflächen in C. Obwohl Qt existiert, ist für die professionelle Nutzung eine kommerzielle Lizenz erforderlich, sodass MFC die einzige Option ist.
MFC stellt grundlegende UI-Komponenten bereit, ist aber dennoch in der Lage, Programme auf Produktionsebene wie CAD-Software oder Anwendungen für Krankenhäuser zu erstellen.
Der aktuelle Stand des JavaScript-Ökosystems ist ziemlich ähnlich.
Es gibt kein Framework, das speziell für die Ziele von HPSE entwickelt wurde. Zwar gibt es Spiel-Engines wie Babylon.js, diese bieten jedoch nur Funktionen für 3D-Grafiken und keine übergreifende Struktur wie React.
Am Ende kommt es also auf Vanilla JavaScript und TypeScript an. Es ist nicht so, dass Entwickler Vanilla JavaScript verwenden, weil sie es lieben; Sie nutzen es, weil es keine andere Wahl gibt. So wie in den Anfängen, als Entwickler mangels kommerzieller Frameworks alles von Grund auf in C erstellen mussten, stehen wir heute bei JavaScript vor der gleichen Situation. Es gibt kein bestehendes Framework, das die Anforderungen von HPSE vollständig erfüllt, daher müssen wir manuell mit Vanilla JavaScript entwickeln.
Und ehrlich gesagt gilt dies nicht nur für JavaScript. Das gilt auch für die meisten anderen Sprachen.
Es gibt ein Sprichwort: „So etwas wie ein kostenloses Mittagessen gibt es nicht.“
Viele der Programme, die mit großen Ambitionen begannen, neue Grenzen zu sprengen, verlassen sich letztendlich stark auf benutzerdefinierte Funktionen, die direkt in die Programmiersprache integriert sind. Auch HPSE begann mit der Vision, eines Tages native Programme im Browser auszuführen, und vorerst muss es Stück für Stück in Vanilla JavaScript geschrieben werden.
Einige könnten argumentieren: „Warum nicht einfach JavaScript aufgeben und stattdessen C oder Rust verwenden, um ein WebAssembly-Modul (WASM) zu erstellen und es stattdessen im Browser auszuführen?“
Es gibt eine gute Geschichte, die diese Frage beantwortet.
Die Leiter von Babylon.js und Three.js wurden einmal in einem Kommentar gefragt, ob die WASM-Technologie die Zukunft ihrer Motoren sein würde. Ihre Antwort war „Nein.“
Der Grund ist einfach: C/Rust-Code läuft nicht direkt in der Webumgebung, was das Debuggen erschwert. Und dank der Fortschritte der V8-Engine kann JavaScript jetzt eine hohe Leistung erzielen. JavaScript ist eine Skriptsprache, die direkt im Browser läuft und eine hohe Produktivität bietet – auf diese Stärken müssen Sie nicht verzichten.
In der Vergangenheit konkurrierten Programmierer mit der Entwicklung eigener Betriebssysteme. Doch nachdem Windows, Mac und Linux zu Standards wurden, verlagerte sich der Fokus auf die Entwicklung von Programmen, die auf diesen Systemen laufen. Ebenso haben sich die Browser heutzutage so weit entwickelt, dass es sinnvoll ist, darüber nachzudenken, wie man Programme erstellt, die in ihnen ausgeführt werden.
Wenn es klare Regeln darüber gäbe, wofür JavaScript verwendet werden sollte und was nicht, und wenn High-End-Aufgaben wirklich ungeeignet für JavaScript wären, dann hätte Microsoft das Babylon.js-Projekt nie gestartet, und Three.js würde es nie tun wurden erstellt. Gleiches gilt für WebGPU, das als neuer Webstandard etabliert wird.
Vor kurzem habe ich über meine Identität als Entwickler nachgedacht und mich gefragt, was genau „Frontend“ bedeutet und ob dieser Begriff wirklich den Umfang der Web-Client-Entwicklung umfassen kann.
Ich bin mir sicher, dass es in meinen Gedanken viele Fehlinformationen gibt, aber ich werde dies als meinen ersten Blogeintrag veröffentlichen, um meine Gedanken zu festigen.
Das obige ist der detaillierte Inhalt von(Die einzige aktuelle Alternative: Vanilla JavaScript. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!
