Bun 1.0 // Flutter 3.13 // PowerSync // Jetpack Compose Multiplatform // Astro 3.0 // Unity Fee // Node 20.6

Hallo und herzlich willkommen zur Programmierbar News 38 23 mit folgenden Themen heute und zwar Flutter 313 Flutter Power Sync, ChatPack Compose. Ansonsten ist Astro 3 rausgekommen, BAN 1.0 und wir sprechen ein bisschen über das Unity Bezahlmodell. Ich bin der Sebi und heute mit mir hier. Ist der Garald. Und der Jojo. Dann würde ich sagen, starten wir gleich los, oder? Fea möchte anfangen. Ich fange mal an. Genau. Ist ja jetzt eine ganze Zeit her gewesen. Wir hatten ja wie Sommerpause dazwischen und wir haben wirklich so in einer langen Liste von Themen irgendwie gesucht und gegraben und geguckt, okay, was ist das Wichtigste ist. Da wir ja auch viel in Flutter unterwegs sind, habe ich gesagt, ich nehme so ein paar Flutter Themen mit, die einfach in der Zwischenzeit entstanden sind und stelle ein bisschen was vor. Also in der Zwischenzeit hatten wir zum Beispiel den Release von Flutter 313. Das ist jetzt die neueste Version. Das ist ungefähr vor zwei Wochen rausgekommen. Wir haben noch nicht geupdatet, weil wie immer gibt es noch einige irgendwie Patch-Versionen, die hinterherkommen, die so ein bisschen was fixen und wir haben so die Erfahrung gemacht, also die erste Version ist nie ganz gut. Was vor allem sich in dieser Version getan hat, ist, dass sie halt sehr stark an der Empeller Engine weitergearbeitet haben. Empeler Engine haben wir, glaube ich, in verschiedenen Newsfolgen schon mal so ein bisschen thematisiert. Was es ja eigentlich ist, ist, dass die neue Rendering Engine von Flutter ist und diese alte oder die vorherige Skier-Engine ersetzt. Und was einfach der wesentliche Vorteil ist, dass es halt eben die Aufwärme der Shader, also letztendlich alle Artefakte, die irgendwie von Zeichnen, von Komponenten auf der UI verwendet werden, nicht mehr zur Laufzeit gemacht werden. Das ist ja das große Problem mit Skier, dass man halt eben gerade auf iOS Geräten sehr stark diesen Animation-Jank hatte, weil eben die Shader Dateien nicht da waren, erst mal diese ganzen Caches aufgewärmt wurden und dadurch die ersten Animationen sehr, sehr ruckelig waren. Und das ist eben der Hauptpunkt, für den eigentlich Impeler eingeführt wurde. Und da werden alle Shader und alle Reflexionen, die irgendwie in der UI vorkommen, zur Bildzeit kompiliert. Ich frage mich immer, wie sie das machen. Irgendwie werden sie wahrscheinlich intelligente Ansätze haben, wie sie das rausfinden können. Und man gewinnt aber außerdem durch Portabilität für die Entwickler, weil es eben Flutter sehr unabhängig von der Client Rendering API ist. Also es ist nicht mehr irgendwie abhängig von Vulcan oder Metal, sondern hat da eben eine eigene Zwischensticht. Natürlich wird untendrunter wahrscheinlich Bestandteile von diesen Rendering APIs verwendet, aber es ist eben so, dass es auf einer viel tieferen Ebene passiert. Und seit 3.10 ist ja schon die Impeller jetzt die Standard Engine für iOS geworden. Wir haben das gerade zum Beispiel auch noch deaktiviert. Wir sind jetzt auch auf der 3.10, aber es ist so, dass ein paar Funktionalitäten noch nicht funktionieren, wie zum Beispiel „Pain-Styl-Stroke wird noch nicht unterstützt. Und deswegen, weil wir natürlich ein Spiel haben, wo man sehr viel irgendwelche Texte hat, irgendwelche Outlines bekommen, die dann eben diesen „Pain-Styl-Stroke brauchen, können wir noch nicht darauf gehen. Dafür gibt es aber auch einen Fix, der irgendwann kommen wird, aber jetzt noch nicht in der 313 gelandet ist. Und die Impeler Engine ist jetzt eben auch für andere Plattformen eben auch verfügbar. Das heißt, wir haben für Mac OS und auch alle anderen Desktop Plattformen, glaube ich jetzt, für Mac OS ausschließlich gerade noch, eben eine Preview Version. Auch Android ist ein Preview Status. Ist noch ein bisschen experimentell. Das heißt, man kann es aktivieren, sollte es aber noch nicht für Produktions Zwecke nutzen, dann ist es natürlich auch interessanter, dann insgesamt auf die Impeler Engine zu switchen, worauf sie sich eben aktuell eben hauptsächlich fokussiert haben, dass sie eben die Performance für iOS deutlich erhöht haben. Das heißt, man hat jetzt hier eine deutlich geringere Latenz und viel höheren Durchsatz von den Frames, die gezeichnet werden müssen. Und sie haben verschiedene Benchmarks, die sie dagegen haben laufen lassen. Und da ist es so, dass bei vielen Benchmarks nur noch die Hälfte der Rasterzeit … Also es gibt in Flutter eigentlich immer zwei Phasen. Einmal ist sozusagen das Layouten, wo einfach sozusagen die UI positioniert wird, gelayoutet wird und dann kommt das Raster, was letztendlich dann die entsprechenden Informationen dann wirklich in Bildpixeln umwandelt. Und das ist wohl eben extrem viel mehr deutlich performanter geworden. Sonst gab es eigentlich gar nicht so viele Neuerungen. Also die große API Neuerung, die eben gekommen ist, dass jetzt zweidimensionales scrollen unterstützt wird. Es gibt einfach zwei neue Widgets. Zweidimensionales scrollen heißt aber, ich kann nicht nur nach oben und nach unten scrollen, sondern es gibt es eben Komponenten, die auch erlauben, dass ich diagonal scrollen kann, wenn ich das brauche. Und was sie eben ein bisschen an der Plattform-Unterstützung haben sie ein bisschen was geschraubt. Also zum Beispiel auf Android werden die API Level 16, 17, 18 nicht mehr supportet. Dafür wird aber das neue Android API Level 34 supportet. Und wenn ihr jetzt eben schon für iOS 17 und X-Code 15 entwickeln wollt, müsst ihr auch die 3.13 verwenden, weil dafür wohl kein Support vorhanden ist in den vorherigen Flutterversionen. Mit Flutter-Releases gibt es ja auch meistens neue Data Releases. Da ist eigentlich nicht so viel passiert. In Data 3.2 ist etwas hinzukommen, was so ein bisschen vielleicht den Entwicklern das Arbeiten vereinfacht, das Schreiben vereinfacht, das nennt sich Private Feed Promotion. Es ist einfach so, wenn ich Private final field habe, die irgendwie null sind, ich dann irgendwo eine Abfrage habe, ist letztendlich diese private Variable irgendwie nicht Null? Dann ist es so, dass in den anschließenden Kontexten ich nicht noch mal sozusagen diesen null Asserting Operator nutzen muss, das zu Casten vor was immer so ist. Konnte natürlich jederzeit zur Laufzeit oder eigentlich war im File natürlich nicht zur Laufzeit sich diese Variable ändert. Deswegen hat immer der Compiler gesagt, es ist nicht ganz sicher, ob letztendlich dieser Null Check, den du direkt eine Zeile obendrüber ausgeführt hast, immer noch gültig ist, weil irgendwelche Nebenläufigkeiten von Code oder Funktionen, die du aufrufst, natürlich dazu führen können, dass sich das verändert. Aber ja, sie können das in gewissen Kontexten jetzt besser aufschlüsseln. Wenn eine Variable final ist, dann muss man letztendlich diesen Check nicht mehr ausführen. Es gibt, glaube ich, ein paar Stellen bei uns im Code, die das irgendwie ein bisschen vereinfachen. Aber das war so die große Neuigkeit. Die haben sich so ein bisschen zurückgehalten bei drei, zwei und DATE1 Änderung. Die haben dafür eine sehr ausführliche Roadmap vorgestellt, was an neuen Features in den nächsten DATE Version kommen wird. Und da wird auf jeden Fall einiges Spannendes dabei sein. Aber eher waren dieser Release eher so eine Roadmap Vorbereitung, die weiteren Entwicklungen dann eben einbringen zu können. Okay, cool. Hast du eine Einschätzung, wann ihr Empeler nutzen könnt? Haben sie irgendwas gesagt? Also ich glaube, dieser Fix, auf den wir warten. Ich wollte eigentlich vorher noch mal reinschauen, es war auf jeden Fall so, dass wir vor zwei Wochen war es noch nicht in der Umsetzung, aber dass zumindest so aussah, das wird jetzt bald auf einen Alpha Kanal kommen. Dann hat man natürlich einen gewissen Release Zyklus. Also es kann schon bis zu zwei Monate dauern, bis wir letztendlich da auf Impella switchen können. Ja, das wäre nicht mehr so lange. Wäre schon spannend. Ihr habt es wahrscheinlich auch noch nicht ausprobiert, ob ihr da irgendwie Performance. Verbessern könnt. Also wir haben letztendlich ja das mal aktiviert bei uns und uns das angeschaut. Wir haben gesehen, wir sehen eigentlich eine ähnliche Performance Line. Also wir haben uns jetzt nicht irgendwie die Ausgaben in den Debug Tools angeschaut, das mal zu verifizieren, sondern rein irgendwie optisch geguckt, passen die Sachen, werden sie so gerendert, wie sie vorher gerendert wurden? Und dabei ist uns eben aufgefallen, dass das halt noch nicht die Unterstützung für dieses Pain Sky Stoke gibt. Ja, aber wir haben jetzt noch nicht tiefer drüber hinaus. Also was ja eigentlich gesagt ist, es soll eigentlich auf jeden Fall eine bessere, eine gleich gute, wenn nicht bessere Performance bieten. Aber das sollte sich natürlich dann auch bestätigen, auch wenn sie natürlich auch so viel Zeit investieren und gerade solche Aspekte jetzt noch mal irgendwie deutlich verbessern, wie sie jetzt dieses Mal gemacht haben. Dann haben wir noch ein Thema, was auch mit Flutter beginnt, PowerSync. Ja, es stimmt. Es gibt da... Ich weiß nicht, ob das Thema so spannend ist. Erstklang ist spannender als es vielleicht ist. Also was es auf jeden Fall ist und das ist natürlich etwas, wo wir auch in dem Zuge mehr mit zu tun haben, dass es eine neue Offline First dannBank für Flutter-Applikationen ist. Sie ist aktuell noch in der Beta und auch noch nicht für produktive Einsätze gedacht. Wurde erst vor ein paar Tagen so in den verschiedenen Kanälen irgendwie gedropt. Was es eigentlich ist, ist eigentlich ein Cloud Service, eine Postgreif-Datenbank, On-Device-Datenbanken auf einem Gerät irgendwie in Sync zu halten. Und man kann eigentlich so vom grundsätzlichen technologischen Anspruch jede Postgreif-Datenbank ansprechen. Das heißt, man könnte das auch selber hosten oder irgendwie eine andere Cloud gehostete Datenbank dafür nutzen. Dazu muss man eigentlich auf dieser Datenbank ein bisschen was machen, nämlich diesen Riterhack Log aktivieren. Das ist etwas, was von Postgreif genutzt wird, sich auch mal zwischen verschiedenen Knoten zu synchronisieren. Und man muss letztendlich noch ein User für PowerSync mit den entsprechenden Rechten auf der Datenbank einrichten. Aktuell unterstützt diese PowerSync eben nur PostgreS und hat auch nur eine SCK für Flutter. Deswegen habe ich es mal so zu dem Flutter Thema gepackt. Aber es ist auf jeden Fall so, dass sie sagen, sie möchten in Zukunft eben auch andere Datenbanken unterstützen. Also MySQL und Microsoft SQL Server haben sie explizit aufgeführt. Ich glaube alles etwas, was natürlich so ein bisschen auf dem SQL Standard basiert, werden sie damit abdecken können. Und sie wollen auch andere SCKs oder SCKs für andere Programmiersprachen veröffentlichen. Also JavaScript, SWift, Kottlin haben sie genannt. React soll eine eigene SCK bekommen. Aber das ist so ein bisschen Zukunftsmusik. Also das ist der erste Wurf. Und technisch funktioniert es vielleicht ganz interessant, weil wir natürlich eine andere Lösung haben, die man vielleicht ein bisschen vergleichen kann. Also letztendlich ist es so, dass PowerSync eine Client-STK mitbringt, eben für Flutter, und die speichert alle Daten in einer lokalen Datenbank auf SQLite. Also ist ja eine sehr etablierte Datenbank im Mobile Umfeld. Und dann liegt man letztendlich in der PowerSync UI, also PowerSync ist sozusagen erst mal ein Cloud Service, was letztendlich dann in der Web, im Web irgendwie eine Administrations-Überfläche bietet und ich kommuniziere letztendlich dann von meiner, von meinem Client zu dieser PowerSync Cloud Lösung. Und was ich dort eben festlege, sind einfach Sync-Rules, mit denen man so ein bisschen definieren kann, okay, auf welche Tabellen, auf welche Daten, also Rows innerhalb der Tabelle hat ein bestimmter User, der gerade verbunden ist, eben gerade Zugriff. Das kann man auch so ein bisschen dynamisch gestalten. Aber letztendlich sind das vor allem letztendlich so SQL basierte Statements, die man definiert, Regeln festzulegen, auf welche Daten zugegriffen werden kann. Dann nutzt PowerSync diesen Reiter-Headlock des PostgreCus-Servers und damit auf dieser PowerSync Zwischenschicht ebenso einen kontextbasierten Ausschnitt der Daten für den verbundenen Benutzer, weil wahrscheinlich nicht jeder Nutzer die gesamte Datenbank irgendwie sehen muss oder für ihn relevant sind, kriegt er sozusagen für sich in dieser Zwischenschicht eine User spezifische Sicht der Daten irgendwie generiert, die sich natürlich an diesen Sync Regeln hält. Und dann kümmert sich diese Power Sync Schicht eben darum, dass letztendlich dieser Kontext basierte Sicht, dieser Ausschnitt der Daten eben für den Benutzer konsistent gehalten wird. Also er gleicht das eben gegen den Postgreif Server ab. Was ändert sich an diesen Daten und aktualisiert in seiner Repräsentation immer die entsprechenden Einstellungen und kann das natürlich dann zu einem verbundenen Client dann pushen. Wenn jetzt Änderungen an Daten passieren, da wird es ein bisschen spannender und vielleicht auch nicht so schön, würde ich mal sagen. Wenn jetzt Daten lokal gespeichert werden oder geschrieben werden, werden die erst mal in der lokalen Datenbank präsentiert und dann in so eine FAQ geschrieben, was einfach sozusagen eine FAQ der Änderung ist. Und immer wenn man Netzverbindungen hat, wird diese dann abgearbeitet. Es ist aber so, dass man in dem Fall nicht direkt mit diesem PowerSync Cloud Service kommuniziert. Also er macht eigentlich vielmehr eigentlich nur die Lese-Operation, sondern ich brauche eigentlich noch eine zweite eigene Backend-Applikation, die letztendlich diese Changes dann entgegen nimmt. Das ist einfach ein Satz an Operationen. Also es werden PUT, Patch und DELETE-Operationen unterstützt. Und was man dann sich dann zum Beispiel machen muss, wenn man – weil das ist ja immer so ein bisschen die Schwierigkeit, wenn ich letztendlich so eine gesunkte Datenbank habe – was passiert denn, wenn ich Kollisionen habe? Was passiert, wenn letztendlich zwei Clients den gleichen Datensatz in der gleichen Zeit irgendwie verändern? Welcher gewinnt dann? Wem soll letztendlich da dieses Konflikt-Handling übergeben werden? Und da bietet eineigentlich PowerSync wirklich sehr, sehr rudimentäre Ansätze, nämlich drum, weil es ist nämlich so, dass das Backend diese ganzen Update-Operationen eigentlich entgegennehmen muss und dann selber entscheiden muss, stimmt der Daten oder der Datenbestand, den ich da gesehen habe, das Update, was ich dort sehe, noch zu dem Datenstand, den ich irgendwie lokal sehe. Also sozusagen dieses ganze Konfliktmanagement und den Abgleich eigentlich mit meinem lokalen Stand, muss ich dann auf meinem einweckenden System implementieren. Das heißt, ich brauche da auf jeden Fall Lösungen, wo andere Lösungen, wo ich vielleicht darauf eingehe, natürlich schon viel integriertere Lösungen haben und sagen: „Okay, die kümmern sich das ganze Annehmen der Daten dieser Patch-Operation, und zeigen dir eigentlich nur an, das ist die veränderte Version des Dokumentes und ich sehe sozusagen meine lokale Version. Welche von diesen beiden Versionen möchtest du letztendlich dann übernehmen? Wenn ich sogarund damit habe ich noch nicht mit dem Nutzer natürlich eine Auswahlmöglichkeit gegeben, sondern ich muss Backend-seitig eine Logik implementieren, die das unterstützt. Und da kann ich mich natürlich dafür entscheiden, einfach so eine Default-Strategie zu verwenden, dass ich sage „last right wins, dann muss ich mir vielleicht nureinem Zeitstempel von diesen ganzen Dokumenten oder von diesen Update-Operationen angucken und das vergleichen. Wenn ich was irgendwie komplexeres haben will, ist das schon ein bisschen aufwendiger. Wenn ich das alles Client-seitig machen möchte und das ist oftmals ja etwas, was ich will, dass ich dem Nutzer eigentlich diese Auswahl geben will: Für welchen dieser Datenbestände möchtest du dich jetzt entscheiden, dann ist es so, dass ich mir eine separate Tabelle anlegen muss, was nur sozusagen diese Ride-Konflikte irgendwie abbildet. Jedes Mal, wenn ich auf meinem Backend-System einen Konflikt feststelle, schreibe ich das in diese Konfliktabelle. Das wird wieder zum Client irgendwie gesüngt. Der muss das entsprechend auflösen. Vielleicht irgendwie dann natürlich eine Update-Operation oder auch ein neues Dokument irgendwie schreiben, was dann diese Resolution eigentlich darstellt. Und dann muss sich letztendlich das Backend-System wieder darum kümmern, das zu verheiraten. Also man sieht schon, gerade für diesen Konfliktlösungsfall ist da ein bisschen was zu tun. Und das bringt uns natürlich zu dem Vergleich mit einem System. Wir nutzen ja, wir haben einen ähnlichen Ansatz, wir nutzen auch eine Offline-First-Lösung, nutzen dafür aber Couch-Base. Dazu könnt ihr auch den DeepDive 1001 euch anhören mit Gabri, Terwest und Kregor Bauer von Couchbase, der sehr in die Tiefe geht, wie das funktioniert. Und das ist eigentlich genauso, wie wir es jetzt bei PowerSync haben, inzwischen ein DataBase as a Service Konstrukt. Also wir nutzen da Cappella von denen. Man kann das natürlich auch selber hosten, aber die haben eigentlich auch so einen On-Cloud Service, den man eben nutzen kann. Und es ist eigentlich von der technischen Struktur genau das Gleiche. Ich habe letztendlich eine Couchbase Datenbank, ich habe dann auch, das ist das, was das Postgreif wäre. Dann habe ich meine App Service Nodes, die machen die ganze Kommunikation über Web Sockels zu den Client. Und dann habe ich noch eine SQLite Datenbank, die die Daten auf dem Client vorhält. Das eine Schöne letztendlich in Couchbase ist, dass das alles unter einer Benutzeroberfläche gekapselt ist. Also ich habe letztendlich Kapelle, letztendlich meine Datenkonfiguration, genauso wie meine Authentifizierung zu verwalten, wie meine Benutzer zu verwalten und brauche da letztendlich nicht in zwei Ebenen reingehen. Und die Kollisionsbehandlung wird direkt vom Couch bei Server unterstützt. Das kann man entweder in JavaScript machen oder in einem anderen Programmauch noch, ich glaube, Lula wird da auch unterstützt. Oder ich habe halt diese Möglichkeit kleinteilig und das ist halt genau das, was wir verwendet haben, ohne dass wir da noch ein zusätzliches Backend gebraucht haben. Wenn man vielleicht diese Fälle nicht hat, dann ist vielleicht ein Anwendungsfall interessant. Das ist nämlich, dass man PowerSync direkt mit SuperBase verwenden kann. Und SuperBase, da hatten wir auch schon mal einen DeepDive irgendwie zu, DeepDive 93 mit Torchef, ist ja eine Open Source Alternative zu Firefox, was einfach sehr ähnliche Funktionalität wie Firefox bietet, aber so was auch wie Edge, Function, Storage und Vector Embedded bietet. Und dafür gibt es natürlich auch schon entsprechenden Flutter Package. Aber da ist es eben so, dass man das gleiche Problem eigentlich wie bei Firefox hat, dass das eigentlich keine richtige Offline Funktionalität hat. Man hat auch so eine Art Feeflow Queue, wo alle Änderungen irgendwie lokal gespeichert werden, aber immer auf dem letzten gesunkten Stand eigentlich angewendet werden. Also je länger ich offline bin, je mehr Änderungen sich lokal anhäufen, desto länger sind sozusagen immer diese Patch-Operationen, auf dem letzten gesunkten Datenstand meinen aktuellen lokalen Datenstand herzustellen. Deswegen ist es halt immer nur für eine Zeit. Die reden immer davon, wenn du mal durch den Tunnel fährst, ist in Ordnung, aber eigentlich nicht dafür ausgelegt, jetzt tagelang sehr schreibintensive Operationen durchzuführen, was es dann irgendwann sehr langsam macht. Aber das kann man direkt eben verknüpfen. Das heißt, da haben sie auch einen ganz guten Blogartikel, wie man das eben verbinden kann. Ist, glaube ich, für einige Anwendungsfälle spannend. Also wir hatten uns einfach mal angeschaut, zu sehen, kann es eine Alternative sein. Für uns ist auf jeden Fall CouchBase da einfach die komplettere Lösung, weil wir einfach mehr von diesem ganzen Konfliktmanagement abbilden können, was wir sehr intensiv brauchen. Ja, gut. Ja, der Vorteil von SuperBase ist ja auch Postgreif-basiert. Genau. Ja. Na mal. Gucken, was braucht es denn in der Zukunft. Die haben jetzt auch erst die, was ist gerade neu, geil. Das ist irgendwie vom kleinen SCKM in null null. Also es sieht auf jeden Fall so aus. Die haben zwar eine sehr gute Marketing Seite, also auf jeden Fall sehr hübsch, optisch sehr hübsch aufgemacht. Aber ich glaube, es dauert natürlich noch ein bisschen. Das halbe Leben. Genau. Und von wem ist das? Ich glaube, das heißt Journey Apps ist letztendlich die Seite, über die man einen Account kreiert. Also ich weiß nicht genau, wer dahinter steckt und was es auch immer kostet. Also momentan ist das eben eine Trial-Phase, die komplett frei ist. Aber das wäre natürlich auch mal so ein Punkt, den man da gegenhalten muss. Auch Couchbase bedarf natürlich gewisser Lizenzkosten, wenn man das wirklich irgendwie in diesem Cappella Service betreibt. Und das müsste man natürlich mit entsprechenden Super-Base-Kosten und Power-Sinn-Kosten dann noch mal vergleichen, wenn man dann final irgendwie weiß. … Ja, dann … Und dann updaten wir irgendwann, wenn sich da was tut. Ja, genau. Schieben wir ein Update nach. Alles klar. Apropos, ein Update. Astro hat ein. Update nachgeschoben. Astro hat ein Update nachgeschoben. Am 30. August kam Astrot 3.0. Für diejenigen, die nicht wissen, was Astrot ist, ich kann das heute Morgen auch nicht –, ist ein Web Framework, womit man einfach sehr schnell hauptsächlich statische Seiten bauen kann, aber auf Web Application, also es ist nicht darauf begrenzt, sondern es ist vergleichbar mit Naxed, Gatsby. Sie vergleichen sich selbst auch mit WordPress, was ich auch spannend finde und bieten einfach... Erstmal okay, wir bieten viel, viel bessere Performance. Und aber was AStro 3 gebracht hat, war eine ganze Reihe an Sachen. Und das Spannendste fand ich, dass sie die Vue Transition API eingebaut haben, die ja relativ neu ist. Du hast sie schon selbst ausprobiert und mir zeichnet. Du hast mir coole Sachen gezeigt. Und zwar ist diese View Transition API im Prinzip dazu gedacht, relativ einfach Transitions von Elementen auf der Seite darzustellen. Ob es jetzt von einer Page zur nächsten ist oder auf der Seite selbst, ist eigentlich egal. Aber es geht darum, ohne viel Aufwand da so Fades, Slides oder Mof Animationen einfach darstellen zu können. Und die binden das relativ einfach ein. Also es ist wohl wirklich so einfach, dass du einfach eine Komponente von ihnen einbindest und dann funktioniert das. Also es sah sehr einfach aus, so wie sie es dargestellt haben. Das ist. Ja Promising. Ist es denn schwer? Dann wäre das irgendwie so im JavaScript Code direkt anzubinden oder macht man das über CSS, diese View Transitions, weißt du, wenn du das einfach so Vanilla irgendwie koden würdest? Also, ich sage mal ins Vanilla. Die View Transition API ist aktuell nur in Chrome, ist aber schon seit Chrome 111 drin. Und das funktioniert so, dass man innerhalb von einer Funktion irgendwas am Dom ändert, also irgendeine Änderung machst. Und er macht einen Snap, also ein Bild von einem Anfang und vom Ende. Und dann kannst du im Default Modus macht er halt ein Cross-Fade, kannst aber die einzelnen Elemente auf deiner Seite irgendwie Namen vergeben und dann macht er das so ein bisschen smarter. Okay, und da muss sich die gesamte Seite dann muss ich die gesamte Seitemit einem Element versehen, dass er weiß, hier auf dieser Seite soll eben eine View Transition angewendet werden. Also wie wird das gekennzeichnet, dass ich diese Funktionalität nutzen möchte? Das ist aktuell auf dem Dokument. Das ist eine Start View Transition und dem gibst du dann so ein Callback mit, wo du die Sachen änderst. Und du gibst den Elementen ID's, damit sie wissen, okay, hier war das vorher, jetzt ist es da und dann passiert da ganz viel Magic. Sieht sehr cool aus. Also so ein Beispiel ist irgendwie, man hat einfach eine Liste von Blogartikeln, wo dann schon Titel und ein Subtitel mit drin ist und dann klickt man da drauf und dann schwebt eben dieser Titel nach oben in diesem Blogartikel, anstatt dass es so snapt. Das sieht schon sehr cool aus. Also sie haben da auch sehr coole Beispiele. Genau, würde ich sagen, ist die größte Änderung, auch die spannendste für mich. Aber Sie bringen auch noch Sachen wie Image Optimization, das ist jetzt stabil, also Sie hatten das vorher schon, aber es ist jetzt eben überall verwendbar. Sie haben noch mal die Library, die Sie nutzen, gewechselt und es gibt wohl auch Synergien mit dem Image Server von VersaEll. Das heißt, wenn man den nutzt, macht er da viel automatisch. Viel mehr weiß er aber leider auch nicht. Ja, das reicht auch aus den Performance. Ja, Faster Rendering Performance einfach 30% schneller bei den meisten Komponenten. Google nimmt man immer gerne mit. Ssr Verbesserungen finde ich sehr spannend, vor allen Dingen was Serverless angeht. Und zwar konnten sie da auch in Verbindung mit Versnell so ein paar Dinge optimieren, und zwar, dass man pro Route Code Splitting machen kann, automatisch, dass du die Mittelware auf Edges packen kannst, auch sehr praktisch, und dass man die Hosts, also man hat ja verschiedene Serverless Hosts, und dass man da ein besseres Debugging machen kann, weil sie besseres Tooling anbieten, je nachdem, welchen Provider man nimmt. Und wenn. Die stark von Versel irgendwie gesponsert, wenn sie so viel mit Versel machen, wahrscheinlich ist es so. Das ist. Der Hauptsponsor. Ich meine, ich. Habe es gelesen. Ja, ja, ich weiß es nicht. Das einzige, was ich auch nicht weiß, ist, ob nicht auch wieder irgendein Hauptentwickler von Astrobay von Versal eingekauft wurde, weil die kaufen ja alle ein. Zumindest sind sie der offizielle Hosting Partner. Ich gehe jetzt mal davon aus, dass sie auch der Hauptsponsor sind. Gute Frage. Genau. Und für die React-Leute auch noch sehr erfreulich. Sie haben React Fast Refresh eingebaut. Das ist praktisch ein HMR Enhancement, das wirklich sehr, sehr snappi ist. Es gibt kein Page-Freeload und so Timer und so werden auch nicht resettet. Das funktioniert sehr, sehr gut, aber eben nur für JSS, also React oder Projekt. Ich glaube, zur Einordnung kann man das noch hinterher schieben, dass Astros so ein Web Framework ist, was sich auszeichnet dadurch, dass das Framework agrostisch eigentlich ist. Weil NaX ist ja Vue-basiert, NaX ist React-basiert und weiß ich nicht, was es da noch gibt, Wildkit oder so. Da ist ja alles mit dem Frontend verheiratet und Astros dann... Astros macht es mit jedem. Die neuen Sachen natürlich für Solid oder so unterstützen sie ja auch. Das ist natürlich sehr cool. Finde ich. Ja, ich mag Astrot. Weiß zwar nicht genau warum, aber ich mag es. Nutzen wir das schon irgendwo? Ja, aber noch nicht offiziell. Aber wir spielen damit schon rum. Das. Dashboard lief mal auf Astrot. Wieso lief? Das hat dann nicht funktioniert. Vielleicht nicht. So laut. Aber diese ketzerische. Frage ist nicht so gut. Man muss über Naxx haben, kann ich sagen. Das Dashboard läuft auf Naxx. Aber du hast auch noch ein Update zu einem anderen Framework. Ja, jetzt weiß ich auch noch nicht so genau, was das ist. Aber wir haben ja ein paar Mal schon über BANN geredet und hatten immer eine Null vorne. Und dieses Mal, ich glaube am 8. September, ist BANN 1.0 rausgekommen. Die Neuerungen da drin halten sich allerdings in Grenzen, würde ich sagen, oder sind nur im Detail zu entdecken. Was ich aber bemerkenswert fand, ist, dass dieser schillernde Mähntrainer, dieser Charret, wie auch immer er heißt, schon einen Monat oder zwei Monate vorher angekündigt hat, dass an dem Datum BANN 1.0 rauskommt. Was ich erst mal krass fand, dass jemand so ankündigt. Und dann hatten sie das tatsächlich mit einem Video-Event und alles wie so eine Keynote-Veranstaltung aufgezogen. Kam dann halt nicht an dem Abend raus, wegen Bugs. Kam zwei Tage später, aber ist auch egal. Nee, ich habe gelesen, es ist irgendwie Venture Capital-Bakt-Projekt und ja, also cool. Erst mal Bann ist halt eine JavaScript Runtime, die so ein bisschen gegen Node antritt, möchte aber noch ein bisschen mehr sein, also ein Bundler und ein Installer, also macht MPM und Node in einem und auch noch WebPack. Und wir haben ein sehr ambitioniertes Ziel. Die Kompatibilität zu Node ist noch nicht komplett da. Also viele Sachen, die man versucht zu replen, da hakt es noch an der einen oder anderen Stelle. Aber man hat performt technisch ist es großartig, wenn man einen Use Case hat, wo man einsetzen kann, sollte man das tun. Man interpretiert TypeScript out of the box, das heißt, da kann man sich das alles sparen. Es bundelt Sachen in Executables. Es gibt einen Docker Image. Ban-install ist das, NPM install, aber in schnell. Also viele coole Ideen. Und jetzt 1.0, Sie sagen selber ist Produktion ready. Habe ich vorsichtig noch ein bisschen, aber bald bestimmt. Aber wenn man es mal angespielt hat und so, glaube ich, möchte man nicht mehr zurück, wenn es funktioniert. Das heißt, du nutzt BAN auch schon vor allem auch als NPM ersetzt das auf jeden Fall, aber für Webseiten nur lokal und noch nicht. Ja, also als NPM ersatz auf jeden Fall. Da ist das kleine Sternchen, dass die Post Install Scripts noch nicht ausgeführt werden, zumindest nicht out of the box. Da muss man noch so eine Konfig Datei dazulegen. Das ist so ein bisschen ein kleiner Hussle. Und ansonsten zum Ausführen von unserem JavaScript Code oder TypeScript Code können wir es aktuell noch nicht verwenden, weil eben diese Node Kompatibilität noch nicht komplett gegeben ist. Jop, aber weiß ich nicht, sollte man mal ausprobieren. Die Internetseite ist auch glaube ich BANN. Sh. Fand ich interessant, dass es sh als Endung hat. Egal. Dann würde ich sagen, ich schrieb gerade noch eine Sache nach und zwar Node 206 ist rausgekommen vor, weiß nicht letzte Woche vorletzte Woche und da ist neu dazu gekommen, dass es jetzt eine Möglichkeit gibt. Env Dateien automatisch zu laden, dass ich also nicht mehr dieses. Env NPM Package installieren muss, sondern das kann Node jetzt out of the box. Das hat sich dann doch auch extra auf die Fahne geschrieben, dass sie das können. Und jetzt auch. Und da war auch ein kleiner, ach egal, also okay, mini, mini irgendwie so kleines Schlammützel auf Twitter zwischen dem, der für die Performance bei Node verantwortlich ist und Bann. Also zumindest gab es irgendwie Leute, die Bann 1.0 und dann so: „Eat that, irgendwie du Hunk von Node Performance Maintener und so und dann so: „Oh nein, wie könnt ihr nur und der macht das doch freiwillig und das ist alles ehrenamtlich und so. Also da ist es ein bisschen ein bisschen spacy. Wie das Internet halt so ist. Ja, es geht alles. Also ich meine, es ist natürlich was anderes, ob du ein Venture Capital-Bakt Projekt bist mit Vollzeitentwicklern, die sich den ganzen Tag nichts anderes sharen oder ob du halt ein Open Source-Maintener bist und da deine Freizeit reinsteckst. Und dann den irgendwie noch niederzumachen ist natürlich nicht die feine Englischsprache. Gerade weißt du, wenn du auf einer Plattform aufbauen musst oder erweitern die Performance, die halt so viel abbilden muss, wo ja noch gar nicht die volle Kompatibilität hergestellt wird. Da kann ja noch vieles irgendwie schlechter werden, wenn sie dann wirklich außer man den vollen Funktionsumfang vielleicht abdecken müssen. Und bei Node kannst du eben auch die ganzen Zöpfe nicht abschneiden. Das heißt du hast Abwärtskompatibilität Sachen noch und nöcher. Oh, apropos, 14 ist jetzt nicht mehr supportet. Und 14 ist end of life vorletzte Woche oder so. Oder war das 16? Oh mein Gott. Auf jeden Fall die Zeit vergeht. Ich glaube 14 ist schon länger weg. Ich glaube es war 16. Yes, dann haben wir noch Jackpack Compose Multiplattform. Genau, Jackpack Compose Multiplattform ist ja etwas, was ChatBrain irgendwie so in Eigenverantwortung entwickelt und basiert ja eigentlich auf ChatPack. Chatpack 1.5 wurde von Google bereits Anfang August vorgestellt und ChatBrain hat jetzt mit Compose Multiplattform einfach nachgezogen und ein bisschen Funktionalität immer erweitert. Was aber interessant an dieser Version ist, dass jetzt zum ersten Mal, also vorher war ChatPack Compose natürlich immer mit diesem großen Ziel eigentlich gestartet, wir möchten eigentlich auf allen Plattformen laufen. Vielleicht auch so ein bisschen, ich will nicht sagen Konkurrenz zu Flutter sein, aber zumindest gibt es natürlich so im Google Umfeld gefühlt zwei Ansätze, die das Gleiche möchten. Was auch auf der Flutter kommt, so ein bisschen Thema war, inwieweit sich da Google oder warum sich Google da mit diesen beiden Technologien dann irgendwiebeschäftigt und das unterstützt. Sie haben jetzt für Desktop-Applikationen, unterstützen Sie jetzt vollwertig, also Linux, Mac OS und Windows kann ich jetzt damit bauen. Ios ist jetzt ins Alpha-Stadium gekommen und Web Support gilt als Experimentell, aber man kann es zumindest ausprobieren. Bin ich sehr gespannt. Wäre auf jeden Fall etwas, was ich gerne mal ausprobieren würde, inwieweit das besser oder schlechter als Flutter Web ist. Ja, das ist so die große Neuerung, was Sie jetzt da eben erreicht haben. Sprechen natürlich auch davon, dass Sie jetzt auf jeden Fall schnell irgendwie stabilisieren wollen und da auch auf die anderen Plattformen gerade natürlich für iOS dort bald einen releasefähigen Kandidaten haben möchten. Was sonst noch passiert ist, dass jetzt eben Dialoge und Popups irgendwie direkt im Framework unterstützen. Vorher war es so gewesen, dass man dort immer Plattform spezifischen Code irgendwie schreiben musste, jetzt auf Android oder auf dem Desktop irgendwie dann Dialog oder Popup anzuzeigen. Das ist jetzt integriert. Es werden jetzt Windows Insets unterstützt, das heißt irgendwie Safe Areas, die ich einfach auf mobilen Geräten habe, die eigentlich dann System Komponenten vorgehalten sind, kann ich jetzt die direkt abfragen und entsprechend mein Layout damit versehen. Ja, vor allem waren wohl Verbesserungen für iOS im Fokus. Das heißt, sie haben hier die Ressourcenverarbeitung vereinfacht, Textverarbeitung unterstützt, die jetzt auch Bildraten bis zu 120 FPS. Vorher war wohl nur 60 FPS unterstützt, was manchmal irgendwie zu bisschen stottern geführt hat bei der Anwendung. Und sie haben wohl auch alle Compost Test APIs auf Desktop portiert, sodass man letztendlich auch irgendwie Desktop testen kann. Das war es. Cool. Danke dir. Und dann würde ich sagen, als Abschluss reden wir ein bisschen über den Aufschrei, der fast das Apple Event mit den iPhones überdeckt hat. Und zwar Unity hat sein Bezahlmodell ein bisschen angepasst, einen Euphamismus hier mal zu verwenden. Ein bisschen angepasst. Wie haben die das? Was haben die da? Sie haben es so dargestellt, dass es so ein bisschen angepasst ist. Die ganzen Entwickler, die darauf entwickelt haben, haben es ein bisschen anders aufgefasst. Ja, wenn man es dann mal durchrechnet, dann merkt man schon, dass es halt große Änderungen für die Bezahlung in vor allen Dingen einigen Szenarien mit einhergeht. Und was ist das genau, was sie da gerne haben? Sie nennen das Runtime Fee. Kannst du mir mal erklären, wie es vorher war? Weil ich weiß überhaupt nicht, wie Unity abgerechnet wird. Ich habe es so verstanden, dass sie vorher einfach einen Revenue Share hatten. Also einfach, wenn du Revenue hattest, dann hast du einen Teil davon abgegeben. Genau. So kannte ich das. Das ist natürlich auch eine Unity Ad Tendenz. Ich glaube auch, du hast natürlich gewisse Lizenzkosten, die du bezahlst, die sich ein bisschen nach der Größe irgendwie … Wie viele Installationen gibt es da draußen oder wie viele Entwickler hast du? Wie groß ist dein Unternehmen? Installation von dem Dev, also von dem Dev2. Ja, genau. Also zumindest hatten wir damals ja pro Seed. Irgendwie bezahlt. Und darüber hinaus noch Revenue. Also so eine Kombi aus. Den beiden. Also sie ändern auch nicht das Bezahlmodell, was du hast, wenn du die Software nutzen willst. Das bleibt gleich. Es geht rein darum, wenn jetzt Leute das Spiel spielen, wie kommt dann Geld? Also wenn du es vertreibst sozusagen. Und vorher war es eben Revenue Share. Das heißt, du hast einfach anteilig Geld abgegeben. Und was sie halt jetzt machen, ist, dass sie das basierend auf den Anzahl der Installationen machen. Ob ich damit Geld verdiene oder nicht? Nee, gar nicht. Ob Unity dafür Geld bekommt? Weißt. Du auch einfach? Also vorher war es ja so, ein Revenue Share ist ja so, ich verdiene mit dem Spiel auch Geld. Und wenn ich jetzt Unity Spiele verschenke und das installieren eine Million, muss ich trotzdem zahlen. Genau so ist es. Das sind auch so die Hauptproblematiken. Die blöd. Ja, weil du hast auch ganz oft irgendwie Charity Bundles, du hast Piracy Probleme, du hast vielleicht einen Subscription Service, wo du das gar nicht so dolle in der Hand hast, wie viel Geld du durch Installationen machst. Aber wenn du dann eben pro Installation zahlen musst, kann es sein, dass du halt Minusgeschäfte machst. Theorie. Theoretisch kann es sein und das ist so das Riesenproblem dabei. Ich glaube, gerade für kleine Indie Entwickler weißt du, die gerade eher solche Modelle nutzen, sagen okay, vielleicht ist das Spiel erst mal kostenlos, damit du halt eine Verbreitung über Stream bekommst. Für die rechnet sich das in vielen Fällen wohl gar nicht mehr. Also da gibt es ein paar Kandidaten, die gesagt haben, das würde für sie irgendwie 400.000 € mehr im Jahr Belastung oder Dollar mehr Belastung bedeuten. Und gerade als kleiner Indie Entwickler, der nicht sagt, ich muss erst mal eine gewisse Basis aufbauen und verdiene eigentlich mein Geld über irgendwelche Subscription Modelle oder ähnliches, ist es halt schwierig, das manchmal zu realisieren. Obwohl man da auch zu sagen muss, es gibt halt Threats, also du bezahlst nicht ab der ersten Installation, sondern es gibt je nachdem was für einen Wandel du hast von Unity, bezahlst du vielleicht erst nach den ersten 100.000 Instore und es gibt immer ein Install Threat und ein Revenue Threats. Das heißt, ich glaube, wenn du die Standardversion hast, sind es 1000 Instore und 200.000 Dollar Thresh-Feld im Jahr. Was heißt das? Ich muss 200.000 verdienen und dann muss ich erst. Zahlen für die Installation? Dann musst du erst zahlen. Bis dahin hast du das nicht. Das heißt, sie sagen, dass sie davon ausgehen, dass eh nur 10% der Unity Entwickler davon betroffen sind, diese Kosten bezahlen zu müssen, weil es eben diese Thresures gibt. Also deswegen, das wäre das Gegenargument gegen Indie Entwickler. Aber zumindest sagt die Community, es sind deutlich mehr als 10%, es wirkt zumindest so, als würden sich mehr davon betroffen. Zumindest das, was man auf Twitter mitbekommt, sind auf jeden Fall sehr viele, die davon betroffen sind. Aber du hast schon recht. Ja, stimmt, da gab es auf jeden Fall solche Mittel. Ich glaube, wo viele sich gegen hat, drüber aufregen, das hat jahrelang eine relativ offene Preispolitik oder Lizenzpolitik eben gehabt, dass man sagt irgendwie auch mit diesen Free oder es gab ja diese kleinste Lizenz, die es gab, wo du gar nichts zahlen musstest. Und dass man halt so drauf irgendwie sehr viel darauf basiert hat, ein ganzes Ökosystem, halt die meisten Entwickler sich genau aus dem Grund dafür zu entschieden haben, dass gesagt, das ist einfach eine faire Verteilung. Und dass jetzt auf einmal sozusagen diese, diese Änderung kommt, wo alle Entwicklerstudios, die sich darauf so fokussiert und committed haben, sagen: „Ja, hätten wir das früher gewusst, hätten wir es vielleicht anders entschieden. Es gibt ja mit Goddard eine Alternative, die da ein bisschen aufstrebend ist und hätten wir vielleicht früher da mehr investiert und was anderes gemacht oder versucht, irgendwie andere Ansätze zu finden. Dass das halt so ohne Ankündigung plötzlich kommt, ist, glaube ich, auch wie ein Dorn im Auge. Gab es zumindest, meine ich, irgendwie ein offizielles Statement, das Sie zurückrudernirgendwie? Sie versuchen ein paar Kritikpunkte ein bisschen anzupassen. Sie sagen zum Beispiel, dass man Demos hochladen darf und die dann noch nicht zählen, so als in Storys. Aber sobald irgendwie eigentlich das ganze Spiel mit drin ist und es nur so ein Early Access ist oder so, musst du auch doch bezahlen. Also sie versuchen so ein paar der Pain Points darauf einzugehen, die zu fixen. Aber es wirkte für mich jetzt nicht so, als würden sie generell dieses Pricing Modell wieder abschaffen wollen. Zumindest noch nicht. Mal gucken. Weil es gibt auch schon 16 Studios, die so einen boykott fahren und sagen okay, wir schalten jetzt keine Werbung mehr, damit Unity auch da kein Geld mehr bekommt. Einfach sie irgendwie dazu zu bringen, dass sie wieder rückgängig zu. Machenstimmt, das habe ich auch gelesen. Unity boykott. Na gut. Ja, ein anderer Service, der auch jetzt gerade bald vielleicht ein bisschen Kosten leidet. Eben als TwitterX hat ja auch angekündigt, dass jetzt User bald zahlen werden. Also es wird Zeit, dass wir unseren programmierbar Master to Master umfragen, eine Alternative zu bieten. Ich dachte, dass wir jetzt unsere Podcastfolgen verkaufen. Oh Gott. Nee, nee, also uns kann man nach wie vor hören auf den einschlägig bekannten Podcasts, Providern, Spotify, Apple Podcasts und vielleicht sogar auf unserer Website. Und ansonsten ja, würde ich mal uns ein Welcome back wünschen. So nach der Sommerpause. Und wenn ihr Feedback habt, schreibt uns gerne. Und ansonsten wünsche ich eine schöne Woche. Also bis dann. Tschüss. Ciao. Ciao. Macht's gut.