Jemand, der seine Einschätzung von früher, nach geänderten Rahmenbedingungen, "nochmal auf den Prüfstand stellen muss". Dass ich das noch erleben darf. Alleine dafür gibts einen Daumen hoch
Danke schön - wobei ich denke, das sollte eigentlich selbstverständlich sein, dass man zwar eine fundierte Meinung hat, die man argumentativ vertreten kann, aber dass man auch immer neuen Argumenten gegenüber offen sein sollte. Aber ja, das ist wohl nicht die Regel. Insofern: Vielen Dank für's Kompliment 😊
Auf jeden Fall schön Deine Einschätzung zu dem Thema zu hören. Ich schaue auf das Themengebiet bun, deno, node immer mit einem halben Auge drauf. So ein bisschen wie ein Unfall, bei dem man nicht wegschauen kann. Wie alles eben im JS Ökosystem. Man muss ja wissen was der Feind macht (wen trigger ich mit der Aussage? ... keep calm 😄) Bin so froh in dem Bereich keine Backends schreiben zu müssen. Für Geld würde ich ja alles machen, aber solange man die Wahl hat, mache ich da unbedingt einen Bogen rum.🌞
Ja - ich bin leider wieder erkältet, aber dieses Mal nicht so schlimm wie beim ersten Mal vor ein paar Wochen. Die Stimme hört sich auch tatsächlich heiserer an als ich bin. Aber ja, Du hast grundsätzlich schon Recht - übernehmen sollte ich mich nicht 😊
Etwas anderes, was auch wesentlich mehr Spaß macht, als mit NodeJS und npm, ist Deno mit JSR. Als langjähriger Open Source Package Maintainer habe ich schon sehr lange Probleme mit den ganzen neuen Publishing-Standards und TS vs. ECMAScript vs. CJS sowie dem Upgrading meines Toolings etc gehabt. Und als ich zum ersten Mal Pakete für JSR gebaut habe mit Deno, war ich extrem positiv überrascht. Ich brauchte nahezu kein Extra-Tooling, mein Beispiel-Paket hatte weniger als 10 Files und gepublisht wurde mit fantastischer TS source maps Integration. Dadurch minimiert sich mein Maintenance-Overhead einfach enorm.
Ja, das stimmt - den Punkt hatte ich im Video bewusst außen vor gelassen, um nicht auch noch JSR erklären zu müssen, und wie sich das auch in Node.js integriert, aber ich bin absolut bei Dir! Das Publishen bei npm ist schon lange zu umständlich, wenn man TypeScript nutzt.
Wie gut funktionieren Monorepos mit Deno 2.0? Gerade das nervt mich bei Bun, dass dort Monorepos zwar unterstützt werden, aber nicht sonderlich gut und das Ökosystem praktisch gar nicht (z.B. Dependabot/Renovate).
Also Deno ist schon geil, das muss man einfach sagen. Ich finde vorallem schön, dass es einfach nur ein Binary ist, was man runterlädt und schon geht es los (portabel), dann der Web Standards-first Ansatz, ESM-Imports anstatt CommonJS, Safety first, kein node_modules Neutronenstern mehr imProjektverzeichnis, stattdessen zentral gecachte Abhängigkeiten, Typescript-first. Es gab sogar mal einen Bundler mit an Bord, der wurde aber leider gestrichen. Sind aber alles Sachen, die es schon sehr zeitig in Deno gab, also als du Deno und Ryan Dahls Ideen noch doof fandest.
Cool dass ihr da jetzt ausgerechnet auch ein Video macht :) ich bin gerade dabei, mich intensiv mit Deno zu beschäftigen, weil ich Deno als Skriptumgebung in eine größere Rust-Anwendung einbauen will. Und ich bin echt sehr angetan von Deno und dem Ökosystem
Bisher hatte ich mit Deno absolut nix am Hut. So wenig, dass ich erst durch dein Video erfahren habe, dass da überhaupt ne neue Version gekommen ist. Das klingt alles wirklich sehr interessant. Ich bin gerade dabei ein kleines Framework zur Datenhaltung und API-Design zu schreiben und hab mich da ganz bewusst gegen TS entschieden, gerade weil die Toolchain so extrem groß ist. Stattdessen nutze ich nur das TS im Editor und mache ansonsten alles mit JSDoc. Durch die Neuigkeiten werde ich mir das aber noch mal überlegen und mal schauen, wie sich das mit Deno gebessert hat. Ich vermute aber mal, dass da keine Abhilfe für den Browser eingebaut ist, oder? Weil das ist das, was mich mitunter noch am meisten nervt. Bei node gab es ja wenigstens noch ts-node aber was gibt's im Browser?
Wenn ich das richtig im Sinn habe, werden die von RUclips nicht auf allen Plattformen ausgespielt - im Zweifel sollte man sie in der Desktopversion finden können.
Benutze Bun und bin damit recht zufrieden. Gleichen Vorteile wie bei Deno plus tests werden wirklich 10-100x schneller ausgeführt, was Tests schreiben und ausführen dann Spaß macht. Meiner Meinung nach ist Node.js einfach nur veraltet und kann mit den neuen Ansätzen und VC-Geld nicht mithalten.
Als Entwickler will ich das Produkt, an dem ich arbeite, vorantreiben und Mehrwert liefern. Ich will mich nicht mit dem Tooling herumschlagen müssen. Aber genau das muss ich immer wieder mit Nodejs. Wenn Deno es schafft, dass das Tooling wie aus einem Guss funktioniert, dann ist das aus meiner Sicht ein Riesenvorteil für Deno. Deshalb mag ich auch Golang so gerne - die Tools funktionieren einfach und ich kann mich daher auf meine eigentliche Arbeit fokussieren.
@@i-am-the-slime nein, aber netter Versuch ;) Aktuell besteht meine Arbeit überwiegend darin verschiedene npm Packages miteinander kompatibel zu bekommen und davor musste ich Workarounds für Bugs im Spring Framework implementieren, aber das gehört in großen Projekten leider manchmal dazu. Daher weiß ich es zu schätzen, wenn ein Ökosystem einfach funktioniert und ich mich darauf fokussieren kann Mehrwehrt zu liefern und Kundenprobleme zu lösen.
@@cfo3049 Ja das ist sehr schade, aber ich habe auch nicht erwartet, dass die runtime auf Anhieb mit dem ganzen JS Chaos aufräumen wird. Nichtsdestotrotz scheint Deno2 ein großer Schritt in die richtige Richtung zu sein.
Da ich hauptsächlich mit der Cloud (AWS Lambda, Firebase und SupaBase) als Backend arbeite und Deno zur Zeit nur die eigene Cloud unterstützt Bzw. die Cloudanbieter das noch nicht ausführlich unterstützen, macht die Migration momentan keinen Sinn. Die Wirtschaft ist so oder so ziemlich resistent was den Umbau ihrer Backends betrifft, wird also ein hartes Stück für das Projekt.
Ich bin vor einiger Zeit zu bun gewechselt, einfach weils so einfach war mit TS und sqlite, denke aber, dass Node bleiben wird. Der einzige wirkliche Nachteil an Node den ich sehe ist die Performance ggü. deno oder bun. Diesen Ansatz den deno und bun jetzt versuchen, also eine Art Toolkit auszuliefern, das einige packages enthält die man sowieso installieren würde, könnte man bei Node theoretisch auch machen.
Ja, das stimmt - und Node.js versucht das ja auch, mit Sachen wie zB dem integrierten Test-Runner. Es geht nur leider alles so zäh und langsam vonstatten … und Deno macht es halt inzwischen seit sechs Jahren vor, wie es geht.
Ich muss gerade weder node noch deno einsetzen. Ich frage mich gerade ob wir in eine ähnliche Situation laufen wie damals mit io.js. Zugegeben ist deno kein Fork von node, aber irgendwie fühlt es sich ähnlich an. Meiner (lückenhaften) Erinnerung nach waren die großen Innovationstreiber von node auch immer 3rd-Partys die irgendwas cooles damit gemacht haben. Eine .package-lock hätten wir zum Beispiel nicht, wenn nicht yarn gekommen wäre und das alles so viel besser gemacht hätte und auch die V8 zu nutzen war quasi der Verdienst von io.js. Vielleicht katalysiert das jetzt Dinge beim node-Team. Vielleicht auch nicht... Ich guck mir das auf jeden Fall gespannt an und wenn ich doch mal wieder serverseitiges JS nutzen muss, werde ich wohl genauer schauen müssen ob es jetzt node oder deno wird (Das Logo/Maskottchen ist halt auch einfach gleich 10 Mal so cool)
Wer Node.js ersetzen will, dem rate ich eher zu Bun. Bun schlägt sowohl Node als auch Deno deutlich. In Bun ist TypesScript eine First Level Sprache (wird genauso wie JS unterstützt, dafür muss man nichts installieren, tsc und ts-node kann Bun out of the box), Bun bringt das Testframework schon mit (Vitest oder Jest braucht man nicht, kann Bun out of box), Bun ist auch ein Paket Manager (npm oder Yarn braucht man nicht, Bun schlägt diese um Welten in Geschwindigkeit), Bun kann auch native Web Assembly ausführen. Bun kommt als ein einziges Binary und verbraucht viel weniger Speicher auf Platte und RAM während der Laufzeit als Node oder Deno.
wir haben zig Abhängigkeiten und sind vor ca. 1 1/2 Jahren von npm auf pnpm umgestiegen. Seitdem gibts keine rauchenden Rechner mehr :) ein Punkt mehr, warum man deno nicht braucht
Die Anzahl der Sterne auf GitHub sagt rein gar nichts darüber aus, wie häufig die Software in freier Wildbahn produktiv genutzt wird. Ich verstehe, was Du mir sagen willst, aber GitHub-Sterne sind da (IMHO) die falsche Metrik.
Deno hat keine lock-Datei für Pakete? Dann ist Deno im Business-Umfeld vollkommen unbrauchbar und nutzlos. Gerade aus Security-Sicht MUSS es eine lock-Datei geben, damit nicht plötzlich ungewollt ein unsicheres Sub-Package installiert werden kann. Und eine effektive Vulnerability-Prüfung ist ohne lock-Datei auch unmöglich.
Wenn das so wäre wie von dir beschrieben, wäre Deno tatsächlich ungeeignet. Man muss aber das große Ganze sehen. Stichwort sind hier das permission system und url based versioning. Außerdem kannst du deine Abhängigkeiten auch in einer depts.ts festhalten. Braucht man aber nicht. Deno ist eben kein Node
@@geeksy2278 Ah, ich verstehe. Also anstatt eine einheitliche Lösung, die bei jedem identisch ist, wie bei Node, gibt es bei Deno mehrere Lösungen, die alle nur so halbgar sind? ;) Abgesehen davon geht es mir nicht um direkte Dependencies. Die sollte man in seinen Endanwendungen sowieso nicht mit Version-Ranges einbinden. Es geht mir um Sub-Dependencies und Sub-Sub-Dependencies und so weiter.
Ich bekomme von Deno genauso viel wie von allen anderen, wo wir Technologien vorstellen - nämlich nichts. Ansonsten wäre das hier auf RUclips auch als gesponsertes Video gekennzeichnet.
Jemand, der seine Einschätzung von früher, nach geänderten Rahmenbedingungen, "nochmal auf den Prüfstand stellen muss". Dass ich das noch erleben darf.
Alleine dafür gibts einen Daumen hoch
Danke schön - wobei ich denke, das sollte eigentlich selbstverständlich sein, dass man zwar eine fundierte Meinung hat, die man argumentativ vertreten kann, aber dass man auch immer neuen Argumenten gegenüber offen sein sollte. Aber ja, das ist wohl nicht die Regel. Insofern: Vielen Dank für's Kompliment 😊
Cool. Wäre eine Einführung von euch zu Deno 2.0 möglich? Bei so viel Input verliert man den Überblick 😅
Vielleicht wäre das ein Thema für einen Livestream … ist keine schlechte Idee 😊
Genau auf dieses Statement hatte ich gewartet. Danke für deine Einschätzung.
Auf jeden Fall schön Deine Einschätzung zu dem Thema zu hören.
Ich schaue auf das Themengebiet bun, deno, node immer mit einem halben Auge drauf.
So ein bisschen wie ein Unfall, bei dem man nicht wegschauen kann. Wie alles eben im JS Ökosystem.
Man muss ja wissen was der Feind macht (wen trigger ich mit der Aussage? ... keep calm 😄)
Bin so froh in dem Bereich keine Backends schreiben zu müssen. Für Geld würde ich ja alles machen,
aber solange man die Wahl hat, mache ich da unbedingt einen Bogen rum.🌞
Naja. Alles besser als der ganze Java-Müll. Die schlechteste Programmierersprache aller Zeiten. Da gibt es ja gar keinen Fortschritt.
@@i-am-the-slime Flaaaaaaaag
Pass auf deine Stimme auf. 100% gesund hört es sich noch nicht an. Danke für das Video!
Ja - ich bin leider wieder erkältet, aber dieses Mal nicht so schlimm wie beim ersten Mal vor ein paar Wochen. Die Stimme hört sich auch tatsächlich heiserer an als ich bin.
Aber ja, Du hast grundsätzlich schon Recht - übernehmen sollte ich mich nicht 😊
Etwas anderes, was auch wesentlich mehr Spaß macht, als mit NodeJS und npm, ist Deno mit JSR.
Als langjähriger Open Source Package Maintainer habe ich schon sehr lange Probleme mit den ganzen neuen Publishing-Standards und TS vs. ECMAScript vs. CJS sowie dem Upgrading meines Toolings etc gehabt.
Und als ich zum ersten Mal Pakete für JSR gebaut habe mit Deno, war ich extrem positiv überrascht. Ich brauchte nahezu kein Extra-Tooling, mein Beispiel-Paket hatte weniger als 10 Files und gepublisht wurde mit fantastischer TS source maps Integration.
Dadurch minimiert sich mein Maintenance-Overhead einfach enorm.
Ja, das stimmt - den Punkt hatte ich im Video bewusst außen vor gelassen, um nicht auch noch JSR erklären zu müssen, und wie sich das auch in Node.js integriert, aber ich bin absolut bei Dir! Das Publishen bei npm ist schon lange zu umständlich, wenn man TypeScript nutzt.
Auf dem Kanal von Anton Putra ist ein Benchmark von Deno vs. Node.js vs Bun. Deno schneidet dort auch sehr gut ab.
Wie gut funktionieren Monorepos mit Deno 2.0? Gerade das nervt mich bei Bun, dass dort Monorepos zwar unterstützt werden, aber nicht sonderlich gut und das Ökosystem praktisch gar nicht (z.B. Dependabot/Renovate).
Also Deno ist schon geil, das muss man einfach sagen. Ich finde vorallem schön, dass es einfach nur ein Binary ist, was man runterlädt und schon geht es los (portabel), dann der Web Standards-first Ansatz, ESM-Imports anstatt CommonJS, Safety first, kein node_modules Neutronenstern mehr imProjektverzeichnis, stattdessen zentral gecachte Abhängigkeiten, Typescript-first. Es gab sogar mal einen Bundler mit an Bord, der wurde aber leider gestrichen.
Sind aber alles Sachen, die es schon sehr zeitig in Deno gab, also als du Deno und Ryan Dahls Ideen noch doof fandest.
Cool dass ihr da jetzt ausgerechnet auch ein Video macht :) ich bin gerade dabei, mich intensiv mit Deno zu beschäftigen, weil ich Deno als Skriptumgebung in eine größere Rust-Anwendung einbauen will. Und ich bin echt sehr angetan von Deno und dem Ökosystem
Wie stelle ich ein größeres Projekt mal schnell von node auf deno um, um es auszuprobieren?
Du lädst Deno herunter und startest es genauso, wie Du es heute mit Node.js machst - entweder es funktioniert oder halt nicht.
@@thenativeweb not implemented scheme 'https' in package.json
@@LA-fb9bf klar, da muss man ändern, web server inkl. https bringt Deno selber mit
Moin Golo, vielen dank für deinen Content! Ich wollte schon fragen, ob du Deno2 mal bewerten kannst!
Haha 😊
(Und Danke für das schöne Feedback, das freut mich!)
Yep, Deno 2 ist auch noch auf meiner bucket list, danke fürs' Video.
Bisher hatte ich mit Deno absolut nix am Hut. So wenig, dass ich erst durch dein Video erfahren habe, dass da überhaupt ne neue Version gekommen ist. Das klingt alles wirklich sehr interessant. Ich bin gerade dabei ein kleines Framework zur Datenhaltung und API-Design zu schreiben und hab mich da ganz bewusst gegen TS entschieden, gerade weil die Toolchain so extrem groß ist. Stattdessen nutze ich nur das TS im Editor und mache ansonsten alles mit JSDoc. Durch die Neuigkeiten werde ich mir das aber noch mal überlegen und mal schauen, wie sich das mit Deno gebessert hat. Ich vermute aber mal, dass da keine Abhilfe für den Browser eingebaut ist, oder? Weil das ist das, was mich mitunter noch am meisten nervt. Bei node gab es ja wenigstens noch ts-node aber was gibt's im Browser?
Hallo 😃 Ich glaube die Info karte oben links gibt es meiner Meinung nicht mehr, zumindest auf meinem Iphone
Wenn ich das richtig im Sinn habe, werden die von RUclips nicht auf allen Plattformen ausgespielt - im Zweifel sollte man sie in der Desktopversion finden können.
Benutze Bun und bin damit recht zufrieden.
Gleichen Vorteile wie bei Deno plus tests werden wirklich 10-100x schneller ausgeführt, was Tests schreiben und ausführen dann Spaß macht.
Meiner Meinung nach ist Node.js einfach nur veraltet und kann mit den neuen Ansätzen und VC-Geld nicht mithalten.
Als Entwickler will ich das Produkt, an dem ich arbeite, vorantreiben und Mehrwert liefern. Ich will mich nicht mit dem Tooling herumschlagen müssen. Aber genau das muss ich immer wieder mit Nodejs. Wenn Deno es schafft, dass das Tooling wie aus einem Guss funktioniert, dann ist das aus meiner Sicht ein Riesenvorteil für Deno. Deshalb mag ich auch Golang so gerne - die Tools funktionieren einfach und ich kann mich daher auf meine eigentliche Arbeit fokussieren.
Besteht deine Arbeit darin möglichst oft zu schreiben if err!= nil return err?
@@i-am-the-slime nein, aber netter Versuch ;) Aktuell besteht meine Arbeit überwiegend darin verschiedene npm Packages miteinander kompatibel zu bekommen und davor musste ich Workarounds für Bugs im Spring Framework implementieren, aber das gehört in großen Projekten leider manchmal dazu.
Daher weiß ich es zu schätzen, wenn ein Ökosystem einfach funktioniert und ich mich darauf fokussieren kann Mehrwehrt zu liefern und Kundenprobleme zu lösen.
@@toTheMuh Ich muss dich leider enttäuschen, denn die Dependencies wirst du mit Deno2 auch noch manuell kompatibel halten müssen.
@@cfo3049 Ja das ist sehr schade, aber ich habe auch nicht erwartet, dass die runtime auf Anhieb mit dem ganzen JS Chaos aufräumen wird. Nichtsdestotrotz scheint Deno2 ein großer Schritt in die richtige Richtung zu sein.
Da ich hauptsächlich mit der Cloud (AWS Lambda, Firebase und SupaBase) als Backend arbeite und Deno zur Zeit nur die eigene Cloud unterstützt Bzw. die Cloudanbieter das noch nicht ausführlich unterstützen, macht die Migration momentan keinen Sinn. Die Wirtschaft ist so oder so ziemlich resistent was den Umbau ihrer Backends betrifft, wird also ein hartes Stück für das Projekt.
Ich bin vor einiger Zeit zu bun gewechselt, einfach weils so einfach war mit TS und sqlite, denke aber, dass Node bleiben wird. Der einzige wirkliche Nachteil an Node den ich sehe ist die Performance ggü. deno oder bun. Diesen Ansatz den deno und bun jetzt versuchen, also eine Art Toolkit auszuliefern, das einige packages enthält die man sowieso installieren würde, könnte man bei Node theoretisch auch machen.
Ja, das stimmt - und Node.js versucht das ja auch, mit Sachen wie zB dem integrierten Test-Runner. Es geht nur leider alles so zäh und langsam vonstatten … und Deno macht es halt inzwischen seit sechs Jahren vor, wie es geht.
Ich muss gerade weder node noch deno einsetzen. Ich frage mich gerade ob wir in eine ähnliche Situation laufen wie damals mit io.js. Zugegeben ist deno kein Fork von node, aber irgendwie fühlt es sich ähnlich an.
Meiner (lückenhaften) Erinnerung nach waren die großen Innovationstreiber von node auch immer 3rd-Partys die irgendwas cooles damit gemacht haben. Eine .package-lock hätten wir zum Beispiel nicht, wenn nicht yarn gekommen wäre und das alles so viel besser gemacht hätte und auch die V8 zu nutzen war quasi der Verdienst von io.js. Vielleicht katalysiert das jetzt Dinge beim node-Team. Vielleicht auch nicht... Ich guck mir das auf jeden Fall gespannt an und wenn ich doch mal wieder serverseitiges JS nutzen muss, werde ich wohl genauer schauen müssen ob es jetzt node oder deno wird (Das Logo/Maskottchen ist halt auch einfach gleich 10 Mal so cool)
Deno 2.0 hat die Features die ich mir schon länger von Node erhofft hatte.
Eine native AWS Lambda Unterstützung würde enormen Aufwind bringen
Deno 2.0 ❤
Danke für Deinen Kommentar 😊
Wer Node.js ersetzen will, dem rate ich eher zu Bun. Bun schlägt sowohl Node als auch Deno deutlich. In Bun ist TypesScript eine First Level Sprache (wird genauso wie JS unterstützt, dafür muss man nichts installieren, tsc und ts-node kann Bun out of the box), Bun bringt das Testframework schon mit (Vitest oder Jest braucht man nicht, kann Bun out of box), Bun ist auch ein Paket Manager (npm oder Yarn braucht man nicht, Bun schlägt diese um Welten in Geschwindigkeit), Bun kann auch native Web Assembly ausführen. Bun kommt als ein einziges Binary und verbraucht viel weniger Speicher auf Platte und RAM während der Laufzeit als Node oder Deno.
Guten Morgen
Guten Morgen 😊
wir haben zig Abhängigkeiten und sind vor ca. 1 1/2 Jahren von npm auf pnpm umgestiegen. Seitdem gibts keine rauchenden Rechner mehr :) ein Punkt mehr, warum man deno nicht braucht
Das hat doch überhaupt nichts mit der runtime zu tun
Bun finde ich spannender. Aber es gibt sowieso viel zu viel Fokus auf Mainstream-Müll. Über Unison bspw. redet kaum jemand.
"Vom Bun Hype hört man nix mehr"
MEME
74k github stars
🤡
Die Anzahl der Sterne auf GitHub sagt rein gar nichts darüber aus, wie häufig die Software in freier Wildbahn produktiv genutzt wird.
Ich verstehe, was Du mir sagen willst, aber GitHub-Sterne sind da (IMHO) die falsche Metrik.
Deno hat keine lock-Datei für Pakete? Dann ist Deno im Business-Umfeld vollkommen unbrauchbar und nutzlos. Gerade aus Security-Sicht MUSS es eine lock-Datei geben, damit nicht plötzlich ungewollt ein unsicheres Sub-Package installiert werden kann. Und eine effektive Vulnerability-Prüfung ist ohne lock-Datei auch unmöglich.
Wenn das so wäre wie von dir beschrieben, wäre Deno tatsächlich ungeeignet. Man muss aber das große Ganze sehen. Stichwort sind hier das permission system und url based versioning. Außerdem kannst du deine Abhängigkeiten auch in einer depts.ts festhalten. Braucht man aber nicht. Deno ist eben kein Node
Wie kann man sich anmaßen, zu denken, die Leute die Deno entwickeln wüssten das nicht viel besser als man selbst? Mir unbegreiflich
@@geeksy2278 Ah, ich verstehe. Also anstatt eine einheitliche Lösung, die bei jedem identisch ist, wie bei Node, gibt es bei Deno mehrere Lösungen, die alle nur so halbgar sind? ;)
Abgesehen davon geht es mir nicht um direkte Dependencies. Die sollte man in seinen Endanwendungen sowieso nicht mit Version-Ranges einbinden. Es geht mir um Sub-Dependencies und Sub-Sub-Dependencies und so weiter.
und wie viel bekommst du von deno? schonmal irgendwie daran gedacht warum deno so viel geld für PR ausgibt?
Ich bekomme von Deno genauso viel wie von allen anderen, wo wir Technologien vorstellen - nämlich nichts. Ansonsten wäre das hier auf RUclips auch als gesponsertes Video gekennzeichnet.
Komm zum Punkt warum redest du so um den Brei
keine Geduld für nen 13 Minuten Video? o.O
Wieder einer, der glaubt, alles ginge schnell schnell auch ohne Kontext. Holzweg.