Transcript

[0:00] Welche Bereiche habt ihr euch denn so rausgepickt, die ihr dann mit unpoly supercharged habt?
Du sagst halt, dieser Link soll von unpoly gehandelt werden.
Da kannst du so ein Attribut sagen, ab follower ist.
Das heißt, dieser Link soll eben nicht mit dem Browser laden, sondern halt durch unpoly.
Du kannst aber auch global konfigurieren, dass es alle Links handelt.
Und dann lädt halt unpoly eben das Ziel erst mal einfach mit Fetch oder XHR.
Ja, was wir auch machen ist, dass wenn du im Link folgst, dass wir so die Antworten für eine Weile cachen, sodass wenn du nochmal da hinten navigierst, dass du einfach halt die Antwort schon hast.

[0:36] Music.

[1:04] Liebe Hörer und Hörerinnen, feiert am 07.01.
Von 15 bis 18 Uhr mit uns die 600. Podcast-Episode bei einem einzigartigen Online-Event, denn wir veranstalten eine Fishbowl-Diskussion.
Bei einer Fishbowl-Diskussion können einige Teilnehmer und Teilnehmerinnen im Kreis diskutieren, während andere im sogenannten äußeren Kreis zuhören und dann einsteigen können.
Wir freuen uns sehr auf diese interaktive und dynamische Form für einen Austausch zwischen uns Web-Devs.
Meldet euch über den Meetup-Link in den Shownotes an und seid Teil dieses spannenden Formats.
Wir freuen uns schon sehr auf euch und jetzt erstmal viel Spaß bei der folgenden Revision.
Revision 595. Wir sind heute nur zu zweit, da wären aus dem Team nur ich,

Revision 595: "HTML over the Wire" und Unpoly

https://workingdraft.de/595/

[1:57] der Shep, und das bedeutet, wir haben einen Gast da, und zwar den Henning Koch.
Hallo Henning. Hallo Shep, schön, dass ich da sein darf.
Schön, dass du da bist. Du warst noch nicht bei uns zu Gast und die Tradition erfordert ist, dass du dich dann einmal kurz vorstellst für unsere Hörerinnen und Hörer. Wer bist denn du?
Ja, ich bin der Henning Koch, komme aus Augsburg, bin Mitgründer von Makanda.
Wir haben ein Team aus vor allem Ruby-Entwicklern, JavaScript-Entwicklern, UI-Designern, Ops-Leuten hier in Augsburg eben. Wir bauen halt Web-Anwendungen, Maßgeschneidert.

[2:31] Und, ich glaube, ich bin heute hier, weil das Thema heute… Der Titel verrät es schon, den aufmerksam Hörerinnen.
HTML over the wire und das ist so ein Ding, was mich sehr sehr beschäftigt, weil ich halt hier so einen Open Source Tool maintainer heiße, unpoly, das ist so ein Verfechter von dieser.

[2:52] Vorgehensweise in Web-Entwicklung ist. Darüber möchte ich heute ein bisschen erzählen. Ja.
Also, darüber wollen wir sprechen. Und ich würde sagen, ich hab das Gefühl, dass HTML over the Wire so eine gewisse Art Hype erfährt oder vielleicht immer mal Aufwand ist.
Wir werden ja gleich irgendwie darüber sprechen.
Und es gibt ja auch schon ... Diese Konzepte gibt's ja schon lange.
Aber irgendwie erfahren die meines Gefühls nach irgendwie gerade so ein Uptake.
Und ähm. Auf jeden Fall gerade so ein Internetmoment. Genau.
Vor allem Artimix glaube ich wahrscheinlich. Das ist so das populärste aus der Reihe.
Ja genau. Das ist auch so der erste Kandidat würde ich sagen. Also stimmt nicht ganz.
Also der erste Kandidat war glaube ich äh, wie heißt das denn, äh, hier Laravel, ähm, Laravel Livewire gibt das? LiveWire, genau.
Da haben wir auch eine Folge zu aufgenommen, schon eine Weile her.
Aber… Ich will da so vorfahren, so wie Turbulence, PJax und so, das war noch ein bisschen früher da, aber… Ja, genau.
Aber so als eigenständiges Ding hatten wir das jetzt so noch nicht auf dem Schirm.

[4:06] Und genau, darüber wollen wir sprechen. Aber wir müssen wahrscheinlich erst mal so ein bisschen Grundlagenarbeit machen, um so ein bisschen dahin zu führen, was das für ein Konzept ist und warum das möglicherweise gerade so ein Uptake erfährt.
Genau, wofür ist denn HTML over the wire gedacht oder wo muss man das irgendwie sehen?
Ja, er muss ja auch ein klein bisschen ausholen. Also, als das Web damals so gelegt wurde, da war es ja vor allem so eine Idee, so Dokumente zu verbinden mit Hyperlinks.
Und dann kamen ja so die ersten Web-Ermendungen und das waren ja erstmal auch so eher so dokumentähnliche Dinge, ne?
Also, ja, du hast halt eine Seite mit Links, wo man auf Link klickt, produziert da selber wieder HTML mit der neuen Seite, aber eigentlich wechselst du ja wie so eine Slideshow so zwischen den Zuständen von der UI.
Und heute würden wir so die Art, Sachen zu schreiben, wahrscheinlich Multipage-Apps, nennen, wo du halt so eine Page nacheinander renderst.

[5:09] Und, genau, dann gab's ja die Zeit, dass dann Leute angefangen haben, das so ein bisschen mit JavaScript so ein bisschen aufzubrezeln, ne, dass man auch mal im Kleinen so kleine Sachen machen kann, so, wenn man auf den Link klickt, dann klappt irgendwas auf oder so.
Aber grundsätzlich war es halt weiterhin noch diese Slideshow und als dann so die Requirements, dass es immer mehr so Richtung nativen Apps geht, halt mehr geworden ist, kam halt so in den 10er-Jahren halt dann diese Sache, mit den Single-Page-Apps.
Wo dann der Server irgendwie wenig oder gar kein HTML mehr erzeugt hat, sondern das alles halt eher im Kleinen geschehen ist und der Server halt eher nur so ein großer JSON-Endpoint geworden ist.
Ja, jetzt haben die Leute das halt ein paar Jahre gemacht so mit Single-Page-Apps, und haben so gemerkt, okay, ist auch nicht nur geil.

[5:59] Also, du bist halt zum Beispiel irgendwie nicht mehr synchron an deinen Daten dran, musst alles über JSON-APIs ziehen oder kannst nicht mehr deine Wunschsprache, im Backend haben und bist halt in dem meistens halt doch eher komplexeren JavaScript-Ökosystem unterwegs.
Und deswegen ist, glaube ich, gerade so eine spannende Zeit, weil beide Seiten, Single-Bit-Apps und Multiple-Bit-Apps, flirten mit der anderen Seite.
Single-Bit-Apps, ich weiß nicht, ob du das verfolgst mit React-Server-Components und, so, dass man sagt, ich find's interessant, dass auch teilweise Komponenten wieder auf dem Server HTML produzieren.
Und auf der anderen Seite ... versucht man halt, und da kommt jetzt dieses HTML-over-the-wire-Spiel, halt auch wieder zu experimentieren mit Ansätzen, wo der Server weiterhin so am Steuer ist und HTML produziert. Aber du dennoch versuchst, so ein paar von diesen Vorteilen zu kriegen, die sonst nur Single-Page-Apps haben.
Also mit so Vorteilen meine ich so was wie, dass halt Interaktionen nicht mehr die ganze Seite abreißen, sondern auch mal kleine Fragmente austauschen, dass so Navigationen sehr smooth sind, dass du Animationen hast, solche Sachen.
Und halt auch so von Entwickler-Erfahrungen, dass halt Dinge einfacher werden, die sonst in dem Multi-Page-App-Paradigma schwer sind.

[7:15] Also so Formulare aus der Hölle, wo so jedes Input von jedem anderen Input abhängt und so.
Und genau, das ist eben so dieser Gedanke von HTML over the wire.
Da gibt's halt jetzt diverse Tools, die sind alle ein bisschen verschieden.
Also, wir hatten schon HTMX, jetzt Livewire hatten wir, Phoenix Liveview, Turbo ist noch so ein großes Ding.
Und halt dann meine Bibliothek Unpoly.
Die unterscheiden sich alle ein bisschen, wie sie das machen, Aber die Idee ist halt immer so, der Server sagt an, der Server ist am Steuer, der Server prozent hat ML und der Client ist halt eher so ein Abspielgerät, wo du hast nicht so viel kleinsteilige Logik wie bei einer reinen Single-Page-App.
Genau, aber ich mein, in jQuery-Zeiten, gab's so was ja auch in Form von eben einfach Ajax-Requests.
Das war ja so, ich sag mal, in den Web 2.0-Zeiten, da spielte sich ja viel so ab. Also, da kenn ich das auch, dass ich mir meistens ...
Ich hab ja eigentlich oft auch fertiges HTML schon abgeholt beim Server und das dann einfach ins DOM geknallt. Aber, also, Jackery hat eben einfach nur so quasi atomare Tools für diese Geschichten geliefert. Aber diese HTML-over-the-wire-Frameworks.

[8:35] Die bieten sozusagen ein Developer-Experience-Konzept, rund um das Ganze drumherum. Und man muss eben auch wenig zu Fuß machen.
Also, das heißt, die Fokus setzen wieder in dem Element, wo er vorher war.
Oder, ähm, ja, einfach Transitions zwischen verschiedenen quasi States.
Das muss man alles nicht mehr zu Fuß machen, sondern das kann man eben sehr einfach markieren, sozusagen.
Genau, also, weil dieses grundsätzliche, ich hol mir Inhalt vom Server ab und setz ihn irgendwo ins DOM, das ist ja sehr einfach, aber wie du sagst, das ist halt super viel Zeit drumrum.
Ja, klar, Fokus, Scrollpositionen, Meta-Tags im Head, ähm, irgendwie aktive Inhalte aktivieren auf dem neuen HTML und so weiter.
Das ist vielleicht auch so der Grund, warum ja viel so von so diesem jQuery-Spacket, die geredet wird von damals, weil alle haben das halt irgendwie, haben irgendwie Rechtecke gezeigt, mit jQuery, aber halt dann vergessen, was man noch alles machen muss.
Und das haben diese HTML-Over-the-Wire-Tools halt für dich größtenteils schon erledigt.
Und du kannst halt dann zum Beispiel so Fragmente austauschen, indem du zum Beispiel einfach nur irgendwie ein Attribut auf den Link setzt oder so.

[9:53] Ja, ich habe auch das Gefühl, dass es, ich weiß nicht, vielleicht ist es aber auch nur eine bestimmte Framework, so wie eben Dynes und HTMX, dass da auch die Philosophie ist, wir nehmen HTML, weil das im Grunde als Basis gut ist, aber wir erweitern dessen Fähigkeiten durch z.B.
Die Möglichkeit, dass man Links nicht nur auf Fenster targeten kann oder auf Frames, sondern eben auch dann sowas macht wie, hey, warum kann ich, man kann doch auch ein Target auf, also in den Target auch ein CSS-Selektor schreiben und dann.

[10:34] Wenn dieser Link eben aufgerufen wird, dann werden dessen Daten geladen, aber eben nicht in die Seite gesetzt oder auch nicht in Frame gesetzt, sondern eben in das eine Element, auf das da verwiesen wird. Ja, ganz genau.
Ich bin mir nicht ganz sicher, aber HTMX hat ja, glaub ich, auch die Möglichkeit, da kann man Formulare dann auch mit irgendwie, nicht nur mit Post und Getup schicken, sondern da gibt's ja dann auch noch irgendwie die Möglichkeit, andere HTTP-Methoden, also die sozusagen, die fehlenden HTTP-Methoden.

[11:05] Und wie jeder immer sich gefragt hat, was ist eigentlich mit denen passiert, warum gab's die nie?
Solche Dinge halt, also dass man eben guckt, wo hat HTML seine noch Shortcomings, was so das Bauen von deklarativen, interaktiven Anwendungen angeht, und das eben nachrüstet.
Ja, hast, glaub ich, ganz gut gesagt. Also bei allem, was so entsteht mit neuen Features in HTML, so Fragmente austauschen ist irgendwie nie dabei.
Also das ist so ein Thema, das umschiffen die HTML-Menschen sehr gerne.
Also so die Idee, klickst auf einen Link und tauscht vielleicht nur einen Pallbereich aus und wirft nicht die ganze Seite weg, ist irgendwie immer vorgesehen, ja, mach doch bitte auf Ascript.
Und ja, klar kann man das auch machen. Also erstaunlich, dass das nicht so als...

[12:04] Als Betätigungsfeld erkannt wird für die HTML-Spec-Macher.

[12:10] Ja, sie machen dann so manchmal so benachbarte Sachen wie jetzt so, weiß nicht, so mit Page Transitions oder mit diesen Portals zum Beispiel, was, finde ich, so ein super weirdes Konzept ist.
Weiß nicht, wo du so eine Seite schon mal so vorlädst als Portal, so in einem so Mini-I-Frame und dann klickst du drauf und dann wird das groß, was ich noch nie gesehen habe.
Ich glaube, das war so ein Brainfart von Google, also ich glaube, das müsste dann für die Google IOS schnell rausgehauen werden, um was zu zeigen zu haben. Ich glaube, das ist aber auch tot.
Aber ich weiß, was du meinst, ja. Ja. Genau, also es ist ja viel so, sagen wir mal, so Streuselkram, aber so am Fundament wird nicht so richtig gearbeitet mehr, ne? Oder das wird nicht erweitert.
Ja, da wird halt immer so in den Bereich machst halt Mensch, aber es wird abgeschoben.

[12:57] Und ja, kann man schon machen, aber dann… Wobei ich auch das Gefühl habe, dass da so ein bisschen so ein Umdenken stattfindet, also so Projekte wie Open UI, wo eben gesagt wird so, hey, alle bauen Tabs und Akkordeons und filterbare Combo-Boxen.
So wir müssen uns jetzt wirklich mal hinsetzen und quasi die Dinge dann auch in deklaratives HTML gießen, weil das leider dann doch oft verunfallt am Ende.
Ja. Ja, also Hoffnung ist auf jeden Fall da. Oder auch so was wie hier das Lazy-Attribut bei den Bildern oder so.
Das ist ja auch was, was man schon irgendwie lange mit Intersection Observer bauen konnte und Dings und Bums.
Aber es ist halt trotzdem leichter, einfach ein HTML-Attribut zu setzen. Ja, auf jeden Fall.
Ja, also wir sind uns einig, würde ich sagen, dass es schön wäre, wenn da ein bisschen mehr passieren würde, ne? Ja, auf jeden Fall.
Genau, also zwischenzeitlich, bis es soweit ist, springen eben die HTML-over-the-Wire-Frameworks, ein.

[14:07] Du hast so eine Präsentation auch verlinkt auf der unpoly-Seite.
Du nennst das sozusagen auch den Sweetspot aus Komplexität in Entwicklung und vielleicht irgendwie Eye-Candiness, also die man haben will, oder Responsiveness.
Das ist ja letztendlich, warum man eine SPA haben möchte, ne?
So, okay, der initiale Aufwand, die hochzufahren, ist halt für alle Beteiligten hoch, in Anführungszeichen, so in Computerdimensionen gesehen.
Aber wenn das Ding dann da ist, dann geht eben alles leicht von der Hand und Dinge animieren und schieben sich und klappen auf und zu und verändern sich und so.
Und das kann eben HTML over the wire auch, weil es sozusagen diesen Prozess, dieses per AJAX Dinge holens ergänzt.
Also zum Beispiel, ich weiß nicht, bei HTML ist es so, vielleicht bei Anpoli auch, dass man DOM-Diffing-Algorithmus auch benutzen, um quasi das HTML dann einzusetzen, das vom Server kommt, und das Diffen mit eben dem Abschnitt, mit dem Zielabschnitt, wo es dann reingehört.
Ja, das ist so eine Erweiterung, die kannst du bei HTMX nutzen.
Mit dem Ideomorph heißt, glaub ich, diese Bibliothek, die sie benutzen.
Macht Ampoli jetzt nicht. Da ist eher drauf ausgerichtet, dass man kleine Fragmente austauscht.
Und dass, wenn irgendwas da drin erhaltenswert ist wie Scrollposition oder Fokus, dann wird das vorher weggespeichert und wiederhergestellt.

[15:35] Oder du sagst halt, dass du jetzt irgendein Element, zum Beispiel ein spielendes Video oder so, kannst du so markieren, das bitte nicht austauschen.
Und dann bleibt eben das Element erhalten, auch im neuen Rahmen und so.
Ja. Ich glaube, dass Turbo das auch einbauen möchte mit dem Morphen.
Zumindest haben sie es auf der Raids-World angekündigt.
Da war eine Konferenz vor ein paar Wochen. Mhm.

[15:58] Und das führt aber dann auch dazu, dass im Prinzip diese Frameworks ja viel leichtgewichtiger sind, weil dieser ganze ... Also der erst, sagen wir mal, vor zehn Jahren geschaffene ...
Der das Backend vom Frontend wieder wegfällt, also quasi da, wo jetzt auf einmal so die ganze Logik- und Datenverarbeitung dann vom Server ins Frontend gewandert ist.
Diese ganze Schicht wandert dann wieder zurück auf den Server und als Frontend-Entwickler.

[16:33] Macht man dann wirklich wieder eher klassisches Frontend und User-Interface, und solche Geschichten.
Genau, also du brauchst natürlich jetzt nicht mehr irgendwelche JSON-API-Endpoints, und Clients, um nur Daten von A nach B zu schaufeln.
Template hast du vorher oder nachher. Also vorher war es vielleicht irgendwie JSX und React.
Jetzt ist es halt wieder eher so ein... hat der Maker ein generierendes Template.
Jetzt, ich bin jetzt in der Hobbywelt, da muss man da irgendwie, weiß nicht, ERB oder HAML, Aber jede Programming-Sprache hat da ja irgendwas.
So Puck oder Jade oder keine Ahnung, wie die alle heißen.

[17:09] Ich würde nicht sagen, dass das ein Vollentwickler ist, auch wenn der im Paradigma gar nichts mehr tut.
Oder dass es überhaupt keinen JavaScript mehr gibt, auf kleine Seite.
Aber du hast natürlich auch weiterhin irgendwo mal so einen Custom-Controller oder so.
Oder irgendwas, wo man sagt, das macht total Sinn, das mit Scripting zu machen.
Das hat aber eher wieder so Sprinkles obendrauf.

[17:28] Sie machen jetzt nie das JavaScript, macht nie das Heavy-Lifting, es macht nichts Routings, macht nichts Renderings von HTML, sondern verknüpft noch Elemente. Also so was wie ...
Ähm, wenn du was in Select-Boxen willst, aber irgendwie, ich weiß nicht, TomSelect oder irgend so eine Bibliothek nutzt, die Select-Boxen jetzt irgendwie, die suchbar sind oder so, dann würdest du so was halt kleinseitig weiterhin aktivieren.
Und da gibt's dann halt meistens irgendwelche Callbacks, wo man das reinhängen kann.
Also, bei Unpoly sind das Compiler. Da kann man sagen, okay, ich will alle Elemente mit dem Selector Select, will ich aufgerufen bekommen, und dann tue ich auf dem Element, den wir aufrufen, halt in dem Fall, was nicht zum Beispiel TomSelect.
Oder bei, in dieser Hotwire-Welt, ist dann halt Stimulus, das verkennt man vielleicht auch noch, das ist auch so ein Weg halt noch so, JavaScript-Sprinkles ein bisschen zu organisieren auch, damit es eben nicht mehr dieses jQuery-Spagetti von damals wird.
Ja, umso eher. Das Heavy-Lifting, ne? Also das Heavy-Lifting macht jetzt das Server, also Routing, HTML-Produktion und so weiter. Mhm.
Ja, genau, und dementsprechend hat man sehr angenehme Ladezeiten, weniger Runtime Last auf dem Client selbst.
Ja. Ja.

[18:46] Und du hast es schon gesagt, in dieser Gattung gibt's eben Unpoli, Dann HTMX, Turbolinks, Phoenix Liveview und, ja, ich glaub, Laravel Livewires ist dann so ein Konzept, das auch so ähnlich ist, aber eben einfach verheiratet ist auch mit Laravel.
Aber Phoenix Liveview ist es ja auch. Also genau, und UnPoly und HTMX, die sind ja im Prinzip agnostisch.
Denen ist ja völlig Wurst, was man im Backend für eine Serversprache benutzt.
Ja, genau. Das ist auch so ein Designziel, dass du idealerweise am Backend irgendwie nichts oder sehr wenig machen musst.

[19:28] Also wir haben zum Beispiel auch irgendwie die Doku von Ampuli, selbst Ampuli.com, das ist zum Beispiel einfach nur ein Ordner, mit halb Melldateien.
Also da gibt es sozusagen gar kein aktives Backend. Und trotzdem habe ich halt da die Vorteile, wie so schnelle Seitenübergänge oder Sachen, die in Overlays aufgehen und so.
Ja, das heißt also im Grunde, also wir haben, glaube ich, auch unter unseren Höheren und viele Fans von statischen Seitengeneratoren.
Damit lässt sich das natürlich dann auch prima kombinieren.
Genau, ja, als Play ausgenommen, so was wie LiveView und LiveBrewer, die sind dann schon sehr verheiratet mit ihren Backends.
Also, mit LiveView ist halt ... Du brauchst eine LXC auf dem Backend.
Ich glaub, es würde auch gar nicht anders funktionieren, weil es sehr LXC-spezifisch ist.
Aber sonst so eine Mix an Poly kannst du mit allem benutzen.
Und kannst wieder die Programmiersprache deiner Wahl haben. Geht aber auch mit JavaScript. Wenn du Note schreiben möchtest, geht's auch mit Note.

[20:22] Und jetzt wäre natürlich die Frage an Poly ...
Also es gibt an poli aber was gab dir oder euch die initial zündung an poli zu entwickeln also genau wie wie kam das und wann kam das ja.
Ja also auch wenn vielleicht ist irgendwie viele hörer das zum ersten mal hören es ist halt schon die freie politik die gibt es schon seit 2015 haben wir angefangen damit.
Also es ist halt entstanden so im Rahmen so meiner Tätigkeit da bei MacGyver, also ihr müsst euch vorstellen, wir machen halt vor allem so Greenfield-Projekte, also immer so Custom-Web-Applikationen, davon halt, eine ganze Menge, also wir starten da vielleicht im Jahr vier neue Anwendungen und wir hatten halt, so zu der Zeit, so Anfang der 2010er-Jahre, als so, ja

[21:11] Klar, Anfang, sehr viel schlechte Erfahrungen gemacht, so mit so Jackery-Spaghetti-Haufen, Dann sind wir mal eine Weile lang so all-in gegangen mit AngularJS und waren, dann nach ein paar Jahren auch nur so halb glücklich damit, so wie es so war und dann ...
Was hat euch da, was war der halb glücklich Faktor, Faktoren?
Ja, also einmal halt, es war so vergleichsweise extrem viel Code, ne? Also wir kommen halt so auch so aus der Ruby-Rails-Welt, da ist so wenig Code.

[21:42] Ist halt so ein ganz ... so ein Core-Value auch. Und es hat man schon gemerkt, okay, ich brauch erstens viel mehr Code, um's leicher zu machen.
Dann war's aber auch so, okay, Logik war halt ... ja, viel verteilt, also ...
Ähm ... Die Leute waren sich auch immer so unsicher, mach ich jetzt so, weiß nicht, einen Filter oder Zukunftsrechtsabfrage, gehört die auf dem Server, gehört die in den Client?
Und dann hattest du halt dann irgendwie ... Ja, halt irgendwie so fette Angular-Controller, die dann halt irgendwie über irgendwelche Wege ihre Daten bekommen haben und geerbt haben von außen und so.
Also, wir waren uns halt nicht so sicher, ob's jetzt wirklich halt das Wert war, alles.
Und ... Also, mit Wert mein ich halt vor allem so, ob jetzt so dieses Plus an User Experience ...

[22:28] Und vielleicht das Plus an, was wir als Entwickler machen können, so im Verhältnis steht zu dem, was mir erkurrt war.
Und dann gab's halt auch bei uns diesen Bruch da mit Angular 1, Angular 2. Das war damals so quasi ein Rewrite von dem Framework.
Konntest eigentlich deine Sachen wegwerfen, neu machen. Und dann war das so unser Anlass, so was machen wir jetzt?
Und dann... Ja, wenn wir eh schon wegwerfen, dann können wir auch noch mal überlegen, also was wir da nachnehmen, ne?
Ja, genau. Und dann hatten wir halt so Rätuspektive gemacht, Welche Anwendung haben wir alle in Angular geschrieben?
Wo war es eine gute Idee? Wo war es vielleicht nicht so eine tolle Idee?
Und da haben wir gemerkt, okay, bis auf wenige Ausnahmen waren wir jetzt nicht so wahnsinnig überzeugt.
Und dann fanden wir halt auch, vielleicht ist es ein bisschen unfair, wenn man auf der einen Seite sagt, irgendwie Entwickler, also früher, Entwickler machen eher random Javascript, vielleicht mit JQuery oder so, aber halt eigentlich so ohne Struktur, ohne Framework von Null.
Und dann auf der anderen Seite benutzt du halt irgendwie wie ein Framework mit zehntausenden Personentagen irgendwo bei Google entstanden. Also, es ist vielleicht auch kein Level-Playing-Field.

[23:32] Und dann haben wir uns überlegt, so können wir so ... vielleicht so diese ...
So ein paar Patterns, die man vielleicht so auch händisch mit JQuery, AJAX und so gemacht hatte, können wir die vielleicht mal ein bisschen besser abpacken?
Äh, halt mit mehr Fidelity, mit mehr Features, mit Tests, ja, auch, ne?
Also ... ja, und dann ging das halt so los, dass wir halt das erste Feature-Versäl, gemacht haben, war halt eben so Links, die nur Fragmente austauschen.
Und dann, okay, hat schon ganz gut geklappt. Und dann hat man schon gemerkt, okay, viele so Probleme, die man mit so Single-Page-Apps hat, gehen halt einfach weg, wenn man nicht bei jedem klickt, die Seite wegwirft.
Also eben halt sowas wie, ne, nehmen wir mal ein Beispiel, so ein Layout wie bei Gmail vielleicht, so Links hast du Liste mit deinen E-Mails und rechts so einen großen Bereich, wo du die E-Mail, hast, ne, und da scrollst du ein bisschen deine E-Mails runter und klickst auf eine E-Mail und dann, ja, Single, Multi-Page-App, alles wird weggeworfen, Scroll-Position ist weg und so weiter. Super doof.
Aber weil du jetzt sagst, du tauschst halt nur diesen Hauptinhaltsbereich aus, plötzlich ist das Problem nicht mehr da. Und es fühlt sich halt auch irgendwie ähnlich an.
Weil, ja, auch Gmail muss halt so warten auf irgendeine JSON-API, um deine E-Mail zu laden.
Und das kannst du eigentlich dann genauso einfach HTML laden.
Also, das ist jetzt auch so von Performance.
Ja, das kostet ja auch nochmal zusätzlich Zeit, ne? Also, das, dann ist das JSON-Empfang.
Ja, da muss das ja auch irgendwie erst mal wieder in HTML reingegossen werden.

[24:56] Genau, und dann, ja, haben wir halt dann nachher mal ein bisschen weitergesprungen.
Können wir auch Formulare damit machen? Können wir auch irgendwie Overlays damit machen?
Können wir irgendwie Links preloaden, wenn man drauf hauert und so weiter und so?
Hat sich das so nach und nach so zu einer ganz reifen Bibliothek gemausert.
Und so, dass wir tatsächlich heute überwiegend tatsächlich die Apps mit Antworten im Frontend machen.
Und via React sowas, also wir haben auch noch React im Einsatz, aber es ist überwiegend jetzt nur für einzelne Komponenten.
Also irgend so ein Rechteck, wo wir sagen, okay, hier lohnt sich auch wirklich der Einsatz.
Also ungeschlagen sind Single-Page-Apps oder so, Bibliotheken wie React natürlich weiterhin so mit optimistischem Rendering, damit meine ich so, der User macht irgendwas, und du zeigst gleich eine Änderung an, ohne überhaupt den Server zu fragen. Also nicht mal den JSON-API, du machst einfach sofort irgendwas.
Sowas wie jemand schreibt irgendwas in den Chat und checkt die Nachricht ab, und du siehst sofort, in deinem Chat erscheint deine Bubble, wo du halt die neue Nachricht hast.
Das sind halt so Cases, also jetzt zum Beispiel ein Chat, wir haben so einen Chat für Telefonsorge, der ist halt so Ende in Ende verschüttet und der sollte halt einfach auch responsive sein.
Und da ist halt dieses Chat-Rechteck, ist zum Beispiel eine React-Komponente.

[26:08] Aber alles drumherum ist wieder unpoly, also die Navigation zwischen den Bereichen der Seite oder wenn ich zwischen Channels wechsle oder so, ist halt dann wieder mit unpoly, aber wir haben einzelne Rechteck in React.
Wir sind halt da schon recht happy damit und haben inzwischen halt auch schon irgendwie signifikant Tage da rein versenkt, und hat inzwischen auch sehr, sehr viel Traffic gesehen und sehr viele verschiedene Projekttypen, sodass wir schon da ganz zuversichtlich sind, dass das schon auch jetzt nicht nur, das markantere Framework ist, sondern halt auch irgendwie allgemein für viele Anwendungen eine gute Lösung sein kann.

[26:42] Ja, also, genau, man könnte ja jetzt sagen so, okay, erzeugt das irgendwie vielleicht dann mehr Last wiederum, wenn da mehr Logik wieder vom Origin-Server irgendwie abgearbeitet werden muss.
Aber wahrscheinlich ist es gar nicht so viel mehr, als JSON-Dateien zusammenzuschreiben.
Also, ein bisschen ist schon klar. Also, HTML-Bauen dauert schon Zeit.
Also, wenn du jetzt guckst, wie lange es ein Endpoint bei dir braucht, um zu antworten, ist es halt immer, weiß nicht, Datenbank und Template-Rendern.

[27:14] Aber ein großes JSON-Bauern dauert auch Zeit. Also davon nicht vergessen.
Und du schickst halt, sagen wir mal, tendenziell irgendwie bei JSON auch zu viele Daten an Client.
Weil du kannst jetzt oft nicht irgendwie für jeden Bildschirm einen Endpoint bauen.
Oder vielleicht, wenn du sowas wie GraphQL machst, da war das dann wieder ein Backend schmerzhaft.
Insofern ist, glaube ich, das Last-Thema so vergleichbar.

[27:44] Und als Gegenzug hast du halt weniger Last auch beim Client, gerade wenn du Leute so schwächere Devices haben, die dann halt auch manchmal einfach mal 30 Sekunden stehen, während dein React Blog bootet.
Das hast du natürlich nicht, wenn du gleich mit dem ersten Request einfach HTML rausschickst.
Ja, okay. Macht auf jeden Fall Sinn.

[28:07] Und wenn wir jetzt mal so in die Lösungen reinschauen, für die ihr euch entschieden habt, also, welche Bereiche habt ihr euch denn so rausgepickt, die ihr dann mit Anpoli supercharged habt?
Es hat schon so ein paar Bauteile, damit du so ein bisschen in die Region kommst, dass es sich so anfühlt wie eine Single-Page-App.
Also das Wichtigste sind erst mal so, okay, Links sollen sich einfach schnell anfühlen. Hab ich schon ein bisschen gesagt, ja.
Du sagst halt, dieser Link soll von Anpoli gehandelt werden.
Dann kannst du sagen, so, kannst du ein Attribut sagen, ab follow us, das heißt, dieser Link soll eben nicht mit dem Browser laden, sondern halt durch Anpoli.
Oder du kannst einfach auch global konfigurieren, das heißt, alle Links handelt, und dann lädt halt Anpoli eben das Ziel erst mal einfach mit Fetch oder XHR.
Schneidet sich so dann halt meistens halt so ein Selektor raus oder wenn du nichts angibst, einfach das Main-Element, den Hauptinhaltsbereich, und legt es halt so in die Seite rein. Dann hast du halt schon mal so Vorteile.
Du verlierst nicht so den Kontext drumrum, der Browser muss nicht das HTML neu parsen, der muss nicht das CSS neu, gut, HTML muss er parsen, aber so JavaScript und CSS bleibt einfach da, ne?
Also musst nicht irgendwie wieder das JavaScript von null in den Speicher.

[29:22] Jetzt kannst du halt so Sachen machen auch, das sagst, okay, ich will jetzt eine Animation machen, das alte Element fährt links raus und das neue kommt von rechts rein oder so. Das ist halt dann wieder sehr einfach zu machen.
Dann kannst du noch so ein paar Tricks tun, wie zum Beispiel, dass du den Link nicht erst so bei Maus ablädst oder folgst, sondern schon bei Maus down.
So klingt es so irgendwie egal, aber es sind tatsächlich so 70 Millisekunden oder so, die Leute halt so auf der Maus bleiben und 70 Millisekunden, sag mal, ist jetzt.
Also nicht nichts, ne? Wenn du jetzt irgendwie den Endpoint optimierst, dann ist 70 Millisekunden schon nicht schlecht, wenn du das rausholen kannst.
Oder irgendwas, was wir auch machen, dass wir so Links preloaden.
Also wenn du schon so irgendwie drüberhaverst mit der Maus, dass schon mal so das Ziel geholt wird.
Und dann idealerweise ist es schon da, wenn der User dann halt die Maus loslässt.

[30:15] Einfach, um halt die Latenzen zu kaschieren letztendlich, ne?
Und so ein gewisses Snap in Maske zu haben. Genau.
Die eine Sache, die du nicht hinbekommst, ist dieses optimistische Rendering, dass du ohne den Server schon was machst.
Das wär irgendwas, das kannst du mit so was React tun.
Machen aber viele React-Apps auch nicht. Viele React-Apps, du klickst irgendwo hin und dann wartet der auf eine JSON-API. Du hast ähnliche Latenzen wie in dem HTML-over-the-Wire-Ansatz.
Das braucht schon extra Code, dass du dieses optimistische Rendering machst.
Weil du ja auch irgendwie brauchst wieder Code, der jetzt auch wieder zurückgerollt, wenn's nicht klappt.
Und spart man sich halt dann auch dann gern, weil ... kompliziert.
Aber das ist wahrscheinlich einfach ein Pattern, das wahrscheinlich ihr gerne benutzt bei euren Sachen.
Und, äh, genau deswegen ...

[31:06] Deswegen fällt dir das jetzt einfach ... Kommt dir das in den Sinn?
Ja, ja, genau, also das, ähm ... Genau, kommt mir in den Sinn.
Und das ist die eine Sache, die wir nicht haben können, wenn der Server sozusagen immer gefragt wird.
Aber wir können es halt irgendwie so in den Bereich bringen, wo es sich halt so quasi instantan anfühlt, wenn man irgendwo draufklickt.
Und das ist dann auch so der Bereich, wo es wieder okay ist.
Weil ich glaube, es ist schon weiterhin so, dass du, sagen wir mal, die beste Fidelity in der UI bekommst du über den Single-Page-Ansatz.
Aber die meisten Teams und BGs erreichen das nicht.
Und die durchschnittliche React-Anwendung oder Single-Page-App ist, glaube ich, nicht so gut wie die durchschnittliche Anwendung in dem HTML-Overview-Bio-Ansatz.
Weil du einfach so viel weniger brauchst, um so die UI-Erfahrung schon sehr okay wird. Ja.

[31:56] Was wir auch machen, ist, dass wenn du im Link folgst, dass wir so die Antworten für eine Weile cachen.
Sodass, wenn du noch mal dahinten navigierst, dass du einfach halt die Antwort schon hast.
Also aktuell cachen wir jetzt tatsächlich so für 90 Minuten.
Und dann gehst du halt drauf, also gehst du auf irgendeine Seite, wo du schon mal warst, dann bekommst du sofort die Antwort natürlich.
Und dann wird sie halt nochmal im Server revalidiert. Das heißt, dann wird nochmal, also eventuell, wenn zum Beispiel, sag mal, du lädst eine Liste mit Datensätzen und dein Kollege hat aber währenddessen auch schon mal was geeditet, dann siehst du ganz kurz sozusagen so die Cache-Liste, und dann wird sie das aktualisieren mit der Variante vom Server.
Also auch ein nicht eine optimistic UI-Ansatz.

[32:36] So ein bisschen, ja. Zumindest, wenn du bestehende Seiten nochmal irgendwie neu anguckst.
Und hat auch Vorteile, wenn du zum Beispiel irgendwie offline gehst, damit du fährst in den Tunnel oder bist bei der Deutschen Bahn unterwegs, dann kann es ja mal passieren, hab ich gehört, dass mein Internet weg ist.
Und dann hast du halt weiterhin die Möglichkeit, dass du so die bestehenden Seiten nochmal nutzen kannst, ja.
Und also kannst du sogar so ein Handling hinterlegen, was soll passieren, wenn eine Seite im Finale nicht aufrufbar ist.
Da ist ja auch so das Default-Verhalten von Multi-Pitch-Apps nicht so cool.
Also wenn du mal offline gehst und du klickst auf einen Link, plötzlich platzt alles weg und du hast die Seite verloren.
Kennst du das? Das gibt's in den Saurier bei Chrome und so. Ja.
Eigentlich will ich ja in dem Moment lieber noch das behalten, was ich schon hatte.
Und vielleicht seh ich noch irgendwie im Exo eine Meldung, ey, bist gerade offline oder so, das ist eine viel nettere Erfahrung. Ja.
Ich meine, das Nächste, was wir angegangen sind, sind natürlich die Formulare.
Das ist auf jeden Fall auch ein heißes Thema, ja. Ja, genau.
Also sicher so Painpoint-Sachen wie, dass du halt Eingaben validierst, während der User noch auf dem Formular ist.
Also nicht erst so die Formulare abschicken musst, um zu sehen, was passt, was passt nicht.
Da haben wir einfach so ein Attribut eingefüllt, das heißt up-validate, also die Attribute heißen immer so up-, irgendwas.

[33:59] Hängst du zum Beispiel an Formular oder an einzelne Felder und dann wird so das, beim Ändern vom Formular, wenn du aus dem Feld rausgehst, wird halt so diese Formulargruppe vom Server aktualisiert und dann siehst du halt gegebenenfalls schon eine Fehlermeldung direkt dann.

[34:14] Eine andere Sache, die du vielleicht schon mal gehabt hast, so Formulare, wo so alles von allem abhängt.

[34:25] So was irgendwie so, ich weiß nicht. Wenn du das anhakst, dann klappt die Gruppe auf und darin sind dann aber Required-Felder.
Die sind aber nicht mehr required, wenn man dann oben den Haken wieder wegnimmt und das dann wieder alles einklappt.
Genau, oder die Werte in einem Select hängen ab von den Werten von einem anderen Select. So, weißt du, du hast zwei Select-Felder, eine für die Abteilung und dann in einem Select die Mitarbeiter von der Abteilung.
Und dann musst du dich beim Ächsel der Abteilung, solche Sachen, oder ein Preview irgendwo.
Und das lässt sich aber auch mit dem gleichen Attribut lösen, also das UpValidate nimmt einen Selektor und dann sagst du, wenn sie dieses Feld ändert, bitte lass den Server dieses andere Fragment austauschen.
Also sagst du zum Beispiel am Feld für, vorhin hatten wir Abteilung, sagst du UpValidate, weiß nicht, Employees oder so und dann wird er beim Ändern von der Abteilung, wird er dann die Mitarbeiter einfach neu laden.
Und, äh, meine Frage dazu wäre, also, wenn man das macht, also, ist es dann so, dass der Endpunkt beim Server dann im Grunde das gesamte HTML zurückgibt und sich dann Anpoli eben nur diese Bestandteile dann wieder herauspickt, um die dann einzusetzen?
Oder muss ich auf dem Server dann auch tatsächlich nur dieses eine Feld dann irgendwie ausgeben können? und hat Unpoly da irgendwie so spezielle URLs oder Parameter, dass man das so verweist?
Also, es ist ja so, also ...

[35:49] Also, Unpoly wird in dem Moment einfach das Formular abschicken, an die Action vom Formular.
Und dann gibt's noch so einen Header mit, wo drin steht, so xUpValidate, und da steht drin, bitte nicht abspeichern, nur validieren.
Also sprich, du machst die Validierung, die du auch abschicken machen würdest, aber am Ende tust du's nicht, sondern renderst nur das Formular.

[36:08] Per Default immer ganze HTML-Dateien gerendert. Okay.
Nicht irgendwie Fragmente. Also, der Server kann sich entscheiden, dass er nur das rendert, was angefragt ist.
Dafür gibt's auch einen Header, der heißt xupTarget. Da steht so ein Selector drin.
Wenn der Server das sieht, kann er sich entscheiden, ich rendere nur das Target.
Am Ende wird der Handpulli sowieso alles andere wegwerfen.
Das ist zum Beispiel bei HTML ein bisschen anders. Per Default wird er eher erwartet, dass du jetzt Fragmente ... Also, nur die angefragten Fragmente renderst. Aber eben...
Genau, dann ist quasi euer Ansatz nicht maximal optimiert.
Also, von der Approach ... Du kannst optimieren, aber es ist halt deine Frage.
Würdest du es schwer machen, wenn's einen Performanceunterschied macht?
Weil die meiste Zeit, hey, egal, dass noch irgendwie der Head dabei ist.

[36:55] Ähm, aber zum Beispiel, sag mal, du hast irgendwie eine superfette Navileiste, so, weiß nicht, so mit 100 Ebenen, und das kostet signifikant, die zu rendern, dann würde man sich die halt sparen, wenn man sieht.

[37:07] Es wird gerade nicht das ganze Dokument angefragt, sondern halt nur ein Teilfragment.
Aber es ist eine Optimierung, die man halt machen kann, wenn es dann zu langsam wird. Ich würde es nicht per Default machen.
Naja, im ersten Schritt ist es tatsächlich so, dann wirklich deutlich leichter, serverseitigen Code zu machen, ne?
Ja. Ja, es ist halt auch so, weißt du, wenn du nachher hast, sag mal, wir gehen mal zurück zu den Links.
Weil ich will halt eigentlich auch, dass, wenn der Link gefolgt wird, sich die URL ändert.
Und dann kann es ja auch sein, dass der User die URL einfach nimmt und im neuen Tab aufmacht oder später noch mal reloaded.
Oder muss der Server in dem Fall ja schon mit einer vollen HTML-Seite antworten können.
In diesem Fall bekomme ich halt erst mal geschenkt, wenn ich sage, der Server macht schon einmäßig einfach volle HTML-Seiten.
Während ich das Fragmenten rendere, hab ich immer diesen Fall, wenn Fragment, dann so, sonst anders oder so.
Und dann vergess ich's bei irgendeinem Endpoint und dann hast du irgendwas in der URL stehen, was walk-in-URL ist oder was nicht, was jetzt irgendwie alleine keine sinnvolle Antwort generiert.
Ja, macht absolut Sinn. Und deswegen auch wahrscheinlich die HTTP-Header, weil öffnet man dann, so sagen wir mal, würde man den Server so auslegen, dass wenn dieser HTTP-Header, da ist, er dann eben nur diesen Abschnitt rendert, den Angefragten, dann könnte jemand dennoch diese URL kopieren, den Browser eingeben, der Browser würde diese Ressource aber eben ohne dieses Target.

[38:27] HTTP-Header anfragen, und dann wüsste der Server, okay, dann muss ich den ganzen Apparat rendern. Genau.
Genau, das sind halt so ein paar Vorteile, die du bekommst, wenn du halt sehr so auf diese Progressive-Enhancement-Schiene setzt, dass halt viele Browser-Funktionalitäten, einfach weiterhin funktionieren. So Reload, Backbutton.
Und für SEO wahrscheinlich auch nicht schlecht.
Ja, genau. Für die abfäulende Seite. Ja.
Ja, also mit dem App-Validate kriegst du tatsächlich irgendwie sehr viele.

[38:57] So Formulare aus der Hölle sehr gut in den Griff.
So klappt auch alles, auch wenn der User irgendwie wild rumklickt und während der Server noch lädt, macht er weiter Renderung und soweit.
Das ist alles immer konsistent, das ist relativ ausgeklügelt gemacht.
Eine Sache, die wir dann so in Ampli 2 angegangen sind, sind so das Thema, wenn du so Overlays hast, hat man relativ oft in Designs, dass du halt hast irgendeinen motoralen Dialog und rechts.

[39:28] Ich weiß nicht, rechts fährt irgendwie eine Leiste rein mit der Navi oder irgendwas.
Und natürlich gibt's da superviele Bibliotheken, die dir so ein Modal öffnen.
Oder auch den Dialog in HTML gibt's dazwischen auch, ne?
Aber die hören immer meistens so auf, damit der Dialog geht auf.
So, und dann ist es so, jetzt hört die Idee auf.
Was uns halt da sehr interessiert, ist, was ist, wenn ich in dem Dialog zum Beispiel jetzt wieder eine mehrseitige Interaktion hab?
Also zum Beispiel irgendwie habt ihr irgendeine Auswahl, und da kommt ein Formular und das Formular kann eine Validierungsfehler haben.
Und da ist es halt so, dass diese Layer heißen, die Ampoli, also die Seite selbst ist ein Layer, der rote Layer, und dann kann ich wieder beliebig viele Overlays drüber stapeln.
Und ich habe immer die Garantie, dass die Interaktion im Overlay auch da drin bleibt.
Also das heißt, wenn ich zum Beispiel im Overlay einen Link folge, dann wird der Link in dem Overlay weiter bleiben, bis ich ausschließlich sage, ich möchte jetzt das Overlay schließen.
Das macht sehr viel Schmerz weg und so ein Feature, was wir ...
Okay, da muss ich ein bisschen ausholen. Wir haben so ein Feature, das heißt Subinteractions.
Weil du hast ja nicht nur das Problem, dass du jetzt eine mehrstoffige Interaktion im Overlay hast, aber du willst ja vielleicht am Ende auch wieder zurückkehren zu dem, was du eigentlich mal in der Ebene davor gemacht hast.
Sagen wir mal, du hast irgendwie so ein Checkout-Formular.

[40:51] In einem Shop und dann wählst du da deine Lieferadresse aus.
Und dann geht da irgendein Overlay aus. Und dann kannst du eine Adresse auswählen oder neue anlegen.
Und dann musst du ja, wenn du fertig bist oder meine eigene Adresse ausgewählt hast, musst du irgendwie ihren Weg wieder finden, so in dieses Bestellformular, was da immer noch im Hintergrund offen ist.
Und ich glaube, das haben wir sehr, sehr cool gelöst. Weil was du da machst, ist, dass du sagst, hier im Checkout-Formular sagst du, hier, dieser Link öffnet das Overlay mit den Lieferadressen, und dann kannst du so eine Bedingung angeben, wie lange das Overlay offen bleiben soll.
Beispiel kannst du sagen, es soll so lange offen bleiben, bis du ein gewisses URL-Muster erreicht hast, zum Beispiel den ShowView von Lieferadresse, oder es bleibt so lange offen, dann bis ein Event auf dem Overlay ausgelöst wird.
Und wenn das so ... Man kann so sagen, wenn das Overlay zu Ende ist, also sozusagen diesen Ziel schon erreicht hat, dann schließt es automatisch und gibt mir mit, wo es aufgehört hat.
Und dann kannst du zum Beispiel sagen, ich ändere jetzt die Lieferadresse in dem Checkoutformular, was im Hintergrund offen ist.
Und das erlaubt es einmal, dass ich zwischen den Layern auch eine Kommunikation habe.
Und die andere Sache, die es mir erlaubt, ist, dass ich einfach so Interaktionen, die ich eh schon habe und kann, also die ich eh schon gebaut habe, noch mal in einem Overlay verwenden kann. Also, wenn wir noch mal das Beispiel nehmen mit dem Checkout-Formular.

[42:18] Du hast wahrscheinlich eh schon irgendwo so einen Crud für deine Lieferadressen, eh schon gebaut, außerhalb vom Checkout-Formular.
Jetzt kannst du einfach sagen, okay, in meinem Checkout-Formular verlinke ich die bestehenden Oberflächen und öffnen die in einem Overlay.
Und dieses bestehende Lieferadressen-Crut muss gar nichts wissen, dass es jetzt im Overlay läuft. Es muss nicht irgendwie wissen, wenn Overlay, dann das, sonst nicht.
Sondern es wird einfach ganz normal sein Ding tun. Ich hab ja beim Öffnen vom Overlay gesagt, wenn diese Zielbedingung erreicht ist, dann schließ dich und sag mir, wo du aufgehört hast.
Und so kannst du einfach halt so Sachen auch aneinanderschachteln, einfach wiederverwenden.
Und hast halt auch hier nicht irgendwie so den Fall, wenn Overlay dann so ist und so.
Das hat so dieses ganze Thema für uns extrem vereinfacht und erlaubt sich halt auch irgendwie extrem komplexe Sachen.
Also Sachen, wo du schon so das Design siehst und so, ah, fuck, äh, sorry, also, das wird schwierig.
Werden halt da halt extrem einfach dadurch. Weil du halt irgendwie so Overlays eher siehst wie so eine Promise, die am Ende halt so einen Wert hat.
Oder halt entweder ein positives Ende oder ein negatives Ende, wenn du aufs X klickst.
Und vielleicht so das letzte Thema, was wir viel nutzen, ist eben so Compiler, habe ich vorhin schon mal kurz benannt.
Das ist, wenn du halt so noch so kleine Sprinkles hast, die du brauchst an der Seite, zum Beispiel eine Custom-Komponente.

[43:46] Oder halt irgendwie dann ein anderes, noch ein neues Attribut, was du einfügen willst, was, weiß nicht, ne Gruppe von Feldern Read-Only macht oder irgendwas automatisch scrollt oder so, dann kannst du halt sagen, ich hinterlege so einen Compiler, sagst du halt hier, für alle Elemente mit diesem Selektor, also der Selektor soll halt ver.java-sub ausgeführt werden.
Und das ist so ein bisschen wie vielleicht Custom Elements, nur halt, dass du es halt mit beliebigen Selektoren machen kannst, nicht nur mit neuen Elementen, sondern auch bestehenden Elementen.

[44:17] Und das ist auch so ein bisschen unsere Extension, unser Extension-Mechanismus, wenn du irgendwas willst, wo es halt jetzt kein fertiges Unpoly-Attribut gibt, dann ist es so, dass fast alle Funktionen, die es in Ampli gibt, sind immer so auch als JavaScript-Funktion verfügbar.
Also es gibt zum Beispiel, ich habe vorhin gesagt so, dieses Attribut up-follow, aber es gibt auch eine JavaScript-Funktion, die heißt up.follow, nimmt halt ein Link-Element und halt ein Hash mit Optionen.
Und so kannst du halt, sagen wir mal, dir auch so ein bisschen so das zu Ende bauen, wenn du sagst, du hast noch so deinen spezifischen Dialekt von Attributen, die du in deinem Projekt gern hättest, dann kannst du das einfach noch, dazuhängen, in den Compiler hängen und dann kriegst du halt die Garantie, die Compiler laufen sowohl beim initialen Pageload als auch wenn du neue Inhalte nachlädst.

[45:02] Und da macht ihr im Prinzip, also nutzt ihr dafür Mutation Observer oder macht ihr dann einfach einen Query-Selektor dann quasi auf den Scope, den ihr gerade ausgetauscht habt?
Ähm, also aktuell machen wir es immer tatsächlich noch, ähm, also händisch immer dann, wenn wir, wenn Unpoly irgendwo Inhalte einfügt.
Und, ähm, wenn du selbst jetzt, wenn du selbst Inhalte produzieren würdest, gäb's schon eine Funktion ab Hello, wo du das, das, äh, das machen, auch selbst machen kannst, ähm, aber ... Ich hab die Überlegung, ob wir's mit Mutation Observer machen wollen.
Es ist so ein bisschen ... Also, einmal ein Performance-Thema.

[45:39] Und bei Mutation Observer kann's sein, dass du manchmal, gerade wenn Leute so nach und nach den DOM bauen, dass du so mehrere Aufrufe kriegst, das ist dann manchmal ein bisschen schwierig.
Und wir halt so sehr viele Garantien abgeben, in welchem Zustand ist so der DOM, wenn die Compiler aufgerufen werden.
Also, wäre so was wie zum Beispiel, die History wurde schon verändert und so weiter. Und das ist ein bisschen schwerer zu kontrollieren, wenn wir es mit Notation Observer machen, weil natürlich die Notation Observer halt sofort feuern, sobald wir Elemente in DOM laden.
Und dann, ähm, aber, äh...
Im Endeffekt macht's jetzt keinen Riesenunterschied. Hat mich nur so interessiert. Ja.
Und was für Use Cases hat man, um sozusagen den Sprachumfang, also das Annotationsvokabular zu erweitern, wie du eben meintest.
Also, was ist denn so ein typischer Use Case, wenn man da irgendwie dem App noch weitere Dinge beibringen wollte?
Hast du dann ein Beispiel aus der Praxis?

[46:44] Du hast irgendwelche komplexeren Hotkeys, so mit, weiß nicht, Control-K oder so, soll irgendwas tun, und dann würdest du das gerne als Attribut am Element machen. Untertitel der Amara.org-Community, Okay, kannst du einen Compiler machen, der das halt irgendwie ausliest und dann halt entsprechende Listen registriert oder... Okay.
Wir haben so ein Text-Area für so einen Markdown-Editor und die soll halt noch so ein bisschen Markdown-Aware sein, dass ich weiß nicht, bei Listen-Einträgen, wenn, du Enter, drückst, dann nochmal gleich schon so den nächsten Listen-Eintrag präfixt oder, dass du mit Tab-Sachen einrücken kannst oder so.
Also wo du halt so bestehende Elemente so ein bisschen verändern möchtest, ohne sie komplett zu ersetzen, das geht halt sehr gut mit der Compiler-Logik.
Also weil dann muss ich nicht irgendwie mir neue Text-Area-Komponente, erdenken.

[47:34] Oder so, sondern kann einfach die vorhandene nehmen und die ein bisschen erweitern.
Ja. Und andere Use-Case ist sowas wie natürlich so Bibliotheken.
Ich hab vorhin schon gesagt, du willst so eine Custom-Select-Box haben, oder dir gefällt der Datepicker nicht von InputTypeDate und sagst, du willst, dass lieber dein Datepicker aufgeht.
Das wäre natürlich dann auch immer ideal, dass du in einem Compiler einfach dann sagst, wenn du mal ein InputTypeDate in DOM kommst, dann bitte, dann capturst du halt irgendwie den Fokus-Event, oder so und öffnest dann deinen Datepicker.
Ok.
Und dann wäre meine Frage, also du hattest ja eben erwähnt, dass hier Anpoli Version 2, also dass Anpoli mindestens in Version 2 existiert, ist das auch die aktuelle Version von Anpoli?
Aktuell ist 3.3 und die nächste große kommt jetzt Anfang November raus, also das ist dann Anpoli 3.5.
Kann sein, dass die Hörer das dann schon vor sich haben.
Das ist gut möglich. Ja, genau.
Ampoule 2 hat vor allem diese ganze Sache mit dieser Layer-Isolation gemacht, dass man halt nicht mehr aus Layern ausbrechen kann.
Und so ein großes Thema bei Ampoule 3 war vor allem so.

[48:52] Nebenläufigkeitsprobleme, die du halt auch hast, wenn du sowas händisch baust mit JackRay. Ja, was ist, wenn du ein Fragment austauschst und während des Layers klickt der User schon das nächste Ding an und will auch wieder was austauschen.
So diese Probleme haben vor allem alle in Ampoule 3 gelöst.
Das ist dann, wo die drei halt auch so ein Konzept kennt, wie das halt so Bereiche abgebrochen werden, wenn man irgendwo, äh, parallel laufende Anfragen hat.
Also auch wieder so Sachen, die man gar nicht drüber nachdenkt, wenn man halt so in diesem Multi-Patch-Dokumentenaustausch-Welt.

[49:20] Lebt, wie viel der Browser halt eigentlich für dich tut. Ähm, und, ähm, aber ich hab das Gefühl, dass wir das langsam so ganz gut erschlagen haben.
Er grad so mit Edge-Cases im Real-World-Einsatz dass irgendwie Leute klicken will, diese Seite, Verbindung geht weg und so weiter.
Das ist, glaub ich, inzwischen sehr, sehr gut implementiert.
Und wie handhabt ihr das mit, also, backwards compatibility?
Also, ist es grundsätzlich dann einfach zu migrieren von Major Version zu Major Version?
Oder ist das ein Stück weit Arbeit? Oder ist es viel Arbeit?
Also, wir hatten so einen großen Bruch. Das war halt so von Version eins auf zwei.
Da war es so ... Okay, es war halt noch relativ jung, und da mussten wir halt wirklich mal so einen großen Bruch machen, um so die ganzen Fehlentscheidungen mal zu korrigieren am Anfang.
Ich glaube, seitdem ist es relativ smooth. Wir haben so einen Polyfilter, Polyfilter heißt unpolymicrojs.
Ähm, im Endeffekt sind dort so für alle JavaScript-Funktionen.

[50:28] Attribute, Events, die es nicht mehr gibt, sind da überall Polyfills drin, dass die automatisch ähm, dann halt, äh, äh, sozusagen die neuere Entsprechung davon für dich aufrufen.
Dann schreiben sie halt noch so eine Warnung ins Log, hey, pass auf, du hast die alte Funktion benutzt, du hast die Art.replace benutzt, bitte benutzt Art.render.

[50:48] Und, ähm, wenn wir jetzt zum Beispiel ein Projekt upgraden, was wir machen, ist, wir laden diesen Polyfill, ähm, lassen Test-Suite laufen.
Die Test-Suite stößt halt ab, wann immer eine Warnung im Log ist.
Dann fixen wir die. Am Ende ist es ein relativ mechanischer Prozess.
Ja. Ja, und natürlich benutzen die eure Nutzerschaft, nutzt natürlich dann das Migrate-Ding bis zum bitteren Ende.
Und erst dann wird das natürlich dann alles umgebaut. Das ist ja auch klar.
Ja, also bisher haben wir noch nie was aus dem Polyfill ausgebaut.
Ja, und ihr braucht einen Polyfill dann für den Polyfill, wenn ihr die wiederum nächste Major Version habt.
Ja, okay, aber das klingt doch super.
Und wie ist das so mit Dependencies? Hat UnPoly viele Dependencies oder überhaupt welche?
Weil das ist ja so ein Stück weit, ich sag mal, der Fluch der modernen Entwicklungswelt, dass man in so einer Dependency-Hölle, irgendwann landet und einem alles um die Ohren fliegt nach einem Jahr oder so.

[51:58] Ja, so aktuell hat es keine Dependencies. Das ist auch so ein Designziel, keine zu haben.
Also ganz, ganz früher, so vor acht Jahren war es mal jQuery, das haben wir inzwischen dann irgendwann raus runtergespritzt.
Aber hat gar keine Dependencies und soll eigentlich auch so bleiben, einfach aus den Kunden, die du genannt hast.
Macht halt auch so ein paar Sachen möglich, wie dass du vielleicht auch mal eine kleine strategische Seite hast, wo du auch vielleicht überhaupt keine Build-Pipeline, hast für dein Freund, dein Kram.
Und sobald du halt anfängst, Das Ding ist, ein ESL-Modul mit Abhängigkeiten, brauchst du halt irgendwas, was es lädt, oder?
Und im Endeffekt kannst du jetzt im einfachsten Fall, wenn du's ausprobieren willst, einfach über einen CDN als Script-Tag in dein Head hängen, und dann ist es halt da.
Sehr, sehr angenehm. Also, das ist so. So war's früher, und das war schon sehr schön.
Also, ist ja auch immer toll, ein modernes Projekt aufzusetzen, aber ich denke, viele kennen das, das ist, wenn man dann nach ein, zwei Jahren wieder irgendwie was am Projekt aktualisieren muss.
Also ich weiß noch, dass ich auch so ein Projekt hatte, da hatten wir auch eine Google-Maps-Karte drin und irgendwann haben die ja eingeführt, dass man Keys brauchte.
Also da konnte man dann nicht Google Maps nutzen.
Und dann, also es gab im Grunde keinen Anlass, aber einfach so, Google hat seine Bedingungen geändert, wir mussten diesen Key da einbauen und es war einfach nicht mehr möglich, dieses Projekt an den Start zu kriegen, es ging einfach nicht.

[53:22] Das ist schon schlimm. Ja, also ich hab ja vorhin ein bisschen noch gesagt, so, okay, irgendwie viel Komplexität hörst du dir mit dem Single-Page-Fail.
Oft ist die Komplexität gar nicht so in dem Ding, was du so direkt benutzt.
Also jetzt das React oder das Angular und das ist halt so der ganze Kram, den du auch noch brauchst.
Und mit dem Drumrum oder halt vielleicht einfach auch deine Build-Pipeline selbst, dass halt irgendwie das Webpack nicht mehr hochkommt, wenn du es halt nach zwei Jahren wieder anmachst.
Oder das kann er nicht mit der Note oder keine Ahnung, ihr kennt das alle, das macht so ein bisschen so dieses...
Dieses dieses dieses wolkneufühling auch dann aus was man halt dann oft in dem ökosystem hat oder vielleicht bin ich gut mit javascript oder so.

[54:07] Pflichtig hierbei ich glaube das also ich glaube nicht dass da jemand sagen würde das team nicht so wäre also ich mein klar wenn man ständig irgendwie arbeitet die maintenance steckt dann dann ist das okay, aber wenn man auch wenn man das eben nicht möchte wenn man irgendwas stabiles gerne haben möchte, dann kann schon arg nervig werden.
Ja, gut. Wir merken es halt relativ viel in der Arbeit, weil wir halt, wir haben halt irgendwie, wir machen halt viele Anwendungen und maintainen die halt dann auch teilweise zehn plus Jahre und, entsprechend switchen wir halt auch mal wie immer wieder in ein altes Projekt rein, wo vielleicht auch mal zwei Jahre nichts geschehen ist und es muss halt einfach gehen, dass du es dann wieder aufmachst und dass du nicht erstmal einen Tag lang irgendwie deine Entwicklungsumgebung debugst.
Ja.
Cool.

[55:00] Klingt auf jeden Fall super. Ich werd's definitiv auf dem Schirm halten.
Und ich bin gespannt, wann und in welchem Kontext ich das dann mal zum Einsatz bringen kann.
Ich bin halt meistens in so einzelnen, sehr, sehr langlaufenden Projekten.
Das heißt, ich switche jetzt nicht so oft, wenn ich jetzt so in eine Agentur wäre.
Das sind ja immer so die perfekten Umfelder, um alle drei Monate mal wieder sozusagen einen Baustein auszuwechseln und sich den anzuschauen.
Also so habe ich es zumindest früher immer gemacht in Agenturen.
Immer so die ganzen Bausteine von vorher bis auf einen bleiben gleich, weil man muss sie noch irgendwie abliefern und dann so, da muss man dann mit dem arbeiten, was man kennt.
Aber einen Baustein, so den konnte man sich immer rauspicken und den vielleicht mal durch einen anderen auswechseln und gucken, wie sich das so anfühlt.

[55:52] Genau, also...
Freu ich mich schon drauf. Abschließende Frage vielleicht noch.
Wir könnten noch einmal kurz eingehen auf HTMX und Unpoly.
Beide Projekte sind ja, wie ich das verstanden habe, so in der Vordiskussion freundschaftlich verbunden.
Also, der MaxMensch macht auch quasi für euch und für andere ähnliche Frameworks Werbung.
Wobei, so viele gibt's jetzt, glaub ich, nicht, die so komplett backend-agnostisch, sind, oder? Gibt's viele?
Ja, weiß nicht, gibt da irgendwie, weiß nicht, boah.
Bisschen unbekanntere Sachen. Aber ich glaub, das sind schon so die beiden Platzhirsche.
Erdec, also der HMX-Typ, der hat zwar einen ziemlich wilden Twitter-Account, aber er ist eigentlich ein echt super lieber Kerl.
Ich glaub, das ist so ein Cowboy-Typ, oder? So halber.

[56:44] Ja, was ist das? Da sitzt, glaub ich, irgendwo ein Montaner oder so.
Ja. Teilzeitkauf und die andere Teilzeit macht er halt, irgendwie hat er nix.
Und dem geht's halt vor allem darum, einfach so, dass der Bewusstsein da ist, dass es halt Alternativen gibt.
Und, ja, so wichtig ist so, weil jetzt so, wie sagt man das?

[57:07] Also, der ist ein Verfechter eher dieses quasi, dieser Framework oder dieses Konzept letztlich. Letztlich.
Ja, hat er mir immer super gehalten. Ja, genau. Und machte eben auch immer wieder Werbung, so, hey, schau mal, hier gibt's noch andere Ansätze.
Und er ist eigentlich so unsere Marketingabteilung, weil wir halt mit Ampuli selbst sehr wenig Marketing machen.
Okay, du hast wegen Unterschieden gefragt.

[57:34] Also, also Hardtermix ist auf der einen Seite halt insofern ein bisschen flexibler, weil du halt wirklich so alles machen kannst.
Also es hat jetzt nicht so diesen progressive enhancement-Ansatz, sondern da ist wirklich so die Idee, was ist, wenn jedes Element alles bei jedem Event machen kann?
Was ist, wenn das Diff beim Scroll eine Attache-Request macht?
So, okay, sowas würde es nie in einem PuTTY geben. Also, weil Diffs machen keine Requests.
Und es gibt auch keine, sagen wir mal, es gibt auch keine graceful degradation für die Idee.
Aber da ist halt, das ist halt so ein Ding, oder du kannst auch mit Antworten halt viel flexibler umgehen. Du kannst sagen, nimm die Antwort und platziere die ganz woanders hin oder schieb die nochmal durch irgendein Template.
Das geht bei HTMLX dann alles anders?
Ja, genau. Da kannst du wirklich viel weniger Ahnung darüber, was für HTML du ablieferst, ob du ganze Seiten lieferst, ob du Fragmente ablieferst.
Ähm, vielleicht so einen großen Unterschied, den wir so immer den Leuten sagen, also, weil der Karsten, also ich, wenn es darum geht, was der Unterschied ist, so, dass Ampoule immer versucht, eher so high-level zu sein, als auch, und HTMLX immer versucht, eher so die low-level-API.

[58:47] Ähm, anzubieten. Also mal vielleicht so ein Beispiel, ja, ähm, klar, du kannst mit HTMLX auch ein Overlay öffnen, aber das ist halt eher so, weiß nicht, so, du zeichnest halt dein HTML in irgendein Rechteck rein, und das hat halt Fixed Positioning oder so.
Und bei Unpoli würde ich sagen, mach jetzt bitte ein Overlay.
Und weil ich aber auch weiß, dass es ein Overlay ist, kann ich halt sagen, ich isoliere den künftigen Inhalt jetzt in dieses Rechteck rein, ich hab eine Focustrap, damit ich nicht irgendwie den Hintergrund fokussiere.
Wenn ich's zumache, fokussiere ich, wie ein Link jetzt aufgemacht hat.
Solche Sachen, die ich halt irgendwie machen kann, wenn ich ein High-Level-API hab.

[59:24] Aber die ich halt nicht machen kann, wenn ich nur sehe, okay, der zeichnet irgendwie jetzt Inhalte in den Rechteck rein.
Und das finde ich übrigens echt super, also Accessibility haben wir jetzt ja so nicht direkt benannt, aber genau, also ja, dass eben nur Link-Elemente, upgegradet werden können zum Beispiel, damit man zumindest so diese ganzen semantischen Rollen irgendwie auch damit verknüpft hat und vielleicht auch eben die User Experience, die man eben gewohnt ist, dass man irgendwie mit Enter und der das öffnen kann, auch mit dem Keyboard und so Sachen.
Du kannst natürlich immer dazubauen, also wenn du sagst, man kann immer alles dazubauen.
Dann kannst du alles zubauen, das sich über so verhält, aber du musst halt auch dazubauen, sonst... Genau, und HTMLX erfordert es nicht von dir, dass du das dann auch dazubaust wahrscheinlich.
Also das ist halt irgendwie so, du kannst machen, wie du willst, aber es ist dann manchmal ja eben auch nicht förderlich, wenn man alles machen kann, was man will.

[1:00:29] Genau, ja. Also entweder brauchst du halt irgendwie, entweder ist es dir egal, oder du brauchst halt deutlich mehr Disziplin, um das dann auch durchzuhalten.
Und da kriegst du halt ein paar Sachen einfach geschenkt, wenn du sagst, du verwendest halt irgendwelche Sachen, die im Browser eh schon drin sind. Ja.

[1:00:42] Ja, cool. Eine Sache hab ich mir noch gedacht.
Also, ich hab so ein bisschen mich mit Sustainable Web Design beschäftigt.
Da spielt das natürlich auch so ein bisschen rein, ne? Weil irgendwie das zumindest auf den Clients dann leicht gewichtiger ist.
Und da wollte ich nur sagen, dass ich auch glaube, dass wenn man so in die Richtung sich begibt, da irgendwie ein bisschen grüner werden möchte, dass solche Konzepte wie eures eben auch hilfreich sind, weil bei deinem eigenen Server, da hast du eben sozusagen die Entscheidungsgewalt darüber, zum Beispiel, bei welchem Hoster du bist, mit welcher Energie dieser Hoster arbeitet.
Also ist das ein Greenhost oder nicht?
Und je mehr Logik du eben dann auf dem Server lässt, desto grüner ist ebenso der gesamte Lifecycle deiner Anwendung.
Und das ist eben bei SBAs nicht der Fall, die dann irgendwie fleißig auf irgendwelchen Clients rumackern, bei denen irgendwie gar nicht klar ist, mit was die eben letztlich befeuert werden.
Also mit Kohle oder mit irgendwie Gas oder doch Solarenergie. Energie.
Man weiß halt nicht, was die eigenen Besucher schafft, was bei denen aus der Steckdose kommt.

[1:02:04] Wollte ich nur gesagt haben, es ist jetzt nur ein Aspekt, überhaupt nicht der wichtigste, aber das ist so ein Gedankengang, den ich da auch hatte in dem Kontext.
Ja.
Ja, super. Ich würde sagen, da haben wir einen guten Abriss hingekriegt.
Sowohl von HTML over the Wire, von UnPoly im Speziellen, aber eben auch einen Blick irgendwie so in HTMX geworfen.
Genau, und wir werden auf jeden Fall noch ein paar Links in unsere Schaunotizen streuseln.

[1:02:41] Und ja, wenn man Fragen hat, dann also Anlaufstelle, die Nummer eins ist natürlich die Anpoli-Seite.
Da ist ja sehr viel Dokumentation und Demos gibt's auch.
Und auch nochmal deine Präsentation, sozusagen deine, ja, wie soll ich sagen, deine Elevator-Pitch-Präsentation, die, aber sehr lange Elevator-Fahrt ist. Ja, genau.
Das ist damals immer so zweiteren Punkt und einmal so. Genau, das ist eher so im Burj Dubai oder Burj Al Arab, so eine Aufzugsfahrt.
Also schon mehr Slides, aber sehr interessant.
Da kann man sich auf jeden Fall nochmal durchklicken.
Genau, und sonst würde man dich oder euch finden auf welchen Plattformen für Fragen und für Vernetzung?

[1:03:28] Genau, also mich, Henning, ich bin triskveline auf GitHub, auf Twitter, triskveline.de, da könnt ihr auch noch, wenn es euch irgendwie interessiert, was ich sonst noch mache, Talks, solche Sachen, könnt ihr abrufen.
Verlinken wir. Genau. Ist hier auch ein paar Beispiele, wenn ihr euch mal anschauen wollt, was kann man damit machen.
Auf Makandra.de, das haben wir so ein Portfolio, die Sachen sind fast alle da mitgemacht.
Könnt ihr ein bisschen spicken.
Und falls das jemand wirklich mal ausprobieren möchte und irgendwie, weiß nicht, irgendwo hängt oder so, dann E-Mail schreiben oder auf Twitter eine DM schreiben, nehm ich mir gerne die Zeit.
Vielleicht ein paar Fragen zu beantworten oder euch irgendwo zu debuggen.
Und seid ihr interessiert an irgendwie so Showcase-Sachen?
Also habt ihr das auch bei euch auf der Seite, dass irgendwie so Projekte, die mit Anpoli gemacht sind, irgendwie featured oder verlinkt oder so?

[1:04:27] Haben wir aktuell nicht, aber wenn jemand sagt, er hätte das, würde ich gerne platzieren. Okay.
Wunderbar. Dann bleibt mir nur vielen Dank zu sagen. Ja, danke schön für die Zeit.
Genau. Liebe Grüße. Und ja, ich freu mich, dich irgendwann mal zu treffen.
Vielleicht einen Talk von dir zu sehen irgendwo.
Oder wir quatschen uns noch mal hier zusammen.
Ja, super gerne. Vielleicht bei Poly 4 oder so was. Wenn da Bock habt, sag da einfach Bescheid.
Alles klar. Dann mach's gut, ja? Du auch. Bis dann. Tschüss.
Musik.

[1:05:05] Music.