Revision 563: Ein Update zu Projekt Fugu

Transcript

[0:00] Bei den isolated Web Apps geht es darum, dass man auch solche APIs wie Direct Sockets aktiviert.
Das ist ein bisschen wie ein Electron, wo ich einfach die auf dem System vorhandene Browser-Technik gleichsam hijacke, um darin meine Applikation abzufeuern und ich schleppe sie nicht mit mir mit für jede Echse, die ich mir da installiere.
Das sind ja wirklich Unmengen an APIs und so mehr ist ja nicht immer besser.
Je intrinsischer die Motivation ist, umso besser ist natürlich auch das Ganze für ein Projekt wie Fugu.

[0:32] Music.

[0:57] Working Draft Revision 563 Diese Revision von Working Draft wird euch präsentiert von pCloud, der sicheren Cloud-Lösung aus der Schweiz. Der Online-Speicher von pCloud ist etwas Besonderes, denn es gibt ihn nicht nur als monatliches Abo, sondern auch mit lebenslanger Lizenz.
Ihr zahlt nur ein einziges Mal und könnt all eure Dateien, Dokumente und Projekte in, in einer bis zu 10 TB großen Cloud abspeichern.
Durch den Schweizer Standort hält sich pCloud an besonders strenge Datenschutzbestimmungen und ist damit vollständig DSGVO-konform.
PCloud überzeugt zudem mit leistungsstarken Apps für Mobile und Desktopgeräte. Und jetzt der Clou.
Zu Ostern bekommt ihr die Familienlizenz von pCloud 78% günstiger.
Aber schnell sein lohnt sich.
Nach 24 Stunden steigt der Preis Stunde für Stunde wieder an.
Also, sichert euch die 78% Rabatt ab dem 6. April. Den passenden Link zu pCloud findet ihr auf workingcraft.de in den Shownotes.
Wir danken pCloud für die Unterstützung von dieser Revision von WorkingCraft.

Revision 563: Ein Update zu Projekt Fugu

https://workingdraft.de/563/

[2:10] Wir sind heute zu dritt. Da hätten wir aus dem Team den Peter. Moin Moin.
Ich bin der Shep und das bedeutet, wir haben wieder einen Gast und zwar den Tom.
Hallo Tom. Hallo, Moinsen.
Moinsen. Du warst schon mal bei uns. Das ist aber ganz schön lange her, nämlich das jetzt mal im Oktober 2019.
Und viele unserer Hörerinnen und Hörer kennen dich vielleicht gar nicht deswegen, oder kennen dich wahrscheinlich schon, aber vielleicht nicht mehr aus der Folge mit uns.
Deswegen erzähl doch nochmal, wer du bist und was du machst.

[2:44] Ja, sehr gerne. Wow, 2019, hör das? Ja, ja, die Zeit fliegt.
Das kommt einem voll wie vorgestern. Na gut.
Ja, also, ich bin Thomas Steiner, Tomajag auf Twitter, Mastodon und so weiter im Internet GitHub.
Genau, ich bin im Chrome Team, Chrome Developer Relations, und fokussiere mich dort auf das Thema Project Fugu, also sprich, dem Browser neue Fähigkeiten beibringen, sodass ihr, ihr Developer hier draußen, auf der Webplattform alle Applikationswünsche und Ideen umsetzen könnt, für die ihr früher vielleicht eine Windows, Mac, Android, iOS, was auch immer, Applikationen bauen musstet.
Genau, unser Ziel ist, euch das zu ermöglichen, auf der Webplattform zu realisieren.

[3:27] Ja, cool. Tatsächlich warst du auch damals schon zu diesem, ja, zu diesem Themenkomplex, zu diesem Project Fugu, zu Gast.
Das damals, glaube ich, noch relativ neu war, auch nicht immer so ganz neu, aber schon doch relativ neu.
Genau, und seitdem hat sich viel getan.
Tatsächlich ist auch der Ursprung dessen, dass wir drei hier sitzen, war ein, also ich glaube, ein Mastodon-Tut von jemandem, der sich gewünscht hat, dass wir das Project Fugu mal besprechen.
Und daraufhin haben wir halt gesagt, so, ja, das haben wir ja schon mal.
Da hatten wir, Moment, ich such das mal raus.
Ich glaube, da hat sich nicht so viel dran geändert. Dann hast du gesagt, ja, Moment, das ist nicht so ganz korrekt.
Da hat sich schon einiges getan.
Da wollen wir jetzt mal so ein bisschen reinschauen.

[4:23] Aber du hast ja schon gesagt, das Project Fugu hat ja so ein bisschen das Ziel, also das, was man, ich weiß nicht, ob man das noch heutzutage benutzt, aber Cordova oder vielleicht auch Dinge wie Elektron und andere Wrapper-Konstrukte um Browser und Web-Anwendungen herum, die möglicherweise überflüssig zu machen.

[4:46] Ist das so richtig? Ja, genau, also, das geht zumindest in die richtige Richtung.
2019, ja, also da war Project Fugu noch ziemlich frisch.
Damals war eigentlich das Hauptthema das Schließen der sogenannten App-Gap, haben wir das immer genannt, also sprich, die Lücken APIs, die nativ anbietet, also sprich Android, Windows, Mac, was auch immer, die aber auf dem Web noch nicht realisierbar ist.
Also zum Beispiel direkten Zugriff auf das System-Clickboard oder die Fähigkeit, dass man Dateien nicht nur aufmachen kann, im Sinne von File Open, sondern tatsächlich auch öffnen kann, um darauf zu schreiben.
Ganz viele andere Fähigkeiten, direkten Zugriff auf Videocodecs, Audiocodecs und so weiter. Und von 2019 bis, ja, 20...

[5:36] 22 kann man vielleicht sagen, war das Ziel von Project Fugo tatsächlich, das Schließen dieser App-Gap.
Und wir haben ganz, ganz viele APIs implementiert im Browser.
Ja, haben das in Chrome, in Chromium, in vielen Fällen direkt geschippt.
Die ein oder andere API, die wir zwar gedacht hatten, dass man braucht, haben wir am Ende dann festgestellt, die brauchen wir so in dieser Form vielleicht nicht, oder die Grundlagen haben sich geändert, also sprich, vielleicht irgendwas in Android hat sich geändert.
Also, das, was damals ursprünglich realisierbar schien, auf einmal dann in Android sich nicht mehr realisieren hat lassen, aber im großen Ganzen waren wir sehr, sehr erfolgreich, und ich hab das damals nachgezählt, haben 55 APIs und Features released, und ich hab dann so einen Post geschrieben, wo ich die rhetorische Frage gestellt habe, ist Project Fugu dann? Also, sind wir fertig mit Project Fugu?
Haben wir alles implementiert?
Und natürlich, rhetorische Frage, die Antwort war natürlich, nein, wir sind nicht fertig.
Sondern bei ganz vielen APIs haben wir so eine Art MVP-Implementierung realisiert.
Und je mehr Leute das jetzt nutzen, je mehr Leute ihre App-Wünsche auf dem Web realisieren, Stellen wir eben fest, oder stellen Entwickler viel mehr fest.

[6:52] Bestimmte Sachen, ja, da kann man einfach noch das Ganze fine tunen, da kann man das Ganze geschmeidiger machen, sodass es einfach sich besser anfühlt, richtig gleichzieht mit Nativ und nicht nur fast gleichzieht.
Als konkretes Beispiel kann man angeben, zum Beispiel, dass man Dateien jetzt natürlich im Web aufmachen kann und editieren kann.
Das kann man auch mit Verzeichnissen machen, das heißt, ich kann via code.dev, also die Visual Studio Code Implementierungsumgebung kann ich im Web aufmachen und dann meinen Project Folder selektieren.
Wenn ich die Applikation dann aber neu lade, also sprich, beim Browser reload drücke oder einfach dem Browser neu starte, da wird dann zwar der Zugriff nach wie vor auf die Dateien möglich sein, aber eben erst nach einer erneuten Sicherheitsabfrage.
Grund hierfür ist natürlich, dass man einfach sagt, man will sicherstellen, dass der Benutzer ganz bewusst nochmal Zugriff gibt auf das Verzeichnis, dass sie oder er hochgeladen hat, oder was heißt hochgeladen, geöffnet hat, also ich denke immer noch so ein bisschen in den alten Schemen, ja, also Upload, Download, aber ja, letztendlich natürlich haben wir echten lokalen Zugriff hier ermöglicht, also sprich, das Verzeichnis, dass sie oder er aufgemacht hat, dass da eben nach wie vor dann Zugriff besteht.

[8:11] Und man möchte eben sicherstellen, dass das eine Bewusstentscheidung ist.
Und das ist natürlich, wenn man jetzt ein gewiefter Benutzer ist von VS Code und jeden Tag den Browser neu gestartet oder von mir aus jede Woche, was auch immer, ist das immer lästig, wenn man dann jedes Mal nochmal sagen muss, ja, ich möchte tatsächlich nochmal auf C, Programs, bla, was auch immer, Program Files Zugriff gewähren, was auch immer, dann ist das natürlich, ja, so ein Erneuerungs, wenn man sagt, klar, theoretisch ist alles möglich, aber halt in der Praxis ist es noch ein bisschen umständlicher als über nativ, und, ja, da sind wir eben dabei, uns zu überlegen, Wie kann man das so hinbekommen, dass eben Benutzer, die genau das eben wollen?
Diesen Schritt gehen können und sagen können, ich möchte jetzt auf mein Projects-Folder für immer Zugriff gewähren für VS Code.dev oder was auch immer es sein mag, aber halt jemand, der jetzt aus Versehen vielleicht Zugriff gewährt hat für eine Datei, diese Person erwartet vielleicht nicht, dass in der Zukunft jedes Mal, wenn man jetzt die App wieder neu lädt, dass nach wie vor dieser Zugriff besteht. Und ja, da sind wir eben dabei, herauszufinden, wie kann man im konkreten Beispiel Permissions für das File-System, wie sagt man, persistieren, genau, das ist das richtige Wort, persistieren, sodass das in Zukunft eben möglich ist, genau das zu realisieren, was der Benutzer möchte, und was natürlich auch der App-Developer möchte.

[9:36] Ja, ist auf jeden Fall schwierig. Also stelle ich mir auf jeden Fall sehr knifflig vor, da eine gute Heuristik zu finden, so die das ausbalanciert.
Ich glaube, was ihr auch gemacht habt, ist, dass hier mehrere APIs, die im Grunde sich relativ ähnlich sind, dass ihr die noch mal quasi aufgeschnürt habt.
Also mir fällt jetzt zum Beispiel diese Sensors API ein. Ich weiß nicht, ob die so heißt, aber auf jeden Fall, es gibt ja irgendwie Accelerometer und, keine Ahnung, Ambient Sensor und irgendwie noch zig andere.

[10:12] Und die funktionieren im Grunde alle ungefähr ähnlich. Und ich glaube, da gibt's jetzt quasi so eine, übergreifende API, die man eben anzapft, wo die dann alle dranhängen, anstatt irgendwie jede einzeln zu bespielen.

[10:27] Genau, also das ist die Generic Sensor API. Das ist tatsächlich schon eine der älteren APIs.
Da ist die Idee, man hat verschiedene Sensoren im Telefon typischerweise, die zu sogenannten Fusion-Sensoren typischerweise zusammen modelliert werden, sodass man dann so eine Art Orientierungssensor quasi hat, was in dem Sinne gar nicht existiert.
Ein Orientierungssensor ist eine Kombination von Magnet, Gyroskop, wie heißt das auf Deutsch, Gyroskop, keine Ahnung, Beschleunigungssensor, Und, ja, das wird eben über die High-Level-Akis verfügbar gemacht, aber letztendlich ist das, wie gesagt, ein Fusion-Sensor, und, ja, da möchte man eben auch Zugriff gewähren auf die einzelnen Untersensoren, um eben neue Use-Cases zu ermöglichen, die eben nicht quasi die abstrahierte, fusionierte Sensor-View abbilden, sondern eben, ja, eine Art und Weise, wie jetzt eben ein Magnetsensor oder ein Gyroskop oder was auch immer Bewegungen, Magnetfelder, was auch immer registriert.

[11:38] Und man hat dann festgestellt, letztendlich die Art und Weise, wie das funktioniert, ist bei allen gleich, also man hat so eine Art Polling-Intervall, wo man eben Sensorwert ja ausliest.
Und da ist dann die Idee, dass man eben sagt, man abstrahiert das Ganze, man hat diese Generic Sensor API on top, Man kann dann eben über die jeweiligen Unterklassen sozusagen auf den jeweiligen Sensor zugreifen Und eben nach wie vor, auch wenn man das möchte, bestimmte Fusion-Sensoren auch über das gleiche Interface abfragen.

[12:11] Okay, das heißt so die Fusion ist dann hauptsächlich, wenn ich jetzt, ich scroll da gerade so durch die Code-Beispiele in der Spezifikation.
Also der Hauptgegenstand der Fusion ist ja mehr oder minder dann das gemeinsame Permissionsmodell, ne?
Also ich frag ab, gib Sensor und zwar mit diesen und jenen Capabilities und dann kann ich mir darunter selbst konstruieren, wie ich da gleichsam reingreifen möchte, was ich mir da rauspicken will.

[12:34] Genau, also da ist eben wichtig auch zu verstehen, solche Sensoren, solche Sensordaten, die können immer auch, verraten, zum Beispiel, ob jemand sich gerade bewegt, ob jemand läuft, ob jemand joggt, ob jemand hüpft oder was auch immer.
Man kann über diese Sensoren und natürlich dann inzwischen Machine Learning, jada jada, wenn man gewisse Patterns einfach von Sensordaten über Machine Learning annotiert und lernt, so sieht was auch immer Jogging aus, so sieht Laufen aus, so sieht Gehen aus, so sieht Hüpfen aus, kann man eben, wenn man dann ein Sensorsignal abfängt von jemand, das über Machine Learning dann klassifizieren lassen.
Und ja, das ist natürlich nicht zwingend im Sinne des Erfinders, dass diese Daten direkt dann für Fingerprinting und User Tracking verwendet werden.
Das heißt, man möchte natürlich dann schon sicherstellen, dass diese Bewegungsdaten und Sensordaten im Allgemeinen eben nur verwendet werden, wenn den Nutzer dem zustimmt.
Ihr habt auch diese schöne Seite, die heißt, glaube ich, Fugu API Tracker. Aber die war das.

[13:42] Die ist wirklich sehr, sehr lang. Da steht drin, welche APIs sind geschippt, welche sind vielleicht gerade in Beta oder Canary, und welche stecken noch gerade so in den Grundzügen.
Und was ich ganz gut fand, da hatte jemand gesagt, ob man nicht...
Also es gibt ja bestimmte APIs, die so user-activated sind.

[14:11] Also wo man jetzt keine Permission braucht, aber so ein User Activation.
Und das war die Vibration API jetzt zum Beispiel. Und das ist mir aufgefallen, weil ich selber diesen Wunsch irgendwann mal hatte, dass die einfach nicht jedes Mal erst User Activated werden muss.
Also was bei einer SPA vielleicht noch so gerade so okay ist, aber bei einer MPA dann doof.
Genau, und was ich ganz charmant fand, Das war eben da auch den Vorschlag, hey, wenn man eine PWA, also eine Progressive Web App, einmal installiert hat auf seinem System, könnte man da dann nicht eben anderes Verfahren mitrechten.
Und ich finde das eigentlich ganz gut. Also der Safari, der hat jetzt ja auch die Push Notifications, und die haben auch so einen Ansatz.
Also ich glaube, die erlauben ja gar nicht erst diese Push-Requests in der nicht installierten Version, so wie das an anderen Browser erlauben, sondern man muss eben sozusagen sich auf eine Anwendung erstmal committen, Interesse zeigen, die installieren als Progressive Web App und dann kommt so was.
Aber ich finde also dieses, dass man das unterschiedlich betrachtet, wenn es gerade so quasi aus dem Web geladen wird oder ob man sich das richtig installiert hat, So da Unterschiede zu machen, finde ich total gut.

[15:40] Ja, also das wäre auch mein Lied jetzt gewesen, um die Frage zu beantworten.
Ja, also es gibt quasi zwei Schulen, auch innerhalb von Chrome, die sagen...

[15:51] Installieren einer Applikation ist ein ganz klares Signal. Wir wollen da dann mehr Use Cases, vielleicht auch mit leichteren Permissions, also sprich, die dann weniger scary sind, oder weniger häufig auftreten, arbeiten, oder dass man sagt, manche APIs sind vielleicht sogar ohne explizite Permission dann nutzbar, und es gibt die andere Schule, die sagt, nee, also die zwei Welten sollten genau gleich sein, installiert und nicht installiert.
De facto ist es, glaube ich, einfach so, die Differenzierung existiert.
Also, es gibt bestimmte APIs, die ergeben nur Sinn für installierte Applikationen.
Also, konkretes Beispiel, die Badging API, die einem erlaubt, so ein kleines App-Pad, also, sprich so, was man so kennt von Gmail zum Beispiel, dass man sagt, fünf ungelesene E-Mails, also meistens sind es eher 5.000 als 5, dass man dann eben so eine kleine 5 oder eine 5.000 auf das App-Icon setzt und der Benutzer dann weiß, das ist, ja, was ich zu tun habe, gibt's natürlich in den Fav-Icons, quasi per Software umgesetzt, also dass man irgendwie in SVG-Fav-Icons setzt.

[16:56] Und dann per SVG die Zahl im Fav-Icon modifiziert.
Das ist das, was im Browser läuft.
Es gibt aber auch quasi direkt auf dem installierten App-Icon die Möglichkeit, so ein Badge zu setzen, und das sind klassischerweise eben keine SVGs, die man einfach mal so modifizieren kann, sondern das sind PNGs, typischerweise, was da Android, MacOS und so weiter voraussetzen, und dafür gibt's die Badging-API, und ja, die ergibt natürlich nur Sinn für installierte PWAs.

[17:29] Und es ist ziemlich interessant eigentlich, dass Apple dieses Modell aufgenommen hat, weil Apple hatte so eine interessante Beziehung zum Thema PWAs, also sie nennen das ja gar nicht PWA, sondern sie nennen das App Added to the Home Screen, Ja, die sagen ja, die erkennen das ja nicht an als offiziell, also oder als, weiß ich nicht, Web-Anwendungsgattung.

[17:52] Der WebKit Lead, hat das vor kurzem klargestellt, Mathieu, der meinte, sie haben nichts gegen den Begriff PWA, aber was sie eben verstört, ist so ein bisschen diese Unterscheidung zwischen ist PWA jetzt installiert, oder ist PWA nicht installiert, oder ist das installierbar, oder was bedeutet das denn jetzt?
Und letztendlich, ja, wie im Prompting, wir sagen PWA und installierte PWA, wenn man so unsere Artikel liest, um einfach diesen Unterschied klar zu machen, Und das ist aus, ja, Gründen, die Matthe aufgeführt hat, eben nicht Apple-konform, das heißt, die sagen jetzt einfach App added to the home screen, um ganz eindeutig zu sagen, das ist eine installierte PWA, was auch immer, auf iOS.

[18:36] Also, lange Rede, kurzer Sinn, ich finde es sehr interessant, dass Apple dieses Modell gewählt hat, um eben nur installierten PWAs den Zugriff auf Push zu gewähren.
Ja, letztendlich ist es natürlich wahrscheinlich auch so ein bisschen Sicherheitsdenken. Ihnen war es ja ganz arg, das Thema Notification Spam, also kennen wir alle, wenn man so ein fremdes Android-Gerät von jemand an die Hand bekommt, die oder der jetzt nicht zwingend super webaffin ist und man dann sieht eine Milliarde Notifications von irgendwelchen sketchy Sites, ja, und das wollten sie auf jeden Fall verhindern und ich vermute mal, Das war jetzt auch einer der Gründe, warum sie gesagt haben, wir machen das jetzt vielleicht zumindest erstmal hinter Installation.
Vielleicht wird ja irgendwann das aufgemacht, wenn man merkt, es ist jetzt vielleicht nicht so spammy, oder Benutzer haben gelernt, damit umzugehen, oder vielleicht auch die Prompts werden in einer anderen Art und Weise gezeigt, also was wir ja in dem Chrome-Desktop machen.
Wenn wir merken, die Seite ist ein bisschen spammy, was jetzt Permissions angeht, dann zeigen wir nicht diesen blockierenden Prompt, sondern wir zeigen so einen, ja, in der URL-Bar versteckten ein bisschen Bubble Prompt.
Kann man auch im Artikel darüber lesen, wo ich erzähle, wie das Permissions-Team das gemacht hat.

[19:57] Ja, letztendlich, ja, sehr interessantes Modell, wie gesagt, das Apple da gewählt hat, aber ja, so ist es und ich glaube, persönlich, man sollte schon so ein bisschen unterscheiden zwischen, jemand hat die App installiert, das heißt, man kann dann etwas Laxa sein, was Permissions angeht, und ich denke, längerfristig ist das auch das, was die Mehrheit des Chrome-Teams möchte, aber ja, nach wie vor, es gibt beide Schulen innerhalb des Chrome-Teams.

[20:25] Ja, also ich finde das auf jeden Fall auch eigentlich einen guten Ansatz, also deswegen, da wäre ich dann auch bei euch, mit in eurem Team.
Genau, und ich hab auch gesehen, als ich diese Liste durchging, dass es nicht nur PWAs gibt mittlerweile, sondern etwas, das sich IWA nennt.
Das habe ich jetzt zum ersten Mal gesehen. Und habe dann geguckt, was das denn wohl sein könnte.
Und das sind isolated Web Apps.
Was hat es denn damit auf sich?
Genau. Isolated Web Apps sind quasi, wenn man so die Bandbreite an gefährlich und nicht gefährlich anschaut, dann ist quasi im Browser-Tab laufend, das ist komplett ungefährlich.

[21:20] Installierte PWA ist potenziell ein kleines bisschen gefährlich und dann hat man so am anderen Ende des Spektrums die sogenannten IWAs und gefährlich meine ich im Sinne von, welche APIs sind denn für diese Applikationen verfügbar und bei den isolated Web Apps, da geht's eben darum, dass man auch solche APIs wie jetzt Direct Sockets aktiviert.
Viele wundern sich, ja, Web Sockets ist ja eine API, die existiert.
Websockets ist halt limitiert, was man darüber schicken kann.
Und Direct Sockets erlaubt einem eben, dass man jedes Protokoll quasi abbilden kann über, ja, native Sockets.
Und das große Problem dabei ist, das erlaubt einem, wenn man geschickt ist und weiß, wie es geht, dass man da eben zum Beispiel Enterprise Firewalls umgehen könnte.
Und das ist eben natürlich das, was viele Leute nicht wollen und natürlich auch die meisten Leute nicht von einer Webapplikation erwarten, dass die jetzt sich irgendwie über die Windows-Firewall oder was auch immer, die vom Arbeitgeber vorgegebenen Firewall hinweg setzt.
Letztendlich gibt's aber viele Use Cases, die das doch durchaus erfordern, also sprich native Sockets, und im konkreten Fall sind das Anbieter, die aktiv sind im Bereich VDI, also Virtual Desktop.

[22:41] Das I steht für Integration, glaube ich, Also sprich, das Streamen von einem Betriebssystem auf ein anderes.
Und da gibt's verschiedene Anbieter, ich kann jetzt natürlich keine Namen nennen, aber parallel auf Englisch übersetzt ist zum Beispiel einer davon, oder was so ähnlich klingt wie Zitrone, ist ein anderer, und ja, die haben eben klassischerweise native Applikationen für Windows, für Mac, die eben genau das umsetzen.
Für die ist eben der Bereich Chromebooks auch ein sehr interessanter Bereich, eben weil Chromebooks relativ günstig zu haben sind und Chromebooks eingesetzt werden gerne auch im Enterprise-Bereich natürlich.

[23:25] In Callsend dann beispielsweise, wo man eben eine riesige Flotte an Chromebooks hat, und die ganzen Applikationen aber letztendlich alle auf Windows-Ebene laufen und was diese Anbieter dann machen, ist, sie streamen die Windows-Umgebung auf das lokale Chromebook gerne eben so, dass sich das überhaupt nicht mehr nach einem Chromebook anfühlt, sondern dass eben alles aus einem Guss sich anfühlt.
Das haben sie bisher gemacht über sogenannte Chrome Apps. Die Chrome Apps Plattform wird allerdings deprecated.
Und isolated Web Apps ist jetzt ein erster Schritt, um dann eben die Use Cases, die diese Anbieter haben, doch nochmal umzusetzen auf, ja, Web Plattform ist ein bisschen relativ, weil, ja, es gibt bestimmte Einschränkungen, was jetzt eine IWA kann, zum Beispiel kann man sie nicht einfach so direkt im Browser aufrufen, sondern muss diese Applikation über irgendeine Form von Store beziehen, oder man muss über den Enterprise Admin die Applikation installiert bekommen, aus seinem gemanagten Chromebook.
Und ja, da kann man dann auf diese Art und Weise dann eben quasi mit Web-Technologien, also nicht Web, aber Web-Technologien, Applikationen bauen, die dann mit zum Beispiel dem nativen Socket Server von einem Streaming-Anbieter sprechen.

[24:47] Und dann eben da diese Windows, was auch immer, Umgebung gestreamt darstellen auf dem lokalen Chromebook.
Und da kommt man dann natürlich auch gleich sehr schnell vom 100. ins 1000.
Wenn ich ein Browser-Fenster hab und im Browser-Fenster ein anderes Fenster darstelle, also sprich im, sagen wir, Chromebook-Fenster ein Windows-Fenster darstelle, was passiert denn, wenn ich das Windows-Fenster schließe, soll dann auch das Chromebook-Fenster sich schließen, oder was passiert, wenn ich das Windows-Fenster minimiere oder maximiere, erzähle ich jetzt dann immer sehr schnell der Wunsch da, Fenster im Fenster quasi gar nicht erst anzuzeigen, sondern das gestreamte Fenster zum eigentlichen Fenster quasi abzugraden, also sprich das Chrome-Fenster, Chromebook-Fenster, dann seamless zu machen, also borderless, seamless, keine Controls mehr anzuzeigen, keine Chromebook-eigenen Close-Buttons, Minimize-Buttons und so weiter, sondern das alles dann quasi, ja, über die gestreamte Plattform zu emulieren, dass man eben sagt, wenn ich jetzt in Windows Minimize drücke, dann soll das übersetzt werden in ein Chromebook-Window, Minimize-Event und so weiter, sodass sich das Ganze sehr natürlich und nativ anfühlt.
Und ja, da ist man eben sehr schnell bei APIs, die ziemlich, in Anführungszeichen, gefährlich sind, und deshalb eben dieses neue Arbeitsfeld isolatet überwärmt.

[26:07] Dass dann, wenn ich es richtig verstehe, ein verschobenes Feature-Set ist, also privilegiert in so mancherlei Hinsicht, weil ich direkt Zocken spucken kann und ähnliches, aber halt limitiert in anderer Hinsicht, Ich schaff das nicht eben an und dann ist das da.

[26:22] Genau, also das ist einfach ein anderes Sicherheitsmodell da.
Die Installation ist tatsächlich eine Installation im klassischen Sinne, also sprich, es ist noch nicht genau, ja, realisiert, aber die Idee ist, dass man auf irgendwie so eine Art Play Store, Chrome Web Store, was auch immer gehen muss, und dann auch so eine komplette Zeremonie in puncto möchtest du das jetzt wirklich installieren, das und das sind die Permissions, bla bla, du downloadest das in Anführungszeichen, Das läuft dann auch nicht in einem Origin wie example.com oder HTTPS, example.com vielmehr, sondern das läuft dann auch so einem Gewalt Chrome Extension sozusagen, die ja auch so ein eigenes Scheme haben, also Chrome Extension slash Scrolling blablabla und das ist dann eben auch so eine quasi opake Origin-artige Umgebung, die eben auch komplett von der Webumgebung gesendboxt ist und ja, auf die Art und Weise wird eben sichergestellt, dass jetzt auch zum Beispiel so eine IWA sich nicht sandboxen lässt oder iframen lässt oder was auch immer, sondern dass das komplett eine eigene Umgebung ist.
Ist ein bisschen wie ein Electron, wo ich einfach die auf dem System vorhandene Browser-Technik gleichsam hijacke, um da drin meine Applikation abzufeuern und ich schleppe sie nicht mit mir mit für jede Echse, die ich mir da installiere, ne?

[27:43] Das geht in die Richtung, genau, Elektron schickt ja jedes Mal ein eigenes Chromium mit, das heißt, wenn ich mir jetzt zwei Elektron-Apps installiere, dann habe ich zweimal Chromium intern, installiert, sozusagen, gerne auch mal outdated, wenn jetzt Elektron nicht so häufig aktualisiert wird, was das Paket, das drunter liegt, angeht. Es gibt dann andere von, andere Wrapper-Technologien, die dann eben versuchen, System WebView oder die System Chrome oder Default Browser Umgebung zu nutzen.
Das Problem dabei ist, ich hab mir das vor kurzem mal angeschaut, das funktioniert prinzipiell, aber sobald man interessante Sachen machen möchte, also sprich irgendwelche Advanced Web APIs nutzen, dann ist es eben blöd, wenn man sich darauf verlässt, dass jetzt bestimmte Chrome-APIs da sind, aber der Benutzer Safari installiert hat beispielsweise und dann eben die Applikation sagt, okay, ich bin jetzt der Wrapper. Ich schaue, was gibt es für Browser auf dem System.
Okay, es ist Safari da. Ich implementiere intern meine gewappten Calls.
Über Safari APIs und wenn die eben nicht da sind, dann ist es halt blöd und dann ist man wieder bei diesem Thema, ja, ich will halt irgendwie doch sicherstellen, dass meine Runtime vorhersehbar ist.

[28:59] Und dann ist man doch wieder zurück beim Modell Elektron oder, ja, es gibt verschiedene andere Tricks, die dann zumindest sagen, wir verwenden das installierte Chromium oder Chrome oder was auch immer und man kann dann quasi den Browser festzuhren, aber auch das, habe ich festgestellt, ist nicht zwingend vorhersehbar, also man kommt da in sehr, sehr komische Bugs und ja, wir hatten vorher das Thema Masteron, es gibt einen interessanten Client, der heißt Elk, da gibt es auch eine native Applikation, die über ein Framework namens Tauri implementiert wird, und da bin ich gerade mit ein paar anderen Leuten auf dem Issue, ich weiß jetzt die Nummer nicht, aber können mir bestimmt im Nachhinein nachreichen, wo dann eben drin steht, ja, man startet die Applikation, man lockt sich ein und dann hat man einen schwarzen Bildschirm.
Und das ist letztendlich genau der gleiche Code, der auch im Browser läuft, ohne jedes Problem, aber halt aus irgendwelchen Gründen kommt dieser super spezielle Bug dann zum Vorschein.
Und ja, also, das müsste man eben über IWIS quasi dem Benutzer ersparen, dass man sagt, die Umgebung ist vorhersehbar, das ist eben das Chrome, das der Benutzer installiert hat, oder das Chrome, das jetzt auf dem Chromebook läuft, Und ja, dadurch ist die Umgebung verhälssicher, aber halt am Ende auch der Vorteil, dass man nicht für jede Applikation ein eigenes Chromium mitschippen muss, ist dann auch gegeben.

[30:26] Ich hab gerade nachgedacht, weil ich irgendwie musste ich an die Apple Store-Regel denken, dass man ja eben keinen anderen Browser installieren darf, keine andere Engine benutzen darf, als die Safari-Engine und da kam ich gerade erst auf den Gedanken, dass das ja anscheinend bei Elektron eben nicht der Fall ist.
Wobei, nee, stopp, das ist ja eh Desktop, genau, deswegen ist das wurscht, da geht das ja.
Okay, nee, Kommando zurück, ich hatte nur überlegt, also wie sieht's denn da eigentlich aus?
Okay, ja, das ist ja auch ein Problem, das man dann nochmal separat lösen muss.
Ich weiß ehrlich gesagt nicht, wie es auf dem MacOS App Store ist, dass man da Elektronenapplikationen liefern darf, aber auf iOS, iPadOS da auf jeden Fall nicht.

[31:14] Genau, weil Slack gibt's ja auch für MacOS, aber da ich selber Windows hab, weiß ich jetzt nicht, ob man das auch über den Apple Store beziehen kann.
Aber das werden uns unsere Hörerinnen und Hörer vielleicht noch erzählen.
Wie seid ihr denn, ähm, also wie geht ihr denn vor? Also ist es so, dass ihr ...
Oder ich könnte mir vorstellen, dass ihr euch vielleicht so ein paar für Fugu jetzt, sozusagen, dass ihr irgendwie auslotet, was brauchen die Leute, dass ihr so ein paar Flagship, vielleicht, sagen wir mal, Elektronenanwendungen oder ehemals Cordova-Anwendungen euch irgendwie geschnappt habt, und dann mit den Entwicklern gesprochen habt und gesagt habt, das sind jetzt erst mal so unsere Flagsschiffe, die werden wahrscheinlich relativ viele API-Wünsche mitbringen und damit decken wir dann relativ viel ab.
Oder ist es eher so, dass ihr quasi wartet, was so eintrudelt, und ihr dann sozusagen aussiebt so ein bisschen, wo die meisten Leute nachrufen.

[32:17] Wie macht ihr das? Also eine Mischung aus beiden, plus eine dritte Komponente.
Die dritte Komponente erwähne ich ganz am Anfang.
Das hat eben quasi ursprünglich mit dem Vorgänger von Project Fugu angefangen.
Das Projekt hieß Intern FIS. Und die Idee war Chrome Apps.
Hatte ich ja vorher schon erwähnt, eine Plattform, die inzwischen deprecated ist, und ein erster Schritt war quasi, man schaut sich alle Chrome Apps, APIs an, und versucht die dann zu übersetzen in Open Web APIs, also sprich, keine Chrome APIs mehr, sondern, ja, man versucht sie eben zu generalisieren.
Das war der dritte Inputfaktor sozusagen, ohne dass ich die jetzt irgendwie ranken möchte. Der zweite ist letztendlich Partner Requests.

[33:08] Konkrete, große Leuchtturmprojekte, natürlich jetzt Adobe, Photoshop, haben wir bei Google I.O. gehört, ohne Ende, und ja, ist auch nach wie vor, würde ich sagen, einer der faszinierendsten Fälle, und dann natürlich auch einfach in die Breite, also Entwicklerbedarf, jeder kann einen neuen Fugu-Bug requesten, also das ist bit.ly slash new dash Fugu dash request, und da kommt man auf so ein Bug Template sozusagen und beschreibt dann seinen Use Case und das landet dann in der Queue und ja, interessierte Entwickler, Entwicklerinnen können sich dann auf diesen Bug quasi starren, also sprich den Bug.

[33:51] Abonnieren sozusagen, natürlich auch kommentieren und die eigenen Use Cases, ja, klar machen, warum braucht man jetzt die API und was auch immer. Und ja, also die Kombination aus diesen drei Faktoren Chrome APIs, also Chrome Apps APIs, große Partner und letztendlich allgemeine Entwickler-Requests.
Das ist das, was uns quasi motiviert hat und auch priorisiert hat, jetzt die ganzen APIs zu entwickeln.
Und ja, inzwischen ist eben diese Phase, wo man jetzt die Haupt-App-Gap abgedeckt hat, also weitmachen, es gibt natürlich noch eine lange, lange Liste, du hast ja vorher erwähnt, den Fugue API Tracker. Da gibt's auch ganz, ganz viele APIs, die sind under consideration, also sprich, man schaut sich das mal an, aber wir haben einfach noch keine konkrete Entscheidung getroffen.
Und ja, da schauen wir dann eben, was machen wir in Zukunft, und welche von den existierenden APIs haben denn vielleicht irgendwelche Feinheiten, die man noch korrigieren kann.
Ich hatte ja anfangs erwähnt, das mit dem Thema Permissions, und, ja, die eben persistiert werden, so dass das eben doch irgendwie sicher ist, aber halt auch Use Cases unlocked, die vorher nicht möglich war.

[35:10] Ja, man muss ja auch dazu sagen, also es sind ja wirklich Unmengen an APIs.
Mehr ist ja nicht immer per se besser.
Ist ja auch einfach Arbeit für euch. Also Engineering-Arbeit wird da gebunden, das zu implementieren.
Ihr müsst quasi Tests schreiben. Und alles wird ja dann letztlich, also je mehr APIs man später dann durch Codeänderungen nicht kaputt machen darf, desto schwieriger wird es natürlich auch.
Das ist ja sowieso, also bei Browsern, das ist ja der helle Wahnsinn, was das für Monstermaschinen sind mittlerweile.
Und ein Wunder, dass die nicht einfach kaputtgehen.
Also, dass Releases überhaupt geschippt werden können, ohne dass irgendwie links und rechts irgendwelche APIs wieder kaputtgegangen sind.
Einfach weil's so viele sind und weil das so ein komplexes Thema ist.
Genau, also da bin ich immer wieder höchst beeindruckt.

[36:09] Also, es kommt vor, dass was kaputt geht. Teil unseres Prozesses sind natürlich auch, dass man genügend Webpagetests schreibt, dass man genügend Webpagetests schreibt, die eben versuchen, alle möglichen Fallstricke, die eine API hat, abzutesten.
Vor kurzem ging kaputt die Shape Detection API, die eben intern in das Framework des Betriebssystems sich einhakt, um dann eben QR-Codes aus Bildern oder aus Bildestreams, also von der Kamera zum Beispiel, zu lesen.
Da hat mit macOS Venture sich irgendwas intern geändert und das hat bisher kein Test abgefangen.
Ready von unserem Team hat dann durch großes Hin- und Her-Engineering herausgefunden, wo das Problem war.
Und dann natürlich den Test geschrieben, dass das in Zukunft nicht mehr passiert, aber ja, also du hast schon Recht, das ist schon alles mit Arbeit verbunden, man möchte natürlich auch, dass die APIs genutzt werden, dass man sich auf das fokussiert, was den größten Impact hat, also sprich, was die meisten Leute verwenden werden, oder was vielleicht die größten Partner von einem wünschen, dass man implementiert, letztendlich ist natürlich auch immer wichtig.

[37:22] Idealerweise soll das alles natürlich auch sich in Web APIs übersetzen lassen und nicht nur Chrome APIs bleiben.
Viele APIs, ja, die werden von anderen Browsern auch unterstützt, also zum Beispiel WebShare oder WebTransport, WebCodex zum Beispiel, wo die anderen Browser-Mentoren sagen, tolle Idee, wollen wir auch haben.
Da startet das dann vielleicht zuerst auf Chrome und wird dann später umgesetzt, auf anderen Browsern.

[37:51] Es gibt aber auch APIs, würd's zum Beispiel Apple oder Firefox ganz klar sagen, wir wollen im konkreten Fall zum Beispiel sowas wie WebUSB nicht haben, nicht mit dem existierenden Modell, weil grundlegende...

[38:05] Ja, Annahmen, die jetzt Chrome sagt, sind sicher. Die sagen, sind nicht sicher.
Also, zum Beispiel, wenn man jetzt ein Gerät auswählt, in einem Hardware-Picker, dann sagen wir, der Benutzer hat jetzt ausgewählt, seine, was auch immer, Nintendo Joy-Cons, um damit über die Web-Hit-API zu sprechen, und Apple und dann Mozilla sagen dann, ja, das hat vielleicht der Benutzer gemacht, aber es war jetzt keine bewusste Entscheidung, weil die meisten verstehen nicht, was da passiert.
Und das sind eben einfach grundlegend andere Auffassungen, was das Thema Educated Consent sozusagen angeht.
Ich würde sagen, das ist letztendlich auch okay. Jeder Vendor darf natürlich machen, was er möchte.
Wir versuchen einfach zu zeigen, die Use Cases sind da. Wir sind der Ansicht, wenn die Use Cases da sind, dann wird das eben umgesetzt über eine native Applikation, die im schlimmsten Fall eben deutlich mehr kann, hat jetzt eine Web-Applikation jemals können wird.
Und ja, deshalb sind wir der Meinung, wenn jetzt der Use-Case da ist und gerechtfertigt ist.

[39:10] Dann sollte man das vielleicht in der sicheren Web-Sandbox realisieren und ja, dadurch eben dann sicherstellen, dass die Leute, dann wenn sie ein Gerät aus dem Hardware-Picker auswählen, dass sie eben wissen, um was es geht.
Und ich bin immer wieder fasziniert, wenn ich dann auf diesen Bugs subscribed bin und dann mitbekommen wir unser interne Security-Team und UI-Team.
Ihr werdet zum Beispiel den Text von einer Vermischung.

[39:36] Kilometerweise E-Mail-Threads führen, um eben sich hinzustellen, das Chrome-Team sagt, wir wollen A, einfach nur API macht das, das Security-Team sagt, ja, API macht das, und möglicherweise kann das und das und das und das dann passieren, und dann sagt das UI-Team, nee, nee, du kannst jetzt nicht eine hellenlange Liste an das und das und das kann passieren, Dingen in diesem Permission-Text aufführen, wir brauchen eben den sinnvollen, ja, Middle Ground sozusagen, Und ja, da geht's eben dann teilweise wirklich kilometerweise E-Mails hin und her, was jetzt der richtige Text ist, und da geht dann sehr, sehr viel Arbeit rein, das so darzustellen, dass die meisten benutzer dann eben verstehen, was sie sagen, was sie abnicken oder was sie eben vielleicht auch blockieren.

[40:22] Das ist auch eine Kunst für sich, irgendwie so Dinge treffend und verständlich und so zu formulieren, genau, nicht ohne Grund gibt's da wirklich Experten dafür.
Wie ist es denn, wenn andere Vendoren sagen so, hey, wir haben da irgendwie so ein anderes zugrunde liegende oder eine andere zugrunde liegende Philosophie, was die Kommunikation an den User angeht.
Die wollen vielleicht irgendwie, weiß ich nicht, vielleicht wollen die sich da irgendwie an Betriebssystemen Dingen bedienen, die da den Weg ebnen wollen.
Ist es denn so, dass die dann sagen, wir finden das nicht so cool, wie jetzt gerade der Serviervorschlag ist, aber wir hängen uns jetzt auch dahinter und wir arbeiten das weiter aus, sodass es dann am Ende so ist, wie wir möchten?
Oder ist es eher so, dass sie das nur doof finden und tendenziell nichts machen?
Oder ist das so ein Mix? Wie würdest du das, also wie ziehen die da mit bei der ganzen Geschichte?

[41:27] Also Hintergrund der Frage ist natürlich, das ist total cool, dass Chrome das alles kann, aber natürlich ist es ja immer schöner, wenn man so eine Perspektive darauf hat, dass alle Engines irgendwann dahin kommen.
Vielleicht, also es muss ja jetzt ja nicht alles sein, aber eben so eine gewisse diese Mindestzahlen-APIs dann eben auch implementieren.
Wollte es genau auch gerade fragen, weil es gibt ja auch diese schöne Webseite hier aus den Shownotes hier, howfuguismybrowser.dev, wo ich gerade mal spaßeshalber mit meinem Chrome drauf gegangen bin und da fehlt am Ende irgendwie noch so 5% und da bin ich mit meinem Firefox drauf gegangen und dann ist der optische Eindruck von dieser Progressbar mehr so, dass die 5% sich da halt eben an dem, was unterstützt, daran orientiert.
Und das ist ja, also, ne, klar, das sind Web APIs im Sinne von, die sind im Browser und die haben irgendwie eine Spezifikation und Zeug, aber ich meine de facto ist es ja schon alles ein bisschen chromig im moment noch.

[42:26] Genau. Ich möchte zwei Geschichten dazu erzählen. Die erste Geschichte ist Figma.
Figma ist natürlich eine sehr populäre Applikation. Gibt es online, aber man wird sehr schnell feststellen, man muss da eine Chromium-Applikation runterladen, Quatsch, eine Elektronen-Applikation runterladen, also sprich, eine Chromium-Runtime, in der das Ganze läuft, dann funktioniert das alles wunderbar.

[42:51] Wenn man die Web-Applikation verwendet, muss man eine zusätzliche Browser-Extension installieren und diese Extension macht letztendlich möglich, dass man Zugriff hat auf die lokalen Schriftarten.
Für Designers ist natürlich immer wichtig, Zugriff auf alle Schriftarten zu haben, die jetzt auch vielleicht nicht zwingend als Web-Fonts verfügbar sind.
Also, das erste, was die meisten sagen, ist, ja, lokale Fonts ist doch Blödsinn, gibt doch Web-Fonts, ja, gibt es natürlich, aber ganz viele Schriften, gerade im Corporate-Umfeld, sind eben so lizenziert, dass die nicht als Webfonds ausgeliefert werden dürfen und nur quasi als physische Dateien auf den genau 27 Geräten, die die Firma jetzt bei was auch immer, Linotype oder wem auch immer, angemeldet hat und da ist eben genau das Ding, dass diese Schriftarten dann doch lokal ausgeliefert werden müssen und ja, also, was ist der Umweg?
Entweder man lädt sich die Elektron App runter, die eben Chromium implementiert und dann Zugriff liefert auf die lokalen Schriftarten über irgendwelche Node APIs oder über diesen Umweg, dass man dann im Browser zwar arbeiten kann, aber trotzdem eine Browser-Extension braucht.

[44:01] Und, ja, was ist der Use Case?
Ja, der Use Case ist natürlich, lokale Schriftarten zu bekommen.
Es gibt die Local Fonts Access API, die eben genau das ermöglicht.

[44:13] Da sagt bisher zumindest Apple, das ist ein großer Tracking-Vektor und da haben sie absolut recht.
Also die Schriftarten, die man installiert hat, die sind sehr, sehr, sehr identifizierend.
Konkretes Beispiel, ich bin bei Google angestellt, das heißt, auf meinem Laptop findet sich eine Schriftart, die heißt Google Suns, die sieht quasi genau gleich aus wie Helvetica, für den Nicht-Typografen ist aber nicht Helvetica, was letztendlich Google ermöglicht, dafür keine Lizenzgebühren zu bezahlen.

[44:43] Und, ja, so ist das bei ganz vielen Firmen, und wenn man eben weiß, dieser Tracking-Vektor existiert, dann könnte ich über die Schriftarten, die ich installiert habe, rausfinden, ist diese Person bei Google beschäftigt, ja oder nein. Das ist, was die meisten Leute eben gar nicht so richtig klar haben, und, ja, was wir eben wollen, ist trotzdem diesen Use-Case zu ermöglichen, was eben, trotz der Tatsache, dass dieser Tracking-Vektor existiert, einfach, weil wir sagen, Firmen wie Figma, die müssen einfach diesen Use Case abdecken und sie finden einen Weg und dieser Weg ist typischerweise eben ein schlechterer, als im Browser direkt die API anzubieten und wir geben natürlich auch die Schriftart nicht einfach nur so raus, sondern da kommt ein Prompt und in diesem Prompt steht dann irgendwie drin, möchtest du Zugriff auf die lokalen Schriftarten gewähren, bla bla bla, und dieses bla bla bla ist wie gesagt sehr sehr sorgfältig gewählt, ich weiß nicht genau den Satz, der da drin steht, aber das steht schon in Richtung, ja, das kann möglicherweise identifizierend sein, steht irgendwas dazu.
Und die andere Geschichte, die ich erzählen möchte, ist die von Adobe.
Adobe hat Photoshop, das natürlich eine native Applikation ist und war, also gibt es natürlich auch nach wie vor als native Applikation, und das haben sie übersetzt mit M-Scripten auf Web, und die haben gesagt, wir brauchen Zugriff auf Dateien, und zwar so, dass das schnell ist.

[46:07] Jeder, der sich ein bisschen auskennt, weiß natürlich, man kann über Dateien, über File Open und so weiter arbeiten, also, dieser klassische hat mir vorher schon File Upload Case oder man kann auch auf den Client dann zugreifen, aber letztendlich das Problem bei sowas ist immer, man kann nicht zurückschreiben.
Das Problem der Dateien aus dem Internet ist natürlich auch immer, da kann ein Virus drauf gespeichert sein, es kann sein, diese Datei wird dann oder das Wortzeichnis, das man jetzt freigibt, wird verschlüsselt, und dann verlangt jemand eine Milliarde Bitcoins, um das Verzeichnis wieder zu entschlüsseln, und was auch immer, also solche Ransomware-Attacks, und da haben einfach Apple und Mozilla gesagt, wir wollen keinen Zugriff derzeit auf Dateien geben für native Applikationen, andererseits sehen wir aber ein, diese Use-Case von Adobe Photoshop, dass die eben Zugriff brauchen auf native Dateien in einer performanten Art und Weise, ohne dass jetzt Safe Browsing oder der Virenscanner drauf rumpusht.

[47:12] Und dadurch dann quasi die Performance wieder kaputt macht.
Warum braucht Adobe das? Weil sie ein Format verwenden, das nennt sich Midmaps. Die Idee ist, zoomen auf dem Web ist ja sehr, oder allgemein, in den Grafikseditoren, ist ja eine sehr teure Operation, vor allem, wenn man sehr, sehr große Dateien hat, Der Trick, wie man das schneller macht, ist, man speichert quasi permanent für verschiedene Auflösungen das vorgerechnet quasi schon mal in der Mid-Map, also sprich 100 Pixel auf 100 Pixel, 200 Pixel auf 200 Pixel und so weiter, und wenn der Benutzer dann zoomt, kann man immer nur auf der nächsten näheren Schrittweite quasi die Skalierung berechnen, was sehr viel billiger ist, als jetzt immer von, was auch immer, den 5000 auf x 1000 komplett hoch und runter skalieren, und ja, diese Maps, die müssen natürlich bei jedem Schritt, den man editiert, aktualisiert werden, ja, das heißt, man braucht eben permanent, wenn ich jetzt einen Pixel auf den Bild dazu füge, muss sich das natürlich auch auf alle Zoom-Stufen sofort auswirken, und ja, da ist man eben sehr schnell an den Grenzen, was mit herkömmlichen Storage-Mechanismen zu machen war, also IndexDB oder was auch immer.

[48:26] Da haben wir die Leute, Filesystems quasi on top implementiert, aber das war einfach nicht performant genug.
Lange Rede, kurzer Sinn, Adobe hat diesen Use Case und Adobe ist natürlich Adobe, Adobe ist nicht irgendwer, das heißt, Adobe sagt dann zu Apple, hört her, wir können folgendes machen, wenn wir Photoshop Adobe.com aufrufen, sagen wir, liebe Benutzer, bitte installiere Chrome, oder ihr Apple Safari, was auch immer, Mozilla's implementiert bitte das Origin Private File System und letztendlich hat das eben funktioniert, dass der große Partner dann gesagt hat, hey, wir brauchen diese API, wir haben das sehr wohl motiviert, warum wir das brauchen, und am anderen Ende des Spektrums wurde dann eben trotzdem.

[49:10] Im Sinne von, ja, die Benutzer können eben keine gelegigen Dateien öffnen und der Browser kann nicht auf gelegige Dateien zurückschreiben, die im User Visible File System sind, wurde eben auch dieser Sicherheitsaspekt, den jetzt Apple und Mozilla sehen, beachtet und letztendlich, ja, die Picker-Methoden, die das File System Access API anbietet, die implementieren Apple und Firefox im gegentfall jetzt noch nicht. Chrome tut das aber und die Speck, die dahinter steht, die File System Access API Speck, die wurde dann eben auch gesplittet in eine OPFS-Spec sozusagen, die dann eben die rudimentären Dinge, wie Dateien, Zugriff auf Dateien, Lesen, Schreiben und so weiter spezifiziert.
Und die File System Access API-Spec, die beinhaltet dann eben jetzt nur noch die Picker-Methoden, die eben auch Zugriff geben auf das User Visible File System.

[50:08] Ja, wahrscheinlich, weil bei dem OPFS dann einfach der Browser selber entscheidet immer noch, wo findet diese Schreiboperation statt. Und der ist ja dann immer noch Mittler.
Und die Seite kann eben dann nicht frei entscheiden, wo jetzt gerade hingeschrieben werden soll, sondern einfach nur, hey, ich möchte eben diesen Riesenberg mit Maps schreiben.
Mir völlig egal, wo du die parkst.
Ich muss die jetzt schreiben, und ich brauch die später. Kümmer dich drum. So, ne?

[50:37] Ganz genau, und der Benutzer kann jetzt auch nicht erwarten, diese Dateien irgendwo physisch auf der Festplatte zu finden.
Intern kann es sogar sein, der Browser implementiert diese OPFS-Dateien, was auch immer, in eine SQLite-Database, oder was auch immer, und lasst das dann eben nur für den Benutzer aussehen, über das Interface, als wären das Dateien.
Ich weiß ehrlich gesagt nicht mal, wie es intern realisiert ist.
Das ist einfach dann im Browser irgendwie im Profil gespeichert, Aber letztendlich, ja, der Benutzer weiß nicht wie, kann auch auf diese Dateien nicht zugreifen, und, ja, das ist eben quasi dann die Idee dahinter, dass man auch sagt, selbst wenn jetzt da irgendein Virus sich auf der Datei registrieren würde, der Benutzer kommt, oder Trojaner, was auch immer, der Benutzer kommt nie in die Verlegenheit, quasi diese Datei auszuführen oder die Excel zu klicken oder was auch immer, einfach weil man kann überhaupt nicht drauf hin navigieren, nicht mit dem Terminal, nicht mit dem, was auch immer, Windows Explorer.
Das ist einfach private Evidence Origin quasi der Seite.

[51:42] Einfach ein High-Performance-Index-DB oder Local Storage letztlich, ne?
Der dann eben, ja genau, im Prinzip ist es das.
Und sieht auch nach außen eben einfach nur aus wie ein Dateisystem.
Ja, genau. Also wie gesagt, es kann sein, dass es als SQLite implementiert ist.
Ich weiß es nicht. Es ist einfach spezifiziert als dieses Interface muss es unterstützen.
Wie du browserintern das machst, ist dir überlassen.
Und das kann jetzt auch sein, Chrome, also wie gesagt, ich weiß es nicht, wie es umgesetzt ist, Das kann sein, Chrome speichert das als echte Dateien, irgendwo in Chrome Profile, bla bla.
Und es kann sein, WebKit, die setzen das als SQLite oder was auch immer Datenbank um.
Das ist einfach Implementierungsdetail, das kommt nicht nach außen.
Die Dateien sind nicht für den Benutzer erreichbar.

[52:30] Ja. Ja, interessiert ja auch keinen. Also, wenn die Performance stimmt.
Gibt es Fugu APIs, die nicht vom Chrome-Team gekommen sind?
Also, das passiert ja dann, also zum Beispiel bei Apple passiert das ja, die sind ja oft so, dass die jetzt, sagen wir mal, eher hinterher implementieren, aber manchmal kommen die dann und, hey, guck mal hier, Wir haben folgenden Vorschlag, und dann ist man so, sagen wir mal, überrascht, dass die auch mal wieder was einbringen.
Die machen super Arbeit, aber ich würde sagen, die sind jetzt noch nicht sozusagen vor der Welle.
Das heißt also, die implementieren eben tendenziell immer noch hinterher, gerade was so APIs angeht, vielleicht nicht so bei CSS.
Und dann kommt eben aber trotzdem hin und wieder, kommt was richtig Cooles von denen.
Ist das im Fugu-Bereich auch so, dass die anderen Browser-Ersteller dann auch irgendwie Dinge mal eingebracht haben?

[53:33] Also man muss vorsichtig sein, die Unterscheidung Chrome und Chromium.
Also Chromium ist ja das Open-Source-Projekt unter Chrome. Zum Beispiel Microsoft Edge, Samsung Internet und so weiter, die bauen alle auf Chromium auf.
In Project Fugu ist nicht nur Google, sondern da sind auch Microsoft, da sind auch Intel, da sind auch Samsung.
Interessanterweise auch Intel als Prozessorhersteller organisiert und verschiedene APIs kommen aus verschiedenen Ecken.
Also Microsoft, die Adbustern, die haben zum Beispiel auch Office mit Excel, die sie auf dem Web umsetzen möchten.
Die sind eben sehr daran interessiert, dass das Thema Clipboard reibungslos funktioniert, also sprich, dass man aus einer Excel-Tapelle mit Formatierung und was auch immer und Formeln direkt kopieren kann in eine Web-Excel-Tabelle oder in eine Web-Word-Datei oder in eine native, was auch immer, Microsoft-Powerpoint-Datei, und dass das eben alles quasi aus einem Guss funktioniert.
Das war's.

[54:35] Edge hat eben sehr viel Arbeit geleistet in puncto Clipboard und aus dem Chrome-Team kommen dann vielleicht andere Vorschläge, die jetzt wir mit unseren Partnern, was auch immer, Google Slides oder was auch immer, intern gehört haben als Use Cases oder natürlich auch extern.
Und ähnlich ist es bei Microsoft auch. Die sind zum Beispiel sehr interessiert am Thema Inking, also die haben mit dem Surface ein Gerät, das natürlich einen Touchscreen hat mit Stylus.
Und die wollen eben, dass man da so schön wie möglich draufschreiben kann.
Samsung, die haben verschiedene Foldable Devices, ich weiß gar nicht genau, wie die heißen, aber die klappbaren Handys, und die haben eben das Thema, ja, klappbare Devices, wie kann ein Browser feststellen, ist ein Gerät ein klappbares Device, wie kann ich über CSS oder über JavaScript sagen, dieses Element soll jetzt auf dem zweiten Windows-Segment dargestellt werden, und so weiter.

[55:33] Also, sprich, jeder hat so ein bisschen seine Vorstellungen und seine Motivationen, was man jetzt umsetzen möchte.
Wir werden immer wieder gefragt, warum ist denn Intel im Projekt dabei?
Die machen doch gar keinen Browser. Die Antwort ist, ja, Intel hat festgestellt, auf Intel-Prozessoren laufen eben mehr als 60% der Zeit irgendwelche Web-Anwendungen, und Intel hat eben deshalb gesagt, wenn diese Web-Anwendungen auf unseren Prozessoren laufen, dann sollen sie bitte schön auch gut und sauber laufen.
Und die haben dann interessante Proposals eingebracht, wie zum Beispiel die Compute Pressure API.

[56:09] Die einem erlaubt, als Applikation uns festzustellen, wie Beschäftigt ist dann gerade der Prozessor, wenn ich jetzt in der Videostreaming-Applikation bin und ich merke, der Prozessor ist bei 90% Auslastung, dann kann ich vielleicht mal kurzfristig von 4K runtergehen auf 2K oder was auch immer Videoauflösung und dadurch eben den Prozessor ein bisschen entlasten.
Elektron, das ist das, was der Vocher erwähnt, zum Thema Elektron und Cordova überflüssig machen.
Man würde denken, die würden, also zumindest jetzt Elektron, Cordova ist, glaube ich, so ein bisschen nicht mehr aktiv.
Ich will nicht sagen, tot, aber hab's jetzt auch nicht mehr in letzter Zeit verfolgt, vielleicht bin ich da falsch, aber jedenfalls Electron, da kann ich garantiert dafür sprechen.
Man wird jetzt erwarten, vielleicht, die hassen Project Fugu, weil das ja deren Ast sägt, auf dem sie sitzen. Das Gegenteil ist der Fall. Electron ist selber Teil von Fugu, und man fragt sich dann vielleicht so, hm, warum?
Die Antwort ist, jede API, die Sie im Chromium nutzen können, ist eine Node-API weniger, also eine Dependency für die weniger, die Sie mit reinziehen müssen.
Also, konkretes Beispiel, Web Serial wurde angeboten über, ich glaube, das Paket heißt Node Serial, und als das dann eben über Web möglich war, über die Web Serial API, konnten sie eine Dependency sich einsparen, also sprich, das Electron Gesamtpaket wurde kleiner, einfach weil der Browser mehr mitgebracht hat.
Und deshalb ist eben auch Electron mit dabei, und die sind eben auch daran interessiert.

[57:38] Ihre Dependency Trees so klein wie möglich zu halten und so viele möglich über die Browser APIs direkt abzuholen.

[57:48] Das heißt, es ist auch hilfreich, wenn diejenigen, die an diesen Features arbeiten, selber in-house-Use-Cases haben, sozusagen.
So wie früher XML, HTTP-Requests auch aus dem Outlook-Team kamen und so eben vieles damals im Internet Explorer gelandet ist, weil Microsoft eben einige Teams im Haus hat, die die Dinge gebaut haben.
Und ins Web bringen wollten, so ist es im Endeffekt auch ein Stück weit, und genau, das haben dann eben andere Browser, ja, Engine-Konglomerate vielleicht weniger, als die, die sich jetzt eben um das Chromium-Projekt herum gesellt haben.
Genau, aber wie gesagt, die sprechen eben oftmals auch mit denselben Partnern wie Google oder wie Microsoft oder wie Intel.
Das heißt, im konkreten Fall von Adobe, da können wir das erzählen, weil das alles publik ist, oder zumindest Adobe-Mitarbeiter auf Twitter publik gemacht haben.
Die sprechen halt auch mit Microsoft und die sprechen auch mit Apple.
Und auf die Art und Weise hat man eben auch so einen Hebel, wo man sagen kann, wir decken diesen genialen Use Case ab, liebe Browser-Vendoren, setzt doch das mal um.

[59:10] Und klar, je intrinsischer die Motivation ist, umso besser ist natürlich auch das Ganze, für ein kollektives Wohl.

[59:18] Und erzähl doch mal, was ist das Incentive für Anwendungsentwickler in den vermehrt Anwendungen auf Fugoo zu portieren?
Was beobachtet ihr da? Was ist so der Hauptantrieb für Firmen wie zum Beispiel Adobe, Photoshop zu portieren? Weil man könnte ja auch sagen, das ist jetzt so ein cooler Tech-Showcase.
Vielleicht hat da irgendwie Google auch so ein bisschen Invest drin, um sozusagen ein bisschen so ein Paradebeispiel zu haben, ein bisschen Show-off, so für, also eine Raison d'etre für Fugu zu schaffen.
Was ist so die Motivation für die Kunden?

[1:00:09] Also, ich würde sagen, für die meisten ist die Motivation dieses uralte der Write Once Run Anywhere.
Es ist natürlich in vielen Firmen so, dass sie verschiedene Teams beschäftigen, die die iOS App umsetzen, die Android App umsetzen und dann vielleicht auch die macOS App umsetzen und was auch immer.
Adobe natürlich, die sind auf allen Plattformen, v.a. auch mit nativen Apps präsent.
Und manche Firmen können sich das leisten oder wollen sich das leisten, aber letztendlich, wenn man dann so sich umschaut und dann überlegt, Ja, ist das denn tatsächlich nötig?
Dann sieht man bei ganz vielen Firmen eben auch das Bedürfnis, mit wenigen Entwicklern mehr Plattformen abzudecken.
Also, es gibt ja, was auch immer, Blogposts von Airbnb, und darüber sprechen, wie sie ich weiß nicht mehr, von React Native wegmigrieren oder hinmigrieren, ich weiß nicht mehr, in welche Richtung es war, vielleicht hat sich das auch wieder inzwischen umgekehrt, keine Ahnung, aber so, es gibt viele Firmen, die eben genau diesen Wunsch haben, schon irgendwie die nativen Plattform-Guidelines zu respektieren, also wo soll's der Action-Button sein, oder wie soll die Botten-Navigation aussehen, oder was auch immer, Aber letztendlich wollen sie eben auch sehr viel Code dann einsparen oder teilen zumindest.
Und da ist mit M-Scripten sehr viel möglich geworden in puncto Algorithmen, also bei Adobe oder was auch immer.

[1:01:37] Die pure Rechenleistung quasi in M-Scripten umsetzen und dann letztendlich nur noch das Interface nach draußen über Web-Anwendungen umsetzen zu lassen und mit der nativen Applikation wird dann oftmals eben der Großteil der MScripten APIs geteilt, aber letztendlich dann, ja, das User Interface wird vielleicht noch mal tief entwickelt, aber wir sehen eben ganz viel dieses Bedürfnis zu sagen, ja, wir wollen Code einsparen, wir wollen Code nutzen auf verschiedenen Plattformen.
Auf Desktop vor allem merkt man, viele Applikationen sind einfach inzwischen auf dem Browser zu Hause, Einfach auch über das Thema installierbare PWAs oder neue APIs, die möglich geworden sind.
Man merkt das auf Mobile auch ein Stück weit. Bisschen weniger, also da ist Nativ immer noch sehr, sehr stark.
Vor allem natürlich auf iOS. Vielleicht ändert sich das in Zukunft, gerade weil jetzt eben Push möglich geworden ist.
Und jetzt vielleicht nicht mehr jede News-Applikation eine eigene iOS-App und ne Android-App und ne was auch immer MacOS-App braucht.

[1:02:50] Sondern die jetzt inzwischen überall über Web alle abdecken können.
Und ja, ich denke, in diese Richtung wird sich da einiges entwickeln.
Safari war schon oftmals, oder ist oftmals nach wie vor, ein Hinderungsgrund, warum uns manche sagen, wir brauchen eben doch noch die nativen Apps.

[1:03:10] Ja, aber die geben ja wirklich auch gerade übelst Gas, Also vielleicht jetzt nicht was Fugu APIs angeht, aber so PWA, so der Kernbereich da und auch sonst.
Also das ist schon, ja, ist super.
Peter und ich haben auch letztens erst eine Folge dediziert zu den Tech Previews des Safari gemacht, was da wieder an Feature Lawinen auf einen zurollt.
Das ist schon super.

[1:03:43] Also, ich bin auch persönlich sehr gespannt auf iOS 16.4, was da final herauskommen wird.
Bin bei jeder Beta mit dabei und ja, da ist schon sehr, sehr viel Fugoliebe auch dabei und gerade, was jetzt APIs angeht, wo wir gemeinsam mit den anderen Vendoren auch ein gemeinsames Verständnis haben, also sprich, zum Beispiel Webshare oder zum Beispiel Webtransport, zum Beispiel Webcodecs, da ist einfach auch so ein gemeinsamer Antrieb zu spüren, bei den ganzen Teams auch, wir wollen Anwendungen auf dem Web ermöglichen.
Und solange da keine großen Risiken, in Anführungszeichen, damit verbunden sind, sind die anderen Vendoren eben auch dabei.
Und die ganzen Diskussionen sind, man tut das immer so vielleicht negativ ab, ja, Apple ist ein Bremser und was auch immer, aber die ganzen Diskussionen sind natürlich auch sehr, sehr hilfreich, um eben auch.

[1:04:35] Als jetzt jemand, der eine API umsetzen möchte, festzustellen, was sind denn mögliche Sicherheitsrisiken.
Wir setzen immer natürlich auch voraus, dass die B3C-Tag, also die Technical Architecture Group, involviert wird. Jede API, jeder Vorschlag für eine API, wird von der Tag reviewed auf Security, auf Privacy, auf verschiedene andere Aspekte, und wenn jetzt die Tag sagt, das ist eine furchtbar schlechte Idee, dass sie das macht, dann blockiert uns das nicht, also wir hören nicht auf, dann zwingend, weil die Tech Nein gesagt hat, irgendwas zu shippen, aber es gibt uns dann schon sehr zu denken, und typischerweise wird dann eben nochmal zurückgegangen und geschaut, kann man vielleicht die Tech, ja.

[1:05:19] Über verschiedene andere Limitierungen oder Begrenzungen oder was auch immer, dann vielleicht überzeugen, das ist doch eine gute Idee.
Manchmal ist das Resultat dann die Agree to Disagree, aber oftmals ist eben auch genau das Gegenteil, dass man sagt, okay, das war vielleicht in der ersten Iteration keine so gute Idee, Ich lasse das nochmal zurückgehen.
Vielleicht ganz von vorne planen, vielleicht nochmal ein Stück weit zurücknehmen und Teilschritte neu planen.
Und das ist auf jeden Fall Teil des Ganzen, das bei Fugu auch eine Sache, ja, am Ende als Resultat haben kann. Wir haben es versucht, aber es ist nichts am Ende dabei rausgekommen, was wirklich alle zufriedenstellt.

[1:06:03] Ja, ja, klingt gut. So will man das ja eigentlich auch bei der Softwareentwicklung haben, dass viele Meinungen da irgendwie zusammenkommen und man das beste Destillat daraus macht, oder eben auch irgendwelche Features gar nicht erst implementiert.
Dann vielleicht noch die abschließende Frage. Wir reden ja darüber, dass idealerweise das Project Fugu und dieser PWA-Bereich dazu führt, dass wir Anwendungen, die wir bisher entweder nativ geschrieben haben oder irgendwie als Hybrid-Anwendungen verpackt haben, dass es nicht mehr nötig ist, die auf diese Weise zu programmieren und zu shippen.
Also, ich finde, was bei den Web-Apps immer noch ein großes Problem ist, und vielleicht ist das aber auch nur mein subjektives Empfinden, ist, dass es, und das fand ich bei Firefox auch ein Problem damals, es gibt keinen richtigen Store, Also keinen ausgewachsenen Store mit einer guten Discoverability, vielleicht noch ein bisschen Curation, ist natürlich auch nicht schlecht, damit nicht nur Müll da drin ist.
Und eben vielleicht auch noch der Möglichkeit, Payments durchzuführen, also Anwendungen für Geld zu kaufen.

[1:07:29] Um den Bereich hört man irgendwie nicht so viel, und das erstaunt mich, weil ich glaube, dass das ein ganz wichtiger Baustein ist, auf dem Weg da in diese Zukunft, die wir uns da ausmalen.
Weißt du da irgendwie Dinge zu berichten?
Ja, also ein paar Dinge sogar. Erstmal, PWAs sind ja inzwischen auch auf vielen App-Stores willkommen.
Also Microsoft zum Beispiel, die betreiben sogar PWIBuilder.com an so eine Umwandlungsmaschine, wo man seine URL eingibt, und dann kommt am Ende eine PWA raus, die man über den Microsoft Store serviten kann. Die haben verschiedene Plugins auch für, oder Plugins, verschiedene Subfeatures für den Oculus Store, dass man seine PWAs so bekommt, dass sie auf Oculus Devices laufen.
Die haben sogar einen iOS-Wrapper, der dann über WKWebView das Ganze implementiert.
Und, ja, also, lange Rede, kurze Sinnen, viele App-Stores sind inzwischen auch offen für PWRs.
Der Play Store übrigens auch, über sogenannte Trusted Web Activity, wo einfach quasi eine Fullscreen-Webview läuft, die dann die ganze PWR abbildet.

[1:08:49] Es gibt natürlich auch immer die Möglichkeit, irgendwelche PWA-Directories zu bauen, zu basteln.
Da ist gerade im Stealth-Modus was, was mich erreicht hat. Ich weiß nicht, weiß den Namen nicht mehr, aber PWA-Rocks oder was auch immer, gab's ja in der Vergangenheit, also in diese Richtung, oder AppScope, gab's ja schon verschiedene Ansätze.
Da gibt's wohl irgendwas, was gerade so im Stealth-Modus, wie gesagt, ich weiß den Namen gerade nicht, aber können wir vielleicht auch nachreichen, oder wenn's Stealth ist, dann vielleicht doch nicht.
Vielleicht erst nach Release das Ganze. Aber da gibt's jemand, der sehr viel Humor intern macht.

[1:09:27] Auf den verschiedenen sozialen Netzwerken.
Und ja, wir haben bei Google natürlich auch uns überlegt, wie können wir denn coole Fugo-Use-Cases und Fugo-Applikationen darstellen.
Und da haben wir den sogenannten Fugo-API-Showcase entwickelt, wo man als App-Entwickler sagen kann, Ich möchte meine Fugo APIs gelistet sehen und man kann dann sagen, ich bin App-Entwickler, ich möchte meine Applikation, die heißt abc.com darstellen.
Im Fugo Showcase, ich verwende die API x, y, z und man schickt das dann über ein Formular ab und dann guckt jemand rüber vom Team und sagt dann, okay, das ist CURL-Spam, das ist alles legitim.
Wenn man den Source-Code hält, kann man das natürlich auch im Formular mit angeben.
Und ja, wir haben inzwischen eine ganz schöne Kollektion an filterbaren Fugo-Applikationen in unserem Showcase, wo man sagen kann, ich bin interessiert an Apps, die den Namen Futo im Namen haben und was auch immer die File System Access API verwenden.
Und ja, da kann man eben sehr schön slicen und dicen und gucken, dann gibt's welche davon, die vielleicht auch von SoaS sogar sind, und dann kann man auch immer so ein bisschen spickeln, wie haben die denn das implementiert, und sich dann Inspiration holen.

[1:10:49] Ja, habe ich eben im Vorfeld der unserer Aufnahme, habe ich auch nochmal da ein bisschen geguckt und gefiltert und geschaut, welche Anwendung denn welche, auch vielleicht ein bisschen exotische API nutzen könnte.
Genau, ja, super interessant.
Also, ist offen für alle, wenn ihr, liebe Hörer, an der API arbeitet, aber abarbeitet, die Fugo APIs einsetzt, gerne über das Formular, das im Showcase verlinkt ist, abschicken, und dann werden wir das gerne lösen.
Genau, das kommt in die Show Notes rein, sowie auch die ein oder andere Geschichte, die während des Erzählens gefallen ist.
Genau und du hast ja auch in unserem Projektboard für diese Aufnahme hast du auch noch ein paar Links hinterlegt. Die wandern da auch alle rein.

[1:11:44] Ja, super. Ich würde sagen, damit haben wir das Thema Fugu ganz gut, oder da uns ganz gut wieder auf Stand gebracht.
Fürs Erste?
Fürs Erste, genau. Da die Annahme ja nicht stimmt, dass sozusagen da sich gar nicht mehr so viel ändert, hoffen wir natürlich darauf, dich spätestens in, na ja, vielleicht nicht in vier Jahren und auch nicht in dreieinhalb hier wieder begrüßen zu dürfen.
Genau, ihr seid ja jetzt in einer neuen Phase, wo ihr fein schleift, und das ist bestimmt auch echt spannend, und das sind vielleicht sogar fast die dickeren Nüsse zu knacken, die ihr da habt, also mit diesen ganzen Permissions und Userflows und so, da bin ich sehr gespannt, wo uns das hinführt.
Ja, ich auf jeden Fall auch. Vielen, vielen Dank für die Einladung, dass ich das zweite Mal hier erzählen durfte, und vielen Dank auch für die tollen Fragen, die ihr vorbereitet habt.
Ja, also in drei Jahren oder vier Jahren oder was auch immer, gerne wieder am Start.
Ich freue mich. Oder früher. Oder früher.
Genau. Wenn du was hast, sagst du Bescheid. Und wenn unsere Hörerinnen und Hörer Fragen oder Feedback haben, dann findet ihr uns.
Also ihr wisst ja, wo ihr uns findet.
Und den Thomas findet ihr, wie gesagt, als Thomajag auf Twitter und auf Mastodon, Thomajag at, was ist das, frontend.social oder sowas? Ich habe Tooth, Pong, Kaffee.

[1:13:10] Ich war auf Mastodon, bevor es cool war. Ja, ich auch, aber ich bin bei Mastodon.social gelandet.
Und Frontend.social gibt's ja, da sind die coolen Leute, aber die sind schon dicht.
Ich glaube, weil man kann ja maximal 150 Leute auf so einen Server packen und dann ist der schon irgendwie am Limit.
Das scheint sehr viele Ressourcen zu ziehen.
Alles klar, also tomajack.at.tud.café.
Genau.
Ja, vielen Dank fürs Zuhören.
Und genau, nächste Woche ist dann wirklich der Marvin Hagemeister da.
Wo ich schon letzte Woche überlegt hatte, ob der möglicherweise diese Woche unser Gast ist, aber es war fast andersrum, und der Thomas war der Gast, und Marvin kommt nächste Woche.
Und dann reden wir darüber, wie man das JavaScript Ökosystem und die Build-Tools schneller machen kann und noch nicht direkt auf Rust wechseln muss.
Glaub ich.
Alles klaro. Also, bis dann. Tschüss. Tschau. Tschüssi. Danke!

[1:14:16] Music.