Transcript

[0:00] Wir haben noch nie über Nux.js gesprochen. Ja, da wird's Zeit, ne?
Los geht's. Die Idee, am Ende zu sagen, gut, Vue 2.0, Vue 3.0 bedeutet nicht nur ein paar Breaking Changes, sondern auch eine neue API, ist an sich erst mal kein Fehler gewesen.
Dass man sagt, es braucht eine neue API, um Probleme zu lösen, nämlich die Probleme, wie teile ich am besten Code und vor allem, wie gruppiere ich den Code.
Ja, ich denke, Vue 4.0 wird jetzt in nächster Zeit nicht kommen.
Weil ich denke, mit der Composition-API sind eigentlich alle recht glücklich, wie das soweit ist.

[0:30] Music.

[0:56] Revision 608, Diese Revision von Working Draft wird euch präsentiert von Mitwald.
Next Level Hosting für deine Projekte.
Jetzt fragt ihr euch bestimmt, wie kann sowas langweiliges wie Hosting Next Level sein? Ganz einfach.
Mitwalds hochperformantes Cloud-Hosting ist perfekt abgestimmt auf die Anforderungen von Freelancern und Agenturen.
Es gibt zum Beispiel ein smartes Rollensystem für die Zusammenarbeit mit euren Projektpartnern und Mitwald hat mit dem Studio auch eine sehr schöne moderne Verwaltungsoberfläche gebaut, mit der das Arbeiten Spaß macht.
Aber jetzt mal ehrlich unter uns Nerds.
Sachen anklicken? In einem User-Interface?
Muss das sein? Nein, muss es nicht.
Denn bei Midwild gibt's die M-Studio CLI. Mit der könnt ihr euer Hosting komplett über die Kommandozeile verwalten und natürlich auch entsprechend automatisieren.
Von Nerds für Nerds bringt euch Midwild die optimale Developer-Experience, wenn's ums Hosting geht.
Und deshalb jetzt auf zu midwild.de slash workingdraft.
Denn da wartet auf euch exklusiv als Hörer von Workingdraft das Angebot, den Tarif pro Space für 30 Tage kostenlos zu nutzen.
Das war nochmal mittwald.de.
Wir danken Mittwald für die Unterstützung von dieser Revision von Working Draft.

[2:09] Hallo und herzlich willkommen beim Working Draft. Heute mit mir am Start.

Revision 608: Nuxt & unJS

https://workingdraft.de/608/

[2:14] Als erstes wollte ich begrüßen den Shep aus dem Team. Hallo. Hallo Vanessa.
Und ich stolpe hier gerade schon zum zweiten Mal meines Satzes, obwohl ich den Satz gerade schon mal beginne, weil heute passiert noch was anderes, nämlich ganz liebe Grüße an den Hannes Dorn, an unseren Patreon.
Vielen lieben Dank für die Unterstützung.

[2:32] Und wir sind heute nicht nur all zu zweit hier für euch, sondern wir haben noch einen Gast dabei, den ich hier quasi irgendwie mit reingeschmuggelt habe, denn er war schon mal hier bei uns bei der Live-Aufnahme bei der 600.
Und als ich für die Aufnahme danach die Shownotes geschrieben habe, wollte ich auch diverse Personen, die sehr viel mit uns geplaudert haben, auch benennen und habe so geschrieben.

[2:56] Ehemalige Gäste wie da, da, da und da, da, da und natürlich der Alexander Lichter, weil ich den Alex schon ein bisschen privat kenne und mir nicht vorstellen konnte, dass er noch nicht schon hier Gast, gewesen sei und er schrieb mir dann doch so, danke, aber ich war ja noch gar nicht Gast, das müssen wir doch nachholen und dann Und dann, locker flockig, ist das die erste Aufnahme und wir planen noch eine zweite.
Und jetzt freue ich mich sehr, dich zu begrüßen. Hallo Alex.
Ja, hallo Vanessa, hallo Shep. Vielen Dank fürs hier sein und für die tolle Introduction.
Es war sehr lustig. Wir hatten, glaube ich, auch, keine Ahnung, vor zwei Jahren oder sowas verquatscht mit, ja, Working Draft oder anderthalb oder sowas. Vielleicht zum letzten VJs Amstel damit. Da machen wir.
Und jetzt haben wir es geschafft. Sind wir hier.
Einer von vielen. Wer weiß, was da noch so kommt.
Ja, ansonsten zu mir vielleicht ein paar Worte, genau, wer mich schon undercover gehört hat sozusagen, also gar nicht so sehr undercover, aber bei der 600, genau, war ich ein bisschen mit dabei, hab mitdiskutiert mit all den tollen Leuten, auch da nochmal Chapeau, war eine sehr, sehr coole Aufnahme mit richtig spannenden Themen und guten Diskussionen, konnte ich auf jeden Fall auch viel mitnehmen.

[4:03] Ja, ansonsten, was mache ich so? Ich bin Web-Engineering-Consultant, also, ne, schöner Begriff für, ich helfe irgendwie Firmen, wenn es um Vue, Nuxt.js generell, Frontend-Web-Entwicklung und wenn es sein muss, ab und an noch ein kleines bisschen Backend, also Full-Stack geht und, ja, in der Regel heißt es dann, okay, frag mich an, wir haben eine Nuxt-Anwendung, kannst du mal drüber gucken, wir haben ja folgendes Problem, Performance, Code-Qualität und Co.
Und da sage ich dann, ja klar, kriegen wir hin, gucken wir das Ganze an.
Ansonsten bin ich, ja, Open Source auch noch ein bisschen tätig im NUX-Team und bin auch unter anderem im NJS-Team, also die zwei Themen, um die es heute so ein kleines bisschen geht und vielleicht hat mich der eine oder andere nicht nur bei der sechsthundertsten Folge vielleicht auf YouTube gesehen, sondern auch über meinen YouTube-Channel, wo ich einmal die Woche Videos veröffentliche rund um die Frontend-Webentwicklung.

[4:52] Denn was jetzt unsere Hörer und Hörerinnen leider nicht hören, also sehen können, ist dein absolut professioneller Background.
Wir haben vorher schon, ich bin eine Minute zu spät gekommen und ich habe schon gehört, hier wird schon diskutiert, wie du diese Glühbirne im Hintergrund gemacht hast.
Und dabei ist mir nochmal aufgefallen, nicht nur, dass dein Hintergrund so gut ist, aber deine Kamera ist der, ich habe jetzt keinen Affiliate-Link, aber das ist hier ein anderes Setup, also ich fühle mich hier gerade ein bisschen schlecht.
Das Setup ist mega, wir müssen jetzt abholen bei uns.

[5:25] Vielen lieben Dank. Kennt ihr das, wenn man immer so ein bisschen checken möchte, wie man selber gerade aussieht?
Weil ich habe dieses Ding, dass ich schon immer meinen Kopf ein bisschen schief halte und dann schaue ich immer auf mein Bild, damit ich sehe, wie schief hängt mein Kopf schon wieder, damit ich ihn wieder gerade ziehen kann.
Und jetzt möchte ich nicht mehr auf mein Bild schauen, weil ich komme ja dann einfach ...
Vielleicht brauchst du aber auch so eine Nachführkamera, die dann auch schräg wird, dass du wieder gerade bist. Das ist echt cool, ja.
Oder ich muss meinen ganzen Körper auch, ist hier nur der Nacken, meinen ganzen Körper schief halten. Nee, aber die Farben sind...
Tipptopp. So ein bisschen hot pink im Hintergrund auch. Genau.
Verweise einfach auf deinen YouTube-Channel, weil da kann man das bewundern und in jedem Content.
Absolut. Dankeschön. Ja, hat auch ein bisschen gedauert, das einzurichten, aber da ich seit letzten September, also September 23, gesagt, okay, hier, jetzt muss ein bisschen was her, Website neu gebaut und damit YouTube so als großes Ding angefangen, weil ich gemerkt habe irgendwie, ja, es gibt viel Beginneranhalte zu allem Möglichen und Beginneranhalte sind immer schick, weil es für viele Leute super, aber sobald es dann komplexer wird, hört es dann schnell auf.
Klar, hier gibt es mal weiterführende Blogposts oder auch mal Talks, aber so wirklich.

[6:35] Wiederkehrendes Material zu Themen, die eigentlich Leute interessiert, findet man mal vergraben in GitHub-Issues, aber da guckt halt auch nicht jeder, zumal, naja, muss man auch erst mal hinkommen, dass es das Ganze da gibt und man hat auch nicht Zeit, das jetzt alles zu durchsuchen.
Deswegen hatte ich gedacht, ja, so intermediate und advanced halt rund um Vue nags zu nehmen, auch JavaScript und TypeScript und die Rest der Frontend-Entwicklungen, das könnte eigentlich was Spannendes sein.
Und ja, das läuft bisher ganz nett, es gab positives Feedback und auch da, wenn es da irgendwelche Anmerkungen gibt, Ideen, bin ich immer für offen.
Deswegen konnte ich mir, wie gesagt, wirklich nicht vorstellen, dass du noch nicht da warst.
Deswegen auch an dieser Stelle die offizielle Entschuldigung, dass du noch keine Einladung hattest, weil ich einfach immer dachte, du warst schon da.
Ich habe unser Sheet durchsucht, weder du warst da, noch hatten wir jeweils über das Thema von heute gesprochen, was ich jetzt mir gar nicht vorstellen kann als View-Person in Deutschland.
An dieser Stelle der kleine Disclaimer, ich mag auch andere Sprachen, Aber wir haben noch nie über NUX.js gesprochen. Ja, da wird's Zeit, ne?
Los geht's. Auf geht's. Auf geht's. NUX.js ist das Framework.

[7:45] Des Frameworks Vue.js, das ich nutzen kann für Server-Side-Rendering, aber ich glaube, an dieser Stelle kannst du schon einspringen und sagen, das war jetzt ein bisschen plump, das kann noch mehr.
Ich weiß schon was, und zwar, die heißen dann, glaube ich, Meta-Frameworks. Genau, richtig.
Vue wäre das Framework und die Dinger sind dann diese Meta-Frameworks.
So ist es. Genau, so Vue und React und all die anderen schönen Frameworks, die auf diesem Level beruhen, sind ja so Component-Level-Frameworks, könnte man sagen.
Also ich kann meine Logik irgendwie nicht wie bei jQuery einfach imperativ runterschreiben, sondern ich gieße die in Components, die kann ich wiederverwenden und dann einige sagen, die Higher-Level-Frameworks, aber das klingt auch irgendwie so, als wären die was Besseres, deswegen ja Meta-Frameworks, Frameworks basierend auf einem Framework und als ich irgendwie angefangen habe mit Public Speaking, also so im Jahr 2019, war immer diese große Frage, ja, warum braucht man das?
Also jetzt hat man irgendwie schon Vue und warum braucht man jetzt ein Framework, was auf dem Framework basiert?
Also irgendwann hat man ja so viele Abstraktionsschichten, dass man sagt, das muss man auch alles lernen und verstehen und das war damals so ein großer Punkt mit, naja, wieso? So, und Vanessa hat es schon richtig gesagt, Server-Side-Rendering ist da ein großes Thema.
Nicht das einzige tatsächlich, aber erstmal ein großer Punkt, weshalb viele, unter anderem auch ich damals, Ende 2017 war das, so zu nackt gekommen bin, wenn man sagt, okay, ja, Vue ist super, ist schön, aber Single-Page-Applications sind halt für Search-Engine-Optimierung, also SEO, schwierig.

[9:13] Und da kommt man hin, was macht man da? Ganzes Frontend irgendwie von der Landing-Page oder dem Portfolio in Vue gebaut oder Framework hier einsetzen und dann, ja, kein Server-Side-Rendering, heißt, nicht so gut performend, man hat es in Google-Suchen nicht gefunden, was gibt es für Möglichkeiten?
Ja, nimmt man Nuxt, ändert ein paar kleine Sachen und schon läuft das Ganze, so in der Theorie.
Das war so ein bisschen auch, wie ich zunächst gekommen bin und dann halt irgendwann so nach einem Dreivierteljahr ins Core-Team, aber dazu vielleicht später nochmal ein bisschen was.
Ja, und jetzt ist die Frage, okay, warum kann Vue das nicht einfach selber einbauen?
Also hat Vue da keinen Support für oder was ist die Idee dahinter?

[9:51] Und da ist es recht interessant. Interessant. Evan, also Evan Yu, der Erfinder von Vue, hat mal gesagt, gut, Server-Side-Rendering, es gibt dafür eine API, sonst könnte man das gar nicht realisieren, aber im Vergleich zum Beispiel, was React ja aktuell macht mit Server-Components und Co., hat da Evan gemeint, naja, eigentlich bei Vue, wir wollen schon dem Prinzip, okay, wir sind halt ein Client-Framework treu bleiben und alles, was in Richtung Server-Side-Rendering passiert, so halt in den Meta-Frameworks, die es da gibt.
Gibt es tatsächlich auch mehrere, je nachdem, ob man zum Beispiel bei React, gibt es ja Remix, Next.js, Gatsby und Co. Und auch bei Vue gibt es tatsächlich zwei.
Quasar ist nämlich das andere, das darf man hier auch noch nennen an der Stelle.
Und das soll halt da passieren.
Diese ganzen Experimente passieren halt dort, damit wir eben sagen, gut, wer mit Vue anfangen möchte und von dieser ganzen Serverwelt eigentlich gar nichts wissen möchte, der kann entsprechend einfach plain Vue nutzen.

[10:45] Ich bin ja zu NUX damals gekommen, also ich bin tatsächlich, deswegen habe ich vielleicht auch wirklich ein bisschen drüber hier gesprochen, ich benutze kein NUX, ich benutze in meinen Projekten immer rein Vue.js und andere Techniken, selbstgebautes, ob man es jetzt braucht, selbstgebautes ist es eher, ich lasse das jetzt mal raus.
Aber als ich NUX.js machte, das war noch so die allererste Version, denke ich. Da gab es auch, da war auch Vue 3 noch lange kein Thema.
Und ich habe es tatsächlich deswegen verwendet, weil ich selber eine Webseite bauen wollte.
Und mir dann dachte, ich mache das mit Vue. Und dann so, aber ich habe ja, wie denn eigentlich?
Ich will ja nur eine statische Seite. Und natürlich kannst du dann auch sowas wie NUX.js einfach nur als Bild-Tool benutzen, wo dann statisches HTML rauspurzelt.
Klar, das gibt es mittlerweile auch bei S-Welt und bei, ich weiß gar nicht mehr, wie es bei S-Welt-Kit ist, glaube ich. Genau.
Genau, und bei React natürlich auch, aber ich fand es natürlich super mit Vue.
Was mir dann auch aufgefallen ist, genau, ich habe auch mal gesagt, ja, das verwendet man dann, wenn man eine statische Seite einfach nur bilden möchte oder wenn ich das eben mit SSA benutzen möchte.
Aber mir ist dann auch recht schnell aufgefallen, ich kann es auch einfach nutzen, um es nur als Vue-Framework zu nutzen, also auch nur als Single-Page-Application, bekomme dann aber.

[12:03] Helferlein oder Best Practices oder vorstrukturierte Sachen rein, die ich bei Vue selber nicht drinnen habe.
Also das Erste, was ich jetzt denke, ich habe einen Folder namens Pages und wenn ich da eine Datei hinzufüge, ist das automatisch der Router dafür erstellt, ohne dass ich jetzt manuell schreiben muss und den Router konfigurieren muss.
Mein großer Kritikpunkt an Meta-Frameworks war dann immer dieses, ich habe ein Framework auf dem Framework. Ich sehe da zwei Nachteile.
Das war jetzt leider sehr View-spezifisch und ich glaube, da sind genügend Entschuldigungen und Sorrys gefallen, aber View 2 auf View 3, war für die, jetzt nicht unbedingt in erster Linie für die Endnutzer, also die Developer, Developer.
Ein ganz großes Problem, es war auch ein Problem, sorry, aber nicht das größte.
Ich glaube, vor allem für die DevTool Developer war es ein großes Problem.
Ich weiß es ehrlich gesagt. Ich höre jetzt oft zu brabbeln.
Ich habe gehört, das war wohl sehr schwierig und deswegen hat es auch bei Beautify und bei Nux recht lange gedauert.
Der zweite Kritikpunkt, den ich da auch immer habe, genau dieses, du musst lernen auf lernen.
Und Vue war ja immer so super, weil es ja so einfach war und so schön war.
Zu erklären, so logisch aufgebaut.

[13:21] Dementsprechend war es vermutlich auch dann eben limitiert und jetzt haben wir so ein bisschen auch im View dieses Ding, du kannst die Options-API lernen, wenn du zum Beispiel noch ein älteres Projekt hast, du musst es vielleicht noch ein bisschen migrieren oder du möchtest es einfach sofort führen.
Das klingt doch immer so blöd, weil Options-API, die geht ja immer noch nicht, meines Kenntnisstandes ist die auch immer noch da und valide.
Ich würde noch nicht weggehen.
Wird auch nicht weggehen, jetzt haben wir es nochmal hier gehört.
Hat auch Evan gesagt, ich suche gerne mal eine Quelle raus, aber hat gesagt, das ist kein Plan der Degradation.
Genau, tausendmal gesagt, auch nie was anderes gehört. Sorry, dass ich es jetzt schon wieder so formuliert hatte, aber den Punkt, den ich eigentlich machen wollte, ist, du kannst eine Options-API, die Syntax lernen, du kannst die Composition-API, die Syntax lernen und dann hast du halt noch die Eigenschaften von Nux.js, die du zusätzlich lernen musst.
Ich weiß noch, dass ich bei der Vue.js Forge, wo ich eine Exercise mitmachen durfte, habe ich die einmal vorher schön durchgeprobt, damit ich da nicht total wie ein Depp dastehe, wenn ich das live und remote machen soll.
Und ich habe es nicht gerafft, warum mein Code fällt, als ich schrieb, import computed from Vue und computed machen wollte.
Und alles hat mich so angeschrien, bis ich kapiert hatte, dass da automatisch ein Plugin drin war, was mir diese Core-Sachen von Vue, die ich so gebrauchen könnte in der Composition API, schon extrahiert oder zur Verfügung gestellt hatte.
Also Refs und Computed und keine Ahnung was, 2Rev wahrscheinlich.
Alles mögliche, tatsächlich. Genau, Reactive auch, wer will.

[14:49] Watch on Mounted. Habt ihr, so ähnlich wie bei Tests, also alle Leute, die vielleicht mit Chess oder mit V-Test, V-Test, Moment, was ist es? V-Test, ja, ja. V-Test.

[15:01] Test schreiben, da ist ja zum Beispiel auch dieses Describe und It oder Expect ist ja auch so Auto-Import und genauso ist es da auch.
Finde ich auch super, aber Aber ich stand da erst mal, hä? Ich check die Wählermeldung nicht.
Und das natürlich, wenn ich dann von dem Projekt auf das andere Projekt springe, kann's verwirrend sein, was natürlich jetzt dein Argument sein könnte.
Ja, dann nimm doch immer Nux, dann weißt du's.

[15:23] Okay, ja. Ich hab rausgehört, auf jeden Fall, dass so ein Metaframework einfach nochmal irgendwie Dinge anders handelt und ein View dann vielleicht sich etwas anders anfühlt.
Man ein bisschen neue Sachen lernen muss.
Und wir dröseln es vielleicht nochmal auf. Also da sind auf jeden Fall ganz viele Punkte gewesen.
Ich fange vielleicht mal mit dem Thema Vue 2 zu Vue 3 an. Vielleicht wurde das auch schon hier des Öfteren mal angesprochen, wenn es um Vue ging.
Ich sag mal so, ich bin auch ein bisschen der Meinung, die Idee am Ende zu sagen, gut, Vue 2, Vue 3 bedeutet nicht nur ein paar Breaking Changes, sondern auch eine neue API, also nochmal ein neuer Weg Komponenten zu schreiben, nämlich die Composition API.

[16:04] Ist an sich erstmal kein Fehler gewesen, dass man sagt, es braucht eine neue API, um Probleme zu lösen, nämlich die Probleme, wie teile ich am besten Code und vor allem, wie gruppiere ich den Code.
Habe ich auch ein sehr langes Video dazu gemacht, für Leute, die von dieser Options API sozusagen, ich gruppiere nach nach Typ, sowas wie, ist es ein Computer Property, ist es State, dann ist das jeweils, gehört das alles immer zusammen in einer Gruppe, zu, ich kann das gruppieren, wie ich möchte, weil ich halt nicht mehr diese einzelnen festgelegten Gruppen habe.
Ein bisschen habe ich darüber erzählt und gesagt, naja, vom Prinzip her ist das große Thema Separation of Concern auch so ein bisschen, ich packe all mein JavaScript in eine Ecke, all mein CSS in eine Ecke, all mein HTML in eine Ecke und sage dann eigentlich, naja, wenn ich Komponenten habe, dann bestehen die ja irgendwie aus Template, aus Business-Logik und Interaktion und aus ein bisschen Style.
Also so Separation of Concerns ist immer so ein bisschen Blickwinkel-Sache und Vue macht das mit den Single-File-Components ja eigentlich auch ganz gut, es ist mir gesagt, eine Komponente wird eben mit den drei Sachen beschrieben, also packe ich die auch in eine Datei und so ist mit der Composition-API am Ende auch ein bisschen das, man sagt, naja gut, ich kann halt gruppieren, nicht bei, nicht nach Typ, also wie gesagt, so der ganze State zusammen, die ganzen Watcher zusammen, die ganzen Methoden zusammen, sondern ich kann halt gruppieren nach wirklich Logik, Domain oder Feature und das dann sogar extrahieren, wenn man möchte.

[17:20] Spannenderweise sind sich dann natürlich nicht alle alle einig in der Entwickler-Community.
Es gibt ganz viele Leute, die sagen, ja, die Options-API, und da gebe ich natürlich recht, die war einfach zu lernen, weil man hat sich ja nie gefragt, wohin mit dem Code.
Man hat halt immer gesagt, okay, ist ein Computer-Property, ja, ich habe ja schon so computet, das ist ein Objekt, da packe ich das einfach rein.
Ja, eine Funktion, ja, kommt in Methods, kein Problem. Und State, da habe ich dieses Data für, da packe ich einfach noch mehr rein.
Das funktioniert wunderbar.
Gerade Anfängern gibt es eine Struktur, zu sagen, ich muss mir jetzt zum einen nicht überlegen, wie gruppiere ich das, ich packe Sagt es da rein, was da reingehört.
Das ist auch genau mein Gedanke, der mir dabei kam.
Das gibt einem so was vor, dem man halt relativ leicht folgen kann.
Auch wenn das am Ende dann natürlich nicht skaliert.
Richtig. Weil früher oder später muss man halt einfach sich Gedanken machen über Architektur und ...

[18:11] Da hilft einem dann die Options-API auf lange Sicht wahrscheinlich nicht mehr.
Und das ist genau, sobald du halt sagst, du hast Funktionalität und dann gibt es schnell den Punkt mit, ja, wenn du so groß, so viele Funktionalitäten hast, dann teile doch die Komponente auf.
Gehe ich mit, teilweise geht das aber nicht. Teilweise hast du einfach so viel Funktionalität in einer Komponente, gerade so im E-Commerce-Bereich gibt es da wieder tausende Sachen.
Aber es ist ein Beispiel von vielen, wo man sagt, naja gut, das sind eigentlich drei verschiedene Funktionalitäten, die eine Komponente mit regelt.
Und dann möchtest du halt nicht sagen, ich muss halt, man kennt das vielleicht aus dem bekannten Screenshot, ansonsten dazu sende ich auch nochmal einen Link, der einmal zeigt, links Options API, rechts Composition API und dann einfach color-coded nach Logik.
Dann sagt man, ich springe vom Anfang irgendwie einmal nach unten in die Mitte und muss mir halt meine Teile zusammensuchen, wie das Ganze zusammenspielt.
Und bei der Composition API, wenn ich es halt, das ist halt da der Punkt, richtig gruppiere, in Anführungsstrichen, also dann nach Logik, habe ich es halt einmal alles zusammen.
Aber natürlich, das ist halt der Punkt, wo man sagt, man hat halt nicht diese klassische Sicherheit, ich weiß halt nicht, wo ich was hinpacke und das kann vielleicht am Anfang erstmal ein bisschen erschlagend wirken, bis zu dem Punkt, wo man würde sagen, ah ja, das ist ja nur eine billige Kopie von React Hooks gewesen, was ich ganz stark bezweifle, wenn es ist eine bessere Kopie, aber nein, Spaß beiseite.

[19:30] Ich verstehe den Punkt auf jeden Fall allerdings auch da, es hält da nichts davon ab, dass man sagt okay, gerade wenn man in einer Firma ist, es gibt dann gewisse Standards, es gibt gewisse Leitlinien und mit Code Reviews und eben da aber auch Leute mit Expertise generell was Architektur und Codes Stil angeht, kriegt man das hin für den, ich sag mal Solo Indie Entwickler, mag das vielleicht ein bisschen schwieriger sein, Und dann gab's doch, glaub ich, auch den quasi den Wechsel von JavaScript auf TypeScript, oder?
Also genau, das ist richtig.
Also Vue 2 war in Flow geschrieben tatsächlich und das wurde dann in TypeScript neu geschrieben.
Das kommt halt dazu. Ich glaub aber, der schwierigste Punkt war wirklich das Thema der Composition API, weil wie es dort gemacht wurde und auch das sind Sachen, die beispielsweise in Avenue nachher so ein bisschen als Lesson Learned sieht.
Es wurde gesagt, Vue 3, neue API wurde entwickelt, RFC, was erstmal gut ist RFC ist uns sehr wichtig, früher war das nämlich klassenbasiert und das haben wir heutzutage zum Glück nicht sondern wir haben das schön composable und funktionsbasiert, und dann haben wir gesagt, okay, das wird in Vue 3 entwickelt bereitgestellt, Leute können es testen und dann irgendwann in Vue 2.7, was deutlich, deutlich später kam wurde das Ganze einmal nach Vue 2 zurückportiert.

[20:52] Und heutzutage so die Lessons learned, hätte man es halt andersrum machen sollen.
Zu sagen, gut, okay, in Vue 2, wir bauen da die Composition-API, wir bauen das Ganze ohne Breaking Changes ein, dann könnt ihr es nutzen, ihr könnt es unter einer Feature-Flag zum Beispiel nutzen oder schon upgraden oder, oder, oder. Und dann haben wir die Breaking Changes.
Das hätte nämlich das Ganze, ja, Options-API wird vielleicht deprecated, FOMO und wir müssen jetzt alles sofort ändern.
Das hätte diese Teilung des Ökosystems vielleicht ein Stück weit abgemildert.
Weil auch heutzutage zum Beispiel, ja, man kann die Options-API nutzen nach wie vor in Vue 3, aber wenn man halt eine Library hat, die zum Beispiel die Options-API nicht supportet in dem Sinne, sondern sagt, ja, Composition-API oder ist nicht, dann steht man wieder vor dem Punkt, kann man schon nutzen, aber in gewissen Situationen wird man vielleicht doch dazu genötigt, oder so ein bisschen genutscht zu sagen, na ja, weiß ich nicht, vielleicht dann doch nicht, zumindest in den Komponenten, wo ich dann Library XY nutzen möchte.
Ja, das finde ich dann das, was einem so ein bisschen auf die Füße fällt, wenn man den Leuten mehrere Möglichkeiten gibt, dass es, immer total nett und ist ja auch freundlich gedacht und macht ja auch erstmal alle glücklich, aber, es führt dann am Ende eben zu mehr Verwirrung oder man hat irgendwie keine klare Linie, die irgendwie feststeht.

[22:15] Also finde ich auch immer doof, wenn es so tausend, du kannst es so machen, aber wenn du das möchtest, kannst du es auch so machen.
Oder Weg Nummer drei. In der Front entdeckt. Ja, stimmt, das ist im Frontend ja gar nicht so unüblich, das ist richtig.
Aber ja, für das Ökosystem, und da sind wir natürlich bei einem Punkt, den Vanessa auch vorhin angesprochen hat, für das Ökosystem war es natürlich schwierig.

[22:37] Beautify wurde schon angesprochen, das war sehr lustig. 2020 war ja John leider der Projektleiter, also der Ersteller auch von Beautify, war ja bei der Vue Amsterdam und hat gesagt, ja, wenn Vue 3 rauskommt, vier Wochen, wir haben es alles migriert, gebe ich dir jetzt meine Hand drauf.
Was ist Beautify noch schnell? ist eine Component-Library für Vue.js basierend auf Material-Design. Genau, das ist ein sehr guter Punkt.
Und ja, Endergebnis war, es ging dann doch nicht so schnell wie gedacht, hat dann ungefähr, weiß nicht, eineinhalb Jahre oder sowas länger gedauert, weil dann geht's natürlich weiter mit, okay, interne Änderungen, Composition-API, was bedeutet das, wie können wir was bereitstellen?
Und ich glaube, Feature-Parity gibt's zwar jetzt immer noch nicht, weil es sehr viele große Komponenten gab, aber es ist halt auf jeden Fall nutzbar.
Und Und ja, ähnlich mit Nux.js, wo das Problem halt noch mal ein größeres war, weil, gut, wir haben ein Metaframework.
Und wir haben im Team auch überlegt, wie machen wir das jetzt?
Okay, Vue 3 ist im Beta-Release, alles klar.
Es gibt auch so eine Art Compatibility-Build, das ist schön. Dann geht's aber los.

[23:40] Vue 2 und vor allem Nux 2 ist sehr Webpack-dominiert gewesen.
Vue 3 und dann Vite vor allem, super schnell, alles toll. Jeder will eigentlich Vite nutzen.
Gut, haben wir ein Veed-Modul erstellt für NUX, konnten die Leute auch damals benutzen, aber eben mit Einschränkungen, weil es war halt nicht so gut integriert wie eine First-Party- oder First-Class-Integration.
Ja, die Vue 2 zu Vue 3 Änderungen, die wir gerade schon diskutiert haben, ist natürlich ein Punkt.
Weitere technische Entscheidungen zu sagen, gut, okay, wir haben eigentlich noch interne Breaking Changes für das Meta-Framework selber, also für NUX, wo wir sagen, naja, wir wollen auch Sachen anders machen, zum Beispiel das Thema NUX 2 auf Serverless, schwierig. Das ist schwierig.
DAX 3 mittlerweile hat eine eigene Server-Engine, auf die wir nachher noch zu sprechen kommen und damit kannst du halt fast überall deployen.
Also egal, ob Cloudflare-Worker, also irgendwie VAD Isolates, Dano auf einem ganz klassischen VPS oder eigentlich überall, wo Node läuft, aber eben auch in Nicht-Node-Environments.

[24:33] Und das waren halt ganz viele Sachen, wo man halt sagt, gut, das kommt halt alles zusammen, sollen wir das jetzt stückweise abhandeln und sagen, gut, wir machen erstmal unsere eigenen Breaking Changes und dann Vue oder andersrum und wir haben auch so ein bisschen versucht, so eine kleine Brücke zu bieten mit, naja, die Composition API, dann als die gebackportet war, könnt ihr hier schon mal mit nutzen und das war aber auch alles nicht super First Class integriert und die Entwicklung hat natürlich auch lange gedauert.
Nux2 zu Nux3 war auch wieder ein Rewrite von JavaScript Script in TypeScript, das ist auch nochmal ein Punkt gewesen und deswegen hat es schon eine Weile gedauert und tatsächlich Nuxt 3 selber, der, nicht Release Candidate, sondern wirklich das Stable Release war Januar 2023, also ist jetzt ungefähr ein bisschen mehr als ein Jahr her und damit ich glaube anderthalb, zwei, sowas in der Richtung, Jahre nach dem eigentlichen Vue 3 Release, was auch schon eine ganz schöne Zeit ist und da gab es natürlich trotzdem Libraries, die gesagt haben, ja, Vue 3 supporten wir, Vue 2 nicht mehr und dann sagen alle.

[25:28] Nuxt-User dann so, meh, Das ging zum Beispiel mit Headless UI so, das ist eine Library vom Tailwind-Team, die gibt es für React und Vue, die stellt effektiv UI-Komponenten bereit ohne die UI, also kann man selber stylen, aber die Funktionalität ist da, auch eben Accessibility-technisch super und ja, da waren wir am Punkt Vue 3 only. Ich habe gesagt, ja, wie sieht es aus mit Vue 2?
Gibt ja auch so ein Library sogar, der sogar den Code in Vue 2 und Vue 3 abbilden konnte.
Und da hat dann Adam Weatherton von Tailwind CSS gesagt, ja, gibt es, ist cool, aber wir arbeiten auf so einem Low-Level, also mit Render-Funktionen und Co., dass das nicht wirklich machbar ist.
So, wer Lust hat auf so eine Community, kann das machen. Gerne sind wir nicht abgeneigt, aber wir geben da unsere Zeit nicht drauf, was ich auch verstehe.
Deswegen, diese ganze Frustration droht darum, und da gehe ich absolut mit, Das war keine angenehme Zeit für das View- und Next-Ökosystem.

[26:20] Aber jetzt ist es ja ein Jahr später und noch deutlich mehr Jahre nach Wii U 3. So ist es.
Hat sich das alles gelegt und entspannt, würdet ihr sagen?
Also haben alle den Schwenk jetzt vollbracht und geschafft?
Also ich glaube, alle nicht. Basierend auch, also Wii U 2 ist mittlerweile End of Life.
Seit Ende letzten Jahres, das muss man auch dazusagen. Also es gibt keine Supports in dem Sinne mehr, nur noch Paid über eine Firma und keine Security Fixes und Co.
Bedeutet an sich, theoretisch sollte jeder Migriert haben.
Praktisch sieht das so aus, dass das Thema Migration bei mir noch öfter auf dem Tisch liegt.
Einfach auch klar, Zeithorizonte für größere Migrationen sind natürlich schwierig und dann zu sagen, ah, lieber ein neuer schreiben es gibt Leute, die haben gesagt, okay, Vue 2, alles gut, aber wenn wir es eher mal neu schreiben, machen wir es vielleicht doch in React, weil es halt der Platzwürsch ist, allein Adoption-mäßig, andere haben gesagt, gut, ich will es in Vue 3 machen, haben auf, weil sie zum Beispiel Nux 2 benutzt haben, dann auf Nux 3 gewartet, und ich glaube, viele haben den Sprung schon geschafft, es gibt vor allem auch sehr viele Leute, die Nux in dem Jahr jetzt auch so ein bisschen für sich entdeckt haben, weil es da sehr viele Features gab, die es vielleicht in anderen Metaframings doch nicht gibt, obwohl sie sich alle sehr ähnlich sind.

[27:44] Aber ja, ich glaube, es gibt immer noch so einen leichten Bruch in der Community, gerade eben auch nach dem, Video mit, okay, wenn ihr die Optis API genutzt habt und dann das gleiche in der Composition API so schreibt, ist nicht so clever und dann ganz viele Leute gesagt haben, ah nee, furchtbar, nein, bitte, wir müssen das genauso weitermachen, habe ich auch so gemerkt, okay, hätte ich vorher vielleicht gar nicht so sehr erwartet, Es gibt noch sehr viele Anhänger der alten Art und Weise.
Und manchmal wird man auch die Meinung nicht ändern können, was da voll okay ist. Aber da sieht man noch so einen leichten Bruch, denke ich.
Ja, na ja, die Leute, theoretisch zumindest, dürfen sie ja auf den alten Versionen einfach glücklich weiterarbeiten. Klar.
Genau, können halt dann irgendwie Plugins und Co. nicht aktualisieren, nicht mehr hochleveln.
Aber genau, irgendeinen Tod muss man ja dann sterben.

[28:33] Und würdet ihr sagen, jetzt ist ja Vue 3 schon eine Weile da, ich weiß nicht, ob an Vue 4 gewerkelt wird, also sind da ähnliche Umbrüche am Horizont?
Du bist nicht die erste Person, die mich damit schon konfrontiert jetzt.
Wie schaust du mit Vue 4 aus? Arges Kopf für da. Vielleicht ist ja auch keine Notwendigkeit für da, also man muss ja nicht sozusagen des Release-Willens releasen.
Also, wenn ... Ich find's, glaub ich, auch nur ... Ich mein, wir haben jetzt V3. Was haben wir grad? React 18?
Oder so was? Das ist doch, glaub ich, hier seit anderthalb Jahren in Beta oder so was. Oder in Alpha.
Und die Vercel-Menschen nutzen das doch schon fleißig. Ach so, Canary, ja, das kann sein, genau. Aber aktuell ja, 18, ja. Mhm.

[29:20] Hey, ich kenn das nicht. Ja, View ist doch total schlecht dann, wenn das nur Version 3 ist. Total mies, hängt ja voll hinterher.
Wir brauchen halt nicht so viele Break-and-Changes. Einmal und dann richtig.
Aber nicht so sehr wie bei AngularJS zu Angular. Das wollen wir uns nicht vorhalten lassen.
Ja, das ist auch mit den Namen. Sie hätten auch einfach einen ganz neuen Namen nehmen können. Das war, glaub ich, der größte Fehler, dass sie den Namen behalten haben.

[29:43] Wir haben das JS jetzt weggelassen. Jetzt wird alles besser.

[29:48] Aber nein, er ist ... Ich hab keine Ahnung. Ähm, Alex, View 4?
Ja, ich denke, View 4 wird jetzt in nächster Zeit nicht kommen, ähm, weil ich denke, mit der Composition API sind eigentlich alle recht glücklich, wie das, äh, soweit ist.
Es gibt natürlich weitere Miner-Releases, die auch wichtiger sind mit neuen Features.
View 3.4 kam jetzt vor Weihnachten, nee, sorry, vor Silvester, zwischen Weihnachten und Silvester raus, ähm, mit einigen coolen Updates, sowohl für Leute, die Server-Side-Rendering nutzen, Stichwort Hydration Errors, sind immer die größten Freunde, ähm, bedeutet also, wenn der, wenn man Server-Side-Rendering nutzt, wird ja Teil auf dem Server gerendert, Und dann Vue auf der kleinen Seite sagt dann, okay, ich nehme das HTML und mache es reaktiv, also bringe es in meine Repräsentation.
Wenn Vue auf dem kleinen was anderes erwartet, als der Server wiedergibt, gibt es einen Mismatch, also einen Hydration Error.
Und die sind immer unschön zu debuggen. Das ist aber besser geworden.
Abgesehen davon verschiedene neue Compiler-Makros, weil Vue auch einen Compiler nutzt, und Shorthands, also da passiert relativ viel.
Ich habe das Gefühl, dass jetzt vor allem für diese 3.4-Version sehr, sehr viele Patch-Versionen auch released wurden.
Also es da hinterher geht mit Bugs fixen, neue Sachen raushauen, das scheint mir auf jeden Fall sehr belebt und ja, ich glaube, also über Vue 4 brauchen wir nicht groß reden, über Nux 4 vielleicht schon eher, aber ja, bei Vue stehen erstmal alle Zeichen auf, alles stable, keine Sorge.
Einfach nur Feinschliff jetzt. Genau. Und hier sind da neue Features natürlich auch, aber nichts, wo man sagt, jetzt müssen wir nochmal alles umstellen. Mhm.

[31:13] Sehr gut. Aber dann lass uns doch wieder zu Nux zurückkommen.
Du hattest jetzt zwei Sachen gesagt.
Das eine war, es gibt ein paar coole Features, die andere auch nicht haben.
Nee, fang mal anders an. Fangen wir mal mit den Basic. Ich glaube, wir haben jetzt gerade ganz viel über Vue 2 und Vue 3 gesprochen.

[31:30] Aber bleiben wir mal bei Nux. Wir haben genannt, ich habe ein cooles Ding, dass die Sachen werden automatisch importiert, die ich benutzen könnte, die Funktionen und Typen.
Und ich habe gesagt, ich kann Dateien in den Pages-Folder reinschreiben und dann wird das automatisch eine Route. Aber das hat ja bestimmt noch viel mehr.
Genau, also nochmal vielleicht noch basic-mäßiger. Also Nuxt benutzt man, du hast es vorhin einen Use-Case genannt, also Suchmaschinen-Optimierung ist halt immer so ein Ding mit Single-Page-Applications, die kann die Google, der Google-Crawler kann die rendern, aber es ist halt ein deutlich höherer Ressourcenaufwand, Und darum ist es halt cool, wenn man eben schon vom Server fertiges HTML bekommt, das ist halt leichter zu parsen.

[32:17] Genau, und auch Performance war ja auch generell ein Thema.
Ich glaube, auch da war Google wahrscheinlich der Treiber mit den Core Web Vitals und so First Contentful Paint und solche Metriken, wo man einfach architektonisch im Nachteil ist, wenn man nur auf Single Page Applications setzt.
Weil das halt einfach, da muss halt mehr rübergeschickt werden, da muss dann erstmal gepasst, kompiliert und ausgeführt werden.
Das hat man halt nicht, wenn man schon von Anfang an HTML schickt und das macht Nuxt oder das machen alle diese Meta-Frameworks im Endeffekt, die füllen diese Lücke und arbeiten, glaube ich, noch in so einer Folder-Struktur, wie du es schon gesagt hast.
Das ist so ein bisschen so, wie man vielleicht auch generell, wie statische Seitengeneratoren aufgebaut sind.
Ja, oder eben, wenn man noch weiter zurückgeht, so wie PHP mal klappt mit, ich ziehe jetzt hier meinen Index.php rein und dann ist es einfach da.
So von der Developer-Experience her, sage ich mal, ist die Idee da auch her.

[33:16] Und genau, jetzt nochmal zu den Use Cases. Vanessa hatte vorhin auch noch sehr gute Punkte erwähnt, nämlich genau, Server-Site-Rendering dynamisch einmal, also eben ich habe jetzt beispielsweise, ich habe einen Webshop und ich möchte auf der Produktseite dynamisch anzeigen, wie viele sind noch da und halt, wenn es neue Seiten gibt, wenn es irgendwas ausverkauft ist oder oder.
Oder dann das Ganze kann man halt auch, also Server-Side-Rendering zur Bildzeit kann man machen.
Das nennt sich dann Static-Side-Generation oder Pre-Rendering.
Also eben, okay, ich habe jetzt mein Portfolio von mir selbst und ich ändere da jetzt nicht zukündlich was dran. Ich habe vielleicht kein CMS dahinter, sondern Markdown.
Aber ich hatte halt gerne eine statische Seite, die aber trotzdem, nachdem sie geladen ist, das ist immer bei Server-Side-Rendering so mit den Frameworks, dann in eine Single-Page-Application überführt wird.
Also der initiale Request ist eben, serverseitig gerendert, egal ob jetzt zur Laufzeit über einen wirklichen Server oder zur Bildzeit und dann als HTML schon mal in CDN gepusht, aber in dem Fall ist es halt immer so, serverseitig kommt das HTML, Nux und View nehmen das und wandeln das dann effektiv einmal in eine interaktive Single-Page-Application wieder um.
Das ist eben dieser Hydration-Prozess, den ich mal kurz erwähnt habe.
Und das ist halt nochmal ein wichtiger Punkt, das hatte Vanessa auch vorhin schon sehr gut erwähnt, man muss halt nicht zwingend Server-Side-Rendering nutzen, man kann auch sagen, ich baue eine klassische Single-Page-Application trotzdem mit diesem Meta-Framework.

[34:40] Das ist tatsächlich auch nicht üblich, ich weiß nicht, wer stand bei Next.js ist, aber das war mal ein großer Kritikpunkt mit, naja, ich brauche eigentlich gar kein Server-Side-Rendering, jetzt kann ich das vielleicht hier und da ausstellen, aber so eine komplette SPA so ganz klassisch bauen, habe ich zumindest von vielen Leuten gehört, das ist, wenn, nur mit einigen Hürden möglich.
Und bei uns ist es halt okay, next, man setzt SSR false und ist fertig.
Also ich bestätige das. Ich wusste nicht, dass es bei Nexten...
Doch, stimmt, der hat doch letztens bei uns gerade eben... Doch, doch, ich erinnere mich, da hat letztens jemand geschrieben, wie geht das denn bei Nexten? Ich sehe ja keine Ahnung.
Gibt es doch nicht so ein SSR false? Jetzt erinnere ich mich da dran.
Ich kann bezeugen, das war genau so, wie gesagt, mein einziger Punkt.
Und ich möchte es gleichzeitig nämlich als Vorteil und als Nachteil einfach so verkaufen.
Ich fand das auch großartig. Ich meine, es ist jetzt auch nicht unbedingt schwer, einen Router zu schreiben, aber das hört ja nicht auf.
Ich glaube, da war ganz schön sehr, sehr viel mit diesem asynchronen Laden und asynchrone Komponenten, Dynamic Loading, alles schon vorbereitet.

[35:42] Das kann eben nur dementsprechend so eine Art Nachteil sein.
Das hat nichts mit Nux zu tun, sondern das hat was mit Meta zu tun.
Je mehr Magic du auf je mehr Magic du hast, desto schwieriger wird vielleicht mal auch auch zu verstehen, dass das auch nur eine Funktion dieses Meta-Frameworks ist und das hätte man auch selber implementieren können.
Mein Klassiker, den ich da immer nenne, ist dieser Nuxt-Link, den es gibt, wo mir mehrere Developer ganz freudig erzählen, hey, siehst du den Nuxt-Link und der kann so prefetchen und so.
Und ich so, ja, Link-Prefetch.

[36:15] Und das kann...
Ich will mich gar nicht drüber lustig machen. Das Problem, das dabei entstehen kann, ist, dass ich vielleicht das dann irgendwann nicht mehr so gut debuggen kann, weil ich selber nicht mehr die Foundation darunter verstehe.
Auf der anderen Seite, jetzt will ich mit mir selber argumentieren, muss ich das immer ganz genau verstehen, weil eigentlich ist mein Job vielleicht auch einfach, Features zu shippen und je mehr, Developer-Tooling ich damit in die Hand bekomme, desto schneller kann es halt auch sein und ich muss nicht schon wieder das Rad neu erfinden, um mir meine Prefetching selber zu bauen.
Sondern es ist einfach da und ich nutze es einfach und es ist super.
Ich glaube manchmal, ich bin ziemlich sonst eher auf der Low-Level-JavaScript-Ebene vielleicht noch unterwegs, habe es aber auch schon irgendwie von anderen, ganz anderen, also von nicht Web-Developern, sondern von anderen Developer-Freunden irgendwie gehört, so, wieso habt ihr da jetzt kein Framework für, wieso musst du das selber machen?
Und ich so, ja, weil sonst müsste ich mich zwischen acht Frameworks entscheiden und ich kann nicht.

[37:06] Ja, das sind total valide Punkte. Ich bin da so halb auf deiner Seite, in Anführungsstrichen, denn ich sehe das auch so ein bisschen zwiegespalten.
Ich bin auch ein großer Freund davon. Ich will zumindest grob wissen, was darunter passiert.
Also zum Beispiel, dass der Nux-Link auch nur auf dem Router-Link von Vue-Router passiert und dann halt einige schöne Sachen macht, wie mal versucht mit dem Router-Link vom Vue-Router auf eine externe Seite zu verlinken.
Wird schwierig. Schwierig.
Nux Link baut es einfach direkt mit ein, sodass man da jetzt keinen Stress mehr hat. Seit Nux 3, aber geht. Ich meine, warum auch nicht? Es ist ja super.
Und dann, ja genau, so Prefetching ist tatsächlich ein bisschen mehr als Link Prefetch, einfach weil man halt die ganzen Ressourcen der extra Seite fetcht.
Aber genau, das sind auch Sachen, wo zum Beispiel dann Leute sagen.

[37:49] Hä, warum lädt er denn das CSS von der anderen Seite, die da verlinkt ist?
Und das ist aber irgendwie ein MB groß.
Und weil ich habe noch 3.js und da 1000 Sachen, das soll der gar nicht laden.
Warum macht er das denn? Das ist ein Issue, den habe ich heute in der Next-Repo gesehen und dann geantwortet und gesagt, ja, hier, Next-Link Prefetching.
Dann geht's aber weiter.
Das Problem, was du gerade für Metaframings beschrieben hast, ist das gleiche für Component-Libraries, mit dem entweder baut man es halt selber und hat halt, man ownt die Implementation, bedeutet auch Maintenance, aber man weiß halt theoretisch, was passiert oder zumindest das Team, oder ich nutze eine Component-Library, wie in dem Fall der Nutzer, der dann sagt, hey, ich habe doch aber gar keinen Next-Link, aber trotzdem passiert das. und warum wird der denn genutzt?
Und dann geht's halt weiter mit, naja, die Component Library sagt halt, okay, wenn du Nux hast, dann ist halt der Button, wenn du ein True-Attribut mitgibst, ist halt dann ein Nux-Link.
Oh, das war's dabei, stell ich mir auch schön vor. Oh, da können wir vielleicht noch eine dritte Episode zu machen.

[38:44] Aber ja, das sind so Szenarien, wo man natürlich sagt, okay, das, was darunter liegt, verstehen, ist halt super wichtig. Und.

[38:51] Die Dokumentation ist dann natürlich das A und O, also zumindest zu sagen, okay, das ist die Funktionalität davon, hier ist vielleicht ein Link zum Source-Code und zu Top-Level oder High-Level, was passiert.
Schlimmer wird es beim Thema Data Fetching. Habe ich auch ein langes Video zugemacht, das Thema Composables auch generell.
Also mit Vue Composition API kann man Composables nutzen, das sind am Ende Funktionen, die eine Art und Weise von State halten, der kann reaktiv sein, und die Composition API am Ende unter der Haube nutzen.
Also sowas wie, ah ja, bei einer Lifecycle-Hook, mach das, oder guck dir mal den State hier an, oder du kriegst was Reaktives rein, was dann was macht.
Und die können auch zum zum Laden von Daten benutzen werden.
Also bei Nux ist das so, es gibt was, das nennt sich Use Fetch, das ist also die Idee, es wird einfach die Fetch-API am untersten Level genutzt, um Daten zu holen.
Wenn du aber sagst, okay, der Link ändert sich, dann werden die Daten neu geladen.
Oder, okay, ich kann Parameter nutzen, um die aufzubauen, auch da, wenn die sich ändern, wird das Ganze neu geladen.
Das ist super nützlich für, oh, ich kippe meine ganzen Filter rein, die gebe ich als Query-Parameter zum Beispiel für die API rein, wenn sich da was ändert, muss ich es nicht manuell machen, sondern sondern weil es alles reaktiv ist, passiert das direkt.

[40:04] Erstens müssen das natürlich Leute wissen, dass das so funktioniert.
Und zweitens, die Composables haben natürlich eine Einschränkung.
Und die Einschränkung ist, die dürfen halt nur in einem View-Kontext genutzt werden.
Bedeutet also, man kann jetzt nicht sagen, ich initialisiere so ein Composable in einem Händler von zum Beispiel einem Click-Event.
Weil das kann sich dann nicht mehr selber aufräumen. Und auf einmal passiert es, dass ich aus Versehen mein Formular bei jedem Tastendruck zwei, drei, vier, fünf Mal absende, weil ich eben dieses Architekturprinzip Composables nicht verstanden habe.
Und auch da ist natürlich der Punkt mit, okay, man kann halt nicht einfach sagen, ich baue drauf los, weil sonst wird es vielleicht und es funktioniert, aber es gibt halt dann ganz viele Edge-Cases oder Szenarien, die man halt vielleicht gar nicht gewollt hat.

[40:51] Ja, und das klassische Problem von Magic, also das ist ja immer so, also wenn's so, wenn's läuft, läuft's super und alles ist megacool, aber wenn dann Dinge merkwürdig werden und man versuchen muss, das zu debuggen.

[41:09] Dann wird's immer ein bisschen, da wird's ein bisschen anstrengender.
Das stimmt absolut, das ist richtig. Und da denke ich, also wie gesagt, das Thema Dokumentation ist da halt ganz wichtig, egal ob jetzt auf der Nux oder auf der View-Seite nochmal zu erklären, okay, Composables, es gibt eine ganz lange Dokumentationsseite dazu.

[41:27] Aber einfach auch als Verständnis dann zu sagen, gut, es gibt halt Szenarien, wo du das halt nicht nutzen solltest und das macht einen großen Unterschied, ob du eine Funktion hast, wie, keine Ahnung, ich, keine Ahnung, pack den ersten Buchstaben von einem String uppercase, also sowas wie eine Capitalize-Funktion oder ähnliches, oder ich habe halt eine Funktion, die sagt, okay, ich behandle halt eine Art State von einer Komponente oder von einer Applikation, und Und den Unterschied, gerade so Junior-Entwickler, den kennen die vielleicht nicht, weil die damit noch nie gearbeitet haben.
Oder sagen, okay, hier ist deine Funktion, ich rufe die auf, in JavaScript geht das ja auch.
Und ich denke, da ist sehr viel Dokumentation und Wissenstransfer halt natürlich wichtig.
Und da geht es zum nächsten Problem mit, okay, Dokumentation, wir brauchen ein gutes Level zwischen, die muss schon, einmal muss sie sehr schnell verständlich machen, was es ist.
Also wir haben jetzt die Funktion useFetch, die macht das. Hier, das sind die Optionen.
Dann vielleicht noch ein Beispiel.
Dann wäre es aber auch schön, wenn man einen weiteren Kontext hätte, sowas wie Best Practices, hier sind noch mehr Beispiele, hier ist eine ausführliche Beschreibung.
Aber es gibt viele Leute, die sagen, mir reicht genau diese Abschnitte am Anfang und der Rest ist für mich Zusatz.
Auf der anderen Seite, die würden halt bei eben so einem langen Text dann eben aussteigen.
Und da ist auch richtig abzupassen, ist auf jeden Fall schwierig.
Total. Das ist echt eine Kunst, eine gute Doku zu schreiben.

[42:47] Genau. Da gibt es aber nicht ohne ohne Grund auch wieder Spezialisten dafür eigentlich.
Richtig. Aber ja, jetzt sind wir so ein kleines bisschen von, also von Nux generell weitergekommen.
Ja, nochmal zu dem Use Case für diese Meta-Frameworks. Genau, es gibt weitere schöne, tolle Funktionen, weshalb ich zum Beispiel auch, egal ob ich eine SPA baue oder nicht, auf Nux zurückgreife.
Und den einen Aspekt der Familiarität haben wir auch schon so ganz grob tangiert.
Dann zu sagen, gut, ich habe meine Ordnerstruktur, ja, Components, Common Components, Pages in Pages, ich habe vielleicht meine Lieblingsmodule in Nux, die ich noch nutze, die effektiv sagen, oh ja, hier kann ich mal Plausible Analytics reinladen oder das macht was schneller mit einer experimentellen Methode.
Hier sind SEO-Optimierungen direkt out of the box.
Da kann ich meine Open Graph Images für diese kleinen Link-Preview, wie man die im Social Media Network teilt, der Wahl, oder irgendwie im Messenger, dass man da so einen kleinen Preview bekommt mit dem Bild, dass das alles geht und dynamisch generiert wird.
Das sind dann alles Sachen, die macht Nux nicht im Core, sondern die werden halt ein Modul ausgelagert, weil nicht jeder braucht halt diese SEO-Optimierung und trotzdem sind die nützlich.
Und natürlich ist auch der Punkt gut, wenn man sich einmal daran gewöhnt hat, die Sachen funktionieren, die Sachen gibt's, die nutze ich in einem weiteren Projekt, dann ist halt die Schwelle auch nicht so hoch zu sagen, okay, das passt auch fürs nächste.
Und wenn ich die Module nicht brauche, dann haue ich die halt raus.

[44:10] Und durch diese Module lässt sich Nux halt auch insoweit erweitern, dass man sagt, okay, ich kann halt direkt Funktionalitäten des Frameworks selber anpassen.
Zum Beispiel, ah ja, die Seite wird jetzt per Server-Site-Rendering gerendert.
Bevor die rausgesendet wird, ändere man noch das HTML.
Oder ich generiere mir die Seite schon mal vor, also Static Site Generation.
Wenn die fertig ist, generiere man noch die Seite mit oder füge mal da einen Pfeil hinzu. Oder, oder.
Und das hat natürlich den großen Vorteil, sobald es irgendwelche Business Requirements gibt, zu sagen, okay, ich habe schon verrückte Sachen gesehen.
Und du sagst, warum braucht ihr das aber wieder? Weil naja, es gibt dieses Requirement, die Entwickler sagen, wir können halt nichts machen, so soll es halt sein.
Dann hilft es natürlich, wenn man ein Framework hat, was sich auch anpassen lässt und wo man halt nicht erst sagen muss, jetzt muss ich da die nächsten Hack drum herum bauen, sondern habe eine Möglichkeit daraus, ich sag mal, idiomatisch zu integrieren, also eigentlich so, wie es gedacht ist.
Du, ich finde es super wichtig, dieser Punkt, den du sagst. Ich meine, klar, wir jetzt unter uns Devs, wir finden da gern unseren Schmunzler, wenn wir da Business-Sachen halt so machen müssen, obwohl die sind vielleicht, merkwürdig, aber das ist halt die Realität.
Also ich glaube, ich hatte noch nie ein Projekt, wo ich nicht für mich gefühlt was Komisches machen musste und das ist auch die Aufgabe an uns Developer, dass wir aus nichts irgendwie was erschaffen können und da ist es natürlich extrem wichtig.

[45:32] Dass mein Framework mir dann diese Möglichkeiten erlaubt und ich glaube, das ist für mich jetzt immer die Sorge, auch bei zum Beispiel eher UI-Frameworks jetzt oder beziehungsweise alles, was halt nicht headless ist.
Ich bin jetzt immer super begeistert von solchen Tools wie jetzt Storyblock oder den TipTap Bridge Text Editor, wo man mir eine unfassbar einfache Schnittstelle gibt und hier mach den Rest draus, wie du willst.
Nicht irgendwie, also wenn du jetzt genau Custom Properties slash CSS-Variablen oder du gibst uns in diesen, also diese Property in CSS-Datei mit, dann kannst du diese drei Farben ändern.
So, ich bräuchte aber ein anderes Padding oder sowas.
Das ist ein großartiger Schnittstern. Und du hast mir jetzt gerade anscheinend Nux so verkauft, als wäre das dann, weil es auch so modular aufgebaut ist, Plugin-Format.
Dann kann ich auch meine Quirkies da mit reinbauen, die ich so brauche.
Absolut, also genau dafür ist es da, es gibt sogenannte Nux-Tooks, auch da nichts zu verwechseln mit React-Tooks oder ähnliches, sondern einfach, was mir sagt, in verschiedensten Prozessen, in verschiedensten Schritten des Frameworks hake ich mich ein und sage zum Beispiel, wir haben ja dieses File-System-Based-Routing erwähnt mit, ich schiebe meinen Index.View in Pages und wer sagt, er möchte das nicht, kann es entweder generell ausstellen oder ich sage, ich möchte noch eine Seite hinzufügen, ja, die kann ich halt so nicht abbilden oder will ich nicht so abbilden oder die kommt aus meinem CMS zur Bildzeit, die kann ich, also geht halt nicht.
Dann kann ich sagen, ich rufe so eine Hook auf, die heißt Pages Extend, also ich erweitere die Seiten und gebe das dann da entsprechend an.

[47:01] Also quasi so eine virtuelle Datei injecten, die es gar nicht gibt zum Beispiel.
Genau, das kann eine virtuelle Datei sein, das kann auch eine echte Datei sein, wie auch immer man es machen möchte.

[47:10] Ich denke, daran merkt man dann, dass dieses Framework ist halt schon sehr weit von den Kinderschuhen entfernt, das ist da etabliert.

[47:18] Ich denke, bei so vielen kleineren Frameworks, die da so ein bisschen aufpoppen und so vor sich hin leben, die sind bestimmt super für viele kleine Projekte wie Landingpages oder ich brauche meinen eigenen Blog.
Aber die Personen, die dann wirklich so einen E-Commerce-Shop bauen müssen, werden vielleicht nicht auf dieses ganz kleine Framework setzen wollen, genau aus diesen Gründen, weil irgendwas kommt immer, dass es nochmal spezieller wird.
Was wäre denn sonst noch so dein nächstes Lieblingsfeature, was man so machen kann?
Ich glaube, ich hatte selber diese asynchrone Components erwähnt und vielleicht kannst du auch die nochmal mit einbringen. Ja, sehr gerne.
Das ist nicht mein Lieblingsfeature, aber habe ich tatsächlich auch schon drüber berichtet. Es gibt so ein Lazy-Prefix, nennt sich das.
Also ich habe eine Komponente zum Beispiel, sag ich mal, die heißt MyButton und wir haben auch da wieder ein Auto-Import, heißt, wenn ich die in Components-Folder packe, dann muss ich die nicht irgendwie importieren, sondern da kann ich die direkt im Template-Inview nutzen. nutzen.
Also auch hier wieder Signal vs. Noise, im Sinne von ich muss den Import nicht schreiben, wenn das halt MyButton heißt, kann ich auch wieder per Deklaration in das File kommen, guck mir das an.
Und natürlich volle TS-Integration, volle IDE-Support, also da fällt nichts weg.

[48:25] Der spannende Teil wird, der dass man sagt, okay, ich habe auch die Option Lazy MyButton zu integrieren und hier ist die Idee, wenn ich zum Beispiel ein Model habe, was ich über einen VIF öffne, also ich sag zum Beispiel, wenn ich den Button gedrückt habe, dann zeigt mir dieses Model an, dann ist diese Lazy-Prefix super, weil dann wird halt aus dieser Komponente ein eigenes JavaScript-File, was auch erst geladen wird, wenn es gebraucht wird.

[48:49] Und das muss ich halt nicht aufwendig programmieren oder ganz die Boilerplate für haben.
Ich kann halt einfach Lazy davor setzen und in anderen Szenarien, wenn ich halt das Lazy nicht brauche, dann lasse ich es halt weg.

[48:58] Also so ein bisschen wie das Quick-Framework das ja auch macht, wobei bei denen ist ja so, ist ja, glaube ich, alles Lazy.
Bei Quick geht es ja eher um Resumability. Das ist Genau, das ist nochmal eine ganz andere Ecke, die vor allem auf dem View-Level eher gelöst werden muss, auch da, wobei man auch hier sagen muss, dieses Lazy ist halt auch nur eine nice oder eine ganz nette Convenience und Erleichterung um Sachen, die View an sich schon kann.

[49:27] Okay. Genau. Wobei, es gibt auch Sachen, die Vue an sich nicht schon kann und die dann entsprechend von Frameworks wie in dem Fall Nuxt gelöst werden.
Nämlich, wir hatten die React-Server-Components schon erwähnt.
Es gibt auch Vue-Server-Components, aber eben nicht in Vue, sondern in Nuxt.
Heißt das, nein, keine Vue-Server-Components. Okay, es sind Nuxt-Server-Components.
Willst du mal kurz erklären, was man darunter verstehen kann?
Weil ich denke halt so, Moment mal, ist NUX nicht quasi die Server-Component-View oder quasi die Server-Side-Geschichte dazu? zu, also, und genau.
Okay, wir hatten ja schon das Thema Hydration und Server-Setter-Rendering so ein bisschen erklärt, also ganz klassisch eben Content, sag ich mal, die Seite, die Ansicht, wenn wir jetzt diese Index.View in Pages haben und die hat eine Komponente, dann, wenn ich den Browser öffne und sag, ich geh jetzt auf slash, also, was ist, example.com, das ist meine Nuxt-App, dann sagt der Nuxt-Server halt, wenn ich dieses dynamische Server-Set-Rendering habe, okay, der Request geht dorthin, ich rendere also meine View-Applikation einmal auf dem Server, mache vielleicht API-Kurse auf dem Server, bekomme die Daten, je nachdem, wie ich das halt eingebaut habe, dann sende ich das HTML alles zurück an den Browser mit ein bisschen JavaScript, dass ich da eben NextMVue laden kann und das dann in eine Single-Page-Applikation überführt wird.

[50:46] So weit, so gut. Der spannende Teil ist aber, wenn wir sagen, naja, okay, wir haben vielleicht irgendwelche Inhalte, die sind statisch oder die brauchen, machen wir es mal anders, die brauchen keine Interaktivität.
Das Prinzip an sich kann man auch so ein bisschen als Reverse-Island-Prinzip interpretieren. Wer die Island-Architektur kennt, zum Beispiel von Astro, zu sagen, okay, alles, was ich nicht direkt interaktiv mache, ist statisch.
Also ich sage, wenn ich halt Interaktivität möchte, nehme ich ein Framework, was ich möchte, wie irgendwie Vue, React und so weiter und mache was interaktiv.

[51:20] Bei Next ist es einmal andersrum, weil wir halt diese standardmäßige Interaktivität und im View haben, heißt, wir haben eigentlich Server Islands oder eben Server Components und sagen, okay, wenn wir was Statisches brauchen, kein Problem, dann haben wir effektiv einen API-Endpunkt, da sagen wir, wir definieren eben vorher unseren Component mit eben .server.view und wenn der geladen wird, wird halt ein Call an die API gemacht und am Ende wird einfach nur HTML eingesetzt. Was spart uns das?
Naja, dieses Hydration-Thema mit, die Komponente wird halt von Vue dann nicht mehr reaktiv gemacht, das kostet halt CPU-Zyklen und ist halt overhead, zumal wenn es halt nur statisch ist, ist es statisch.
Dann ist es mittlerweile so weit, dass wir sagen können, in dieser statischen Komponente kann ich auch wieder kleinseitige Komponenten haben mit Interaktivität, was auch super ist.
Und diese Komponenten können sogar Properties haben. Heißt, wenn ich sage, okay, ich gebe da beispielsweise ein bisschen Markdown rein, was ich gerne gerendert haben möchte in HTML und das Markdown würde sich ändern, dann würde erneut ein API-Call geschehen und dann würde es dann auf dem Server rendern.
Ist wahrscheinlich einfacher, wenn ich sage, ich habe einen Slug von einem Post in der DB, der Slug ändert sich und dann wird eben die Server-Komponent neu gerendert und alles, was CPU-intensiv ist und eben keine Interaktion benötigt, kann man dann auf dem Server geschehen lassen.

[52:41] Okay, verstanden.

[53:04] An der API vielleicht mal was geändert wird. Das heißt, man kann die benutzen.
Ich nutze die tatsächlich auch schon in Production in verschiedenen Projekten.
Die funktionieren sehr gut.
Aber natürlich die Version pinden ist da wichtig, weil experimentelles Feature bedeutet, Breaking Changes können halt auch schon in einer Miner oder Patch-Version zwar unwahrscheinlich, aber könnte passieren.

[53:23] Du hattest auch noch Features erwähnt, die es bei anderen vielleicht nicht gibt.
Genau, also die Server-Components sind ein so ein Ding, aber ich glaube, also wir sind vor allem im Nux-Team natürlich, wie auch viele andere auch, aber wir sind vor allem auf dieses Thema Developer-Experience sehr bedacht.
Und wer sich mit Vue auch schon ein bisschen auseinandersetzt, weiß, es gibt ja die Vue-Dev-Tools und, Anthony Fu aus dem Team ist auch im Vue-Core-Team und im Vite-Core-Team.
Ja, Herzen von Alessa da.
Gebe ich in dem Fall auch raus. Das ist ein Megatyp.
Der hat einmal die NuxDevTools entwickelt.
Das ist also, und das ist das Beste, das ist eine Anwendung, die sitzt in der eigentlichen Nux-Anwendung. Das ist ein Nux-Modul.
Das wird geladen, wenn die Nux-Anwendung geladen ist. Und man kann damit total abgefahrene Sachen machen.
Es ist also eine Nux-Anwendung in einer Nux-Anwendung. Und nur als Beispiel, um mal zu zeigen, was die denn alles so machen könnten.
Man kann in diesen DevTools eine VS-Code-Anwendung laufen lassen, die sich mit dem Editor auf dem Rechner verbindet und kann also über die DevTools, eine NUX-Anwendung in seiner eigentlichen NUX-Anwendung, seinem Projekt, diese Anwendung bearbeiten.

[54:36] Das funktioniert über APC-Cores und so weiter und so weiter, aber am Ende ist es halt eine sehr, sehr elegante Integration zwischen dem Nux-Server und dem Projekt, was halt läuft und dieser Anwendung in der Anwendung und da kann man so Sachen machen wie analysieren wir das Bundle, zeigt mir mal an, was geladen ist an Daten, gibt mir mal alle Routen aus, alle Komponenten und auch da, Sky is the Limit, man kann in die DevTools verschiedene andere Sachen integrieren, also auch Module können sagen, ich integriere mir das Ganze, sie mal, weil ich hätte da gerne eine Ansicht, zum Beispiel für diese Open Graph Images, die ich vorhin erwähnt habe, zu sagen, okay, du hast da eine View-Komponent angegeben, die wird dann gerendert, hier, so sieht das aus, ich habe mal eine Preview für dich, und das ist eine wunderbare Möglichkeit, zum Beispiel auch zu sagen, okay, für mein Projekt schreibe ich mal so eigene Mini-Dev-Tools mit A, mache ich mal zu dem User, mache ich mal Admin, gebe ihm mal die Rechte, ohne das, aufwendig irgendwie mit, ich muss dieses Skript ausführen, sondern ich habe dann einfach drei Buttons in diesen Dev-Tools.

[55:35] Sehr cool. Und jetzt einfach Interesse halber, weil ich ja mit keinem der Frameworks arbeite, ist das denn, also das gibt's zum Beispiel dann jetzt nicht in Next.js zum Beispiel sowas? Genau, also kein anderes größeres Framework hat so eine Art von DevTools.
Jetzt gab es zwar natürlich die Bestrebung zu sagen, okay, was ist, ich Remix arbeite in DevTools.
Astro hat tatsächlich auch, ich glaube vor einem Monat oder sowas, auch eigene DevTools mit rausgebracht, die jetzt nicht eins zu eins das Gleiche können, aber was Ähnliches und dann noch Sachen wie Accessibility-Fehler können gefunden werden und so weiter. Also auch da gut Integration hat.
Aber ansonsten, diese Art von DevTools ist kaum verbreitet.

[56:16] Okay, und der Anthony kriegt dauernd wahrscheinlich irgendwie Avancen von Guillermo Rauch und den anderen. Der arbeitet sicher bei Nux Labs.
Das ist auch nochmal der Transparenz halber wichtig zu sagen.
Nux Labs ist eine Firma, die wurde von dem Ersteller von Nux, also Sebastian Chopin, gegründet.
Hat Venture Capital bekommen 2020 und da war die zu sagen, man baut Services um Nux rum, um das Ganze eben möglich zu machen.
Nux Labs Sponsored verschiedene Entwickler, mich für ein paar hunderte Euro im Monat, also ein kleinerer, dreistelliger Betrag und zum Beispiel aber...
Also wir hatten auch vor ein paar Editionen hatten wir auch Leute von Typo 3 da.

[57:01] Genau, also ich glaube, dass das so ein gutes Modell ist, auch für so Open-Source-Software, dass man eben eine Company hat, die mit bestimmten Services Geld verdient, die aber dann mit dem Geld eben auch die Entwicklung des Open-Source-Frameworks dann voranbringt.
Absolut. Also zum Beispiel Laravel macht das ja genauso. Taylor-Otwell, eine Laravel-ähnliche Idee.
Genau, wichtig ist da noch ein großer Unterschied. Zum Beispiel Daniel Rowe ist der Lead des Nuxt-Teams, des Framework-Teams.
Und der wird eben auch, hat er in einem Blogpost auch beschrieben, wie er selbst am Ende gefundet wird, zum größten Teil von Nuxt-Labs entsprechend bezahlt, dass er Vollzeit sozusagen für das Framework tätig ist.
Genauso Anthony arbeitet bei NuxLabs, Pouya selber arbeitet zum Teil bei NuxLabs, so einige Tage die Woche, und der Rest vom Team, die sind in anderen Firmen untergebracht, also auch da ich bin nicht bei NuxLabs in Arbeit oder ähnliches, ich habe zwar einige Consulting-Sachen, wo dann NuxLabs sagt, hier, hättest du Bock auf den Kunden, wir teilen dann die Ergebnisse und natürlich auch die Bezahlung, aber ansonsten, abgesehen von dem Sponsoring gerade erwähnt, bin ich da nicht mit involviert. Ich habe ja mein eigenes Business.

[58:14] Nö, passt ja auch alles. Und ich finde es ganz interessant, es gibt, wie gesagt, Lucy zum Beispiel aus dem Team ist bei Prismic untergebracht, bei den CMS.
Harlan, der für die ganzen SEO-Sachen zum Beispiel verantwortlich ist, der ist auch in Richtung Freelance und Consulting unterwegs.
Und da hat jeder so ein bisschen, ich sag mal, seine Richtung gefunden.
Und ich muss nur sagen, ich finde diese, ich sag mal, diese Teilung ganz nett, sozusagen auf der einen Seite.
Ich habe Zeit, die ich mir selber schaffe für Open Source.
Weil zum einen erwarten das natürlich Leute, die sagen, okay, ich frage dich an, du musst ja Ahnung haben.
Auf der anderen Seite sehe ich aber wiederum auch, was gibt es denn für Probleme in Projekten und kann dann wiederum dagegen steuern und sagen, okay, wenn das drei Kunden haben oder drei Projekte, dann haben das bestimmt 300 oder mehr genauso.
Die kenne ich halt dann nicht alle, aber dann kann ich vielleicht sagen, Doku updaten, eine Warnung im Dev-Modus oder ein Video.
Ja, du hältst quasi den Kontakt zur Benutzerbasis letztlich und lebst nicht im Elfenbeinturm.
Genau, das ist die Idee. Also ich versuche wirklich sehr stark, zum einen, ich triage eigentlich fast, ich sage mal, ich triage sehr viele Issues, bedeutet also, ein neues Issue wird erstellt, ein nächstes Impository, ich gucke mir den an, schaue, kann man das reproduzieren, macht das Sinn, ist das vielleicht ein Verständnisproblem.

[59:30] Kommentiere dann, weise dann die richtigen Prioritäten und Themen zu, ist das ein Bug, ist das ein Feature-Request oder oder?
Und genauso beantworte ich eben viele Sachen bei GitHub-Discussions oder im Nux-Discord, um eben genau da so ein bisschen, die Community oder das Ohr in der Community zu haben und auch zu verstehen, was sind so Probleme, was sind Fragen, die vielleicht zehnmal auftauchen, eben zu sagen, wie kann man dagegen wirken? So ist es.

[59:56] Genau, ich habe vorbereitend so einen kleinen Blick auf auf das NUX-Projekt geworfen, um noch mal so zu schauen, was Stand der Dinge ist.
Also ich hab gesehen, ihr seid jetzt bei Version 3.8, glaube ich, oder so was. 3.10.1 mittlerweile, genau. 3.10.1 oder so.
Und ich hab in eure Roadmap reingeschaut.
Und da sind auf jeden Fall ein paar Sachen, die ihr da aufgelistet habt.
Und ich hab auch gesehen, dass ihr so ein, sagen wir mal, so ein, ja, vielleicht, so einen schnellen Release-Cycle jetzt macht.
Das heißt, ihr sagt, wir hauen eine Major-Version oder wir peilen an, eine Major-Version einmal im Jahr rauszubringen, einmal im Monat eine Minor-Version.

[1:00:45] Und entsprechend oft eben dann die Bug-Fix-Versions oder ...
Genau, die Patch-Releases. Patch-Releases, genau.
Richtig, also das war eine große Umstellung, Vor allem nachdem Naxx 3 so weit stabil war, dass man sagt, okay, es wird jetzt keine riesigen Änderungen geben wie Naxx 2 zu Naxx 3.
Und jeder, der Naxx 4 hört und schon ein bisschen PTSD bekommt mit Oh mein Gott, oh nein, nicht schon wieder alles über den Haufen werfen.
Heißt ja, also theoretisch, es räumt euch ja die Möglichkeit ein, Breaking Changes zu machen.
Das ist dann, wo die Leute Angst vorhaben.
Ich meine, das Problem ist natürlich, je nachdem, wie viele Breaking Changes es gibt und wie sehr man da, ich sag mal, auch unterstützen kann, Ist es halt das eine oder das andere.
Und genau, ich habe ja gerade schon gesagt, NUX 3, Januar 23, wenn man jetzt sagt, jährliche Major-Version, dann tickt die Uhr theoretisch.
Wir planen NUX 4 für Q1 spätestens, früh ist Q2 so in der Richtung an.
Das ist der Plan aktuell.
Und NUX 4 wird sich sehr auf kleinere Breaking Changes beschränken, wo wir sagen, okay, wir haben zum Beispiel festgestellt, es gibt bessere Defaults oder wir haben festgestellt, Es gibt Sachen, die funktionieren nicht so exakt, wie sie sollten.

[1:02:00] Wir haben da schon eine Möglichkeit, das besser zu machen. Jetzt wollen wir es aber fixen, sodass nicht nur die Leute, die Doku lesen, das verstehen und sehen, ah ja, das geht so besser, sondern wir wollen es gerne für alle fixen.
Und da gibt es auch schon 4.x-Issues. Es gibt viele Sachen, die werden so Sachen sein, wie es gibt Deprecated-Code, der einfach dann rausgeworfen wird, weil der halt schon seit Max 3 dann deprecated ist, mal gedacht war zum Migration-Supporten und Co.
Es wird andere Sachen geben, wo man sagt, okay, man möchte bessere Defaults haben und auch wieder andere Sachen, wo vielleicht Werte entfernt werden und da möchten wir eben auch schauen, zum einen es soll halt, ich sag mal, verhältnismäßig sein, sonst kann man sagen, man wartet noch eine Major-Version und deprecated das erstmal, das ist sowieso wichtig, also wir wollen dann eben niemanden verärgern oder auch da nochmal die Arbeit härter machen, genauso gucken wir eben, was was geht mit Codemods?
Also haben wir eine Möglichkeit dann zu sagen, okay, in dem Code, das ist das Problem, du kannst es jetzt direkt fixen, du kriegst einen Kommentar dazu, siehst, was geändert wird, es funktioniert wie zuvor.

[1:03:04] Aber vielleicht willst du nicht, dass es wie zuvor funktioniert, sondern vielleicht willst du eigentlich das so haben, wie wir es intenten, deswegen da die Info dazu.
Und das werden so Punkte sein, dass man idealerweise die Migration als unproblematisch erachtet, also wirklich nur, ich gehe in Changelog durch, es gibt Codemods und es läuft relativ smooth.
Genau, Codemods ist, also Codemods sind das dann sozusagen Polyfills, die sich zwischen den alten Code und den neuen Code hängen, oder ist es tatsächlich, dass ihr dann, dass die dann den Code umschreiben?
Genau, letzteres. Also, dass man dann sagt, okay, es gibt zum Beispiel das Pending-Attribut nicht mehr, sondern es gibt ein Status-Attribut, und überall, wo Pending steht, können wir sagen, okay, Pending wird halt gealiased zu, ist der Status der oder der.
Heißt, die Funktionalität ist halt wie zuvor, es wird wird halt sozusagen inline gepolied oder ponyfilled.
Und dann eben darüber noch ein Kommentar mit, hey, guck dir das bitte an.
Wir haben das Attribut entfernt, weil das nicht so funktioniert hat, wie du es vielleicht gedacht hast.
Deswegen hier die Informationen. Du kannst das reviewen, wenn das so sein soll, ist alles gut.
Und that's it. Ja, das ist natürlich super. Also, weil selbst wenn ihr deprecated und so, man kennt ja seine Pappenheimer, die schalten einfach die Deprecation Warnings aus und dann noch ein Jahr später, dann hängen sie da.
Ja, sowieso. Also Warnungen in der Konsole, ich bin immer fasziniert, wie oft die einfach ignoriert werden. Auch Fehler. Ja, okay, da ist halt was.
Und es geht nicht, aber okay. Es gibt halt Warnungen.

[1:04:33] Ja, also Warnungen ...
Genau, manchmal hat man da relativ viel Neues, also ich kenne das auch, aber wenn Fehler sind, dann ich kenne das noch so aus früheren PHP-Zeiten so, einfach Error-Reporting off und dann hast du die nicht mehr, ist alles cool wieder mit deinem Cooler, läuft ja auch.

[1:04:52] Aber so sind wir halt alle. Ein anderer wichtiger Punkt ist, sind die Future Flags, das haben wir uns zum Beispiel bei Frameworks wie Tailwind zum Beispiel ein bisschen inspirieren lassen, zu sagen, okay, Wenn wir wissen, es gibt Changes, da wissen wir jetzt genau schon, das kommt in Nuxt 4, wir implementieren das Ganze, wir verstecken das hinter einer Flag, hinter einer Future Flag und sagen, hey, wenn du dich schon mal darauf vorbereiten möchtest, enable es doch mal, guck mal, was kaputt geht, hier ist was passiert und auch da wieder, die Migration wird da vielleicht weniger problematisch, weil das eben das gewünschte Verhalten ist und das sind meistens so Kleinigkeiten wie, keine Ahnung, es gibt Plugins in Nuxt und da kann man sagen, okay, die werden in Version 4.0, wird nur noch dieser Plugins-Ordner Top-Level, also die erste Ebene gescannt und nicht mehr komplett verschachtelt.
Einfach weil das halt bei allen anderen Ordnern so gemacht wird, was das Scannen angeht, zum Beispiel bei Composables und das wollen wir einfach in Line bringen.
Und gibt gleichzeitig die Möglichkeit zu sagen, gut, ich kann halt meine Implementation von vielleicht den Plugin-Helpers oder was auch immer näher an diesem Plugin bringen und es wird eben nur dieser Top-Level gescannt.
Das kann man dann enablen und meistens in 80 plus Prozent der Fälle macht das keinen Unterschied.
Und wenn es einen Unterschied macht, dann kann man sagen, gut, okay, entweder passe ich meinen Code an oder schau mal, wie ich das mache.

[1:06:09] Ich wollte jetzt noch mal so einen ganz anderen Punkt einbringen.
Denn ich habe im Bereich von Naxx schon öfter mal das Wort, ich stolper hier drüber, weil ich nicht weiß, wie ich es aussprechen soll, Nitro oder Nitro? Ich glaube Nitro.
Na man, das wird mit I geschrieben. Gut, Nitro, schon was gelernt.
Gehört. Ich habe keine Ahnung, was es ist, aber ich habe irgendwie dieses Wort immer wieder im Hinterkopf. Was Schnelles.
Was sehr Schnelles, so ist es, ja. Was ist schnell? Was ist das denn?
Muss ich das eigentlich kennen?
Ich weiß es nicht, es klingt aber auf jeden Fall schön.
Ich sag mal so, ihr kennt ja bestimmt Express.

[1:06:49] Ja, von da an. Das JavaScript-Server- Framework, was auch immer.
Jetzt stellt man sich mal Express vor, in modern und schnell und du kannst es auch deployen in Cloudflare Worker oder eben in Dano oder wie auch immer.
Und man hat so einen kleinen Composable-Ansatz, im Sinne von, dass ich eben auch da wieder alles schön miteinander verbinden kann und da kommt Nitroball raus.
Jetzt fragt man sich, okay, wir haben wieder ein neues HTTP-Framework, yay, muss das denn sein?
Gibt, wie gesagt, valide Gründe, eben zum einen den Punkt, dass es halt gedacht ist, universal zu laufen, also nicht zu sagen, ja, Node, aber kein File-System, ja, schade, tschüss, geht nicht.
Und der andere Punkt ist halt, das ist die Server-Engine von Nux3.
War früher mal, übrigens wissen die wenigsten, war der Code-Nummer mal Sigma, wurde geändert aus Gründen, aber, so kenne ich es noch, damals habe ich da angefangen, an dem Code mitzuschrauben, und die Idee ist, dass Nitro, wie ganz viele Teile von Nux.js, eigentlich ein Extrapaket ist, was aber eben diese Funktionalität ermöglicht, vor allem das Thema Deployment zu, verschiedensten Plattformen, ist nicht nur irgendwie Versal und Netlify, wie gesagt, auch Cloudflare Worker und Co.
Und das alles seamless macht, entweder mit Zero Configuration oder hier und da mit ein bisschen mehr Aufwand, aber es geht.
Und da ist die Idee dahinter, ja, in Nux2 hat man sehr viel im Core gehabt, aber es müsste eigentlich gar nicht da drin sein, weil an sich kann das auch in jedem anderen Metaframework nützlich werden.

[1:08:15] Und da war eben dann die Idee zu sagen, gut, okay, wir haben eine Organisation, die nennt sich UnJS, und da gibt es ganz viele Pakete, die zwar zum Teil in Nux.js genutzt werden, aber eben auch für andere Projekte oder auch Standalone, wie zum Beispiel Nitro, auch Standalone genutzt werden können. Und so hat sich das Ganze entwickelt.
Mittlerweile ist es tatsächlich so, Nitro, das wie gesagt auch genutzt werden kann, um ein eigenes Metaframework zu bauen, wenn man möchte.

[1:08:41] Von Analog.js hatten wir kurz in der Vorbesprechung schon erwähnt, das Metaframework, das neue im Angular-Kosmos mitgenutzt wird.
Und genauso von Solid Start, dem Metaframework von Solid.js genutzt wird.
Da immer in Kombination mit Vite, das ist so die, auch die Go-To-Kombo, außer man heißt Next.js, aber...
U2U-Versal, das ist okay. Und das ist so ein bisschen der Hintergrund dazu.
Also Nitro gedacht als moderne Option, auch da wieder Nitro basiert auf einem Router-Paket, das nennt sich RedX3, also RedX3, weil gut und wegen RedX3, ja, wie auch immer.
Und dann gibt es noch H3, also H3 für HTTP.
Das ist auch nochmal, man kann es vergleichen mit Express und Connect.
So Connect ist eigentlich dieser ganz low-level Barebone-HTPServer, sowas wie was H3 ist und dann hat man eben Express, was halt auf Connect aufsetzt und ein bisschen User Experience und Co. bringt.
Bei Nitro und H3 effektiv das Gleiche.
Und so sind auch in dieser UnJS-Organisation ganz viele andere Pakete, die eben genutzt werden können, in Nux.js, aber auch in anderen Szenarien Einsatz finden und.

[1:09:50] Die wir aber aus dem Core extrahiert haben, aus dem einfachen Grund, dass sie halt isoliert sind, einfacher zu testen sind, funktionieren, dass man sie unabhängig davon auch bumpen kann, also auch die Versionen erhöhen können.
Und im Idealfall, dass sie eben auch von anderen Projekten und Frameworks genutzt werden können.
Zum einen, die natürlich damit weiter verbessert wird, weil mehrere Augen, mehrere Contributor und auch eine Bereicherung für die gesamte Community sind.

[1:10:16] Das heißt, es ist auch nicht nur für Vue oder Nuxt, sondern es ist ähnlich wie bei Vite ich habe vielleicht ein komplett anderes Framework aber ich hätte jetzt auch super gerne diesen einen kleinen Helferlein den kann ich mir dann auch bei meinem vielleicht Vite und React Framework Projekt Oder sogar, ich habe mit einer JavaScript, ich will aber einen, einfachen, kleinen Wrapper um die Fetch-API haben, da gibt es sowas wie ki oder got oder sowas und wir haben halt ofetch, was auch eben NUX genutzt wird und autoimplantiert wird und, genau ähnliche Idee, da kann man sagen, okay, was macht das jetzt anders zu den anderen Paketen, das kann man im Detail dann jeweils schauen, es gibt aber, also wir sagen jetzt nicht nur, okay, wurde nicht hier gebaut, wir müssen es nachbauen, sondern es hat immer den Hintergrund, dass es halt was Neues bringt, sei es, okay, okay, ist halt in ESM und TypeScript geschrieben, wie zum Beispiel in Proxy für eben auch Nitro, zu sagen, gut, okay, der funktioniert halt auch überall oder was jetzt demnächst rauskommt, ist zwar schon Public, aber in Nitro auch integriert wird, Web-Socket-Support, dass man sagt, okay, Web-Sockets, die aber auch funktionieren, in Dano, in Cloudflare Worker und Co., was gar nicht so einfach ist, weil Node, ja, klar, können Dingen, der Rest ist halt der schwierige Teil.
Ich finde es aber auch ganz spannend für die Arbeitsstruktur der Open-Source-Devs.

[1:11:43] Es ist, also einerseits finde ich es wunderschön, weil man dann wirklich, ich bin jetzt hier auf Andres gegangen und du hast halt pro von dieser Mini-Lib, Mini-Bibliothek, so eine eigene Kachel, eine eigene Karte.
Dann hast du das wirklich schön aufgelistet.
Aber ähm, Also ich kenne das ja auch selber, wenn man jetzt einfach eine ganze Seite implementieren soll, fällt es teilweise einfach immer schwer, so einmal umzudenken und so, okay, was sind meine kleinen Teile, was kann ich auch wirklich unabhängig voneinander bauen, mach das dann für UnJS, test es aber wahrscheinlich dann erstmal im NuxJS-Framework und muss dann wieder schauen, habe ich da auch wirklich nix Nux-spezifisches so drin?
Aber ansonsten, du hast jetzt Nitro erwähnt. Genau, richtig.
Was ist da denn noch Cooles drin?
Genau, Nitro und H3, also H3, habe ich erwähnt. Übrigens, Nitro, ein geiles Logo. Ja.
Das schaut übrigens auch aus wie deine Rückwand. Das ist Zufall.

[1:12:46] Ja, also die Farben sind total zufällig. Ich weiß nicht, ich glaube, das Nitro-Logo war vor der Rückwand da, leider, aber ja, so ist es.
Ja, weitere interessante, wie gesagt, O-Fetch hatte ich noch mit erwähnt, so als Fetch-API-Wrapper.
Dann, ich denke, was noch wichtig zu erwähnen ist, ist das ganze Unplugin-System das kriegt man auch gar nicht so mit, aber als Library-Autor oder Modul-Autor, das ist sehr spannend wir haben ja, alle möglichen Bundler und Dev-Server, wie Troller, Webpack, ES-Build IS-Pack, whatever, und die Idee ist, wenn ich jetzt eine Funktionalität habe, und die würde ich ganz gerne, eigentlich egal, welchen Bundler jetzt man nutzt oder welchen Dev-Server, was auch immer, welches Build-Tool, das soll schon so zu existieren, dann fange ich jetzt an, ich schreibe ein Rollerplugin, ich schreibe ein Webplugin, ja, will man nicht.
Und Unplugin, auch da, un.js, un.
Hat den Präfix, bietet eine gemeinsame API an, um zu sagen, okay, hey, du schreibst es einmal, wir übersetzen das für dich und alles funktioniert.
Achso, ein bisschen die Idee dahinter. Es gibt dann natürlich auch Limitationen, zum Beispiel, wenn der eine Bundler was hat, was die anderen Bundler nicht haben, dann kann man das halt hier und da nicht nutzen, die sind aber alle relativ gut erklärt.
Die meisten Sachen sind aber kompatibel und das macht halt auch so ein bisschen den Charme aus, dass du wirklich sagst, okay, ich spare mir halt Arbeit, muss auch nicht die kompletten Details zwingen können.

[1:14:09] Ich sehe hier noch auch ganz viele Sternchen bei einem Unicorn-Logo, Magic Rack Exp Ja, Magic Wraggers ist eine, ich kann fast sagen, Donation von Daniel auch.
Also wir werden Lead des Next Frameworks, unter anderem, ist ja noch viel mehr als das.
Ist auch eine sehr, sehr coole Library. Ja, wer kennt's nicht, wir schreiben Regular Expressions und wir haben dann... Also wir nicht, ChatGPT schreibt.
Okay, sorry. Wir kopieren das Ganze von ChatGPT und haben dann was, was wir nicht verstehen, aber es soll funktionieren.
Von der Idee her. Und jetzt könnte man ja sagen, naja, was ist denn, wenn wir das Ganze mal mit Worten beschreiben?
Also wenn wir jetzt sagen würden, beispielsweise, matche bitte genau Vanessa oder Shep.
So, dann beschreibe ich das entsprechend so, hab da also Funktionen, die genauso benannt sind.
Und am Ende purzelt da ein Regex raus. Natürlich auch mit irgendwie Maybe und Gruppen und so weiter und so weiter.
Und das Schöne ist, das Ganze können wir auch noch tatsächlich zu Bild-Time transformieren.
Das heißt, wir haben nicht mal den Overhead zu sagen, jetzt rufe ich da diese ganze Funktion auf und dann wird das alles langsam, weil soll ja schnell sein.
Nein, wir können einfach sagen, gut, okay, zur Laufzeit ist das Ganze schon vorkompiliert.
Also zur Bildzeit wird es kompiliert und es klappt.

[1:15:29] Und das macht halt Regex ein bisschen, ich sag mal, besser lesbar für den durchschnittlichen Menschen.
Also auch für mich definitiv. Und das ist eine ganz schöne Library dafür.
Und das ist auch was, was ihr in dem Nuxt-Core, also jetzt nicht für Nuxt-User, sondern was ihr auch wirklich im Nuxt-Core auch gebraucht habt, dass ihr Bei Magic Crackers weiß ich gar nicht, ich weiß halt, dass Daniel das ursprünglich genutzt hat, ich kann dir gar nicht sagen, ob das aktuell in einem Teil von Andrzej erst weiter genutzt wird.
Ich guck mal ganz kurz in die Dependencies, äh, sorry, in die Dependents rein.

[1:16:01] Das weiß ich nicht auswendig. Es kann auch sein, dass es nicht der Fall ist, weil das ist auch so ein Szenario mit, okay, das kann man ja einfach so mal in ein Projekt reinwerfen.
Genauso wie eben auch so so was wie Dollar Fetch und Co., also O-Fetch, das kann man benutzen.
Okay, also dann auch wie du sagtest, es können fast auch so Donations sein von Leuten, die aber das UnJS auch schon kennen und sagen, okay, das brauche ich jetzt da gar nicht unbedingt, um NUX zu entwickeln, aber ich finde es auch cool und wir haben hier noch so ein kleines Helfer-Tool.
Genau, genau so ist es. Ich sehe gerade, also in verschiedenen NUX-Modulen, wie im Tailwinds-HSS-Modul wird es genutzt, in NUX-SEO, also nicht direkt im Core, aber in Modulen auf jeden Fall.
Auch da die Idee, also es gibt kein hartes Kriterium zu sagen, das kann jetzt ein Ange erst.
Die Idee ist, am Ende Puja, auch ein Core-Contributor und Maintainer von Nux, der ist da Lead der Organisation, kümmert sich auch aktuell sehr, sehr viel darum und maintaint auch viele dieser Pakete.
Daniel und eins von ihm ungefähr die andere Hälfte und dann bleibt nicht mehr so viel.
Da auch noch ein Shoutout, das war es ja noch gar nicht.
Wir haben so eine Community-Nodes, wo wir sagen, okay, Harlan, derjenige, der für Naxx SEO verantwortlich ist, macht da auch noch viel mit Unhead und dann gibt es noch Johann, Johann Schopplich, der aktuell in Leipzig wohnt, meine Heimatstadt, liebe Grüße gehen raus.

[1:17:17] Der maintaint auch ein paar Sachen dort und da ist die Idee okay, wer möchte, der pitcht eine Idee an Pouya, sagt, hey, okay, deswegen ist es nützlich, deswegen zum Beispiel ist es überall lauffähig es ist besser als die aktuellen Optionen, weil wie gesagt, es geht nicht darum wir müssen es bei uns bauen, sondern was gibt es für einen Mehrwert, Und damit spricht man das Ganze. Also theoretisch gesehen, wenn wir jetzt eine coole Idee hätten, die dann auch in dieses Schema passt, von wegen ich kann es dann entweder als Nux-End-User oder als Nux-Core-Team-Arbeiter auch nutzen oder nicht auf Nux und Vue spezialisiert, sondern generell irgendwas Hilfreicheres, könnte ich das jetzt auch vorschlagen?
Absolut, genau. Dann geht die Nachricht raus am Puja und dann würde er sagen, ja, ist cool oder ja, ist nicht cool. oder gib mir noch ein paar mehr Details dazu und genau, dann läuft das.

[1:18:08] So ist es. Auch da ist die Idee, dass diese Organisation wirklich mehr dient als eine Art Kollektiv, weil also, nur weil zum Beispiel Puja da jetzt der Lead-Maintainer ist, bedeutet nicht, dass der dann sagt, was in deinem Paket passieren soll.
Also du bist immer noch verantwortlich für dein Paket.
Genauso wie zum Beispiel jetzt bei Magic Regex ist Daniel zum Beispiel weiterhin verantwortlich oder Anthony für Unplugin.
Natürlich Natürlich gibt es Pull-Requests und Reviews und Co., logisch, aber der jeweilige Maintainer entscheidet halt, was dann am Ende rein soll und was nicht.
Das ist mehr wirklich als ein Kollektiv und natürlich auch eine Sammlung von eben sehr hilfreichen Paketen gedacht.

[1:18:48] Vielleicht ein weiteres noch zu nennen, was auch ganz cool ist, ist UFO.
Da geht es darum, man kennt das klassische Szenario, ich habe einen Pfad von einer URL und ich habe eine Basis-URL und ich will dieses Beispiel verbinden.
Jetzt weiß ich nicht, hat der jetzt einen Trading Slash oder startet der mit einem Slash oder wie ist das?
Und so gibt es natürlich ganz viele Szenarien, wie gib mir mal diese URL ohne den Query-Parameter.
Füge mal hier einen Slash an, ja, nein. Also ganz viel URL-Manipulation.
Und da ist eben auch das Paket da ganz nützlich, um zu sagen, gut, okay, wenn ich da eine Funktion draus brauche, wie zum Beispiel bitte passmanuell oder join mir mal zwei oder mehrere URLs, dann ziehe ich mir diese kleine Funktion, ist alles natürlich tree-shakable, hat Herr-Support und da kann ich das entsprechend nutzen.
Und das ist natürlich auch was, was im Projekt sehr nützlich ist, also nutze ich eigentlich auch in fast jedem größeren Projekt von mir, einfach weil man es natürlich kennt, zu sagen, okay, ich muss da jetzt mal zwei URLs zusammenpacken, die Basis wäre etwas anderes, und ja, das passt also auch super zum End-User sozusagen, zum End-Entwickler.
Das Paketchen, was ich hier gerade noch gesehen habe, ist das Fontain.
Ich glaube auch wieder, Daniel, ich habe es ein paar Mal gesehen, automatische Font-Fallbacks, basierend auf Font-Metrics. Das war jetzt ein halb Denglisch.
Font-Metriken, gibt es Font auf Deutsch? Ich glaube, Font ist auch Deutsch.
Schriftart? Weiß ich nicht.

[1:20:10] Schrifttyp? Ja, bleiben wir Font. Was sagt der Chef dazu?
Können wir Font übersetzen? Ich weiß es nicht. Es gibt ja einen Unterschied zwischen Type und Font. Ja.
Also, da kann man sich ganz böse in die Nässe setzen.
Ich glaube, deswegen gibt es wahrscheinlich dafür, doch, wahrscheinlich gibt es dafür auch ein deutsches Wort, aber das kennen wir einfach nicht.
Okay, das war eine sehr diplomatische Antwort, so ab jetzt zugegeben. Könnte sein.

[1:20:33] Was mir jetzt gerade auffällt, ich finde diese Dokumentation hier jetzt zum Beispiel einfach super, weil diese mehreren Beispiele kommen und noch mal genauer reingegangen wird, how it works. Ich habe mir jetzt natürlich nicht diese Seite durchgelesen.
Also im Endeffekt weiß ich jetzt nicht, was da steht, aber ich sehe diese Headlines und wenn da jetzt nicht danach Jibberish kommt, dann gibt es da einige Infos und ich mag das eigentlich so.
Ich denke, was ich nebenbei jetzt gerade auch schon offen hatte, war bei Nux die Experimental Features zum Beispiel und so ein anderer Bereich auch noch, wo ich so Sachen ein- und ausschalten kann. Opt-in war das, glaube ich.

[1:21:14] Und ich war jetzt die Person, ich habe mir das überflogen und ich kann das Beispiel nicht mehr nennen, weil ich habe ja eigentlich vorsätzlich dir zugehört, deswegen kann ich das Beispiel nicht mehr nennen.
Und das Ding war, ich sehe, es gibt jetzt eine Funktionalität, dass ich damit irgendwas machen kann, aber ich habe keine Ahnung, warum sollte ich das machen wollen?
Und da denke ich dabei, ah, wahrscheinlich gab es da 10% von NUXT-Usern brauchen dieses eine bestimmte Feature und für die ist es da.
Und wenn die danach suchen, die sagen, yeah, genau das ist, was ich brauche, das machst du vielleicht auch für Neuanfänger im NUXT-Bereich, also jetzt nicht für ganz Junior-JavaScript oder Views, sondern das ist auch das, was ich ein bisschen diese Hürde finde, dann gibt es da auf einmal Features für irgendwas und ich lerne vielleicht schon, wie die Syntax dafür ist, aber ich weiß gar nicht, ob ich das brauche, wozu ich das brauche und ob ich es vielleicht nicht auch falsch verstehe, weil ich habe bestimmt schon, keine Ahnung was, aber ich habe bestimmt schon öfter mal irgendwie den Feature eingesetzt, dass ich dachte, das soll so sein und dann habe ich mir mal einen Talk auf einer Konferenz angesehen, wo ich mir dachte, ich setze das vollkommen falsch ein, upsie.

[1:22:18] Tatsächlich, das ist was, was ich relativ oft höre und wir versuchen eigentlich auch zum Beispiel bei den experimentellen Features eigentlich immer zu zeigen, okay, so schaltest du es an und was löst das Problem?
Manchmal ist da ein Link zu einer Erklärung in einem GitHub-Pro-Request, gerade bei den Experimental-Sachen.
Manchmal ist es auch ein bisschen kryptischer, sowas wie, es gibt das Async-Entry-Feature und da sagt man einfach nur, okay, das ermöglicht die Generation für so einen asynchronen Einstiegspunkt für das View-Bundle und das sagt einfach nur, okay, es hilft für den Module-Federation.
Wenn du also, keine Ahnung, von Metal Federation hast, muss ich sagen, ich habe keine Ahnung von Metal Federation, wahrscheinlich uninteressant.
Aber wenn man sagt, okay, ich möchte damit experimentieren, macht das Sinn.
In den meisten Fällen ist aber so, dieses, ja, keine Ahnung, ein kleiner Prozent der Nux-Leute brauchen Feature.

[1:23:05] Meistens versuchen wir das dann so zu lösen, dass man sagt, okay, bau doch ein Modul, was das macht. Oder nutz die Hooks und Co.
Also, alles, was das Framework selber dir schon bereitstellt, du musst es dann halt selber bauen, also ich baue mal ein Vee Plugin oder so ein Unplugin, was das macht, reicht halt aus, geht.
Wir müssen wieder nicht ermöglichen, weil du kannst es schon selber bauen und es nutzen.
Das versuchen wir so zu regeln, weil wir eben dann nicht wollen, wir haben jetzt diese 100 Features und das braucht eigentlich alles keiner, weil es ist ja wieder Maintenance-Aufwand.
Das ist das große Problem mit, so ein Pull-Request ist schnell gemerged und dann kann man es wieder ändern, naja, zur nächsten Major-Version.
Und das ist immer ein großer Punkt. Was einmal drin ist, kriegt man auch nicht mehr raus so leicht. Sehr schwierig, richtig.
Ja, nee, das ist schon gut so. Und deswegen auch da die Flexibilität einfach zu sagen, ganz oft in Issues ist das, hey, cooles Feature, so was wie eben halt vorgeschlagen, Maintenance-Mode.
Zu sagen, okay, ich kann irgendwie einstellen, die Seite ist in Maintenance, wird jetzt nicht mehr angezeigt, sondern so ein kurzer Screen.
Super Feature, macht Sinn, Baumodul, let's go. Aber nichts für ein Core, weil das brauchen halt die meisten Leute nicht und wir doch selber bauen.

[1:24:11] Ja, die können auch mal was machen. So ist es.
Und wie seid ihr dann als Modul open sourcen und dann hat man das Problem wieder nicht, weil wenn man es selber braucht, gibt es bestimmt andere Leute, die das auch brauchen und das ist dann schnell getan.
Also vom Selberimplementieren zu einem Modul ist es nicht so weit weg.
Plus, auch da, wir haben eine sehr nette Community am DAX-Discord, sind viele Leute, wie gesagt, unter anderem auch nicht selbst, aktiv, beantworten Fragen, helfen, also wenn man sagt, hey, ich will ein Modul bauen, dann müssen die Letzten uns sagen, ja, viel Spaß, tschüss, sondern eher mit haben, was willst du machen, erklär mal, wo kommst du nicht weiter.

[1:24:42] Deswegen mag man die Vue-Community. So ist es.
Und eben auch, das kam vorhin auch schon ganz gut nochmal raus, wo es um UnJS ging.
Irgendwie habe ich das Gefühl, die Vue-Community, der liegt halt, der Rest der Javascript-Community auch sehr am Herzen, zu sagen, okay, ja, Vite als Beiprodukt so ein bisschen, als Nebenprodukt mit, naja, ist doch cool für Vue.
Und dann, ja, jetzt ist es halt ein eigenes Team.
Es wird von fast allen Major Frameworks, wie gesagt, sagt, Next.js in Versailles, you do you, unterstützt. Auch Angular mittlerweile, wo du sagst, okay, das sind halt wirklich auch Größen, alle sind aktuell auf Vite ausgelegt.
Vola, der nächste Punkt, das sind Language-Tools, ursprünglich als Vue-Language-Tools gestartet, jetzt halt generalisiert zu sagen, gut, okay, das klappt auch für Astro, für andere Projekte für Svelte und Co. Warum nicht?
Und ich denke, NGS reiht sich da ganz schön ein.
Jetzt habe ich gelernt, dass es nicht Vola ausgesprochen wird.
Komisch, das ist doch sonst alles französisch. Ja, das stimmt.
Ich kann ja kein Französisch, das Volar ist ja deutsch.
Aber magst du es nochmal aussprechen? Also ich hab das jetzt wie ein Deutscher ausgesprochen. Es gibt ja Volar, also da fehlt ja das I dann wahrscheinlich noch, aber Hickforum ist.

[1:25:57] Volar mit R hinten tatsächlich dran. Ah, okay. Ich weiß aber auch nicht, wo der Ursprung, der Wortsprung herkommt, aber ich sag einfach nur Volar.
Das klingt ja viel cooler.
Das klingt so ein bisschen nach Fliegen, weil im Französischen ist das Volare.
Es scheint Spanisch zu sein.

[1:26:17] Laut Victionary. Pinia ist ja auch nicht Französisch. Das stimmt, richtig.
Aber es ist wieder lustig, weil Eduardo lebt ja in Paris, kommt aber aus Spanien.
Vielleicht kommt alles Spanisch noch rein.
Ich wollte nur sagen, wir hatten vor einem Jahr den, ungefähr einem Jahr den Joe, Ray Gregory da und hatten so ein bisschen das wollten wir eigentlich auch dieses Jahr, also das wollten wir eigentlich wiederholen, so einen Blick in die Glaskugel, so was in 2023, dann so in der Frontend-Entwicklungswelt so angesagt sein wird und der hatte auch schon damals damals auf UNJS hingewiesen als Sammlung von Mikro-Bausteinen, mit denen man irgendwie Probleme lösen kann.
Mir war nur überhaupt nicht klar, dass das eben alles sozusagen aus dem, ja so quasi aus der View-Welt gekommen ist.
Also wieder was dazu. Ja, was vielleicht auch sonst einen falschen Eindruck, denke ich, vermittelt.
Das sind halt immer dann die Personen, die aus dieser Welt kommen.
Aber deswegen habe ich ja auch schon nachgefragt, das hat nichts mit Vue zu tun. Genau richtig, das ist ganz wichtig.
Aber es ist auf jeden Fall cool, da noch mal so, okay, so ist das entstanden.
Ja, das ist gut für das nächste Mal bei Günther Jauch.

[1:27:46] Wir haben eigentlich sowas, Web2Media als Developer, als Frontend.
Freut mich mal. Das klingt nach einer Idee.
Oh, ich habe so viele Ideen in meinem Hinterkopf. Ich habe so viele, dass ich meinen nächsten Satz oder eine Frage vergessen hatte.
Deswegen stelle ich eine andere. Haben wir jetzt bei UnJS gerade ...
Stimmt. Woher kommt denn UnJS? Also das Un ...
Von Unified. Unified JavaScript Solutions, können wir sagen, oder von Unified JavaScript.
Und Unified im Sinne von Universal läuft halt everywhere.
Everywhere, wo JavaScript läuft. Ja.
Theoretisch sowas wie H3 oder ähnliches das könnte man sogar auch im Browser laufen lassen, im Service Worker zum Beispiel.
Auch da wieder die Idee zu sagen, okay, wenn du aus irgendeinem Grund das Ganze im Browser laufen lassen möchtest, um irgendwas zu simulieren, dann go for it. Mach das bitte.
Okay, das ist so der gemeinsame Nenner all dieser Pakete, die kannst du im Browser laufen lassen, auf Dino, auf Node, auf Serverless-Plattformen.
Genau, das ist die Idee dahinter, dass man eben sagt, okay, wir wollen halt einen Support bieten auf all diesen 14-plus Runtimes, die es aktuell gibt.

[1:28:58] Und falls das irgendwie nicht funktioniert, dann Error-Raisen und let's go.
Es gibt natürlich auch Szenarien, so wie UFO zum Beispiel, da sagst du, okay, das könntest du auf dem URL basieren, also einfach auf der URL-Klasse, da geht es eben weiter mit, was ist, wenn es das nicht gibt.
Plus eben auch seine Quirks, eben da auch zu sagen, gut, dann baut man das entsprechend sich ähnlich zusammen.
Ja.
Cool, cool. Hast du denn noch so Sachen in der Pipeline, die jetzt dann bald bei NJS anstehen oder bei NUX, die du noch mal hervorheben möchtest, was du jetzt vielleicht noch nicht genannt hast, außer wir hatten alle schon durch?
Ich überlege gerade. Also genau, was ich halt spoilern darf, habe ich auch schon grob erwähnt, das Thema WebSockets.
Das ist mal ein großes Thema, eben diese Cross-WebSocket-Implementation.
Weil das ist eben echt ein bisschen tricky gewesen. Da hat das Puja geschafft.
Aber kommt das nicht auch so ein bisschen aufs Backend drauf an?
Naja, dadurch, dass du Nitro ja als Server in dem Sinne hast.

[1:30:02] Nitro, also auch das ist vielleicht eine Besonderheit, die man mit Next-to-Nitro nochmal erwähnen darf. Das funktioniert auch mit anderen Metaframeworks, die auf Nitro basieren.
In Nitro, wenn man sagt, das ist so ein bisschen wie Express, nur moderner und universal einsetzbar, kann man da ja auch zum Beispiel mit Hypescript seine APN-Punkte definieren.
Da kann man dann andere APIs aufrufen, wenn man möchte. Da gibt's auch Caching, was natürlich auch sehr cool ist, sowas wie StyleValueValidate oder Incremental Static Generation und so weiter und so weiter, wenn man's möchte, oder einfach sagen, hey, ich cache das forever für eine Stunde oder ähnliches.
Cool ist aber auch, okay, Nitro kennt dann die Typen, was also am Ende als Ergebnis rauskommt bei dem API-Endpunkt, wenn du die definierst.
Und was halt diese Nuxt-Nitro-Integration betrifft, ist es so, dass man sagen kann, okay, Nuxt kennt dann also so deine APN-Punkte, die definierst du ja, und die typen.
Heißt also, wenn du jetzt mit sowas wie UseFetch oder DollarFetch in Nux sagst, ich frage einen APN-Punkt von Nitro an, dann ist der End-to-End-Type-Safe.
Weil, du weißt ja, was rauskommt. Oder eben, dann ist es halt null, sonst gibt es halt einen Fehler, ne, gibt es ja auch.
Aber, das ist möglich, dass du nochmal diese End-to-End-Type-Safety ohne irgendwie tRPC oder ähnliches und, ja, gibt es nochmal einen netten Schwung Developer Experience. Vielen Dank.

[1:31:21] Mhm. Und gibt es irgendwas, was so der, was, das ist jetzt nicht vorbereitet, also bitte nicht drüber stolpern, wenn du darauf nicht klar verantworten kannst, weil ich ja gerade vorher meinte, dann höre ich mir so Konferenztalks an und stelle fest, oh, ich habe dieses Feature vollkommen falsch eingestellt.
Gibt es so diese ein oder zwei Stolpersteine bei NUX, die du immer und immer und immer wieder siehst, die du jetzt mal kurz mit auf den Weg geben möchtest, die nicht so zu machen?
Ja, also theoretisch jedes Mal Videos, aber das ist zu kurz.
Die meisten sind einfach daraus entstanden, dass ich diese Frage zum x-ten Mal gehört habe oder einfach sage, okay, das ist ein Feature, das sollten mehr Leute nutzen.
Ich denke wirklich, das Thema Composables versus normale Datenfetching, da habe ich auch so ein Video, das heißt you are using useFetch wrong oder so und dann in Klammern I hope you don't, weil wäre ja eigentlich unschön, ich wünsche es ja niemandem, aber aber die meisten nutzen es halt falsch.
Ich denke, das ist ein großer Punkt. Also dieses Thema, wann nutze ich ein Composable und wann sollte ich es nicht nutzen? Ja.
Das ist aber auch nicht so einfach. Das ist auch wirklich nicht so einfach.
Und das war nochmal der Punkt von der Options-API, es war einfach.
Ja, das stimmt. Das vielleicht auch klingt ein bisschen falsch, aber es wurde einem so einfach wie möglich gemacht, komplexe Sachen dann damit zu machen.
Und Composables klingt super und diese Gruppen, wie du vorher genannt hast, und logischen Einheiten, das klingt auf dem Papier so klasse, aber manchmal steht man dann in seiner eigenen Komponente und sollen wir jetzt ein Pinier-Store machen, sollen wir eine Composable machen?

[1:32:49] Und wenn man es sich vielleicht mal in einer ruhigen Sekunde anschaut, ist es vielleicht dann doch wiederum nicht so kompliziert, aber die Realität ist dann halt oft, diese Sache gab es schon.
Ich meine, wie oft entwickeln wir so komplett neue Features?
Oft heißt neues Feature-Bauen auf bestehenden Features jetzt ein weiteres hinzuzufügen.
Dann gehst du da in diesen Code rein.
Ich sage jetzt nicht mal, dass er unbedingt schlecht ausschauen muss, Aber für dieses neue Feature, egal wie modular und gut du das baust, musst du das vielleicht ein bisschen anpassen und dann steht man manchmal, oder zumindest ich, ich kann nur für mich sprechen, stehst du manchmal da und checkst gerade einfach so wirklich die Sache nicht.
Soll ich das so oder so machen, weil irgendwie nicht gerade verwirrt?
Ja, klar. Also definitiv Composables.
So schön, wie sie sind, so viel man damit auch Code und Logik teilen kann, bügen sie auch ein bisschen mehr Komplexität hinzu.
Vor allem, das ist auch nochmal natürlich der Punkt, wenn man sie eben nach Gusto und Gudünken einsetzt und keine, ich sag mal, superklare Struktur hat.
Ich habe da, das bin ich der Erste, da gibt es einige Leute, die darüber berichtet haben, aber auch ein Konzept vorgestellt, das nennt sich Inline Composables.
Also die Idee ist, ich habe Logik, die gehört zusammen und dann kann ich sie erstmal im JavaScript-File oder im View, in einem Script-Setup zusammenpacken.
Jetzt kann ich aber sagen, naja, okay, in einem klassischen JavaScript- oder TypeScript-File oder irgendeiner Programmiersprache, was würde ich machen?
Ich baue eine Funktion daraus, die ich dann aufrufe.
Die Funktion benenne ich dann auch noch ganz nett und füge vielleicht noch ein bisschen Dokumentation hinzu Tu und alles gut.

[1:34:16] Ich habe aber das Gefühl, ich habe es oft gesehen, Leute machen das in Vue nicht, sondern sie sagen halt, okay, entweder ich mache da eine Funktion raus, nenn es halt Composable, weil du nutzt dann Vue API, füge das in ein ganz neues File hinzu, weil das wird immer so beigebracht, mit euch packst mal woanders hin.

[1:34:32] Weil die Datei ja dann auch kleiner bleibt wieder, weil die Single-File-Components sollen ja gar nicht so groß werden.
Und wenn du jetzt eine Art Funktions, so eine logische Einheit baust, dann ist es halt so, machst du da jetzt Kommentare hin, um zu sagen, das ist jetzt dieser Funktionsblock und dann hast du sowas, so ein Kommentar wie bla bla start, bla bla end oder du wraps das tatsächlich sogar eher eine richtige Funktion, dann kannst du das Code vielleicht noch ein- und austockeln, aber vielleicht returnst du, weil wir sind ja alle ganz große Destructuring-Fans hier, dann hast du da noch einen Return mit 20, okay, ist übertrieben, aber lass es nur 3 sein.
Schon hast du halt vielleicht 4 Zeilen nochmal mehr und plötzlich ist deine Component, die gar nicht so viel macht, schon 400 Zeilen oder gut, 300 Zeilen lang und dann ist sie vielleicht sogar schon klein.
Aber du denkst, irgendwie ist das jetzt zu viel, ich lager's doch lieber aus.
Und dann kann ich vielleicht das auch Composable vielleicht auch durchaus wieder leichter testen, wenn's in der eigenen Datei ist.
Dann geht die große Problematik los, teste ich das Composable oder teste ich die Component.

[1:35:37] Ich sag mal, das Thema Inline Composables, ich würde eben genau dieses aus der ja Komponente rausziehen, das würde ich sehr kritisch betrachten, weil wenn ich sage, ich habe ein Composable, das nutze ich nur da, warum soll ich rausziehen?
Also wenn ich jetzt was habe, was ich Notifications, das ist ein klassisches Beispiel, klar, das brauchst du an x Stellen, alles gut, macht Sinn.
Aber alles, was ich eigentlich nicht wiederverwende, sondern eigentlich nur gruppieren möchte, ja, mache ich eine Function Declaration, wird gehäustet, kann ich also ganz nach unten packen, das ist dann mein Inline Composable.
Das kann zum Beispiel auch sagen, okay, gab auch die Frage, ja, was machst du dann?
Ich habe jetzt einen Ref, also eine reaktive Referenz, und die brauche ich eigentlich in zwei Funktionsblöcken, die voneinander getrennt sind, dann haben wir gleich einen Input.
Antwort ist, ja, gibst du als Parameter rein. Alles gut.
Bringt einen auch zu, ein bisschen über Architektur nachzudenken.
Und also, das ist glaube ich was, was viele Leute, was es sich lohnt, anzuschauen.
Man hat ja gesagt, ja, gerade für alte Vue2-Hasen wie mich ist das super, gehe ich voll mit.
Habe ja auch sehr viel mit Vue2 gemacht, und bei mir hat es auch ein bisschen gedauert, diesen Schritt zu machen.
Zu sagen, okay, warum packe ich es immer neu in Dateien? Oder warum packe ich es nicht einfach in eine Funktion, in diese Komponente? Obwohl es halt bei einem klassischen JavaScript-File oder TypeScript-File so offensichtlich wäre.

[1:36:53] Ich denke, wir hatten ganz oft den Punkt, ist das ein Composable oder ist das eine Util-Function? Weil dann doch im Endeffekt oft nur eine Component-Property, also eine ...
Boah, Alex, kannst du mal kurz eine Composable-Property erklären?
Ja, also einfach theoretisch einen Wert, der basierend auf anderen Werten, auf anderen reaktiven Werten neu berechnet wird. Wunderschön.
Es wird spät für mich, Entschuldigung. Es wird für uns alle spät, keine Sorge. Ihr weißt das eigentlich gar nicht, glaubt's mir. mir.
Genau, aber was ich sagen wollte, oft purzelt bei vielen Composables, die wir schreiben wollten, so eine Computer-Property raus und dann war, aber ist das nicht eher eine Util und ich schreibe dann halt in meiner View-Komponente halt, wrap ich das wieder in den Computer rein und wäre davon irgendwas besser oder schlechter.
Da haben vor allem halt am Anfang noch so ein bisschen die Erfahrung gefehlt, aber man wollte es ja nicht falsch machen.

[1:37:45] Aber anscheinend gibt es ja ganz viele tolle Alex-Videos, die wir uns dazu anschauen können.
Ja, also zum Thema beim Computed ist auch so, am Ende niemand schreibt fest, zu sagen, was in dem Computed abläuft, gerade wenn es komplizierter ist, kannst du auch eine Funktion auslaken.
Ist halt kein Composable, sondern eine Funktion, eine Hilfsfunktion, aber voll in Ordnung. Ja.
Ich denke, was ich mir oft da anschaue, ist, dass du weißt gleich, was ich meine. View-Use.
Ja, View-Use ist auch super. Und ich meine nicht unbedingt, dass ich jetzt jede Funktion davon oder Composable importiere und nutzen möchte, aber einfach mal, um auch zu verstehen, wofür bauen denn diese Leute oder was gibt es da denn für Composables, um mal so ein bisschen Inspiration mehr reinzuholen.
Ich denke, ich habe tatsächlich auch Composables gebaut, wo einfach dann Business-Logic irgendwie drin war, um bestimmte Daten bei vier verschiedenen Komponenten immer und immer wieder gleich zu transformieren, wo dann auch wieder die Frage war, ist das Composable oder ist das eine Util-Funktion?
Aber so Composables, wenn ich so was sehe wie UseDebouncedRef oder UseDebounced anderes andere reaktive Werte.
Das ist ja komplett Business-Logik frei. Das ist einfach wirklich wiederverwendbares Composable, wo ich dann auch gar nicht so viel drüber nachdenken muss, ob man das jetzt in der Property hat oder nicht. Ja.
Also cooles Hilfswerk. Absolut. Bei View-Use reinschauen, Best Practices sich angucken und einfach auch da, die haben gute Guidelines, wie denn deren Composables gebaut werden.
Auch da definitiv, das lohnt sich.

[1:39:15] Ich würde wahrscheinlich eine Sache noch ansagen, was bei Nux so eine Pitfall sein könnte, habe ich auch mittlerweile Docs geupdatet und auch ein kleines Bewegtbild dazu aufgenommen mit ein bisschen Sprachunterlage.
Und zwar das Thema Runtime-Config.
Auch wieder, wer mit Next vielleicht ein bisschen was macht, kennt das Wort daher.
Ansonsten, wir haben eine Anwendung und die Anwendung hat Umgebungsvariablen, Entvariablen, kennen wir.
Jetzt haben wir aber das Problem, naja, wir wollen unsere Naxt-Anwendungen zum Beispiel einmal bauen und wollen dann aber dieses gleiche Artefakt, was nach dem Bauen rauskommt, für vier unterschiedliche Instanzen nutzen.
Da aber sagen, in dem einen Fall ist die APU-LDR, weil da ist halt was sich Loadbalancer oder sowas davor oder ähnliches ist und da soll es so und so sein und, jetzt können wir halt in unserer Naxt-Applikation nirgendwo einfach sagen Process.env, weil so ein Process.env gibt es halt gar nicht überall, dass hier was Node-spezifisches und zum anderen.

[1:40:17] Naja, wenn wir das so nutzen würden, dann würde beim Bauen das Ganze halt einfach in die Applikation direkt eins zu eins gebacken werden und das steht fest.
Dafür gibt es eben die Option RuntimeConfig und da ist die Idee zu sagen, man definiert eben Werte, die werden nach einer bestimmten Struktur, bestimmten Endvariablen zugewiesen, also wenn ich zum Beispiel sage, RuntimeConfig ist ein Objekt, da habe ich dann my API, also my API mit großem A für CamelCase ist, dann ist das das Gleiche wie, die Endvariable naxt-my-api.
Und das ist super. Problematisch wird es aber, wenn dann Leute denken, naja, diese Struktur ist eigentlich egal, wichtig ist, was ich für einen Wert zuweise.
Und das ist nicht so, weil der Wert ist nur der Default-Wert und nur diese Variable, also nur dieses naxt-my-api kann die Sachen wirklich zur Laufzeit überschreiben.
Und das ist, was viele Leute noch ein bisschen.

[1:41:08] Abbringt vom richtigen Weg. sagen, ah, meine Variablen gehen nicht wie so und naja, in der Dokumentation steht relativ klar, das ist die Struktur.
Tatsächlich, wenn du über diesen String, also über diesen Key hoverst, in der Nuxt-Config steht da, du kannst diesen Wert als TS hin, du kannst diesen Wert überschreiben mit und dann genau wie die Endvariable heißen muss.
1 zu 1. Trotzdem, viele Leute realisieren das nicht und wenn man jetzt sagt, ich baue meine Anwendung und deploye die direkt, ist es egal.
Aber eben sowas, größere Anwendungen, E-Commerce zum Beispiel, so ein klassisches Beispiel, ich muss das halt überall verteilen oder so White-Label-Sachen mit, ah, da würde ich ja gerne sagen, mein Client ist Firma 1, da ist Firma 2.

[1:41:46] Schwierig. Ja, das ist natürlich auch immer die Erwartungshaltung, die man sonst so haben kann.
Also mir ging es bestimmt schon eben, klar, deswegen mag ich ja Vue, weil da immer sehr viel sehr gut erklärt war.
Und ich bin nie als erstes auf Stack Overflow gegangen. Ich bin immer zuerst zu der Vue-Dokumentation gegangen.
Manchmal sogar auch Spaß, so was gibt es so Neues, auch wenn ich gar nichts Bestimmtes gesucht habe.
Aber ich war trotzdem bei vielen anderen Tools, die angeblich auch so cool und so von der Community, von so vielen Leuten genutzt werden, werden, wo ich dann Stunden versucht habe, mit der Dokumentation rauszufinden, was ich da eigentlich tun soll und nach Stunden habe ich festgestellt, ich muss jetzt andere Leute fragen.
Also je mehr Erfahrung ich mit sowas habe, desto schneller fange ich wahrscheinlich an, einfach zu fragen, um mir selber fünf Stunden zu ersparen.
Ja, ganz, ganz wichtig. Ich glaube auch, also gerade so bei den Meta-Framework-Themen, lieber auf GitHub irgendwie ein Issue erstellen, discussionen oder viel schneller im Discord mal fragen.
Sagen, es wird immer Leute geben, die sagen, okay, wenn es so das typische Problem ist, so die fünf Klassiker, hier ist ein Link, das, guck mal, mach das, dies, das und vor allem, das sage ich auch tatsächlich ganz oft, lernen, wie man eine Reproduktion baut.
Nicht sagen, hier ist mein Projekt oder, oh, es geht nicht, sondern wirklich sich die Mühe machen, die fünf Minuten einfach zu sagen, okay, die Funktion geht bei mir nicht in meinem riesigen E-Commerce-Projekt, zum Beispiel in meinem riesigen Projekt generell.
Ich baue es mal in einer neuen Nacktinstanz nach. Hat sie wahrscheinlich, der backt dann auch schon Resolve von alleine.

[1:43:14] Ey, ich sag das immer, mir passiert das auch noch oft, dass ich sag, okay, ich hab eine riesige Anwendung, denke, okay, alles klar und ich teste es aus und it just works. Ich bin so, okay, Mist.
Und dann hat man sich halt auch nochmal Zeit gespart, zu sagen, jetzt muss ich auf die Antwort warten, bis jemand antwortet.
Ansonsten hat man halt eine gute Option zu sagen, hey, das ist das Problem, wie löse ich's?

[1:43:39] Und das gilt natürlich. Framework und sprachübergreifend Reproductions sind das A und O und so klein wie möglich.
Ja, auf jeden Fall, wenn man schnell Hilfe braucht, auch immer gut.
Ich glaube, in jedem Fall, wenn man Hilfe braucht, ist es ideal.
Weil, also, ich hatte jetzt auch logischerweise weder die Zeit in der Freizeit zu sagen, okay, ich wühle mich jetzt durch dieses Riesenprojekt.

[1:44:04] Natürlich, wenn man sagt, okay, ich habe jetzt hier ein Großprojekt und will ein Order oder ähnliches haben, ist eine andere Geschichte.
Aber Aber ansonsten ... Ja, da muss man dich dann schon engagieren.
Da bin ich dann dabei, richtig.
Man muss sozusagen den Weg so weit gehen, wie man ihn gehen kann und dann uns die User Experience für dich halt oder für die anderen Leute, die das rauskriegen könnten, eben dann so gut machen, dass die auch die Lust haben und die Zeit sich nehmen, von der sie jetzt ja auch nicht übermäßig viel haben.
Genau, das ist natürlich der andere Punkt. Man sagt, man hat irgendwie 900 offene Issues.
In der Next Repository ist natürlich nicht alles Bugs, sondern es sind halt viele Sachen, wo noch Try-Hash aussteht oder Feature-Request oder oder, aber dann zu sagen, okay, es gibt ein Problem, ich gucke es mir an und es gibt halt nicht mal einen Link oder ähnliches, dann ist halt klar, es gibt ein Label, da wird automatisch drunter kommentiert, wird dann gesagt, okay, hey, hier, so erstellst du das, mach das doch bitte, ansonsten ist der Issue in der Woche wieder zu, weil, also basierend auf irgendwie drei Textschnipseln wird es schwierig.
Wenn jemand sagt, ich copy-paste den Code, ist das schon mal besser als gar nichts, ist auch schon mal besser als ein Screenshot von Code, aber ey, wenn du so weit gehst, dann erstell doch so eine neue Nux-Applikation, dann kann ich es wirklich direkt sehen und du kannst schreiben, erstens, klick auf den Link, zweitens, guck in die Konsole, drittens, seh den Fehler.

[1:45:14] Das ist halt zwei Minuten mehr Aufwand und teilweise ist es halt okay, Leute wissen nicht, wie das gemacht wird, weil das bringt einem ja auch in dem Sinne jetzt keiner klassisch bei, und viele Leute machen das dann tatsächlich, wenn man auch über diesen automatischen, Kommentarsinn sagt, okay, ja, hier, kein Problem.
Genau, das wollte ich auch gerade dazu sagen, das soll überhaupt nicht als Entschuldigung oder sonst was gemeint sein.

[1:45:37] Ich bin jetzt in vielen Projekten auch nicht nur im Startup gewesen, wo ich so immer wieder Projekte von vorne gemacht habe.
Ich stelle es mir aber trotzdem als eine Hürde vor. Ich komme in eine große bestehende Firma, die haben schon immer dieses Setup.
Vielleicht hat die Person wirklich noch nie einen Create-Weed-Create-Next-App gemacht.
Und dann hat man da so ein bisschen, man will ja jetzt, also ich würde persönlich jetzt auch nicht sagen, ich habe euch hier was zum Reproduzieren gegeben, weiß aber nicht, ob das eigentlich richtig ist, was sie gemacht hat, das ist ja vielleicht auch ein bisschen peinlich oder sowas.
Das war jetzt die nette Variante, die andere Variante, irgendjemand ist einfach faul und das ist, oder man sagt, die Person hat bestimmt ganz morgen eine ganz wichtige Deadline und stand halt leider unter Stress.
Ja, urgent, urgent, please fix now, otherwise I will get fired.
Ja, das leider kann das vermutlich sogar leider dann manchmal zutreffen.
Aber dann dürfen natürlich diese Firmen keine Open-Source-Produkte nutzen, dann sollen sie halt einen Paid Sachen verwenden, wo man dann 24-Stunden-Support hat. Ja.

[1:46:40] Aber also genau, das ist auch, ich würde es niemandem vorwerfen, zu sagen, hey, jemand, der es noch nie gemacht hat, bitte, dafür haben wir ja genau diese Anleitung, zu sagen, guck mal, hier ist der Link, guck dir das an, wenn was nicht klappt, dann schreib mir eine Nachricht, kein Problem, aber natürlich dieses gewisse, okay, hier hast du eine Anleitung, ab da ein bisschen Eigeninitiative und Research, das will man den Leuten, die ja dann auch freiwillig helfen, so ein bisschen zumuten.
Und ich glaube, sobald das halt den Leuten auch klar ist, wie gesagt, die meisten sagen dann, okay, ja, hier oder, wie gesagt, merken dann, okay, ich hab's gefixt, hier, das schreiben dann am besten noch hin, das war die Lösung und das hab ich falsch gemacht, alles super.
Nur mal so ein Flow, vielleicht bekommt die Person wieder so ein Ticket mit so zwei Stichwörtern und die Person, die ein Ticket abarbeiten muss, mit zwei Stichwörtern und einem Screenshot von einem Text, den man abschreiben muss am besten oder von dem Screenshot, den, das Padding rausbekommen muss, dann, die Die sollen dann plötzlich ihr Mind umswitchen auf, ach nee, ich mach das ja jetzt schon ausführlicher.
Ja, guter Punkt. Jetzt haben wir ja einen großen Banger für ein Ende noch.

[1:47:46] Genau. Ja, und für alle, die mit Nuxt noch nicht gearbeitet haben, genau, wir haben es gesagt, ihr habt eine gute Doku, die ist wahrscheinlich so, da habt ihr wahrscheinlich einen guten Get-Started-Guide.
Ihr habt wahrscheinlich so Starter-Packs, die man sich dann installieren kann, wo schon wahrscheinlich ganz viel so quasi so Standard-Webseiten Boilerplate drin ist.
Man muss doch bestimmt nochmal die Portfolio-Webseite nochmal neu schreiben.
Also tatsächlich, es gibt ein Command, da kann man einfach ganz, ganz plain mit so wenig wie möglich anfangen und das würde ich tatsächlich auch immer empfehlen.
Ich habe immer die Erfahrung, wenn man so Boilerplates bekommt mit, hier sind schon mal 100 Dateien, wenn man 90% davon nicht weiß, was los ist, ist immer schwierig.
Deswegen lieber von Null und sagen, okay, jetzt baue ich mal Step-by-Step und schaue mal und kenne auch die Features.
Klar, wenn ich sage, okay, ich habe jetzt schon hier Next und Angular und Svelte und alles genutzt, ich will direkt reinjumpen, auch kein Problem, fork dir einfach meine Seite und let's go.

[1:48:40] Okay, und genau, das macht man.
Ich würde wahrscheinlich noch wissen wollen, was würdest du empfehlen, wo ich das am schlauesten hoste, weil so ein Node.js-Hosting gibt es ja nicht bei allen Hostern.
Genau, also auch da wieder, wir haben ja kein Vendor-Login und mittlerweile, also wenn man sagt, ich brauche dynamisches Server-Side-Rendering, dann kann man von irgendwie VPS auf Digital Ocean, wenn man das unbedingt möchte und sich die Maintenance und Co.
Antun möchte, aber es ist halt die günstigste Variante, so habe ich am Ende auch angefangen.
Man kann sagen, ich packe das serverless zu irgendwie Versal oder Netlify, geht genauso, haben gute Free-Tiers.
Es gibt Fly.io, es gibt Render, wo man dann so Sachen laufen lassen kann, eben mit längeren Prozessen, die ja nicht serverless laufen und Und ich denke, das sind ganz gute Startpunkte.
Ja, cool. Und dann hast du gesagt, es gibt einen Discord. So ist es.
Und genau, es gibt einen GitHub-Issue-Tracker und so weiter und so fort.
Also genau, es wird einem weitergeholfen.
Das definitiv. Also wir versuchen wirklich auch schnell zu antworten.
Das klappt auf jeden Fall gut.
Und ansonsten, wenn es irgendwelche Fragen gibt, ich biete mich auch direkt an, shootet mir eine Nachricht auf Discord, Twitter, bzw.
Xlinkedin mastodon. Ja, wir werden alles verlinken.
Wunderbar. Inklusive YouTube natürlich. Genau, das schau ich auch nicht. Ich guck gern vorbei.
Auch da gerne, wenn ihr schon ein bisschen Nackterfahrung habt. Und ja.

[1:50:09] Wunderbar. Vielen, vielen Dank. Das war super.
Sehr gern. Wir sehen und hören uns ja auf jeden Fall noch einmal wieder, mindestens. So ist es. Ich hoffe, es wird nicht das letzte Mal bleiben.
Vielen Dank für deine Expertise, Vanessa.
Und meinen Verschreiber mit dem unser langjähriger Gast.
Das ist ja manchmal durch Raumzeiten-Kontinuums-Verschiebungen passiert sowas ja schon mal. Zukunft, Vanessa.
Jetzt hast du es verraten. Wir nehmen die Folgen ja auch manchmal in unterschiedlichen Reihenfolgen auf und dann denkt ihr nur, die werden in der Reihenfolge aufgenommen, sind sie aber gar nicht.
Stellt euch mal vor, wir würden zurück in die Vergangenheit reisen, ob Leute uns glauben würden, dass wir von der Zukunft kommen würden.
Wir gehen da also jetzt mal so, gar nicht mal so weit, lasst uns mal nach Jahr 2000 nur zurückgehen und dann gehen wir da hin.
Also Leute, also in 20 Jahren haben wir da 20 verschiedene Frontend-Frameworks mit 20 verschiedenen Meta-Frameworks.
Das wird's werden. Wie funktionieren die alle?
Weiß ich nicht. Das machen andere Leute, die werden dafür an sich nicht so bezahlt.
Die machen das unter Freizeit. Wie funktioniert das Konzept?
Weiß ich auch nicht. Irgendwie funktioniert das. Ja, aber ich meine, das Wichtigste ist ja eigentlich, dass wir Sachen vertikal zentrieren können.
Und damit ist ja schon klar, dass wir müssen aus der Zukunft sein. Das stimmt.

[1:51:38] Uns macht CSS Spaß, was? Ja.

[1:51:43] Alright. Alright, ja dann, vielen Dank nach Amsterdam, wo du sitzt, haben wir gar nicht erwähnt.
Genau, so ist es. Lieben Gruß und lieben Dank zurück.
Hat mich sehr gefreut. Super Konversation, sehr spannende Themen.
Und dann uns aufs nächste Mal, sagen auch unseren Hörerinnen, vielen Dank fürs Zuhören.
Und genau, nächste Woche geht es um, was machen wir da, dann reden wir doch mal über, Designsysteme, und wie man ein Schnellstart-Design-System hinlegen kann mit so einer Art Boilerplate.
Auch sehr spannend. Genommen von den Menschen von Kickstart.de.
Die hatten wir schon mal vor einem Jahr da oder so.
Genau, die haben wieder was Neues und wollen ein bisschen was erzählen.
Alles klaro. Dann vielen Dank und bis bald. Tschüss. Gehabt euch wohl. Ciao, ciao. Ciao, ciao.

[1:52:41] Music.

[1:52:51] Bis zum nächsten Mal.

Revision 608: Nuxt & unJS

Es wird über Nuxt.js, Vue 3.0, Composition-API, automatische Datei-Importierung, serverseitiges Rendering, Tools wie Storyblock und Nuxt DevTools gesprochen. Auch Vue 4.0 und Migrationskonzepte werden thematisiert.

Chapters

Long Summary

Brief Summary

Tags

Transcript

Revision 608: Nuxt & unJS

https://workingdraft.de/608/