ESM, steht für ES Modules, steht für JavaScript-Module. Also, import und Freunde.
Browser unterstützen es heutzutage. Es gibt viel Nuancierung, aber solange du IE fallen gelassen hast, steht die Tür ziemlich offen.
Vor ESM war die Situation für JavaScript-Projekte
- Wir haben Pakete, die wir von npm verwenden müssen.
- Wir werden sie im Voraus mit unserer
package.json,npm installund was auch immer von npm installieren. - Wir werden
import-Anweisungen schreiben, die aus irgendeinem Grund *ungültige* ESM sind (Bequemlichkeit des Entwicklers, nehme ich an) und davon ausgehen, dass wir Pakete aus einem lokalennode_modules-Ordner importieren. - Unser Bundler wird wissen, was er mit diesen ungültigen Imports machen soll.
- Das ist alles in Ordnung, denn man sagt, dass Bundling immer noch für die Leistung erforderlich ist, und es macht andere Dinge, die wir sowieso wollen, wie die Ausführung von Babel und Co.
Jetzt, wo wir uns mehr auf ESM verlassen können, verschiebt sich die Geschichte etwas, und all diese Dinge werden hinterfragt.
- Was wäre, wenn wir nicht
npm installmachen müssten? - Was wäre, wenn wir keinen Bundler brauchen?
- Was wäre, wenn die Leistung in Ordnung ist, zwischen HTTP/2+, globalen CDNs, Browsern, die schicke Dinge tun, usw.?
- Was wäre, wenn wir vielleicht Code nicht so sehr *kompilieren sollten*, weil wir zu viel heruntermkompilieren?
Wir sehen Werkzeuge der nächsten Generation, die all das nutzen. Snowpack 3 wurde gerade veröffentlicht und schau dir das an
Dieses React (mit JSX), das ganz normal geschrieben ist, und es gab kein npm install, kein node_modules-Verzeichnis und keinen Build-Schritt. Aber immer noch ein Dev-Server und Reload. So leicht. Sehr erfrischend.
Ich habe gerade eine neue Folge von Toolsday gehört, bei der Una und Chris mit Jason Miller über WMR sprachen, von dem ich bis dahin nichts gehört hatte. Es fühlt sich Snowpack/Skypack sehr ähnlich an. Mit WMR kann man npm-Pakete verwenden, ohne sie installieren zu müssen, oder mit Dingen wie JSX, TypeScript oder CSS Modules schreiben und erhält eine Menge Entwicklungskomfort, wie einen Server, Hot Reloading usw.
Hier ist eindeutig etwas in der Luft, und ich glaube, das ist eine Hinwendung zu ESM.
Selbst auf der Node.js-Seite *passiert* ESM. Hier ist Sindre Sorhus, der über 1.000 npm-Pakete hat (!)
Ende April 2021 ist Node.js 10 End-of-Life, was bedeutet, dass Paket-Maintainer Node.js 12 anvisieren können. Diese Node.js-Version hat volle Unterstützung für JavaScript Modules, auch bekannt als ESM.
Er plant, fast alle dieser 1.000 Pakete im Jahr 2021 auf ESM umzustellen. Keine "Dual"-Konfiguration, bei der man verschiedene Formate ausgibt... *nur* ESM, und er ermutigt alle, dasselbe zu tun. Ich denke, diese Dynamik hin zur direkten ESM-Nutzung im Browser spielt eine große Rolle, wenn das npm-Ökosystem genau dasselbe tut.
Und wenn man doch bündeln muss, weil zum Beispiel etwas auf npm noch nicht ESM-ready ist, dann werden die Bundler der nächsten Generation rauchend schnell.
Im Moment mit npm, solange ich die Pakete bereits heruntergeladen habe, spielt es keine Rolle, ob ich mein Projekt ohne Internetzugang ausführen möchte. Cacht ESM lokal irgendwo anders als im Browser, in dem ich entwickle?
CDNs wie Skypack, die diese Pakete bereitstellen, cachen das Paket und halten den Cache länger, je öfter er getroffen wird. Sehr beliebte Bibliotheken wären also extrem, extrem schnell. Oder vielleicht liege ich falsch. Ich weiß es nicht.
Ich fürchte, Sie verwechseln zwei Dinge.
Snowpack oder WMR cachen diese lokal, genau wie NPM/Yarn (vielleicht nicht für andere Projekte geteilt, das weiß ich nicht).
Wenn Sie jedoch
import Foo from "https://…"direkt im Browser ohne ein Tool, das es transformiert, verwenden, findet keine lokale Caching statt.Ich denke, das gilt vielleicht für WMR, aber Skypack ist ein globales CDN für Pakete, bei dem Sie nichts lokal herunterladen, und Snowpack 3 hat "Streaming Imports", die es nutzen. Aus ihrem Blog-Post
Moment, sind die Node-Unterstützung ES-Module nicht auch die gefälschten ES-Module?
Bezüglich Ihrer Frage "Was wäre, wenn wir Code vielleicht nicht so sehr kompilieren sollten" und Ihres letzten Absatzes, verwechseln Sie nicht irgendwie Bündelung mit Transpilierung und/oder Auflösung von Abhängigkeiten?
Es gibt Gründe für Bündelung, die über die Verwendung von Babel/Bublé/was auch immer oder sogar das Importieren mit "bare import specifiers" hinausgehen, Sie können Babel/etc. ohne Bündelung verwenden, und schließlich könnten Sie wahrscheinlich ein Tool haben, das bare import specifiers umschreibt und Dateien verschiebt, ohne etwas anderes aus Ihrem Code zu ändern (z. B. als Workaround für fehlende Import-Map-Unterstützung).
Wir neigen dazu, Bundler für all diese Dinge zu verwenden, aber sie sind nur Schritte in unserer Build-Pipeline, die wir separat oder gar nicht ausführen könnten.