The State of Nuxt

Hallo und herzlich willkommen zu einer neuen Folge der Programmierbar. Heute haben wir wieder ein Deep Dive vorbereitet und diesmal sprechen wir über NACST und alles, was es da so Neues gibt. Ich bin Jan und mit mir im Studio. Ist Sebi. Hallo. Und auch für diesen Deep Dive haben wir uns einen Gast organisiert, einen Experten zum Thema, damit Sebi und ich nicht nur mit ungesundem Halbwissen glänzen müssen. Heute ist für uns mit dabei der Alex. Hallo zusammen. Schön, dass du da bist. Alex war schon mal bei uns zu Gast. Ich glaube im Meetup auch und auf alle Fälle im Podcast in der Deep Dive Folge 76 habe ich vorhin noch mal angehört. Also werden noch mal Core Intro zu Nachst will, dem sei auf alle Fälle die Folge 76 empfohlen und auch die Folge, die ich vor dem Archiv gesucht habe, '66, wo wir das allererste Mal über Naxt gesprochen haben. Und weil ich ja kein Nachst Experte bin und bestimmt ganz viele Leute da draußen auch nicht. Daher gleich mal die ersten zwei Fragen an Alex. Was ist Nachst und warum soll es mich interessieren? Genau. Also ich fange erst mal so rum an, wenn man nichts mit Webentwicklung im Hut hat und auch überhaupt keine Webseiten bauen möchte, ist es wahrscheinlich gar nicht so interessant. Wenn man sagt okay, ich möchte irgendeine Web-Anwendung, sei es eine Website, eine kompliziertere App bauen oder ähnliches, dann ist Nachst schon wieder hoch relevant. Nacst ist ein Framework, basierend auf einem anderen Framework, wie man das heutzutage so schön nennt, Meta-Framework, basiert auf View. View macht ganz viel Spaß, insbesondere wenn man noch vielleicht nicht so viel Ahnung hat von Frameworks, weil die Einstiegshürde ist nicht so hoch und die Lernkurve ist wunderbar. Gerade wenn man sagt okay, so ein bisschen JavaScript, HTML, CSS kenne ich, aber mit so Frameworks habe ich nicht gearbeitet, kommt man da wunderbar rein. So ging es mir damals auch vor sechs, sieben Jahren so was in der Richtung. Und ja, Nax basiert darauf. Und da ist so ein bisschen das Ziel zu sagen okay, wir nutzen die Macht von View, setzen ein paar gute Defaults drauf, Build Tools, Tooling, weitere Dev Tools drumherum und machen am Ende das Entwickeln von Apps noch deutlich einfacher, sodass man auch sagt okay, man hat eine schnellere Time to Market, hat eine wunderbare Dev Experience und vor allem man kann deployen, wo man möchte. Wir sitzen ja heute nicht ohne Grund zusammen, sondern wir wollen ja sprechen über die gerade abgeschlossenen Next Nation. Und deswegen die zweite Frage sozusagen direkt an Alex Was ist die Next Nation und was hast du damit zu tun? Ja, die NX Nation ist eine Konferenz, die findet komplett Remote statt, ist auch gratis. Das ist meiner Meinung nach eine der besten Sachen an den Remote Konferenzen meistens. Total free. Es gibt Talks rund das Framework Nax. Js. Das ist auch so ein bisschen eine Besonderheit, weil das ist die einzige mir bekannte Konferenz, die sich rund Nax dreht. Es gibt natürlich viele View Konferenzen, wo auch Nax ein wichtiges Thema ist, aber insbesondere bei der Next Nation geht es ja wirklich rund Nax. Js. Ja, was habe ich damit zu tun? Gar nicht so viel. Ich bin weder Organisator noch Co, aber ich habe einen Talk gegeben. Ich war Teil von einem Panel und es gab auch so zwischendurch ein paar kleine Videoclips mit kleinen Wissenshäppchen, die nennen sich Multi Bites. Da habe ich auch ein paar beigesteuert. Genau. Und wie bist du dazu gekommen? Ja, also typisch wie bei Konferenzen füllt man natürlich einen Call for Paper aus, zu sagen Hey, okay, ich hatte ja einen interessanten Talk. Vielleicht hättet ihr ja Lust, den mit aufzunehmen. Für die Malti Bites, da habe ich mit den Organisatoren tatsächlich geredet, weil ich jetzt auch mehr und mehr Richtung Content Creation mache und dachte Okay, das wäre ein ganz guter Fit. Das hat es ja auch letztes Jahr schon bei der Nax Nation mit vorbereitet, wo ich dann nicht mit beigewirkt hatte. Hatte ich aber auch einen Talk gegeben und habe dann gesagt klar, logisch, ich bereite gern so zwei, drei Videos vor mit eben so ein, zwei Minuten Inhalt, was ganz gut verdaulich ist und habe die entsprechend eingesendet. Und fürs Panel, gut, da ich Teil vom Nax Team bin, war da entsprechend die Frage, ob ich gerne mit beim NACST Team-Panel mitwirken möchte zusammen mit einigen anderen aus dem Team, also Pouya, Antony Fou, Daniel Row, das ist ja der Lead und Sebastian Chopen, also Atinux, einer der Gründer von oder der ursprünglichen Autoren von NACST. Kann man deinen Talk auch im Nachgang noch gucken oder war das nur live und online? Ja, den kann man im Nachgang gucken. Link, der ist dann in den Shownotes, denn die werden, glaube ich heute gepublished. Also ich glaube, meiner ist jetzt zu dem Zeitpunkt der Aufnahme noch nicht online. Aber spätestens wenn ihr das da gerade hört, ist er live und der Link ist zu finden. Absolut. Kannst du jetzt ganz kurz noch einen Pitch machen? Was war dein Talk? Was war dein Thema? Und warum sollte man den unbedingt gucken? Genau. Also auch hier, wer von Angst noch keine Ahnung hat, vielleicht gerne erst mal ein bisschen mit dem Framework vertraut machen. Denn ich habe so acht Sachen vorgestellt, die nicht so sehr bekannt sind. Also sind Funktionalitäten im Framework, die sind super nützlich in den meisten Fällen, aber zu wenig Entwickler kennen die, weil es vielleicht noch nicht super dokumentiert oder experimentell oder auch eine der Sachen war brandneu. Dadurch, dass ich aber als Web Engineering Consultant tätig bin und auch hier und da mit Projekten zu tun habe, wo ich sage, guckt euch mal das Feature an, das hilft euch vielleicht, verschlankt den Code, macht das Ganze besser. Ja, konnte ich da ein paar Empfehlungen zum Besten geben. Hab das Ganze verbunden noch mit bisschen Live Coding und die Leute waren soweit ich es gesehen habe happy. Cool, coole Sache. Also du arbeitest wirklich an dem Framework, an dem Code mit? Du. Bestimmst das? Genau. Ich bin, also Code Contributions mache ich mittlerweile bisschen weniger. Aber an sich, ich bin im Team. Ich kümmere mich vor allem Community Arbeit, issue-Driaging und das Ökosystem. Ich habe gerade, also bin im Team seit 2018, das sind jetzt auch schon wieder fünf Jahre und habe vor allem früher sehr viel zum Core, gerade bei NACS 2 mit, mit-contributed. Wie gesagt, jetzt ist es viel Community-Arbeit, ein bisschen Dokumentation, ein bisschen Ecosystem, Bugs fixen, issue Triation und ansonsten Fragen auf GitHub und Discord beantworten. Das Thema Content Creation, so zum Teil war ich drin, aber ich auch gemerkt habe, okay, es gibt viele Leute, die bräuchten halt so ein paar Informationen, die weit über die Dokumentation hinausgehen. Aber man kann eben auch nicht jeden Use Case dokumentieren. Und da habe ich auch gedacht okay, schreibe ich mal ein paar Blogposts, ich erstelle ein paar Videos. Genau. Und ein paar Module verwalte ich auch noch. Also ein paar Module, die man bei Nax installieren kann, zu sagen keine Ahnung, generiere mir mal ein RSS Feed aus meinen Blogposts oder hier, ich binde mal den Dienst XY ein. Da gibt es auch ganz viele, die von unterschiedlichsten Leuten verwaltet werden. Und da bin ich auch einer der Menteiner. Also du bist schon ziemlich lange mit dabei. Und vielleicht können wir das einmal als als Übergang nehmen, bevor wir auf die Nax Nation und die einzelnen Neuerungen zu sprechen kommen. Wo geht denn gerade so deiner Meinung nach mit Nax die Reise hin? Also jemand, der jetzt vielleicht die letzte Podcastfolge dazu gerade frisch gehört hat, auf unsere Empfehlungen hin. Was ist so das Fast Forward? Was sind so die zwei, drei Highlights aus den letzten paar Jahren? Die großen Änderungen, die große Richtung, über die sie Bescheid wissen müssten? Ja, Also ich würde erst mal anfangen mit Nax 3. Ist jetzt auch schon wieder ein kleines bisschen älter. Die letzte große Major Version. Da gab es halt ganz, ganz, ganz große Änderung, weil man hat halt die Upgrade von View 2 auf View 3. Das an sich ist ja schon mal eine Änderung gewesen. Dazu kommt aber man hat den Bundler noch geändert. Was bei NACS 2 Webpack war, ist jetzt entweder Webpack 5 statt Webpack 4 oder die übliche Variante VEAD, kommt ja auch aus dem View Ökosystem, ist aber Framework agrostisch. Dazu kommen natürlich noch einige interne Änderungen und vor allem da halt Clean-Ups, Breaking Changes und Co. Nacs hat eine neue Server Engine bekommen, die nennt sich Nitro. Die ist super nützlich, damit man auch auf Serverless gut unterwegs ist, damit man überall deployen kann. Und das Schöne ist auch, dass NaX der Kern etwas schlanker geworden ist, weil viele Funktionalitäten extra Pakete ausgelagert wurden, die man auch in eigenen Projekten auch unabhängig von NaX benutzen kann. Da gibt es eine extra Organisation für, die heißt UnJS. Und da sind dann verschiedene Sachen wie zum Beispiel eben die Server Engine, die auch mittlerweile andere Meta Frameworks betreibt mit drin. Da gibt es ein ganzes System, das nennt sich Unpluggen, Plugins zu schreiben für verschiedene Bundler, aber mit einer Unified API. Also sicherzugehen, ich muss nicht alles viermal schreiben, wenn ich Rollup und WebPack und WhatNot unterstützen möchte und so weiter und so weiter. Gibt es ganz, ganz viele Utabilities, die super nützlich sind. Gibt es da so einen gemeinschaftlichen Abstraktions-Layer? Also wenn du jetzt sagst, die einzelnen Komponenten sind im Prinzip auch so nutzbar, ist das so wie in anderen Sprachen, dass große Frameworks sich zusammentun und so einen gemeinsamen Standard für z. B. Einen Router finden? Und dann kann ich hier meine Naxx-Anwendung nehmen, aber den Router ersetzen durch was anderes? Auf welchem Level wird da raus extrahiert? Oder warum macht man das überhaupt? Genau. Leider nicht. Und so ein bisschen leider und auch gut so, weil auf der einen Seite kann man sagen, wenn alles gleich wäre, wo bleibt die Innovation? Auf der anderen Seite ist dann eben auch so ein Wechsel von ich möchte jetzt keine Ahnung meine NACS Anwendung in ein anderes Framework portieren natürlich auch schwierig. Das geht auch erst mal auf das Framework Level zurück. Also wenn ich sage, ich will von Vue zu React wechseln, ist es halt trotzdem eine größere Umstellung. Eine Sache, das hat jetzt gar nicht so viel mit NACS zu tun, aber woran gearbeitet wird, ist Signals, die ja im Angular Umfeld und im React und Solid Umfeld und Co. Populär sind, die entfällt nicht so sehr, weil unsere Reactive API eh schon sehr Granular ist, dass die standardisiert werden und dann in allen Frameworks zur Verfügung gestellt werden. Da arbeitet man gerade dran, die ganzen Framework Autoren zusammen, da eine Möglichkeit zu finden, das zu standardisieren, sozusagen. Was Nitro angeht zum Beispiel oder an JS generell geht es eher darum, dass man sagt, gut, wir haben die Funktionalität und anstelle die im NACST Kern zu lassen, wie es bei NACST 2 der Fall war, extrahiert man die lieber, zu sagen, gut, okay, zum einen, man kann es eben dann in anderen Frameworks nutzen. Es ist isoliert testbar, es hat eine eigene Verantwortlichkeit und man muss nicht sagen, da ist alles in dem Kern drin. Und der Hintergrund, dass Nitro dann auch für andere Meta Frameworks wie zum Beispiel analog, JIRs im Angular Umfeld oder Solid Start und bald auch weitere genutzt wird, hat den Hintergrund, dass man auch da sagt okay, die jeweiligen Frameworks werden erst neu gebaut oder wurden in den letzten Monaten, teilweise Jahren neu gebaut. Man will da aber das Rad nicht neu erfinden und sagt okay, warum den Aufwand machen, wenn es da was gibt, das ist genutzt, das ist Battle testet, weil es eben auch in NaX, was ja ein sehr großes Meta Framework ist, genutzt wird, zum Einsatz kommt, dann nehme ich das lieber, guck wie ich das integriere und habe da eben die Benefits. Das sind jetzt eher so die Benefits für Außenstehende oder Neuankömmlinge in dem Ökosystem. Aber was ist der Treiber dafür? Naxt selbst. Also wie profitiere ich als reiner Naxt Nutzer davon? Genau. Also als Naxt Nutzer natürlich erst mal der große Bonus ist die Pakete selbst sind einfacher testbar für uns, also für das Entwicklerteam. Wir haben also nicht das Problem, okay, hier gibt es eine Funktionalität, die sagt, die ist tief im Kern. Jetzt muss ich gucken, schreibe ich dafür vielleicht einen Test, sondern es sind halt eben einzelne Pakete, die auch wie gesagt dann in anderen Projekten genutzt werden können. Zum Beispiel kann man auch sagen okay, ich brauche kein ExpressJS mehr, ich nehme einfach ein ITRO, das funktioniert besser, könnte man sogar fast sagen, nicht nur genauso, sondern besser. Es gibt ein Kompatibilitäts-Layer, dass ich sage, ich kann trotzdem noch ExpressMitarware benutzen und so weiter und so weiter. Als NACS-Nutzer zum Beispiel mit der neuen Server Engine, hatten die großen Vorteile, dass wenn neue Features in diese Server Engine kommen, können die halt auch NACS-Nutzer direkt nutzen, wenn sie da entsprechend updaten. Das heißt also, selbst von anderen Contributoren sagt okay, ich sage mal, das Hollistat braucht das und das Feature, das wurde implementiert. Oder jemand hat gesagt, ich nutze Nitro, ich möchte das gerne einbauen oder ich fix ein Bug in einem Paket. Muss das nicht zwingend ein Nax-Nutzer sein, sondern kann es einfach jemand sein, der JavaScript und TypeScript mag. Aber habe ich das richtig verstanden, dass im Prinzip alle Komponenten dadurch ja auch einzelner updatbar sind? Das heißt, ich habe nicht mehr diese eine große NACST Dependenc, sondern ich habe mein Ende und mein Auto, mein was weiß ich nicht alles und kann die bei Bedarf auch einzeln hochziehen und muss aber auch nicht alle gleichzeitig hochziehen, wenn ich da Angst vor irgendwelchen Breaks oder oder. Sowas habe. Genau richtig. Also natürlich, NACST setzt bestimmte Versionen voraus, aber man kann natürlich sagen okay, ich halte was zurück und Patch da was, oder ich ziehe andere Sachen selber hoch. Genau, absolut das geht. Und eben auch kann man sagen, man muss kein Nax Update releasen, nur zum Beispiel ein Nitrow zu updaten. So ist es. Und heißt es auch, dass meine Anwendung im Großen und Ganzen schlanker werden kann, weil ich nicht immer alles aus dem ganzen Stack brauche, dass so ein bisschen Composible mir raussuchen kann, die und die Komponenten brauche ich und die und die vielleicht aber auch nicht? Absolut. Also das ist sowieso bei Naxx und Vue schon eine Sache, dass alles deutlich mehr tree-shakeable ist. Also mit Vue3 ist es auch so, keine Ahnung, ich nutze die Transition-API nicht, dann wird die entsprechend rausgeschaket. Das funktioniert sehr gut. Ähnliches bei Naxx. Wenn ich da bestimmte interne Funktionen nicht mehr nutze, dann werden die gar nicht erst mit gebundelt und damit ist das JavaScript-Bundle entsprechend schlanker und der Bildprozess funktioniert auch schneller. Ja, also ich wollte jetzt fragen, was ist so unter der Haube? Also Nitrol, erst mal macht er wahrscheinlich nur Server-Side-Rendering, also in dem Kontext irgendwie Sinn. Nax kann wahrscheinlich nach wie vor auch einfach nur HTML-Seiten raus generieren. Und ich interessiere mich so ein bisschen für diese, was Astro irgendwie hat, diese Island oder sowas. Und gibt's das auch? Vielleicht musst du einmal für die Leute da draußen erklären, was Astro-Islands sind. Das ist eine gute Idee. Das wäre cool, wenn mir das nochmal jemand … Ich bin mir nicht ganz sicher, aber ich glaube, dass dann die einzelnen Teile separat geladen werden können, zumindest das JavaScript von irgendwelchen Widgets und das nicht alles zusammen mit der Seite auf einmal kommt. So habe ich es irgendwie abgespeichert. Aber bitte korrigiert mich. Genau. Also am Ende der AStRO verfolgt eben diesen einen Ansatz, die eine Architektur und die macht, denke ich, auch viel Sinn, dass man sagt okay, standardmäßig haben wir keine Reaktivität überall und wir müssen nicht die JavaScript-Lizenten für die halt immer statisch bleiben. Das heißt also, wir haben auch keinen Hydration-Prozess. Bedeutet irgendwie, wir rendern Daten auf dem Server, wir müssen da irgendwie Json mitgeben. Also die Daten, die vom Server sind, der State sozusagen vom Server an den Client, irgendwie das Client Framework wie View oder React, wo man sagt, hier ist der State. Ich gehe jetzt durch den Dom, nehme alle Elemente und mache die wieder reaktiv oder bilde mir mal einen Virtual Dom daraus. Das hat man alles nicht, was natürlich bedeutet, performanzechnisch ist das Ganze deutlich schlanker. Wenn man jetzt aber doch sagt, okay, ich brauche hier Reaktivität, wenn der Button klickt, dann möchte ich gern da ein Model haben, dann hat man eben so eine reaktive Island, also wirklich so einen kleinen Teil, und da kann man dann sagen: „Gut, wenn das gebraucht wird, dann lade ich eben das JavaScript nach, dann ist das reaktiv, dann hole ich mir den State und kann damit sagen: „Okay, der initiale „Load funktioniert relativ gut, da brauche ich nicht so viel JavaScript, sondern nur an den Teilen, die wirklich interaktiv sind. Genau so viel zu Astro. Bei NACST ja, das ist auch ein Ansatz, der sehr interessant ist und wir verfolgen den auch. Bei uns heißt es aber Server Components, auch da nicht zu verwechseln mit zum Beispiel React Server Components. Hier ist die Idee, NACST ist ja erst mal per se ein Framework, was eben auf Vue und JavaScript basiert. Bedeutet aber, wir drehen den Island Ansatz einmal und sagen okay, wenn es Teile gibt, die statisch sind und die sich nicht ändern, dann haben wir dafür eine Route, die wird entsprechend über Nitro abgebildet intern. Wir sagen einfach, diese Komponente ist Server-only und dann wird entsprechend statt JavaScript anzufragen, einfach diese Nitro-Route angefragt, die dann HTML zurückgibt. Also auch da HTML in Json, was dann genommen wird. Das Schöne ist, diese Server Components können auch State haben. Also wenn man sagt, man hat irgendwie Props, die da reingegeben werden, die ändern sich, wird dann auch der Request noch mal neu durchgeführt und es gibt upgedatetes HTML. Erinnert vielleicht so ein bisschen an Letter of Life Wire oder Hot Wire oder ähnliches, wenn das was sagt. Und das ist auf jeden Fall ein Ansatz, den wir verfolgen. Der nächste Schritt jetzt, da sind wir gerade dabei, ist, dass wir dann wiederum reaktive Teile in diesen Server Components haben können, dass man also am Ende sagt: „Okay, wir haben einen Server Component, der ist an sich nicht interaktiv, aber Kindkomponenten können wieder aktiv sein, zum Beispiel so was zu haben wie „Okay, wir haben Links in einem Server Component, dann sollen die aber on-Click trotzdem funktionieren wie bei einer Single Page Application. Das ist der nächste Schritt. Da gibt es einen Pair, der schon offen ist. Und ich sage mal, eines der Ziele oder Visionen kann natürlich auch sein zu sagen, okay, unsere komplette Anwendung ist erst mal so eine Serverkomponente mit eben einigen kleinen reaktiven Inseln. Und da sind wir wieder bei dem, was Astro macht. Jetzt kann man natürlich noch mal einen Schritt weitergehen. Das wollte ich noch mal aufgreifen mit dem Thema Server-Seite Rendering. Auch mit NAC3, was relativ neu dazugekommen ist. Wir haben etwas, das nennt sich Routours und können sagen: „Für unterschiedliche Pfade und unterschiedliche Seiten haben wir unterschiedliche Regeln. Zum Beispiel, wir haben eine große Anwendung und die besteht aus Landingpages, aus einem Admin Dashboard, aus Blogbeiträgen. Und dann können wir sagen: „Okay, unsere Indexseite, die wird auf dem Server generiert, aber die wird via „Stayl bei Revalidate alle 30 Minuten neu im Background validiert, dass wir sagen: „Okay, alle 30 Minuten gucken wir mal, ob es geupdateten Content gibt oder alle paar Sekunden, aber der Nutzer bekommt den alten Content im Hintergrund revalidiert und für den neuen Nutzer gäbe es den neuen Content. Genauso kann man sagen: „Okay, das Admin Dashboard, das braucht ja gar kein Server-Set Rendering, das ist ja hinterher eine Authentifizierung. Dann nehmen wir das einfach als gute alte SPA und sagen für den Teil „Server-Set Rendering schalten wir aus. Und die Blogbeiträge, da können wir sagen: „Na ja, gut, das sind vielleicht ein paar Blogbeiträge, die generieren wir vor und machen da ein bisschen „Static Site Generation. Heißt, wir können also auch all diese unterschiedlichsten Rendering-Modes kombinieren und haben damit den Vorteil zu sagen: „Okay, wir brauchen nicht nur Server-Sendering, ja, nein, oder SPA, ja, nein, sondern können eben auch so was wie Inkremental Static Regeneration machen, also Static Sight Generation on Demand. Wir können wirklich das Pre-Rendering machen. Wir können alte SPAs rendern und auch klassisches Server-Set Rendering machen. Das klingt ja cool. Es ist auf jeden Fall sehr nützlich, weil es gibt meistens Anwendungen, die alles mögliche wollen. Wie wir es gerade so gesehen haben, so ein Beispiel mit Admin Panel braucht kein Server-Set Rendering, Blockposts, wollen wir vielleicht inkrementell generieren oder vorgenerieren, je nachdem wie viel es sind. Und das ist auch einer der Funktionalitäten, die nicht viele Frameworks in dem Bereich auf jeden Fall können und was sehr hilfreich ist. Ja, ist auf alle Fälle auch etwas, was wir auch auf unserer eigenen Website gesehen haben. Das ist ja das Interessante daran, die Mischung zwischen dem statischen und dem dynamischen Content. Genau. Cool. Abgesehen davon – und jetzt sind wir schon ein bisschen schlauer –, was waren denn so deine Highlights von der Nax Nation? Ja, auf jeden Fall von der Nax Nation. Ich würde sagen, erst mal die Diversität an Talks, die es gab. Also es gab ja die unterschiedlichsten Themen. Ich fand zum einen natürlich State of Nax, das ist immer ganz schick zu sehen. So, was ist denn passiert in den letzten, ich glaube, elf Monaten, seitdem Nax 3 rausgekommen ist, wie viel Downloads gab es? Wie viele Leute nutzen NaX 3 zum Beispiel, wie sieht das mit Modulen aus? Das war auf jeden Fall ganz schick. Es war schön über UnJS ein bisschen mehr zu erfahren, was Pouya erzählt hat. Der NaX Layer Talk war ganz nett von Kruti. Das Thema selber hatte ich zum Beispiel letztes Jahr einmal rudimentär aufgegriffen, weil auch NaX Layers, das ist eines der Features, das ist fast schon ein Alleinstellungsmerkmal. Kann ich gleich noch mal erklären, worum es da genauer geht. Und ansonsten ich glaube auch das Highlight war so ein bisschen die Community. Es gab so viele Fragen im Chat, es gab unglaublich viele Antworten und das hat einfach Spaß gemacht. Ich war beide Tage auch als ganz normaler Teilnehmer erst am Chat, habe Fragen beantwortet, selber Fragen gestellt und es war eine super Atmosphäre, vor allem für eine Online Konferenz. Es war nur online. Genau, es war nur online. Richtig. Ich habe noch eine Frage zu dem Sebastian Chaupein. Ja. Habe ich hier nicht irgendwas gelesen, dass der gewechselt ist? Nee, das war sein Bruder. Das war Alex. Okay, aber der war auch Mitgründer, Mitautor, Mit-. Genau, also Alex Alex und Sebastian haben Nax zusammen auf die Beine gestellt. Das war 2016, 2017, so was in der Richtung, glaube ich. Nagel mich darauf fest, aber auf jeden Fall vor 2018. Und die beiden haben auch zusammen eine Firma gegründet, die heißt Naxlabs, wo die Firma, ihr da ist zum Beispiel Sponsor, Leute aus dem Open Source Bereich, ist aber an sich erst mal nicht für die Entwicklung von Nax zuständig, sondern von Sachen drum rum. Auch da, ich bin nicht angestellt bei Naxlabs oder ähnliches, das nur als Transparenzhinweis. Ich arbeite zwar mit Naxlabs hier und da zusammen, gerade beim Thema Consulting, aber ansonsten habe ich nichts mit Naxlabs zu tun. Und da ging es eben darum, also Sebastian selber ist CEO der Firma. Alex war, glaube ich, CIO oder so und ist jetzt eben zu Direktor gewechselt. Und das hat aber mit der Entwicklung des Open Source Frameworks erst mal nicht viel zu tun. Da hat Daniel Row, den Lead, ist also für da effektiv für die Aufgabenverteilung, für die das Big Picture sozusagen verantwortlich. Und der Rest des Core Teams hilft dann bei der Bearbeitung, bringt neue Ideen ein und natürlich auch die ganzen Leute, die Contributen, die Module bereitstellen. Und jeder, der selbst ein Typo bei den Docs editiert, hilft auf jeden Fall. Sehr schön. Ich wollte ja gerade fragen, weil du meintest, es war nur eine reine Online Konferenz. Und du hast gesagt, trotzdem war irgendwie die Community ganz, ganz cool. Was hat denn Next Nation so gemacht, so dieses Gemeinschaftsgefühl online irgendwie zustande zu kriegen? Weil das ja für ganz viele Veranstaltungen immer so eine Challenge ist, auf so einen rein Online Kanal wechselst, dann trotzdem irgendwie alle Leute mitzunehmen, zu begeistern etc. Was lief denn da deiner Meinung nach besonders gut oder was war nicht so gut, was kann man verbessern? Aber was können Leute da draußen lernen, mitnehmen von der NACS Nation? Genau. Ich fand die Interaktion an sich ganz gut. Es gab eigentlich nach jedem Talk ein Q&A, was auch immer ganz nett ist, weil dann weiß man gut, wenn ich Fragen im Chat stelle, dann gibt es auch eine ganz gute Chance, das sagen die mit aufgenommen werden, dass ich auch meine Frage beantwortet bekomme. Ansonsten, es war auch sehr wichtig, dass eigentlich sehr viele Leute, die Talks gegeben haben, ich glaube fast alle waren entsprechend auch im Chat aktiv, haben also da nicht nur während des eigenen Talks, weil da haben sie ja einen Talk gegeben, sondern davor, danach an anderen Tagen mit der Community interagiert. Und ja, diese Chatfunktion ist natürlich super wichtig, gerade wenn man sagt okay, was gibt es Neues? Man weiß, man kriegt eigentlich auf jede Frage eine Antwort, selbst wenn es eine Antwort ist, die sagt okay, lass mich noch mal das nachreichen oder lass mal da und da schauen. Und ich glaube, zum großen Teil macht es auch die NaX to New Community, weil da fühlt sich eigentlich jeder auch direkt willkommen. Es gibt nicht so ein Gate, so ein Gatekeeper Attitüde oder ähnliches, sondern jeder, der auch eine Frage hat, der wird nicht erst mal wie doof ist das denn? Sondern einfach willkommen und sagt okay, hey, guck mal mal oder schau mal da. Ich denke, das trägt auch ganz viel dabei. Was war dein Talk? Mein Talk hieß, sagen wir NaX to Hidden thesures, 8 Gems, every Developer would know. Und genau da ging es eben diese acht eher weniger bekannten Funktionen. Einen davon wurde auch erst in der neuesten Version 3.8 vorgestellt. Deswegen kannte die auch noch kaum jemand. Dazu habe ich tatsächlich noch mal ein ausführliches Video danach gedreht, weil ich gemerkt habe, das kam ein bisschen kurz. Leute waren interessiert. Vielleicht noch mal kurz 10 Minuten Video danach entsprechend nachschieben. Genau. Ansonsten ging es viele Sachen, die schon länger dabei sind, aber die eher, ich sage mal, eher weniger Anklang finden, weil sie einfach nicht bekannt sind oder weil es zum Beispiel, es gibt ein Kommando, wo man sein Bündel analysieren kann, also mit Naxi Analyse, Naxi ist das hier, das ist das Ziel von NACTS. Und gerade zum Checken der Performance hilft es extrem, erst mal zu sehen, okay, was wird denn gebundelt, wie wird das Ganze aufgeteilt? Und dann sieht man, oh, vielleicht habe ich irgendwo eine Dependency, die super riesig ist und alt. Deswegen werden da nicht nur die drei Funktionen gebundelt, die ich eigentlich nehmen möchte, sondern alle 100, die da genutzt werden, auf einmal habe ich da 50 Kilabyte mehr im Bundle. Also so was ist natürlich dann auch ganz nett, wenn man weiß, okay, es gibt einfach einen Befehl, da kann ich nachgucken und sieh, wie das Ganze aussieht. War das der Talk, ne die, das 10 Minuten Video über Fetch Caching? Genau richtig. Das war das Video, was ich nachgeschoben hatte. Geinfach mit Cash Data mit der Fetch API. So ist es. Ja, cool. Coole Sache. Habe ich gesehen. Ah, super. Wie fandest du das? Ja, geil. Vielleicht auch da. Vielleicht wollt ihr für die Leute da draußen einmal erklären, was das ist. Wir wissen jetzt alle, es ist geil und das Video war gut. Jetzt müssen die. Selber kurz. Es ist auch noch mal verlinkt. Das auch noch mal. Genau, wenn ich weiß, was es ist. Ich gebe gerne eine kurze Zusammenfassung in NACS 3.8. Wir haben Composibles zum Fetschen von Data, nennen sich Usefatch und Use-Azing Data. Nennt sichUseFetch und UseAzure Data in der VU3 Composition API geht ganz viel über Composibles und Reaktivität. Heißt wir rufen eine Funktion auf, die gibt reaktive Werte zurück und basierend auf deren Änderungen machen wir dann Sachen. Heißt also so ein UseFetch gibt erst mal einen Data Wert zurück und der kann erst mal null sein, weil der Call ist ja vielleicht noch nicht ausgeführt. Wenn die Daten da sind, ändert sich eben dieser reaktive Data Wert. Spannend ist es, wenn wir sagen, wir haben verschiedene Seiten in NACST und wir gehen auf Seite A, da werden Daten geladen, dann gehen wir auf Seite B und gehen zurück auf Seite A. Und jetzt ist die Frage, was soll passieren? Sollen die Daten, die wir schon mal geladen haben, wiederverwendet werden oder sollen die neu geladen werden? Weil oftmals kann man sagen, ja okay, wenn ich jetzt hier eine, keine Ahnung, eine Liste von Tweets zum Beispiel hätte, wäre es schön, wenn ich die neu laden würde. Auf der anderen Seite will man vielleicht auch sagen: Na ja, gut, ich zeig die Alten an und geb eine Option zum Neuladen. Oder es sind vielleicht Daten, die ich alle, keine Ahnung, 30 Minuten neu laden möchte oder alle 30 Sekunden und nicht sofort, wenn er wieder zurückgeht. Und das war bisher immer nur mit einer eigenen Implementation möglich, die ein bisschen, ich sage mal anspruchsvoller und mehr Workaround war. Und seit NACS 3.8 gibt es die Funktion getCashData, die effektiv sagt okay, wenn es Daten gibt, die gecacht wurden, die kannst du in der Funktion einfach abrufen und du die zurückgibst, dann werden die entsprechend so angezeigt. Wenn du aber nichts, also Null oder undefined zurückgibst, dann ist effektiv die Anleitung okay, dann bitte für diesen UseFatch Call einfach noch mal aus. Und dadurch, dass die Funktion definiert werden kann, wie sie möchte, kann man auch sagen, ich baue da so einen simplen Time to Live Mechanismus ein und sage okay, ich gucke, wann wurden die Daten gefälscht? Und wenn das halt zehn Minuten in der Vergangenheit liegt oder länger, dann fälsche ich die Daten neu, ansonsten gibt sie zurück. Kann ich da auch so was Optimistik UI-mäßiges bauen? Ich nehme erst mal die Daten, die im Cache sind, damit ich irgendwas anzeigen kann und so gefühlt das schnelle UI Erlebnis habe. Und parallel lade ich quasi schon die neuen Daten und zeigt die an, sobald ich sie habe. Das kannst du machen. Absolut. Das klappt auch schon ohne Get-Hash Data. Also das geht auch schon vorher. Dadurch, dass du auch sagen kannst, du hast bestimmte Hooks und so was wie, wenn es eine Antwort gibt, mach das und das bzw. Die Daten, die schon mal da sind, kannst du darauf zugreifen. Ja, das geht. Absolut. Ich hätte noch eine FrageGeht das nur, wenn ich eine Single Page Application habe mit dem Vor und Zurück und so? Klingt irgendwie für mich so oder? Genau. Also du bräuchtest eine Single Page Application, aber das bedeutet Server-Side-Rendering kannst du trotzdem haben. Das geht auch. Wenn du aber gar kein JavaScript mitlieferst, was in NACS ja nur möglich ist, wenn du entweder theoretisch alles in Server Components nutzen würdest, die sind dann experimentell. Das hatte ich vorhin noch nicht erwähnt, das ist noch wichtig zu sagen. Was nicht bedeutet instabil, sondern nur experimentell. Man kann sich also noch ein bisschen was ändern. Oder wenn du sagst, du gibst überhaupt kein JavaScript mit rein, dann hast du wirklich so eine ganz klassische, starre Seite. Das funktioniert halt für Landingpages zum Beispiel super. Aber das ist ja nicht in Ordnung. Deswegen da bräuchtest du eine Single Page Application. Aber ob das dann, ob der initiale Request mit Server-Seit-Rendering gemacht ist oder nicht, ist da egal. Ja, cool. Das ist ein cooles Feature. Absolut. Und ich habe ganz viel gelesen. Oh mein Gott. Genau das, diese Limitationen, da sind wir schon oft drauf gestoßen. Wir haben dann im Workaround, es gibt so ein paar Anleitungen auch im Internet, wo man sagt okay, man kann sich etwas komplizierter so ein eigenes Compose bebauen, was dann Use Fetisch wieder nutzt. Aber so ist es halt ein kleines bisschen einfacher. Ich hätte noch eine andere Frage, und zwar die mich persönlich interessiert diese Image und Pixel Komponente von NACs. Ja, gerade was, was, wie, wo, wann, warum? Also ich. Ja, vielleicht erklärst du es einfach. Ich kann jetzt ein paar Mutmaßen und sagen, wie ich es mir ausmale. Aber erklär doch mal. Gerne. Also diese Image Komponente, genau NACST Image, gibt es auch eine offizielle Doku Seite natürlich dazu. Ich glaube Image. Nax. Org ja gerade noch mal sicherheitshalber geguckt. So ist es. Und die Idee ist, es haben ja einige Frameworks und am Ende macht es auch viel Sinn, wenn wir erst mal davon ausgehen, gut, wir haben ganz klassisch so ein HTML Image Tag, wir packen da unser Image rein und fertig. Und dann kann man damit ja erst mal viel richtig machen, aber eben auch viel falsch machen. Zum Beispiel man lädt dann schön ein großes zwei Megabyte Image rein und optimiert es nicht. So hat man schon ganz oft gehabt. Man kennt es, gerade wenn man sagt okay, das kommt vielleicht von einem CMS, dann baut man die Seite und auf einmal hat man ja Lighthouse Score 20, 10 Megabyte Daten. Also einer der Vorteile von Luxed Images, dass man sagt, man kann entsprechend Größen angeben für ein klassisches Sourcset oder auch sagen okay, für den Breakpoint lgxl, die man wieder definieren kann. Bitte nimm die Breite, die Höhe. Und mit Nxt Image ist es so, dass man sagen kann Okay, intern läuft IPX, das ist auch wieder ein angepasstes Paket. Es ist so ein kleiner Image Service, der generiert dann genau diese Größen raus während des Bilds, also zur Bildzeit. Und das bringt eben den Vorteil, dass man dann sagt, man muss sie nicht alle manuell optimieren, sondern die werden entsprechend generiert. Man kann auch sagen, man nutzt einen Image Service, so wie zum Beispiel CloudMemory oder gibt es noch ganz viele Image X und so weiter und so weiter, kann die entsprechend auch angeben und kann dann die Transformation darüber durchführen, aber eben mit den Daten, die im Next Image, in der Next Image Komponente stehen. Ah, okay, cool. Also zur Bildzeit werden dann verschiedene Bildgrößen zur Verfügung gestellt und der Browser kann sich die dann über einen Source-Set nehmen? Genau so ist es. Kann man auch auf meiner Website sehen. Ich nutze da auch die Next Image Komponente auch da. Das ist alles Open Source. Also wenn der mal einen Blick wagen möchte, wie das aussieht, immer gerne. Und die Pick-Club Komponente ist dann dafür da, dass ich auch noch verschiedene Formate zur Verfügung stelle, oder? So ist es ganz genau. Und das zu kombinieren mit ich möchte WebP, Aviv, JPEG, 2000 oder wie auch immer alle ausliefern. Ich beschränke mich da meistens auf ich glaube Aviv, WebP und dann JPEG oder PNG oder was auch immer das originale Format ist. Einfach die Top acht. Dieses IPX, von dem du gerade erzählt hast, hat das, wie verhält sich IPX zu SharePoint? Ipx nutzt SharePoint unter the Hut tatsächlich, also ist eine Abstraktionsebene sozusagen drüber. Sehr spannend ist auch, dass IPX zum Beispiel von Nettlyfy genutzt wird, also von tatsächlich der Plattform, ihr neben Wirstell für so typisch statische Seiten mittlerweile auch mit Serverless Functions und Serverlesset Rendering dafür passiert, ja einer der großen Hoster ist. Und die nutzen zum Beispiel IPX auch, übersichtlich die FH Image eben die Bilder zu verbessern. Ah, cool. Da haben wir ja auch einen coolen Use Case für, warum es sinnvoll ist, so was als Modul rauszuziehen. Absolut, genau. Da kann halt am Ende, können alle mit profitieren. Natürlich auch Firmen, die entsprechend auch geltend machen, klar, aber genauso andere Open Source Projekte oder auch andere Frameworks, die sagen Hey, wir wollen auch so eine Komponente, ja, ist frei zu nutzen. Cool. Vielen Dank. Das fand ich sehr interessant. Ich mag Bilder. Verständlich. So lange sie nicht zu einem B groß sind, bin ich da voll dabei. Jetzt sind wir eigentlich über die Hidden Jams hier hingekommen. Und bevor ich meine eigentliche Frage stelle, noch einmal die Chance, noch irgendeinen anderen Hidden Jamm, den du irgendwie unbedingt nochmal pushen wollen würdest? Oh, noch irgendeinen anderen. Jetzt sponne ich ja alles zu meinem Talk. Vielleicht ist es auch etwas, was nicht in deinem Talk ist, wo das hätte vielleicht auch noch. Reingekommen ist. Das ist der neunte. Ja, es gibt tatsächlich so viele, so viele coole Sachen. Eine Sache, die ganz interessant ist, ist es gibt in dem Lachs Link Komponente entsprechend zu linken von Seite A auf Seite B und man kann das Verhalten von dem Lachs Link entsprechend auch abändern, was den Trading Slash angeht. Also man kann zum Beispiel sagen Hey, alle Links sollen automatisch einen Trading Slash besitzen oder nicht? Ist besonders super für SEO. Er sagt okay, ich habe keine öffentliche Seite, ist vielleicht weniger interessant. Aber das einmal komplett uniform zu machen, also wirklich sicherzugehen, da ist immer der Slash oder eben nicht, kann man das einstellen. Das kann man ja sogar mittlerweile in der Nax Konfig einstellen. Bis Version 3.8 ging es immer darum zu sagen Okay, ich baue mir kurz eine eigene Komponente, da gibt es so eine Define Nax Link Funktion, da gebe ich dem mit Trading Slash Behavior Append oder Remote glaube ich. Und mittlerweile geht das auch über die NaxConfig. Das ist auf jeden Fall noch ein Tipp, dass das lohnt sich das zu machen, insbesondere wenn man eine öffentliche Seite hat. Abgesehen von deinem Talk und der Nax Nation als Ganzes. Was sind denn vielleicht deine Lieblingsquellen, diese JAMs auch so im laufenden Tagesgeschäft nicht zu verpassen, wenn man sich jetzt so in das NACST Ökosystem stürzen will? Genau. Ich sage mal allen voran die Doku. Das klingt jetzt wieder ja, ob wir es, Read the Manual und so, aber das lohnt sich. Auch da ist natürlich nicht alles immer 100% topgenau beschrieben, aber zum Beispiel werden die Dokumentationen für die NACST Config, also alle Werte, die man in der Konfigurationsdatei setzen kann, die wird automatisch generiert aus dem Code und aus den js Doc oder TS Doc Kommentaren. Das hilft also, heißt auch da, wenn es eine neue Funktion gibt. Man muss jetzt nicht zehn Absätze in den Docs dazu schreiben. Es reicht halt komplett aus, wenn die ordentlich dokumentiert ist. Und zumindest das machen wir regelmäßig, wenn wir PRs mergen. Das lohnt sich. Und dann, ja, jetzt habe ich es auch schon so halb gesagt, es wird aus dem Code raus generiert. Also auch gern einfach mal in die GitHub Repository reingucken und in den Code, in das Schema, in die letzten PRs, die so gemerged wurden. Weil da gibt es meistens auch ganz gute Erklärungen, die dann auch nicht immer eins zu eins den Weg in die Dokumentation schaffen, weil es zu technisch, zu viel Vorwissen oder einfach nicht genug ausformuliert. Aber ich glaube, das lohnt sich. Und last but not least, es gibt natürlich einige Projekte, wenn man auch gerade sagt, so, Ah, NACST Ökosystem, ich guck mal rein, aus welchen Projekten kann man jetzt so viel lernen? Das ist auch immer so eine ganz beliebte Frage. Und da gibt es einige, auch für steigende Level. Zum einen gibt es die NACST MOWies App, die gibt es auch für andere Frameworks, dass man sagt, okay, in Angular, in Next. Js und Co wird die fast gleiche App gebaut mit ähnlichen Funktionalitäten, dass man es so ein bisschen vergleichen kann und man kann sich eben den Code anschauen. Also wenn man sagt, ich kenne mich in Angular aus, aber keine Ahnung von Nax oder ich kenne mich in Next. Js aus, keine Ahnung von Nax, dann kann man die App hernehmen, mal schauen, was passiert da? Okay, ich verstehe das dort. Ja, so macht das hier Sinn. Das ist immer ganz super. Und etwas mehr, ich will sagen, etwas tiefergehend, gibt es einen Masterplan Client, der nennt sich Elk. Der wurde gebaut von Leuten aus dem Vee Team und aus dem NACS Team. Der ist komplett Open Source, hat mehrere tausend Nutzer im Monat. Also ist glaube ich eine der wenigen Applikationen, die nicht nur so typisch Education mal gebaut wurde, sondern die wirklich regelmäßig genutzt wird und auch über eine Website oder einen Blog hinausgeht und Open Source ist. Und das ist eine reine Frontend Anwendung? Das ist auch wieder lustig. Jein, da ich das nutze, den Mastron API, also sozusagen. Aber mit der Server Engine von NACS kann man auch eine eigene API bauen. Also sagen okay, wenn da ein Server läuft für Server-as-a-Drendering, dann kann der auch API Endpoints ausliefern und und Routen. Heißt so halb. Okay, das. Wäre ja auch eine interessante Challenge gewesen, das ohne Backend und ohne eigenen State zu machen, nur auf der Masse dann API aufbauen, sozusagen. Das einzige ich glaube, da müsste ich noch mal tiefer gucken, ist so was wie zum Beispiel Caching ist natürlich super hilfreich, wenn man sagt … Man hat da so ein bisschen Backend for Frontend mäßig. Ich glaube, das ist auch so einer der üblichen Patterns oder so was wie keine Ahnung, ich liste die Master und Server. Aber ansonsten wird das primär über genau die Mastodon API genutzt. Ich gucke gerade noch mal kurz rein, aber ich sehe okay, das einzige was ist genau das Auflisten der Server, Caching und Oauf, also Authentifizierung. Ja, okay. Ich glaube, das zählt mal als Teil. Das ist kein Backend. Das ist okay. Ja, ist cool. Also ich fand auch den Hinweis mit so einfach mal die letzten PRs von so einem Projekt, von so einem Framework irgendwie oder wahrscheinlich auch für jedes Library da draußen, einfach mal reingucken und gucken, woran da gerade so gearbeitet wird, was die neuesten Sachen sind. Und insbesondere vor dem Hintergrund, dass jetzt die Einzelpakete ja hoffentlich ja dann auch schneller und unabhängiger voneinander releast werden können, ist ja auch die Chance, dass so ein PR, den du heute geschlossen siehst, dass der, ich weiß nicht, morgen, übermorgen schon bei dir in der Codebase sein kann, ist ja dann wahrscheinlich auch relativ hoch im Vergleich zu so klassischen Release Zyklen. Ganz genau. Das ist eben auch einer der Vorteile, wie du es gerade gesagt hast. Unabhängige Versionierung bedeutet eben auch okay, wir können schneller Bugfixes releasen und müssen uns nicht mit dem kompletten Ökosystem abstimmen. Versionierung ist ein gutes Stichwort. Unabhängige Versionierung. Gibt es so ein gemeinsames Versioning Pattern, wo sich alle dran halten? Also sagen wir, wir gehen alle – weiß ich nicht – die Major Version gleichzeitig hoch oder machen nur HotFixes voneinander unabhängig? Oder gibt es da irgendwas oder ist es mehr so free for all und jede Komponente geht halt hoch, wie sie gerade braucht? Also alles was Naxx unabhängig ist, hat eine eigene Versionierung und alles was Naxx abhängig ist, also wirklich Naxx selber, da ist auch so ein bisschen eine Monorepo mit verschiedenen Paketen, die gehen zusammen. Da hat man zum Beispiel auch so was wie die Naxx Dev Tools. Das gehört alsowird mittlerweile mit Naxx mit ausgeliefert. Das ist so ein bisschen wie die View Dev Tools, nur eben für Naxx. Und ich habe auch von ganz vielen Leuten aus anderen Ökosystemen schon gehört, hey, warum haben wir das nicht? Lohnt sich also auch, sich das mal anzuschauen? Das ist dann auch wieder was, was eigenständig personalisiert wird, weil da macht es nicht so viel Sinn zu sagen: „Gut, okay, wir müssen das jetzt synchronisieren. Das ist halt zu weit weg, als dass es Sinn macht. Oder dann zu sagen: „Oh ja, jetzt geht hier die Miner Version hoch, jetzt müssen wir das überall bampen. Das ist ein bisschen tricky. Ja, ich habe überlegt, wie das für für Neulingen im Ökosystem dann ist, wenn du dann merkst in Version 3, deine Link Komponente in Version 10, deine Image Komponente in Version. Also woher habe ich dann so ein Gefühl für ist meine Anwendung insgesamt irgendwie aktuell, wenn das alles so ein bisschen sehr auseinander wächst? Also das Gute ist ja, der Kern ist ja trotzdem gleichversioniert. Und dann hat man natürlich die einzelnen Versionierung der Module, zu sagen okay, keine Ahnung, in Next Image, wir müssen jetzt einen Breaking Change einführen, weil die darunterliegende Library sagt: „Okay, hier, wir supporten das nicht mehr oder „Wir müssen zum Beispiel eine Node Version, wir supporten die nicht mehr, dann können wir das halt machen, ohne zu sagen, der Core ist damit beeinflusst. Und wie man das natürlich immer macht, wenn mans die their tendencys hat und die updatet und die Major Version ändert sich, guckt man natürlich in den Logs, sieht man Bracking Changes. Was passiert da? Am Ende ist es aber meiner Meinung nach besser, lieber regulärer Bracking Changes zu haben. Also zum Beispiel bei Naxx ist auch das Ziel. Naxx 2 zu Naxx 3 hat ja wirklich lange gedauert, einfach weil es gab halt so viele Änderungen, auch intern und auch View 2 zu View 3, wie und so weiter und so weiter. Das soll bei Naxx 3 zu Naxx 4 deutlich angenehmer werden, dass man also sagt okay, da hat man nicht gefühlt ein halbes Jahr Migration vor sich, je nachdem wenn man einen riesigen Shop hat und nicht so viele Leute. Aber ich habe da auch schon einige Migrationen mit begleitet und das kann dauern, kann auch super schnell gehen. Manchmal sind es auch Re-Writes, aber bei Naxx 3 zu Naxx 4 geht es wirklich eher darum, okay, es gibt ein paar Breaking Changes. Im besten Fall kann man da schon eher via Optin, das wollen wir bald einführen, so eine Future Flag haben zu sagen, gut, das wird passieren, wenn ihr das schon mal vorbereiten wollt, könnt ihr machen. Am Ende müsst ihr nur diese Flags rauslöschen, dann ist gut. Und einige Sachen, die werden halt schwieriger vorzubereiten sein, aber das soll deutlich angenehmer werden. Future Flags habe ich auch schon mal in Remix gesehen, da habe ich das zum ersten Mal gesehen. Aber es ist ein interessantes Thema. Was sind zum einen aus eurer Sicht noch Schritte, die ihr gehen könnt oder wollt, die Migration eben einfacher zu machen für die Nutzer draußen? Und was kann ich als Nutzer von NACST auch tun, mich quasi schon vorzubereiten und mir den Weg möglichst einfach zu machen später? Ja, also wenn wir jetzt erst mal davon ausgehen oder ich fange noch mal einen Schritt vorher an, die Future Flags kenne ich zum Beispiel vor allem aus Tailwind. Da habe ich die zum ersten Mal gesehen. Was so kommt. Also bisher haben wir nichts großartig auf der Liste, wo wir sagen Oh mein Gott, das sind jetzt Developer Facing, riesen Changes. Es sind halt vor allem Sachen auch für Modulautoren, zu sagen Gut, okay, da sind die Anpassungen hier und da, da können wir mithelfen, da können wir ein paar PRs senden. Das wird eher unproblematisch. Sobald wir aber was haben, wir sagen: „Wir wissen, das soll definitiv geändert werden. Wir wollen diesmal von Anfang an natürlich auch einen Migrations Guide schreiben, schon mal step by Step zu sagen: „Das werden die Änderungen sein. Erst mal mit den Future Flags sagen: „Hier könnt ihr opt-in. Es wird sicher kommen. Dann könnt ihr euch schon mal darauf vorbereiten. Ansonsten auch das Thema Code Mods. Das ist immer ein bisschen tricky, weil wir hatten auch am Anfang gedacht, NACS 2 zu NACS 3 Code Mods wären schön. Dann hat man aber das Problem, es gab so viele Änderungen und auch so viele interne Änderungen, so viel Dependency Änderungen, dass man halt. Es gab halt tausend Wege was zu machen und man kann halt keine Code mit schreiben, die tausend Sachen abdeckt. Ansonsten haben wir NACS Bridge aktuell, was zum Beispiel von zwei zu drei die Migration einfacher machen soll. Da ist die Idee, Features von NACS 3 weg zu porten auf Nax2. Das klappt. Vor allem jetzt haben wir auch viel Unterstützung von der Community, die das immer besser und besser mitmachen. Und Nax Bridge ist auch so ein Thema an sich eine sehr gute Idee. Gerade so als Kompatibilitäts-Layer. Braucht halt wieder viel Arbeit und ich hoffe, dass wir das von NACS 3 zu NACS 4 nicht so brauchen. Das wäre jetzt auch so meine ketzerische Frage gewesen an der Stelle. Also Feature Backposten oder die Bridge bauen, das ist ja schön und gut und macht es natürlich sehr bequem für Leute, die noch nicht Upgraden wollen, können, dürfen, wie auch immer. Aber gleichzeitig muss man sich doch schon auch die Frage stellen, ist das wirklich die beste Verwendung von Zeit und Energie? Absolut. Versus nicht einfach generell mehr Aufwand in eine einfachere Migration, in Dokumentation etc. Zu stecken, die Leute wirklich mitzunehmen und das ihnen nicht noch, also überspitzt gesagt, einfacher zu machen, auf der alten Version zu bleiben. Da ist halt die Idee, die Bridge macht das tatsächlich auch, indem wir sagen: Hey, du kannst effektiv NX3 mit den NX2 Kompatibilitäten laufen lassen und dann Step by Step Features hinzufügen. Also du hast dann auch wieder Feature Flags, wo du sagst okay, bitte schalt mal Nitro, die Server Engine ein, bitte schalt mal Composition API ein, mach mal das und das. So kann man halt Step by Step sagen okay, ich so klassische Migration, ich schreib meine Komponenten in zum Beispiel die Composition API Dann schalte ich das ein, dann mache ich das, dann dies und wenn man eh schon Tests hat, ist ja nicht immer gegeben, aber angenommen man hat ein Projekt mit Tests, kann man die halt Step by Step durchlaufen lassen und sieht dann wo es hakt. Oder man sieht: Oh, ich habe irgendwie einen WebPack Loader Custom geschrieben oder mal vielleicht 10, die kann ich nicht einfach ersetzen. Das heißt, ich lasse erst mal WebPack drin, mach den Rest schon mal und guck dann: Na ja, klappt das mit WebPack fünf? Ist das Upgrade zu wie sinnvoll? Also die Bridge soll schon eher helfen, so eine Art smoothe Transition zu ermöglichen. Aber es ist natürlich tricky und der Zeitaufwand, keine Frage. Vor allem, wenn man jetzt sagt: „Fetcher Flags, super. Ja, aber man kann auch nicht alle Kombinationen von allen Feature Flags mit allen möglichen Custom Sachen, die Leute so bauen, testen. Und da sehen wir halt oft Probleme, dass Leute dann sagen: „Oh ja, hier Nax Bridge geht nicht, die ist getestet, die funktioniert gut. Aber natürlich in dem speziellen Szenario mit den Flags an und den dort, ist es halt, so Custom, das kann man sehr schwierig abdecken. Ja, das ist richtig. Und wenn du sagst, ihr wollt auch eine Bridge dann anbieten, ist die Idee dann aber schon, dass ich quasi, wenn ich Nax 3 verwende, quasi eine Bridge bekomme, NACS4 schon nutzen zu können? Oder ist es eher so, dass ich, wenn ich immer noch auf Nax 2 bin, die Bridge dann so weit Extended wird, dass ich sogar in 4 schon rein hüpfen kann damit? Also die Bridge ist nur was, was von Nax 2 zu Nax 3 geht. Für Nax 3 zu 4 wird es keine Bridge geben, weil da sollen die Migrationen wirklich so einfach sein, dass man idealerweise sagt: „Okay, wie gesagt, mit dem Future Flags kommt man rein und kann dann entsprechend sagen okay, hier, die und die Module müssten vielleicht geupgraded werden, weil die eben von uns oder von den Autoren die Updates bekommen haben. Das sind halt auch Changes, wo man sagt, da muss man nicht total verrückt an den Kern vom Modul ran, sondern kann halt einfach sagen: „Okay, man guckt entspannt, nutzt er dieses Feature? Nein, dann ist das Modul okay. So wie wir es ein bisschen auch gemacht haben, jetzt bei den Modulen von Nax 2 zu Nax 3, es wird gecheckt, ist es kompatibel? Wird es überhaupt noch gebraucht? Gerade bei zwei zu 3 gab es ja auch Features, die jetzt einfach NightTru übernehmen kann. Vorher war das schwieriger. Oder zum Beispiel das TypeScript Modul wurde in total unnütz, weil Nax 3 läuft jetzt halt mit TypeScript out of the box. Und da kann man sagen, die werden nicht gebraucht, die schon. Hier gibt es ein Replacement. Und bei NACS 4 geht es halt wirklich einfach nur darum, okay, Kompatibilität herstellen. Wir haben auch einen Nightlead Channel, der wird dann noch mal sehr, sehr spannend. Der gibt jetzt schon einfach die neuesten Commits einfach als Release aus. Und spätestens wenn es dann NACS 4 geht, wir da die Version vorbereiten, gibt es dann auch einen Channel, zu sagen Gut, ihr könnt das schon mal austesten, Module können dagegen testen, Systeme können dagegen testen und sehen, was klappt, was klappt nicht. In welcher Version kommen die Server Sachen, Server Components? Die werden noch vor NACS 4 kommen. Also die laufen jetzt schon. Es gibt ja eine Experimental Flag. Die Idee, warum das Experimental ist und das erwähne ich immer dazu. Das bedeutet nicht, dass die instabil sind. Das bedeutet einfach nur, dass sich vielleicht in der API noch mal was ändert, dass man sagt okay, es wird vielleicht eine Direktive geben statt einem Slot, solche reaktiven Island zu ermöglichen in Server Components. Oder wir wollen das und das umbauen. Genau so. Also instabil im Sinne von die API ist instabil und kann sich noch mal ändern, aber das Feature ist nicht von der Performance oder Laufzeit her instabil und quetscht die am laufenden Band weg oder so was, nur da draußen die Verwirrung zu vermeiden. Absolut. Ja, das ist ein guter Punkt. Deswegen experimentell kann einfach bedeuten, ja, es können sich Sachen auch zum Teil Breaking ändern, wenn man dieses Feature anhat in Miner oder Patch Version. Deswegen da am besten die Next Version pinnen, würde ich sowieso empfehlen und dann eben gucken, wenn man solche Experimental Features verwendet, was gibt es dann jeweils Neues? Das erwähnen wir auch in den Releases regelmäßig, wenn es dann dazu Updates gibt. Und ja, gut, wenn eure Tests nicht mehr funktionieren, seht ihr das auch. Aber am besten schaut man dann in den Release Nodes nach. Das ist halt eins der wichtigen Punkte. Genauso zum Beispiel es gibt ein Feature, das nennt sich Typed Routes. Bedeutet also, da wird ein Plugin genutzt, dann zu ermöglichen, dass man so einen Nax Link sagt. Okay, ich kenne halt genau die Routen, die genutzt werden. Das heißt, da kann ich mit Hype Scootern absichern, dass es den Link, wo ich den Link habe, wirklich gibt. Und das ist super nett. Es ist aber experimentell, weil das darunterliegende Plugin noch mal intern ein paar Changes braucht, weil wir bei Nax noch ein paar Requirements haben, die mit abgedeckt werden sollen. Das funktioniert aber super. Ich hätte noch. Eine Frage und zwar zurück kommend auf das du gesagt hast, andere Framework User schielen neidisch auf die Dev Tools. Könntest du die mal grad pitchen? Sehr gerne. Also die Idee ist, man kennt es vielleicht auch von anderen Frameworks oder auch von VUEN hat so ein Chrome oder Firefox Plugin, da sind Dev Tools drin. Bei Nax läuft es ein bisschen anders. Die Dev Tools sind Teil der Anwendung und in den Dev Tools läuft eine Nax Anwendung. Das heißt eigentlich sind die Nax Dev Tools eine Nax Anwendung, mit der man die eigene Nax Anwendung hier steuern kann. Genug Inzeption. Ich sage mal, mit diesen Dev Tools kann man alles mögliche nachher, vor allem kann man das Ganze auch mit dem Nax Server, also mit dem Dev Server verbinden und kann so auch sagen: „Hey, bitte installier mir mal Module, bitte update mir mal was. Bitte, wenn ich zum Beispiel gar kein Routing brauche, aber sage: „Jetzt hätte ich das gerne, gibst du einen Button, zu sagen: „Oh hier, du hast das Routing nicht, möchtest du es enabeln? Ja, dann wird das zur Konfiguration hinzugefügt. Ist okay, sagst du „Ja, da wird das gemacht. Und mal die Möglichkeiten zu verdeutlichen, rein aus Spaß – und den Tab gibt es immer noch –, gibt es einen Tab, der nennt sich VS Code. Das heißt also, da ist ein VS Code Instanz in den Dev Tools, die man dann aufmachen kann. Man verbindet die mit dem lokalen Dev Server und auf einmal kann man die Dateien der NACST-Anwendung, die gerade läuft, in den Dev Tools der NACST-Anwendung ändern. Man hat also theoretisch ein kleines Fenster mit VS Code, schreibt daran was, speichert das und die NACST-Anwendung über HotMode Reload hat die Änderung. Also kann sozusagen wirklich die Browser Anwendung mit den Dev Tools der Browser Anwendung im Browser entwickeln. Okay, ich glaube, das Semi ist gerade abgestürzt. Das klingt ein bisschen crazy, klappt aber alles über RPC Calls. Da ist wirklich nur die Idee, die Dev Tools können halt wirklich mit der NACT-Anwendung kommunizieren. Gleiches hast du natürlich auch so Sachen wie okay, zeig mal die OG Tags oder die Meta Tags generell für SEO. Zeig mal Vorschau, zeig mal die Payloads von Use Fetcher und Use Async Data. Gib mir eine Timeline, zeig mir die Komponenten an. Also da gibt es ganz, ganz viele Funktionalitäten. Danke. Kein Problem. Gerade dachte ich so, es hört sich irgendwie wie diese Totgeburt von CLI, GUI an. Ach so, nein, nein, nein, nein, keine Sorge. Hier geht es wirklich nur darum, dass die Dev Tools so eng mit der Applikation verzahnt werden können, dass man eben mehr machen kann als anschauen, so ein bisschen State checken. Und auch dazu gab es einen guten Talk, ich glaube von Antony auch, der mit die Dev Tools ins Leben gerufen hat, dass da auch das Ziel ist, dann irgendwann zu sagen, gut, wie kann man das mit den View Dev Tools kombinieren? Kann man vielleicht eine Infrastruktur basierend auf Lead vielleicht bauen für Dev Tools generell, dass auch andere Frameworks in den Genuss kommen? Aber das wird wahrscheinlich noch ein bisschen dauern. Deswegen guckt euch gerne mal die Nax. Dev Tools an. Ich kenne so komfortable Dev Tools nur so aus der PAP Welt. Da ist es allerdings auch so, dass sie so schon sehr Plugable sind. Das heißt, wenn ich für meine eigene Anwendung irgendwie dann besondere, du hast gesagt, OG Text anzeigen, vielleicht will ich was, was mir Json, LD, Schema anzeigt. Zum Beispiel, wenn es das jetzt nicht gibt, vielleicht gibt es ja schon, keine Ahnung, wenn nicht, würde ich das vielleicht gerne bauen? Kann ich mir da so ein eigenes Plugin reinhängen? Absolut. Das ist das Schöne. Du kannst in jedes Naxx-Modul oder auch einfach deine Anwendung kannst du sagen: „Hey, ich möchte irgendwas in den DevTools-Tab integrieren. Das kann ein simples iFrame sein, das kann auch deutlich mehr sein. Beispielsweise gibt es von Harn auch einen Coating Member, der hat ein Paket, das nennt sich Naxt OG Image. Das basiert auf Sartori von Wörter. Kennt man vielleicht, wenn man so ein bisschen aus der React Welt oder in der React Welt lebt, kann man damit also wirklich selber zur Laufzeit und auch über Nitrow die Open Graph Images generieren für die Seiten oder eben zur Deploy Zeit. Das mache ich dann für meinen Blog, zu sagen Gut, ich habe ein Bild, ich habe einen Text, ich habe einen Titel, ich habe Text, Lesezeit und die werden dann generiert. Und dafür gibt es einen Dev Tools in Playground. Da wird also angezeigt, wie sieht das HTML aus dafür? Wie sieht das Ganze aus, wenn ich es ad hoc als SVG rendere, als PNG rendere? Welche Prop es gibt? Also da können wirklich auch kompliziertere Sachen entsprechend gebaut werden und sogar wenn man will, auch eigene App Dev Tools. Und zu sagen okay, ich klicke hier, ja, dann soll es der und der User gesetzt sein, das soll im Local Storage geändert werden. Also man kann eben dadurch, dass man auf die NACS App selber auch zugreifen kann, ja so ein bisschen eigene App Dev Tools erstellen. Nachdem ich letzte Woche angefangen habe, an der Programmierer Webseite zu arbeiten, will ich das jetzt auch haben. Ist ja auch ein NACS. Ich will jetzt NACS Dev Tools haben. Ist es dann möglich über dieses Plugin, dass man in dem Plugin was einstellt und das Plugin ändert dann die meine Seiten dementsprechend ab? Absolut. Natürlich nur in Dev, aber das geht. Klar. Sehr schön. Ja, jetzt bin ich es auch. Ich sehe Möglichkeiten vor meinem inneren Auge. So soll es sein. Und die Dev Tools kommen standardmäßig, ich glaube standardmäßig, aber das ist mittlerweile in Nax 3.8 und einfach eine Flag in der Nax Config ändern, dann läuft das Ganze. Ausgezeichnet. Ich liebe es, wenn ein Plan funktioniert. Okay. Jetzt müssen wir einen Computer zurück. Ja, schade. Das war schon wieder. Nein, ich will dich natürlich jetzt hier nicht festnageln auf Themen, die noch lange nicht feststehen, aber wir haben ja schon so ein bisschen NACST4 angerissen mal eben und du hast ja auch schon gesagt, es wird jetzt nicht der große Wurf für Developer Facing Features, sondern eher für die Leute, die Modular Autors sind. Unter welchem Stern steht denn aber so generell dieses Release vielleicht? Und ja, also unter dem Präfix, das kannst du alles noch ändern, ist noch alles nicht fertig. Aber nur den Leuten noch mal so einen Ausblick zu geben, wo da vielleicht die Reise hingehen kann. Ja, der Plan ist, das hatte Daniel in seinem Nax Division 2023 Blogpost mal geschrieben, es soll halt jährliche Major Releases geben. Einfach auch dieses okay, wir wollen weg von die Zahl ist eine Marketing Zahl, hin zuEs geht wirklich darum, Major Version bedeutet halt nicht krasse Features, sondern vor allem Breaking Changes. Kann natürlich auch bedeuten Breaking Changes, die krasse Features ermöglichen. Aber erst mal geht es darum, Breaking Changes. Heißt also, das hat man so ein bisschen bei ich glaube bei VEAD auch mal gehabt, wo man sagt Okay, komm jetzt VEAD 5 gar keine Aufregung, sondern okay, paar Breaking Changes, Sachen müssen angepasst werden. Aber für den Endnutzer, da gibt es erst mal sofort nicht viel, wo man sagt Okay, da muss man jetzt direkt updaten. Und eben auch da, wie du es schon gesagt hast, das ist alles auch jetzt, das kommt nicht heute und morgen. Da haben wir auch intern noch nicht super viel zu gesprochen. Aber der Pfad dahin ist klar auch, dass wir wie gesagt, das muss ich unbedingt noch hervorheben, nicht wollen wie die NACS 2 zu NACS 3 oder Leute ewig hängen und sagen, sondern das möglichst entspannt haben wollen. Und diese Änderungen für Modulautoren. Warum dieser Fokus oder was versprecht ihr euch davon? Geht es darum, einen Grundstein zu legen, dass dann dieses Modulökosystem in NACS 4 nochmal exponentiell erwachsen kann? Geht es darum, mehr Leute da reinzuholen? Geht es darum, nur denen, die schon dabei sind, das Leben einfacher zu machen? Was ist die Motivation aus eurer Sicht jetzt? Genau da sind es auch keine Brown-Bracking Changes und auch da stellt man nicht viel fest. Da ist einfach nur der Punkt, wenn es interne Änderungen gibt, dann betrifft es vor allem die Modulautoren, weil die nutzen am ehesten noch Internas. Also wer jetzt keine Ahnung Usefatch Composible nutzt, der nutzt dann nicht die die Internas, sondern das, was direkt exponiert wird von Axel, wo man sagt okay, das ist für euch da, das könnt ihr nutzen. Kann natürlich auch da sein, dass wir sagen Gut, da gibt es eine Flag, die ist auch jetzt mit 3.8 gekommen, die nennt sich Deep. Also soll das Ganze ein Ref oder ein Shello Ref werden. Bedeutet also dann noch mal kurz zusammengefasst wir Fatchen Data und wenn das Ganze As Ref ist, dann ist die wirklich dieses komplette Data Objekt reaktiv. Also auch die verschachtelten verschachtelten verschachtelten Objekte, was für die Runtime Performance nicht immer gut ist, vor allem wenn man es nicht braucht. Und dieses Dieb des Steinmetzigen of True, das war nämlich genau das Verhalten, was jetzt da ist. Man kann es aber als FALse setzen, damit kommt daraus ein Shalloref. Bedeutet also, dass es nur reaktiv top Level oder wenn man es eben entsprechend austauscht und nicht, wenn man irgendwas darin ändert. Weil meistens ist es so Ja, ich nehme jetzt meine Daten, dann habe ich die und die will ich aber nicht immer abändern. Vielleicht habe ich was, was darauf basiert, was zu berechnen, aber was abändern? Selten. Meistens ist es eher ich mache einen neuen Request, dann wird das Ganze ersetzt. Okay. Und solche Sachen, wo man sagt okay, Default ist True. Besserer Default wäre aber FALSE, weil eigentlich braucht man das sehr, sehr selten. Solche Änderungen, die kann man jetzt halt nicht im laufenden Betrieb machen, sondern sagt halt okay, die schiebt man auf Lachs 4. Wer will, kann halt schon mal rein, indem man einfach sagt Ja, alles auf FALSE oder eben mit einer Feature Flag, die dann so was wie Deep heißt oder Use Fetch Deep oder ähnliches. Mal gucken, wo man es schon mal entsprechend einstellen kann. Klingt sinnvoll. Cool. Klingt cool. Ich gehe gerade durch den Kopf. Wie grenzt sich denn Use Fetch von NACST und Use Fetch von View Use ab? Also abgesehen davon, dass das also nur zufällig heißen die ja gleich. Aber hat das, gibt es da eine Verbindung? Nee, das ist wirklich nur der Name. Und wer View Use nutzt, bin ich auch ein sehr großer Freund von. Da ist es auch so, selbst mit dem Modul, was die ganze Sache Auto importiert, da wird Usefatch nicht automatisch importiert, weil das Usefetche von NACST eben noch mal deutlich anders funktioniert als das Usefetche von View Use. Diese Composibles sind vor allem wichtig, wenn man Server-Seite Rendering hat, weil die sorgen dafür, dass die Daten, die damit gefetcht werden, auch vom Server auf den Client übertragen werden und dass man nicht sagt, ich habe den Request, den muss ich serverseitig machen und Client-seitig. Deswegen, da ist ein bisschen was, was im Background passiert und was da das Ganze notwendig macht. Ich kam, glaube ich, auch drauf, weil Antonio ist von VU. Use auch Autor? Genau, der ist auch da mit im Team. Richtig. Richtig. Cool. Sebi, noch eine Frage, die dir auf dem Herzen brennt? Eigentlich bin ich jetzt nur gespannt, was der Pick of the Day ist von Alex. Da. Kommen wir gleich zu. Aber vorher noch: Alex, eine Sache, die du noch irgendwie erzählen wolltest, Mensch, wieso haben sie uns dazu nicht gefragt? Das wäre doch voll offensichtlich gewesen. Irgendwas super, super Wichtiges für dich? Außer der Rat. Ich würde vielleicht einfach noch mal ganz kurz erzählen, was Next Layers sind. Weil da sind wir nicht mehr drauf zurückgekommen und das ist ein super schönes Thema, weil da kommt bestimmt auch noch mal einiges an coolen Features in der Zukunft. Also ganz sicher. Die Frage ist natürlich nur, wann. Die Idee ist, dass man, aktuell hat man Module, zum Beispiel Komponenten hinzuzufügen, Sachen zu ändern. Und es gibt seit NACS 3 noch eine zweite Möglichkeit der sogenannten Layers. Layers kann man eher sehen als so eine Teil, in AnführungsstrichenTeile, Applikation. Also wenn man sagt keine Ahnung, ich habe eine Anwendung und die soll für drei Kunden oder drei Brands ausgebaut werden. Die Basis ist gleich, aber ja, hier soll das Design da geändert werden, da gibt es vielleicht andere Funktionalitäten oder das soll halt für eine Web App sein oder das andere halt ganz normal. Dann was macht man aktuell? Okay, man baut vielleicht eine Component Library, man hat die als NPM Paket, man importiert die. Trotzdem gibt es ganz, ganz viele Logik Teile und Composibles, die man halt entweder wieder als Paket schicken müsste oder einfach dupliziert. Und das ist natürlich auch doof. Mit Next Layers ist es so, dass man sagt okay, man kann eine Basis App haben, die hat zum Beispiel alle Komponenten aus der Component Library verschiedene Module installiert und noch ein paar Funktionalitäten und kann dann sagen z. B. In einem Monorepo oder auch als Paket oder ähnliches: Okay, ich nehme diese App als Basis und dann setze ich da eine App obendrauf und die kann Inhalte überschreiben von einer App, kann die aber auch genauso nutzen und kann zum Beispiel sagen Okay, ich füge eine neue Komponente hinzu, ich ändere ich was, ich ändere zum Beispiel Konfiguration, ich ändere Design Tokens und somit lassen sich vor allem so, ich sage mal Multi Brand Applikationen oder White Label Apps oder wie hatte ich es mal genannt, auch irgendwas mit Multi, aber am Ende, wenn man verschiedene Applikationen auf der gleichen Basis ganz gut zusammenbauen. Gerade wenn man sagt, ich habe verschiedene Kunden und brauche da eine Applikation für oder ich habe eine Basis und hier soll meine Karriereseite, hier soll eine Homepage, hier soll ein Admin Dashboard. Dann kann man trotzdem sagen, man nimmt das gleiche als Basis. Und das ist ein sehr cooles Feature, was irgendwann auch ermöglichen soll, diesen Multi-App Support zu haben. Kann man sich ein bisschen vorstellen als Micro Frontend 3 Imag, wie es Daniel mal genannt hat. Also zu sagen, ich habe verschiedene Applikationen, die laufen auf verschiedenen Pfaden zum Beispiel und ich stiche die einfach nur zusammen. Ich packe die einfach in einem. Inwieweit muss meine Base Application, also die von der dann alle weiteren Extenden wollen. Inwieweit muss die darauf vorbereitet sein? Muss die diese Extensions Points schon selbst definieren und vorbereiten? Oder kann ich im Prinzip jede beliebige App nehmen und dann einfach sagen okay, an der Stelle, wo jetzt normalerweise Komponente XY geladen wird, überschreibt die einfach zur Laufzeit mit meiner Komponente ABC und los geht's. Genau. Also du brauchst keine Vorbereitung für die App selber. Du brauchst halt den Code irgendwo, zum Beispiel in einem anderen Ordner, einer Monorepo oder als Paket. Dann gibst du in der Next Konfigur an externes, gibst den Punkt da an und dann kannst du sagen, ich überschreibe das und das oder ich ändere dies. Das Gute ist halt, man hat trotzdem den vollen TypeScript Support, man hat Auto-Imports, alles was Nax so mit sich bringt. Die Routen funktionieren alle wie sie sollen. Ja, also braucht man die NaX nicht großartig präparieren. Das heißt aber auch, dass die Projekte hart getrennt voneinander bleiben. Also ich mische keine Dependencys oder so, sondern zwei komplett unterschiedliche Trees sozusagen dafür aufgebaut. Genau, du weißt also, wenn du in der Applikation A die von der Basis erbst was ändert, dann hat das nichts mit B zu tun. Das ist auch einer der schönen Teile. So ist es. Das ist eigentlich auch ein cooler Modus für so größere Refactoring oder so, Legacy Sachen umzubauen. Das heißt, wenn ich jetzt in einem klassischen Kundenprojekt bin, wo ich eine bestehende Anwendung ablösen muss, dann sage ich okay, die ist jetzt meine Base und ich fange quasi an, peu a peu davon zu extenden und ersetze alte Funktionalität mit neuer Funktionalität, so lange, bis nichts mehr von der alten App erforderlich oder notwendig bleibt. Richtig. Das Einzige ist, die müssen natürlich beides drei Apps sein, aber das ist der einzige Constraint. Aber ansonsten, genau, das geht. Cool. Für alle Legacy-Applikationen die letzten elf Monaten. Die werden auch irgendwann Legacy. Mein Anwendungsfall wäre … Geschäftsmodell-Incomeing. Werden dann solche vorbereiteten Base Sachen irgendwo bereitgestellt, dass ich mir... Hier gibt es zum Beispiel so ein, was du gesagt hast, hier Block, Admin, Dashboard und Landing Page in der Route, in der Route-Rules hieß es glaube ich, entsprechenden Konfiguration irgendwie, dass es da schon so ein Examen gibt, von dem ich einfach nur erben kann und dann die Punkte überschreibe? Also es gibt Beispiele, die man natürlich nutzen kann, aber jetzt direkt, ich sage mal, Templates mit „Hier hast du so einen, keine Ahnung, einen Starter für eine Admin-Applikation gibt es noch nicht eins zu eins. Gibt es natürlich von Third Party, wo man sagt „Okay, Leute haben da schon mal ein bisschen was gebaut, das durchaus, aber von uns als Team gibt es das nicht, nein. Dann ist das dafür wahrscheinlich auch gar nicht gedacht, gell? Naja, also es kann auch Sinn machen, wenn man sagt „Okay, ich kann mir das schon gut vorstellen, gerade, keine Ahnung, wie das Leravel macht mit Spark zum Beispiel. Du hast so ein vordefiniertes Paket in dem Fall, du sagst halt Layer und nutzt das Ganze. Absolut. Also würde ich auf jeden Fall nicht ausschließen. Ist ein guter Anwendungsfall dafür. Cool. Haben wir noch mal was Interessantes. Gelernt zu Layers. So, aber Sebi hat es ja eben auch schon angeteasert. Wir wollen ja noch zu unseren Pics of the Day kommen. So ist esSo. Pics of the Day. Sebi, willst du anfangen? Oh Gott. Mein Pick of the Day ist, kennt ihr wahrscheinlich alle, aber es ist mir neulich erst wieder untergekommen, und zwar CSS Clipping Masks. Okay, ich dachte gerade, CSS ist dein Pick of the Day. Ja, das ist es. Von der etwas langen Pause. Das ist so eine richtig coole Technologie, die mir neulich mal … Ne, Clipping Masks. Und zwar in Kombination oder Anwendungsfall: Ich möchte einem Div eine Gradient Border geben und trotzdem irgendwie noch durchgucken können. Und das in Kombination mit einem Hintergrundbild, das am Border Box geklickt ist und dann die Maske, klickt aber den Content Box. Bereich raus. Ich glaube Clipping macht auch so ein richtig gutes Thema, das dann im Podcast vorzustellen. Also jedenfalls ich fand es irgendwie super interessant und hatte es gar nicht so auf dem Schirm und mochte es sehr. Kann davon abraten zu versuchen, die zu animieren. Es ist ein Performance Ad. Ist aber auf alle Fälle immer, wenn man das so sieht, in Gebrauch, so in the Wild denkt man sich: Krass, dass das mittlerweile so geht, wo man früher irgendwie drei Layer in Photoshop gebraucht hat und einen Masculär dazwischen und so und jetzt geht das so zur Laufzeit im Browser. Das ist schon nice. Ja, ich fand es auch lustig, dass es da tatsächlich irgendwie Verrechnungsmöglichkeitens, die es gibt von den Masken. Also Mas Composite oder irgendwie sowas heißt das. Ja, lustig. Kann man sich mal angucken. Jetzt bin ich jetzt nur drüber gestolpert, habe gemerkt, dass ich darüber nichts weiß, weil ich es nicht benutze und habe es mal gepickt heute. Cool. Alex, was hast du mitgebracht? Ja, ich habe ein YouTube-Video mitgebracht, so wird es aber. Und zwar geht es dabei erfolgreich verhandeln lernen. Das habe ich mir vor Jahren mal angeschaut und es ist nach wie vor ein sehr guter Talk von Professor Dr. Jack Nasher. Auch da wieder ein Link in den Shownotes. Da geht es eben darum, okay, so ein paar Tipps und Tricks zum Verhandeln, sei es Gehalt, sei es Aufträge, auf jeden Fall ein paar kennt man vielleicht, die sehr, sehr hilfreich waren. Was ist dein Favorit Trick, den du daraus mitgenommen hast? Zum einen das klassische mit natürlich zuhören. Aber so eine Sache, die ganz interessant ist, dass man so ein Teil hat, aber bewusst und sagen okay, es geht Summen und dann dieses auch deutlich zu machen. Ja, okay, das, das auch wenn man sagt, du bist. Vielleicht ganz zufrieden. So ein expliziter Teil. Ja, richtig, richtig. Und auch mal deutlich okay, jetzt der andere hat vielleicht dich durchschaut, aber eigentlich ist es mir bewusst klarzumachen. Ja, ne, haut nicht so hin. Hat mir vielleicht schon den einen oder anderen Euro mehr eingebracht. Wer weiß. Ah, nicht schlecht. Mein Pick of the Day ist Kulify. Und zwar wenn ihr da draußen seid und die ganzen coolen NACS Anwendungen baut, müsst ihr die am Ende des Tages ja auch irgendwo hosten. Und wenn ihr es leid habt, irgendwie das fünfte Herokko Abo oder den dritten Netly Fly Account zu erstellen dafür. Dann könnt ihr euch Kulify angucken. Und zwar Kulify ist so ein Platform as a Service Open Source Platform. Also es ist eine Mischung von Docker Containern, die ihr einfach auf euren eigenen Server drauf schmeißen könnt. Und der bietet euch im Prinzip diesen ganzen Convenience Funktionen wie automatische Deployment, Monitoring, Automatisierung über Webhooks und so weiter. Ihr hinterlegt dann da eure Anwendungen, euer Git-Repo oder euren Container und der übernimmt den ganzen Rest für euch Rollout, URL, ein bisschen Traffic Proxy mit drin. Und das macht es für mich immer super einfach, wenn man so ein kleines Testprojekt hat, was man irgendwo ausrollen will, dass man da nicht erst sich groß mit beschäftigen muss. Ja. Sehr, sehr cool. Kenne, sagt mir auch schon was, leider noch nie probiert, aber habe sehr, sehr viel Gutes gehört. Ist gerade in einem großen Re-Write, das glaube ich schon in der Beta Version der nächsten Version verfügbar, aber ist auf alle Fälle, also am Ende ist es untendrunter auch nur Docker und wer Traffic irgendwie selber bedienen kann über Docker-Envelopment-Variablen oder sowas oder Labels, der kann das auch irgendwie alles machen. Aber es macht es halt super super konvient einfach, wenn man nur mal eben so ein Image irgendwohin schicken will, dann geht das schon. Vielleicht auch mit Webhooks könnte das sehr nice sein. Also im Sinne von so klassisch ein Feature, was bei Netflix ja sehr cool ist noch bei Wurcell, baue ich meine Seite neu, wenn mein CMS neue Einträge hat. Brauchst du die Webhooks gar nicht, weil da gibt es eine GitLab und GitHub Integration. Dann kannst du einfach einmal verlinken und dann kann er das schon automatisch. Sehr cool. Aber selbst wenn es ein CMS ist, was irgendwo gehostet ist, wo ich nicht sage, ich update mein Markdown. Nee, dann. Musst du. Wahrscheinlich den nehmen, aber dafür gibt es die auch. Und er macht auch andere, hat natürlich nichts anderes als Webhooks, aber er registriert sie halt für dich bei GitLab und so weiter. Und dasAh, okay, sehr cool. Schick. Ja, ist ganz nice. Cool. Dann bleibt mir nicht viel zu sagen. Danke an euch. Danke für die Zeit. Insbesondere dir, Alex. Danke fürs mich hier haben. Immer gerne. Du bist ja Wiederholungstäter und das ist hoffentlich auch nicht das letzte Mal. Ich hoffe es auch. Alle guten Dinge sind drei. Also zwei haben wir schon. Ja, dann zählen wir einfach das Meetup nicht mit. Und dann darfst du noch einmal in den Podcast kommen und musst auch noch zweimal zu den Meetups. Und dann haben wir das auch. Und dann fangen wir von vorne an. Wunderbar. Wenn es da draußen Feedback, Anmerkungen, Kritik, was auch immer gibt, dann bitte immer gerne an podcast@programmier. Bar oder über das Kontaktformular auf der Website. Oder für alle, die, die uns über Spotify hören, könnt ihr auch direkt die Kommentarfunktion Spotify benutzen. Ich gucke da regelmäßig rein. Die anderen nötige ich auch ab und zu dazu. Dann kommt das auch bei uns an. Wunderbar. Schön. Vielen, vielen Dank. Das war es. Danke. Und tausend Dank. Macht's gut. Und bis zum nächsten Mal. Bis dann. Tschüss.