Node.js 18: Der Anfang vom Ende?! // deutsch

00:00 – Einleitung
00:46 – Die Fetch-API
03:00 – WebStreams statt Streams
05:03 – Der globale Namensraum
08:57 – Ein integriertes Test-Framework
11:03 – Ausnahmen beim Laden von Modulen
13:39 – JSON Import Assertions und HTTPS-Imports
16:06 – Stimmt die eingeschlagene Richtung?

────────────────────

Über the native web 🦄

Wir sind ein Beratungs-, Schulungs- und Entwicklungsunternehmen, das sich auf Web- und Cloud-Technologien spezialisiert hat. Wir streben nach intelligenten und eleganten Lösungen für komplexe Probleme, und wir glauben, dass Softwareentwicklung kein Selbstzweck ist. Stattdessen sollte Software tatsächliche Probleme der realen Welt lösen.

Wir glauben, dass native Web- und Cloud-Technologien das Fundament sind, auf dem die Zukunft aufbaut. Unsere Kernkompetenz ist der Entwurf und die Entwicklung verteilter Web- und Cloud-Anwendungen unter Verwendung dieser Technologien in interdisziplinären Teams. Wir entwickeln auch unser eigenes Open-Source-Framework namens wolkenkit. Und wir lieben es, unser Wissen in Schulungen und Workshops, auf Konferenzen und bei Usergroups zu teilen.

────────────────────

Weiterführende Links 🌍

[sebastianhildebrandt]

Hervorragendes Review der neuen Node-Version! Danke an dieser Stelle an all eure wirklich ausgezeichneten Videos! Bereichert mich jedes mal!

[SimonJentzschX]

Sehr gute Zusammenfassung. Nur mit dem Satz, daß "99% des Codes der für node.js bzw. für den browser geschrieben wurde, nicht auf der anderen Platform ausgeführt wird" habe ich meine Probleme. Das stimmt für die Applikation natürlich, aber viele Bibliotheken werden durchaus auf beiden Platformen genutzt.

[yahmk]

Sehr interessanter Beitrag. Vielen Dank.

[SpliffSplendor]

Super Review! Danke! Ich stimme deinen Punkten, besonders bzgl.der Inkonsistenz, voll zu.

[dCoder]

Die genannten Features, die neu hinzugekommen sind, sind meiner Meinung nach aber auch dringendst notwendig gewesen (Deno ist da in vielen Punkten einfach viel "weiter").
Der Teil mit der FetchApi war vorher eine Katastrophe mit dem extra Package.

Gefühlt hat es auch eine Ewigkeit gedauert, bis die ES6 imports richtig in Node angekommen sind. 3/4 der Dokus zeigen immer noch require.
Wenn ich einen Punkt an JavaScript hasse, dann ist es legacy code.

[SuperDuperDevelopersClub]

Ahhh, dieses eine Haar, das da hängt. Can't be unseen :)

[marinaegner]

Tolles Review! Hinterlässt bei mir aber auch ein eher gemischten Eindruck.

[zuimelanieforno]

Moin aus Hamburg. Was ist denn Node.js? Wozu und Überhaupt?
Ich kann das gut nachvollziehen, wenn Konsolidiert wird und dann wieder ausgeschehrt wird...
Das hat Sven mit PHP schon gut auf den Punkt gebracht.
Da wird ein Feature so stark gewichtet, das es den Anschein hat, als gebe es nur noch diese Art der Umsetzung.
Als ich zum erstenmal den Begriff "Treeshaking" gehört habe war es um mich geschehen und musste mir vor dem Senior das Lachen verkneifen...
Ich komme aus dem ".NET-Land" und nicht aus dem "User-Land", dort ist die Konsolidierung jetzt Faktisch gegeben. Alles läuft zusammen in ".NET nn". Gerade Zahlen sind LTS-Versionen.
Aktuell ist es die Version ".NET 6" die erste Ihrer Art. Um das Implementieren sicher zu stellen, gibt es vom hersteller Tools, die die "alte Codebase" analysiert und eine gute, aussagekräftigen Bericht gibt, ob es sich Lohnt umzustellen.
Die .NETerInnen proklamieren nicht umzusteigen wenn es nicht muss, weil sich der aufwand vielleicht nicht lohnt. (Never Change a not fully Running System)

Danke für das Video. Daumen an den Monitro geklebt und dann gescrollt... verda...mter Button bleibst du da jetzt... So! Gelicked äääh geliked!

[AlexanderRedmann]

Hmm, Code Remote nachladen, dass das keine so gute Idee ist hatten wir ja erst vor kurzem im Java Umfeld gemerkt. Aber gut wer beachtet schon Geschichte, man könnte ja was draus lernen...
Aber gerade gleicht sich ja alles an. Java fühlt sich immer mehr wir Javascript an und Javascript mit Typenscript geht in Richtung Java. Warum sollten man dann nicht auch die Bugs mit übernehmen, das macht dann die Umstellung einfacher 😂

[IonizedSun]

Vielen Dank für den Beitrag. Ich nutze Node.js im privatem Umfeld, daher sind die beschriebenen "Probleme" für mich nicht so tragisch. Wurde denn propagiert, warum man die entsprechenden Entscheidungen getroffen hat ? Oder ist das intransparent ?
Erst letzte Woche habe ich mich mit fetch herumgeschlagen (experimental funktionierte nicht - aus was für Gründen auch immer), da ist eine Implemtierung durchaus wünschenswert.
Warum man node-fetch nicht integriert hat ? ¯\_(ツ)_/¯

[veitkunz]

Naja, dass die fetch-APi mit allem drum und dran global verfügbar ist, liegt ja an der Cross-Kompatibilität von Librarys. Wenn ich eine JavaScript-Library entwicklet, die sowohl in Node, als auch im Browser laufen soll (wo von es einige gibt), macht es den Library-Code so deutlich übersichtlicher. Am Ende ist es eine Abwägung zwischen verschiedenen Anforderungen, also ganz so einfach, wie du es darstellst, ist es am Ende nicht.
Und da das "test"-Modul stabil 30.000 Downloads pro Woche hat, würde ich es jetzt nicht unbedingt als "kaum verwendet" bezeichnen ;)

[chk]

Danke für das kritische Video. Kann den einen oder anderen Punkt durchaus nachvollziehen.
Du kannst ja mal Matteo Collina z.B. zu einem Diskussions Video einladen 😉 Er beantwortet die Fragen sicherlich gerne.

[_nikeee]

Hm, mit HTTP-Imports könnte das problematisch mit TypeScript-Typen werden. Deno kann ja TS importieren, aber Node ja nicht.

Dass beim Test-Modul das Protokoll Pflicht ist, wird sicher der erste Schritt sein, dass irgendwann immer ein Protokoll davor stehen muss, wenn es nicht auf dem Dateisystem liegt.

[yt]

Jetzt bekommt der Titel eures Videos "Wir canceln Javascript? Let"s Go!" ja einen ganz neuen Sinn. War gar kein Clickbait, sondern eine Konsequenz aus der weiteren Node Entwicklung. 🙂
Grundsätzlich wäre es wohl günstig einen eigenen "node:" Namensraum zu schaffen um Konflikte in Zukunft zu vermeiden. Das sollte aber in der Tat konsistent durchgezogen werden. Es scheint aber so zu sein, dass Deno doch mehr Druck macht als gedacht und die Entwicklung bestimmt. Da lügen die vielen Stars wohl doch nicht und die Verbreitung ist schon größer als gedacht.

[DJTechnostyler]

Eine gesunde Skepsis hat noch nie geschadet. Ich sehe die Entwicklungen aber nicht ganz so kritisch wie du. Der globale Namensraum ist im Browser ja auch schon ziemlich voll und mich hat es ehrlich gesagt nie gestört. Zugegeben: request, response und co werden auf der Serverseite deutlich häufiger genutzt, aber auch das kann man umgehen, indem man einfach global.Response schreibt. Auf kurz oder lang wird sich das einpendeln, aber so wirklich kaputt geht ja erst mal nix. Was ich allerdings extrem kritisch finde ist die Tatsache, dass man Abhängigkeiten aus dem Netz laden kann. Damit öffnet man vieren Tür und Tor. Ich hoffe Node schiebt da irgendwie einen Riegel vor, sodass man das Laden solcher Abhängigkeiten auch verhindern kann. Das mit dem inkonsistenten Import finde ich jetzt auch nicht so prickelnd. Aber ich kann mir auch vorstellen, dass das in der nächsten Version dann wieder angeglichen wird. Die Streams finde ich nicht so schlimm. Je mehr Kompatibilität zum Browser, desto besser ist das für mein kleines Projekt, bei dem ich ein "Framework" schreibe, dass man sowohl auf dem Server als auch im Browser nutzen kann, mit dem man dann MVC abbildet. Ansonsten bin ich aber mit Node weiterhin sehr zufrieden =)

[BenjaminWagener]

Ich hatte schon immer wenig Interesse daran mit Node zu arbeiten. Es wirkte alles einfach immer zu frickelig und planlos. Zu viele Änderungen in zu kurzer Zeit, die unkontrollierte Modulhölle mit all ihren Skandalen und jetzt kommt diese Inkonsistenz oben drauf die wieder maximal undurchdacht wirkt. Hauptsache neue Funktionen, soll der Nutzer zusehen wie er damit zurecht kommt. Danke, aber nein Danke. Ich bin sehr froh, dass es genug Alternativen zu node gibt.

[tobiasnickel]

die letzten Jahre wird node richtig gegen den baum gefahren. die sollteb das import statement und die require function einfach kompatibel machen, und default export ist auch scheisse. und was soll der dreck mit "type":"module", damit wurde das gesamte ecosystem in zwei geteilt. neu und alt. es ist nicht sauber moeglich ein modul zu machen das gut fuer alte und neue node versionen funktioniert.

[jodufan]

Node ist schneller 18 geworden als ich... ich könnte kotzen!

[Sourcerr]

Das in der Version 18 integrierte Modul "node:test" ergibt schon Sinn: wenn der Import in andern Umgebungen geladen wird, ist die node-spezifische Implementierung nicht gewährleistet.

Das es bereits ein Modul auf npm gibt, ist eher zweitrangig.