Was mich bei Dir immer wieder fasziniert... 24 min Video und nicht ein Schnitt und das Thema flüssig themaitisieren. Rhetorisch eine Meisterleistung wie ich finde. Inhaltlich ja sowieso
fällt mir auch immer auf, einfach der Burner. 🔥 Ich könnte nicht mal so schnell denken wie er struktiert und nachvollziehbar die Themen auseinanderpflückt. :D
Genau diese Inkompatibilitäten in node (fetch api, integrierter Test runner, und vor allem cjs - esm Probleme beim tooling (z.B mit jest) machen für mich die Arbeit mit Deno so angenehm. Und , dass deno eine einzige exe ist! Es ist selbst heute immer noch kompliziert, eine Portable Version von Node aufzusetzen, bei deno muss ich nur die exe runterladen und in den Pfad eintragen. Und Updates kann ich einfach via deno Upgrade installieren! 😍
Danke für das Video. Um das ganze beurteilen zu können müsste man wissen was im Hintergrund passiert und was die Gründe für die Entwicklung von Deno und Bun sind. Ich könnte mir schon vorstellen, dass es eine große Unzufriedenheit mit Node gab und diese zu unflexibel waren darauf zu reagieren. Am Ende wird sich zeigen ob die großen Player auf den Zug aufspringen und wohin die Reise geht.
Wie immer ein fachlich ausserordentlich gutes Video. Allerdings finde ich die Einstellung "die anderen haben Unruhe reingebracht" schwierig. Einerseits steht es jedem frei, eine eigene Entwicklung zu starten. Daran wäre nur dann etwas zu kritisieren, wenn dies mit der Absicht passiert, "dem anderen" zu schaden. Andererseits sehe ich das mit unterschiedlichen Laufzeitumgebungen ähnlich wie mit einer Framework-Entscheidung zwischen Symfony und Laravel oder bspw. der Entscheidung, ob ich ein WPF-Programm oder WinForms-Projekt starte. Ich muss dann damit leben. Genauso schwierig dürfte es sein, meine C++ Entwicklungsumgebung ohne Probleme unter Linux zu betreiben, wenn ich die Tools betrachte.
[gr] Leider weiß ich nicht, auf welchem System Du unterwegs bist. Aber bei mir auf iOS ist es zum Beispiel so, dass die Infokarten nur in der TH-cam-App angezeigt werden, nicht in der webbasierten Variante. Und wie Henning in dem anderen Kommentar ja schrieb, gibt es bei Android auch ein paar Besonderheiten …
Spannend, deine Kritik an Bun und Deno ist also im Grunde genommen, ihre Wirkung auf Node und die Unfähigkeit der dahinter stehenden Community, angemessen auf diese neue disruptive Entwicklung zu reagieren?!? Ich teile die Kritik, dass der native TS Support in Bun Makulatur ist. Aber den beiden Projekten vorzuwerfen, sie würden Node vor sich her treiben und zur Fragmentierung des Ökosystems führen, teile ich nicht. Dann müsste man auch KDE/Gnome/I3 etc für die Fragmentierung des Linux Desktops verantwortlich machen. Vielmehr erinnert mich die Situation an OpenOffice/LibreOffice oder OpenSSL/LibreSSL. Die Community hinter dem etablierten System ist vielleicht einfach zu satt, teils arrogant. Die Diskussion um die unterschiedlichen Release Zyklen von Node und ESlint ist da das beste Beispiel. Ja es wird deswegen zur Fragmentierung kommen. Ja vielleicht ist das der Tod von Node, so wie wir es heute kennen. Muss das etwas Schlechtes sein? Nicht unbedingt. Etwas Disruption tut in der SW Entwicklung imho ab und zu ganz gut. Ideal wäre natürlich, wenn aus den verschiedenen Strömungen am Ende wieder ein gemeinsamer Konsens hervorgeht. Aber auch dafür gibt es ja Beispiele in der Vergangenheit. Was Node aus meiner Sicht jetzt gut stehen würde, wäre durchaus Anregungen/Konzepte der anderen beiden zu übernehmen, sie dann aber auch konsequent und mit eigenen Konzepten umzusetzen. Dieses Trauerspiel bei CommonJS vs ESM. Wozu gibt es denn Major Versionen?
[gr] Meine Kritik an Bun und Deno ist im Grunde genommen, dass sie - ohne Not - Inkompatibilitäten einführen, die dazu führen, dass es für alle schwieriger wird, JavaScript auf dem Server auszuführen. Sei es, weil Code auf Node entwickelt wird und auf Deno nicht läuft, sei es, weil Modul X nur für Deno verfügbar ist und nicht für Node, sei es, weil das Publishen von Modulen auf einmal doppelt so viel Aufwand ist wie vorher, und so weiter … Natürlich belebt Konkurrenz das Geschäft, wie es so schön heißt, und das letzte, was ich wollen würde, ist ein Monopol von welcher Technologie auch immer. Aber ganz bewusst mit (Quasi-)Standards zu brechen, und das dann anzupreisen als vermeintlich längst überfällige Revolution, das hat weniger mit gesunder Konkurrenz, sondern eher mit anderen Dinge zu tun … Wo ist denn der ach so große Benefit von Deno? Dass Promises unterstützt werden? Dass der TypeScript-Compiler zur Laufzeit in-memory davorgeschaltet wird? Dass auf npm verzichtet wird? …? Das alles waren Argumente von Ryan Dahl, warum er Deno entwickelt hat - zu einem Zeitpunkt, wo es Promises in Node schon gab. Zu einem Zeitpunkt, wo es ts-node schon seit Jahren gab. Zu einem Zeitpunkt, wo Dich niemand gezwungen hat, npm zu nutzen. Ja, Deno bietet Dinge, die Node nicht hat: Das wichtigste dürfte die Sandbox sein, das zweite die Integration von Tools wie Linting, Formatting & Co. Darüber hinaus wird es aber schon sehr dünn. Ob das dann den Bruch mit einem bestehenden Ökosystem rechtfertigt und langfristig so viel nützt, dass es den ganzen Rattenschwanz an Problemen, die es mit sich bringt, aufwiegt, wage ich persönlich zu bezweifeln, aber da muss sich jede:r ihre/seine eigene Meinung bilden. Und auffällig ist nun eben, dass Bun mit genau der gleichen Taktik vermarktet wird, Probleme zu benennen, wo keine sind, beziehungsweise Dinge zu versprechen, die nicht gehalten werden, wie zB der Pseudo-TypeScript-Unterstützung, die ja nun wirklich eher Augenwischerei ist. Aber warten wir es ab, wie sich der Markt entwickelt, etwas anderes bleibt uns am Ende ohnehin nicht übrig.
@@thenativeweb Hi Golo, danke dass du noch mal detailliert auf meine Punkte eingegangen bist. Ich denke, wir sind uns prinzipiell einig. Wir haben aber in einer Hinsicht wohl unterschiedliche Auffassungen. Du betrachtest das JavaScript Ökosystem wohl eher als ein einheitliches. Aus meiner Erfahrung heraus, auch von anderen Plattformen, ist das so nicht wirklich möglich. Wenn ich zum Beispiel nach PHP schaue, auch da kann ich Symfony und Laravel oder Laminas nicht nach Belieben mischen. Klar, Runtime und Framework sind jetzt nicht dasselbe, aber ich denke immer, es gibt nicht den PHP Entwickler oder den JavaScript-Entwickler. Normalerweise spezialisiert man sich ja auf eine Plattform oder dort auf ein Set an Frameworks und Libs. Ich würde Bun/Deno eher als alternative Runtimes, wie ReactPHP oder Swoole verstehen. Sie teilen sich die Plattform und erfüllen zu einem gewissen Grad denselben Zweck, aber haben eben doch ihre Eigenheiten. Auch bei der JVM gibt es ja verschiedene Implementierungen, wenngleich sich da viel konsolidiert hat. Und seien wir mal ehrlich, das Modulsystem, bzw. das eben das Fehlen eines standardisierten solchen, hat bei JavaScript schon immer dazu geführt, dass Libs gleich mit einem Set davon um die Ecke kamen (meist CommonJS und AMD, später noch ESM). Die Situation ist ja nicht neu. Dazu dann noch neben NPM die Alternativen wie Yarn und PNPM. Also die Fragmentierung ist real und das JS Ökosystem wohl das dynamischste und disruptivste im Markt, weshalb ich es auch nicht mag. Für Leute, die OSS in dem Bereich betreuen, ist das natürlich unglücklich. Aber vielleicht kommt es ja doch noch zur Konsolidierung und am Ende steht eine Runtime, die heute noch gar nicht existiert. Bis dann wieder jemand etwas daran auszusetzen hat und sein eigenes Ding startet. 😁 Ich meine, TypeScript existiert ja auch nur, weil erst einige Google und später Microsoft Entwickler mit dem Typensystem von JavaScript nicht zufrieden waren. VG
Gutes Video! Ich bin hin- und hergerissen ob ich diese Zersplitterungen wie bei den JS-Plattformen, Linux Distros, Browser Engines, usw...., jetzt gut oder schlecht finden soll.
[gr] Es freut mich, dass Du schreibst, dass wir das nicht nötig hätten - dem stimme ich prinzipiell zu. Aber es gibt einen Grund, warum wir es (leider) trotzdem machen (müssen), zumindest in gewissem Sinne - dazu haben wir schon mal ein Video gemacht, wo ich das etwas ausführlicher erkläre, warum wir von relativ nüchternen, sachlichen Titeln auf die etwas reißerischen umgestiegen sind … vielleicht kann es das ein bisschen nachvollziehbar(er) machen: th-cam.com/video/1HZs2hWJNhU/w-d-xo.html
@@thenativeweb Das Video, auf welches du verweist, kenne ich. Ich möchte an dieser Stelle betonen, dass ich deine Videos nicht wegen, sondern trotz manch schrecklicher Titel schaue. Das tue ich, weil ich die inhaltliche Qualität deiner Videos schätze. Normalerweise mache ich einen großen Bogen um Videos mit solch reißerischen Titeln, weil oftmals nur heiße Luft dahinter steckt. Ob deine Entscheidung die Richtige ist, weiß ich nicht. Mir kommt dabei jedenfalls folgender Spruch in den Sinn: "Die Geister, die ich rief ..." Ich hoffe, du verstehst, worauf ich hinaus möchte.
[gr] Danke schön 😊 Und was die Fragmentierung angeht, bin ich sehr gespannt … IMHO werden sich Node und Deno immer weiter aneinander annähern (und Deno dann überflüssig werden), und für Bun sehe ich persönlich zumindest derzeit eigentlich keinen nennenswerten Raum. Das ist aber nur meine persönliche, subjektive Meinung.
Hallo Beno, vielen Dank für so ein schönes Video! Ich programmiere kaum mit Javascript. Mit Java gar nicht. Doch dir höre ich gerne zu. Und heute ging zwar um Frameworks zu Java, jedoch wenig um Java, sonder mehr, wie es nicht einfach ist, Menschen zusammen zu bringen. Viele stellen für sich fest, nicht mehr mit anderen mehr zusammen an einem Produkt arbeiten zu wollen. An sich - eing ganz normaler Vorgang. Irgendwann gehen auch deine Mitarbeiter weiter, auch sogar wenn sie woanders auch nicht unbedingt was besseres finden werden. So sind eben Menschen. Das sind unsere Fluch und Segen gleichzeitig.Und rational zu denken - ist auch nicht die Stärke von Menschen. Aber. Du hast alles auf den Punkt gebracht. Mal sehen, wann deine Prophezeiung wahr wird. Denn, ob - das Frage ich mich schon nicht mehr. Das ist offensichtlich. Nochmals danke!
Ich hätte, wenn überhaupt eher eine Laufzeitumgebung, welche direkt und ausschliesslich (strict) Typescript macht, und zwar ohne den (internen) umweg über Javascript. Ich kann mir gut vorstellen, dass aufgrund des statischen Typesystems deutlich performanterer Code dabei herumkommen könnte, als wenn die Laufzeitumgebung wieder nur live testen muss, was das aktuell für Typen sind. An sonsten sehe ich das Problem der Zersplitterung von Serverseitigem Javascript nicht soo schlimm, da im Fall von Serverseitig nur der Entwickler selbst entscheidet, auf welcher Umgebung der Code läuft und nicht der Benutzer (wie im Fall von Webseiten, die auf unterschiedlichsten Geräten laufen müssen) Im Besten Fall wird ein Paket eh als Docker (oder Ähnlich) gebaut und dann ist man von den (parallel) installierten Paketen auf dem Server unabhängig.
@@rumpeldrump Ja, ich habe verstanden, was Typesctipt ist, ich bin seit 20 Jahren Professioneller Softwareentwickler und im Falle von Typescript seit der Beta dabei. Ich habe auch nicht gesagt, dass ich Javascript schlecht finde, ich meine nur, dass man Typescript auch direkt mit allen Vorteilen in einer Laufzeitumgebung ausführen könnte, ohne dass man erst nach Javascript übersetzt. Das wäre in dem Fall eine komplett neue Laufzeitumgebung, nicht V8 oder Javascript Core.
@@dattitoo Das ist so pauschal schlicht nicht wahr, weil man eben einen JIT-Compiler integrieren könnte der TS direkt ausführt, anstatt ihn erst über den Umweg auszuführen.
Ich kann deine Kritik verstehen. "Zersplitterung" der Javascript-Community in Node-, Bun- und Deno-"Lager" wäre wirklich kontraproduktiv. Bin gespannt was aus diesen Projekten wird.
Mir wärs lieber wenn wir bei node bleiben, das kann ich inzwischen ein bisschen. Müsste ich eine kompexle Anwendung für den Server bauen würde ich bei node bleiben. Aber wenn es nur darum geht, zb. für eine nextjs App Seiten auf dem Server zu rendern wäre mir die Umgebung vermutlich egal. Mehr als doppelt so schnelles rendering ist schon eine Nummer
Wo wird denn bitte die Community gesplittet?! Jede Runtime wird immer ihre Macken haben und ihre Fanboys die es für wichtiger halten sich darüber zu streiten was nun besser ist als zu evaluieren welche Runtime für welches Projekt zutreffen und sich besser eignen. Wer immer auf das gleiche Pferd setzt wird nie etwas gewinnen. Die Frage die man sich beispielsweise stellen muss: Brauche ich eine schnellere Runtime für meinen Anwendungsfall? Ein Beispiel: Nehmen wir an ich benutze Node um etwas zu builden in einem docker-container und das ganze brauch 5 Minuten, ja so what dann geh ich mir halt noch schnell nen Kaffee holen. Hab ich aber ein schon bestehendes Projekt und auf einmal kommt ne Story bei der ich Templating-Performance brauche wie bei PHP, dann kann ich ja nicht meine ganze Codebase umbauen. Ergo kommt dann bspw. Bun wie gerufen und ich würde mir langfristig Gedanken machen ob ich noch lieber auf PHP oder Rust umsteige. Es kommt immer auf den Anwendungsfall und die Gegebenheiten an, woran man letztendlich wählt was man benutzt und nicht auf die "potentielle Gefahr der Zersplitterung der Community". Wenn man dann keine Alternativen hat und es nicht zu einer Entwicklung kommt sieht man ganz schön alt aus. Auch wenn Deno nicht entwickelt worden wäre hatte Node immer noch die gleichen Probleme. Es ist wie in dem Peter-Fox Song: "Wenn's dir nicht gefällt, mach neu", Wasserfall ist out und Rückschrittlich, zumindest for now und wir können glücklich sein dass nicht alle am "Alten" festhalten sondern sich fragen was man noch besser machen kann.
Ich kann deiner Wahrnehmung nur zustimmen. Manche "new kids on the block" machen in einer Gesamtbetrachtung des technischen Umfeldes nur wenig oder gar nichts besser.
Was die Nutzung des esbuild (oder swc) Ansatz angeht halte ich das gar nicht für einen so falschen Ansatz. ich würde sogar einen Schritt weiter gehen: Ich unterstütze die Erweiterung des ECMAscript Standards um eine standardisierte Typsyntax. Man würde dann gar keinen Transpiler mehr benötigen. Der Typescript-Compiler wäre dann lediglich ein Typechecker. Grundsätzlich finde ich verschiedene Implementierungen und Variation sinnvoll - auf diese Weise entsteht Konkurrenz und Wettbewerb. Was wir uns wünschen ist Fortschritt und nicht Stagnation. Ohne “Ausreißer” mit welchen neue Ideen probiert werden bleibt eben leider vieles auf den festgetretenen Pfaden. Gute Ideen können natürlich übernommen werden. Insofern zweifle ich an Deiner Theorie, dass Deno oder Bun wirklich schädlich ist.
naja ... ein problem mit Pluralismus geht halt auch schnell Richtung antidemokratischem denken und wo bleibt dann der open source Gedanke... wenn der Entwickler von node mit deno einen Neustart versucht, hat das wohl einen Grund und andere bzw neue Ansätze probieren ist gut! sehr sogar! das erzeugt diversität und die fragmentierung entsteht ja schon innerhalb node, also was solls... node braucht sich nicht unter druck gesetzt fühlen und könnte "neue" features (wie zb fetch) auch "einfach" vernünftig implementieren. dann halt eine version später. deshalb werden jetzt nicht alle zu deno/bun rennen. hätte node überhaupt etwas getan, um das und andere Themen in angriff zu nehmen, oder sich Enterprise-artig zurückgelehnt und sich zufrieden gegeben? ich denke nicht. leider. deshalb ist ein gewisses maß an Konkurrenz gut. es liegt bei node, deno und bun unwichtig zu machen - aber bitte nicht via "wir haben mehr addons auf npm"; das müffelt ein bisschen nach Schw...vergleich und wäre peinlich.
6:20 Hui… das klingt ja fast so als ob ihr euch wünscht, dass Google endlich mit Chrome den einzigen Webbrowser anbietet. Die Implementierungsvielfalt der Webbrowser war keineswegs “das größte Problem von Javascript”. Es war der fehlende, ständig gepflegte und weiterentwickelte Standard. Und deshalb ist es seit ES6 auch stetig besser geworden und nicht etwa weil Google durch äußerst fragwürdige Praktiken mittlerweile ein Monopol im Browsermarkt erreicht hat. Diesen Zustand zu glorifizieren finde ich als langjähriger Webentwickler verstörend. Ich kann und will mir nicht vorstellen, dass ihr das so gemeint habt. Ein wenig schmunzeln muss ich aber doch: Zuletzt noch Go und jetzt “Long live Chrome the only browser in the world”? Gehts euch “Goo…(t)”? 😉
Mich hast Du damit nur darin bestätigt, dass ich allen drei Runtimes fern bleiben werde. JavaScript sollte man offensichtlich so wenig wie nur möglich überhaupt einsetzen, sowohl im Backend, als auch im Frontend.
Was willst du denn im Frontend anderes als JavaScript verwenden? Da gibt es maximal noch WebAssembly und WGSL, aber auch da brauchst du JavaScript, um die zu laden.
@@BenjaminAster Ich habe nicht gesagt es gar nicht zu verwenden, sondern so wenig wie nur möglich. Serverside prerendering ist da ein Schlagwort von vielen.
Ich hoffe einfach, dass man in Zukunft zumindest für interne Projekte ab und an mal Blazor verwenden darf. Ich sehe die Nachteile, aber die JS/TS Welt ist mir ziemlich unsympathisch. Im .NET Backend bin ich besser aufgehoben. Ich möchte meine recht bescheidenen Erfahrungen mit Angular und VUE noch etwas vertiefen, aber die Arbeit mit NODE und npm finde ich auf Dauer mühsam.
@@BenjaminWagener Dann kannste auch gleich wieder Java Server Pages verwenden, back to the roots in 2000. Ne, sorry, die Schlussfolgerung so wenig Javascript zu verwenden wie moeglich ist einfach nur aus der Zeit gefallen.
@@manmanmanichfindekeinennam7613 Wo hast du denn den Unsinn her? Die ganzen modernen JavaScript-Frameworks, sei es Next.js, Nuxt.js oder SvelteKit bauen alle unter anderem auf serverseitigem Rendering, um die Clients so weit wie möglich von Komplexität zu entlasten und auch die Menge an übertragenen Daten möglichst gering zu halten. Gerade wenn man unnötig Daten und Rechenaufgaben auf den Client auslagert, obwohl der Server das viel performanter erledigen kann, dann erhält man erst recht Apps die NICHT performant sind und unnötig den Speicher, die Bandbreite und den Traffic des Client belasten. Und wenn man mit JavaScript viel besser als mit jeder anderen Sprache UIs programmieren kann, warum verwenden dann immer mehr App-Developer Flutter statt React Native und Co., welches mit Dart statt JavaScript arbeitet? Und warum ist dann JavaScript nicht allgemein DIE Sprache mit denen alle nativen AppUIs gebaut werden? Sorry, aber deine Sichtweise scheint da doch sehr undifferenziert und teilweise auch schlicht falsch bzw. erklärst du ziemlich leichtfertig deine persönlichen Vorlieben zu Fakten, obwohl die Realität an etlichen Stellen doch weit von deinen Behauptungen entfernt ist.
Interessantes Video. Die Entwicklerteams sollten kooperieren und gemeinsam die Features ausbauen. Sofern der Stolz, das zulässt. PS: Bitte hör auf zu gendern. Sag doch einfach Developer. Das beinhaltet alle Geschlechter, die es aktuell gibt und noch erfunden werden.
Das PS klingt nach einer sehr arrogante Haltung vor allem bzgl der „Erfindung“ von Geschlechtern. Klar gibt es auch beim Gendern die Ansichten und Vorschläge, die übers Ziel hinaus schießen. Aber mir ist beim Hören des Videos nicht mal aufgefallen, dass er gendert. Und ich finde gut, dass man ein wenig auf seine Umgebung achtet und wenn man mit einem sehr geringen Aufwand vielen Menschen den Tag besser machen kann, ist das doch sehr gut :)
Der Content auf dem Channel ist so qualitativ! Vielen Dank, dieser Channel verdient so viel mehr Reichweite!
[gr] Vielen, vielen Dank 😊
Was mich bei Dir immer wieder fasziniert...
24 min Video und nicht ein Schnitt und das Thema flüssig themaitisieren. Rhetorisch eine Meisterleistung wie ich finde. Inhaltlich ja sowieso
fällt mir auch immer auf, einfach der Burner. 🔥
Ich könnte nicht mal so schnell denken wie er struktiert und nachvollziehbar die Themen auseinanderpflückt. :D
Genau diese Inkompatibilitäten in node (fetch api, integrierter Test runner, und vor allem cjs - esm Probleme beim tooling (z.B mit jest) machen für mich die Arbeit mit Deno so angenehm.
Und , dass deno eine einzige exe ist! Es ist selbst heute immer noch kompliziert, eine Portable Version von Node aufzusetzen, bei deno muss ich nur die exe runterladen und in den Pfad eintragen.
Und Updates kann ich einfach via deno Upgrade installieren! 😍
Gewünschte Monokultur? Das hab ich auch noch nicht gehört 😎
Danke für das Video. Um das ganze beurteilen zu können müsste man wissen was im Hintergrund passiert und was die Gründe für die Entwicklung von Deno und Bun sind. Ich könnte mir schon vorstellen, dass es eine große Unzufriedenheit mit Node gab und diese zu unflexibel waren darauf zu reagieren. Am Ende wird sich zeigen ob die großen Player auf den Zug aufspringen und wohin die Reise geht.
Wie immer ein fachlich ausserordentlich gutes Video.
Allerdings finde ich die Einstellung "die anderen haben Unruhe reingebracht" schwierig. Einerseits steht es jedem frei, eine eigene Entwicklung zu starten. Daran wäre nur dann etwas zu kritisieren, wenn dies mit der Absicht passiert, "dem anderen" zu schaden.
Andererseits sehe ich das mit unterschiedlichen Laufzeitumgebungen ähnlich wie mit einer Framework-Entscheidung zwischen Symfony und Laravel oder bspw. der Entscheidung, ob ich ein WPF-Programm oder WinForms-Projekt starte. Ich muss dann damit leben. Genauso schwierig dürfte es sein, meine C++ Entwicklungsumgebung ohne Probleme unter Linux zu betreiben, wenn ich die Tools betrachte.
Was muss ich eigentlich tun, um die Infocards zu sehen?
Auf dem Desktop gucken und das ℹ️ Icon oben rechts anclicken. Die Android App zeigt nur 4 der 5 verlinkten Videos (erst ⚙️, dann ℹ️ anclicken)…
[gr] Leider weiß ich nicht, auf welchem System Du unterwegs bist. Aber bei mir auf iOS ist es zum Beispiel so, dass die Infokarten nur in der TH-cam-App angezeigt werden, nicht in der webbasierten Variante. Und wie Henning in dem anderen Kommentar ja schrieb, gibt es bei Android auch ein paar Besonderheiten …
Spannend, deine Kritik an Bun und Deno ist also im Grunde genommen, ihre Wirkung auf Node und die Unfähigkeit der dahinter stehenden Community, angemessen auf diese neue disruptive Entwicklung zu reagieren?!?
Ich teile die Kritik, dass der native TS Support in Bun Makulatur ist. Aber den beiden Projekten vorzuwerfen, sie würden Node vor sich her treiben und zur Fragmentierung des Ökosystems führen, teile ich nicht. Dann müsste man auch KDE/Gnome/I3 etc für die Fragmentierung des Linux Desktops verantwortlich machen.
Vielmehr erinnert mich die Situation an OpenOffice/LibreOffice oder OpenSSL/LibreSSL. Die Community hinter dem etablierten System ist vielleicht einfach zu satt, teils arrogant. Die Diskussion um die unterschiedlichen Release Zyklen von Node und ESlint ist da das beste Beispiel.
Ja es wird deswegen zur Fragmentierung kommen. Ja vielleicht ist das der Tod von Node, so wie wir es heute kennen. Muss das etwas Schlechtes sein? Nicht unbedingt. Etwas Disruption tut in der SW Entwicklung imho ab und zu ganz gut.
Ideal wäre natürlich, wenn aus den verschiedenen Strömungen am Ende wieder ein gemeinsamer Konsens hervorgeht. Aber auch dafür gibt es ja Beispiele in der Vergangenheit.
Was Node aus meiner Sicht jetzt gut stehen würde, wäre durchaus Anregungen/Konzepte der anderen beiden zu übernehmen, sie dann aber auch konsequent und mit eigenen Konzepten umzusetzen. Dieses Trauerspiel bei CommonJS vs ESM. Wozu gibt es denn Major Versionen?
[gr] Meine Kritik an Bun und Deno ist im Grunde genommen, dass sie - ohne Not - Inkompatibilitäten einführen, die dazu führen, dass es für alle schwieriger wird, JavaScript auf dem Server auszuführen. Sei es, weil Code auf Node entwickelt wird und auf Deno nicht läuft, sei es, weil Modul X nur für Deno verfügbar ist und nicht für Node, sei es, weil das Publishen von Modulen auf einmal doppelt so viel Aufwand ist wie vorher, und so weiter …
Natürlich belebt Konkurrenz das Geschäft, wie es so schön heißt, und das letzte, was ich wollen würde, ist ein Monopol von welcher Technologie auch immer. Aber ganz bewusst mit (Quasi-)Standards zu brechen, und das dann anzupreisen als vermeintlich längst überfällige Revolution, das hat weniger mit gesunder Konkurrenz, sondern eher mit anderen Dinge zu tun …
Wo ist denn der ach so große Benefit von Deno? Dass Promises unterstützt werden? Dass der TypeScript-Compiler zur Laufzeit in-memory davorgeschaltet wird? Dass auf npm verzichtet wird? …?
Das alles waren Argumente von Ryan Dahl, warum er Deno entwickelt hat - zu einem Zeitpunkt, wo es Promises in Node schon gab. Zu einem Zeitpunkt, wo es ts-node schon seit Jahren gab. Zu einem Zeitpunkt, wo Dich niemand gezwungen hat, npm zu nutzen.
Ja, Deno bietet Dinge, die Node nicht hat: Das wichtigste dürfte die Sandbox sein, das zweite die Integration von Tools wie Linting, Formatting & Co. Darüber hinaus wird es aber schon sehr dünn. Ob das dann den Bruch mit einem bestehenden Ökosystem rechtfertigt und langfristig so viel nützt, dass es den ganzen Rattenschwanz an Problemen, die es mit sich bringt, aufwiegt, wage ich persönlich zu bezweifeln, aber da muss sich jede:r ihre/seine eigene Meinung bilden.
Und auffällig ist nun eben, dass Bun mit genau der gleichen Taktik vermarktet wird, Probleme zu benennen, wo keine sind, beziehungsweise Dinge zu versprechen, die nicht gehalten werden, wie zB der Pseudo-TypeScript-Unterstützung, die ja nun wirklich eher Augenwischerei ist.
Aber warten wir es ab, wie sich der Markt entwickelt, etwas anderes bleibt uns am Ende ohnehin nicht übrig.
@@thenativeweb
Hi Golo,
danke dass du noch mal detailliert auf meine Punkte eingegangen bist. Ich denke, wir sind uns prinzipiell einig. Wir haben aber in einer Hinsicht wohl unterschiedliche Auffassungen. Du betrachtest das JavaScript Ökosystem wohl eher als ein einheitliches. Aus meiner Erfahrung heraus, auch von anderen Plattformen, ist das so nicht wirklich möglich.
Wenn ich zum Beispiel nach PHP schaue, auch da kann ich Symfony und Laravel oder Laminas nicht nach Belieben mischen. Klar, Runtime und Framework sind jetzt nicht dasselbe, aber ich denke immer, es gibt nicht den PHP Entwickler oder den JavaScript-Entwickler. Normalerweise spezialisiert man sich ja auf eine Plattform oder dort auf ein Set an Frameworks und Libs. Ich würde Bun/Deno eher als alternative Runtimes, wie ReactPHP oder Swoole verstehen. Sie teilen sich die Plattform und erfüllen zu einem gewissen Grad denselben Zweck, aber haben eben doch ihre Eigenheiten. Auch bei der JVM gibt es ja verschiedene Implementierungen, wenngleich sich da viel konsolidiert hat.
Und seien wir mal ehrlich, das Modulsystem, bzw. das eben das Fehlen eines standardisierten solchen, hat bei JavaScript schon immer dazu geführt, dass Libs gleich mit einem Set davon um die Ecke kamen (meist CommonJS und AMD, später noch ESM). Die Situation ist ja nicht neu. Dazu dann noch neben NPM die Alternativen wie Yarn und PNPM. Also die Fragmentierung ist real und das JS Ökosystem wohl das dynamischste und disruptivste im Markt, weshalb ich es auch nicht mag. Für Leute, die OSS in dem Bereich betreuen, ist das natürlich unglücklich. Aber vielleicht kommt es ja doch noch zur Konsolidierung und am Ende steht eine Runtime, die heute noch gar nicht existiert. Bis dann wieder jemand etwas daran auszusetzen hat und sein eigenes Ding startet. 😁
Ich meine, TypeScript existiert ja auch nur, weil erst einige Google und später Microsoft Entwickler mit dem Typensystem von JavaScript nicht zufrieden waren.
VG
Gutes Video!
Ich bin hin- und hergerissen ob ich diese Zersplitterungen wie bei den JS-Plattformen, Linux Distros, Browser Engines, usw...., jetzt gut oder schlecht finden soll.
[gr] Danke schön 😊
Wozu tendierst Du denn?
Die Frage im Videotitel wurde meiner Meinung nach nicht beantwortet. 😉 Ansonsten erinnert mich die Situation an das SNAFU-Prinzip. 😁
Clickbait!!!
@@comodDas sehe ich auch so. Dabei hat der Kanal das überhaupt nicht nötig. 🤷🏻♂️
[gr] Es freut mich, dass Du schreibst, dass wir das nicht nötig hätten - dem stimme ich prinzipiell zu. Aber es gibt einen Grund, warum wir es (leider) trotzdem machen (müssen), zumindest in gewissem Sinne - dazu haben wir schon mal ein Video gemacht, wo ich das etwas ausführlicher erkläre, warum wir von relativ nüchternen, sachlichen Titeln auf die etwas reißerischen umgestiegen sind … vielleicht kann es das ein bisschen nachvollziehbar(er) machen: th-cam.com/video/1HZs2hWJNhU/w-d-xo.html
@@thenativeweb Das Video, auf welches du verweist, kenne ich. Ich möchte an dieser Stelle betonen, dass ich deine Videos nicht wegen, sondern trotz manch schrecklicher Titel schaue. Das tue ich, weil ich die inhaltliche Qualität deiner Videos schätze. Normalerweise mache ich einen großen Bogen um Videos mit solch reißerischen Titeln, weil oftmals nur heiße Luft dahinter steckt. Ob deine Entscheidung die Richtige ist, weiß ich nicht. Mir kommt dabei jedenfalls folgender Spruch in den Sinn: "Die Geister, die ich rief ..." Ich hoffe, du verstehst, worauf ich hinaus möchte.
Sehr interessante Zusammenfassung! Irgendwie aber auch frustrierend, vor allem diese Fragmentierung :-/
[gr] Danke schön 😊
Und was die Fragmentierung angeht, bin ich sehr gespannt … IMHO werden sich Node und Deno immer weiter aneinander annähern (und Deno dann überflüssig werden), und für Bun sehe ich persönlich zumindest derzeit eigentlich keinen nennenswerten Raum.
Das ist aber nur meine persönliche, subjektive Meinung.
Hallo Beno, vielen Dank für so ein schönes Video! Ich programmiere kaum mit Javascript. Mit Java gar nicht. Doch dir höre ich gerne zu. Und heute ging zwar um Frameworks zu Java, jedoch wenig um Java, sonder mehr, wie es nicht einfach ist, Menschen zusammen zu bringen. Viele stellen für sich fest, nicht mehr mit anderen mehr zusammen an einem Produkt arbeiten zu wollen. An sich - eing ganz normaler Vorgang. Irgendwann gehen auch deine Mitarbeiter weiter, auch sogar wenn sie woanders auch nicht unbedingt was besseres finden werden. So sind eben Menschen. Das sind unsere Fluch und Segen gleichzeitig.Und rational zu denken - ist auch nicht die Stärke von Menschen. Aber. Du hast alles auf den Punkt gebracht. Mal sehen, wann deine Prophezeiung wahr wird. Denn, ob - das Frage ich mich schon nicht mehr. Das ist offensichtlich. Nochmals danke!
Ich hätte, wenn überhaupt eher eine Laufzeitumgebung, welche direkt und ausschliesslich (strict) Typescript macht, und zwar ohne den (internen) umweg über Javascript. Ich kann mir gut vorstellen, dass aufgrund des statischen Typesystems deutlich performanterer Code dabei herumkommen könnte, als wenn die Laufzeitumgebung wieder nur live testen muss, was das aktuell für Typen sind.
An sonsten sehe ich das Problem der Zersplitterung von Serverseitigem Javascript nicht soo schlimm, da im Fall von Serverseitig nur der Entwickler selbst entscheidet, auf welcher Umgebung der Code läuft und nicht der Benutzer (wie im Fall von Webseiten, die auf unterschiedlichsten Geräten laufen müssen)
Im Besten Fall wird ein Paket eh als Docker (oder Ähnlich) gebaut und dann ist man von den (parallel) installierten Paketen auf dem Server unabhängig.
@@rumpeldrump Ja, ich habe verstanden, was Typesctipt ist, ich bin seit 20 Jahren Professioneller Softwareentwickler und im Falle von Typescript seit der Beta dabei. Ich habe auch nicht gesagt, dass ich Javascript schlecht finde, ich meine nur, dass man Typescript auch direkt mit allen Vorteilen in einer Laufzeitumgebung ausführen könnte, ohne dass man erst nach Javascript übersetzt. Das wäre in dem Fall eine komplett neue Laufzeitumgebung, nicht V8 oder Javascript Core.
@@AFE-GmdG er meint halt das TS keine eigene Programmiersprache ist, sondern nur nach JS übersetzt werden kann. Also kein TS ohne (intern) JS
@@dattitoo Das ist so pauschal schlicht nicht wahr, weil man eben einen JIT-Compiler integrieren könnte der TS direkt ausführt, anstatt ihn erst über den Umweg auszuführen.
Ich kann deine Kritik verstehen. "Zersplitterung" der Javascript-Community in Node-, Bun- und Deno-"Lager" wäre wirklich kontraproduktiv. Bin gespannt was aus diesen Projekten wird.
Top wie immer!
Hab schon ein bisschen gelesen bun soll total schnell sein
Mir wärs lieber wenn wir bei node bleiben, das kann ich inzwischen ein bisschen. Müsste ich eine kompexle Anwendung für den Server bauen würde ich bei node bleiben. Aber wenn es nur darum geht, zb. für eine nextjs App Seiten auf dem Server zu rendern wäre mir die Umgebung vermutlich egal. Mehr als doppelt so schnelles rendering ist schon eine Nummer
Monokultur und Monopole waren ja noch nicht vielversprechend. Ich finde mehr Auswahl besser
Wo wird denn bitte die Community gesplittet?! Jede Runtime wird immer ihre Macken haben und ihre Fanboys die es für wichtiger halten sich darüber zu streiten was nun besser ist als zu evaluieren welche Runtime für welches Projekt zutreffen und sich besser eignen. Wer immer auf das gleiche Pferd setzt wird nie etwas gewinnen.
Die Frage die man sich beispielsweise stellen muss: Brauche ich eine schnellere Runtime für meinen Anwendungsfall?
Ein Beispiel: Nehmen wir an ich benutze Node um etwas zu builden in einem docker-container und das ganze brauch 5 Minuten, ja so what dann geh ich mir halt noch schnell nen Kaffee holen. Hab ich aber ein schon bestehendes Projekt und auf einmal kommt ne Story bei der ich Templating-Performance brauche wie bei PHP, dann kann ich ja nicht meine ganze Codebase umbauen. Ergo kommt dann bspw. Bun wie gerufen und ich würde mir langfristig Gedanken machen ob ich noch lieber auf PHP oder Rust umsteige.
Es kommt immer auf den Anwendungsfall und die Gegebenheiten an, woran man letztendlich wählt was man benutzt und nicht auf die "potentielle Gefahr der Zersplitterung der Community". Wenn man dann keine Alternativen hat und es nicht zu einer Entwicklung kommt sieht man ganz schön alt aus. Auch wenn Deno nicht entwickelt worden wäre hatte Node immer noch die gleichen Probleme. Es ist wie in dem Peter-Fox Song: "Wenn's dir nicht gefällt, mach neu", Wasserfall ist out und Rückschrittlich, zumindest for now und wir können glücklich sein dass nicht alle am "Alten" festhalten sondern sich fragen was man noch besser machen kann.
Ich kann deiner Wahrnehmung nur zustimmen. Manche "new kids on the block" machen in einer Gesamtbetrachtung des technischen Umfeldes nur wenig oder gar nichts besser.
[gr] Danke für Deinen Kommentar 😊
Was die Nutzung des esbuild (oder swc) Ansatz angeht halte ich das gar nicht für einen so falschen Ansatz. ich würde sogar einen Schritt weiter gehen: Ich unterstütze die Erweiterung des ECMAscript Standards um eine standardisierte Typsyntax. Man würde dann gar keinen Transpiler mehr benötigen. Der Typescript-Compiler wäre dann lediglich ein Typechecker.
Grundsätzlich finde ich verschiedene Implementierungen und Variation sinnvoll - auf diese Weise entsteht Konkurrenz und Wettbewerb. Was wir uns wünschen ist Fortschritt und nicht Stagnation. Ohne “Ausreißer” mit welchen neue Ideen probiert werden bleibt eben leider vieles auf den festgetretenen Pfaden. Gute Ideen können natürlich übernommen werden. Insofern zweifle ich an Deiner Theorie, dass Deno oder Bun wirklich schädlich ist.
naja ... ein problem mit Pluralismus geht halt auch schnell Richtung antidemokratischem denken und wo bleibt dann der open source Gedanke...
wenn der Entwickler von node mit deno einen Neustart versucht, hat das wohl einen Grund und andere bzw neue Ansätze probieren ist gut! sehr sogar!
das erzeugt diversität und die fragmentierung entsteht ja schon innerhalb node, also was solls...
node braucht sich nicht unter druck gesetzt fühlen und könnte "neue" features (wie zb fetch) auch "einfach" vernünftig implementieren. dann halt eine version später. deshalb werden jetzt nicht alle zu deno/bun rennen.
hätte node überhaupt etwas getan, um das und andere Themen in angriff zu nehmen, oder sich Enterprise-artig zurückgelehnt und sich zufrieden gegeben? ich denke nicht. leider.
deshalb ist ein gewisses maß an Konkurrenz gut.
es liegt bei node, deno und bun unwichtig zu machen - aber bitte nicht via "wir haben mehr addons auf npm"; das müffelt ein bisschen nach Schw...vergleich und wäre peinlich.
6:20 Hui… das klingt ja fast so als ob ihr euch wünscht, dass Google endlich mit Chrome den einzigen Webbrowser anbietet. Die Implementierungsvielfalt der Webbrowser war keineswegs “das größte Problem von Javascript”. Es war der fehlende, ständig gepflegte und weiterentwickelte Standard. Und deshalb ist es seit ES6 auch stetig besser geworden und nicht etwa weil Google durch äußerst fragwürdige Praktiken mittlerweile ein Monopol im Browsermarkt erreicht hat. Diesen Zustand zu glorifizieren finde ich als langjähriger Webentwickler verstörend. Ich kann und will mir nicht vorstellen, dass ihr das so gemeint habt. Ein wenig schmunzeln muss ich aber doch: Zuletzt noch Go und jetzt “Long live Chrome the only browser in the world”? Gehts euch “Goo…(t)”? 😉
Der content ist gut. Das gendern ist unerträglich.
Mich hast Du damit nur darin bestätigt, dass ich allen drei Runtimes fern bleiben werde. JavaScript sollte man offensichtlich so wenig wie nur möglich überhaupt einsetzen, sowohl im Backend, als auch im Frontend.
Was willst du denn im Frontend anderes als JavaScript verwenden? Da gibt es maximal noch WebAssembly und WGSL, aber auch da brauchst du JavaScript, um die zu laden.
@@BenjaminAster Ich habe nicht gesagt es gar nicht zu verwenden, sondern so wenig wie nur möglich. Serverside prerendering ist da ein Schlagwort von vielen.
Ich hoffe einfach, dass man in Zukunft zumindest für interne Projekte ab und an mal Blazor verwenden darf.
Ich sehe die Nachteile, aber die JS/TS Welt ist mir ziemlich unsympathisch. Im .NET Backend bin ich besser aufgehoben. Ich möchte meine recht bescheidenen Erfahrungen mit Angular und VUE noch etwas vertiefen, aber die Arbeit mit NODE und npm finde ich auf Dauer mühsam.
@@BenjaminWagener Dann kannste auch gleich wieder Java Server Pages verwenden, back to the roots in 2000.
Ne, sorry, die Schlussfolgerung so wenig Javascript zu verwenden wie moeglich ist einfach nur aus der Zeit gefallen.
@@manmanmanichfindekeinennam7613 Wo hast du denn den Unsinn her? Die ganzen modernen JavaScript-Frameworks, sei es Next.js, Nuxt.js oder SvelteKit bauen alle unter anderem auf serverseitigem Rendering, um die Clients so weit wie möglich von Komplexität zu entlasten und auch die Menge an übertragenen Daten möglichst gering zu halten. Gerade wenn man unnötig Daten und Rechenaufgaben auf den Client auslagert, obwohl der Server das viel performanter erledigen kann, dann erhält man erst recht Apps die NICHT performant sind und unnötig den Speicher, die Bandbreite und den Traffic des Client belasten. Und wenn man mit JavaScript viel besser als mit jeder anderen Sprache UIs programmieren kann, warum verwenden dann immer mehr App-Developer Flutter statt React Native und Co., welches mit Dart statt JavaScript arbeitet? Und warum ist dann JavaScript nicht allgemein DIE Sprache mit denen alle nativen AppUIs gebaut werden? Sorry, aber deine Sichtweise scheint da doch sehr undifferenziert und teilweise auch schlicht falsch bzw. erklärst du ziemlich leichtfertig deine persönlichen Vorlieben zu Fakten, obwohl die Realität an etlichen Stellen doch weit von deinen Behauptungen entfernt ist.
Interessantes Video. Die Entwicklerteams sollten kooperieren und gemeinsam die Features ausbauen. Sofern der Stolz, das zulässt.
PS: Bitte hör auf zu gendern. Sag doch einfach Developer. Das beinhaltet alle Geschlechter, die es aktuell gibt und noch erfunden werden.
Das PS klingt nach einer sehr arrogante Haltung vor allem bzgl der „Erfindung“ von Geschlechtern. Klar gibt es auch beim Gendern die Ansichten und Vorschläge, die übers Ziel hinaus schießen. Aber mir ist beim Hören des Videos nicht mal aufgefallen, dass er gendert. Und ich finde gut, dass man ein wenig auf seine Umgebung achtet und wenn man mit einem sehr geringen Aufwand vielen Menschen den Tag besser machen kann, ist das doch sehr gut :)
Es ist leider das selbe wie bei Linux. Jeder denkt/will was anderes und dann hast Du hunderte distros.
Gendern finde ich auch voll doof, aber „Entwicklerinnen und Entwickler“ finde ich absolut okay 👍