Javascript – Warum gibt es eine Spezifikation für Sync- und Async-Module?

Lesezeit: 5 Minuten

Ich habe das gerade fertig gelesen Artikel auf Javascript-Module. Ich kann verstehen, dass CommonJS-Module synchron geladen werden, während AMD-Module asynchron geladen werden.

Was ich nicht verstehe ist, wie kann ich Modul werden magisch synchron wenn ich es im CommonJS-Format schreibe, oder wie es auf magische Weise asynchron wird, wenn ich es im AMD-Format. Ich meine, Javascript hat keine define oder require Stichwort sogar. Alles, was sie sind, sind Spezifikationen, keine Bibliotheken.

Ich meine, das Verhalten beim Laden von Modulen hängt vom Modullader ab und nicht davon, wie das Modul strukturiert ist. Und wenn das der Fall ist, warum folgt man dann einem Codierungsmuster für verschiedene Arten von Modulen?

Gehe ich richtig in der Annahme, dass alle Bibliotheken in der NodeJS-Welt synchron geladen werden, egal in welchem ​​Format sie geschrieben sind. Und alle Module im Browserbereich werden asynchron geladen.

Wenn meine obige Annahme richtig ist, warum gibt es dann überhaupt eine Spezifikation für UMD? Ich meine, wenn ein Skript basierend auf der Umgebung geladen wird, in der es vorhanden ist, warum dann eine Spezifikation für das Laden universeller Module erstellen?

Kann mir jemand bei dieser Verwirrung helfen?

  • Wie ein “Modul” geladen wird, ändert nichts am Code – Ihre Annahme über den Code innerhalb des Moduls ist Ihr Stolperstein

    – Jaromanda X

    10. November 16 um 8:35 Uhr

  • @JaromandaX Ja, warum gibt es Modulspezifikationen? Könnten Sie bitte näher erläutern, was Sie meinen?

    – ng.Neuling

    10. November 16 um 08:43 Uhr

  • Das Modul selbst wird nicht synchron oder asynchron, es ist nur die Art von Loader-Schnittstelle, die sie aufrufen. Das CJS-Format geht von einem synchronen Ladeprogramm aus, das auf Browsern nicht gut funktioniert, daher wurde das AMD-Format erstellt, um eine Abhängigkeitsdeklaration mit asynchroner Textausführung (ein Rückruf) zu ermöglichen. AMD würde auch mit einem synchronen Loader arbeiten.

    – Bergi

    10. November 16 um 10:43 Uhr

Das ist eine gute Frage. Es ist ein Thema, das viele hitzige Diskussionen in der Node-Community ausgelöst hat. Um zu verstehen, worum es geht, sollten Sie lesen:

Beantworten Sie nun Ihre Frage: Warum gibt es eine Spezifikation für Sync- und Async-Module? Weil einige Anwendungsfälle das synchrone Laden von Modulen bevorzugen, wie die serverseitigen Module in Node.js, wo Sie alles laden möchten, was Sie brauchen, bevor Sie mit dem Verarbeiten von Anfragen beginnen, und einige Anwendungsfälle bevorzugen das asynchrone Laden von Modulen, wie im Browser, wenn Sie ihn anziehen Ich möchte den Rendering-Thread nicht blockieren, während Sie die Abhängigkeiten laden.

Es gibt wirklich keine Option zum synchronen Laden im Browser, da dies dazu führen würde, dass der Browser nicht reagiert.

Sie könnten argumentieren, dass Sie asynchrones Laden auf dem Server verwenden könnten, aber dann müssten Sie entweder Promises anstelle von Modulen zurückgeben require() oder es könnte Rückrufe annehmen. In jedem Fall würde es jeden komplexen Code, der viele Module verwendet, viel komplizierter machen.

Ein weiteres Problem ist das Caching und die Mutation der bereits geladenen Module. Bei synchronem Modulladen mit require Sie laden das Modul nur einmal und alle anderen Aufrufe dazu require für dasselbe Modul in der gesamten Codebasis (für diesen Prozess) eine zwischengespeicherte Antwort zurückgeben, die jedes Mal dasselbe Objekt ist. Jeder Teil des Codes kann dieses Objekt ändern und es steht jedem anderen Teil des Codes zur Verfügung. Einige Anwendungsfälle, die diese Funktion verwenden, wären viel komplexer zu implementieren. Außerdem wäre die Reihenfolge des Ladens und Ausführens von Code schwerer vorherzusagen.

Um die Antwort auf Ihre Frage zusammenzufassen, gibt es Argumente für beide Arten des Ladens von Modulen, und keine dieser Methoden ist für jedes Szenario ein klarer Gewinner. Beide werden benötigt und beide haben einige Spezifikationen, um ihr Verhalten zu standardisieren.

Lesen Sie die Artikel, die ich verlinkt habe, um ein detaillierteres Verständnis zu erhalten.

  • Danke, aber sag eine einfache Sache. Ich schreibe ein js im Browser und lade es über einen beliebigen asynchronen Loader, der zu einem asynchronen Modul wird. Aber ich verwende dieselbe Datei in NodeJS, die zu einem Synchronisierungsmodul wird. Mein Punkt ist also, warum ich einer Spezifikation für zwei Umgebungen folgen sollte, wenn es keine Rolle spielt. Auch AFAIK, <script> Tags bieten synchrones Laden im Browser, während Ladeprogramme wie SystemJS bietet asynchrones Laden, richtig? Also ich meine, Sie können synchron in den Browser laden, oder?

    – ng.Neuling

    10. November 16 um 10:39 Uhr


Ich meine, das Verhalten beim Laden von Modulen hängt vom Modullader ab und nicht davon, wie das Modul strukturiert ist. Und wenn das der Fall ist, warum folgt man dann einem Codierungsmuster für verschiedene Arten von Modulen?

Ob das Modul synchron oder asynchron geladen wird, hängt vom Modullader ab, aber Ihr Modul muss in der Lage sein, einen Modullader zu verwenden, muss also enthalten Schnittstelle um mit dem Lader zu kommunizieren. Sie können keine Module in node.js mit AMD laden define Funktion. Sie müssen verwenden require.

Wenn meine obige Annahme richtig ist, warum gibt es dann überhaupt eine Spezifikation für UMD? Ich meine, wenn ein Skript basierend auf der Umgebung geladen wird, in der es vorhanden ist, warum dann eine Spezifikation für das Laden universeller Module erstellen?

Das Skript wird nicht basierend auf der Umgebung geladen, sondern über die Loader-Schnittstelle. UMD ist für Bibliotheken, die sowohl im Browser als auch auf dem Server verwendet werden. Der Autor der Bibliothek muss nicht zwei Versionen der Bibliothek erstellen, eine für den Browser und eine für den Knoten, weil UMD weiß mit beidem umzugehen.

.

501050cookie-checkJavascript – Warum gibt es eine Spezifikation für Sync- und Async-Module?

This website is using cookies to improve the user-friendliness. You agree by using the website further.

Privacy policy