Qwik mit Fabian Hiller

Hallo und herzlich willkommen zu einer neuen Programmier.bar Folge, einem Deep Dive zu Quick auf der Couch neben mir. Der Sebi Hai. Und unser Gast, den wir heute haben, brauchen wir eigentlich kaum noch vorstellen. So häufig jetzt schon zu Deep Daves hier gewesen. Fabian Hiller. Hallo Fabian, schön, dass du wieder da bist. Vielen Dank für die, die dich noch nicht kennen. Also einige Folgen. Eigene Details hast du ja schon in der Programmier.bar abgeliefert. Das war auch glaube ich, der Bezugspunkt. Warum du dann mal da warst und die Programmier.bar Webseite im aktuellen Status größtenteils gebaut hast. Und ja, gestern Abend hatten wir gemeinsam Meetup zusammen, wo es im Doppel Vortrag über. Unsere Gäste also. Für uns gestern. Ach so, ja für euch ist ja schon ewig her diese Folge hier online geht. Vor langer Zeit. Langer Zeit hat mir zu solide ES und Quick Doppelvortrag Und jetzt gibt es ja schon ein Deep Dive. Genau. Und heute machen wir dann das Pendant dazu über Quick Quick. Ein Satz Was ist Quick. Quick is not node JavaScript Frameworks, weil es von Grund auf anders funktioniert. Aber das gleiche Ziel hat. Genau. Es hat ähnliche Ziele wie als die großen Frameworks, die man so kennt, versucht aber ein paar Dinge anders und vielleicht auch besser zu machen. Und was vielleicht wichtig ist. Die meisten, also die also viele der letzten Entwicklungen, waren vor allem auf die Ex fokussiert. Zum Beispiel sobald man schreibt nur noch eine Variable anstatt irgendwie eine Hook oder so und dann macht es der Compiler das reaktiv, das heißt man reduziert den Code aufs Minimum, zum Beispiel. Für alle. Da draußen. Developer Experience Developer Experience. Und Quick hat auf jeden Fall Fokus auf Performance. Das ist auch so der Hintergrund, warum es Quick gibt. Und warum es wahrscheinlich auch quick heißt smarten Marketingmänner. Es hatte mal einen anderen Namen, aber ich weiß gar nicht was. Also auf jeden Fall Krieg ist besser. Alles klar. Also Konkurrenz, Nur um es mal zu nennen, wo wir uns heute befinden React.js solche Frameworks, wo es viele gibt und dort eine Alternative, die ist nicht so Sebi. Ich hätte jetzt eher Next Next Astro als Konkurrenz. Im Grunde sind beide Konkurrenz, weil bei den aktuell großen Frameworks ist es ja so, da gibt es, sage ich mal, dann die Library zum Bauen der Benutzeroberfläche und dann gibt es halt die Meta Frameworks obendrauf obendrauf und Quick bietet halt beides. Bringt halt beides Out of quick City. Genau. Ja, Okay. Ah, verstehe. Ja, cool. Dann aber ist wirklich eins. Oder ist es auch irgendwie getrennt und man kann beide Komponenten dazunehmen? Also, es sind getrennte Imports. Du kannst auch nur, sage ich mal, deine App mit Quick rendern, ohne dass du das Routing und alles. Du kannst auch dein eigenes Meta Framework draufsetzen. Genau. Also am Ende glaube ich, war das auch gar nicht so alles geplant, dass da jetzt ein komplett neues Framework entsteht. Miscore, der Kopf hinter Quick neben Manu und Adam hatte auch nicht vor, ein neues Framework zu bauen. Er wollte eigentlich versuchen. Ich glaube sogar in React die Ideen mit einzubringen, hat aber dann im Research gemerkt es geht gar nicht so einfach, weil die Annahmen, die seine Ideen voraussetzen, nicht mit den aktuellen Frameworks kompatibel sind. Und ich glaube, auch sie hatten gar nicht vor, dann Quick City zu bauen. Aber es hat sich dann halt ergeben, dass die das Fundament von Quick schon so gut ist, dass es gar nicht viel Aufwand war, Quick City noch oben zu packen. Ich glaube, auch der Quick City Code meinte mit dem letzten Mal, das kann sich auch mittlerweile schon wieder ein bisschen geändert haben. Ist auch nur irgendwie so vier Kilobyte oder so, also auch nicht allzu viel. Okay, jetzt hast du gerade schon so ein paar Namen gedroppt von Leuten, die das machen. Vielleicht kannst du da noch mal zwei Worte zu sagen. Wäre so ein bisschen Background zu quick Und wer macht das genau? Die Domain ist ja irgendwie auch nicht einfach nur quick. Ja. Komm oder dev oder io oder was auch immer, sondern quick .io, also das irgendwas anderes noch mit verbandelt. Ja. Also hinter Quick steht vor allem erstmal Misco. Er ist auch der Kopf hinter Angular. Er hatte Angular cs und auch Angular erfunden und geschrieben. War demnach auch eine Zeit lang bei Google und hat dort das Framework weiterentwickelt. Und er hat auch soweit ich weiß, die initiale Idee für hat den initialen Research betrieben und hat sich dann mit bilder.io zusammengetan. Bilder.io ist ein visuelles Headless CMS. Das ist im Grunde jetzt die Company, die hinter Quick steht und halt das ganze Finanzielle macht. Und mit im Team sind neben Cisco auch noch Manu und Adam und Manuel Adam sind aus, sind ehemalig aus dem Team von Ionic und haben dort vor allem auch an Stencil gearbeitet. Das ist ein Open Source Projekt im Ionic bereich. Das heißt, wir haben hier jetzt kann man schon sagen, ein richtiges Dreamteam, die Quick nach vorne pushen. Und das merkt man auch als Quick. Der erste Commit auf GitHub ist ungefähr zwei Jahre alt und wir sind seit Mai in V1, haben also unser erstes stabiles Release. Und ja, es geht auf jeden Fall schnell nach vorne. Okay. Macht es Sinn an der Stelle kurz über bilder.io zu sprechen? Also allzu viel kann ich dazu gar nicht sagen, weil ich Bilder auch nicht noch nicht benutzt habe. Aber im Grunde ist es halt ein visuelles Headless CMS und es wird vor allem viel im eCommerce auch benutzt. Und das sieht man vielleicht auch so ein bisschen, warum Quick Sinn macht in Kombination mit Bilder.io, weil Quick extrem gut in der Start up Time ist, was im eCommerce sehr gefragt ist. Okay, ganz kurz abbiegen und ein visuelles Headless CMS ist. Das heißt das im Grunde Headless CMS. Das heißt, dein CMS CMS ist getrennt von deiner UI. Ja, und der visuelle Part ist, du kannst im Grunde an bestimmten Stellen so eine Art Drag and Drop Editor mit einbauen, wo du dann halt über dein CMS etwas Feingranulare, den Aufbau und auch das Design bestimmen kannst. Das heißt aber, ist nicht. Das Design immer irgendwie stark abhängig von dem Frontend, was ich eigentlich baue? Genau das ist halt so der Trick dabei Wenn man ein normales Headless CMS nutzt, dann hat man ja das Problem, dass sage ich mal, das Marketingteam dauernd um die Ecke kommen mit neuen Ideen und jetzt muss das irgendwie zwei Pixel größer, das muss eine andere Farbe haben und dann müssen die Developer das dauernd anpassen. Oder alternativ sie müssen irgendwie die Infos ins CMS packen und dann irgendwie auslesen. Aber das führt dann halt zu Spaghetti Code und Bilder. Bietet halt mit dem visuellen Editor genau da eine Lösung. Ich kann jetzt nicht aus der eigenen Erfahrung berichten, aber man kann im Grunde seine Komponenten an Bilder anstöpseln und hat dann so eine Art Baukastensystem, das aber dann auf den eigenen Komponenten basiert, wo man dann recht frei die Website gestalten kann. Und dadurch können halt die Entwickler das einmal aufsetzen und das Marketing Team kann dann halt tun und lassen was es möchte. Okay. Also hätte ich so ein bisschen in Klammern geschrieben. Genau. Und man kann halt das coole hier. Man kann halt als Entwickler und Entwickler in jedes Framework mit sich bringen. Also das kann dann alles eingestöpselt werden. Aber besonders gut lässt es sich ein Quick anstupsen. Genau, was vielleicht am Anfang noch so ein bisschen Sinn macht. Wie komme ich denn eigentlich zu Quick, dass man da den Background auch versteht? Ich habe Quick zum Ersten Mal in einem Studentenprojekt im letzten Semester verwendet. Wir hatten so einen Social Media um Jokes herum gebaut, haben das an so eine Jokes API angeschlossen und es war so mein erster Touchpoint. Ich fand so die Gedanken interessant. Also Quick versucht zum Beispiel alles lazy zu laden und lazy auszuführen, also alles verzögert zu laden, verzögert auszuführen und versucht halt JavaScript möglichst zu reduzieren. Und zu dem Zeitpunkt, als ich dann auch mal Quick ausprobiert hatte, hatte ich mich vor allem stark in solid.js eingearbeitet, wo ja auch die Bundles heißen. Pro Argument war und ich fand die Gedanken von Guy gespannt und dachte, so einem Studentenprojekt kann man das mal ausprobieren. Und das war dann auch der Zeitraum, wo ich Modular Forms for Solid entwickelt hatte und Modular Forms. Also die Reaktivität meiner Formularbibliothek baut vor allem auf Signals und da Quick auch auf Signals basiert, also der Zustand wird auch über Signals definiert. Hatte ich einfach mal in den Quick Discord geschrieben. Ich könnte mir vorstellen, vielleicht meine Library auch für euch zu schreiben. Und dann Irgendwie hat sich das alles so ein bisschen zufällig ergeben. Ich weiß nicht. Irgendwie hat entweder MySQL mich geerdet als Freund oder. Irgendwie auf jeden Fall. Dann haben wir uns so zugewunken bei Discord. Also wir wo Discord nutzen kann das und irgendwie also das war gar nicht so bewusst irgendwie. Es hat sich einfach ergeben und dann hat Misco mich mit den anderen Kormborn in eine Gruppe gepackt und ich hatte dann auch einen Call mit MySQL, wo ich so ein paar Sachen durchgequatscht hab. Ich hatte zuvor schon mal so die ersten Tests gemacht, um zu gucken Funktioniert denn meine Form Library für Quick? Und tatsächlich musste ich bestimmte Dinge anders machen, damit das Ganze als serialisiert werden kann. Weil zuvor war viel Runtime passiert und bei Quick musste man halt ein paar Sachen anders machen und so hat sich halt letztendlich der Kontakt ergeben. Und mittlerweile ist meine Formbibliothek tatsächlich meines Wissens nach den wöchentlichen Downloads das beliebteste Projekt, das aktuell auf QC aufbaut. Genau das ist so meine Verbindung zu Quick und deshalb hoffe ich doch auch, dass ich ein gutes und tiefes Verständnis für das Framework hab und euch heute hier ein paar Einblicke bieten kann. Sehr gut, dann schieß los, oder? Ja. Ich denke also bei Solid sind wir ja recht schnell, sage ich mal direkt mit Solid gestartet. Heute möchte ich mal ein bisschen anders vorgehen. Ich denke, es ist wichtig zu verstehen, was macht denn Quick so anders? Und deshalb kann es Sinn machen, erstmal einen Blick auf die aktuellen großen Frameworks zu werfen und auf zwei Probleme die die so haben. Und dann schauen wir uns mal an, wie Quick das vielleicht lösen kann. Und zwar das erste, was wir uns anschauen ist wie rendern denn die aktuellen Frameworks wie ReactIF und Co letztendlich die Website? Und standardmäßig schickt React zum Beispiel einfach ein leeres HTML Dokument an den Browser. Da ist vielleicht ein leeres Diff drin mit Neid und dann ist noch ein Script Tag eingebunden. Das Script lädt dann des Framework und unseren eigenen Code und sobald dann alles im Browser angekommen ist, wird es dann ausgeführt und reactlet dann letztendlich die Anwendung in unser HTML Dokument rein. Das heißt aber auch, wenn wir zum Beispiel noch Data Fasching ing machen, dass wir erst mal eine ganze Zeit lang vor allem bei schlechtem Internet eine leere Seite sehen und vielleicht ein paar Spinner. Und das ist nicht das optimale Benutzerlebnis. Und des Weiteren bringt es auch Probleme mit, was SEO und Websing betrifft, weil am Anfang wird ja initial eine leere Seite geschickt, da gibt es noch keinen Inhalt. Und die Lösung dafür der aktuellen Frameworks ist, dass man Prerendering betreibt, das heißt durch Serverside Rendering oder durch statische Generierung rendert man einfach das HTML des Initial angezeigt wird im Vorhinein und schickt das fertige HTML mit dem Inhalt plus natürlich auch dem Script zum Laden des Frameworks an den Browser. Und der Browser hat dann den Vorteil, dass er direkt den Inhalt darstellen kann. Was allerdings nicht funktioniert, wenn wir irgendwo hin klicken, dann passiert nichts. Ich denke, die einen oder anderen kennen das vor allem am Smartphone. Ihr öffnet eine Website, wollt direkt auf das Bürger icon klicken und es passiert einfach nichts. Und der Grund, warum da nichts passiert ist. Zu dem Zeitpunkt gibt es nur das HTML mit keine Informationen über Interaktivität. Das heißt es gibt auch keine Event Listener und keine Eventhändler, weil die befinden sich ja in unserem JavaScript Code des HTML weiß davon nichts. Bedeutet wenn dann unsere Webseite angezeigt wird, wird dann das Framework geladen. Das wird ausgeführt und bei dem Initial Client seitigen Rendervorgang wird dann der Zustand wiederhergestellt und die Event Listener werden an die DOM Notes angeheftet. Und das ist der Schritt, den man unter Hydration kennt. Oder Icon. Irgendwas kann's nicht aussprechen. Und was wir jetzt hier sehen, ist derselbe Code muss zweimal ausgeführt werden, bis unsere Website dann wirklich nutzbar ist. Das heißt, wir führen unsere Anwendung komplett auf dem Server aus für das Pre Rendering und wir führen es dann noch mal clientseitig aus. Und das ist halt eigentlich so ein bisschen ein Overhead. Ich verstehe, dass es auf dem Server gerendert wird und dann das komplette HTML ausgeliefert wird und dann die JS Funktionalitäten noch dazukommen. Was ist der zweite Schritt, Dass es dann im Browser noch mal komplett gerendert wird oder die auch die Inhalte? Du meinst. Die Downloads werden da nicht überschrieben. Die sind ja bereits da. Im Grunde wird halt nochmal die komplette Anwendung ausgeführt, weil die aktuellen Frameworks top down laufen müssen, also von oben nach unten. Und in dem Schritt wird zum einen der Zustand hergestellt. Und da ist auch wichtig, dass der initiale Zustand, der beim Serverside Rendering existierte, auch der gleiche ist, der dann Client seitig existiert. Sonst gibt es so einen Mismatch. Ich denke die wo drin sind, die kennen das. Dann gibt es auch einen Fehler in der Konsole usw und in dem Schritt wird halt wie gesagt der Zustand hergestellt plus dann auch die Eventliste nur angeheftet, weil ohne das funktioniert halt nichts. Ohne das gibt es keine Interaktivität, weil ohne den Zustand weiß er das Framework nicht, wann zum Beispiel der Counter auf eins oder zwei zählen muss. Und ohne Eventhändler passiert erst gar nix, weil dann der Counter auch nicht hochgezählt wird. Also bleiben wir bei einem Counter. Beispiel sind. Genau. Wir haben jetzt eine zweifache Ausführung. Und was wir auch haben, was man vielleicht nicht auf dem ersten Blick erkennt. Wir übertragen den Inhalt doppelt. Der Inhalt wird hier einmal per HTML an den Browser geschickt und der komplette Inhalt befindet sich ja auch noch mal in unserem JavaScript Code. Das heißt, wir schicken da im Grunde alles oder Großteil einfach doppelt rüber. Das heißt, das sind so die zwei Overheads, die Hydration, das Vorgehen der aktuellen Frameworks mit sich bringt. Und ist das auch der STANDARD oder gibt es da in den großen Sachen irgendwie ein irgendwas, was das verhindert? Was machen die Eilands genau? Also es gibt alternative Wege. Es gibt zum Beispiel Eilands, bekannt durch Astro und Astro, versucht folgendes Anstatt die komplette Website zu hitrieren, gibt es einfach kleine interaktive Eilands und nur die werden hier das heißt auch nur der Code dieser Eilands wird benötigt. Das hat den Vorteil, dass auch nicht der gesamte Code heruntergeladen werden muss, der ganze Code angepasst werden muss, sondern nur der Bereich, der auch wirklich interaktiv ist. Allerdings bringt die Island Architektur auch so ein paar Problemchen mit sich, weil zum Beispiel. Es macht es schwierig Zustand zwischen den Eilands zu scheren, also zum Beispiel Global State. Ich muss sagen, ich habe mit Island nicht gearbeitet, kann da auch nicht ins Detail gehen. Aber ich habe zumindest in Vorträgen gehört und gesehen, dass es da halt dann auch einfach Probleme gibt und das vielleicht nicht die finale Lösung ist. Ich bin vielleicht zu weit weg aus der Entwicklung, aber trotzdem ist mir das nicht ganz klar, wieso alle Daten nochmal in dem JavaScript Ding drin sind. Also das Ding ist ja, Grundsätzlich befindet sich ja deine ganze Anwendung im JavaScript, deine ganzen Komponente und alles drum und dran. Ist ja im JavaScript in sag ich mal deinem Code, dass du mit Preact, mit IF, mit Angular schreibst. Und dieser Code wird ja serverseitig benutzt um dann das HTML zu generieren und dann schickst du ja das HTML an den Browser und der gesamte das gesamte Framework Code für die jeweilige Seite muss halt dann im Browser nochmal ausgeführt werden, weil Preact und Co sind halt so gebaut, dass die von oben nach unten ablaufen müssen Preact Das sind am Ende Komponente, die man schachtelt. Eine Komponente ist am Ende eine Funktion und am Ende hat man halt einen Baum von Komponenten, das heißt eine Funktion ruft eine Funktion auf und ruft eine Funktion auf usw und da kann man keinen Code Splitting betreiben, weil das von oben nach unten durchläuft. Ja, okay, aber es ist von der von der absoluten Größe ist der erste Platte wahrscheinlich deutlich kleiner, oder? Also weil wir, wenn wir sagen alle Daten doppelt, dann ist ja trotzdem irgendwie wenn ich die fertige HTML Seite habe, sind das jetzt in Anführungsstrichen nur. Die. HTML Komponenten und die Inhalte und Texte und keine Ahnung, was die da drin stehen. Aber der größere Part, das ist wahrscheinlich denn das JavaScript und es kommt alles, was da drauf ist. Das kommt tatsächlich auf deine Anwendung an, Wenn du jetzt eine Website hast mit viel Inhalt, aber wenig Interaktivität und der Inhalt kommt vielleicht von der Datenbank, dann legt er gar nicht mehr JavaScript Code. Dann kann es aber trotzdem sein, dass dein HTML riesig ist. Und wenn du jetzt aber eine Website hast, die vielleicht gar nicht so viel Inhalt anzeigt, aber super viel Funktionalität hat, wo man vielleicht irgendwie einen Texteditor hat oder so, dann ist vermutlich das HTML deutlich kleiner als dann die der JavaScript Code, der benötigt wird, um die ganze Interaktivität von komplexen UI abzubilden. Okay, also irgendwas doppelt. Genau. Und der optimale Zustand. Das ist immer das Doppelte. Da fragt man sich, warum haben die also? Da hätte man ja von vornherein dran denken können, dass es eine doofe Idee ist. Aber da muss man halt auch die Historie betrachten. Deshalb habe ich ja auch angesprochen, dass das initiale Vorgehen halt einfach Spa war, das heißt Single Page Application ohne irgendwie Serverside Rendering. Das hat man dann erst dazu gepackt. Das heißt also eigentlich erstmal eine leere Webseite, also eine leere HTML Seite rausschicken, genau das füllen und haben dann festgestellt, das ist doof und langsam. Hat einfach irgendwie historische Gründe. So hat sich das halt ergeben. Und sowas wie Preact und vor allem auch Angular wurde ja auch vor allem anfangs und wird auch heute noch super viel oder großteils auch für irgendwelche Adminuis benutzt oder irgendwelche Sachen hinter einem Login. Da interessiert ein Rendering auch nicht unbedingt. Das kam halt dann, wo man das auch angefangen hat, vor allem für normale Websites, Blogs, Onlineshops zu nutzen, wo man einfach sonst so Nachteile hätte und auch Nachteile in der Benutzererfahrung. Okay, aber wir haben ja jetzt zum Glück Quick. Ja, also der Optimalzustand, um da jetzt noch mal zurückzukommen, wäre ja eigentlich der Server rendert unsere Website passiert. So gesehen dann die Applikation schickt sie an den Browser und der Browser kann halt direkt den Inhalt darstellen plus von dort aus die Ausführung fortsetzen, sodass wir halt direkt interaktiv sind und nicht noch warten müssen, bis JavaScript herunterladen heruntergeladen st und ausgeführt wird. Und dann schauen wir uns noch ein zweites Problem an, das die aktuellen Frameworks mit sich bringen. Und zwar ist das die Bundles heiß. Wie eben schon angesprochen. Um interaktiv zu sein, benötigt Preact View und Co wirklich den gesamten Code einer Seite, weil der halt komplett ausgeführt werden muss im Browser. Bedeutet das die Start up Time mit steigender Funktionalität und gleichzeitig mit mehr Code immer schlechter wird. Und wir hatten jetzt bei dem Vortrag eine Grafik gesehen, die hat gezeigt, wie sich so die Entwicklung von der Bundesvize und JavaScript über die Jahre verändert hat bei unseren Websites. Und da ist halt klar der Trend zu sehen, dass unsere Website immer mehr JavaScript enthalten, weil unsere Websites werden immer interaktiver und haben immer mehr Features und Funktionen. Und es führt halt, wenn man so Frameworks wie ReactIF und Co nutzt, einfach zu mehr JavaScript. Und da der gesamte Code benötigt wird, verlangsamt das automatisch den Start up Prozess im Browser. Das heißt der Zeitpunkt, wo man halt den Request sendet, bis die Seite dann interaktiv ist und man sie dann im Grunde nutzen kann und auch verschiedene Tests bezogen, vor allem auf den Lighthouse Score, haben gezeigt, dass JavaScript bei vielen Websites mit das größte Bottleneck ist, weil das Herunterladen des Paars und das Ausführen den Manfred blockiert. Bedeutet, während das ganze Zeug im Hintergrund passiert, Ist die Website nicht möglich oder kann die Webseite auf nichts anderes reagieren? Das magister einem MacBook Pro vielleicht nicht so negativ auffallen, aber bei mobilen Geräten, da kann es auf jeden Fall ins Gewicht fallen. Wie schon mal gesagt, jeder kennt es vermutlich. Man öffnet eine Website, drückt irgendwo drauf und es passiert einfach gar nichts. Fun Fact Ich glaube, Google hat dieses Jahr auf der Googleio angekündigt, dass sie dieses Tool Time to Inter Activity im Lighthouse Score hoch pumpen, so dass es noch wichtiger wird. Also erst wenn ich wirklich interagieren kann mit der Webseite, dann ist es cool, wenn ich das schnell kann, weil dann kriege ich einen besseren Lightroom. Oh ja, und tatsächlich gibt es auch eine Formel, wo man so ein bisschen die Bundles als berechnen kann von den bisherigen Frameworks. Und zwar lautet die Formel Wenn man das jetzt mal mathematisch aufarbeitet Y gleich mal fix plus B, also auf Deutsch übersetzt Die Bundle Size berechnet sich durch ein Multiplayer mal dem eigenen Code plus einer fixen Größe. Das ist natürlich jetzt pauschalisiert. Also worauf ich hinaus möchte Jedes Framework kommt ja mit einer fixen Größe. Aktuell sind wir so bei 40 Kilobyte solid.js glaube ich so um die acht Kilobyte. Das heißt das hat man initial drin. Und wenn man mal das durchrechnet mit Komponenten, also zum Beispiel von null bis oder von einer, man braucht mindestens eine Komponente bis zum Beispiel 80, dann ist zum Beispiel initial bei einer Komponente world der Gewinner, weil es generiert ja ein Großteil des Codes und ist dann natürlich am kleinsten mit so grob vier Kilobyte. Und wenn dann weitere Komponenten dazukommen, wachsen die Frameworks ganz grob linear und irgendwann. Ich glaube 80 Komponenten war dann das World bei 150 Kilobyte und die Gewinner waren Preact und solid und war das noch viel? Ich bin mir nicht ganz sicher mit so um die 100 Kilobyte, das heißt man sieht da schon einen krassen krassen Unterschied. Aber worauf ich hinaus möchte die bisherigen Frameworks, die wachsen mit jedem Code und daran ist auch nichts nicht zu drehen. Der Optimalzustand. Ganz kurz unterbrechen sebi y plus b. Lineare Funktion und. Geraden, geraden Gleichungen. Weitermachen. Also die bisherigen Frameworks, die wachsen einfach linear und daran ist auch nicht nichts zu tun. Und eigentlich wäre ja der Optimalzustand. Oh oh, sorry. Und zwar gibt es eine. Gibt es die Big IoT ations? Das ist auch irgendwie so eine mathematische Formel Geschichte, die beschreibt, wie sich Sachen verändern über den Zeitraum. Und perfekt wäre ja, wenn das sage ich mal, eine gerade Linie wäre. Das heißt, wir können als Entwickler Features Funktionen hinzufügen, aber die Start up Time bleibt immer gleich, weil initial wird immer dieselbe Menge an JavaScript benötigt. So, das sind jetzt so die ganzen Gedanken, die hinter sich sprechen. Ich weiß es, weil es viel Vorarbeit, aber ich glaube, jetzt haben wir die zwei Painpoints der aktuellen Frameworks ausreichend behandelt und können mal ein bisschen einen Blick auf Quick werfen. Von Quick. Von eins von was ist das gerade jetzt gerade ist. Das ist gerade Notation. Äh. Oh. Oh. Ach, gerade eins, oder? Das hatten wir doch auch gerade gesagt. Hat er das gesagt? Ja. Na dann. Weiter. Sebi passt auf. Sehr gut. Wir haben ja schon so. Eine Autowebseite gehabt. Wir haben ja schon so die allgemeinen Infos ein bisschen abgearbeitet. Das heißt Kurti und Io, was vielleicht noch zu Beginn wichtig ist, wenn wir jetzt ein Quick reingehen, wo steht Quick aktuell? Ich habe ja bereits angesprochen, wir sind in V1, haben ein stabiles Release. Quick steht im Moment bei so grob 11.000 wöchentlichen Downloads bei bei Npm und bei fast 20.000 Sterne bei GitHub. Das heißt, das Projekt ist auf jeden Fall stark am Wachsen. Ich denke vor allem jetzt über die nächsten Monate hinweg, weil ja gerade auch so die Hochzeit der Konferenzen ist. Wird Quick noch mal einen guten Push erhalten, allein durch diesen Podcast? Ja, allein durch diesen Podcast. Und ich denke, man kann schon darauf davon ausgehen, dass wenn die Entwicklung so weitergeht, Get Quick dann auch eines Tages vielleicht zu den Großen mit dazu gezählt werden kann. Ich würde es als erstes einen Blick auf die Ziele werfen von Quick. Wichtig ist da auch anzusprechen, dass Quick an sich erst mal ein Allgemeines, einen General Purpose Web Framework ist. Das heißt, wir hatten ja zum Beispiel bei. Shopify das Framework. Wie heißt es High Hydro oder so? Zum Beispiel. Und da war zum Beispiel so ein bisschen Fokus auf eCommerce und so ein paar Sachen. Also es gibt ja Frameworks, die so ein bisschen auf was spezialisiert sind, zum Beispiel Astro auf die Multi Page Applications. Und wichtig ist, dass Quick ein allgemeines Rap Framework ist, das sich im Grunde für jede Art von Webanwendung eignet. Das kann eine Single Page Application sein, das kann ein Multi Page Application sein. Das kann eine Website sein mit Serverside Rendering oder auch mit statischer Generierung. Und ein wichtiges Ziel von Quick ist eine automatische Optimierung auf Performance. Es gibt in Quick keine Performance Hooks wie in React. Es gibt keinen Grund, dass der Entwickler sich Gedanken machen muss um Performance, Dass der Entwickler bewusst den Code so schreibt, damit dann die Anwendung möglichst performant läuft und erreichen will, dass Quick vor allem bei der Start up Time durch Wiederaufnahmbarkeit auf Englisch resable oder resume ability und durch direkte Interaktivität auf Englisch instanton. Und das mit etwa ein Kilobyte JavaScript, das immer gleich bleibt, unabhängig von Größe und von Komplexität der eigenen Anwendung. Und dann kommt noch ein Spiel, Das Quick versucht alles verzögert und im besten Fall auch noch im Hintergrund. Das heißt nicht über den Manfred herunterzuladen und dann auch immer nur den JavaScript Code auszuführen, der für die jeweilige Aktion erforderlich ist. Und Quick setzt sich am Ende so grob aus sechs Bestandteilen zusammen. Wir haben den ersten Touchpoint, den man als Entwickler hat. Das ist die CLI. Das heißt, Quick kommt mit einer CLI. Damit kann man eine eigene App erstellen. Und was cool ist die Kelly kann dir auch so was wie Tailwind mit reinpacken und es geht auch im Nachhinein. Das heißt man hat da eine super Anbindung an Dinge wie Tailwind oder wie Test oder was es da noch so alles gibt. Das heißt, es ist super einfach für uns als Entwickler. Wir müssen uns da keine Dokumentation durchlesen, wir geben nur den Command ein und lassen die dies hier den Rest machen. Und Modular Forms kann man auch einfach einbinden, oder? Ja, aber. Da gibt es noch. Keine Zielanbindung. Aber ich glaube, die braucht man auch nicht unbedingt. Okay. Und dann kommen wir zum Zweiten Bestandteil. Das ist die komponentenbasierte UI Library inklusive Statemanagement. Das heißt im Grunde die Runtime von Quick. Dann kommt der dritte Part des ist das DOM Rendering, das heißt eine Dombibliothek, die JAX dann am Ende in HTML umwandelt. Der vierte Bestandteil ist der Optimizer. Und das ist im Grunde ein Compiler, der zur Bildzeit den eigenen Code in kleine Chunks zerbrechen kann und das auf einer sehr granularen Ebene. Das heißt, es können nicht nur Komponenten gesplittet werden, sondern es können auch die Eventhandler in unseren Komponenten von der Komponente gesplittet werden. Das heißt, es ist zum Beispiel möglich, in bestimmten Fällen, wo keine feingranulare Reaktivität anwenden kann, ohne das Template erneut auszuführen, dass wirklich nur der Eventhändler benötigt wird, ohne die Komponente selbst zu laden. Und dann haben wir noch den fünften Bestandteil Es ist der Code. Oder wenn wir gerade schon gehört Quick benötigt ein Kilobyte JavaScript initial und das ist der Quickloader und der Quickloader ist dafür da, um sobald dann das HTML im Browser ankommt, globale Event Listener zu platzieren und im Hintergrund verzögert JavaScript feingranular herunterzuladen. Und jetzt noch zu dem letzten Baustein und das hattest du schon angesprochen. Das ist cool City. Das ist im Grunde des Meta Framework und Top of Quick, was verantwortlich ist für Layouts, Routing, Data Fact, Checking Actions usw. Das heißt, mit den Bestandteilen hat man schon mal so eine grobe Übersicht. Was bringt Quick alles mit und was ist vielleicht da auch so ein bisschen unique? Meinst du mit Data featuring dann für Serverside Rendering? Ja okay. Und halt auch Quick ist am Ende auch ein Full Stack Framework und bietet eine super einfache Kommunikation zwischen Client und Server. Das heißt, du kannst diese Loader von QuickCity entweder nutzen, um bei Serverside Rendering die Daten direkt in das Dokument zu laden. Du kannst es aber auch nutzen, um bei der clientseitigen Navigation dann Daten von deinem Backend abzurufen und du musst dich da sage ich mal um nichts kümmern. Du musst da kein Feature oder so schreiben, das macht im Grunde alles quick fertig. Es muss keine API in Points anlegen. Und das bringt auch den Vorteil mit, dass wir in Quick eine vollumfängliche Typsicherheit bekommen, weil wir erstellen, sage ich mal unseren Roadloader und nutzen den als Hook dann in unserer Komponente. Und dadurch haben wir halt automatisch eine Typsicherheit und die ist ja unterbrochen, wenn wir unser Backend komplett vom Frontend trennen, weil dann müssen wir händisch irgendwie sagen, gut, das ist jetzt der Datensatz mit der Typisierung und das ist natürlich einfach eine super Entwicklungserfahrung, das so mit drin zu haben. Dazu habe ich auch einen kleinen kleine Sideinfo. Ich meine, Firebase hätte dieses Jahr angekündigt, dass sie Atomic Deployce anbieten, was ja die Voraussetzung dafür ist, dass das funktioniert. Und zwar Atomic Fir Firebase Hosting und Firebase Cloud Functions, so dass man Backend und Frontend atomar umschalten kann auf die neue Version. Das ist ja essenziell für den Ansatz von Quick, dass das Backend nicht was anderes, das eine andere Version hat als das Frontend, weil dann würde ja genau das alles nicht mehr funktionieren. Ja, mit Sicherheit. Dann werfen wir vielleicht jetzt mal kurz einen Blick auf die Ähnlichkeiten, weil wie schon gesagt, spielt ja dann auch im Bereich von Project Fugu und Co. Das heißt, da gibt es definitiv auch Ähnlichkeiten und zwar vor allem auch was die Geeks betrifft. Also Quick ist natürlich auch eine deklaratives und komponentenbasiertes Framework, das heißt, es baut auf den Erfahrungen und Vorteilen der bisherigen Frameworks auf. Wir nutzen wie in React auf Hooks für Zustandsmanagement und Lifecycle. Und ich sag mal die APIs, die Quick mit sich bringt, die sind vertraut. Wir haben Sachen wie, uh, Signal. Das ist im Grunde If State in Reaktor oder wie RAW in If. Wir haben just ask. Das ist im Grunde vergleichbar so ein stückweit mit use Effekten oder mit Use Watchin für richtig oder watch. Einfach nur einfach nur Watch, einfach nur Watch. Effekt. Effect. Was bei Solid genau das heißt einfach eine Lifecycle Hook. Genau. Und dann haben wir auch so Sachen wie eine Context API, also so die die Grundfeatures, die sind da gleich und funktionieren auch ähnlich. Was genau ist eine Kontextapi? Kontext ist der Kontext. Kontext API ist im Grunde eine Schnittstelle, um Daten zwischen Komponenten auszutauschen, ohne sie über die Props durchzureichen. Und wenn ich jetzt Daten habe, die komplett global der Anwendung verwendet werden, vielleicht so was wie das Team, dann möchte ich das ja nicht in jede Komponente durchreichen, sondern dann nutze ich halt die Context API und mache es zugänglich von überall aus. Also sowas wie ein global state global state. In einfachen Worten ich weiß nicht, wie da der Begriff ein View ist. Haben wir? Glaube ich nicht, aber. Interessant. Okay. Ja easy. Und ist da auch meine Requestparameter und sowas drin? Oder ist das erste, was bei QuickCity dann mitkommt? Das kommt dann erst bei Glücksspiel damit. Genau. Und was noch ähnlich ist Wir haben im Meta Framework, also bei QuickCity auch dateibasiertes Routing, wie halt bei den anderen großen Playern, zum Beispiel Next.js oder Next. Dann haben wir auch Lotus und Actions und API Endpunkte, was die meisten großen Frameworks mittlerweile auch mit drin haben. Loaders und Actions sind ja vor allem durch Remix bekannt. Dann können wir eine Quick Anwendung bei allen gängigen Anbietern Deployment. Da gibt es also auch keinen wirklichen, kein wirklicher Unterschiede. Und es gibt ganz einfache Integration für Taiwan, Story Book wie Test usw und wie fast jedes neuere JavaScript Framework baut auch Quick auf wieder auf. Und damit können wir mal auch einen Blick auf die Unterschiede werfen. Also was ist denn an Quick anders? Und zwar setzt Quick auf Signals und nutzt meist granulare Domupdates. Vergleichbar wie auch Solid. Es funktioniert. Man muss sagen, Quick ist nicht ganz so Feingranulat. Solid, weil solid ist wirklich 100 % feingranular. Bei Quick ist es so, dass Änderungen, die das Template nicht verändern, zum Beispiel wenn einfach eine Textnote sich von null auf eins ändert. Oder wenn wenn ein Textfeld also in einem Inputelement irgendwas eingetippt wird, dann werden die Änderungen feingranular vorgenommen. Sobald sich aber das Template verändert, zum Beispiel wir zeigen eine Fehlermeldung an, das heißt ein neues Domelement landet im Browser, dann muss das Template, also das Change Nx, gerendert werden und dann wird auch die Komponente benötigt. Und was auch so ein bisschen ein Unterschied ist oder was in Auffälligkeit ist. Überall, wo der Optimizer das war der Compiler, den wir ja eben schon angesprochen hatten, den Code splitten kann, befindet sich in Quick 1 $ sein des Dollar sein macht erst mal nichts, aber ist für uns als Entwickler einfach ein Hinweis, dass hier Code Splitting passieren kann. Und warum ist es wichtig, wenn wir eine. Wenn wir zum Beispiel einen Eventhändler aus unserer Komponente raus trennen? Dann gibt es ja Dinge, die wir beachten müssen. Es ist ja nicht untypisch, dass ich in meinem Eventhändler vielleicht zum Beispiel eine Variable nutze, die ich zuvor in der Komponente definiert habe. Das heißt, wenn ich jetzt den Eventhändler raus move, wie habe ich dann Zugriff auf die Variable? Und da gibt es ein paar Regeln, die man beachten muss, weil Quick, da kommen wir gleich auch noch zu. Wenn der. Die Anwendung an den Browser gesendet wird alles serialisiert. Das heißt, ich kann zum Beispiel wenn es so Boundaries gibt, wo der Code gesplittet wird, kann ich ja nicht eine JavaScript Funktion zum Beispiel übergeben, weil die kann ich serialisiert werden. Also quick kann es serialisieren, das heißt man kann es dann doch wieder, aber man kann nicht direkt die Funktion übergeben und da gibt es halt so ein paar Sachen, an die man dann einfach denken muss. Was auch ein Unterschied ist, vor allem zu zum Beispiel Reactio nutzt Slots auch. Wie soll ich auch wie if und wie World? Und warum nutzt Quick Slots? Der Hintergrund ist der eine Quick Komponente weiß nichts von ihren Kindern, weiß auch nichts von ihren Eltern. Und warum? Weil Quick wie eben angesprochen, versucht ja immer den kleinst möglichen JavaScript Code auszuführen. Das bedeutet, Quick ist in der Lage, Komponenten komplett unabhängig von ihrem Baum zu rendern. Wenn sich nur was irgendwo zwischendrin verändert hat und auch nur das .x ausgeführt werden muss, dann kann auch wirklich nur das ausführen. Und das ist ein großer Unterschied zu den aktuellen Frameworks, weil die müssen ja immer top down rendern, das heißt die müssen, wenn eine Eltern Komponente neu gerendert wird, zum Beispiel bei Preact auch alle Kinder neu rendern und benötigen daher auch den Code der Kinder. Und das fällt bei Quick Weg weg und dadurch kann Quick halt die Komponenten auch komplett asynchron rendern. Das bringt auch wieder so ein paar andere Sachen mit, weil zum Beispiel wenn die Eltern keine Informationen über ihre Kindern haben, dann kann ich ja auch nicht Komponenten über Props übergeben und sie irgendwie verändern. Das heißt, da gibt es dann auch wieder so ein paar Dinge, auf die man einfach achten muss. Was meinst du denn mit asynchron rendern? Die also quick kann die Komponenten, sage ich mal in zufälliger Reihenfolge, sage ich mal rendern. Die müssen nicht top down und synchron nacheinander gerendert werden. Aber wenn ich sie anzeige, dann müssen sie ja trotzdem in der richtigen Reihenfolge gepflegt werden. Die sind ja schon initial applied durch Rendering. Ach so, und dann und dann wird nur die Änderung vorgenommen, die auch wirklich relevant ist. Und das kann zwischendrin passieren, also zwischen den Komponenten, die sich zwischendrin in der Baumhierarchie befinden. Der Baum ist ja schon aufgebaut und jetzt geht es eigentlich nur um Update und da können sie asynchron geupdatet werden. Das heißt es wird am Ende einfach deutlich weniger JavaScript Code ausgeführt und demnach auch benötigt. Und ja, wie schon angesprochen, bestimmte Dinge werden bei Quick serialisiert und dadurch gibt es halt auch ein paar Regeln, die man beachten muss. Zum Beispiel habe ich ja eben angesprochen Funktion könne ich direkt als Props zum Beispiel übergeben werden, was wir ja in React ganz typisch machen. Wenn wir einen Eventhändler irgendwie eine Komponente übergeben, dann packen wir die, halten die Props rein. Das geht bei Quick auch, aber das muss zuvor zu einer sogenannten Karl umgewandelt werden. Am Ende müssen wir als Entwickler da nichts beachten. Wir gehen eigentlich auch so vor wie in React und packen halt zum Beispiel so 1 $ sein Drumherum, der den Rest macht dann quick. Das macht dann der Optimizer, aber im Grunde wandelt der dann am Ende den Code, den wir geschrieben haben, in einer schönen, die um zu einer Kugel, die dann Quick wiederum nutzen kann, um lazy bestimmte Chunks zu laden. So cool, gerade noch mal erklären. Das ist ja so ein nicht gängiger Begriff, ist eher so quick spezifisch. Ja, so eine Kugel ist wie das so eine Art von Serialisierung, die es quick ermöglicht, im Grunde Komponenten oder Code nachzuladen. Und also man kann sich das so vorstellen wenn Quick zum Beispiel einen Event Händler serialisiert, dann schreiben wir als Entwickler ganz normal unseren Eventhändler rein, was Quick aber unter der Haube macht. Quick splittet den Code, erstellt, verschiedene Chars, die Chance bekommen, einen Namen plus benötigen ja dann auch den Code, der in dem Trunk exportiert wird. Das heißt eine URL besteht dann zum Beispiel aus Punkt Schrägstrich Check JavaScript, dann kommt ein Hashtag und dann kommt das Simple, Simple ist im Grunde der Export des Eventhändlers und dann vielleicht noch ein paar andere Informationen. Und die kann dann Quick wiederum nutzen, um dann lazy unsere JavaScript Tags auszuführen. Und ich glaube, jetzt sind wir mal so mit den Basics durch und können mal auf Resume ability gehen. Das ist ja so die Hauptinnovation von Quick, die genau versucht, diese Probleme, die wir ganz am Anfang besprochen hatten, zu lösen und die Probleme von Hydration noch mal zu wiederholen, waren ja zum einen, dass wir den gesamten Code benötigen. Der muss initial komplett an den Browser gesendet und ausgeführt werden. Plus wir schicken halt auch bestimmte Informationen doppelt im HTML und im JavaScript Code und wir benötigen das. Also wir müssen den kompletten Code rüberschicken, weil wir müssen den Zustand wiederherstellen und wir müssen dann die Eventhandler platzieren Event Listener. Und jetzt ist die Frage, wie kann man das alles erreichen, ohne den ganzen Code rüber zu schicken? Und dafür gibt es zwei Punkte, die wichtig sind. Das ist zum einen Serialisierung, das heißt ich muss zum Beispiel die Zustände und die Abhängigkeiten der Zustände und auch die Event Listener irgendwie als Information ins HTML packen. Und 0.2, das hatten wir jetzt ja schon ein paar Mal angesprochen, ist dann das Codesplitting. Ich brauche irgendwie einen Compilerschritt, dass mir mein JavaScript in ganz kleine Runde bricht, sodass ich dann ja auch, sodass ich dann auch die Möglichkeit habe, wirklich nur den minimalsten JavaScript Code auszuführen, wenn es nach am Ende wieder ein großer Trunk ist, habe ich dann nicht wirklich was gewonnen? Und die Funktionsweise wie resumability funktioniert? Schauen wir uns jetzt mal an einem Beispiel an, zum Beispiel einer einfachen Counter Komponente der Counter Komponente definiert, hier am Anfang einen State in quick mit Signal setzt oder setzt dort als initialen Wert zum Beispiel die Zahl null rein und dann rendert es im JS Nx als Template einen Button Element und der Button zeigt dann den aktuellen Zustand an, das heißt Initiale null. Und wenn man drauf klickt, erhöht sich dann halt die Anzahl. Der erste Schritt ist zu Build Zeit und das ist das Codesplitting. Das heißt was Quick jetzt macht. Quick kann den Eventhandler von der Komponente trennen. Das heißt, wir haben bei so einer einfachen Counter App. Dann zwei JavaScript Chunks. Und Quick macht da noch ein bisschen im Hintergrund mehr, damit zum Beispiel auch der Eventhändler weiterhin auf den Zustand zugreifen kann, obwohl er außer Komponente gelöst ist, sowie auch auf lokal definierte Variablen in der Komponente. Dann kommen wir zu Schritt zwei und es ist jetzt bereits Server seit Rendering oder statische Generierung. Das ist dann der Schritt, wo auch Next.js xt und Svelte kit das HTML generieren. Und das macht Quick erst mal genau gleich in dem Prozess, wo aber dann Quick ausgeführt wird, zum Beispiel auf dem Server sammelt Quick aber auch Informationen über Zustände, Abhängigkeiten und über die Event Listener und serialisiert die Dinge wie die Zustände und Abhängigkeiten. Die landen in einem Jason Object, die direkt in einem Skriptelement sich dann im HTML befinden. Das heißt, wenn ich zum Beispiel einen Counter hatte, wo halt der Value des Signals bei null steht, dann ist diese Information in diesem Jason Object und genauso werden dort die Abhängigkeiten notiert. Das heißt jede, jedes kleinste Element, jede Textnote, die die halt Zustand konsumiert, bekommt eine ID und die Abhängigkeiten eines Zustands werden auch in diesem Jason Objekt serialisiert. Und dadurch weiß dann Quick, wenn der Zustand verändert wird, welche weiteren Checks benötigt werden, um dann die UI zu aktualisieren. Das heißt die ganz Informationen, die die aktuellen Frameworks erst dann gewinnen, wenn der komplette Code heruntergeladen wurde und ausgeführt wird, befinden sich bei Quick bereits im HTML. Und noch eine Sache wie eben auch angesprochen, werden auch die Event Listener oder Eventhändler serialisiert oder die Event listener. Und das funktioniert so, dass Quick noch ein paar Zusatzinformationen zu unseren HTMLElementen hinzufügt. Bei einem Klick Händler bei unserer Counter Komponente zum Beispiel ein Attribut, das nennt sich nachher on Doppelpunkt click und dort befindet sich dann diese URL drin, von der wir bereits gesprochen haben und es am Ende nun in String, den dann der Quickloader wieder nutzen kann, um anhand dessen die Straße herunter zu laden, die Tanks auszuführen und letztendlich dann den Eventhändler das tun zu lassen, was er tun muss. Das heißt, im zweiten Schritt, wo unsere Website serverseitig generiert wird, befindet sich alles, was wir brauchen direkt im HTML. Und jetzt kommen wir zum Dritten Schritt und das ist der Schritt, wo dann unser HTML an den Browser geht. In dem dritten Schritt bekommt unser Browser des HTML. Und dort befinden sich ja alle Informationen. Also im Grunde genau gleich wie bei Next oder next usw und dadurch kann der Browser direkt unsere Website und den Content darstellen. Was jetzt aber anders ist Quick hat ja initial direkt den Quickloader im HTML, das heißt der ist eingebunden, der muss auch nicht gesondert irgendwie geladen werden. Das ist ungefähr ein Kilobyte und der platziert globale Event Listener plus. Man kann auch einen Service Worker platzieren, der dann im Hintergrund schon mal die wichtigsten JavaScript Tanks prüft, die wir möglicherweise bei einer Interaktion benötigen. Bei unserem Counterbeispiel zum Beispiel den Eventhändler und was jetzt passiert, wenn der Nutzer auf unseren Button drückt, dann Bubble des Event bis zu dem globalen Event Listener. Der Event Listener oder der Quickloader kann dann den Pfad zurückverfolgen. Den liest dann das HTML Attribut aus. Das war ja das Attribut mit onclick und dann der URL und kann dann anhand dessen den Pfad zu dem JavaScript Funk zusammensetzen. Kann denn das Ganze herunterladen? Wenn es im Cache ist, dann kann es direkt ausgeführt werden. Und anhand von noch ein paar weiteren Informationen kann dann im Grunde Quick den aktuellen Zustand unseres Counters aus dem JavaScript Objekt holen, kann dann den Counter erhöhen, kann dann sehen Ah, okay, der Count hat hier ein paar Abhängigkeiten und kann dann ganz gezielt die Abhängigkeiten informieren, dass an der Stelle jetzt etwas aktualisiert werden muss. Und das ist der Grund, warum Quick durch Resume Ability eine extreme Start up Performance hat, also sofort interaktiv ist und auch immer nur den JavaScript Code am Ende benötigt, der Halt für die jeweilige Aktion erforderlich ist und nicht den das komplette Framework mit dem kompletten Code der jeweiligen Seite. Und es hat auch den Vorteil, dass. Es gibt ja häufig auch Komponenten, die komplett statisch sind, die sich gar nicht verändern und der Quick Optimizer erkennt das. Und solche Sachen werden zum Beispiel erst gar nicht überhaupt an den Browser gesendet, weil da kann sich nichts verändern. Da gibt es keinen Grund, diese Komponenten zu rendern. Muss ich mir da als Entwickler manuell Gedanken machen, welche Teile wann wie nachgeladen werden? Und das ist irgendwie automatisch, in welche Chunks das unterteilt wird. Bei Default passiert das automatisch, allerdings kann es konfiguriert werden und es ist auch noch mal so einen Unterschied oder Vorteil gegenüber den aktuellen Frameworks. Wenn ich bei Preact manuell Code bedingt betreiben möchte und manuell etwas lazy Load möchte, dann nutze ich ja am Ende zum Beispiel dynamische Imports direkt in meinem Code. Das heißt, ich als Entwickler muss mich entscheiden, wo mache ich mein Codesplitting. Bei Quick gibt es das nicht, bei QC schreibe ich einfach meine Komponenten, so wie mir das Quick vorgibt. Und an den Stellen, wo sich das Dasein befindet, kann Quick das sbedingt betreiben. Das bedeutet, ihr könnt es selbst konfigurieren, wenn ihr sagt Hey, bei meiner Anwendung macht es hier keinen Sinn das zu unterteilen. In 20 Chunks. Ich glaube ein Tank ist da dann doch irgendwie besser bei meinen Nutzern, weil ich dann irgendwie eine bessere Komprimierung habe. Dann kannst du das so konfigurieren und du kannst es tatsächlich auch auf die Spitze treiben. Du könntest zur Laufzeit über Analysetools erfassen, welche Chance tatsächlich ausgeführt werden. Also was klickt der Nutzer an und was wird benötigt? Und wenn du ausreichend Daten hast, kannst du halt statistische Analysen durchführen, um festzustellen, welche Chunks müssen wann heruntergeladen werden, also wie werden sie priorisiert und was wird vielleicht erst gar nicht überhaupt benötigt? Ja, und wir kommen es auch so stück cleweise aufs Ende zu. Vielleicht noch mal so ein kleiner Recap. Was sind denn jetzt die Vorteile? Die Vorteile von resumability sind zum einen, dass der komplette Hydrationschritt entfällt, das heißt ich brauche initial nicht den gesamten Code. Bedeutet, wenn meine Webanwendung wächst, weil wir neue Features hinzufügen, brauche ich weiterhin nur. Den Quickloader mit einem Kilobyte. Man muss dazu sagen, wenn ich dann tatsächlich irgendwie was verändert von meiner Seite, das heißt irgendwo draufdrücken, dann wird auch das Quick Framework heruntergeladen, was so grob 30 Kilobyte sind. Wie das habe ich nicht verstanden. Wieso wird das runtergeladen? Na ja, wenn ich jetzt zum Beispiel irgendwie bei meinem Formular auf Abschicken drücke, dann werden aber viele Nachrichten angezeigt. Dann muss die Quick ja rein rendern in das HTML und das kann der Quick oder nicht. Das heißt, sobald, dann sage ich mal das Quick Framework. Auch benötigt wird, wird es ebenfalls heruntergeladen. Das heißt Initialstatus mit dem eins Kilobyte und deine Website ist direkt instant interaktiv. Jedoch wenn du dann wirklich was anklickst, wenn es noch nicht geprüft wurde, muss das Framework plus zum Beispiel dein Event Handler herunter geladen und ausgeführt werden. Und das ist auch so ein Punkt. Den muss man natürlich auch betrachten, weil wenn wir zum Beispiel mit Solid arbeiten und eine kleine Anwendung haben, kann es sein, dass unsere komplette Solid App 30 Kilobyte groß ist und so groß ist alleine halt schon Quick, das heißt je nach Anwendung muss man da auch so Abwägungen treffen, weil zum Beispiel ist solid. Sobald dann die Website einmal ausgeführt wurde und heruntergeladen wurde, dann auch wieder schneller, weil es halt komplett feingranular die Updates vornimmt. Heißt das, sobald ich bei Quick Dom Manipulation mache, zum Beispiel nur einen Dialog anzeigen möchte, dass er dann schon das komplette Framework braucht? Genau. Sand. Das ist ja im Grunde gleich dann wie bei Reactif und Co. Genau. Und das ist 30 groß, weil da der ganze JSX Compiler mitkommt, oder? Da kann ich jetzt nicht ganz genau sagen, wie groß ist zum Beispiel wäre, wenn ich nur so eine kleine Counter Anwendung habe, weil ich weiß es halt aus meiner eigenen Anwendung, die ist ein bisschen komplexer. Da ist noch QuickCity mit drin und es wird sich ebenfalls in dem Bundle befinden. Bei mir ist es 40 Kilobyte. Ich vermute aber recht stark, dass das Framework an sich bei so grob 30 liegt und da bin ich auch gespannt auf die Zukunft, inwieweit sie das optimieren können, weil ich vermute, dass in diesem Junk auch viel drin sein könnte, was Serialisierung usw betrifft. Und vielleicht kann man da in Zukunft auch sagen Hey, das und das brauche ich gar nicht, lass es einfach raus. Aber da muss man dann auch immer sagen Quick ist dann doch noch recht neu. Es gibt noch nicht so viele praktische Erfahrungen und Erfahrungsberichte und ich denke, das wird sich über die Zeit noch zeigen. Plus In den letzten Monaten hat sich natürlich stark auf V1 hin gearbeitet. Da wurden noch mal neue APIs entwickelt, APIs umbenannt, APIs verbessert und jetzt kommt vermutlich dann auch Stück nach Stück der Zeitpunkt, wo dann vielleicht auch noch mal bestehender Code überarbeitet wird, wo vielleicht dann noch mal Sachen wieder rausgeschmissen werden, die gar nicht benötigt werden. Und allerdings muss man ja auch sagen, wenn der Wenn das übergeordnete Ziel ist, die Time to Interaktion maximal niedrig zu halten, dann ist es ja auch egal, ob ich danach noch 30, 40 oder 60 Kilobyte in JavaScript nachlade. All die Ersparnis habe ich ja schon genannt. Ersparnis hat man deshalb schon, weil halt der Manfred nicht blockiert wird. Aber klar, natürlich, Das Framework wird dann halt benötigt und wenn das zum Beispiel noch nicht geprüft wird und ich dann drück, habe ich ja dann auch keine Instanz induktivität zum Beispiel darf man, darf man da auch nicht vergessen. Aber man muss ja auch sehen, wenn das einmal heruntergeladen wurde und gecrasht wurde, dann wird es halt nie wieder heruntergeladen, außer wir bauen unsere App neu und da verändert sich was an dem Bundle, was vielleicht an der Stelle auch noch cool ist. Dieses Lazy, diese Lazy Execution, die funktioniert auch bei Lifecycle Hooks. Zum Beispiel gibt es eine Hook in in Quick, die nennt sich Use Task und wenn wir zum Beispiel eine Komponente haben. Wo eine Animation getriggert werden muss und dann halt vielleicht ein Time out läuft oder so oder Intervall, dann wird er auch wirklich nur dann ausgeführt werden. Die Komponente im IF ist. Das heißt selbst da kann Quick Lazy Execution anwenden und es kann cool sein, wenn wir zum Beispiel so eine ewig lange Marketingwebsite haben mit tollen Animationen und dies und das wird dann Stück nach Stück im Grunde die Website gestreamt, das heißt Stück nach Stück. Wenn ich scrolle und mit der Website interagiert, wird halt weiteres JavaScript geprüft und halt lazy, also verzögert ausgeführt. Also das wird dann ausgeführt, wenn das Element was will wird. Genau, wenn die Komponente im IF ist okay. Und das macht er aber schon mit einem Intersektional Observer. Wie das intern implementiert, das weiß ich gar nicht. Okay. Ja, was vielleicht auch noch cool ist man kann mehrere Quickapps ineinander stecken. Das heißt, man kann zum Beispiel eine Quickapp nur den Header ändern lassen und die andere QuickApp, die Hero Section und eine andere Quickapp den Footer. Das ist erstmal eine dumme Spielerei, aber da wurde also der Punkt, wo es vielleicht interessant wird, wenn ich irgendwie eine große Company bin. Großes eCommerce Business und ich habe viele Teams und ich möchte irgendwie meine Anwendung aufsplitten. Also im Grunde, wie sagt man zu der Architektur Microservices genau? Wenn ich das bei mir implementieren möchte, dann geht es mit Quick und es kann auch wirklich konkrete Vorteile bieten. Weil wenn ich jetzt zum Beispiel einen Onlineshop habe, dann habe ich ja so ein paar kleine Teile, die sind personalisiert, zum Beispiel rechts oben habe ich mein Profilbild, aber andere Teile sind komplett gleich für jeden Nutzer. Und indem ich das über eigene Quickanwendungen ändere, kann ich die einzelnen Quickanwendungen über verschiedene Edgeworkers rendern und kann halt auch unterschiedlichen Caching unterschiedlich Caching betreiben. Ich kann zum Beispiel sagen, der statische Inhalt, der sich nie ändert, der wird komplett gecrasht und das was sich vielleicht ändern kann, wird halt nicht gecrasht und bei jeder Anfrage bearbeitet. Und dadurch kann ich aber den Code, der vielleicht bei jeder Anfrage ausgeführt werden muss, extrem reduzieren und kann halt am Ende wieder vielleicht dann dynamisch Inhalte mit dem Speed von statischen Inhalten über die Tage ausliefern. Das ist Features, die gehen vielleicht ein bisschen zu weit für die meisten Anwendungsfälle, die vielleicht uns direkt betreffen. Aber es ist einfach cool zu wissen, dass Quick das so viel zu viel Power kommt und mit so vielen weiteren Gedanken und Ideen und es nicht aufhört bei dem, was wir aktuell schon haben. Okay. Damit gehen wir dann mal aufs Ende zu. Was ich zum Schluss noch sagen möchte, habe ich auch bereits schon mal so ein bisschen angesprochen. Quick ist noch neu. Wir sind jetzt erst seit kurzem, sage ich mal in V1. Das heißt, viele Erkenntnisse müssen erst noch gewonnen werden. Das Ganze bietet aber auch Chancen, zum Beispiel wenn ihr Interesse habt an eigenen Open Source Projekten. Das heißt, wenn ihr da jetzt reingehen möchtet, wenn euch das interessiert, habt ihr halt die Möglichkeit, früh dabei zu sein und vielleicht dann früher oder später ein großes Open Source Projekt zu haben, das auf sowas wie Quick aufbaut. Das heißt, an alle, die da irgendwie Lust haben, Innovation zu betreiben und das Web Ökosystem nach vorne zu pushen. Da habt ihr jetzt vielleicht eine Chance. Cool. Ich höre dann. Auf. Ja, spannende Entwicklung. Also vieles von dem, wie du schon sagst, wird sich noch mal zeigen, wie es in unterschiedlichen Use Cases am Ende dann wirklich sich anfühlt und etablieren kann. Aber ich finde, zumindest viele der Ansätze, die man da hört, sind erst mal sehr machen Sinn. Und das pusht halt auch das gesamte Ökosystem. Man muss dazu auch sagen, die ganzen Autoren von Solid, Quick View usw, die sprechen miteinander. Das ist jetzt nicht so, dass man da auf Kriegsfuß ist und das ist am Ende irgendwie auch so ein Geben und Nehmen. Der eine bringt eine Innovation in dem einen Bereich, zum Beispiel Solid bei der Runtime Quick bringt wiederum eine Innovation im anderen Bereich und die anderen Frameworks können dann davon lernen und können vielleicht das, was sie auch cool finden, bei sich dann wieder mit einarbeiten und. Das Gesamte bringt uns dann halt alle gemeinsam voran und bringt uns zu einem besseren Web und zu einem schnelleren Web. Ach, das sind ja fast philosophische Worte. Sehr schön. Viel good ending. Ja. Cool. Vielen Dank Fabian, für den Einblick darein. Wir haben heute tatsächlich eine. Die Folge ist auch noch Pics of the day im Gepäck. Ich fange an, Ich habe eine Kleinigkeit, die mir einfach nur neu war und ich nicht kannte und deswegen irgendwie ganz interessant fand, dass das gibt Es gibt was. Das nennt sich Confluent ial Mail bei Google. Also wenn man Google Workplace und Gmail nutzt, dann kann man das anschalten. Dann ist das so, wenn man irgendwie mal eine E Mail verschicken will, die besonders sicherheitsrelevant ist, dann kann man die in einem Confluent ial Modus verschicken und dann kriegt man letztendlich einfach als Empfänger nur ein Link und kommt auf eine Webseite, wo dann diese E Mail drin ist. Und dann kann man so unterschiedliche Sachen einstellen, beispielsweise, dass die Email auch abläuft. Also du kannst sagen, dass sie nur fünf Tage sichtbar sein soll. Man kann auch zusätzlichen Sicherheitscode separat hinterlegen, dass man nur mit diesem Code zusätzlich auf diese Email zugreifen kann. Und standardmäßig ist immer die Frage, wie sicher das dann ist. Aber ich habe in dem Beispiel jetzt eine PDF als Anhang bekommen. Ich kann das PDF zur öffnen, aber Sie haben sehr gut unterbunden, dass ich dieses PDF herunterladen kann. Also ich habe zumindest mal kurz geguckt in den Developer Tools, ob ich da jetzt den einfach an die Quelle von dem PDF komme und Rechtsklick funktioniert nicht und so, also klar, ich kann Bildschirm Screenshots machen von dem was da jetzt ist, aber es ist nicht so ganz einfach gemacht, jetzt auch diese Inhalte dann runterzuladen, die in der Email verschickt wurden. Und das ist echt cool. Ja, was passiert ja doch mal, dass man auch Emails versenden möchte, die halt dann irgendwie Sekretgeschichten enthalten. Und wie die meisten wissen, ist die Mail halt dann noch nicht so sicher und vor allem ist es dann für Ewigkeit gespeichert aus irgendwelchen Servern und da ist das Kommunikationswege. Finde ich ganz ganz interessanter Ansatz. Hat ja 50. Geburtstag gefeiert neulich oder sind nicht Anfang der 70er erste Email. Okay, das ist ne coole Sache und was muss ich dafür tun? Auf der Energieoberfläche muss ich sein. Ja, also du musst in einer Organisation sein, die das grundsätzlich das Feature enabled. Ah, okay, das ist also eine Admineinstellung. Meine Mama kann das jetzt nicht machen, wenn die bei mir ist. Ich weiß nicht, ob es. Privat habe ich noch geheime geheime Kochrezepte. Hallo? Ja geht oder ich gehe davon aus das ein Business Feature ist. Okay. Ja, macht Sinn. Ja. Nice. You speak. Dann mach ich meinen Pick, Denn das Hast du schon mal den Docker Desktop runtergeladen? Ja. Wie war da für dich das Erlebnis, dass man sich da immer noch irgendwie mit einem kostenlosen Account registrieren, damit man die Desktop App runterladen darf? Ich glaube nicht. Nein. Ein bisschen. Aber die Desktop Apple ist auf jeden Fall so ein kleiner Elefant. Irgendwie gut geworden, mit allen möglichen Sachen. Und da ist mein Pick eine Alternative. Und die heißt ObStackorpobstack. Leichtgewichtige Docker Desktop Alternative. Und das habe ich jetzt im Einsatz. Du kannst einfach Docker eintippen, also funktioniert alles wie vorher. Das heißt, es bringt auch Docker mit sich, wenn man das installiert. Genau. Also ist das eigentlich wie Docker Desktop, nur ein bisschen schneller und leichter und hat eine Oberfläche. Und das ist mein Pick. Ich habe auch noch ein Tool. Das Beste zum Schluss. Ja. Wir hatten ja bereits so ein bisschen auch über CMS gesprochen, und zwar über das virtuelle CMS von Bilder .io. Ich möchte an der Stelle noch ein anderes CMS erwähnen, das auch schon immer wieder mal im Podcast irgendwie der Name gefallen ist. Und zwar ist es Directors. Das nutzen wir bei der Programmier.bar Website und es ist auch Open Source und kann im Grunde erstmal jeder nutzen. Und da hat es schon echt einen richtig Power. Also ein Tool mit Power ist denke ich wäre es mal cool, da auch irgendwie eine Sendung zu machen und warum ich jetzt auch die Nennung mache ist, dass ich direkt bei meiner eigenen E-Learning Plattform auch einsetzt und ich tatsächlich gerade mit dem Directors Team im Austausch bin, weil ich eine komplett neue SDK geschrieben hatte, die komplett sicher ist und ein paar Vorteile mit sich bringt. Sie ist auch modular wie meine Bibliothek. Und ja, mal schauen, was da so die Zukunft bringt und in welche Richtung Directors geht und ob meine SDK Einzug findet in das Directors Open Source Projekt. Cool. Auf jeden Fall macht es Spaß zu nutzen. Ein solides, solides CMS gefällt mir. Es ist schön aufgebaut. CMS. Allright. Dann haben wir es. Ist zwar nicht knapp geworden wie gewünscht, aber das ist gut. Dafür habt ihr jetzt viele Informationen über Quick Feedback an Podcast Programmier.bar oder über unsere Webseite. Da freuen wir uns sehr darüber. Fabian Vielen Dank, dass du wieder Teil der Programmier.bar warst. Wir werden mit Sicherheit auch in der Zukunft wieder von dir hören. Schön, dass du dabei warst. Habt alle eine gute Zeit. Genießt den Sommer und bis ganz bald. Macht das gut. Schön.