Revision 500: Yolo

Transcript

[0:00] Ich drücke auf den Button und es passiert nichts. Und ich bin mir nicht sicher, passiert nichts, weil der Loading State fehlt und es passiert eigentlich schon was?
Muss ich mal ins Network Tab schauen, ob da schon was passiert?
Oder war der Button einfach nur noch nicht reaktiv und hat auf Dinge gehört, weil er schon gezeichnet war, aber die Hydration oder die Interaktion oder der Event Listener noch gefehlt hatte?
Also ich habe nicht den Frontend-Masters-Kurs gemacht, sondern einfach die Quick-Doku so detailliert wie mir möglich war durchgemacht.
Das Spannende ist aber, wenn ich das richtig verstanden habe, ist, dass dieses JavaScript-File oder diese Komponente ausschließlich am Server läuft.

[0:41] Music.

[1:06] Revision 576, Diese Revision wird von niemandem gesponsert. Stattdessen möchte ich euch gerne einladen, die Frontiers-Konferenz am 21. und 22. September in Utrecht zu besuchen.
Die Konferenz ist ein Non-Profit-Projekt und wird von mir und meinen Mitschreitern aus dem niederländischen Frontiers-Verein organisiert.
Und wir fahren dick auf.
Es kommen Andy Bell, Lervi Roo, Zach Leatherman, Sarah Vieira, Laura Kalbach und viele mehr.
Insgesamt 14 Sprecher.
Und die Talks behandeln genau gar nicht irgendwelche aktuellen Frameworks, sondern betrachten jeweils bestimmte Aspekte der Web-Plattform oder des Web-Craftings.
Es geht um neue Colorspaces, Web-Components, Performance, Accessibility, Privacy, 3D und Lütti Ein Ticket für die zwei Tage liegt bei 500 Euro zuzüglich niederländischer Mehrwertsteuer und inkludiert sind nicht nur zwei Tage voller toller Vorträge, sondern auch reichlich Essen, und Trinken für euer leibliches Wohl.
Und Utrecht ist auch immer ein Besuch wert, mit seiner Altstadt und ihren Grachten, aber auch ihren spektakulären Neubauten rund um den Hauptbahnhof.

[2:23] Es gibt viele gemütliche Ecken und Restaurants und Utrecht ist die Stadt in den Niederlanden mit der besten Radinfrastruktur.
Bekommen, dann schaut auf frontiersconf.org vorbei und dann sehen wir uns hoffentlich im Herbst in Utrecht. Wir sind heute zu dritt aus dem Team dabei, der Stefan. Hallo, servus. Und als Gast

Revision 576: Qwik

https://workingdraft.de/576/

[2:48] ist bei uns dabei der Bernhard Meyer. Du bist auf jeden Fall auch ein sehr gern gesehener Gast bei uns, aber dennoch, bitte stell dich doch noch einmal vor für die ganze Hörerschaft, die die anderen tollen Episoden noch nicht gehört haben.
Ja, hallo. Ja, ich freue mich heute zum zweiten Mal dabei sein zu dürfen und dann stelle ich mich mal wirklich kurz vor. Also, ich studiere Psychologie, tue gerne Orientierungslaufen und Langlaufen und hin und wieder auch Programmieren. Ich glaube, ich lasse es jetzt so zusammenfassen.
Hin und wieder mehr Programmieren, hin und wieder ein wenig weniger. Und um das noch ein bisschen zu ergänzen, also ich studiere auch noch Mobile Computing und habe mal Software Engineering studiert, damit man das irgendwie komplettieren kann.
Und der Rest, vielleicht ergibt sich ja noch was währenddessen.
Ich finde es schön, wie du dich anders hältst mit deinen drei Studienkursen und ich programmiere mal wieder so hin und wieder. Denn das Thema, über das wir heute sprechen werden, ist QUIC.
Und die Idee hatte ich dazu, weil ich doch zugeben muss, dass ich so ein bisschen das.

[3:51] Thema doch so ein bisschen ignoriert hatte oder mich zumindest nicht stärker damit befasst hatte.
Das hat er das letztes Jahr auch schon gesehen bei State of JavaScript Survey.
Und ich hab das mal so kurz abgehakt, wie, okay, jetzt gibt's noch einen Quik.
Ja, ich schieb das jetzt mal in diese Schublade von irgendwie Svelte, SolidJS, Quik, weil ich glaub, es macht Sachen noch mal besser als jetzt React und Vue, haben vielleicht wieder darauf aufgebaut.
Aber vielleicht so was wie Astro.
Und ich war ein bisschen überfordert in dieser Framework-Landschaft.
Und wir hatten's dann auch in der Episode, Hätte ich auch noch mal in den Shownotes verlinke, ganz am Anfang des Jahres so der Ausblick Frontend Development 2023, da war noch der Joe Ray Gregory bei uns.
Und da war es auch so, ja, und QUIC könnte groß werden, vielleicht nicht.
Und dann ist jetzt aber passiert, dass ich mal wieder einen Monat lang bei Frontend Masters mich umgeschaut hatte.
Und da war ein QUIC-Kurs, dachte ich mir, komm, da schaue ich mal rein.
Ist zwar jetzt außer drei Stunden, wie dann die explizite Syntax und sowas aussieht.

[4:49] Interessiert mich vielleicht an der Stelle gar nicht so drängend.
Aber die erste Stunde war, was das Framework eigentlich ausmacht.
Und dann war ich doch schon sehr schnell sehr interessiert daran und hab in die Runde gefragt, kennen wir irgendjemanden, der sich mit Quik auskennt? Und Werner, da kamst du an den Start.
Und Wie kamst du denn dazu, dich dafür zu interessieren? Ja, also ich war mit Stefan vor mittlerweile schon einigen Wochen auf der NGBI in Belgien.
Und wir haben dort über TypeScript einen Workshop gemacht und der Stefan dann noch einen Vortrag.

[5:24] Und da auf einer Angular-Konferenz, beide als ganz große Angular-Entwickler, Und sind dann am zweiten Tag am Abend in Mischko Heveri über den Weg gelaufen und seitdem trage ich einen Quick-Sticker in meinen Geldtaschen obeinander.
Jetzt schon bald zwei Monate. Und war dann auch so, dass ich mir einfach gedacht habe, möchte ich mir mal genauer anschauen, nachdem ihr dann geredet habt.

[5:52] Genau, und ich glaube, da habe ich auch jetzt schon von Stefan eine Geschichte, ein bisschen einen Teil davon vorweggenommen, wie er zugekommen ist.
Ja, also das war es eigentlich. Es war die Stickerübergabe auf der Konferenz. Man muss ja dazu sagen, also der Mischko Heverdi ist ja vor allem bekannt durch Angular 1 und Angular 2, also da irgendwie 2 Plus, dass eigentlich in Angular sein, dass ich bis zu dem Zeitpunkt war, was ich selbstständig gemacht habe. Und macht natürlich jetzt mit quasi seinem dritten Framework nun mal alles ganz, ganz richtig und komplett anders. Aber das ist für mich eigentlich, muss ich ganz ehrlich sagen, der einzige Zugang, den ich dazu habe. Also ich vertraue mir jetzt komplett auf die Learnings von der Vanessa aus Frontend Masters und von Bernhardt in den sehr spontanen zwei oder drei Wochen, wo ich gesagt habe, hey, jetzt Zeit, machen wir doch was, weil ich habe absolut keine Ahnung, was das Ding kann oder nicht. Also ich habe schon ein bisschen vorgefühlt in der Vorbesprechung. Da habe ich mir gedacht, da klingen einige Dinge sehr interessant und ich werde jetzt einfach mal durch meine gewohnte, konsistente, kritische Haltung durchvalidieren und darum bin Ich bin sehr, sehr aufgeregt, was da jetzt auf mich zukommt.

[7:03] Ja, ich kann, deswegen wollte ich auch wirklich, ich hab erst noch gesagt, ja, falls wir niemanden finden, vielleicht kann ich noch mal richtig tief einsteigen und dann diese Episode quasi ich als Gastsprecherin machen.
Hab mich aber auch sehr schnell dann doch nicht mehr so ganz sicher gefühlt, was da wirklich under the hood passiert.
Aber für mich gibt's jetzt quasi so die zwei Sachen, worüber wir sprechen können.
Wir werden auf jeden Fall natürlich erst mal gleich sagen, was es generell macht im Groben und Ganzen.
Dann könnte man natürlich drüber sprechen, tiefergehende, wie lösen sie eigentlich diese ganzen Prinzipien, die sie verfolgen wollen.
Aber auf der anderen Seite finden wir die Richtung, in die sich das Web entwickelt, generell gut.
Finden wir, es sollte sich dahin entwickeln.
Finden wir, es ist vielleicht notwendig, der nächste Schritt in die richtige Richtung.
Oder, das berühmte Halt, da sollten wir doch noch mal von ganz vorne anfangen, das Normale zu überdenken.

[7:56] Denn ich habe jetzt hier so Begriffe gehört wie Resumability anstelle von Hydration.

[8:01] Und das scheint ja wirklich so ein komplett neues Prinzip auch wieder zu sein.
Denn ich erinnere mich, bei Svelte war es auch schon mal ganz kurzzeitig so, dass es auch wieder so was ganz Neues ist, in dem Sinne, dass der Code schon vorkompiliert ankommt und nicht zwangsweise das Svelte.js-Package auch mit an die Webseite ausgeliefert wird, wie es bei Vue und React einfach sein wird.
Aber bei Frontend Masters, da ging's dann auch gleich los, war eben auch der Kurs von Misko, das quasi, ja, jetzt strafe ich schon drüber. Bernhard, magst du da mal einspringen, was dieser Groundbreaking der Unterschied ist, dass alles so viel schneller ist?
Ja, ich kann es versuchen. Also ich habe nicht den Frontend-Masters-Kurs gemacht, sondern einfach die Quick-Doku so detailliert, wie mir möglich war, durchgemacht. Und tatsächlich kann ich aber da auch, also ist es mir ein bisschen wie dir gegangen, dass ich mir dann auch immer so laut schreiben, so, ah ja, jetzt habe ich es und dann immer der Punkt ist weiter zu erklären, dass dann gleich wieder ganz was anderes ist. Aber grundsätzlich, soweit ich jetzt einmal das verstanden habe und korrigiere mich bitte Vanessa oder Stefan genauso, dass der große Unterschied zwischen Resumability und Hydration jetzt ist, dass man quasi die Sachen am Server oder statisch hervorrendern und dann nur mehr den kleinen, also da sind muss schon wieder bei mir erklären.

[9:29] Ja, den kleinen Part an JavaScript, dass der, ähm, ja, okay.
Mir geht's ganz genauso.
Ich hab mir das angeschaut, statt jetzt durchzulesen, und während ich's angeschaut hab, dachte ich mir die ganze Zeit, ja, das klingt superlogisch. Aber ich hab gemerkt, jedes Mal, wenn ich's versuch, selber zu erklären, ist es irre schwer plötzlich.
Vielleicht fang ich noch mal so an.
Es wurde in dem Kurs auch vorgestellt, zu dem klar, erstmal typische Vergleiche, React, View, blablabla und wie toll dann ein Quickjar dann dementsprechend wäre, aber eben auch das mit der Entwicklung des Webs nochmal.
Also fangen wir nochmal vorne an. Wir hatten früher mal einfach statische Webseiten, die haben super funktioniert. Dann wollten wir aber Interaktionen hinzufügen und Sachen auch asynchron laden und einfach mehr ermöglichen mit den Sachen, die die aktuellen, zu dem Zeitpunkt, modernen Browser unterstützt haben und dann haben wir jQuery angefangen zu benutzen, und Ajax, das war schon mal auch extrem gut, aber dann wollten wir mehr und mehr, nachdem da ja so viel plötzlich ermöglicht war, und es wurde schwieriger für uns in der Frontend-Entwicklung, das noch zu strukturieren, weil es kaum eine gute Architektur möglich war mit reinen HTML, reinen JavaScript und reinen CSS-Dateien.

[10:46] So, lange Geschichte etwas abgekürzt, dann gab's sowas wie React, Angular und Vue, und die benutzen eine Technik namens Hydration.
Denn auch bei diesen Frameworks haben wir ja auch schon dieses statische Vorrendern am Server teilweise.
Was da aber dann passiert, ist, es wird ausgeliefert an die Webseite, je nachdem, je nach Settings und et cetera, bereits am Server vorgerendert, aber dann fehlen ja noch das JavaScript auf dem bereits vorgerenderten Code, das heißt, die Event-Listener und State-Management und et cetera.
Und dann läuft noch mal dieses ganze Processing im Frontend noch mal ab, obwohl es ja eigentlich schon da ist, um die Eventlisten da drauf zu sprinkeln, aber eben auch zu schauen, ob der ganze Status noch passt.

[11:33] Und hierbei kann es wohl durchaus passieren, dass obwohl man es versucht, so klug wie möglich zu machen, dass man wirklich nur das im DOM austauscht, was ausgetauscht gehört, es in der Realität meistens dann doch nicht ganz so gut funktioniert.
Was vor allem auch wirklich dann passiert, wenn das HTML nicht valide ist.
Also, wenn ich zum Beispiel ne UL habe, ne unordered list, mit Listelementen drin und da einfach die Diffs falsch verschachtelt.
Weil man zum Beispiel in einer unordered list, muss als erstes dann kindimmer nen li kommen, aber der Browser lässt schon auch durchgehen, wenn man nen Diff schreibt.
Kann aber sein, dass es im DOM generell dann anders strukturiert wird.
Es schaut visuell richtig aus, aber es springt vielleicht.
Und jedes Mal, wenn ich jetzt aber die Hydration wieder drüberlaufen lasse, dann wird der DOM ausgetauscht, obwohl sich vielleicht gar nichts verändert hätte, nur weil das HTML nicht mehr valide ist.

[12:26] Und dann ist es generell passiert.
Beziehungsweise jetzt mach ich noch mal die Kurve, warum machen wir das eigentlich alles?
Also es geht darum, dass die Webseite möglichst schnell zur Verfügung stehen soll und ich auf Sachen klicken kann.
Und es hat sicherlich alle von uns schon mal erlebt, dass ich auf eine Webseite draufgehe, egal ob Mobile oder auch Desktop, egal wie gut die Internet-Connection war, ich drücke auf den Button und es passiert nichts.
Und ich bin mir nicht sicher, passiert nichts, weil der Loading-State fehlt und es passiert eigentlich schon was, muss ich mal ins Network-Tab schauen, ob da schon was passiert.
Oder war der Button einfach nur noch nicht reaktiv und hat auf Dinge gehört, weil er schon gezeichnet war, aber die Hydration oder die Interaktion oder der Event-Listener noch gefehlt hatte.
Oder es sind dann noch Layout-Shifts, die passieren. Das sind ja so supernervige Sachen.
Und dadurch, dass im Prinzip das mit der Hydration zwar sehr gut funktionieren würde, aber in der Realität dann doch nicht so ganz, haben wir jetzt das Problem, dass es teilweise, obwohl das initiale Zeichnen und Rendern des Browsers schneller stattfindet, das heißt, ich sehe die Sachen vielleicht früher, weil es auch am Server vorgerendert war, dass ich dann auf den Button klicken kann und interaktiv sein kann, kann teilweise mit unserem aktuellen modernen Framework sogar länger dauern, als mit dem guten alten, ich schreibe einfach HTML und ich lasse das einfach ohne dieses ganze Serverseitige, ohne Hydration.

[13:54] Das heißt, wir sind ja fast wieder auf einem Art Rückschritt, wenn's jetzt wieder länger dauert als vorher. Und dann kam Quick um die Ecke und hat versucht, diesem ganzen Problem zu entgehen, dass auch gleich dieser Button klickbar ist.
Und wenn ich das Prinzip hoffentlich richtig verstehe, ist, dass Sie nicht nur am Anfang des HTML ausliefern, was die Seite jetzt braucht, nicht nur dann lazy loaden, was danach kommt, Sondern auch beim JavaScript, nur das JavaScript laden, und dem Browser transpilieren, nein, nicht transpilieren, aber, äh, ihr werdet es schon machen lassen.
Ähm, das jetzt auch tatsächlich zu diesem Status des Users, auf deren, auf dessen Webseite tatsächlich auch benötigt wird.
Weil wenn ich jetzt die ganze Vue-App ausliefe an den Browser, selbst, wenn's vorgerendert ist, selbst, wenn Sachen lazy-loaded sind, schicke ich vermutlich JavaScript mit, das die User an der Stelle gar nicht brauchen, was Vue aber zu der Stelle noch nicht weiß, weil es muss erst die Hydration machen, und dann weiß es, ah, okay, und jetzt brauche ich das JavaScript noch.
Und Quik möchte da, auf anscheinend sehr kluge Weise, die wir alle ein bisschen Tuber haben, richtig zu erklären, nur auch das JavaScript ausliefern, was an dieser Stelle dann benötigt wird.

[15:18] Okay, das ist eine spannende Info und ich versuche jetzt einmal zu resümieren mit dem, was du gesagt hast und dem, was ich jetzt gerade in der Dokumentation an Code-Beispielen aufgesaugt habe.
Um zu versuchen dem, als erstes möchte ich wissen, ob ich es verstanden habe und zweitens versuche ich dem Ganzen ein Bild zu geben.
Also was ich jetzt gesehen habe, wenn ich so ein Hello World aufmache oder sonst irgendwas anderes, dann sehe ich einfach ein normales JavaScript-File oder TypeScript-File, das Anfang ein bisschen wirkt wie React, weil ich mit JSX-Komponenten schreibe. Also die JSX-Komponenten-Syntax habe ich drinnen und ich habe ein Export-Default mit so einer Komponenten-Closure. Das heißt, ich kann nicht einfach nur eine Funktion zurückgeben, sondern das rennt über irgendeine Konvention und irgendeine Funktion, die wird irgendwas machen. Das Spannende ist aber, wenn ich das richtig verstanden habe, ist, dass dieses JavaScript-File oder diese Komponente ausschließlich am, am Server läuft und nicht am Client. Sprich, wenn ich eine Raute anwähle oder irgendwo hingehe, dann wird dieses JavaScript am Server ausgeführt, schickt man das Ergebnis hin und was mitkommt, ist so eine kleine minimale JavaScript-Random, die auf Klicks reagieren kann und auf Basis von jedem Stück, das Interaktion haben soll, Requests wieder zurückschickt, um das nächste HTML zu bekommen, das an dieser Stelle erforderlich ist. Mit dem Zusatz.

[16:42] Dass auch das Javascript mitkommt, das ich hier an dieser Stelle nachher brauche.
Also vielleicht um das irgendwie optimaler zu machen, zu cachen oder sonst irgendwas und nicht ständig Roundtrips zum Server zu haben.
Also man lässt so viel am Server wie noch geht und schickt nachher genau dieses Javascript hin, das du brauchst, um für diese eine Interaktion zu überleben.
Das ist aber ein doofer Name, aber ich glaube, das sollte es ungefähr beschreiben.

[17:09] Genau, jetzt schaue ich noch ganz kurz, wie das ausschaut. Ich hab da jetzt so ein Counter-Ding.
Ja, und da hast du einfach On-Click-Handle. Die haben auch so eigene Syntax, auch mit so einem Dollarzeichen hinteran.
Und ich glaube, das ist auch so der Indikator für den Compiler oder für das Framework so, hey, das Ding kommt jetzt eigentlich auch in den Client oder ist für den Client wichtig.
Das wäre jetzt mal so mein Gut Feeling. Also von dem, was ich jetzt gehört habe, gesehen habe, glaube ich, dass das so funktioniert.
Dann komme ich jetzt, nachdem ich mich wieder ein bisschen gefasst habe, Nur, man kann das komplett bestätigen. Also, das Ding, das da läuft, das kleine Stück JavaScript, das sich um die Interaktionen kümmert, ist der Quickloader, der genau die Aufgabe übernimmt, von diesen interaktiven Elementen dann die Events entgegenzunehmen.
Und da wird es aber eben dann deswegen spannend, weil wir können jetzt sagen, die Sachen werden entweder am Server ausgeführt oder man kann das Ding dann auch statisch kompilieren. Jetzt ist das wieder am Server ausführen, das muss ich sagen, hat mich beim Lesen der Doku, ich weiß nicht, wie es mit dir gegangen ist, Vanessa, auch immer ein bisschen verwirrt, dass man dieses Server-Side-Rendering ja nicht unbedingt hat, sondern man kann es auch zuerst schon statisch generieren. Und dieses spezielle Syntax, dieses Dollarzeichen, das du da erwähnt hast, Stefan, das ist dann genau dazu da, dass man über so einen Optimizer, der in VIT drinnen hängt, dann dieses Codesplitting macht, was von dem ganzen Code Server-seitig laufen sollte.

[18:38] Und was gleichzeitig laufen sollte, beziehungsweise wann, ja.
Das muss ich mir als Developer selber überlegen, was ich wo am Laufen haben wollen würde. Nein.
Das ist, ja, total überzeugt. Das ist genau der Punkt, den ich sehr spannend und sehr schwierig zugleich finde, dass das Ding durch dieses Resumable alles, was es braucht oder was es kann, mal am Server rendert und dann am Client weitermacht und erst dann schaut, wie stellt es sich jetzt den Zustand wieder so her, dass es am Client das weitermachen kann, was es am Server begonnen hat. Das klingt nach totaler Magic und das ist, finde ich, ziemlich ein Magic, wenn man die anderen Frameworks gewohnt ist.

[19:28] Ich glaube, es ist auch Magic. Also, die Wörter, die ich übrigens grade nicht gefunden habe, damit meinte ich, parse and die Execution vom JavaScript, dass es ja mit der Hydration so ist, ich bekomme das statische HTML, aber dann muss ich alles JavaScript erst mal laden.
Alles, was eben nicht lazy-loaded ist oder et cetera. Dann muss ich alles in JavaScript parsen und exekuten.
Und dann weiß das JavaScript, ah, ich muss ja gar nicht so viel austauschen, eigentlich schon fertig, oder ich muss doch so ein bisschen näher noch austauschen, ein bisschen mehr Eventlisten da machen.
Und bei Resumeability habe ich diesen Zwischenschritt von allem JavaScript runtergeladen und alles JavaScript pausen, exekuten nicht.
Und ich erinnere mich dran, aber da wurde es mir dann auch wirklich, da war ich dann so, finden wir jemanden zum drübergeben, dass es Chases gibt, wo die, nicht aufgebaut werden oder wo keine Kette ist, sondern wirklich ein einfaches Chasen, wo auch ein Status oder ein Stage drinstehen kann, in dem sich die User drin befinden.
Und der kann wohl relativ einfach gelesen werden. Also, wie gesagt, nur ein einfaches Chasen, keine Verkettung von Sachen, kein Nachvollziehen, um dann irgendwie schlau rauszufinden, was ist denn dieses JavaScript, was ich gerade brauche, und was brauche ich erst später?

[20:44] Was hast du da erst gesagt, dass es Chasens gibt? Es gibt Chasens mit einem Application Stage.
Diese useSignal oder useStore-Geschichte jetzt in Quick, da ist jetzt um...

[20:59] Okay. useStore kenn ich nicht, aber ich hab gehört, dass der State eben in einem JSON ausgeliefert wird.
Ich glaub, wir kennen das auch ewig ähnlich auch schon von...
Ich kenn's jetzt zumindest nur von Vue, dass da, wenn ich einen State hab am Server bereits, dass ich den auch immer an das Window-Objekt hänge. Natürlich ich nicht selber, sondern das Framework erledigt das für mich.
Und dann kann der Client aus diesem Window-Objekt-Store auch den State wieder herauslesen.
Und irgendwie sowas Ähnliches scheint es hier schon auch zu geben, um schnell zu wissen, um das herauszufinden, was sind denn jetzt eigentlich die Bestandteile, die ich als Webseite noch abrufen muss als JavaScript? Ganz genau, das macht Quick auf Komponentenbasis für einen.
Und das ist eben, ja, genau wie wir vorher schon geredet haben, das ist dieser Resumability-Part, wo man sich aber dann nicht selbst entscheiden muss, sondern er prerendert die Komponente quasi am Server und dann extrahiert er den State und die Event-Handling-Logik und die kann er dann für diese eine Komponente wirklich sehr schlau nachladen, nachdem das Ganze weggesplittert worden ist und so weit optimiert worden ist, dass man es wirklich jetzt pro Komponente hat, bzw. weil das noch nicht einfach genug ist, im Hintergrund macht er da dann noch ein schlaues Prefetching, was die Sachen sein würden, die man wahrscheinlich als nächstes klickt.

[22:28] Das klingt für mich, wie wenn wir in der gesamten Nachladesache, die es ja eh schon seit Ewigkeiten gibt, also Next.js macht das auch schon ewig, dass du einfach HTML renderst, dann kommt halt da die Hydration-Phase, aber dann werden auch einfach nur Seiten oder Routen nachgeladen.
Ich glaube, dass das View oder beliebiges View-Framework des Tages das genauso macht.
Und dass wir jetzt mit Quick die Granularitäten ändern, nicht nur auf Seite nehmen, sondern auf Komponent nehmen, das wäre das Erste, dass du sagen kannst, ja, ich kann nach dem wir dieses Komponentensystem haben, kann ich sagen, ich lade jetzt alles unter diesem Komponenten-Dollar-Ding nach, was ich gerade benötige und sogar auf Event-Ebene tatsächlich, weil ich auch bei einem On-Click oder bei einem anderen Event vom Nutzer oder der Nutzerin genau das gleiche mache. Also ich sage, okay, und da passiert jetzt wieder, sie ist in die Karte, da passiert jetzt Interaktion, da passiert jetzt etwas, dass ich nachladen muss und hole mir dort teilweise nur Änderungen, ein ganzes Changeset.
Also, das ist jetzt in meiner Vorstellung so.
Und ja, eben viel, viel granularer Wald als zuvor.

[23:36] Genau. Also, das ist auch die Ausgangssituation, die ich jetzt mal für mich als die wichtige Info hatte, ohne dann eben technisch alles komplett durchblickt zu haben.
Es ist ... Ich hab das mal ... Ich stampel das jetzt mal sehr plump als Lazy-Loading Stufe zwei ein.
Also, ein noch viel klügeres Lazy-Loading, dass ich tatsächlich nur das lade, auch an JavaScript, was ich jetzt in dieser Millisekunde auch tatsächlich brauche und nicht mehr, damit alles gerade, sichtbare, auch möglichst schnell da ist, möglichst schnell klickbar.
Und nur, wenn ich dann vielleicht scrollen anfange oder hier was draufklicke, dann der Rest kommt.
Was auch mit Lazy Loading schon ging, nur eben noch mal massiv viel besser.
Jetzt war ich aber an dem Punkt, dass ich das auch versucht hab, jetzt wie grade eben so ein bisschen stolperig, Anderen Leuten zu erklären, die keine Frontend-Developer waren.
Zwar immer noch Techies, also haben ungefähr eine Ahnung, was Lazy Loading und so weiter bedeutet.
Und dann bin ich doch sehr auf runzelnde Stirnen und fragende Blicke gestoßen.

[24:39] Was wir hier so generell eigentlich tun, ob das denn eigentlich so sinnvoll ist.
Wen interessiert in der Realität denn tatsächlich eigentlich dieser Lighthouse-Store?
Ist Lazy Loading überhaupt sinnvoll? Das ist doch super nervig, wenn ich jedes Mal wieder auf was warten muss.
Wäre das nicht cooler, am Anfang einfach mal 10 Sekunden zu warten, aber dann kann ich alles tun.
Und ich glaube, der letzte Punkt, ich weiß, ihr wollt mir gleich ganz viel entgegenwerfen, deswegen...

[25:10] Ich hab 100.000 Ecken, von denen ich jetzt auf dich zukommen kann, und ich weiß nicht, welche ich als Erstes nehmen soll. Also, du gehst weiter. Ich mach das wie eine lange Folge.

[25:20] Also ... Und das Letzte noch, dieses Prefetching ist doch auch blöd.
Woher wollen sie denn wissen, dass ich wirklich da draufklicken will?
Und ich weiß, es gibt so was wie einen Data-Safe-Modus und et cetera, aber den muss ja auch nicht jeder anhaben.
Und ich weiß es auch nicht, ob's wirklich eine gute Idee ist, zu denken, ja, ich habe jetzt gerade Bandbreite zur Verfügung, soll ich einfach schon mal die nächsten fünf Blogartikel vorladen, weil ich habe ja gerade Bandbreite zur Verfügung.
So, Stefan, Stage is yours. Also, wenn ich dieses Konzept so höre, es gibt ja das Konzept schon öfter, also Quick ist ja nicht neu in dem.
Es hat vor einigen Jahren zum Beispiel vom Rails-Framework dieses Hotwire-Konzept gegeben, HTML over the wire, wo es ja so ähnlich funktioniert.
Ich bin jetzt hier meine ganzen Erklärungen jetzt verdämmt, weil das ist mir ein bisschen genauer angeschaut früher. Und weil da eine starke Integration hat zum Rails-Framework, das auch sehr serverseitig ist, wo du aber auch sagst, genau diese kleinen Teile kann ich jetzt über Rails auch übertransferieren. Das erste, was mir in den Kopf kommt, ist, wenn ich das höre, wie das funktioniert. Es gibt konstant eine Verbindung zum Server. Wahrscheinlich, keine Ahnung, ob das über Websockets gemacht wird oder über irgendeinen normalen HTTP-Raumtriebs oder oder was auch immer, aber...

[26:38] Das Framework erfordert von mir, dass ich einen Node.js-Server laufen habe, der konstant eine Verbindung zum Client macht.
Und das ist gleich einmal das, wo ich als langjähriger Java- und Node-Entwickler, wo es mir die Ohren spitzt und die Nackenhaare aufstellt.
Also Node.js ist eine fantastische Umgebung, JavaScript ist eine fantastische Sprache zum Server schreiben, aber Node.js ist halt einfach immer richtig, richtig gut im Warten.
Es ist gut im Warten, dass du irgendwo von einer Datenbank eine Daten kriegst und nachher an einen Client schickst, in dem du noch ein paar Felder umänderst oder ein Chesen machst oder was auch immer.
Node ist nicht so gut, wenn du irgendwie an ein Compute gehst oder konstante Verbindungen aufrechterhalten musst.

[27:20] Also eines der beliebsten Node-Tools ist Forever, das sagt einfach, oh, du selber sagst, und naja, ich starte noch halt wieder.
Weil es eben ständig so passiert. Und das ist das erste, wo ich Fragezeichen im Kopf habe, heißt das überhaupt eine gescheite Idee.
Da muss man aber auch bedenken, dass wir es ja hauptsächlich mit zwei Arten von Applikationen zu tun haben.
Es gibt die eine Art von Applikationen oder Webseite, wo du halt Text hast, schönen Text und Bilder.
Also hauptsächlich lesen, konsumieren, wenig interagieren. Der einzige Interaktionsgedanke, den du hast, ist eine Navigation auf eine andere Seite, wo du ja sowieso wieder einen Server-Request auf das gesamte Dokument hast.
Das heißt, da ist der Server-Raumtrip relativ langfristig, das heißt, du lest zuerst, dann navigierst du, dann hast du wieder einen Raumtrip, dann lest du, dann navigierst du, dann hast du wieder einen Raumtrip.
Das heißt, der Server ist relativ entspannt und du kannst die Seite durchnavigieren und durchkonsumieren, wie du möchtest. Da brauche ich keine...
Feingrained Updates, weil ich ja sowieso immer das Gesamte brauche, also das Change-Set, das ich haben möchte.

[28:31] Ist ja die gesamte Seite.
Warum mache ich das auf so kleine Stücke runter? Und warum brauche ich da einen Node.js-Server dazu, wenn ich einfach die HTML-Seiten irgendwie anders auch rauskriegen kann, sei es jetzt dynamisch oder statisch?
Und die zweite Art von Applikationen, die ich habe, das sind die stark interaktiven Applikationen. Das sind die Applikationen, wo du Administrationsmasken hast, wo du vielleicht irgendwelche Grafen hast, wo du regelmäßig Daten vom Becken holst, damit du Charting betreibst oder Tabellen aktualisierst oder mein Gott, sei kreativ und habe ein Canvas-Element, wo du dich kreativ austoben kannst. Und genau diese Art von Applikationen sind sehr JavaScript-lustig. Warum sind die sehr JavaScript-lustig? Na ja, weil es viel um die Interaktion geht. Da ist das Change-Set auch per Default ziemlich, ziemlich groß. Was bringt es mir, wenn ich eine Form habe mit 30 Elementen und ich muss für jedes einzelne Input-Element, das ich bearbeite, nachher das Changeset an JavaScript oder die Updates vom Server holen. Also mir kommt das so vor und ich hoffe, dass ich es richtig verstanden habe, dass für diese beiden Welten, die man hat an Anwendungen, die eine Seite muss schnell sein und da navigierst du über das gesamte Dokument und die andere Administrationsmaske meist hinter am Login, wo du sowieso Time to First Byte oder First Interactive Thing ist sowieso die Anmeldemaske. Wer kümmert sich da drum, was als nächstes kommt? Dass genau für diese beiden.

[29:56] Welten Quick das schlechteste Tool der Wahl ist, weil es eben auf eine Granularität geht, die weder für das eine gut ist, nur für das andere gut ist. Und das ist halt, ja, darum frage ich mich.

[30:08] Für welche Seiten ist es jetzt gut? Oder welche Applikationen gibt es, die genau vor dem profilieren, Außer, ich bin der Misko, war 10 Jahre bei Googlen und Lighthouse Core ist wichtig.

[30:22] Applikation. Vanessa, magst du oder darf ich in Stefan kurz widersprechen bei einem Punkt?
Bitte, sehr gerne. Das war tatsächlich bei mir, warum ich ein bisschen gezögert habe, mich da in Quick einzulesen und jetzt bei euch da zu sein, weil ich mir zuerst so gedacht habe, so genau den Kritikpunkt, den du mit Node selber angebracht hast. Also ich komme eher aus der .NET-Ecke und das für mich immer basteln. Und dann habe ich mir gedacht, was fange ich jetzt an mit einem Web-Framework, wo ich jetzt dann einen Node-Server laufen lassen muss, dass das Ding funktioniert.
Weil ich arbeite nebenbei sonst mit Eleventy oder bin gerade dabei, mir Ameng Astro anzuschauen.

[31:10] Und dann war für mich das so ein riesen Blocker, dass ich meinte, also es geht nicht.
Ich weiß auch, also ich tue mir so viel leichter was auf GitHub Pages zu hosten, wie jetzt irgendwie einen Node-Server zu hosten für eine Frontend-Web-Anwendung.
Und dann kann man aber QUIC sehr wohl statisch bilden über so ein Plugin, add-on, sie haben einen eigenen Namen, wie das Ding heißt, und dann hat man das nicht, dass dieser Server ständig laufen muss, sondern das Ding macht zur Compile-Zeit so ein geschicktes Codesplitting, dass es die Module so sauber zerlegt, dass du die dann einfach wieder statisch hosten kannst und er die dann nachladen kann. Das heißt, das mit dem Node-Server, das ist nicht der Fall, weil ich mir gedacht habe, muss ich dann quasi, schreibe ich dann Rest oder was schreibe ich dann für Backend-Service oder wie mache ich die Sachen dann oder habe ich dann quasi da jetzt gedacht, ist das Backend von meinem Quick, ist das dann ein Backend von Frontend für irgendwas anderes oder so weiter, bis ich draufgekommen bin, dass man das schon sehr wohl einfach dann statisch bilden kann und dann hat man das nicht, dass man jetzt quasi immer diesen Node-Server laufen haben muss.
Okay, das heißt auch die Deltas werden vorkompiliert und das Einzige, was passiert, ich hole mir.

[32:38] Das zurück, ist das in allen Fällen so?
Weil mein Eindruck war jetzt schon auch, dass du servergenerierte oder dynamische Elemente hast.
Das ist nicht in allen Fällen so, sondern so, wie es du möchtest.

[32:53] Und das ist der Punkt, wo wir auch vorher schon gesprochen haben, entscheidet man als Reserver, was am Server und was am Client läuft.
Ich habe mir, wie ich mir das angeschaut habe, habe ich mir für mich eine Notiz aufgeschrieben, where does the code get executed?
Weil du musst das Ding schon wirklich gut verstehen, dass du weißt, was wo läuft.
Und Resumability klingt sehr nett und ich habe das Ding ausprobiert und es ist wirklich faszinierend geworden, die Komponente einfach am Server oder zur Compile-Zeit.

[33:20] Kompiliert wird und läuft, und dann zu einem Server oder zu einer Compile-Zeit kompiliert wird und dann wirklich nur dieses kleine Diff braucht.
Aber ich frage mich eben auch genau die gleiche Frage, die Stefan gerade in den Raum geworfen hat, für wen ist es denn?
Weil eigentlich, ich fände es eigentlich auch ganz nett, wenn wir einfach mal so ein oder zwei Frameworks hätten und die kann man dann einfach benutzen für zwei Use Cases, weil es ist wirklich schwierig, sich da im Wald der Frags noch zurechtzufinden.
Grade wenn man jetzt mal, um mal tatsächlich ehrlich zu sein, so was wie React View ist schon ...
Man hätte auch vielleicht nur eins davon gebraucht. Sie machen schon ziemlich ähnliche Sachen.
Aber jetzt ist es ...
Beziehungsweise will das so eine Art eierlegende Wollmichsau sein.
Also, es funktioniert für statische Seiten, es funktioniert für dies oder für jenes.
Oder ist es explizit ausgerichtet für die JavaScript-lastigen Applikationen, um die schneller zu machen.
Also das mit diesen, ich hab sehr, sehr viele Interaktionen und sehr viel JavaScript, wo ich ja vorher initial die Frage in den Raum geworfen hatte, auf solchen Webseiten, ist es wirklich notwendig, dass alles immer sofort klickbar ist, sodass ein User nicht eh bereit, hier mal kurz zu warten?
Mit dem Vergleich dazu, wie hoch sind eigentlich die Kosten, die wir haben, um das alles zu ermöglichen, dass das hier jetzt alles geladen wird.

[34:47] Ich weiß nicht, ob da, ähm, sie eine offizielle Aussage machen.
Bisher seh ich halt immer nur, es ist so viel, es ist halt besser.
Ich hab jetzt noch nicht gefunden den, den, den Hint für, benutze es genau hierfür.
Denn was schon jetzt meiner Meinung nach wäre, wenn ich jetzt eine einfache HTML, einfache statische Seite haben möchte, die nicht so viel JavaScript hat, dann würde ich normalerweise, da würde ich argumentieren, dass es für die Developer Experience nicht grade gut ist, mir immer so ein Framework eines Beins verbinden, was Breaking Changes haben könnte, sich verändern könnte und ich in zwei Monaten vielleicht nicht mehr lesen kann, weil ich in der Zwischenzeit schon wieder was anderes gemacht hatte.
Und da würde ich doch eigentlich die Sachen doch eher simpel halten.

[35:33] Also ein Gutfeeling, das ich habe, für was QUIC einsetzbar ist, ist tatsächlich Webseiten.
Witzigerweise, weil die Firma, die hinter QUIC steht, einen visuellen Editor, ein visuelles Headless-CMS macht, wo QUIC als gedachter Head für dieses Headless-CMS funktionieren soll.
Und Content-Management-Systeme sind vor allem eher auf content-lastigen Seiten notwendig.
Hätte ich jetzt mal so gemeint. Und darum hätte ich gemeint, ja, ich glaube, die Idee ist, macht's Webseiten.
Ich bin halt jetzt noch, also ich habe jetzt...
In den letzten, glaube ich, sieben oder acht Jahren jedes Framework sehr intensiv genutzt, weil wir in der Firma alle drei Jahre einmal den gesamten Frontend-Unterbau austauschen.

[36:23] Also React sehr, sehr viel, Angular sehr, sehr viel, bevor wir jetzt tatsächlich gar nichts mehr machen.
Ich bin einfach absolut der Meinung, dass es für normale Content-Webseiten, die du machst, es absolut keinen Grund gibt, irgendein überfrachtetes JavaScript-Framework zu nehmen.
Selbst wenn du interaktive Elemente da drinnen hast, wie zum Beispiel ein interaktives Suchfeld mit einem Dropdown oder ein Kalenderwidget oder was auch immer, da gibt es wunderschöne Alternativen.
Ja, MewPetit. Alpine oder Minifu. Heißt das Minifu? Genau.
Also, ja, genau.

[36:59] Man merkt, dass ich die letzten drei Wochen mit Python verbracht habe, weil alles, was klein ist, ist wie der große Bruder Mini.
Also statt Ginger habe ich Mini-Ginger und statt Anaconda habe ich Mini-Conda und fragts mich nicht, was Mini-Conda und Mini-Ginger tun, aber es gibt sie und sie sind mini.
Also gerade mit solchen kleineren Bibliotheken, die ich einfach drauflegen kann, mit denen ich ein bisschen Interaktivität drangebe oder bereitstelle, da fahre ich doch im Endeffekt viel, viel besser.
Und da habe ich genau die Ziele, die auch Quick verfolgt, nämlich einmal eine statische Seite laden und dann interaktiv machen durch Klicks, ja auch erledigt. Und die gab es so Dinge wie, hey, das JavaScript-Bundle asynchron und deferred zu laden, damit sie sich nachher einhängt und die paar Sachen interaktiv macht. Das macht man schon seit 10 Jahren. Also das ist im Grunde die hey, so funktioniert Checkquery-Variante. Und dass man visuell auch sicherstellen kann, dass, keine Klicks sofort stattfinden können.

[38:04] Und dann vielleicht erst später ausgeführt werden, wenn das Javascript bereit ist, dazu.
Das ist auch was, was man lösen kann, da braucht man jetzt auch kein Quick-Framework dazu.
Also, kann man wahrscheinlich sogar besser lösen, wenn man kein Framework nimmt, wenn man dann wieder Zugriff auf die Grundmittel hat.
Und darum bin ich da sehr, sehr skeptisch. Für die Welt, in der ich das sehe.

[38:25] Kommt mir das eher so vor wie eine Bubble in der Next.js-Bubble, Wobei, ganz ehrlich sagen muss, Next.js ist mittlerweile schon ein ziemlicher Schiff.
Ja, Bubble würde ich es nicht mehr nennen. Ja, ja, naja, wobei, da kann ich noch anders philosophieren.
Du nennst es nicht Bubble, weil es ja in deiner JavaScript-Bubble so groß ist.
Ja, ich habe gerade letztens gesehen, dass jetzt gestern der Boilerplate Next.js für Enterprises rauskam und da dachte ich mir, oh, Next.js Enterprise.
Ich mein, es klingt spannender, als es im Endeffekt ist für uns.
Das ist halt ein Boyerplate, wo alle ...

[39:04] Die ... also, einige Sachen vor uns, halt jetzt Storybook, irgendein Router, alles Mögliche, was man normalerweise so ...
Aber jetzt, weil ich ihr grad rede, spring ich da kurz ein. Ich seh ja einen Nachteil bei Alpine JS und PetiteVue, und was es vielleicht noch geben möchte, was mich normalerweise davon abgehalten hat, es zu benutzen.
Und der geht tatsächlich auch wieder in Richtung eher Developer Experience anstelle von User Experience, eigentlich rein auf Developer Experience.
Und das ist, dass, wenn ich jetzt den Use Case hab, ich brauche hier nur so ein bisschen Interaktion, aber der Rest ist eigentlich eine statische Webseite, dann ist das natürlich super, keine Frage.
In der Realität hab ich oft Sachen, da braucht diese eine Seite, bräuchte eigentlich nur ganz wenig Interaktion.
Die andere Seite bräuchte voll viel Interaktion und PTView und Alpine JS reichen da nicht mehr aus.
Ich glaube, mittlerweile sind die auch wiederum vielleicht gewachsen und können mehr, oder es gibt Extensions.
Ich habe keine Ahnung?
Aber für mich war's da, was ist, wenn ich dann doch mal mehr brauche?

[40:11] Und in der idealen Welt könnte ich sagen, dann verwende ich doch auf dieser Seite jetzt Vue.js.
Ich verwende immer die richtige Technologie, die ich gerade brauche.
Also hier verwende ich Vue.js, hier mache ich Alpine.js oder PT.Vue.
Hier habe ich, keine Ahnung, Angular-Dingens.
Aber dann habe ich ja auch drei Sachen zu maintainen, im Kopf zu halten, zu implementieren.
Oder ich habe Teams, und das eine Team ist daraus spezialisiert und mich daraus spezialisiert, was dazu geführt hat, dass ich doch gesagt hab, dann lass es uns doch in Vue.js machen, auch diese Seite, obwohl es hier leider, leider wirklich sehr wenig Interaktion eigentlich bräuchte.
Also sie ist sehr knapp an einer reinen statischen Webseite vorbei.
Jetzt habe ich aber auch die Vue-Komponenten mit Vue halt schon alle voremplementiert und ich bräuchte halt diesen einen Selectbox hier.
Und wir wissen alle, wir wollen keine Selectboxen schreiben.
Entweder wir schreiben sie einmal und benutzen sie für alles Oder ich benutze das native Select.
Aber wenn ich jetzt eben dieses tolle Select-Feld mit der ganz tollen UI auch auf dieser Seite brauche.

[41:10] Dann weiß ich nicht, vielleicht gibt es Adapter und ähnliches, dass ich jetzt meine View-Komponente dann doch auch hier wieder verwenden könnte.
Aber es ist kompliziert.
Und eigentlich möchte ich doch was shippen und was Schönes haben. Und zwar recht bald.
Ja, und dann bist du genau bei dem Punkt, wo du sagst, dann hast du dein Meta-Framework rund um das, wie Next.js, Next.VidPress oder wie es nicht alle heißen, du sagst, ja da kommt eher als erstes einmal diese statische Seite und dann kommt das Framework und macht alle deine Sachen interaktiv und sei es nur ein Dropdown oder sei es nur eine Suche oder sei es nur ein Formularfeld, eine Selectbox und dann sind wir wieder an dem Punkt, wo man sich fragt, naja, aber muss man genau deswegen das gesamte Framework gleich shippen oder geht man nicht auf sowas hin, wie quick das macht, ja jetzt sind wir wieder da runtergekommen. Ah Mist, okay.
Aber da kann ich euch jetzt beide noch eine große Freude bereiten, ich bin nämlich zufällig wie versucht habe, die Fehler in der CLI auf Windows zu debuggen von QUIC, auf das Projekt Mythosis gestoßen von Builder.io. Und das hat jetzt einen schönen Titel, Write Components Once Compiled to Every Framework.
Okay, cool. Und das passt perfekt in die QUIC-Schiene ein. Das ist so die eierlegende Wollmilchsau, mit der man halt, einmal, ich weiß jetzt nicht, ob ich es am Anfang gesagt habe, dass ich euch da ein Geschenk mit einem großen Augenzwinkern machen kann.
Das einfach, das löst genau die Probleme, das ihr jetzt angesprochen habt.
Punkt. Na, Gott sei Dank.

[42:38] Und mir ist da ähnlich gegangen, wie jetzt bei dieser Quick-Diskussion.
Es scheint alles zu können. Und das ist dann dieser Punkt, wo man es dann dafür einsetzt.
Weil wenn man das verspricht, ich kann damit die statischen Seiten generieren und ich kann genauso serverseitig meine Sachen machen.
Dann ist der Punkt halt wieder, ja, wofür soll ich es verwenden?
Und so ein Exempel, das ich ausprobiert habe, ich habe eine Seite, die ist jetzt gerade in Eleventy geschrieben, und da wird ein JSON-File mitgeneriert mit der statischen Seite.
Das ist quasi so die sehr simple API für native Apps, die aber dann halt feilschnell läuft.
Und das hätte ich jetzt probiert einmal in QUIC. Und in QUIC, du kannst QUIC nicht beibringen, dass es in diesem statischen Prozess, einfach nur ein JSON-File generieren sollte, weil es nicht schafft, die Endung für den einen File zu können. Das heißt, ich habe bei diesen Mythoses mit write-components-once compiled to every framework genau die Angst, oder aus der Erfahrung heraus, dass es nicht oder was wir eh alle kennen, dass wenn das Ding alles kann, dass es natürlich dann genau an diese Ecken in genau die Sonderfälle, die man haben wird, und die lassen sich leider leider nicht vermeiden, dass man genau da dann in die Probleme reinläuft, warum wir uns dann eigentlich ganz glücklich sind, wenn man sagt, man nimmt a View, a React, a was man kennt und schreibt es darin.

[44:06] Die eierlegenden Wollmesauen und genau die passieren meistens dadurch, dass sie erst einen Use Case machen und den auch sehr gut, Leute ausspringen, dann, wir haben aber noch mehr Feature Requests und plötzlich wächst es, um alles zu adaptieren.
Deswegen, ich meine, im Endeffekt ist Vue und React superähnlich geworden, gerade mit der Composition API, so ein bisschen wie React-Hooks, etc.
Aber Sie können jetzt bestimmt beide, das Single-Page-Applications, Multiple-Page-Applications, Server-Side-Render, Client-Side-Render, das können Sie beide gut.
Es kann schon sein, und ich kann es absolut noch nicht einschätzen, dass Quick vielleicht nicht die eierlegende Wollmilchsau ist, weil sie erst für den Fall gut funktioniert, aber dann später auch alle Add-ons und alles Mögliche für später noch hat, oder ob's einfach im Prinzip so sinnvoll ist, dass es für alle Use Cases gleich gut funktionieren könnte.
Aber ich bin da, werde alt, bin da irgendwie so ein bisschen skeptisch.
Und ich frag mich nur, weil der Ausgang davon war, und es wird immer so drauf gedrängt, dass dieser erste initiales Zeichen oder das erste initiale.

[45:14] Drücken von Sachen, so viel schneller geht. Frage ich mich, aber was hat das denn für Trade-offs?
Ist es einfach nur, ich muss ein neues Framework lernen, vielleicht ist es ein bisschen komplizierter, vielleicht brauche ich einen Node.js-Server, vielleicht ist einfach nur das Setup ein bisschen komplexer, aber hat es auch Trade-off für die User Experience?
Weil was bedeutet es denn im Endeffekt, wenn ich alles lazy-loade, alles lazy-parse und exekute?
Heißt es dann, dass es zwar initial 0,3 Sekunden da ist, aber alles, was ich danach mache, braucht auch wieder 0,3 Sekunden.
Es kann ja sein, dass das jetzt super smart ist und alles errät, was ich wahrscheinlich als Nächstes drücken möchte und das prefetche.
Aber kann das funktionieren im großen Stil? Wenn ich jetzt eine Quick-App schreibe, eine kleine, die wird sicherlich bombastisch gut funktionieren. Aber was ist, wenn ich jetzt versuche, Amazon Rewe Digital, keine Ahnung, mit Quick zu implementieren?
Wie glauben wir, dass die Performance wirklich alles… Stefan schüttelt den Kopf.

[46:17] Nein, also da sind wir genau bei diesem Punkt, den ich vorhin angesprochen habe.
Wenn du eine JavaScript-lastige Applikation hast, dann macht es ja Sinn, dass du die Sachen zum Client bringst.
Du willst dir jeden Roundtrip nachher noch vermeiden.
Servertraffic funktioniert, soll man auch machen. Server können auch viel Traffic handeln.
Genau wie du es sagst, muss ich für jeden Klick oder für jede Komponente das minimale Delta rüberschippen und einen Server-Roundtrip riskieren dadurch.
Egal, ob das jetzt zum Node.js-Service oder zum CDN oder sonst irgendwo hin.
Was ist, wenn du unterwegs bist und deine Verbindung ist schlecht, Klassiker, was machst du dann?
Also es hat schon Sinn, dass du ein bisschen die Dinge auf einmal rüberschippst.
Da kannst du relativ gut die HTTP-Kompression, die Speed zugutemachen, dass du halt auch die Dinge sauber rüberbekommst und dann dort ein Hosts, anstatt dass du wirklich für jeden kleinen Klick nur mal eine Extratour machst. Also ich bin da absolut deiner Meinung.
Ich kann mir gut vorstellen, dass im Produktiveinsatz solche Dinge schnell sichtbar werden.

[47:27] Wobei, wer wäre dir eine Firma interessant, die wir in Belgien getroffen hätten, die nämlich gesagt haben, sie switchen gerade von Angular nämlich auf QUIC und sind super happy damit?
Bin ich gespannt, wie es ihnen geht, ob das Ding schon läuft und schon draußen ist.
Tatsächlich ist da, also laut der Doku, oder weil wir über die Einsatzzwecke schon gesprochen haben, haben sie in der Doku wortwörtlich so den Satz dann, Applications built with, QUIC are fast, regardless of the number of components or complexity.
They are all of one constant time in terms of JS payload.
Das ist ja ein sehr großes Versprechen. Und, weil ich da gerade in der Doku bin, ein zweites Zitat noch zu dem, was die Vanessa vorher gesagt hat, Richtung Prefetching, woher man weiß, was gebraucht wird.
Da gibt es den schönen Satz, for example, the buy now button is more important than the add to cart button.
So QUIC will prefetch the buy now button first and then the add to cart button.

[48:20] Aber warum denn? Warum ist jetzt der Buy Now-Button wichtiger?
Das hab ich auch gelesen, aber woher weiß ...
A, woher weiß es das? Gebe ich das als Developer an, gebe ich Priority 1, Priority 2 an?
Ist es was Statistisches, das getrackt wird, was wird öfter geklickt? Und je nachdem, wie sich das ...
Aber, ich mein, wenn für mich jetzt grade der Add to Cart-Button wichtiger ist, für mich als User jetzt grade, hab ich ...
Buy Now ist nicht so. Falsch. Beinauswichtiger.
Ja, genau. Schön, dass wir Sie genau das Gleiche gefragt haben.
Also das war so ein Satz, wo ich mir auch so gedacht habe, ja, das klingt halt sehr nach Marketing.
Und zu dem Punkt, den der Stefan gerade gesagt hat, mit dem, wann da die Connection dazwischen ausfällt, weil ich fahre sehr viel hin und her zwischen Innsbruck, Linz und Wien, und da ist das deutsche Eck halt nicht gerade jetzt von Internet gesegnet.
Und da habe ich mir dann genau die Frage gestellt, Und auch beim Probieren fällt dann auf, manchmal geht es halt nicht.
Und da habe ich das Gefühl, wenn ich jetzt irgendeine JavaScript-heavy-Anwendung verwende, wie in React, wie in Vue, ist es sehr oft, dass der Button dann disabled ist, dass ich einen Loading-Spinner bekomme, was auch immer.
Durch dieses ganze, quasi als verkaufte Progressive Enhancement, minimale JavaScript bei Quick, klicke ich auf den Button drauf und nachdem man ja zu dem Zeitpunkt dann das JavaScript fetcht.

[49:43] Am Seriennet, ob er das fetcht oder nicht.
Und dann passiert halt entweder was oder es passiert nix. Es ist aber irgendwie viel weniger predictable.
Du kriegst ja keinen Dinosaurier, wenn du jetzt einen normalen Serverraumtrip machen würdest.
Aber ich würde jetzt doch mal erwarten, dass der Button, was auch immer der machen würde, schon das JavaScript laden muss, wenn er einfach nur sichtbar ist.
Ich kann doch nicht warten, bis ich auf den Button draufklicke, um dann das Javascript erst zu laden und zu parsen. Du hast das Click-Javascript, du hast das Javascript, das sagt, oh, an dieser Stelle passiert was dahinter.
Aber das musst du dann trotzdem immer noch holen.
Aber das hoffentlich wahrscheinlich, wenn es im Viewport schon ist.
Na, je nachdem, wie es möchtest.

[50:27] Die erschütternde Stille der Realisation, das ist alles eigentlich ein totaler Stoffgewiss.
Also ich habe ja in der Vorbesprechung so mal die Idee auch in den Raum geworfen, wie es eigentlich wäre, könnten wir nicht mal so eine Webseite anzeigen und so ähnlich jetzt wie bei Cookie Bunners, jetzt nicht, dass ich Cookie Bunners generell gut finde, aber dieses deutsche oder europäische, eher strengere TDPA, wo tatsächlich dabei steht, du musst jetzt hier akzeptieren, Ansonsten kommst du hier gar nicht erst drauf.
Ähm, vielleicht könnten wir den Usern mal die Wahl geben. So, hey, möchtest du die Seite betreten?
Dann lade jetzt sechs Megabyte runter. Passt das? Dann drücke ich, ja, das passt.
Ich hock hier am WiFi, Glasfaser ist doch super. Und dann muss ich auf nichts mehr warten.
Oder ich sag, boah, nee, ich bin grad mobil unterwegs. Ich geh einfach wieder, bevor jetzt mein Datenvolumen gleich weg ist.
Und ich konnte nicht mal was dagegen tun, weil ich auf die Seite gehe.

[51:23] Aber es ist halt dieses, es muss alles schnell drückbar sein und es muss alles nachladen, um keine Daten zu viel zu verbrauchen.
Ist doch schon eher der Anwendungsfall normalerweise bei mittelgroßen Applikationen, dass sie vor allem mobil was bringen würden, weil ich da die kleinere Memory auf dem Smartphone habe und vielleicht meine eigenen Daten und da wir hier in Deutschland und Österreich wohnen, dann wissen wir, wir haben davon nicht allzu viel.
Sondern wir, unsere Telekom und Vodafone und O2 und wie's hier alle heißen, geben uns gar nicht mal so viel.

[51:58] Aber ist es eben ... Aber genau auf diesen Geräten hab ich ja dann auch diese Probleme, wie was ist, wenn die Mobile Connection kurz weg ist.
Und ich bin doch schon auf der Seite, kann's jetzt ... Ich hab schon was geladen, ich hab schon drei Megabyte ausgegeben.
Aber jetzt komm ich nicht weiter, weil ich's Job da nicht runterladen kann.
Da hätt ich doch vielleicht doch lieber mal und bin jetzt ein bisschen im Offline-Modus und kann trotzdem aber noch die Sachen weiterklicken und vielleicht hat die Applikation noch ein paar kluge Queues implementiert, die meine Requests später noch losschickt, wenn ich wieder Internet habe.

[52:33] Da hättest du halt kein Dropdown brauchen dürfen, sondern ein Buy Now Button. Dann hättest du ein Prefetch gehabt.
Ja, wir sind das alles so kompliziert.
Voll guter Punkt. Also ich habe es jetzt gerade im Hintergrund nochmal ausprobiert und du kriegst dann die Network Requests, wenn du auf den Button drauf klickst.
Wenn ich drauf klicke? Sorry, ich will nicht laden, wenn ich erst drauf klicke.
Oder wenn du drüber hauerst, was natürlich am Mobile dann sehr schön ist.
Und das Nette ist auch, das haben sie auch in der Doku und ich glaube, in der Console ist das drinnen, dass an unterschiedlichen Bildfahren quasi im Development für das Hot Module Reloading und so, und dann einen speziell optimierten Bild in Production, sodass du halt, also die Seiten sind im Dev-Mode extrem viel langsamer wie dann im Production-Mode, was ja eigentlich per se mal gut ist, was aber für mich total zur Verwunderung führt, warum ich im Dev-Mode so lange warten muss.
Und ich wundere mich dauernd, warum ist das Ding so langsam?

[53:40] Und das liegt halt daran, dass er dieses ganze Splitting und Hot-Module-Reloading quasi live macht.
Das wäre ja mal ganz was Neues, wenn der Localhost dann – nee, Localhost langsamer als – nee, stimmt, okay, ja, sorry, jetzt habe ich gerade den Gedankenträger drin.
Aber dieses mit Development und Production Build unterschiedlich, das hab ich ja schon bei Webpack.
Da brauch ich ja noch nicht mal Vite oder TurboPack oder Bun oder Dingsbums.
Weil ich da genauso gut angeben kann, ey, mach hier mal später Chunks drauf, draus.
Aber im DevMode, dann load die mal eager.
Und auf Production, dann loadst du halt lazy. Also ... ja. Ja.

[54:23] Du bringst mich gerade auf einen irrsinnig guten Punkt. Machen wir ein neues Framework.
Nein, nein, das nicht, aber tatsächlich ist ja genau dieses bewusste Auswählen von Komponenten oder Teilen, das haben wir als Entwicklerinnen und Entwickler eh total gut unter Kontrolle.
Es gibt die Importdirektive nicht, oder die Importfunction. Mit der kannst du ein ECMAScript-Modul laden, da kann deine Komponente drinnen sein und fertig.
Und dass du die erst bei Click loadst oder nicht, das kannst du glaube ich jetzt in einem React oder in einem Vue genauso so lösen.
Ich glaube, da brauchst du jetzt nicht großartig einen Compiler dazu, der da das Ganze in einen Nodeserver schmeißt, weil das ist ja browserprimitiv.
Also, was du als Chunk, also Chunk ist glaube ich das, was der Bundler rausmacht, was du da als Chunk bezeichnet hast, muss ja nicht unbedingt ein kompiliertes oder gebündelter Chunk sein.
Kann ja tatsächlich auch nur ein ECMAScript-Modul sein. Meine Webseite ist kein Vergleich, weil es einfach mini ist und ein Blog und so, aber ich habe einfach damals gesagt, hey, ich arbeite jetzt nur mehr mit themenorientierten ECMAScript-Modulen und lade die dann dort, wenn ich sie brauche. Und.

[55:35] Das ist im Grund genau das, was du gesagt hast. Also genau das. Das sind Browsermittel, die haben und wir können genau die verwenden, um dieses Verhalten des Lazy-Loadings, wenn ich es benötige, zu machen. Und wenn der Bernhard sagt, dass wir bei QUIC sowieso selbst entscheiden müssen, was jetzt das Beste für unsere Applikation ist, warum gehe ich dann nicht so gleich den Level zur Browsertechnologie? Eben nicht. Also das Selbstentscheiden, das habe ich noch nicht 100 Prozent eben durchschaut, weil eigentlich macht es das total schlau. Je weiter, dass man in der Doku lest, desto mehr kommt man aber drauf, dass man manchmal natürlich doch entscheiden muss. Also das war für mich das Faszinierendste am Anfang, das Ding auszuprobieren und zu sagen, hey, die Sachen laufen am Server und dann läuft das Ding am Client weiter. Und dann war aber halt irgendwie doch entscheidend, vor allem, wenn man dann, es gibt zum Beispiel eine React-Integration in und dort verhalten sich die Sachen aber dann natürlich wieder anders, weil er das Splitting dann anders macht, beziehungsweise kann quasi Quick aus einer Quick-Komponente, wo du mit diesem Dollarzeichen arbeitest, für diese WIT-Optimization, kann das Ding Server- und Client-Code separat extrahieren und das ist irgendwie einfach so, wo du sagst, wir haben Ist das E in der Hand?

[56:59] Aber das verkauft sich halt schlecht, glaube ich. Wenn du selber sagst, wir können das eh machen, und wenn du dann ein Framework machst, das das automatisch macht.

[57:09] Nein, das ist ja auch der Framework-Gedanke. Der nimmt ja die...
Die manuelle Arbeit ab. Genau, die müßige manuelle Arbeit nimmt er dir ab.
Also das ist...
Ich befürchte aber auch so ein bisschen das Nachdenken dann dabei.
Also ich habe das Problem schon immer bei Vue und React, ich weiß nicht, vielleicht bei Angular ganz genau, ich kenne mich da nur nicht so gut aus, dass ich schon so ein bisschen damit hadere.

[57:31] Dass, jetzt kommen wir wieder Richtung Basics, dass mir Features verkauft werden, und jetzt nicht unbedingt nur von dem Framework selber, sondern dass mir auch wirklich juniorige Developer entgegenkommen, hast du schon mal was von dem Nuxt-Link gehört?
Und der macht ja so ein Prefetching und keine Ahnung.
Ich so, das sind doch HTML-Attribute. Du kannst doch bei jedem Link, Anchor Tag, einen Prefetch angeben, Bei jedem JavaScript, also HTML Script Tag, kannst du angeben Prefetch, Lazy, alles Mögliche.
Du hast es ja schon, konntest das ja alles vorher tun. Es ist, ich will nicht mal sagen, dass es kompliziert ist, nur man kriegt es weniger beigebracht.
Und man muss es nicht können, um mal was zu liefern, sondern fragt sich, beschäftigt sich vielleicht am ersten mit dieser ganzen Problematik, sobald man sich denkt, ja, also irgendwie ist das langsam, was ist denn da los?
Und dann gibt's super viel Wissen drüber, was aber vielleicht auch nicht leicht zugänglich ist, dass wie funktioniert das eigentlich mit Async und Defer und was ist die Reihenfolge?
Und es gibt, glaub ich, noch mehr Preload und Prefetch, wie funktionieren die ganz genau?
Und dann kommen die Browser-Settings dafür oder was passiert, wenn die User Battery-Safe-Modus anhaben und dann funktioniert's ja doch wieder anders.
Außer das eine, weil das blockiert dann wirklich. Aber wir wollen alle die Bandbreite Und wenn du 50, 60, 80 Module hast, die lazy-loaded sein wollen.

[58:54] Was ist denn jetzt das Wichtigste?
Und es scheint mir so, als versucht ...
Also, ich weiß, hoffentlich unterstelle ich jetzt im Framework nichts Falsches, aber als würde es das abnehmen und das versuchen, möglichst klug zu machen.
Aber ich weiß auch selber nicht, wie es möglichst klug dann wäre.
Wenn alle drum streiten, jetzt möchte ich geladen werden, werden.

[59:20] Ja, in Wirklichkeit, wenn jeder sofort geladen werden will, wird keiner sofort geladen.
Also da kannst du das gleich sparen.
Du sprichst am wichtigen Punkt, nämlich der, dass durch Framework so viel Basiswissen obfuskiert wird.
Wir alle haben den Punkt erreicht, dass wir auch wissen, dass die ganzen coolen Dinge, die da passieren, jetzt keine Rocket Science sind, sondern nur, unter Anführungszeichen, Leute, die bestehende Technologie in einer kreativen Weise verbocken und zugänglich machen. Das ist auch gut so. Das gehört ja her. Aber dafür brauche ich keine Frameworks.
Und wo wir eben wieder bei diesem Punkt sind, wo setzt sich QUIC jetzt rein?
Also wo holt QUIC jetzt Leute ab, wo man sagt, okay, diese USPs von QUIC sind tatsächlich auch Benefits für Nutzer und Entwicklerinnen und Entwickler?
Und die Antwort kann ich mir nicht mehr, also die Frage kann ich nicht mehr antworten.
Vielleicht ist es auch nur eine coole Tech-Thema.

[1:00:35] So wie Avatar. Ha ha ha! Ich find ja, ich find ja, ich find, das klingt ultraspannend.
Und als ich das gesehen hab, hatte ich auch kurzzeitig diesen Gedanken, weißt du, dann können wir auch jetzt View und React und Angular, dann schmeißen wir sie doch einfach mal weg, dann machen wir alle Quick.
Dann können wir alle das Gleiche lernen, müssen bei Jobs nicht schauen, was hab ich davor gelernt.
Aber das Einzige, wo ich halt immer noch weiter drauf dränge, A, macht es Sinn, uns so viel Komplexität ans Bein zu pinden?
Oder nimmt's vielleicht tatsächlich diese Komplexität weg? Weil, lass doch mal die Basic Basics sein, aber ich muss ja vielleicht auch nicht wissen, wie der DOM-Rendering ...

[1:01:18] Leider kann man jetzt auch wieder einen Riesenfuss aufmachen.
Muss ich wissen, wie der Rendering-Pipeline funktioniert oder nicht.
Aber viele wissen's wahrscheinlich da draußen dann doch nicht, aber es funktioniert.
Ich kann HTML schreiben, JavaScript schreiben, irgendwas kommt da an.
Diese ganzen Basics, diese ganzen Browse-APIs nicht mehr auswendig kennen, sondern kann mich einfach auf Framework drauf verlassen, dass es weiß, was oder raten kann, was die User jetzt als nächstes brauchen. Aber das, was ich immer noch nicht genau sehe, ist, Developer Experience hin oder her, macht es für die User wirklich Sinn, alles lazy-loading zu machen? Und in vielen Cases bestimmt ja. Aber was hat's denn ... Ich kann nur noch mal auf den Punkt darauf zurückkommen. Ich will doch nicht, dass ich auf einen Button drücke und dann noch mal extra lang warten muss, bis was passiert.
Ich finde das eigentlich ganz nett, wenn ich am Anfang mal drei Sekunden warten muss, aber dann ist auch alles da und alles funktioniert schnell.
Ich muss gerade heulen.

[1:02:13] Sorry, ich klicke gerade durch die Quick-Doku und habe mir den Network-Tab aufgemacht, und von Seite zu Seite gehen.

[1:02:25] Hat so im Schnitt 98 XHR-Requests. Jaja, aber ist das schlimm? Ist das gut? Macht das Sinn?
Es ist schnell. Naja, also das Ding ist, da gibt es halt auch einen Server, der das bearbeiten muss.
Am Client cool, aber es gibt einen Server, der das bearbeiten muss. Und ich meine, Ja, klar können die es selber auch bearbeiten, aber...

[1:02:51] Das kostet ja auch was. Also das ist ja nicht gratis. Du musst ja den Server betreiben können.
Oder mehrere Server, wenn du gerade viel Traffic hast.
Und wenn ich jetzt schaue, welche Deployments das gibt, dann sind die Deployments alle durch die Bank.
Irgendwelche consumption-based Plattformen wie Cloudflare Workers, Netlify Edge, was in Wirklichkeit dennoch Deploy ist, weil es ist LEdge, was in Wirklichkeit Cloudflare Workers ist, oder Google Cloud Run, was in Wirklichkeit eine Kubernetes-Lösung mit Container ist, aber halt auch um Consumption ist.
Es gibt keine Lösung, das Ganze einfach nur irgendwo auf einen statischen Host zu deployen, und Seiten zu liefern.
Also die Integrationen sind alle katsching, ein bisschen Münzen einwerfen, da und dort.
Du sprichst da was voll was Spannendes an, Stefan, Entschuldige, weil das hat mich ich auch gewundert.

[1:03:50] Wenn man die Doku dann weiter reinlässt, dann findet man die Punkte, aber natürlich unter Deployments beworben, seien jetzt mit Ausnahme von Denno, nur diese Consumption-Based Cloud Provider, wie du richtig gesagt hast.
Und es gibt aber ein Standard Node Plugin. Es gibt dieses Denno-Plugin und man kann das Ding SSG prerendern, Server-Side generieren, aber interessanterweise ist es unter die Deployments nicht drinnen.
Naja, ich schätze mal, Sie werden diese Deployments nennen, die auch für das Framework die beste Experience geben oder alle Features lösen. Das heißt, da wird sich nachher der Nächste fragen, aber jetzt habe ich es dort auf Cloudflare gegeben, also das etablierst du dir dann.

[1:04:43] Warum geht denn das nicht? Naja, weil eben ein statischer Host nicht alles kann, was zum Beispiel Athena kann und solche Sachen. Und ja, also vielleicht denke ich da in größeren Ordnungen, die mich ein bisschen unsicher machen, weil wir haben teilweise so, ja, also wir reden so bei uns für ein Teilprojekt zwischen 10 und 20 Millionen Requests pro Arbeitstag. Und das traue ich dem Ding nicht zu.

[1:05:16] Also, ich frag mich halt auch jetzt noch mal, was bringt das alles, wenn ich halt keinen schnellen Server hab?
Weil wir haben jetzt auch bei uns nicht alle Seiten optimiert.

[1:05:26] Im Sinne davon nicht unbedingt im Frontend, sondern wir haben eine Seite, da laden wir grad einfach zu viele Daten.
Klar, könnte auch das Frontend irgendwie besser machen, dass es die richtige, keine Ahnung, eine kleinere Menge anfragt und lazyloadet.
Aber wir unterstützen da im Frontend auch gar nicht so viele Sachen gerade, also muss Backend halt einfach mal, keine Ahnung, 200 Einträge von irgendwas nachschauen, aber jetzt nicht einfach nur gib mir alle von dem, sondern es ist irgendwie eine kompliziertere Query und es ist was mit Elasticsearch.
Aber da würde mir jetzt jedes Quick der Welt nicht helfen, weil an der Stelle ist unser Server beziehungsweise unsere Datenbank so ein bisschen der Knackpunkt.
Und das würde mir, wie gesagt, wenn ich jetzt als Frontend-Developer zum Beispiel, oder bei mir in die Firma im Frontend-Lead, hier, hab ich ja macht, kann ich ja sagen, komm, wir machen jetzt Quick, würde mir in dieser Instanz wahrscheinlich nix bringen, wenn der Server langsam ist stattdessen.
Oder wie viel teurer wird der Server, wenn, weiß ich nicht, was du grad meintest, Stefan, mit Kaching, ist halt ein bisschen teurer. Hm.

[1:06:25] Ein bisschen. Ja. Also, ich glaube, man kann jetzt gar nicht so das ...
Separat betrachten, was macht für uns im Frontend am meisten Sinn.
Ist es Quick, ist es View, ist es Angular, ist es PTView, ist es Inertia, et cetera.
Sondern das muss halt vielleicht schon wirklich das ganze Development Thema, das riesige Auswirkungen.
Wahnsinn, das ist so ein wichtiger Punkt, weil das ist wieder dieses eierlegende Wollmilchsau-Thema.
Es gibt andere Faktoren, nicht-funktionale Requirements, die man nicht außer Acht lassen kann.

[1:06:57] Darfst, weil wenn du jetzt sagst, hey, ich rechne mit sehr sehr viel Traffic und klar hat das eine O1 Blabla Performance Komplexität, aber es resultiert halt auch in Requests auf dem Server. Kann ich diese handeln? Kann ich mit diesen umgehen? Oder kann ich das Geld aufstellen, dass ich mal mehrere Server besorge?
Und wenn ich es nicht, wenn ich sage, es kostet was, meine ich ja nicht unbedingt nur Geld, sondern da ist halt auch Compute Zeit, die drauf geht und eine offene TCP Verbindung, die drauf geht und solche Sachen. Das sind Dinge, die übersehen wir gerne mal, weil es eh immer schon funktioniert hat, aber die sind halt auch je nach Größenordnung oder je nach Anforderungsprofil, das ich habe, sind das auch Parameter, die dort reinfließen müssen. Und da kann es durchaus für mich sein, dass ich sage, nein, das rennt halt für mich nicht. Es kann natürlich auch sein, dass ich sage, nein, ich arbeite jetzt schon seit 10 Jahren mit einem Express-Server und das haut super hin, der kommt damit zusammen, wird das auch können. Kann genau so sein. Also nur, weil ich da beim gerade ein bisschen Skepsis habe gegenüber Node.js-Servern, nach eben zehn Jahren Node.js-Server schreiben, heißt das nicht, dass das bei allen anderen auch so ist? Und darum, ja, Marius, du sagst so viele tolle, absolut richtige Sachen, Vanessa, mit was sind die Trade-offs, was sind die Trade-offs für die Nutzer und Nutzerinnen, was sind die Trade-offs für uns als Entwicklerinnen und Entwickler, das ganze Team-Care berücksichtigt, beziehungsweise auch.

[1:08:21] Die Anforderungen, die man hat. Also ich kaufe diesen, kann eh alles und ist eh für alles toll, Viewscales kaufe ich dem nicht ab. Ich habe zum Beispiel eine ganz große Anforderung in meinen Projekten, ich will nie wieder npm starten müssen. Geht das? Ich weiß nicht.
Es gibt auch dennoch Integration, das klingt schon mal nicht so schlecht, aber….

[1:08:45] Ja, es sind auch Sachen in Rust und in was, weiß ich nicht, was war da immer geschrieben?
Wirklich? Echt? Der Compiler ist in Rust. Der Compiler. Schön, dass wir alle so einen schönen Dialekt haben hier.
Das ist super, wenn man den Compiler in Rust gemischt hat. Also um auf positive Sachen noch mal dagegenzuhalten.
Ich glaube, das Framework macht generell schon sehr viel richtig mit diesem Ansatz von Sie wissen, es gibt schon bereits viele Frameworks da draußen, aber es ist migrierbar.
Du kannst mit, Herr Bernhard, wie hieß das Dingsbums? Mitosis? Ja, genau. Mitosis.
Um alles noch mal in alle Frameworks reinzubringen oder vielleicht auch andersrum.
Ich glaube, da gab es noch ein paar Abas dazu, aber generell sind die ganzen Ansätze da.
Du kannst sicherlich JSX, TSX, TypeScript, et cetera, hast du alles drinnen.
Ich glaube, das ist vielleicht einfacher von Vue zu Quick, von React zu Quick, als irgendwie von Vue zu React oder andersrum.
Also diese Ansätze haben Sie dabei für die erstmals hier Developer Experience einfach zum Starten.
Aber...

[1:09:49] Ja, aber dann, was sind dann so die richtigen Knackpunkte, die kommen würden?
Und dementsprechend nicht nur, wo wird's vielleicht mal schwierig, sondern sehen wir das Ganze vielleicht sonst eher als so einen Zwischenschritt, weil von dieser Ausgangssituation noch mal ...
Um auf die Ausgangssituation noch mal zu kommen, ich hatte damals einen Request an Server für, gib mir mal HTML.
HTML kam zurück.
Okay, jetzt brauchen wir so ein bisschen JavaScript. Jetzt wird das alles nicht mehr so doll.
Jetzt machen wir mal so was wie eine Hydration.
Also, was machen wir? Survey, gib mir mal HTML. Alles klar, hier hast du HTML.
Okay, jetzt kann ich aber noch auf nichts klicken. Und plötzlich muss ich fünf Sekunden warten, um JavaScript gesammelt runterzuladen, zu parsen, zu exekuten, DOM noch mal auszutauschen, obwohl er doch eigentlich schon da war.
Ist ja irgendwie auch ein bisschen doof.
So, jetzt kann ich klicken. So, jetzt kommt Quick mit der nächsten Instanz und sagt, ja, das war doch jetzt auch nicht mehr so klug, lass uns doch mal HTML laden.
Minimalstes JavaScript laden, wenn überhaupt. Und jetzt die ganze Zeit so düng, düng, düng, düng, düng, düng.
HTML, JavaScript, HTML, JavaScript, irgendwie so was.
Aber was wäre denn unserer Meinung nach ...

[1:11:04] Der nächste Ansatz dann? Wollen wir ...
Wollen wir in so einer Kettenverschachtelung alles die ganze Zeit so vor uns hinladen?
Gibt's da nicht noch was Klügeres oder gibt's da nicht noch einen Endzustand, wo wir dahin kommen wollen? Dass wir nicht HTML und JavaScript die ganze Zeit, weiß ich nicht, abwechselnd runterladen. Oder keine Ahnung, vielleicht sollten, vielleicht sollten, pass auf, jetzt sage ich was ganz anderes, wo ich mit meinem Gedanken kommen möchte. Wollen wir bei HTML bleiben? Wollen wir bei einem DOM-Tree bleiben, wo man Sachen austauscht.
Oder sollten wir mit... Wenn wir alle JSX, TSX und sowas schreiben, sollten vielleicht nicht Browser eher auch Komponenten und JSX verstehen können.
Oder Views, wo ich dann den Content so austausche und nicht den ganzen Content im DOM-Tree habe.
Gibt's da nicht auch schon APIs dazu, die das machen? Boah, echt? Keine Ahnung.
Ich glaub, da hat's einmal ein paar...
Ich weiß nicht, ob die schon gelandet sind, das wird der Chef wieder wissen.
Wissen. Aber gerade was für diesen Austausch, dass du nicht mal einen gesamten Raumtrip machen musst, sondern dass du nur Teile holen kannst und austauschen kannst, für das gibt es, glaube ich, auch schon irgendeinen Standard dort. Muss ich mal schauen. MGN Portals, glaube ich, Häster. Portal Element, na das ist glaube ich was anderes.

[1:12:29] Ja, the portal HTML element enables the embedding of another HTML page into the current one for the purposes of allowing smoother navigation into new pages.
Was?
Nochmal. Das Portal-Element, vielleicht gibt es das auf Deutsch, nein, gibt es nicht.
Es ist eine experimentelle Technologie und ich glaube, dass du genau weißt, was es soll.
Das wäre ähnlich zu einem iframe, aber nur, dass du nicht ein iframe hast, wo du nur einen gesamten DOM lädst, sondern die HTML-Stücke werden in dein HTML integriert.
Kannst du ein Portal auf dieses HTML und dann wird das integriert und es gibt eine JavaScript-Database dazu, mit der du diesen Content austauschen kannst. Das heißt, so hängst du andere HTML-Dateien, die woanders liegen, in deinen DOM bereits ein. Das schreit ja fast nach einem Framework.

[1:13:14] Nein, eben nicht, das ist ja schon eine Technologie. Ja, ja, da müssen wir einen Framework-Grund umbauen.
Ja, ja, bitte machen wir das. Aber man muss ganz ehrlich sagen, es ist immer noch hinter einem Also, es ist einfach schon sehr lange nicht da, aber...
Aber wäre das jetzt so ganz absurd, wenn ich das mal im Raum werfen würde, wenn man vielleicht tatsächlich nicht mehr einen Bildprozess hat und HTML shippt, sondern halt einfach JSX shippt und der Browser kann es selber, ohne Framework, ohne Bildprozess?

[1:13:45] Ich wäre ganz stark dafür. Ich mag eigentlich keine Bildprozesse mehr.
Also ich denke, was wir gerne übersehen, und wir meine die Industrie, nicht unbedingt die Runde für mich, wir sind nämlich hier sehr viel, aber was wir als Industrie gerne übersehen, ist, dass ja sämtliche Browser-Technologien sich ja schon hinentwickeln darauf, dass die gesamten Build-Prozesse usw. obsolet werden. Also wenn ich jetzt sage, JSX klamme ich jetzt einmal aus, sage einfach, hey, ich habe HTML, ich habe Template-Strings in JavaScript, mit denen ich was ähnliches machen kann.
Dann kann ich mit den aktuellen Standards, die existieren, kann ich dynamisch Module laden über das Import Statement oder die Import-Funktion.
Dynamisch. Wenn der Standard mit den TypeScript-Typen als Kommentaren durchgeht, dann kann ich sogar TypeScript schreiben und kann das shippen und ausführen. Es wird zwar nicht type-gecheckt, aber ich kann es ausführen.
Wenn ich das Portalelement habe und die Navigations-APIs dazu, kann ich einfach...

[1:14:54] Teile auf meiner Seite austauschen, und sie werden aktualisiert.
Und wenn ich Dinge wie die Transition-Styles habe, kann ich auch Animationen zwischen HTML-Seiten machen, ohne dass ich irgendein Framework dazu brauche.
Das heißt, wir sind eigentlich eh wieder an diesem Punkt, wo wir eigentlich in den ganzen letzten 15 Jahren sind.
Es gibt coole Sachen, die machen Leute irgendwie mit JavaScript, und wir schauen, dass wir das irgendwie in die Browser bekommen.
Leute, ich mache seit zweieinhalb Jahren kein Frontend mehr aktiv, aber sogar diese Browser-Technologien sind bei mir gelandet und ich habe mitbekommen, dass sie existieren.
Also die dürften wirklich sehr populär sein und nicht nur einfach in den Hirn gespenst.
Und da denke ich mir halt auch, wenn das kommt, wäre es doch eigentlich clever, wenn wir.

[1:15:42] Sagen, wir versuchen nicht zu viel framework-spezifische Dinge zu gestalten, wie das zum Beispiel jetzt Welt, soweit ich weiß, macht und Quick teilweise macht, sondern das Framework, das eigentlich sagt, hey, wir patchen jetzt schon mal Browser-Technologien, die mal kommen werden, ist mir eigentlich am sympathischsten, weil da weiß ich, hey, das kommt irgendwann einmal weg und das Framework kann sich dadurch ein bisschen reduzieren und ich kann vielleicht das austauschen durch andere Dinge auch.
Und da fällt mir witzigerweise auf, ja, Eleventy, das Bernhard gerade in die Kamera zeigt, wäre so ein Ding, aber tatsächlich witzigerweise auch ein bisschen langsamer und ein bisschen mit Verzug. Angular macht das ähnlich. Also Angular hat auch das gesamte Lazy-Loading, das sie mal entwickelt gehabt haben, schnell umgestellt durch das Import-Statement, weil sie eben gesagt haben, naja, jetzt haben wir ja eine Browser-Technologie dafür, warum nicht gleich das nutzen? Also das finde ich sehr spannend. Vielleicht sollte man wieder Entschuldigung.

[1:16:36] Ja, ich habe jetzt Eleventy deswegen gerade in die Kamera gehalten, weil ich war letzten Ende der Woche auf der GS Heroes in Rumänien und habe da glaube ich drei Stunden mit dem Sack Glider meinen von Eleventy geredet und da haben wir auch ähnliche Themen gesprochen, wo es halt um die Standards geht, dass man die verwendet und ja, da habe ich dann ein bisschen, wo ich meinen Schritt weg aus der IT hin zum Psychologiestudium hin und wieder ein wenig mache, weil Frameworks verkaufen sich halt einfach besser oder lassen sich das Produkt bewerben. Wer hypt denn einen Standard, bzw. wer hat denn was davon, wenn man einen Standard hypt? Also ich habe das Gefühl, dass es da um ganz, ganz viel größere Themen geht und ich glaube, wenn man eben länger in der Industrie ist, dann fängt man irgendwann an zu schätzen, dass Sachen standardisiert sind und die Aussage, die du gerade getroffen hast, Stefan, die finde ich unglaublich schön, dass man sagt, alles, was nachher wegkommt, ist eigentlich sehr schön, wenn man es jetzt schreiben kann, weil dann weiß man, es wird weniger.

[1:17:38] Ich glaube schon, dass man auf Browser APIs und Standards hypen könnte oder Leute darauf hypen würden, wenn mal jemand anfangen würde zu, wie heißt das, Developer Relations Advocates, dafür Marketing zu machen.
Denn da weisen natürlich jetzt Next und Next und Remix, keine Ahnung, wer noch, alle sehr groß.
Die haben ja Personen dafür, die sich drum kümmern, das beizubringen, zu zeigen, die Vorteile zu zeigen.
Cypress hat Ambassadors, Storyblock hat Ambassadors. Ich habe jetzt selten was von einem Browser-API-Standard-Ambassador gehört.
Da gibt es einige Firmen aus der Google-Ecke, die halt im Chrome-Team sind, aber die haben ein bisschen den Zug verpasst, glaube ich.
Die Sahne-Milch-Stadt.

[1:18:29] Kooperativ zu sein, sehr schnell in so eine Verteidigungshaltung gegangen.
Also es gibt da eine Person, die...
Oh, ich habe den Namen vergessen.
Alex Russell. Alex Russell, der lange im Chrome-Team war und dann die Web Components Standards gearbeitet hat und jetzt bei Edge arbeitet und weiter am Browser-Standards werkt und so weiter, war ein ganz starker Advokat für Browsertechnologien schon von Anfang an.
Aber halt auch ein bisschen ein Arsch.
Also, pardon my French, er geht sehr gerne auf Konfrontation, was jetzt für ein Developer Relations Mensch nicht das Richtige ist.
Da wäre es fast besser, wenn die Leute direkt offen auf die Frameworks zugehen und sagen, hey, wir würden gerne mit euch eure Roadmaps bearbeiten und sagen, was wir vorhaben als Browser Standards, können wir irgendwie einen Weg dort hinfinden, dass das funktioniert.
Ich weiß nicht, ob das passiert. Also, das ist auch wieder so eine Schöpffrage.
Also, ich glaube, der wüsste das ganz, ganz klar.

[1:19:34] Vielleicht sollte man da eben mal im größeren Big Picture drüber nachdenken.
Es gibt verschiedene Browser, die zu verschiedenen Zeitpunkten verschiedene Sachen liefern und daran arbeiten und überhaupt auch der Roadmap haben.
Dann bin ich mir genau bei diesem Austausch zwischen Browser und Frameworks unsicher.
Wie viel passiert da wirklich? Oder versuchen die Frameworks eben anhand mit allem, was ihnen zur Verfügung gestellt wird, irgendwie das Beste draus zu machen?
Und dann in der letzten Instanz gibt's uns Developer, die Frameworks benutzen, um eine möglichst gute Developer-Experience zu haben und auch die möglichst beste User-Experience herzustellen, um dann das Ganze wieder in den Browser reinzumatschen.

[1:20:28] Und das scheint mir irgendwie ein etwas komplizierter Weg zu sein.
Und diese ... Irgendwie scheint so ...
Wir versuchen halt für die Browser dann alles gerecht zu machen.
Aber vielleicht wär's eher mal an der Zeit, die Browser versuchen ... quasi ...
Also eher andersherum. Dass die Browser sich vielleicht mal ein bisschen weiterentwickeln müssten.
Vielleicht gibt's ja ganz viele Gegenargumentationen wie rückwärtskompatibilität und muss überall funktionieren.
Und es ist halt nicht so einfach.
Klar, aber das, was wir aktuell im JavaScript die letzten zehn Jahre so mitverfolgen können mit diesen Frameworks hin und her, das ist jetzt auch nicht gerade einfach. Es ist, alle Leute werden oder alle Developer werden nur noch so ein bisschen verwirrter.
Klar kann man dann auch in der Jobstelle einfach mehr Geld verlangen, weil man sagt, ja, frontend ist ja sehr kompliziert geworden, ich brauche mal 5K mehr.
Aber ich weiß nicht so, ob wir uns gerade in so eine gute Richtung entwickeln.
Ich glaube, da ist der Stefan mit seinem Ausstieg von vor zweieinhalb Jahren ein gutes Beispiel dafür.
Nachdem ich ja auch in vielen Technologien unterwegs bin, kann ich da bei allen Sachen extrem nur zustimmen, Vanessa.
Also, wenn man was anderes anonymer entwickelt, irgendwie im Web aktuell zu bleiben, ist ja schon ein Vollzeitjob.

[1:21:47] Aber das kennen wir eh. Ja, definitiv, aber dann fällt's mir eben auf, wenn ich anderen Software-Developern von ganz anderen Sprachen, und ich würd jetzt nicht mal so was wie Rust nehmen, sondern wirklich in Richtung SwiftUI, Objective-C, Kotlin, Java, so was, wenn ich dann erkläre, was wir machen.
Python.
2.7, nehm ich mal an, nicht 3.
Ähm ... Anaconda, Miniconda. Peep. Keine Ahnung.
Dann muss ich halt oft von Problemen erzählen, die es in diesen Sprachen oder Bereichen gar nicht erst gibt.
Ich sag's noch mal, du kannst eine App nicht teilweise ...
Ja, es gibt ganz viele Abas. Aber du kannst an sich eine iOS-App nicht teilweise herunterladen.
Es gibt dann auch Webviews und alles Mögliche.
Aber du musst halt einfach mal initial sechs Megabyte ausgeben, oder was weiß ich jetzt, und dann hast du die App geladen.
Es ist einfach ein Ansatz, der sehr viel für die Entwicklung halt auch ändert.
Und da gibt's keinen DOM, da gibt's kein HTML, das endlos ist, sondern es gibt Views, und die sind nur so, die sind nur im Viewport auch da.
Und ansonsten müssen die Daten halt klug ausgetauscht werden.

[1:23:04] Aber ich, ja, da, ich bin halt leider auch, was heißt leider, aber da bin ich in meiner standardtäglichen Arbeit, bin ich fokussiert aufs Frontend und mach da die Dinge und dann versucht, die so gut wie möglich zu machen, dass ich dieses große Picture da nicht weiter durchdacht hab.
Aber es war so der Moment, als ich gelesen hab, wo ich mir dachte, also, ich weiß jetzt auch nicht, vielleicht müssen wir noch mal drüber nachdenken.
Und das machen ja die Framework-Hersteller, Herstellerinnen, machen ja genau diese Dinge, das noch mal zu überdenken.
Ähm, da hat sich jetzt in meinem Kopf so ein großes Ding eröffnet, Ich hatte ja jetzt einige Fragen eigentlich.
Vielleicht, wenn ihr hier auf den Konferenzen rumspringt und immer die großen, wichtigen Personen da habt, vielleicht wissen wir die, vielleicht sprechen sie kein Deutsch, aber doch mal hier auch ran schaffen, um mal so eine große Diskussionsrunde, ein großes Panel zu beginnen.

[1:24:04] Ich kann mir auch vorstellen, dass viele von diesen Framework-Autorinnen und Autoren das schon versuchen bestmöglich zu machen für das, was eben möglich ist.
Aber vielleicht haben die ja auch im Kopf und schon viel, viel weiter als ich, weil sie sich viel mehr damit beschäftigen als ich, dass es eigentlich, sollte man es vielleicht doch auch ganz anders machen.
Aber es gibt halt tausend Gründe, dass es jetzt nicht einfach so geht.
Also ich fände es jetzt natürlich selber auch unmöglich, mal kurz HTML abzuschaffen. Schon klar.
Aber mich würde ja schon sehr interessieren, was sie denken würden.
Wie würde man das Web heutzutage aufbauen, wenn man heute loslegen würde?
Und einfach mal so was zum neuen Browser rausbringen könnte.
Erinnert mich daran, dass ja Google tatsächlich vor zehn Jahren vorgehabt hat, Javascript abzulösen durch Dart. Das war ja tatsächlich so ein Drang.
Gutes Beispiel, ja. Und sind auf sehr viel Widerstand gestoßen. Ich bin gespannt, wenn sie heute so eine Aktion machen würden, wo quasi 99 Prozent aller Browser irgendwie Chromium basiert sind, Das war's schon wieder, oder?

[1:25:09] Ähm ... Das ist genau bei TypeScript, nur diesen Ding. Nee, wir finden das doch eher ein Feature von JavaScript, dass es eine Number sein kann, aber dann plötzlich ein String.
Das ist doch vielleicht gar nicht schlecht.
Ja, gut. Ich weiß nicht, wie es in aktuellen Umfragen aussehen würde.
Aber in meiner Erfahrung sind schon viele, viele, viele jetzt auf TypeScript.
Aber jetzt ist mir halt wieder auffällig.
Ich brauch so ein ESLint, das dann unfassbar langsam plötzlich wird.
Dann brauch ich ein Buildstep. irgendwie umwandeln. Dann hab ich aber immer noch keine Runtime-Texte drin, sondern eigentlich ja doch nur die Bildchecks.

[1:25:47] Und dann hab ich plötzlich wieder sowas wie Superstruct oder andere Hilfstools, die dann auch noch bei Runtime noch auf die Typen checken können, um dann an Sentry oder was auch immer zu schicken, oh, hier ist aber ein falscher Typ unterwegs.
Also brauch ich diesen ganzen Clutteradage und könnte ich das nicht einfach lieber ohne diesen ganzen Bildstep an den Browser liefern?
Vielleicht brauchen wir ein neues Wort für Browser dann.
Und das Ding ist klug genug, um sich drum zu kümmern. Und ich muss nicht erst TypeScript übersetzen und transfilieren.

[1:26:15] Siehst du, Vanessa, aber du hast jetzt mit dem gerade... Auch wenn ich mit meinem stark typisierten Hirn mir denke, manchmal ist was ein Number, manchmal ist was anders.
Das ist nicht mein Vorteil, den ich sehe. Aber einfach, so wie du das gerade erwähnt hast, vielleicht müssen wir uns auch einfach darüber nachdenken, ob nicht das, was wir jetzt verwenden, eigentlich eh gar nicht so schlecht ist.
Weil vielleicht kann man dann eh zufrieden sein damit. Ich finde es zum Beispiel total beruhigend, auch einfach mit, in meinem Fall war es jetzt einmal Eleventy oder Preact oder was auch immer, einfach das zu schreiben und am Ende des Tages, wenn man sich bemüht, kommt es eh sauber an.
Und das liegt wahrscheinlich in 98 Prozent der Fälle nicht an dem Tool an sich, sondern, dass man das misused aufgrund von 47 Millionen anderen Sachen, von Zeit, von Finanzen und so so weiter, dass man sich denkt, hey, ähm...
Verwenden wir mal das, was wir eh haben. Das ist jetzt der sehr konservative Ansatz.
Aber manchmal ist der total beruhigend.

[1:27:18] Man denkt so, es läuft eigentlich eh gut, wenn man es richtig macht. Ja klar, es stimmt.
Es ist auch ein guter Punkt. Und ich finde es ja auch faszinierend, was Browser alles im Endeffekt dann doch wieder.

[1:27:32] Herstellen können aus vielleicht eben nicht validen HTML, aus Schemantics und alles mal ignoriert, Accessibility ignoriert.
Aber du kannst ja wirklich Code schreiben und er wird in den meisten Fällen.

[1:27:50] Verbessert und optimiert.
Und ich kann die Sachen klicken und sehen und scrollen, obwohl da eigentlich ein paar Fehlerchen drin sind oder wo ich nicht alles optimieren musste.
Oder wenn ich jetzt eben drüber nachdenke Ich denke an ein Stack, also, ich weiß theoretisch, dass Event-Listener und Promise und Set-Timeouts, wann die jeweils irgendwo landen und wann die ausgeführt werden.
Aber ich muss mich auch überhaupt nicht drum kümmern.
Ich muss mich nicht wie in anderen Programmiersprachen um Threads kümmern, um Multithreading generell mal.
Ich kann zwar Serviceworker nutzen, aber ich muss es auch nicht ...
Es stimmt schon, es ist halt eben nicht kompliziert, zu shippen. Ich nehme jetzt zwei richtig böse Wörter im Mund, an die mich Quick am Anfang erinnert hat. Zum ersten war das JSF, also die Java Server Faces, und zum zweiten war das Oracle Apex. Hat mal von euch wer mit dem gearbeitet? Ich habe keine Worte mehr.

[1:29:04] Ja, vor allem, die letzten werde ich jetzt auch noch nehmen. Ich habe eigentlich beide Sachen ganz lässig gefunden. Das Apex, das ist, da hat man direkt aus seiner Datenbank, außer in so Oracle-Datenmärken vor, wenn ich jetzt nachdenke, das war bei mir auch vor 14 Jahren, 13 Jahre, hat man seine Cloud-Maske außergenerieren können. Und das Ding hat das JavaScript erzeugt, das es gebraucht hat und den Rest, was es halt gebraucht hat, ob es damals schon ein JavaScript oder ob das ein Roundtrip war, aber das Ding hat genauso funktioniert. Und bei GSF hat man dann auch schon die Komponenten gehabt, die genau das JavaScript mitgeschickt haben, das gebraucht haben für den Punkt.
Und das fühlt sich irgendwie so an, so ein...
Nicht jetzt der Server-Roundtrip, sondern ein Dekaden-Roundtrip. Ja, ja.
Das war der Friedrich Otte.

[1:29:53] Ich seh hier bei Oracle Apex, erstellen Sie Unternehmens-Apps 20-mal so schnell mit 100-fach geringem Kodierungsaufwand.
Mir fehlt hier jetzt noch so das Sternchen im Vergleich zu herkömmlichen Shampoos.
20-mal schneller als was mit 100-fach geringem was.
Von was ausgehend. Ja, vielleicht, es ist für mich so ein bisschen an der Zeit, dass man nicht nur einfach Frameworks bewirbt mit, sie sind das und das schneller und dadada und dadada, sondern vielleicht schafft man es tatsächlich auch mal in die Richtung zu gehen.
Was brauchst du? Dieses Framework war für dich das Beste. Was brauchst du? Also, vielleicht gibt's schon ...
Irgendjemand hat doch bestimmt schon mal so ein Klick-Tool implementiert, wo ich sagen kann, ich möchte das, das und das, und dann lande ich irgendwie bei, keine Ahnung, Angular oder Eleventy.
Das ist das Decision Tree.
Ja, weil es wird kompliziert. Es ist schon lang kompliziert.
Stell dir mal vor, du wirst heutzutage damit anfangen, WebDev zu werden.
Unmöglich, unmöglich. Ich bewundere jeden und jede, der das tut.

[1:30:59] Ich hab damals halt Seite speichern untergemacht und kopiert. Und dann gemerkt, oh, es gibt verschiedene Bildschirmkursen, funktioniert ja so gar nicht. Aber wird man jetzt überhaupt noch WebDev oder wird man jetzt ReactDev oder wird man jetzt QuickDev oder wird man jetzt, VueDev? Ich glaub, so speziell geht's noch nicht.
Weil dann kannst du ja dann, weiß ich nicht, so ein bisschen, ich glaub so in Richtung, Gruppierungen, Kategorien.
So diese Art Framework oder diese Art Framework?

[1:31:32] So eher so PTV und Alpine oder so Vue und React oder so Rust?
Gut, der Stefan hat wirklich keine Worte mehr.
Der schaut immer noch ein bisschen schockiert in die Kamera.
Nein, ich versuche eigentlich jetzt gedanklich schon ein bisschen einen positiven Spin zu finden, nachdem ich so viel geshootet und mich beschwert habe.
Tatsächlich ist ja das spannend, was da gerade passiert. Also auch wenn das jetzt so in der Richtung schon mal existiert hat und wenn ich nicht zu 100% überzeugt bin davon, dass die aktuellen Bewegungen irgendwie den.

[1:32:09] Richtigen Use-Case haben. Weil wie gesagt, in den Use-Cases, die ich denke, ist entweder sehr viel Javascript oder gar kein Javascript drinnen. Oder wenig. Ich glaube doch, eben wie du gesagt hast, dass die Entwicklung einfach auch passieren muss, dass das spannend ist, was sie sich für Gedanken machen und ich würde auch gerne mal so ein bisschen aufrufen, vielleicht von den Hörerinnen und Hörern, falls es da irgendwelche Quick-EnthusiastInnen gibt, bitte mal mir auf die Finger klopfen und sagen, Baumgartner, du hast absolut nicht recht, ich erkläre dir das jetzt mal und ich sage dir jetzt, warum das super ist und dann sage ich, ja cool, das ist wirklich super, geht das ohne Notschäß auch.
Und dann schauen wir, was rauskommt. Aber ich muss eh ganz ehrlich sagen, also wie gesagt, die letzten zweieinhalb Jahre Rust, die letzten drei Wochen Python, das Gras ist auf den anderen Seiten auch nicht grüner.
Ich bin prinzipiell jetzt verwirrt von Software.

[1:33:12] Ja, ich kann dir einen zweiten Karriereweg empfehlen, Stefan.
Das mache ich, wenn das Haus abbezahlt ist.
Dann gehe ich wieder studieren.
War das jetzt ein positives Bin?
Ja, vielleicht. Versteckt.

[1:33:31] Positiver wird es ja nicht. Muss ich nicht, für mich jetzt hier nicht.
Nein, also ich hab ja heute auch viel gebrabbelt, wo ich mir auch schon denke, da könnte vielleicht auch etwas Widerstand ankommen.
Ich will, ich wollt's auch bewusst mal hart hinterfragen, was wir hier machen, bevor ich auf den nächsten Halbzug aufspringe.
Ähm, die Entwicklung find ich superinteressant. Und dass es vielleicht hinterfragt wird.
Ich frag mich nur, wie lange das so weitergeht. Vielleicht geht's auch einfach immer so weiter.
Vielleicht bin ich nur an dem Punkt in meinem Leben, wo ich verstanden hab, es wird immer weiter optimiert.
Es kommen immer neue Anforderungen dazu, weil als Nächstes müssen wir Chips in unseren ...
Ihr wisst schon, auf lange Sicht gesehen, und es wird sich halt nicht ändern, und es ist auch schon seit 30 Jahren so, nur mir fällt's plötzlich einfach mal wie Schuppen von den Augen, was andere Leute schon seit 30 Jahren wissen.
Und dann wieder Stefan sagen können, ja, das gab's doch alle schon mal.
Ja, also von daher, ich lass mich auch super gerne umstimmen, dass Quick vielleicht das nächste Ding ist.
Bin jetzt einfach nur ... auch ein bisschen ...
Ich würd einfach nur gerne wissen, wo sind da dann die Probleme?
Weil es wird sie irgendwo wieder geben, die ...

[1:34:45] Die halt einfach ganz standardmäßig auch da sind, wenn ich eine große Webseite habe und keine Ahnung, eine Codebase von was weiß ich, wie vielen Personen pro Tag, die da rumhampeln und Daten haben wollen und Videos und mit der AI sprechen und allem Möglichen.
Tja...

[1:35:02] AI. Also jetzt hören wir auf zu sprechen. Ich bin ja ein ganz großer AI-Freund.
Ich wollte jetzt nur nicht damit anfangen, weil wir sind jetzt bei einer Stunde irgendwas und sonst kommen wir bei fünf Stunden.
Sechs, acht. Sonst kommt der Peter noch dazu und der Hans und dann geht es erst richtig los.

[1:35:26] Du hast das sehr schön zusammengefasst. Ich wollte dir das eher sagen, Vanessa, vielleicht ist es auch nur so, der Zeit erkennt, es ergibt sich vieles wieder und es kommt einmal der Punkt, wo man das erkennt.
Das wollte ich gerade noch sagen. Das ist, glaube ich, auch für mich jetzt eine sehr schöne Erkenntnis des Ganzen, die das Ganze besser einordnen lässt. Damit, glaube ich, gebe ich zurück ins Studio nach Freising. Dann machen wir an dieser Stelle den Deckel drauf. Ich bedanke mich ganz toll bei euch beiden. Es hat mir sehr viel Spaß gemacht. Ich freue mich wahnsinnig auf jedes Feedback aus der Community, entweder bei uns im Slack Working Draft, Community Draft, Slack Channel oder über Social Media Plattformen. Wir freuen uns auch über Sternchen, damit wir gefunden werden. Wir bedanken uns alle, die jetzt gerade immer noch zuhören. Das finden wir spitze.
Schreibt uns auch gerne, falls ihr da mitreden möchtet und nicht einfach nur eine E-Mail schreiben wollt, sondern auch wirklich mitdiskutieren wollt, damit ihr uns mal erzählt, wie es denn tatsächlich wirklich funktioniert. Kommt doch gerne als richtige Experten-Expertin vorbei.
Und dann freuen wir uns aufs nächste Mal und bis bald. Tschüss. Dankeschön.

[1:36:44] Music.