Javascript, eine der Säulen, auf denen das Web Content Engineering ruht, hat die Quarter Century Club. Es gibt es schon lange und egal wie man es betrachtet, seine Bedeutung ist unbestreitbar.
Hier werde ich die ehrgeizige Aufgabe übernehmen Analyse des JavaScript-Ökosystems, wobei zunächst die Geschichte dieser Programmiersprache beschrieben und später die verschiedenen Frontend- und Backend-Technologien behandelt werden, die in ihr existieren. Aber lassen Sie uns zuerst antworten Die Frage wo alles begann.
JavaScript ist eine Programmiersprache, die erstellt wurde von Brendan Eich 1995. Es war die Zeit der Browser-Kriege zwischen Browsern: Internet Explorer und Netscape Navigator kämpften darum, neue Funktionen bereitzustellen, und es gab keine Zeit zu verlieren.
Herr Brendan Eich, ein amerikanischer Technologe, arbeitete für Netscape und musste eine Programmiersprache erstellen, die es ermöglichen würde Frontend-Entwickler um kleine Programme in Webseiten einzubetten und sie interaktiver und dynamischer zu machen. Das Endprodukt musste flexibel, leicht zu erlernen, beliebt und leicht umsetzbar sein.
Herr Eich hatte nur 10 Arbeitstage Zeit, um die erste Implementierung zu erstellen - eine Tatsache, die wir mit dem Mann selbst bestätigten -, aber allen Widrigkeiten zum Trotz gelang es ihm, sie zu liefern.
Hier sind einige existierende Programmiersprachen, die das Ergebnis beeinflusst haben:
Die Sprache wurde unter dem Namen entwickelt Mokka und veröffentlichte später zusammen mit Netscape unter seinem aktuellen De-facto-Namen: Javascript.
Eine unvermeidliche Frage, die sich oft aufgrund der Wurzel ihres Namens stellt und die eine ziemlich kurze Antwort hat: Alles, außer einigen Syntaxelementen wie Klammern, Punkten, Semikolons, die ausdrücken analoge Konstrukte in beiden Sprachen. Der gewählte Name war eine Marketingmaßnahme von Netscape, um seine neue Kreation im Huckepack auf den Hype der Zeit zu präsentieren: Java.
Da JavaScript ein Erfolg war, hat Microsoft es rückentwickelt, um mit Netscape konkurrieren zu können, und veröffentlichte eine eigene Version unter dem Namen JScript.
Von Anfang an gab es mehrere Inkompatibilitäten zwischen den verschiedenen Implementierungen der Sprache. Um die Auswirkungen dieses Problems zu verringern, reichte Netscape JavaScript zur Standardisierung durch die Ecma International Normungsorganisation im Jahr 1997.
Die daraus resultierende standardisierte Version wurde benannt ECMA-Skript und erlangte zunehmend allgemeine Akzeptanz als Sprachspezifikation. Trotzdem blieb der Name JavaScript als De-facto-Name der Sprache in Gebrauch.
Um der Sprache neue Funktionen hinzuzufügen und sie mit der Arbeit anderer Normungsorganisationen kompatibel zu machen, der Standard hat sich von Zeit zu Zeit geändert.
Die Ergebnisse für jede Version sind als „ECMAScript“ bekannt. Hier werde ich eine kurze Beschreibung der wichtigsten Änderungen für jede Version auflisten.
Die erste Version des Sprachstandards.
Diese Version wurde 1998 produziert, als die Sprache auch standardisiert durch ISO/IEC. Es hat den Ecma-Standard so aktualisiert, dass er dem von ISO/IEC erstellten Dokument entspricht.
1999 wurden der Sprache mehrere neue Funktionen hinzugefügt. Die auffälligsten waren:
• Literale für reguläre Ausdrücke;
• Neue Kontrollanweisungen;
• Behandlung von Ausnahmen.
Dieser Versionsentwurf wurde 2008 aufgegeben aufgrund von Meinungsverschiedenheiten über den Funktionsumfang. Es wurde entschieden, dass das Ergebnis zu radikal war, um eingeführt zu werden, und es wurde vereinbart, eine Zwischenversion zu erstellen, bevor solch drastische Entwicklungen stattfinden würden.
Die Version, die Anfang 2016 die meisten Browser unterstützte, wurde 2009 erstellt. Die auffälligsten Merkmale waren:
• Iterationsfunktionen höherer Ordnung (zuordnen, reduzieren, filtern, forEach);
• JSON-Unterstützung;
• Getter und Setter;
• Bessere Reflexions- und Objekteigenschaften;
Genau wie EcmaScript 2 wurde diese Spezifikation erstellt, um den Ecma-Standard an das Dokument anzupassen, das von ISO/IEC für ECMAScript 5 erstellt wurde.
Diese Version hat 2015 mehrere große Änderungen hinzugefügt, nämlich:
• Versprechungen.
• Module;
• Klassen;
• Blockbereichsbezogene Variablendeklarationen (lassen);
• Pfeilfunktionen;
• Vorlage wörtlich;
• Spread-Operator;
• Destrukturierung der Aufgabe;
• Standardwerte der Parameter;
• Ruheparameter;
• Symbole;
• Funktionen des Generators.
Diese Version nur gemacht geringfügige Änderungen <Array.includes>zur Sprache, z. B. Hinzufügen eines Potenzierungsoperators und Angabe der Methode.
Die Browserunterstützung für diese Version ist unvollständig, obwohl es einen Transpiler gibt, der ES6-Code in ältere ES-Versionen konvertiert.
Fügt hauptsächlich Unterstützung für asynchrone Funktionen hinzu.
Diese Version erweitert das Toolkit für reguläre Ausdrücke und führt das ein Ruhe und Verbreitung Operatoren für Objektliterale. Es endlich führt <Promise.finally>als praktische Methode zur Rationalisierung von Verhalten ein, das immer unabhängig vom Ergebnis des Versprechens erfolgen sollte.
Die zehnte Interaktion brachte <Array.flat>und <Array.flatMap>Methoden zusammen mit der Lockerung der Catch-Blockfehlerbindung, die seit der Einführung von ES2017 erhöhte Aufmerksamkeit erregte asynchron und erwarten.
Der Entwurf dieser Version ist zwar noch lange nicht erreicht elfte Stunde, wir können schon zählen mit dem Nullischer Koaleszenzoperator und Optionaler Verkettungsoperator das wird zweifellos die Lesbarkeit des Codes erhöhen.
<Promise.all>Promises wird seine API auch um AllSettled erweitern, eine Alternative dazu löst immer mit einer Beschreibung des Ergebnisses jedes Versprechens auf wo auch immer sie sich lösen oder abgelehnt werden.
Obwohl JavaScript seine Reise mit der Notwendigkeit begann, Webseiten interaktiver und dynamischer zu gestalten, hat es einen langen Weg zurückgelegt und über mehrere Iterationen hinweg ist es ihm gelungen, auch seine Rolle als Backend-Sprache zu festigen.
Nach der Eroberung des Backends war die mobile Welt ein offenes Feld.
Es war mit dem Aufkommen von AJAX 1999 (2006 standardisiert) gewann JavaScript neuen Auftrieb. Vor AJAX wurde JavaScript hauptsächlich zur Animation und Interaktivität einiger Webseiten verwendet. Da diese Interaktivität jedoch nicht den Austausch von Daten mit dem Server beinhalten würde, würde sie nur aus einer zusätzlichen Anzeigelogik bestehen.
Mit AJAX begann JavaScript, wichtige Aufgaben in der Anwendungslogik unserer Webanwendungen auszuführen, bis zu dem Punkt, dass es heutzutage schwierig ist, Webanwendungen zu finden, für deren Betrieb kein Browser mit aktiviertem JavaScript erforderlich ist. Nach dieser Änderung begann das JavaScript-Ökosystem, sich als clientseitige Programmiersprache zu erweitern.
Die Hauptbedürfnisse der Entwickler, die mit AJAX-Webanwendungen arbeiten, sind:
• Ausführen von AJAX-Aufrufen;
• Manipulation des Document Object Model (DOM) — die Datenstruktur, die vom Browser beibehalten wird und die Struktur der Webseite darstellt;
• Reagieren Sie auf die Interaktionen des Benutzers.
Die wichtigsten JavaScript-Funktionen, die diese Funktionen zur Verfügung stellten, waren nicht sehr praktisch und manchmal war ihr Verhalten nicht mit verschiedenen Browsern kompatibel.
Die ersten Bibliotheken, die populär wurden, adressierten genau diese drei Aufgaben und stellten eine Sammlung von Funktionen und Objekten zur Verfügung, die diese Operationen in jedem Browser einfach und funktionell machten. Einige dieser Bibliotheken würden auch viele andere allgemeine Funktionen bieten:
EIN JavaScript-Framework das 2005 im Rahmen der Ruby on Rails AJAX-Unterstützung veröffentlicht wurde. Es erweiterte direkt viele JavaScript-Kernobjekte mit einem Verhalten, das der Programmiersprache Ruby etwas ähnelte, und fügte der Sprache auch ein klassenbasiertes System hinzu.
Diese Kernerweiterungen wurden von anderen Programmiergemeinschaften als problematisch angesehen und die bereitgestellten Funktionen waren seltsamer als die folgende konkurrierende Bibliothek:
Das jQuery-Framework wurde 2006 veröffentlicht und hat - im Gegensatz zu Prototype - quasi den Kern der Sprache belassen und sich eher darauf konzentriert, viele Funktionalitäten rund um DOM, Ereignisse, Asynchronität und Effekte bereitzustellen.
Ein hervorstechendes Merkmal ist das jQuery unterstützt ein Plugin-System, mit dem Bibliotheksprogrammierer seine Funktionalität erweitern können. Diese Bibliothek war die erfolgreichste Bibliothek dieser Art.und wird zum unverzichtbaren Werkzeug für Frontend-Entwicklung, das heutzutage auf den meisten Websites verwendet wird.
Trotz der immensen Beliebtheit von jQuery sowie seiner Fähigkeit, viele nützliche Funktionen bereitzustellen, Es ist wichtig zu beachten, dass moderne Versionen von JavaScript bereits viele der Funktionen bieten, die jQuery beliebt gemacht haben. Vielleicht Sie benötigen möglicherweise kein jQuery überhaupt.
Es wird immer beliebter, jQuery nicht zu verwenden und sich lieber entweder nur auf die aktuellen JavaScript-Kernfunktionen oder auf Bibliotheken zu verlassen, die auf jede spezifische Aufgabe spezialisiert sind (z. B. Fetch für AJAX-Aufrufe).
Bei der Verwendung von DOM-Manipulationsbibliotheken ist es üblich, die Anwendungsdaten im DOM selbst zu speichern. Daher gibt es DOM-Manipulations-Selektorfunktionen, die aufgerufen werden müssen, wenn auf diese Daten zugegriffen oder diese geändert werden müssen.
Diese Art von Code ist oft mit Selektornamen gefüllt und wird leicht zu einem Chaos, wenn sich die Komplexität der Anwendung weiterentwickelt. Es gibt eine Reihe von Frameworks, die es uns ermöglichen, dieses Problem auf elegante Weise anzugehen, indem wir auf Anwendungsmuster zurückgreifen, die den bekannten ähneln Model-View-Controller (MVC) -Muster.
Auf der anderen Seite In letzter Zeit gibt es einen Trend, bei dem Webanwendungen beim ersten Laden der Seite vollständig in den Browser geladen werden, führt alle nachfolgenden Operationen über AJAX aus.
Diese Art von Anwendungen heißt Einseitige Anwendung (SPA) und da ihr Code oft ziemlich aufwändig und komplex ist, Es empfiehlt sich, bei der Implementierung eines SPA eines dieser Frameworks auszuwählen. Schauen wir uns einige davon an.
Rückgrat ist ein Model-View-Presenter (MVP) -Framework, das Ende 2010 veröffentlicht wurde. Es konzentriert sich auf SPAs und erzwingt die Trennung zwischen Anwendungslogik, Display-Logik und Vorlagen.
Die Kommunikation zwischen diesen Entitäten wird ereignisbasiert verwaltet und unterstützt auch eine Router-Klasse, die es den Anwendungen ermöglicht, auf URLs zu reagieren und diese entsprechend den ausgelösten Ereignissen zu aktualisieren.
eckig ist ein von Google implementiertes Framework, das früher einer MVC-Architektur folgte und das sich zu einem MVVC-Framework entwickelt hat. Ähnlich wie Backbone konzentriert es sich auf SPAs und erzwingt die Trennung zwischen Anwendungslogik, Display-Logik und Vorlagen.
Es ist interessant festzustellen, dass Angular es dem Programmierer ermöglicht, HTML zu erweitern, indem er neue Tags erstellt, die in den Vorlagen verwendet werden können und Teile der Seite kapseln.
Eine weitere Besonderheit besteht darin, dass es die Einrichtung bidirektionaler Datenbindungen zwischen den Vorlagen und den JavaScript-Objekten ermöglicht, die von ihnen gerendert werden sollen.
Auf diese Weise löst jede Aktualisierung dieser Objekte automatisch HTML-Aktualisierungen aus, und — in ähnlicher Weise — werden die JavaScript-Objekte aktualisiert, wenn die entsprechenden Vorlageneingabefelder geändert werden.
Wie wir in den vorherigen Abschnitten beschrieben haben, wurde die Anzeigeschicht unserer Webanwendungen von einem einfachen Rechenmodell, bei dem die anzuzeigende Oberfläche nur von einigen vom serverseitigen Code berechneten Daten abhängig war, zu einem viel dynamischeren und komplexeren Modell übergegangen, bei dem es nicht nur von den abgerufenen Daten, sondern auch von den Benutzerinteraktionen und Skripten abhängt, die diese verarbeiten.
Diese Komplexität führt oft zu komplexem Code, der schwer zu teilen und zu begründen ist. Daher begannen einige Leute bei Facebook, mit einem einfacheren Rechenmodell zu experimentieren, um das Frontend zu codieren. Ein Rechenmodell, das es uns ermöglichen würde, uns vorzustellen, was auf der Seite wieder als Ergebnis des Zustands einiger weniger Variablen angezeigt wird, anstatt als Ergebnis der Interaktion zwischen einer „Zillion“ von Model-View-Controller-Klassen.
Um eine solche Änderung durchzusetzen, musste etwas Radikales passieren: Wenn wir wollten, dass die Anzeige nur das Ergebnis der Anwendung einer Funktion auf einige Zustandsvariablen ist, müssten wir aufhören, Teile des DOM direkt zu manipulieren und stattdessen jede Version des Displays als Ganzes rendern.
Da es zu langsam wäre, das gesamte DOM zu rendern, wenn etwas daran geändert wird, Es wurde beschlossen, das DOM auf eine einfache Darstellung abzubilden, die einfach zu regenerieren und zu vergleichen wäre.
Somit Immer wenn wir eine Variable ändern, können wir eine neue Version dieser leichten Darstellung generieren und sie mit der vorherigen Version vergleichenund berechnet so, welche Teile des DOM aktualisiert werden müssen. Wir nennen Virtual DOM für diese einfache Darstellung des DOM.
Reagieren war das erste Framework, das ein virtuelles DOM verwendete. Es wurde von Facebook entwickelt und die Architektur, der die Anwendungen folgen müssen, die es verwenden, ist minimal.
In Bezug auf MVC hält sich React nicht daran und es geht nur um den View-Teil des Codes. Damit wird der View als Baum von Entitäten dargestellt, die als Komponenten bezeichnet werden und selbst aus anderen Komponenten bestehen könnten.
Eine Komponente hat einen bestimmten Status, kann bei der Erstellung Eigenschaften erhalten und weiß, wie sie sich selbst für einen bestimmten Satz von Eigenschaften und Zustandsvariablen rendert. Immer wenn ihr Status geändert wird, wird eine neue Version des virtuellen DOM ihrer Anzeige gerendert und mit der vorherigen Version verglichen. Das benötigte DOM wird entsprechend aktualisiert.
Wenn einige Interaktionen, die an einer bestimmten Komponente ausgeführt werden, den Zustand der übergeordneten Komponenten ändern sollen, muss die übergeordnete Komponente den Behandlungscode in Form eines Callbacks an die Unterkomponente übergeben. Dieser Ansatz garantiert, dass die Komponenten lose miteinander verbunden sind, sodass sie leicht wiederverwendet werden können.
Eine ziemlich umstrittene Entscheidung der Entwickler dieses Frameworks ist, dass, anstatt HTML-Vorlagen wie die anderen Frameworks zu verwenden, eine HTML-ähnliche Darstellung des Codes als XHTML geschrieben wird, gemischt mit dem JavaScript-Code, was die Verwendung eines Compilers erfordert, der weiß, wie man diesen JS-XHTML-Mix (genannt JSX) in HTML-generierendes JavaScript transformiert.
Der komponentenbasierte Ansatz von React ist für kleinere Anwendungen effektiv, obwohl Facebook für die Strukturierung größerer Anwendungen eine Architektur namens Flux vorschlägt, bei der der Status der Anwendung außerhalb der Komponenten in sogenannten State-Containern gespeichert wird.
Die ursprüngliche Implementierung der Flux-Architektur war ziemlich komplex. aber es gibt eine einfachere namens Redux das ist das beliebteste und wurde sogar verwendet, um die Back-Ends der Anwendung zu implementieren.
Seine Architektur ist funktionell und anstatt den Zustand direkt zu mutieren, soll der Programmierer neue Versionen davon erstellen, indem er Reducer-Funktionen anwendet.und ermöglicht so einfaches Undo/Redo und zeitreisendes Debuggen.
Vue begann als MVC-Framework, das Angular ähnelte, sich jedoch darauf konzentrierte, einfacher zu sein und weniger Boilerplate zu benötigen. Die letzte Version bietet bereits einen komponentenbasierten Ansatz und ein Virtual-DOM, ähnlich wie React.
Die Dokumentation beschreibt es als progressives Framework, in dem Sinne, dass es nach und nach übernommen wird und es dem Benutzer somit ermöglicht, zunächst nur den Ansichtsteil des Frameworks zu verwenden und später bei Bedarf mehr Komplexität hinzuzufügen. Der Schwerpunkt liegt auf der Reduzierung von Standardformaten und der Anzahl der verwendeten Dateien, sofern dies möglich ist.
Bei der Entwicklung komplexer Webanwendungen fiel den Leuten auf, dass beim Abrufen von Daten über AJAX-Aufrufe häufig zu wenig und zu viel abgerufen wurde und dass es nicht einfach war, das Caching zu verwalten.
Um dieses Problem zu lösen, hat Facebook eine Abfragesprache entwickelt, mit der die Daten beschrieben werden können, die jeder Teil der Benutzeroberfläche benötigt. Diese Abfragen sollen interpretiert und zu effizienten Gruppen von AJAX-Anfragen aggregiert werden von einem GraphQL-Client.
Es sind mindestens zwei GraphQL-Clients verfügbar:
• Relais, die frühere Implementierung von Facebook, die stark mit React verwoben ist;
• Apollo, das danach strebt, ein Framework-unabhängiges Projekt zu sein.
Obwohl JavaScript seit Mitte der 90er Jahre auf der Serverseite verwendet wurde, waren seine Implementierungen ziemlich langsam und es gab keine klare Antwort darauf, wie JavaScript im Backend ausgeführt werden sollte, vor 2008, als Google die V8-JavaScript-Engine veröffentlichte, die zusammen mit der ersten Version des Chrome-Webbrowsers gebündelt war.
Bei der Implementierung des aufgerufenen V8-Motor, Google verwendete Optimierungstechniken, die beide während der Entwicklung bereits vergessener Compiler für Programmiersprachen entwickelt wurden, nämlich der Compiler von Self und Strongtalk. Das Ergebnis war für eine dynamisch typisierte Programmiersprache wie JavaScript bemerkenswert schnell und übertraf die Leistung anderer Implementierungen deutlich.
Andererseits wurden sowohl Chrome als auch V8 als Open-Source-Software (mit einer BSD-Lizenz) veröffentlicht, sodass jeder seine Arbeit darauf aufbauen und sie als Teil einer Software verteilen konnte, ohne Lizenzgebühren an Google zahlen zu müssen.
Es dauerte nicht lange, bis Ryan Dahl, ein amerikanischer Softwareingenieur, eine Umgebung namens Node.js wo JavaScript auf V8 außerhalb des Browsers ausgeführt werden könnte. Node bringt nicht nur V8 auf die Serverseite, sondern ist auch ereignisgesteuert, sodass alle blockierenden I/O-Operationen asynchron geschrieben werden können.
Diese Art, I/O zusammen mit dem schnellen V8 zu adressieren, machte Node für die Entwicklung serverseitiger Echtzeitanwendungen geeignet, die die Schnelligkeit blockierender I/O zusammen mit der Ausdruckskraft einer höheren Programmiersprache wie JavaScript erforderten.
Da die Kernspezifikation von JavaScript recht klein ist und nicht für die Serverseite gedacht ist, erfordert die Verwendung für solche Aufgaben normalerweise viele externe Bibliotheken. Es besteht die Notwendigkeit, einen Paketmanager für Node zu haben, der es Entwicklern ermöglicht, Pakete zu veröffentlichen und Bibliotheken, die in die Anwendungen des Entwicklers aufgenommen werden sollen, einfach abzurufen.
Das Node-Paketmanager (NPM) ist ein solcher Paketmanager, nur im Stil von Perls CPAN oder Rubys RubyGems.
Es gab einige Versuche, sowohl die Tools als auch die Technologien zu bündeln, um Full-Stack-Anwendungen zu erstellen. Hier werde ich über drei dieser Versuche sprechen.
Meteor ist ein Web-Framework, das MongoDB als Datenbank verwendet. Es verwendet ein Publish-Subscribe-Protokoll, das auf Ressourcen angewendet wird und es Clients ermöglicht, Updates zu erhalten, wenn die Daten auf dem Server aktualisiert werden. Es kann mit jedem clientseitigen Framework verwendet werden.
Das GEMEIN Stack steht für ein Paket mit den folgenden Technologien:
• MongoDB;
• Express;
• Eckig;
• Knoten.
Es enthält auch das Befehlszeilentool „mean“, mit dem Sie Projekte und Dateien generieren und andere nützliche Befehlszeilenaufgaben ausführen können.
Der MERN Stack ähnelt MEAN, konzentriert sich jedoch eher auf React als auf Angular.
JavaScript eroberte zwar das Web, machte aber auch als Technologie für die Entwicklung mobiler Anwendungen Fortschritte. Es wird oft gewählt, um plattformübergreifend mit Mobilgeräten umzugehen.
Apache Cordova ermöglicht die Entwicklung mobiler Anwendungen mit JavaScript, CSS und HTML. Es unterstützt auch einen FFI-Mechanismus, mit dem die Programmierer Teile des nativen Codes einbinden und auf einfache Weise Brücken zwischen JavaScript und nativer Funktionalität erstellen können.
Apache Cordova ermöglicht zwar die Entwicklung mobiler Anwendungen mit JavaScript, bietet jedoch nicht die dafür erforderlichen Funktionen auf hoher Ebene. Ionic ist ein Framework, das solche Funktionen bietet: Widgets, Bildschirmübergänge und andere Funktionen. Es folgt einer MVC-Architektur.
React Native wendet den komponentenbasierten Ansatz von React auf die mobile Entwicklung an, aber anstatt JavaScript auszuführen und es mit nativem Code interagieren zu lassen, kompiliert es das JavaScript eher in nativen Code.
Nativescript erscheint als ein weiteres beliebtes Framework, um die Angular- und Vue.js Webanwendungen in die mobile Welt zu bringen und eine homogene JavaScript-API für die Interaktion mit Mobilgeräten zu bieten.
Als Browsersprache JavaScript hat Anweisungen verpasst, um Abhängigkeiten zwischen Dateien zu spezifizieren und den Compiler anzuweisen, diese zu laden. Um dieses Problem zu lösen, wurden zwei verschiedene APIs spezifiziert, die um diese Aufgabe konkurrierten:
• Asynchrone Moduldefinition (AMD);
• CommonJS-Module;
• ES6-Module.
In der ES5-Welt implementierte Node.js CommonJS-Module, während Frontend-Programmierer AMD bevorzugten, was für Chaos in diesem Bereich sorgte. Es wurde daher eine Möglichkeit angegeben, Module zu benötigen und sie als aufgerufen zu deklarieren Universelle Moduldefinition (UMD), was ziemlich hässlich ist, aber Module mit beiden Modul-APIs kompatibel macht.
Wie dem auch sei, dieses Durcheinander wird durch die Einführung von ES6 gemildert, das bereits Konstrukte auf Sprachebene unterstützt, die auf den Umgang mit Modulen abzielen.
Wenn Sie Module bei der Entwicklung von Webanwendungen verwenden, müssen die verschiedenen Moduldateien häufig zu einer einzigen Datei zusammengeführt werden, die von der Webanwendung aufgenommen werden soll. Es gibt zwei Bibliotheken, mit denen Entwickler diese Aufgabe ausführen können:
Durchstöbern und verifizieren ist der älteste Webmodul-Bundler und ermöglicht es Entwicklern, die CommonJS-Modulsyntax beim Programmieren von Webanwendungen zu verwenden.
Webpack ist ein modernerer Webmodul-Bundler, der nicht nur JavaScript, sondern auch andere Assets wie Bilder und CSS bündelt. Dadurch können die verschiedenen Assets vom Browser im laufenden Betrieb neu geladen werden, wenn sich der Modulcode ändert.
Da nicht jeder mit der JavaScript-Sprache oder ihrer Unterstützung durch die Browser zufrieden ist, wurden mehrere Transpiler produziert, die andere Programmiersprachen in browsergestützte JavaScript-Versionen konvertieren. Es folgen einige Beispiele dafür:
Babel ist ein Transpiler, der modernes JavaScript in älteres, browserunterstütztes JavaScript umwandelt. Es ist sehr anpassbar und ermöglicht das Cross-Compilieren zwischen mehreren JavaScript-Versionen.
Web-Assembly (auch bekannt als wasm) ist ein Bytecode-Format, das jetzt von allen gängigen Browsern als Alternative zu JavaScript unterstützt wird. Derzeit gibt es nur wenige Compiler, die auf Web Assembly abzielen. Es sollte beachtet werden, dass Web Assembly vorerst keinen Garbage Collector enthält.
Daher sollte man beim Kompilieren nach wasm entweder eine Programmiersprache verwenden, die keinen Garbage-Collector benötigt, oder man muss anderweitig eine Laufzeit kompilieren, die die Garbage-Collection zusammen mit der verbleibenden Anwendung/dem verbleibenden Modul ermöglicht.
Dieser von Microsoft erstellte Transpiler konvertiert eine schrittweise typisierte Obermenge von JavaScript mit dem Namen Typoskript in JavaScript.
Flow ist ein statischer Typprüfer, der von Facebook entwickelt wurde. Wie Typescript ist es ein schrittweise typisiertes System, obwohl Flow sich nur auf die Typen konzentriert und der Sprache außer dem Typsystem nichts anderes hinzufügt.
Ulme ist ein Framework und ein rein typisierte funktionale Programmiersprache, inspiriert von Haskell das kompiliert zu JavaScript und folgt derselben Architektur wie Redux, das stark von Elm inspiriert ist.
Im Gegensatz zu anderen statischen Typsystemen garantiert dieses eine 100-prozentige Typabdeckung durch Typinferenz, sodass der Programmierer überhaupt keine Typsignatur explizit eingeben muss. Das Typsystem ist so sicher, dass es keine Laufzeitausnahme zulässt.
Dies ist Facebooks Version der Verwendung einer typisierten funktionalen Programmiersprache zur Generierung von JavaScript. ReasonML hat eine O'Caml-Semantik und eine JavaScript-freundliche Syntax, die auf geschweiften Klammern basiert. Es kann als Elms Cousin angesehen werden, der nicht so sehr an funktionaler Reinheit interessiert ist und der von Facebook unterstützt wird.
Wenn Projekte größer werden und ihre Ressourcen transformiert werden müssen, um sie ausführen zu können, müssen Skripte geschrieben werden, die die Ausführung dieser Transformationen verwalten — etwa make, ant oder rake. In JavaScript sind zwei auf Abhängigkeiten basierende Task-Runner implementiert:
Ein älterer hat angerufen Grunzen - in dem Daten, die zwischen den verschiedenen Transformationsschritten liegen, in temporären Dateien gespeichert werden. Und Schluck - das ist ein neueres, das eher Speicher als die temporären Dateien verwendet.
Da JavaScript eine Sprache ist, die aus dem Browser heraus geboren wurde, warum konnten wir es nicht verwenden, um die Serverseite unserer Webanwendungen zu entwickeln? Express ist das Framework, das sich mit diesem Problem befasst. Es zielt darauf ab, minimalistisch zu sein (wie Sinatra), obwohl es viele große Bibliotheken gibt, die dafür entwickelt wurden (z. B. automatische Backoffice-Generierung).
Da V8 zur Erstellung von Node verwendet wurde, wurde es auch von der dokumentorientierten MongoDB-Datenbank als Interpreter verwendet. Bei der Interaktion mit der Datenbank werden die Daten in JSON-ähnlichen Strukturen geteilt, und in der Abfragesprache geht es darum, JavaScript-Funktionen aufzurufen. Dies macht diese Datenbank bei JavaScript-Entwicklern sehr beliebt.
Yeoman ist ein interaktiver Projekt-Skeleton-Generator, der in JavaScript geschrieben ist. Es ermöglicht die Erstellung zahlreicher JavaScript-Projekttypen mit unterschiedlichen Konfigurationen - obwohl es nicht nur auf JavaScript ausgerichtet ist, kann es beispielsweise auch verwendet werden, um Skelette von Java-Projekten zu generieren.
Rails-Entwickler mit mehr als 10 Jahren Erfahrung mit verschiedenen Technologien. Ich interessiere mich für funktionale Programmierung.
People who read this post, also found these interesting:
.webp)
.webp)
%20(2).webp)
