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.
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.
[gr] Wo wäre denn die "Katastrophe", wenn man zu Beginn einer Datei einmal import fetch, { Request, Response } from 'fetch'; schreiben müsste? Dass die Dinge überfällig waren, dagegen sage ich ja gar nichts - ich finde nur die Art, wie sie implementiert wurden, nicht so wahnsinnig geschickt … Was ES6-Module angeht, hast Du leider recht 😞
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!
Ich würde es nicht mal schlimm finden, wenn sinnvolle Features kopiert werden würden. Sowas wie das Berechtigungssystem von Deno z. B. Der Rest wirkt recht undurchdacht und inkonsistent. "node:test"?! Warum nicht den Spieß umdrehen und "npm:test" für externe Module - wäre logischer. Oder wieso greift man für interne Module nicht das scoping von npm auf? So was wie "@node/test". Fragen über Fragen...
[gr] Ja … ich kann ich dem nur anschießen: Fragen über Fragen … und ich habe leider auch keine Antwort darauf. Es wirkt leider wirklich alles in letzter Zeit immer mehr zusammengestückelt und nicht mehr strategisch geplant und durchdacht. Was schade ist 😞
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 😂
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 ? ¯\_(ツ)_/¯
[gr] Danke schön 😊 Was die Transparenz angeht: Also mir ist zumindest nicht bekannt, dass die Gründe irgendwo kommuniziert worden wären, allerdings sind ja viele Sitzungen des TSC auch als Video zu haben, und vermutlich ist das schon transparent, wenn man es denn findet. Aber wie gesagt, genau kann ich es Dir nicht sagen.
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 ;)
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.
[gr] Wobei Deno TypeScript ja auch nicht nativ verarbeiten kann - es kompiliert die Dateien halt nur on-the-fly, bevor es die Dateien ausführt (praktisch so, wie ts-node das auch macht).
@@thenativeweb Ja, aber es kann TS importieren und hat dementsprechend auch Typen. Stelle es mir PITA vor, für HTTPS-Imports Typisierung bereitzustellen. Ist ja nicht builtin
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.
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 =)
[gr] Vielen Dank für Deinen ausführlichen Kommentar - und ja, natürlich ist das in gewissem Sinne jammern auf hohem Niveau: Node.js ist nach wie vor eine schöne und gelungene Plattform. Ich fände es nur traurig, wenn ich das in drei Jahren nicht mehr aus Überzeugung sagen könnte … denn Node.js war vor 11 Jahren für mich durchaus mehr als nur eine neue Technologie, es war ein Aufbruch in eine neue Welt: www.heise.de/hintergrund/Berechtigte-Chancen-fuer-Node-js-als-naechstes-grosses-Ding-1352310.html
@@thenativeweb Dann sind wir ja schon zwei =) An Jammern ist ja auch gar nix schlimmes. Jammern sorgt dafür, dass die Qualität oben bleibt, vorausgesetzt man hört drauf. Mal sehen, wie sich Node.js entwickeln wird. Ich bin jedenfalls positiv gestimmt und freue mich auf eine einheitliche Welt mit eigentlich viel zu vielen globalen Variablen. Oder der Browser wandelt sich und man muss demnächst Packages referenzieren. Das würde die ES6 Syntax der Imports dann endlich auch mal lauffähig machen.
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.
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.
[gr] Ja, das stimmt … das Thema CJS/ESM ist auch so ein Fall für sich … das ist echt nicht gut gelöst, weil es inkompatibel ist, und es genau zu dem geführt hat, was Du sagst - ein zweigeteiltes Ökosystem. Und einige Autor:innen setzen ja inzwischen nur noch ausschließlich auf ESM (zB Sindre Sorhus), was seine Module praktisch unbenutzbar macht, wenn man nicht mit ESM arbeiten kann, weil zB das Tooling damit noch nicht zurecht kommt, was ja gerade im Kontext von TypeScript wiederum nicht so selten ist … Das ist alles ein ziemlicher Murks.
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.
@@thenativeweb Laufzeit Umgebungen wie deno, Web-Browser oder SpiderMonkey. Das fs-modul ist Altlast... Sollten die nächsten internen Standard-Module dem prefix folgen, werden fs und co. früher oder später nach "node:..." verschoben. Deno hat mit dem std/ namespace auch eine gute Trennung von hauseigenen Bibliotheken hinbekommen... Warum node.js jetzt den Doppelpunkt gewählt hat ist mir noch schleierhaft... Ich mutmaße mal: ein Invalides Protokoll hat weniger fuckup Potenzial. Z.b. bei alias Management muss man schon explizit Protokolle Mappen, bei Pfad ähnlichen mappings ist eine unbeabsichtigte Konfiguration schon wahrscheinlicher.
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.
@@sven2529 Immer dieses PHP bashing :-) , aber komm doch bitte nicht mit Nodejs ist schnell und einfach zu schreiben. Eine Alternative die durch "Einfachheit" und "Leichtigkeit" mir aufgefallen ist und dazu noch eine Performance bringt wo du Nodejs und PHP in die Tonne hauen kannst, ist Go und als Nodejs Entwickler wirst du dich relative schnell an die Sprache gewöhnen. Die Standard Library ist ziemlich umfassend.
@@sven2529 Diese Einstellung "Hauptsache schnell, schnell", ist mit einer der Hauptgründe warum ich die Node-Szene nicht mag. Schnell, schnell was zurecht gefrickelt. Das war schon bei PHP früher Mist, welches Du ja so gerne bashst. Lieber ein paar Handgriffe mehr und dann was ordentliches, als irgendein schwer nachzuvollziehendes Gefrickel voller Inkonsistenzen und fern jeglicher empfohlenen Entwicklungsstandards. Ich empfehle mal im Jahr 2022 anzukommen und den Videos hier auf dem Kanal mehr Aufmerksamkeit zu schenken. Go wurde hier gerade erst in den letzten zwei Wochen als eine leichtgewichtige Alternative erklärt. Und ja, für PHP muss man erstmal einen Server installieren. Aber gerade für kleine Entwickler ist es wesentlich einfacher Mal eben bei irgendeinem Host einen PHP-Webspace zu buchen und sein Projekt drauf zu schmeißen, als sich irgendwas mit Node zurecht zu frickeln. Ein komplett eigener Server ist häufig gar nicht nötig. Und wenn man dann doch unbedingt was komplett eigenes machen will, hat man dann sowieso so viel Administrationsaufwand, dass die Installation von einem Apache, Nginx oder was auch immer den Bock auch nicht mehr fett macht.
Hervorragendes Review der neuen Node-Version! Danke an dieser Stelle an all eure wirklich ausgezeichneten Videos! Bereichert mich jedes mal!
[gr] Vielen lieben Dank 😊
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.
Super Review! Danke! Ich stimme deinen Punkten, besonders bzgl.der Inkonsistenz, voll zu.
[gr] Danke schön 😊
Sehr interessanter Beitrag. Vielen Dank.
[gr] Vielen Dank 😊
Tolles Review! Hinterlässt bei mir aber auch ein eher gemischten Eindruck.
[gr] Danke schön 😊
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.
[gr] Wo wäre denn die "Katastrophe", wenn man zu Beginn einer Datei einmal
import fetch, { Request, Response } from 'fetch';
schreiben müsste? Dass die Dinge überfällig waren, dagegen sage ich ja gar nichts - ich finde nur die Art, wie sie implementiert wurden, nicht so wahnsinnig geschickt …
Was ES6-Module angeht, hast Du leider recht 😞
Ahhh, dieses eine Haar, das da hängt. Can't be unseen :)
[gr] Haha 😂
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!
[gr] Danke für Deinen Kommentar 😊
Ich würde es nicht mal schlimm finden, wenn sinnvolle Features kopiert werden würden. Sowas wie das Berechtigungssystem von Deno z. B. Der Rest wirkt recht undurchdacht und inkonsistent. "node:test"?! Warum nicht den Spieß umdrehen und "npm:test" für externe Module - wäre logischer. Oder wieso greift man für interne Module nicht das scoping von npm auf? So was wie "@node/test". Fragen über Fragen...
[gr] Ja … ich kann ich dem nur anschießen: Fragen über Fragen … und ich habe leider auch keine Antwort darauf. Es wirkt leider wirklich alles in letzter Zeit immer mehr zusammengestückelt und nicht mehr strategisch geplant und durchdacht. Was schade ist 😞
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 😂
[gr] Haha 😂
da hast du so recht
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 ? ¯\_(ツ)_/¯
[gr] Danke schön 😊
Was die Transparenz angeht: Also mir ist zumindest nicht bekannt, dass die Gründe irgendwo kommuniziert worden wären, allerdings sind ja viele Sitzungen des TSC auch als Video zu haben, und vermutlich ist das schon transparent, wenn man es denn findet. Aber wie gesagt, genau kann ich es Dir nicht sagen.
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 ;)
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.
[gr] Wobei Deno TypeScript ja auch nicht nativ verarbeiten kann - es kompiliert die Dateien halt nur on-the-fly, bevor es die Dateien ausführt (praktisch so, wie ts-node das auch macht).
@@thenativeweb Ja, aber es kann TS importieren und hat dementsprechend auch Typen. Stelle es mir PITA vor, für HTTPS-Imports Typisierung bereitzustellen. Ist ja nicht builtin
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.
[gr] Danke für Dein Feedback 😊
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 =)
[gr] Vielen Dank für Deinen ausführlichen Kommentar - und ja, natürlich ist das in gewissem Sinne jammern auf hohem Niveau: Node.js ist nach wie vor eine schöne und gelungene Plattform. Ich fände es nur traurig, wenn ich das in drei Jahren nicht mehr aus Überzeugung sagen könnte … denn Node.js war vor 11 Jahren für mich durchaus mehr als nur eine neue Technologie, es war ein Aufbruch in eine neue Welt: www.heise.de/hintergrund/Berechtigte-Chancen-fuer-Node-js-als-naechstes-grosses-Ding-1352310.html
@@thenativeweb Dann sind wir ja schon zwei =) An Jammern ist ja auch gar nix schlimmes. Jammern sorgt dafür, dass die Qualität oben bleibt, vorausgesetzt man hört drauf. Mal sehen, wie sich Node.js entwickeln wird. Ich bin jedenfalls positiv gestimmt und freue mich auf eine einheitliche Welt mit eigentlich viel zu vielen globalen Variablen. Oder der Browser wandelt sich und man muss demnächst Packages referenzieren. Das würde die ES6 Syntax der Imports dann endlich auch mal lauffähig machen.
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.
[gr] Clickbait war es so oder so nicht 😉
Aber ja, eine gewisse Unzufriedenheit mit den aktuellen Entwicklungen lässt sich nicht leugnen.
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.
[gr] Ja, das stimmt … das Thema CJS/ESM ist auch so ein Fall für sich … das ist echt nicht gut gelöst, weil es inkompatibel ist, und es genau zu dem geführt hat, was Du sagst - ein zweigeteiltes Ökosystem.
Und einige Autor:innen setzen ja inzwischen nur noch ausschließlich auf ESM (zB Sindre Sorhus), was seine Module praktisch unbenutzbar macht, wenn man nicht mit ESM arbeiten kann, weil zB das Tooling damit noch nicht zurecht kommt, was ja gerade im Kontext von TypeScript wiederum nicht so selten ist …
Das ist alles ein ziemlicher Murks.
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.
[gr] Welche anderen Umgebungen meinst Du denn? Und wo ist der Unterschied zwischen dem test- und beispielsweise dem fs-Modul?
@@thenativeweb Laufzeit Umgebungen wie deno, Web-Browser oder SpiderMonkey.
Das fs-modul ist Altlast... Sollten die nächsten internen Standard-Module dem prefix folgen, werden fs und co. früher oder später nach "node:..." verschoben.
Deno hat mit dem std/ namespace auch eine gute Trennung von hauseigenen Bibliotheken hinbekommen... Warum node.js jetzt den Doppelpunkt gewählt hat ist mir noch schleierhaft...
Ich mutmaße mal: ein Invalides Protokoll hat weniger fuckup Potenzial.
Z.b. bei alias Management muss man schon explizit Protokolle Mappen, bei Pfad ähnlichen mappings ist eine unbeabsichtigte Konfiguration schon wahrscheinlicher.
Und es hat begonnen: in node 18.1.0 wurde die Dokumentation für alle Core-Module mit 'node:'-Präfix aktualisiert.
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.
@@sven2529 Immer dieses PHP bashing :-) , aber komm doch bitte nicht mit Nodejs ist schnell und einfach zu schreiben. Eine Alternative die durch "Einfachheit" und "Leichtigkeit" mir aufgefallen ist und dazu noch eine Performance bringt wo du Nodejs und PHP in die Tonne hauen kannst, ist Go und als Nodejs Entwickler wirst du dich relative schnell an die Sprache gewöhnen. Die Standard Library ist ziemlich umfassend.
@@sven2529 Was ist schwergewichtig an Spring Boot oder Quarkus?
@@sven2529 Diese Einstellung "Hauptsache schnell, schnell", ist mit einer der Hauptgründe warum ich die Node-Szene nicht mag. Schnell, schnell was zurecht gefrickelt. Das war schon bei PHP früher Mist, welches Du ja so gerne bashst. Lieber ein paar Handgriffe mehr und dann was ordentliches, als irgendein schwer nachzuvollziehendes Gefrickel voller Inkonsistenzen und fern jeglicher empfohlenen Entwicklungsstandards. Ich empfehle mal im Jahr 2022 anzukommen und den Videos hier auf dem Kanal mehr Aufmerksamkeit zu schenken. Go wurde hier gerade erst in den letzten zwei Wochen als eine leichtgewichtige Alternative erklärt. Und ja, für PHP muss man erstmal einen Server installieren. Aber gerade für kleine Entwickler ist es wesentlich einfacher Mal eben bei irgendeinem Host einen PHP-Webspace zu buchen und sein Projekt drauf zu schmeißen, als sich irgendwas mit Node zurecht zu frickeln. Ein komplett eigener Server ist häufig gar nicht nötig. Und wenn man dann doch unbedingt was komplett eigenes machen will, hat man dann sowieso so viel Administrationsaufwand, dass die Installation von einem Apache, Nginx oder was auch immer den Bock auch nicht mehr fett macht.
Node ist schneller 18 geworden als ich... ich könnte kotzen!
[gr] Haha 🤣
Deno > Node.js
[gr] Weil …? 😉