Deep Dive 199 –

Headless Apps mit Marcel Koch

20.01.2026

// Podcast
// Deep Dive 199

Shownotes

In dieser Folge blicken wir über den Tellerrand klassischer Cross-Platform-Frameworks hinaus. Gemeinsam mit Marcel Koch, Softwareberater, Coach und Rust-Autor, besprechen wir das Konzept der Headless Apps.

Wir diskutieren, wie sich die komplette Anwendungslogik in Rust kapseln lässt, um sie plattformübergreifend einzusetzen – unabhängig davon, ob die UI mit Flutter, SwiftUI oder Jetpack Compose umgesetzt wird. Auch der Einsatz im Web über WebAssembly (WASM) sowie auf Mikrocontrollern spielt dabei eine Rolle. Im Mittelpunkt steht die Frage, wie Headless Apps als Architektur funktionieren und welche Vorteile die klare Trennung von Core-Logik und UI-Layer mit sich bringen kann.

Ein weiterer Schwerpunkt ist die Wahl von Rust als Kerntechnologie. Wir sprechen darüber, welche Rolle Performance, Memory Safety und Portabilität für diesen Ansatz spielen und warum sich Rust besonders für langlebige Software eignet. Außerdem werfen wir einen Blick auf das Crux-Framework von Red Badger, das den Datenaustausch zwischen dem Rust-Core und den jeweiligen UI-Shells strukturiert.

Zum Abschluss machen wir einen Realitätscheck: Wann lohnt sich der zusätzliche Aufwand einer Headless-Architektur tatsächlich und in welchen Fällen ist man mit etablierten Lösungen wie Flutter oder Kotlin Multiplatform besser beraten?

Download

/transkript/programmierbar/deep-dive-199-headless-apps-mit-marcel-koch

Dennis: Hallo und herzlich willkommen zu einem neuen Deep Dive der programmier.bar. Wir sprechen heute über Headless Apps. Ich bin Dennis Becker und zusammen mit mir im Studio ist
Jojo: Der Jojo.
Dennis: Wir haben heute einen Gast bei uns, der ein Buch über Rust mitgeschrieben hat, seit vielen Jahren Cross Plattform Entwicklung macht mit Tab Street, Rustflatter, Java, vielen Programmen Coach für gewaltfreie Kommunikation ist und auch nicht das erste Mal bei der programmier.bar ist und über dieses Thema tatsächlich auch schon in Meet-up bei uns gehalten hat. Marcel Koch, herzlich willkommen in der Programmierbahn.
Marcel: Vielen Dank, freut mich, wieder hier zu sein.
Dennis: Marcel, schön auch, dass Du vor Ort gekommen bist und wir die Möglichkeit haben, hier in Person mit dir zu sprechen und gemeinsam hier zu sitzen. Es ist zwischen den Garnen, bisschen besinnlich. Vermutlich, wenn die Folge rauskommt, seid ihr schon hoffentlich gut in das neue Jahr 2026 gestartet. Wir sprechen heute ja über Headless Apps, in Klammern in Rust oder tatsächlich Headless Apps. Wo würdest Du den Fokus setzen?
Marcel: Gute Frage. Ich glaube, beides ist wichtig. Wenn man mich fragt, ist es natürlich die Richtung Headless Apps in Rust. Warum? Weil sich Rust einfach sehr gut dazu eignet. Ich würde aber nicht so weit gehen, zu sagen, man kann das nur, auf jeden Fall nur in Rust machen, weil der Ansatz, Headless Apps zu gestalten, doch wenn sie denn langfristig angelegt sind, eine gute Idee ist und das muss nicht unbedingt in Rust verbunden sein. Ich würde es aber immer wieder in Rust machen.
Jojo: Mhm.
Dennis: Cool. Genau und dann haben wir ja Julia noch heute hier im Studio, der Langzeit mit Flirt entwickelt hat und sich auch mit vielen Cross Plattform Tools auseinandergesetzt hat, von daher mit Sicherheit auch die ein oder andere spannende Frage dabei hat, aber lasst uns mal beginnen mit der Definition, was denn überhaupt eigentlich eine Headless App ist. Als kleine Definition könnte man sagen, wir trennen, wie
Marcel: ich gerne sage, die dünne Tapete von der dicken Wand. Die dicke Wand ist die Businesslogik, alles, was über längere Zeit Bestand hat. Ich meine, eine gewisse Businesslogik wird sich nicht ändern. Ich hab beispielsweise Kunden, die in der Messtechnik tätig sind. Die Messtechnik wird sich nicht ändern, DUI ändert sich. Und wie ich's gerne sage, ich nehm, ich mach die dicke Wand in Rust und die dünne Tapete, die noch oben drauf kommt, DUI, in welcher Technologie auch immer, wir setzen übrigens auch Flatter ein unter anderem.
Dennis: Mhm.
Marcel: Die kommt dann zusätzlich darauf und die App ist eben die Mauer. Da ist alles drin, was Bestand hat, was was langfristig dableiben soll und die Tapete kann man immer mal wieder wechseln. Habt ihr vielleicht auch schon mal gemacht. Ich, bei mir ist das 'n bisschen her mit der Tapetenwechsel. Aber ja. Also In der Technologie hab ich das schon gemacht.
Jojo: Ja. Der Begriff bezieht sich einfach darauf, dass man halt, wie wär's bei 'nem Browser, wo man keine visuelle Ausgabe hat, eigentlich sagt man baut eine App, die hat letztendlich eine gewisse Funktionalität kapselt, aber ohne letztendlich den Teil mit zu inkludieren, der halt die Anzeige übernimmt.
Marcel: Richtig. Also was auch, was ich auch gerne mit mir trage, ist der Begriff 1 Cross Plattform Domain Cors. Mhm. Das ist son bisschen sperrig. Mhm. Also ich hab auch noch so keinen keinen richtig guten Begriff gefunden, der kurz und gut erklärend ist, aber das ist ja das das große Ding. Da sind wir wieder schon fast bei der Kommunikation. Aber letzten Endes geht es darum, dass dass man sagt, man hat einen bestimmten Kern, den man besonders robust gestaltet und den man überall wieder verwenden kann. Und das Schöne ist ja auch, dass man das nicht nur bei mobilen Applikationen machen kann, sondern man kann den Kern auch im im Browser verwenden. Man kann den Kern auch auf den Desktopsystemen verwenden. Also es geht nicht nur mobile Applikationen, wo er meistens oder vielleicht auch noch die Desktopapplikationen davon spricht, dass man Cross Plattformen macht, sondern das geht darüber hinaus. Und bei ist es sogar so, dass Du dann sagen kannst, okay, ich hab bestimmte Logik, die möchte ich auch auf dem Mikrocontroller laufen lassen. Also das ist das das Schöne und auch, Dennis, zu deiner Frage noch mal noch mal auf deine Frage zurückzukommen, Da ist es so, dass Du mit Rust einfach sehr flexibel und trotzdem robust fahren kannst, was natürlich nicht nur vor, sondern auch Nachteile hat. Nur einen Nachteil zu nennen, es ist eben eine steile Lernkurve, wenn man erst mal in Rust reinzukommen. Und da ist auch genau der Knackpunkt, das Zünglein an der Waage. Die die Frage, die man sich eben immer stellen muss, ist, wie lange und wie robust soll denn dieser Kern leben? Und ich sag gerne, wenn ich auf Konferenzen spreche, wir haben jetzt hier eine Konferenzen App, die würde ich beispielsweise nicht mit diesem Ansatz bauen, weil das macht man vielleicht für 3 Wochen.
Jojo: Mhm.
Marcel: Und dann ist das auch wieder wieder, ja, hinfällig. Ja. Und bei mir sind Kunden eben mehrfach zu mir gekommen und haben gesagt, ich zitiere einen, der gesagt hat, ich möchte, dass das, was wir jetzt angehen, dass das am besten auch noch in 30 Jahren trägt. Ist natürlich eine Riesenanforderung. Keiner von uns weiß, wie das wie das funktionieren soll. Und wir können auch gerne jetzt irgendwie uns die wir die die Karten legen, in die Kristallkugel gucken, ob tatsächlich Ruster noch da ist. Ich hab gestern ein 'n Mitarbeiter von mir gefragt, na, was glaubst Du denn? Glaubst Du, Spotify stirbt früher oder, einfach so ausm Kontext raus, Spotify stirbt früher oder flatter? Weil wir wollen immer wieder darüber sprechen, weil ich natürlich auch immer diese diese Argumentationskette aufzeige. Und er sagte dann, ja, benutzt aber auch kein Spotify. Ich glaube, Spotify stirbt früher. Ich glaub das anders und das ist immer eine Sache, da muss man natürlich dann schauen, woran glaubt man, ne.
Jojo: Mhm.
Marcel: Aber grundsätzlich kann man sagen, wenn man diesen Aufwand treibt, dann muss es sich das natürlich auch irgendwie rentieren.
Jojo: Mhm.
Marcel: Und in in den in den meisten Fällen, also die meisten Fälle, die wir abdecken, machen das nicht nur, wir machen das viel. Lohnt es sich eben, zumindest Stand heute, wir gucken mal, wie's in 30 Jahren aussieht, dass wir sagen, wir haben einen bestimmten Chor, den wir besonders robust haben wollen. Wir wollen ihn auch flexibel haben, weil wir beispielsweise sagen können, wenn wir als Tapete nicht mehr haben wollen oder das nicht mehr geht oder wie auch immer oder die Performance passt nicht mehr, dann sagen wir, dann binden wir einfach unseren Core in native Technologie ein. Wenn ich mir beispielsweise Windows anschaue, da gibt's ja dann verschiedene Arten. Inzwischen sind wir, glaub ich, bei Win UI 3 heißt das. Und wenn sich dann was Neues ergibt, kein Problem, unser Chor bleibt bestehen. Das ist so, wie wenn man sone C-Bibliothek hat, die kann man immer noch 'n bisschen mitschleifen, so ist hier grundsätzlich die Idee, dass man das aufteilt. Und da gehören natürlich 'n paar andere Sachen noch dazu im Detail.
Jojo: Mhm.
Marcel: Aber das ist erst mal die grundsätzliche Idee,
Jojo: dass
Marcel: man sagt, okay, was ist denn eine Headless App? Und die Headless App geht geht darum, dass man einen Chor definiert, den man, und sonst würde ich jetzt vorgreifen, ich schließ jetzt erst mal ab, Mhm. Den man so gut und robust und dabei trotzdem noch flexibel definiert.
Jojo: Mhm.
Dennis: Auch wenn die Frage vielleicht 'n bisschen ist, aber und Du mit Sicherheit deinen Kunden auch zufriedenstellen wolltest an der Stelle, behält es grundsätzlich überhaupt eine vernünftige Anforderung zu sagen, dass eine Software über 30 Jahre existieren soll?
Marcel: Ist ja Fangfrage,
Jojo: ne? Definitiv weißt Du. Ich glaub, ich kommt immer dran, was was Du anbinden möchtest, grade wenn Du halt irgendwelche Sensorsysteme hast, wo Du sagst, ja, das ist ein Produkt, was über Jahrzehnte vielleicht irgendwie so in dieser Form bestehen bleibt. Ich möchte dafür letztendlich einen einen Kern haben, mit dem ich letztendlich das binäre Protokoll letztendlich dieses Sensors verstehen will, kann man, glaub ich, schon von diesen Zeithorizont sprechen.
Dennis: Was denkst Du denn, wie viele Softwareprojekte haben wir noch, die jetzt 30 Jahre alt sind?
Marcel: Ich glaube, viele von denen sehen wir gar nicht. Ja. Ich glaube, viele sind da auch mehr so im b-two-b-Umfeld eingeordnet, verwoben, weil Du dann hingehst und sagst, wie wie wie viele Leute benutzen Software? Ich mein, wir brauchen noch mal mit Kobol anfangen. So von wegen das Ding, was seit Also ich hab 2000, was war das, 4008 bis 2011 war ich mal bei 1 deutschen Großbank und damals hat man gesagt, wir wollen das schon seit 30 Jahren ablösen. Und das längste Provisorium, das kennt man ja. Und es gibt einfach bestimmte Dinge, die schleichen sich dann ein und die werden von ihrer, wie soll ich das mal sagen, von ihrem Naturell grundsätzlich länger bestehen bleiben, ob uns das lieb ist oder nicht. Und wenn es schon sowieso so ist und wenn wir beispielsweise, wenn wir wieder in die Vermessungstechnik gehen. Es gibt halt bestimmte Dinge, die ändern sich nicht und es wäre gut, man könnte es immer noch weiter pflegen. Der der Kunde, von dem ich jetzt auch spreche, hat aktuell viele Implementierungen in Delphi. Und er ist auch zufrieden mit Delphi, nur erfüllen da keine Leute, die sich damit auseinandersetzen. Die Community stirbt aus, weil der Hersteller oder der die Firma dahinter, Emba Cadero, wenn ich das richtig wiedergebe, dann irgendwo mal gesagt hat, wir machen, wir geben keine Campus Lizenzen an Unis mehr raus, sondern die kosten jetzt 25000 Euro. So. Worauf will ich hinaus? Das hat weiter Bestand. Er würde es auch gerne weiter pflegen, aber es funktioniert nicht und deswegen ist die Frage, wenn's sowieso Bestand hat, was kann man sich überlegen? Worauf setze ich, damit das besonders Bestand hat, trotzdem in Zukunft auch flexibel zu sein. Natürlich kann man auch das Argument dann reinziehen, bei dem man dann sagt, na ja, komm, selbst wenn Du's jetzt implementiert hast, Du wirst auch in 30 Jahren irgendwas ändern. Was werden wir in 30 Jahren noch mal angucken? Aber so, wie man den Code dann aufbauen kann, bin ich schon der Ansicht, dass dass man es durch wenig Wartungsaufwand so hinbekommt, dass dass man den auch in 30 Jahren noch noch verwenden kann und als letzten Abschluss. Mein Mitarbeiter hat dann auch gesagt, ich glaube, dass es in 30 Jahren auch noch flatter geben wird und und Spotify vielleicht auch noch und so, deswegen schauen wir mal so. Er hatte gestern auch gesagt, na ja, ich trau auch Google zu, dass er das einfach mal abschneiden. So, werden wir ja unterm Alles sehen. Man könnte es natürlich auch noch in in c implementieren, das wird wahrscheinlich gar nicht mehr weggehen, schauen wir mal. Aber erst mal so ist die grundsätzliche Idee, es gibt eine Anforderung, die ist also da. Es müssen die auch nicht 30 Jahre sein, es können auch nur 5 Jahre 5 Jahre sein und da gibt's wieder eine neue UI Technologie. Wir sind aber trotzdem immer noch dabei, das flexibel gestalten zu können.
Jojo: Ich glaub, weißt Du, das würd ich nämlich auch so so sehen, dass man sagt, das ist vielleicht nicht nur der Zeithorizont, in dem man dann eine einen gemeinsamen Kern irgendwie nutzen möchte, sondern auch, dass man wirklich sagt, das, was jetzt andere Crossplattform Frameworks eigentlich bieten, ich möchte das auf verschiedenen Gerätefamilien eigentlich betreiben können, diese Applikation. Und da vielleicht immer wirklich eine spezifische UI für die Plattform bauen, aber einen gemeinsamen Kern haben, wo halt dann die geteilte Logik drin lebt, dann kann man natürlich auf solche grundsätzlichen Ansätze natürlich dann auch zurückgreifen und sagt, okay, damit hab ich letztendlich nicht vielleicht diese Einschränkungen, die jetzt Flatter mitbringen würde. Es läuft dann auf eben den spezifischen Geräten, für die dann diese oder halt visuelle Integration letztendlich geschaffen wurde, sondern ich hab letztendlich einen einen Kern, den ich auch wirklich weiterverteilt. Wir haben das auch schon für verschiedene Spiele gemacht, dass wir gesagt haben, okay, wir haben damals immer noch dediziert für iOS und Android entwickelt, hatten aber sozusagen auch die Gamelogik, die wir nicht sozusagen auf beiden Plattformen eben dediziert entwickeln wollten. Und da haben wir eben c genutzt, weil wir natürlich wussten, okay, das ist unsere Zielplattform. Wir können letztendlich c oder c plus plus als gemeinsame Basis nehmen und haben eigentlich ja eigentlich wie die Konzepte, die die wir heute noch besprechen wollen, gesagt, okay, es gibt einfach gewitter Schnittstellen, gibt son Mechanismus, wie man halt eben mit dieser nativen Ebene kommuniziert. Wir haben aber die gesamte zentrale Gamelogik des Spiels eigentlich in diesem gescherten Teil und greifen dann eigentlich nur, sagen wir mal, aus der UI von den entsprechenden Plattformschichten dann eben darauf zu. Also dafür halt ich's auch relevant. Und ja, ich glaub, es ist immer auch gut zu sagen, wenn man letztendlich sone Kapselung vornimmt, dann hat man natürlich eine sehr klare Organisationsstrukturen und sich sehr gut Gedanken dazu gemacht, wie schafft man letztendlich diese Kapselung? Und ich glaub, das kann auch grundsätzlich helfen, zu sagen, wie einfach kann ich diesen Code dann vielleicht auch irgendwie portieren? Weil grade natürlich jetzt im Zeitalter der Eye könnte man natürlich auch sagen, sone Kernfunktionität von 1 Sprache jetzt auf was Neues zu übersetzen, wenn die Schnittstellen darüber recht klar sind, ist natürlich auch mit der AI sehr, sehr sehr, sehr einfach möglich. Aber ja, es ist dann vielleicht nicht in der gleichen Qualität, wie ich's vorher schon mal implementiert hatte, mit der gleichen Absicherung, Validierung und Ähnlichem, die ich dann zur Verfügung habe.
Marcel: AI Argumentation auch eine gute ist, dass man sagen kann, ja komm, jetzt machste hier 'n Riesenbohei und dann frag ich in 2 Jahren die AI und die schreibt mir das, was Du vielleicht
Jojo: in
Marcel: welcher Sprache auch immer geschrieben hast, in eine andere neu.
Jojo: Mhm.
Marcel: Aber ich glaube zum, also man kann ja immer nur mit mit dem arbeiten, was was momentan ist. Mhm. Und wir machen das jetzt auch schon 'n paar Jahre. Und da war das mit dem und AI noch nicht so weit.
Jojo: Mhm.
Marcel: Und außerdem würde ich sagen, dass dass Rust durch die Syntax, durch die Robustheit, durch was das ganze Ökosystem von Rust mitbringt, auch eine gute Idee ist. Natürlich bin ich jetzt davon überzeugt. Ich ich hab jetzt kürzlich mit mit jemanden gesprochen. Wir haben auch bei uns angefragt, das sind Kollegen von von 'nem Produkt, der das nennt sich Zeitkapsel, die machen auch Cross Plattform Entwicklung und sie haben bestimmte Implementierungen in Go und wollen dann auf Rust wechseln aus verschiedenen Gründen. Grüße gehen raus. Und da ist es beispielsweise so, dass sie einfach die Idee von diesem Chor auch schon hatten und dann mit 1 Sprache auch Erfahrung gesammelt haben, was sie so jetzt nicht mehr machen würden. Mhm. Da können wir auch gerne noch später drauf eingehen. Und es ist vielleicht aber auch so, dass man sagen kann, ich muss das gar nicht langfristig unbedingt betrachten, ich würde es immer tun, aber man wie wie in 'nem gestrigen Gespräch auch aufkam, vielleicht hat jemand einfach Bock darauf, das in in Rust zu entwickeln und sagt, das ist einfach so robust und da würde ich auch immer hinterhergehen, es gibt kaum eine eine oder eine Software kann in kaum so robuster Art und Weise geschrieben werden wie 'n Rust Mit den ganzen Vorteilen, mit dem dem Borro Checker, mit den ganzen Konzepten können wir auch gerne noch drauf eingehen, aber es soll jetzt ja nicht nur die Sprache gehen.
Jojo: Mhm.
Marcel: Dass man einfach sagt, nee, das das ist einfach nur wunderbare Möglichkeit, mein Zeug in die Welt herauszubringen und auch testbar zu haben. Das auch noch 'n Aspekt, den wir noch nicht genannt haben, denn indem Du hingehst, gehen wir mal weg von Rust, aber indem Du sagst, Du hast einen bestimmten Kern, den Du in Schnittstellen so designst, dass Du sie wunderbar testen kannst. Was wir tun, ist, wir machen das eventbasiert, also dass wir sowohl Events definieren, die eine gute Idee sind, sie an die UI anzudocken. Also ich sage, ein Beispiel könnte sein, ich hab einen Versicherungsrechner, implementier mir so nicht, aber kann man gut greifen. Und dann gibt's eine bestimmte, einen bestimmten Button, da steht drauf, ich berechne jetzt die Police. Und da mache ich genau ein Event, das genau an diesem Button dran geflanscht werden kann. Kein großes Ding, also die die Tapete hab ich wirklich auch deswegen als Metapher gewählt, weil sie so dünn sein soll wie möglich. Mhm. Dass ich wirklich alles vorbereitet habe und nur das, was absolut nötig ist, kommt noch innerhalb von von der Tapete und das flansch ich dann dementsprechend dran und ich kann wunderbar ohne bestimmte UI Integrationen, ohne UI Tests kann ich meine Logik testen und auch mit der Aktion. Also ich hab bestimmte Events, die ich dann die ich dann triggere. Ich hab bestimmte Abfolgen von Events, die ich triggere. Ich kann das wunderbar zusammen orchestrieren und kann das dementsprechend auch testen. Und so hab ich nicht nur den Vorteil jetzt in Bezug auf Rust und die die Programmiersprache, sondern ich habe auch den Vorteil, dass ich hingehe und eine gewisse Struktur auch habe, die ich auch gut wiederverwenden kann, unabhängig davon, was ich denn da so verwende.
Dennis: Eine noch grundsätzliche Frage, die dich am hätte, Du, also ich meine in deiner Metapher ist die Wand sehr dünn, wenn Du jetzt sagst
Marcel: Die Tapete ist. Die Tapete.
Dennis: Die Wand dicker und dass sie sich für vielleicht eine Konferenz ab, die 'n paar Wochen überlebt, nicht so rentiert. Wenn Du dir jetzt so den Best Case für diese Architektur vorstellst und dann sagst, okay, wie viel Aufwand der Entwicklung steckt in der Mauer und wie viel Aufwand der Entwicklung steckt in der Tapete? Wo würdest Du da die Prozentzahlen hinhängen? Also, weil in meiner in meiner Vorstellung ist App Entwicklung oder ne, also er hat schon 'n relativ großen Part auch UI immer dabei. Und daher die Frage, wie viel kann man, wenn man das drauf anlegt, sozusagen in in die Mauer packen?
Marcel: Ist eine bisschen fiese Frage, finde ich. Und deswegen antworte ich auch mit der klassischen Beraterantwort, das kommt drauf an. Ja. Also es ist es ist ja, also wenn wir uns mal die Apps angucken, würden die wir so tun, dann ist das auch, ein Wort zu bedienen, was was seltsam wirkt, aber was es, glaube ich, ganz gut beschreibt, dann ist das Engineering schick. Also das ist nicht etwas, was man als hoch poliert bezeichnen könnte, sondern das ist eher so funktional, was was wir hauptsächlich tun. Also das ist jetzt nicht so was, wo Du sagst, oh, das ist das kommt jetzt gewinnt jetzt den Apple Design Award
Jojo: und
Marcel: deswegen ist das total schwer zu beantworten, ganz allgemein. Es ist feel UI bestimmt, aber ich kann das nicht allgemein, also wie Du es jetzt gesagt hast und so, wird das bei euch bestimmt auch sein, ich kann das nur allgemein nicht unterschreiben, weil je nachdem, was Du halt machst, also wenn wir beispielsweise auch Hardware anbinden, wenn wir Motorsteuerung machen würden et cetera, so was, ne. Dann ist das eine ganz andere Kiste und dann gehst Du dann hin und sagst, okay, mach das jetzt, drück drauf und dann fährt der Motor los und et cetera. Das das ist halt total schwierig.
Dennis: Aber deswegen, weil also habe ich die Frage auch so formuliert, praktisch den Best Case dafür, wenn Du sagen würdest, ne? Also nicht zu sagen oder 'n bisschen als Hörer oder Hörerin auch einschätzen zu können, okay, für welche Use Cases ist denn sinnvoll und wo macht es denn keinen Sinn, da son bisschen
Marcel: Also da, da noch mal reinzucätzchen, wenn wir das jetzt machen würden, wäre für uns das absolut natürlich. Wir kennen das so, wir sind das total gewohnt. Das läuft bei uns einfach. Wenn jemand das erste Mal hingeht und sagt, ich fang jetzt mit Flatter an, dann ist das auch eine eine eine andere Kiste und deswegen fällt's mir total schwer, das das zu beantworten. Ich versuche es jetzt aber mal trotzdem, weil ich deine Frage gerne beantworten möchte, zu zu übertragen und da ist es tatsächlich so, dass wir ein ein Aufwand haben so von 70 30. 70 Chor, 30 Tapete. Mhm. Das kann anders sein.
Dennis: Ja klar.
Jojo: Ja.
Marcel: Aber es ist tatsächlich so, dass wir mehr uns dann darum kümmern, auch wenn wir dann sagen, wir haben diese Anforderung, dass das so lange existieren soll, wie strukturieren wir den Code? Wie testen wir das dementsprechend ab? Wie sorgen wir da, dass dass die Matte, die wir auch implementieren, gut funktioniert et cetera? Das kann aber auch anders sein. Ja. Und das ist, wir haben jetzt auch eine App, da wird der Benutzer dazu aufgefordert, bestimmte Dinge zu malen. Also tatsächlich hab ich verschiedene Farben. Bisschen kompliziert das das jetzt zu erklären, aber das ist auch so, dass wir sehr viel im Chor machen, weil wir uns auch dafür entschieden haben, auch die Geschichte mit dem mit dem Malen und dem Rendering und alles, das machen wir alles innerhalb von Rust.
Jojo: Mhm.
Marcel: Und wir binden das der in dem Fall auch wieder in in Flatter ein und Flatter sagt dann, ja, ich brauch das, brauch die Bilddaten, gib mal. Mhm, okay, ich ränder die. Okay, ich hab hier meinen meinen, heißt er, so viel ich weiß. Mhm. Und der sieht, okay, Du hast jetzt gerade die die Maus, den Finger et cetera drüber bewegt, schick das auch wieder in in den Chor dementsprechend rein, damit wir auch in der Lage sind, das beispielsweise über Work Basamply in den Browser noch abbilden zu können. Deswegen konzentrieren wir uns auch darauf, also auch beispielsweise Internationalisierung. Ihr i18N machen wir auch innerhalb vom Chor. Dieses Ding bringt dann alles mit, Batteraries included sozusagen, was Du brauchst, die Tapete dagegen zu klatschen. Ich glaub, das Klatschen hat man jetzt auch gehört im im
Dennis: Vielleicht filtert's ja eher heraus.
Jojo: Ja, ich glaub, was eben gerade auch Marcel schon gesagt, es kommt halt sehr stark auf die Applikation an. Und ich glaube grad, weißt Du, wenn Du solche klassischen und nicht halt so aufpolierte Apps hast, kommst Du vielleicht mit diesen Verhältnissen an. Ich glaub, bei unseren Spielen ist es genau das Umgedrehte. Wir haben eher sozusagen 70 Prozent UI mit allen Animationen, was außen rum passiert, irgendwie Buttons. Und dann ist sozusagen Chor, obwohl es auch bei 'nem Spiel natürlich eine zentrale und wesentliche Bestandteil der App ist, ist vielleicht diese 30 Prozent, die man natürlich auch sehr gut eben teilen kann. Aber sonst sind's dann eher so, okay, diese Teile sind dann vielleicht so komplex, dass wir sie halt nicht zweimal implementieren wollen, wenn wir wirklich an unterschiedlichen Sprachen sind, sondern wir wollen eine einheitliche Lösung haben, wo's sich dann auch wieder lohnt, halt so einen geteilten Chor in irgendeiner Form dann vorzuhalten. Ich
Marcel: würde gerne noch mal die Frage stellen, was vorhin gesagt hat, dass ihr das in c implementiert habt, ein Chor, den ihr mit verschiedenen Das hat
Jojo: c plus plus ja.
Marcel: C plus plus. Habt ihr den noch? Benutzt ihr den noch?
Jojo: Ja, das Spiel gibt es auch nicht mehr. Das war Okay. Leiderex Momente Spiel, aber ja. Er ist auf jeden Fall liegt er eben im Repo, aber wird nicht mehr aktiv genutzt.
Marcel: Weil weil
Jojo: das Und auch bei verschiedenen Spielen. Also es war bei 2, 3 Spielen, dass wir werden, die sind alle sozusagen nicht mehr aktuell in den Stores verfügbar.
Dennis: Das waren vor allen Dingen so Generatoren und so was, oder?
Jojo: Ja genau, vor allem also genau so Generatoren für Level halt einfach, die halt sone komplexere Logik haben, wo wir gedacht, wir wollen halt im Eimer letztendlich diesen Aufwand betreiben, uns darüber Gedanken zu machen, wie das funktioniert. Und damals musste man alles sozusagen parallel implementieren und konnte das nicht eine Ei übersetzen lassen. Ich hatte grad die Situation, dass ich einen MVP erst mal in Flatter entwickelt habe und den jetzt sozusagen in eine andere Technologie überführe. Und da hat das natürlich wunderbar geklappt zu sagen, hey, die ganze Core Logik, die ich jetzt geschrieben habe, übersetzt mir das mal zu c-sharf und konnte natürlich supergut machen. Aber ja, das ist vielleicht das, was heutzutage möglich ist. Und auch mit diesem Ansatz, hey, ich möchte erst mal schnelles Prototyp nicht haben, wo Du ja schon gesagt hast, also dafür ist es natürlich nicht geeignet, wenn man sagt, man möchte eigentlich nur etwas ausprobieren und etwas nicht für die für die Ewigkeit schaffen, dann gibt es vielleicht irgendwie dort bessere Ansätze, als dann wirklich so einen ja, diesen Aufwand zu betreiben, letztendlich diesen Chor zu definieren, die Schnitzeln zu definieren, die Schnittstellen zu definieren, die unterschiedlichen Plattformen eben an der Stelle anzuschließen.
Marcel: Ist auch
Dennis: Wobei Du wahrscheinlich argumentieren würdest, dass es für euch kein großer Mehrwert, mehr Aufwand ist so richtig?
Marcel: Würde ich so sagen, ja. Ich würd's aber auch nicht so machen. Also wenn man wirklich sagen würde, hallo, macht doch bitte mal eine eine Konferenz App, dann würde ich auch sagen, ich glaub nicht, dass das dass das sone sinnvolle Geschichte ist, weil man hat natürlich auch 'n bisschen Infrastruktur noch mit drin. Man muss das integrieren. Dann muss man gucken, dass das alles so gebaut werden kann zusammen et cetera. Aber die die Frage, die mir auch noch aufgekommen ist, hast Du im Prinzip auch schon beantwortet mit, habt standet ihr schon mal vor der der Frage, ja, machen wir's jetzt in Flatter oder machen wir's jetzt nativ? Mhm. Also dass man wirklich vor der Frage steht, welche UI Technologie nehme ich denn? Und da wird man dann auch, und so hab ich dich jetzt verstanden, das das machst Du grade, wird man auch dadurch 'n Stück weit flexibler, weil man sagen kann, okay, ich hab jetzt das in meiner meiner Struktur und wie gesagt, das muss ja auch nicht in in Rust sein, auch wenn sich das aus meiner aus meiner Sicht sehr gut eignet. Dass ich sagen kann, okay, ich hab das so organisiert und ich wir probieren das jetzt in beispielsweise Flatter.
Jojo: Mhm. Und wenn
Marcel: das nicht funktioniert von von der Performance her, dann machen wir das wieder nativ. Und das kann's ja dann wunderbar integrieren.
Jojo: Mhm. Was Du son bisschen angesprochen hast, was mir interessieren würde, dass Du sagst, okay, man braucht dann auch sone gewisse Struktur. Also grad, wenn man sich's das irgendwie so vorstellt und Du hast das vorhin schon 'n bisschen angesprochen. Und ich fänd's interessant, da bisschen tiefer einzugehen, wie halt wirklich dann so das System die Informationen von außen bekommt, intern verarbeitet und wieder nach außen gibt. Also Du hast vorhin zum Beispiel schon Events angesprochen. Mhm. Wenn da mal 'n bisschen drauf eingehen können, okay, wie ist sozusagen dann dieses Design Pattern eigentlich, mit so einem geteilten Kern arbeiten zu können?
Marcel: Das war auch ganz interessant. Als wir die ersten Apps gemacht haben, hatten auch Kollegen von mir immer wieder Schwierigkeiten, auch da reinzugehen und zu sagen, nein, die Verantwortung ist im Chor, die Verantwortung sind wir machen nicht hier. Was aus meiner Sicht son wunderschönes Anti Pattern ist, dann zu sagen, ich gestalte hier mal 'n Service und dann mach ich hier mal eine Fassade und trotzdem hab ich noch die den Zustand im im Client so, wie man das bei Webapplikationen oder Webarchitekturen auch gerne macht. Und in dem Fall drehen wir's 'n Stück weit und sagen tatsächlich der Zustand, der herrscht innerhalb des Chors.
Jojo: Mhm.
Marcel: Und auf die Events zurückzukommen, ist es so, dass es sich auf der einen Seite, das hatte ich ja gerade schon gesagt, eignet zu sagen, ich definiere meine Events, weil ich die sowieso auf der UI habe. Also jeder, der schon mal irgendwie 'n bisschen UI gemacht hat, wird wissen, okay, irgendwann klicke ich da drauf und dann muss ich das irgendwie bearbeiten, meinen Eventhändler. Da muss ich definieren. Und die definiert man im Prinzip innerhalb des Chors und grob, wie wir das machen, ist das so gestrickt, dass man sagt, man hat einen, man hat diesen Chor, es gehen bestimmte Events innerhalb des Chors rein.
Jojo: Actions oder wird das oftmals auch genannt? Das von außen.
Marcel: Genau, genau. In dem, es gibt ja gibt sone heiße DE Artikelserie, heiße Developer. Da gibt's einen Artikel schon, da beschreibe ich das auch so als Actions, genau. Das von diesen UI Events 'n bisschen zu trennen. Also die Actions gehen oder die Events gehen rein in den in den Chor. Es gibt einen gewissen Zustand innerhalb dieses Chors, da wird irgendwas getan. Also wie beispielsweise bei dem bei dem Beispiel von von vorhin mit der Police Berechnung.
Jojo: Mhm.
Marcel: Dann hab ich bestimmte Sachen schon schon vor eingegeben. Die kommen alle in das, also sagen wir mal, ich gebe im in dem Artikel sage ich auch, ich gebe Namen und E-Mail-Adresse ein, bleiben einfach mal dabei. Ich hab meinen Namen eingegeben, meine E-Mail-Adresse, das wird gehalten innerhalb des Zustandes. Dann drücke ich auf dementsprechend auf den Button und jedes jede Änderung innerhalb von von der von der UI bezieht sich dann auf das auf den Zustand innerhalb des Chors. Das heißt, wenn ich meinen Namen eintipple und dann beispielsweise den den Fokus wegnehme, wird das schon mal an den an den Chor geschickt. Wenn ich dann meine E-Mail-Adresse eingebe, dann auch, dann kann's kann's noch validiert werden et cetera. Und dann habe ich meinen mein Event für den Button, auf dem ich dann was abschicke oder die Police ausrechne et cetera. Und dann gibt es, wenn ich nach draußen wieder gehen möchte, also ich kam hier rein per Events oder per Actions, dann hab ich meinen Zustand und dann gibt es eine Repräsentation, wie ich gerne sage, von dem Zustand für die UI. Das heißt, es ist nicht 1 zu 1 der entsprechende Zustand. Es ist ein Vorbereitung, wie ich gerne sage, es sind das Templateparameter für ein besseres Template, was denn die UI oder die die Tapete ist. Das heißt, ich hab meine gewisse Vorbereitung mit konkreten Übersetzungen, mit Fehlermeldung et cetera. Alles was was die Tapete braucht, eben gerendert zu werden, gebe ich dann über ein Viewmodel wieder zurück. Das ist erstmal mal so die grundsätzliche grundsätzliche Idee. Da gibt's dann natürlich andere Möglichkeiten mit Plattformspezifika umzugehen, aber da können wir dann später noch mal drüber sprechen. Aber grundsätzlich ist erst mal die Idee, Actions beziehungsweise Events gehen in den Chor. Es gibt einen Zustand, der wird im Chor gehalten und eine Repräsentation, das Ergebnis von der Berechnung et cetera kommt durch ein Viewmodel, also diese die mw wm Architektur, die ist euch bestimmt auch schon mal über den Weg gelaufen und ich gebe dann ein Viewmodel dementsprechend raus. Gibt auch andere Ansätze, also beispielsweise mit Kotlin Multiplattform, wo auch die die Idee 1 View Models ganz groß ist. Und da Ja. Das dann das ist dann genau das Gleiche. Also letzten Endes hat man ein Viewmodel, was was vorbereitet wird für die View Ja. Beziehungsweise auf Viewmodel und dementsprechend ränder ich meine Templateparameter, die in die Viewmodel stecken mit der UI.
Jojo: Also in dem Moment ist es eigentlich 'n Viewmodel oder also ich glaub, manchmal gibt es son bisschen unterschiedliche Definitionen, was der View Model ist, weil son View Model ist manchmal wirklich die Komponente, das in dem Fall jetzt sozusagen dein Chor ist, der halt sozusagen den ganzen Zustand intern hält und dann einen State nach außen gibt, der dann dargestellt wird. Aber grundsätzliche Idee, es gehen halt Actions rein, die werden irgendwie verarbeitet mit einem internen Zustand sozusagen der Komponente verknüpft. Und ich hab dann wieder sozusagen einen State, der sich dann auch asynchron, also reaktiv oftmals ja wirklich per Streaming eigentlich dann aktualisieren kann. Ja. Sagt, okay, ich hab dann letztendlich die finalen Daten und die werden dann irgendwie wieder aufbereitet. Genau. Und so die grundsätzliche Idee, die ich auch immer spannend finde, also ich bin auch sehr stark Verfechter von der von der mvvm, also Model View View Model Architektur, dass man sagt, eigentlich ist nachher die UI eigentlich eine recht dumme Funktionalität oder eine Funktion, die eigentlich nur diesen Zustand dann in eine visuelle Repräsentation überführt. Genau. Aber alles andere sozusagen, das ganze der Operation passiert eigentlich sozusagen in dem Viewmodell oder auch den Schichten dadrunter. Und ich hab am Ende eigentlich nur sozusagen ein relativ komplexes Objekt, was halt eben dann in einen, ja, in eine Maske übertragen wird und dann irgendwie zur Darstellung gebracht wird. Richtig.
Dennis: Du hast grade schon Reaktivität genannt. Das heißt, egal welcher Schritt oder wie klein der Schritt ist, der wird trotzdem praktisch, den würde man immer an den Chor senden oder gibt's irgend, keine Ahnung, irgendeine kleinere Abstraktion, weiß ich nicht, dass bei jedem Tippendeck Tastatur oder so, wenn man dann auch was anzeigen möchte, das würde man immer in den Chor schicken. Also es gibt nicht nur mal, keine Ahnung, wie man sie nennen könnte, Micro Actions oder irgendwie Microactation, die außerhalb davon passieren oder ist das eine Möglichkeit?
Marcel: Das finde ich ganz spannend, dass Du das so fragst, weil wir haben immer wieder das Thema. Und wenn wir Flatter einsetzen und vielleicht wisst ihr mehr als ich, aber wir haben vor dem vor der Herausforderung gestanden, dass wir die auch gerne in Windows oder auf Windows benutzen wollten. Dafür gibt's aber keine Implementierung von Flatter. Also es gibt kein Flatter Package, dass das unterstützt. Und dann sind wir hingegangen und haben gesagt, wie machen wir das denn? Wie lösen wir das denn für uns? Und in dieser ganzen Diskussion bin ich dann für mich auf den Trichter gekommen, dass ich gesagt habe, Interpourutices sind keine Businessanforderung. Das ist ein notwendiges Übel und deswegen betrachten wir das außerhalb des Chors. Das heißt, es gibt bestimmte Aktionen, also vielleicht meinst Du was ganz was anderes, aber das kommt mir sofort in den Kopf. Wir nehmen diese Aktion, die nicht zu der Geschäftslogik gehören und packen sie dann auch in die in die Tapete und sie haben dann auch bestimmte Aktionen, aber das ist das Einzige, was bei uns so gemacht wird, dass es dass es außerhalb des Chors stattfindet. Alles, was eine bestimmte Aktion, was die was den Zustand irgendwie verändert, schicken wir auf jeden Fall in den Chor. Okay, was mir beispielsweise noch einfällt, ja wir haben auch wir haben Nee, da haben wir tatsächlich auch Repräsentation innerhalb des View Models. Ich wollt grad sagen, wir haben sone Geschichte mit schicken Sie uns eine E-Mail, wenn Sie Hilfe haben wollen, Support Request oder sowas. Nee, machen wir machen wir aber auch. Also wir haben zumindest was in Viewmodel. Und wir ziehen dann wirklich da die die Grenze, dass wir sagen, alles, was irgendwie, also der der Chor führt immer. Das ist nicht so, dass da dass der dass die Tapete irgendwie Entscheidungen trifft, wenn bestimmte Entscheidungen getroffen werden müssen. Müssen die durch den Chor gehen, allein auf guter Tatsache, dass wir sagen, wir wollen den später auch wiederverwenden. Sonst müsstest Du ja sagen, okay, haben wir da noch irgendwas drin, was da total wichtig ist? Ja, das und das. Ja, das, warum ist das nicht im Chor? Würd ich dann sofort sagen. Beantwortet das deine Frage?
Jojo: Vielleicht muss man sich auch 'n bisschen vorstellen, weißt Du, es ist ja die Tapete, vielleicht die UI Logik, die Du halt auch Benutzer interagierst und was ja auch sozusagen möglich sein muss, dass Du halt sozusagen aus dem Chor auf andere Schnittstellen, native Schnittstellen zugreist, was dann vielleicht wieder raus in den plattformspezifischen Code, wie jetzt Du grad das Beispiel genannt hast, irgendwelche anzubinden, ist natürlich dann wieder plattform spezifisch. Also dass Du auch solche Adapter hast, die Du sozusagen in deiner Architektur mit anbinden kannst, die dann wie wie in Flatter auch die Plug ins plattformspezifischen Code ausführen können. So was brauchst Du dann dann schon zum Teil. Genau, das ist auch
Marcel: der Punkt, warum wir dann gesagt haben, also wir könnten das wir könnten das auch auf Teufel komm raus in den Chor packen. Man kann auch auf Teufel komm raus plattformspezifischen Code innerhalb von Rust implementieren. Gibt da wunderbare Möglichkeiten auf Basis der Attribute et cetera. Aber es gibt irgendwann so den Punkt, an dem man sagt, na ja, wir wollen ja den Chor haben. Wir wollen ja nur das, was wir was wir wirklich für überall wiederverwenden können, auch innerhalb dieses Chors haben. Und wenn man's dann irgendwann, was weiß ich, da if Linux, if iOS, if was weiß ich, dann wird's dann schwierig und das würde ich auch aus dem Chor in 'ner gewissen Weise rauslösen. Da gibt's auch Mittel und Wege. Aber grundsätzlich, noch mal auf deine Frage zurückzukommen, all jede Aktion, die irgendetwas Geschäftsrelevantes, also wirklich Domain Logik betrifft, die kommt durch den die geht durch den Chor.
Dennis: Das heißt aber auch, dass man praktisch, also wenn man irgendwie Features entwickelt oder Änderungen macht, hat man eigentlich auch immer mit dem Chor zu tun, richtig? Ja. Also wenn ich irgendwie eine Liste oder irgendeine Ansicht hab und möchte jetzt die Möglichkeit haben, da Sachen zu löschen, als Beispiel. Okay, das ist ein bisschen zu offensichtlich, aber gut, da brauchst Du die Funktionalität im Chor, dass es da die Möglichkeit zu gibt.
Marcel: Weil das auch getestet haben wollen.
Dennis: Genau, was aber nicht ja zwangsweise bedeutet, dass das jede der UI Implementierungen, die es möglicherweise da gibt, unterstützt dann tatsächlich auch. Na, Du könntest jetzt sagen, keine Ahnung, auf
Marcel: Ach, Du willst beispielsweise nur was auf Desktop machen und nicht auf mobil.
Dennis: Ja, zum Beispiel. Jetzt bei Flatter ist es wahrscheinlich ein bisschen irrelevanter, theoretisch könnte man ja auch native UI
Marcel: Das ist da
Dennis: davor bauen.
Marcel: Der Haupt Use Case, ja.
Dennis: Und wenn Du jetzt dann sagst, okay, Du hast auf iOS eine Funktionalität, die Du auf Android nicht hast, weil die Nutzer nicht danach fragen oder was auch immer, dann brauchst Du trotzdem diese Funktionalität im Chor und hast halt einfach eine UI, die weiterentwickelt ist als die andere in Anführungsstrichen. Mhm. Das heißt, die können sozusagen laufen, die UIs und die, die Du hast, also der Chor und die Ja,
Marcel: also es muss natürlich irgendwie zusammenpassen, grade wenn Du jetzt integrierst innerhalb von Flatter, dann gehst Du natürlich hin und sagst, Du hast 'n bestimmten bestehenden. Und da gibt es die sogenannte. Und die geht hin und der sagst Du auch noch mal, ich habe eine bestimmte Rust Definition, daraus wird ein Dartcode generiert, den Du dann wieder in in Flatter verwendest. Und wenn das natürlich nicht zusammenpasst, also die der die Flatter der Flatter Rust Bridge Code zu dem Code Code, dann hast Du natürlich dann auch dementsprechenden Probleme. Das heißt, es muss schon irgendwie damit umgehen können, dass da 'n zusätzliches Feld ist et cetera et cetera. Aber Du hast natürlich die Möglichkeit, dann auch das Viewmodel so zu gestalten, dass Du dass Du sagst, Du teilst das auf Basis von bestimmten Pages oder Views auf, dass Du sagst, das ist jetzt ein Navigationsbaum, den ich 'ner mobilen Applikation gar nicht habe und dann sagst okay, das ist jetzt für mich ein ein Teil des Viewmodels, das betrachte ich aber nicht. Ich nehme das einfach so hin und wie heißt 'n, es gibt es gibt bestimmte Bezeichnung dafür für für son Typ, nicht nicht obsolet, nicht opal, glaub ich. Mhm.
Jojo: Ich
Marcel: glaube opal, dass Du einfach sagst, ja, das schleibe ich einfach durch. Das gibt's in der Flatter Rust Bridge beispielsweise auch. Und dann kannst Du das so aufteilen, dass dass dass es von Typen her schon mitgehen muss, aber dass dass man das nicht unbedingt behandeln muss.
Jojo: Mhm.
Dennis: Okay und das heißt aber auch so Sachen, was dann in der UI passiert, das sind dann immer Aktionen, die aus dem Chor kommen. Also wenn ich jetzt ein Formular hab und da ist ein abschicken Button und danach komme ich auf die Seite davor zurück auf Home oder was auch immer. Das ist dann etwas, was nicht von der UI getriggert wird, sondern was der Chor sagt, was in der nächste Aktion ist.
Marcel: Genau also es fängt von von der von dem Ablauf fängt es tatsächlich so an, dass die UI wird irgendwie gestartet, wird gerendert und in dem ersten Teil oder in 'nem, ja, von dem ersten Rendern, von der ersten Anzeige ist es auch so, dass er, dass der Chor initialisiert wird und dass Du dann sagst, lieber Chor, gib mir mal das Viewmodel, weil ohne Viewmodel mache ich überhaupt
Jojo: nichts. Mhm.
Dennis: Und das
Marcel: ist auch wichtig, weil Du willst es ja auch vom Chor aus steuern. Du sagst dann, kannst auch vom Chor steuern, zeig bitte dir diese dementsprechende View an, was weiß ich, zeig dir eine bestimmte Fehlermeldung an irgendwie ein, wir sind offline, wie auch immer und das steuerst Du alles über den Core beziehungsweise dann über das Viewmodel, weil wenn wenn die UI etwas rendern möchte, brauchst Du die Information aus dem Template sozusagen, also die Templateparameter und das ist wieder das Viewmodel. Mhm. Und alles, was dann passiert, basiert auf dem Viewmodel beziehungsweise auf dem Chor.
Jojo: Grade zu deiner spezifischen Frage, also auch das Routing zwischen einzelnen Patres irgendwie, weißt Du, wie jetzt Home oder so 'ner speziellen Formularseite würde dann vom Chor gesteuert werden, weil das hatte ich schon oft in anderen Technologien auch gesehen, dass trotzdem sozusagen Routing Logik eher sozusagen außen lebt, also in den Views und nicht in den View Models. Aber euch würde sozusagen auch das Routing dann irgendwie von dem Chor gesteuert werden, zu sagen, wie nach dem Abschicken deines Formulares, Du langst zurück auf die Homeseite, natürlich muss dann die ganzen Templateinformationen für Home wieder geladen werden, aber dass allein wieder der globale Zustand der App auf ich bin jetzt auf Home zurückgeschaltet wird, übernimmt.
Marcel: Das, wir machen beides. Mhm. Einmal ist es, wir wir wir haben eine App, die ist so klein, da gibt's kaum Routing.
Jojo: Mhm.
Marcel: Außer drück mal bitte hier drauf, mal supportey. Also sie ist insofern klein, dass wir sagen, wir haben einfach nur eine Ansicht. Mhm. Wo dann Messdaten eingegeben werden lassen, 'n bestimmtes Ergebnis und Du wechselst das kaum. Ja. Aber Du gehst noch mal hin und sagst, ich hab 'n Problem, ich will Support Recers machen. Ja gut, da gibt's auch noch in dem in dem Viewmodel, die, was ich ja vorhin auch schon sagte, die Supportinformation, also wie lautet die E-Mail-Adresse und was für Text soll angezeigt werden in den verschiedenen Sprachen et cetera. Aber da da da triggern wir das Routing nicht. An in anderen Applikationen machen wir das wiederum schon, dass wir sagen, wir haben bestimmte Sachen, wo wir, woran denk ich gerade am besten, ah genau, die Geschichte mit dem, was ich gesagt hab, mit dem Malen, das dann wechseln wir immer hin und her und das wird dann auf Basis des Hum Models gesteuert, ganz genau. Mhm. Es ist sowieso, also allgemein kann man sagen, so wie bei den Kollegen, die von denen ich vorhin gesprochen habe, ist es eine gute Idee, wenn man sagt, ich möchte Apps anbieten mit einem oder ich möchte einen bestimmten Dienst anbieten, die verschieden die verschiedene Plattformen bedienen, was das auch immer sein soll und ich hab beispielsweise sone Webapplikation. Ist das erst mal eine gute Idee, weil Du eben hingehen kannst und sagen kannst, ich habe meinen entsprechenden Chor, ich habe da dementsprechend mein Web Assembly, da können wir uns jetzt auch noch, also können wir uns reinnörden in, wie groß ist das Web Assembly Modul et cetera et cetera. Überraschung Überraschung, Russ ist mit das kleinste. Man könnte auch noch SIC verwenden, das dann wieder 'n anderes Thema. Mhm.
Jojo: Also
Marcel: kann kann dir den Ansatz auch in SIC umsetzen. Aber Du bist dann eben sehr gut unterwegs mit dem Chor, weil Du sehr kleine Web Assemply Module auch noch auf Basis von erstellen kannst und das dann wieder 'n gute UI Technologie anbinden kannst. Womit ich persönlich keine Erfahrung habe, ist Flatter und und das Web. Ich hab immer mal gehört, das ist so das das das Sorgenkind. Du kannst da vielleicht irgendwie mich gerne korrigieren. Das haben wir nie gemacht, weil wir gesagt haben, wir machen, wir beherrschen andere UI Technologie und binden dann das Modul anders an.
Jojo: Also so
Marcel: hast Du eben immer eine gute und und performante und robuste Implementierung auf Basis von von Rust, die Du auch in dem Browser beispielsweise wieder verwenden kannst.
Jojo: Ja, vielleicht greif ich nur die Frage zu Flatter und Web auf. Ja, auf jeden Fall merkt man, das hat so seine Besonderheiten, wenn man letztendlich Flatterful Web verwenden will, grade wenn man, wie wir versucht, dort Spiele zu bauen und sehr viele Assets hat, dann muss man sicherstellen, diese Sachen müssen auch vorgeladen sein. Also das, was in der Tief so out of the box funktioniert, dass alles direkt instantant da ist, da braucht man letztendlich die Standardwebtechnologien und Ansätze, die halt für Web natürlich optimiert sind, dann Inhalte vorzuladen oder Ähnliches. Aber an sich funktioniert eigentlich Flatter im Web sehr, sehr gut, so von der Performance. Auch grad sagen wir jetzt von der Bundle Size mit dem Canvas Kind und Support, der jetzt dort existiert, auch letztendlich mit der Möglichkeit letztendlich Flatter zu zu kompilieren und dann wirklich als was Modul auszuführen, wird das natürlich doch mal deutlich schneller. Aber ich glaub, für mich ist auch der spannende Punkt, grade so die Frage, Du hast vorhin gesagt, ja, mein, ihr habt das früher in c plus plus gemacht. Also warum ist Rust jetzt grade sozusagen diese Technologie, die man vielleicht für diesen Chor verwenden sollte? Weil man könnte es in c plus plus machen, man könnte es vielleicht auch in Kotelim Multiplattform machen, was hat irgendwie Raster für Vorteile? Und ich glaube, was Du vorhin auch schon angeschnitten hast, es bietet erst mal per se natürlich sehr viel Support oder kann in verschiedenste auf verschiedene Plattformen kompiliert werden. Zum einen halb Web Assembly, wo halt zum Beispiel Cottono Multipplattform natürlich noch nicht so ausgereift ist und bisher nur experimentellen Support bietet. Und das ist wahrscheinlich auch für dich sozusagen der größte Pluspunkt, den Raster eben bietet. Und vielleicht kannst Du das noch mal kurz aufgreifen, was sozusagen
Marcel: die ganzen Faktoren waren, weswegen Du sagst, grade Rust ist da eben der geeignete Kandidat, so eingescherten Codechor zu entwickeln. Das Pferd das Pferd kann man von verschiedenen Stellen von hinten, von vorne, von rechts, von links aufzäumen, weil es ja immer die Frage gibt, warum sollte ich eine bestimmte Programmiersprache verwenden? Mhm. Und es gibt natürlich aus meiner persönlichen Sicht einen großen ein großes Argument, warum viele Dinge momentan in in Rust neu geschrieben werden, dann eine bestimmte Performance rausgeholt wird et cetera. Mhm. Also ich kann das, was Du gesagt hast, so unterschreiben. Als wir hier bei dem bei dem Meet-up waren, hat Mike vor mir einen Vortrag über Koteln Multiplattform gehalten Mhm. Und hat auch gesagt, ja, es gibt jetzt die dementsprechend die Garbage Collection von Web Assembly, deswegen werden die Module mit Cottteln auch kleiner et cetera et cetera. So, also das ist ein riesiges Thema. Ich versuch's aber trotzdem mal mal aufzubrechen. Wenn man dann hingeht und sagt, ich überlege mir, eine bestimmte Programmiersprache einzusetzen und wir sagen jetzt, wir könnten beispielsweise c plus plus verwenden und wir könnten Rust verwenden. Dann würde ich hingehen und sagen, wie sieht's aus mit Speicherverwaltung? Das ist immer der große, große, große Punkt, warum Rust genannt wird, warum man Rust einsetzen sollte, weil Du eben semi manuelles Memorymanagement hast.
Jojo: Mhm.
Marcel: Also das kurz zu umreißen, das soll jetzt ja auch kein Rust Deep Dive werden. Rust hat die Idee von Ownership und von Boring. Das heißt, es wird ein bestimmter Speicherbereich erlocktiert und wenn er nicht mehr gebraucht wird, wird er aufgeräumt. Und dieses nicht mehr brauchen, das ist ja eine Sache, die Du irgendwie ausdrücken musst, beziehungsweise Du musst dem Compiler beziehungsweise dem sogenannten Borrow Checker, es wird mich auch was ausgeliehen, da komme ich gleich dann noch mal drauf, ihr musst Du irgendwie mitteilen, ich will das gerade noch verwenden. Bei Sprachen wie Kotelin und alle fast alle Sprachen, die wir heutzutage verwenden, gibt's ja den Gabor Collector. Mhm. Und der würde dann dementsprechend auch 'n Web Assembly anspringen. Und jetzt kann man sich darüber unterhalten, ist das ein Thema oder ist es das nicht? Und das ist genauso schwierig zu beantworten wie deine Frage, vorhin Dennis. Ich halte es für hochperformante Applikationen für ein Thema Ja. Und gerade wenn's auch Cross Plattform geht. Mhm. So. Das ich muss man seit eigenem Benchmark machen, dann hinzugehen und zu sagen, ist das cool oder ist das nicht, aber nochmal auf Rust zurückzukommen, das ist beispielsweise eine Sache, die Rust als Pluspunkt mitbringt und warum ja auch Rust inzwischen schon in dem Linuxkernel drin ist. Dass man einfach sagt, dieses Memory Management ist nicht da. So, es kommt immer drauf an, womit mit welcher Alternativen man das vergleicht.
Jojo: Aber Du meinst jetzt im Vergleich zu c plus plus und c plus, wo Du wirklich komplett sozusagen die Speicherverwaltung natürlich manuell übernehmenst.
Marcel: Genau, ja. Und bei KootLIN ist es ja beispielsweise so, das läuft ja auch hauptsächlich auf der auf der JWM. Inzwischen ist es ja so, dass KootLIN daraus 'n bisschen erwachsen ist und dass es auch viele Implementierungen gibt, die man dann auch in in Kotelyn Native, dass das dann auch in verschiedene Sprachen übersetzt wird et cetera. So. Da ist es aber grundsätzlich so, dass wenn wenn wir erst mal Kotelyn in Bezug auf die JWM setzen und wie wie Kotelyn hauptsächlich funktioniert, dass er dann auch wieder mit der Garbage Collection zu tun hast. Das kann ein Problem sein, muss es nicht. Mhm. Rust hat zusätzlich auch noch die Eigenart, klingt jetzt zu negativ, aber es hat auf jeden Fall, bringt es auf jeden Fall noch mit, dass Du bestimmte 0 Safety so mitbekommst, dass es das einfach nicht gibt. Du kannst in Rust kein 0 einem Wert zuweisen. Du musst dich jeden Scheiß, ich sag's jetzt mal so, manuell kümmern und sagen, Du triffst diese Entscheidung. Es gab die diese diesen Ausfall, ich glaub bei Cloudfair war das. Musst dann auch noch über LinkedIn ist dann immer diese eine Zeile durch die Gegend durchs Dorf getrieben worden und da gab's dieses unrap und das unrap ist genau das, was Du dich, Du kannst dich dann als Entwickler dazu entscheiden zu sagen, ich prüf das jetzt nicht. Ich sag einfach in, da ist 'n Wert drin, den packst Du einfach aus und wenn da nix drin ist, dann bekommst Du's eben dementsprechend die Ohren gehauen und das ist da, dass es da auch, so viel ich weiß, passiert. Mhm.
Jojo: Ich bin
Marcel: ja jetzt nicht so hundertprozentig drin, aber das ist sone Geschichte, das wird dir einfach als Entwickler viel schwerer gemacht, da bestimmte Knypointer Exceptions, es gibt weder Exceptions in Rust, nur noch die Knypointer, das zu machen. Das heißt, Du hast eine gewisse Robustheit, wenn das ein deutsches Wort ist.
Jojo: Gewissheit, ja.
Marcel: Robustheit, eben
Jojo: von der Sprache her. Die die
Marcel: Du die Du bei anderen Sprachen eben nicht hast.
Jojo: Mhm.
Marcel: Und da da geht's auch wieder so in die Richtung, ich bin, also bei bei uns ist es beispielsweise so, wir sind so in diesem Rust Umfeld drin, dass das sich da total natürlich anfühlt. Ich hab beispielsweise vor 'nem Monat hab ich auch wieder was in NextJS gemacht und mit type Script und da hab ich einfach festgestellt, heiliger Vater, was ist das für eine Kiste von wegen, ja, das wird ja noch in type Script übersetzt und wenn ich dann bestimmte Typen machen möchte und dann möchte ich meinen Union Type irgendwie kontrollieren und ja das kann ich hier nicht und dann muss ich da was machen und dann muss ich hier noch eine Property hinzufügen et cetera. Es gibt einfach bestimmte Dinge an, die gewöhnst Du dich sehr, sehr gut. Jemand der im Java Space drin ist oder im Cottland Space sagt, ey funktioniert doch auch alles. Ich versuch's nur so wirklich so son bisschen Schritt zurückzutreten und zu sagen argumentativ ist das so und so und so. Es hat immer alles 'n Preis. Ja. Aber wenn Du sagen möchtest und das ist 'n das ist ja das Argument, auf der ich das immer wieder zurückführe, Du es längerfristig haben möchtest, Du möchtest es besonders robust haben, Du möchtest es besonders performant haben, Du möchtest es speicher sicher haben, dann ist Rust die Möglichkeit, Ja. Diesen Ansatz von von einem von einem Cross Plattform Chor darauf basieren zu lassen. Ja. Wie gesagt, man kann das auch in in Go machen von den Kollegen, die ich da genannt habe, die haben und ich hab das auch mal für mich getestet. Ich habe einen einen einen Benchmark gemacht oder ich hab 'n Vergleich gemacht, ums nicht so hochwissenschaftlich irgendwie zu zu betiteln, dass ich gesagt hab, pass auf, ich mach jetzt hier sone Aufgabe, die implementiere ich jetzt in verschiedenen Sprachen und die möchte ich 'n Rap Assembley überführen. Mhm. Und dann vergleiche ich einfach mal, was da rauskommt. Und ich habe, was habe ich genommen? Ich habe Cottle Multiplattform genommen, ich habe Sik genommen, ich habe Go genommen und Rust. Und je nachdem, welchen Ansatz man fährt, innerhalb auch von Rust hat man unterschiedliche Größen. Es gibt sowas, das nennt sich Wasn Bine Gen, das fügt dann noch son bisschen Rapper dazu, dass dass Du mit den Typen von Web Assembly zu Javascript 'n bisschen einfach arbeiten kannst, dass Du bestimmte Sachen überhaupt nicht implementieren musst et cetera und Du musst halt sowohl diesen Gluecode, den es bei Kotelin übrigens immer gibt in Java Script, musst Du auch mit reinrechnen. Und ich hab jetzt die Zahlen nicht so im Kopf. Also bei bei Go waren wir im Megabyte Bereich 1.4 glaube ich und bei bei Kotelin waren wir glaube ich bei, jetzt muss ich kurz lügen, ich glaub da waren wir, oh Gott, was
Jojo: Vielleicht war's aber ein bisschen kürzer als Rust am Ende.
Marcel: Also letzten Endes war es so, Zigg war das Kleinste. Ja. Nee, Quatsch, Rust war das Kleinste im im optimierten Zustand ohne Warzen Binegen, danach kam kam Zigg. Danach kam Kotelan Multiplattform und dann kam Rust unoptimiert. Mhm. Aber Go weit, weit, weit abgeschieden. Mhm. Und dann kommt auch wieder die Geschichte dazu, wenn Du es dann implementierst, ist dann die, weil Kotelyn Multiplattform setzt immer auf den Web Assapply Gavage Collector. Das kann ein Problem sein, das muss es nicht.
Jojo: Bist Du nicht von allen Browsern unterstützt? Also von älteren Browsermodellen noch gar nicht?
Marcel: Soviel ich weiß inzwischen schon. Ja, okay. Ja, hatte Mike mich auch 1 1 Besseren belehrt. Inzwischen jetzt auch beim Safari. So, jetzt kann man noch mal sagen, ist das 'n Ding, weil die Gabish Collection hast Du mit Rust nie. Ja. Die hast Du da auch nicht. Ist das jetzt 'n Problem oder nicht? So. Aber letzten Endes kannst Du's machen in in den in verschiedenen Sprachen. Unterm Strich ist Rust für mich genau dieser dieser dieser Suite Spot zwischen, ist das irgendwie hochkomplex, ist es es es bietet bestimmte Vorteile dadurch. Es ist sehr inzwischen ausgereift, also wenn jetzt beispielsweise SIC angucken, SIC oder Rust.
Jojo: Mhm.
Marcel: Go oder Rust. So, da kann kann man sich das mal,
Jojo: für
Marcel: mich ist es einfach nur der Punkt, den ich sage, ich würde grundsätzlich erst mal gucken, ist das mit Rust irgendwie möglich, weil ich da auch in 'ner gewissen Weise drin bin. Mhm. Dass es, wenn da wenn der wenn der Compiler einmal sagt, das ist durch, hast Du auch kein kein Laufzeitproblem mehr und das ist so der Punkt, bei dem ich dann sagen würde, wenn man es auch in Rust machen kann, soll man es so in in Rust machen. Früher ein totaler Java Nerd und mittlerweile ist der Use Case für mich da gar nicht mehr da. Aber ja, so, aber das nur, ich will gar nicht so sehr in in in Rust reingeht. Das ist nur der Grund, warum ich sage, dass das eine eine gute Idee ist, wenn man das wirklich auch über die verschiedenen Plattformen inklusive Web Assembly mit betrachten möchte.
Jojo: Ja. Ich glaube, wir hatten ja auch schon entsprechende Deep Dives hier zu Rust und ich glaub, das ist einfach das, was Du irgendwie genannt hast, dass es einfach die wesentlichen Vorteile sind. Und ich denke grade, man sieht natürlich durch den Support, den's in der Industrie jetzt von Amazon, Google, also alle haben sich ja drauf committet und entwickeln letztendlich auch sehr viel in Rust, dass man gefühlt einfach da 'n sehr großes Backing einfach dahinter hat. Genau. Und deswegen grade auch so diese Bewandtheit. Und ich glaube, was ich hier vorhin ja auch so angesprochen hab, es läuft einfach auf sehr, sehr vielen Plattformen von Haus aus. Du hast dir das Wisum angesprochen, auf Microcontroller hast Du vorhin erwähnt, wo man auch letztendlich dann einfach Rustcort hinportieren kann oder übersetzen kann. So als Nachteil, das hast Du vorhin vielleicht auch son bisschen anklingen lassen. Zum einen natürlich ist diese Strukturiertheit der Sprache sehr, sehr gut, aber es erfordert auch eine gewisse Eingewöhnung, da reinzukommen. Also hat eine höhere Lernkurve vielleicht irgendwie sich mit Rust auseinandersetzen als mit anderen Programmiersprachen wie jetzt vielleicht Dart, aber dafür hat man, wenn man's einmal verstanden hat, letztendlich 'n sehr gutes Tool, damit verschiedenste Dinge machen zu können.
Marcel: Für mich ist einfach 'n riesengroßes Ding, dass ich sage, das hatte ich ja grade eben auch schon angesprochen, wenn ich das einmal kompiliert habe und das ist einmal eine Produktion, mach ich mir da keine Sorgen.
Jojo: Mhm.
Marcel: Das war mit anderen Sprachen nicht immer so. Ja. Mein Gott, also wie gesagt, wir setzen hier dementsprechend auf Flatter ein und ich glaube, es ist auch 'ne gute Idee dann zu sagen, okay, pass auf, wir haben bestimmte Vorteile aufgrund von von Dart. Wir haben bestimmte Vorteile aufgrund von flatter. Ich find das auch, also von von dieser ganzen Cross Plattform, von den ganzen Cross Plattformen Frameworks inklusive und Composed, Multiplattform, was ja was ja von auch wieder von Jetbrains ist und dann auch auf Kotelem Multipattform aufsetzt, aber nur das das Rendering der UIs übernimmt, ist Flatter aus meiner Sicht immer noch die beste, der beste Abstraktionslayer. Das ist ja auch unfassbar kompliziert.
Jojo: Also wenn
Marcel: man sich auch anguckt, was da alles so abstrahiert wird innerhalb so 1 Flatterprojekts, ist das eine eine Riesensache und deswegen ist das erst mal aus meiner Sicht immer noch das Beste, wenn man sagen kann, pass auf, das soll irgendwie laufen. Das ist auch genau der Punkt. Es man merkt es halt auch oft und wenn das aber kein großes Problem ist, dann kann man das ja auch, kann man das nehmen, kann man das auch nehmen und deswegen ist es auch in Ordnung, damit zu starten, Wenn man halt mehr möchte, robuster, langlebiger, sicherer, speicheroptimierter et cetera ist das und das ist das, was wir hauptsächlich machen wollen, dann ist das eine gute Idee, dann auch noch Rusp mit reinzubringen.
Dennis: Wenn man jetzt den Ansatz fährt oder fahren will, den den den ihr gemacht habt, was würdest Du sagen, sind so die größten technischen Herausforderungen oder Stolpersteine, über die man sich Gedanken machen muss?
Marcel: Ich glaub, das hatt ich vorhin schon angesprochen. Man hat dann eine gewisse Art von Infrastruktur, also Dinge müssen ineinandergreifen. Der Chor muss irgendwie eingebunden werden. Und wenn wir beispielsweise das nativ nativ betrachten, dann ist es auch so, dass irgendwie das dann auch übersetzt werden muss. Also ich hab beispielsweise im Bezug auf eine RAS Integration mit Unify, Unify ist son sone RAS Bibliothek, auf Basis von RAS Code sprachfremden Code herzustellen, zu generieren. Und da hatte ich mich mit der Simharb Implementierung gut auseinandergesetzt und das musst Du halt immer irgendwie hinbekommen. Das ist, da wird dann auch serialisiert und deserrealisiert. Wir hatten noch eine weitere Herausforderung, das vielleicht nur noch mit anzusprechen, wir haben darüber hinaus neben der Rast- und Flatter Integration, haben wir sogar auch noch c integriert. Weil der Kunde dann sagte, ich will auf jeden Fall bestimmte Logik in c implementiert haben, weil ich den kommerziellen Support von den Micro Controller Herstellern haben möchte, was die Implementierung angeht. Also beispielsweise sone STM 32 nimmt, das kann man wunderbar implementieren. Mit mit Rust gibt es auch Community Support. Wenn man den kommerziellen Support haben will, ist das eben noch schwierig. So dann.
Jojo: Mhm.
Marcel: Also alles hat irgendwie sein sein sein für und wieder. Und dann haben wir noch c integriert und dann wird es dann schon schwierig, wenn Du das alles zusammenstöpseln musst. Bleiben aber erst mal nur bei bei Rust und Flatter oder Rust und den anderen nativen Technologien. Du musst eben dafür sorgen, dass diese Integration funktioniert. Und Du musst auch dafür sorgen, dass wenn Du das serialisierst und deserialisierst, dass Du dann guckst, dass Du auch nicht zu viel Zeug durch die Gegend schickst, so. Weil das ist halt 'ne Schnittstelle, die Du an anderer Stelle nicht hast und das ist immer noch das das Problem.
Jojo: Also grad wenn Du sagst, ja, Du musst halt irgendwie gucken, dass dann sozusagen diese Flatterteile jetzt mit dem nativen Code irgendwie operieren können mit dem Chor. Also wie passiert das? Also Du weißt das? Ich kenn das früher nur so von Interfaces. Du hast letztendlich diese native Bibliothek und Du musst irgendwie von Hand gucken, dass Du den entsprechenden den wir dazu baust? Oder hast Du da irgendwie 'n Support, dass Du sagst, okay, aus meinen aus meinen Definitionen, kann ich automatisch dann entsprechend die nativen Schnittstellen generieren lassen. Also was fürn Support hab ich da, halt diese Schnittstelle dann einfach einbinden zu können?
Marcel: Also bei Flatter, das hatt ich ja vorhin schon gesagt, gibt's die Flatter Rust Bridge.
Jojo: Mhm.
Marcel: Und Du gehst wirklich hin und sagst, Du Du hast bestimmte Rust Typen, die Du definierst. Mhm. Und markierst sie dann mit sogenannten Attributen, was in anderen Sprachen oder Annotation, wie auch immer heißt. Und dann wird daraus Dartcode generiert.
Jojo: Okay.
Marcel: Unter der unter der Haube wird das auch wieder serialisiert und deserilisiert. Mhm. Und aber letzten Endes kannst Du relativ einfach hingehen und deine Strukturen, also in Russ gibt es ja keine Klassen, sondern Structs, an die man Methoden dran bindet. Und Du kannst dann deine deine Structs nehmen und daraus, wenn Du auch eine Methoden dran hast, Klassen generieren lassen. Und die nimmst Du dann einfach 'n Dartcode. Und wenn Du dich nicht damit auseinandersetzen möchtest, rufst Du halt deinen Dartcode auf. Mhm. Und das wird dann dementsprechend überführt und in in Rust
Jojo: Okay. Deseralisiert. Und für andere Sprachen hab ich dann einfach ähnliche Bibliotheken, die mir dann auch entsprechend Code erzeugen oder
Marcel: Genau. Ja. Also ein eine Anlaufstelle ist Unify. Wenn also wenn wir jetzt im im Plus sprechen, das ist das, was ich gerade schon angesprochen habe und das ist einfach Unify mit FFI, ne. Also UNIFFI, dann zu sagen, ist das FFI nur 'n bisschen aufgemotzt. Mhm. Und da werden dann verschiedene Sprachen unterstützt. Also C-Sharp, typeskript, Java et cetera et cetera. Mhm. Und es gibt auch eine noch eine andere Geschichte, das nennt sich CERDI Generate. CERDI ist eine der beliebtesten Creets, das sind das sind RASP Bibliotheken und da geht's einfach Seralisierung und Deseralisierung, also CER und D, Zeroized und Deserilized und da gibt es auch ein Generate. Das heißt, da werden die die Structs auf Basis von SerDgenerate auch wieder in andere Sprachen überführt. Es gibt für alles eine Möglichkeit und es gibt auch noch, wie heißt denn das andere? Heißt das? Das weiß ich, weiß ich gerade nicht. Es gibt auch noch 'n anderes Create, aber aber Unify, Solid Generate und Flatter Rus Bridge ist das, was wir einsetzen, das dann zu überführen. Aber letzten Endes bist Du immer wieder in der nativen Sprache und kannst auch sagen, ich kann mich überhaupt nicht mit Russ aus, ich schreib hier nur die UI, das kannst Du auch damit tun.
Dennis: Wenn jetzt jemand anfangen möchte und so was Ähnliches oder den Ansatz verfolgen möchte, was sind so die Anlaufstationen, also 'n paar der von euch genutzten Pakete, das ist jetzt genannt. Gibt es da noch irgendwie was, gibt's noch eine, na ja, Dokumentation ja nicht so richtig, aber gibt's noch irgendwas Übergreifendes, was das was das Konzept irgendwo da draus noch mal beschreibt oder den Einstieg darin 'n bisschen erleichtert?
Marcel: Ja, also zu einem möchte ich den von mir sehr geschätzten, leider verstorbenen Stefan Tillkow zitieren. Man kann uns sehr viel Geld geben und da machen wir das. Also, zu uns kommen und wir wir reden darüber, wie wie man das implementieren kann. Es gibt, und das ist auch etwas, was wir unter anderem einsetzen, dass die, die Bibliothek, das Framework, das schreibt man CRUX. Mhm. Das ist eine Implementierung von diesem Ansatz für Headless Apps von 1 Consultingfirma aus London, die nennt sich Red Badger und dort werden diese ganzen Konzepte noch mal zusammen gebündelt. Mhm. Das heißt, es gibt da nicht die Actions, da heißt's tatsächlich Events. Es gibt da dementsprechend das View Model, es gibt den entsprechenden Zustand und es gibt auch eine Geschichte, über die wir noch nicht gesprochen haben, nämlich die Plattformspezifika. Und das wird da da so gelöst, dass es nicht nur Events, dass Events reingehen, sondern es gehen auch geht auch etwas raus und das sind die sogenannten Effekte. Sonst man sich dann, also es ist immer schwierig, wenn man dann über diese eventgetriebene Geschichte geht, bei dem einen sind die Events die Effekte et cetera et cetera. Bei bei Krux ist es so, dass Events reingehen, Effekte gehen raus. Ein Effekt ist beispielsweise, haben wir jetzt, glaube ich, schon zehnmal drüber gesprochen, das Rendering. Also es wird gesagt, die der der der Chor sagt, ich möchte jetzt, dass Du Renderst. Ein anderer Effekt kann sein, gib mir doch bitte mal die aktuelle Uhrzeit, weil die sollte, also kann man natürlich irgendwie auch Teufel komm raus in in den Chor packen. Andere Geschichte ist, greif doch bitte mal auf die Kamera zu. Das ist das, was Julius vorhin auch angesprochen hatte von wegen Plattformspezifika Und das bildet man dann dadurch ab. Und wenn man dann gucken möchte, wie funktioniert das dann? Was kann kann man dann alles so tun, kann man bei Cracks mal vorbeigucken. Was sie noch nicht haben, ist ein Beispiel für für Flatter. Das wird höchstwahrscheinlich in den nächsten Wochen von mir kommen. Bin noch 'n bisschen aktiv in der Community und Sie haben aber bestimmte Beispiel für für andere mobile Applikationen und auch für Webapplikationen. Mhm. Wird auch so was eingesetzt wie Wesm Pack beispielsweise. Wesm Pack ist sone, also man kennt ja Webpack. Ja. Man kannte mal Webpack im Bereich von von Web und Wesm Pack ist im Prinzip 'n Pendant, 'n Raster zu, dann schreibt man an 1 bestimmte Funktion dran. Hier mach mal mach mal Web Assembly. Und da wird das, von dem ich vorhin gesprochen habe, dann auch angesprochen und auf einmal hat man seine Rushfunktion in Web Assembly. Und so gibt's da auch Beispiele, die man sich bei bei Cracks mal angucken kann. Auch sehr simple, wo dann einfach nur son Counter definiert wird. Ja. Genau. Und die die gibt's dann auch für für verschiedene. Ein genau, bei dem, wenn man sich 'n Windows Beispiel angucken möchte, gibt's den. Da gibt's auch diese Implementierung. Ich hatte ja vorhin gesagt, dass ich mich mich mit c-Sharb auseinandergesetzt hatte. Und deswegen hatt ich mich mal das mit auseinandergesetzt, zu zeigen, so würde die Integration in c-Sharb aussehen. Genau. Also von. Und übernimmt dann für mich
Jojo: auch son bisschen so das für meine Bildpipeline, weil das könnte ja son bisschen komplexer sein, wenn ich sozusagen jetzt irgendwie habe, der nativen Code habe. Der führt das schon alles son bisschen zusammen, hat dann son Art Projekttemplate, was ich nutzen kann. Oder ist das immer noch etwas, was ich dann noch erst mal aufbauen, muss ich das, ich meine habe, das alles zusammenzubringen? Du bist
Marcel: natürlich total frei, wenn Du's unbedingt sein möchtest. Wenn man erst mal anfangen möchte, würde ich vorschlagen, sich an die ganzen Strukturen in den Beispielen zu halten und das, was was Cracks am meisten bietet, ist auf der einen Seite Struktur, also dass Du sagst, okay, hier gibt es bestimmte bestimmte Typen, wie ich's implementiere, wie ich die die App implementiere. Und auf der anderen Seite bietet es auch 'n bisschen Toolintegration in Bezug auf Unify. Also dass Du dass Du sagst, wenn Du die Beispiele anguckst, wird das auch gemacht. Okay, pass auf, ich würde das jetzt gerne in in Julius integrieren, ich würde das gerne in iOS integrieren. Wie mache ich das et cetera? Und da kannst Du dich einfach dran halten und dich daran langhangeln und dann hast Du sehr, sehr, sehr schnell auch 'n Ergebnis, ohne dich mit diesem ganzen Detailkram auseinandersetzen zu müssen. Weil Du einfach sagst, guck, hier ist meine Struktur, da ist schon da ist schon iOS drin, ach, dann änder ich dann hier noch was und zack funktioniert das. Bei iOS und x Code ist das immer sone Geschichte. Das wüsste ich dir wahrscheinlich genauso gut wie ich.
Dennis: Ja, ja.
Marcel: Und ja, aber so bietet es eine gewisse Struktur, erst mal damit anzufangen. Cool.
Jojo: Ja, also Genau. Zusammenfassend sagen irgendwie, ich glaub, weißt Du, so die großen Fragen, wann macht das Sinn letztendlich, das einzusetzen, Und für uns so grade als Entwickler, wir haben eher dieses prototypische Vorgehen manchmal, weswegen natürlich dann vielleicht zu sagen, man entwickelt das erst mal in 1 Technologie 'n richtiger Schritt sein kann. Aber ich seh sehr stark natürlich das, was deine Kunden haben, eben dieses Langfristige über verschiedene Plattformen hinweg, wo's natürlich super sinnvoll ist. Und aus der Eigenerfahrung ja, geteilten Code zu haben auf verschiedenen Plattformen, der einfach dann auf jeder Plattform laufen kann. Und wenn er irgendwie ab so gut getrennt werden kann. Und ich glaube grad natürlich, das, was eben auch Krux bietet, das Pattern, was Du beschrieben hast, ermöglicht einen natürlich sozusagen so diese klare Trennung zwischen was ist etwas, ein Event, was irgendwie reingeht in das System, wo dann Zustand verknüpft wird und am Ende letztendlich ein ein ein generiert wird, der in der UI einfach nur wieder repräsentiert. Das ist grundsätzlich natürlich 'n sehr gutes Pattern, halt so die bis Nik Logik oder auch die Anzeigelogik so weit wie möglich eigentlich von der eigentlichen Repräsentation in der UI zu trennen. Und damit natürlich diese Schicht, wie Du's gesagt hast, die Tapete so dünn wie möglich zu halten, dass sie über diesen variablen Kern dann eigentlich drüber liegen kann. Ist, glaub ich, immer 'n sehr, sehr guter Ansatz, dort viel zu teilen und auch vielleicht für weitere Zwecke irgendwie wiederverwenden zu können.
Marcel: Man man muss es ja auch nicht unbedingt in 'ner anderen Sprache machen. Das ist eine Frage, die ich auch noch an euch hätte. Also was ich ja vorhin genannt hatte, ist die Testbarkeit. Man kann das ja auch innerhalb, sagen wir mal, wir würden das in in Flatter so implementieren, also die diesen diesen Ansatz kann man's ja genauso machen.
Jojo: Also Ja,
Marcel: ja, ja, ja, ich hab meinen bestimmten Chor, ich hab meine zu meinen Zustand, ich hab mein Viewmodel et cetera. Ja. Du hast eben und da kommt jetzt gleich meine Frage, dass eben den wunderbaren Vorteil, dass Du es unabhängig davon, wo geklickt wird, eben testen kannst. Ja. Und das wär meine Frage. Wenn ihr eure Spiele entwickelt, wie geht ihr mit den Tests Was testet ihr? Wo wo setzt ihr an? Denn das für uns von unserer Seite noch mal zu sagen, wir fangen meistens damit an, diese Events eben zu orchestrieren und machen noch ein bisschen UI. Aber dann bei UI ist bei uns ganz ganz wenig, weil wir uns darauf verlassen können, dass das dementsprechend läuft. Und das würd mich einfach noch mal interessieren, wie wie ihr das angeht.
Jojo: Ich glaub, weißt Du, ich muss, wir müssen sagen, es gibt nicht immer diesen einheitlichen Weg, den wir vielleicht bei insgesamt Lotum da verfolgen. Zumindest die Spiele, die ich in der letzten Zeit entwickelt hab, waren sehr stark auf diesem Model View View Model Konzept organisiert und hatten natürlich dann eben diesen Vorteil, dass eben das Viewmodell eigentlich komplett die Logik eigentlich gekapselt hat. Es ist oftmals bei mir dann noch 'n bisschen stärker getrennt. Also sozusagen, ich hab eine Data Store Ebene, die halt wirklich sozusagen den reinen Datenzustand der App vorhält, was halt sozusagen, was sind die Userdaten, was sind die grad aktuellen Events, die grade laufen? Und dann hat man sozusagen auch die View Model Ebene, die halt für einzelne Views, für einzelne Pages eben dann die Viewe aufbereitet. Aber auch das ist eben dann eben eine gekapselte Komponente. Und ich muss eigentlich nur diese Komponente kapseln und hab dann eigentlich kaum noch Tests wirklich gegen die UI, wo ich halt Buttons klicke, sondern einfach sozusagen das Viewmodel mit entsprechenden Tests dann eben bestücken kann und die dann vollständig diese Logik an der Stelle eben ja ab ab frühstücken können. Also da eigentlich nur so diese Trennung unter diesem Viewmodel gibt es eben sozusagen noch mal eine Abstraktionsschicht, die halt eben dann eher hardwarenahe, datennah noch mal die Daten vorhält. Die kann ich nämlich auch schon natürlich schon sehr gut testen. Das eine ist sozusagen eher so die zentrale App Logik der gesamten App und das andere ist sozusagen die pagespezifische Logik, die dann ein Formular zum Beispiel dann ausprägt. So ist diese Trennung, die ich eigentlich in allen den letzten Projekten immer versucht habe, sehr stark so vorzuhalten, was eben auch den großen Vorteil bringt, dass es dann einfach eine sehr einfache Portierung ist. Das ist halt eher so wie dieses Prinzip, Also Du hast einmal sozusagen dieses Grundpattern eigentlich etabliert und kannst eigentlich in jeder Technologie mit den entsprechenden Konzepten eben die gleiche Agentur dann anbringen und dadurch natürlich auch eine sehr gute Verständlichkeit dann am Ende realisieren. Und eine sehr gute Testbarkeit eben durch diese klare Trennung eben dieser Ebenen.
Dennis: Cool. Marcel, wärst Du gerne noch was gefragt worden, was wir nicht gefragt haben?
Marcel: Ich hatte vorhin noch 'n bisschen über diese C-Integration gesprochen. Das ist wirklich, das möchte ich auch noch mal so als kleines Bonbon mitgeben, denn es gab diese Anforderung und wir werden das auch weiterhin machen, weil wir weil wir das sehr gut Okay, das das klingt sehr viel nach Eigenlob, aber wir haben es aus meiner Sicht wirklich robust jetzt gelöst, dass wir sagen, wir wollen auch noch c integrieren in die verschiedenen in die verschiedenen Plattformen. Also dass wir eine einen c code haben, den wir auf die verschiedenen Plattformen bringen. Mhm.
Jojo: Mhm. Und
Marcel: ich hatte das auch damals beim beim Meet-up gezeigt, wir unterstützen, was diese Apps angeht, jetzt muss ich kurz überlegen, Android, iOS, macOS, Windows und manchmal auch 'n bisschen Linux. Und wir bauen mit c tatsächlich 11 Targets, die wir irgendwie vorhalten müssen und diese Bibliotheken müssen wir dann auch noch irgendwie in die in dem Fall auch wieder Flatterapplikationen mit reinbekommen. Und das zeigt besonders diese Cross Plattform oder diese das Cross Compiling, weil wir wollen das irgendwie auch automatisieren. Das hat so einen immensen Aufwand mit sich gebracht im Vergleich zu Rust beispielsweise. Also wenn man sagt, man möchte es performant haben, robust et cetera, möchte auf die Mikrocontroller gehen et cetera, war das ein Riesenunterschied im Bezug darauf, dass das erst mal funktioniert hat. Und eine Anekdote dabei ist auch, wir hatten einen Cross Compiler mit, ich glaub, das war der der Min GW mit Linux. Und dann haben wir das auf Windows kompiliert. Dann gab es eine wunderschönen statische Punkt Datei. Ich weiß nicht, ob ihr das schon mal vorher gehört habt. Ich hab bis dato immer nur von DLLs gehört. Eine ist eine statische Bibliothek, die man dann die man dann lingt. Und das Ding hat auch ist auch wunderbar gelaufen und hat sie falsch gerechnet. Das Ding hat einfach falsch gerechnet. Wir haben's dann irgendwann auch abgebrochen und ich will auch gar nicht zu sehr jetzt die die die Details auspacken und für euch vielleicht langweilen, Aber ich mein, der Punkt, den ich machen möchte ist, wenn man wirklich hingeht und sagt, ich möchte diesen Code haben, der ähnlich zur zur C-Performance ist, sollte man wahrscheinlich auch, also Cross Plattform, auf Rust gehen, weil das und die die zusätzliche Kompelierung dahin, das war das war nie 'n Problem. Aber das mit c war ein Riesending. Wir wir gehen dann hin, bauen die Targets, legen die in 'nem in 'nem bestimmten Repository ab, in so 'nem in so 'ner Package Registry, in GitLab ist das in dem Fall. Dann sorgen wir dafür, dass das runtergeladen wird et cetera, et cetera. Da muss das an den entsprechenden Orten liegen. Es ist also verglichen untereinander ist es ein riesen Albtraum. Und deswegen kann ich nur sagen, wenn man das wirklich machen möchte, liebe C-Entwickler, gebt euch mal 'n Ruck und guckt euch das mal mit Drust an. Ob da
Jojo: noch was passieren wird, wer weiß, in diesem Ökosystem.
Marcel: Ja, da da ist ja da ist ja viel im Gange, ne? Ja, das stimmt. Genau. Aber das das wäre so das Einzige, was mir spontan noch einfällt ist, dass wir tatsächlich, das hatte ich vorhin son bisschen in jedem Satz erwähnt, auch noch mehr machen als das, was beispielsweise die die Jungs von Red Bodger von von Krux auch empfehlen, dass wir sagen, wenn es bestimmte Implementierungen gibt in Rust, die Cross Plattformen funktionieren, dann packen wir die auch einfach mit in den Chor. Was meine ich damit? So etwas wie ein HTTP Aufruf. Das ist eine Sache, da sagen wir, dafür müsse ich keinen Effekt nach draußen geben. Das muss die Tapete oder wie wie das bei Krux genannt wird, die Shell nicht machen. Das machen wir auch selbst. Und zudem haben wir auch gesagt, wir packen, das hatte ich in dem Satz erwähnt, die I 18 n auch noch da rein. Das heißt, wir haben, wenn das wenn die Bibliothek kompiliert ist, wenn das auch in ins Web Assembly Modul kommt, haben wir alles innerhalb des Codes. Wir haben 'n gewisses Makro, der liest dann die entsprechenden Übersetzungen ein und das ist in 'nem Kompilat. Du musst keine zusätzliche, was weiß ich, PO Datei, CSV, JSON, wie auch immer hinlegen, Du hast alles innerhalb dieses dieses Kompilats, weil Du einfach sagen kannst, da fange ich oder damit fange ich an, wenn ich dann eine andere UI entwickle und hab alles, wie ich's ja vorhin gesagt hab, mit batteries included. Das sind so Geschichten, die ich noch die ich noch herausstellen würde. Das würde ich auch so empfehlen, weil dann machst Du dir keine Gedanken oder Du musst keine Gedanken mehr darüber machen, ob Du noch irgendetwas anderes brauchst. Nein, Du hast das Ding kopiert, hast das drin, los geht's. Mhm.
Dennis: Cool. Vielen Dank schon mal bis hierhin. Wir haben jetzt gleich noch unsere. Juju, hast Du einen Herr Pick mitgebracht für uns heute?
Jojo: Ja, für alle, die ihr Ei vielleicht mit Claude ist natürlich, nutzen natürlich nicht alle Klonen. Man hat das Gefühl, bei uns nutzen sehr viele Claude, aber ich weiß gar nicht, wie viele das da draußen sind, aber Hat gefühlt schon viele. Schon viele für in den Entwicklungsbereich. Dann hat er's wahrscheinlich schon mitbekommen, dass es ja inzwischen auch bei Claude immer die Möglichkeit gibt, zu definieren. Könnte man vielleicht früher eigentlich nur aus Cursur. Und grade wenn man halt wirklich große Projekte verwalten wird, also es geht eigentlich darum, man möchte irgendwie sein Projekt Memory verwalten, der natürlich sehr in hilfreichen Kontext einfach für die Codegenerierung mit einem Agent dann bietet. Früher gab's letztendlich nur diese eine closed datei pro Projekt und wo man dann gemerkt hat, das große Problem ist halt, dass der Kontext immer größer wird, weil ich möcht natürlich viele Informationen da reinbringen, aber mancher brauch ich natürlich nur spezifische Informationen, die für den Kontext relevant sind, wie zum Beispiel, wenn ich jetzt irgendwas in meiner API entwickle oder vielleicht in meinem View im Model entwickle oder auf der Store Ebene, also in den verschiedenen Bereichen auch vielleicht meiner Softwareicheitektur, brauche eigentlich nicht immer diesen gesamten Kontext und musste mit ans Model schicken. Und das hat jetzt eben Claude damit gelöst, dass sie halt unterstützen. Sind einfach separate Dateien, wo man oben in dem Frontmeter sagen kann zum Beispiel, es soll sich nur auf bestimmte Pfade beziehen, dass wenn ich zum Beispiel in dem API Ordner dann arbeite und dort Dinge hinzufüge, dass dort dann entsprechend die Code Styledefinition für API Klassen mit in berücksichtigt werden sollen, dass er das alles eben mit einliest und dann genau weiß, okay, wenn ich mich in bestimmten Bereichen meiner Projektstruktur, dann organisiere, ist es vor allem letztendlich auf der Dateipfadebene mit Glock Patterns eben möglich, dort solche Einschränkungen für diese zu machen. Und dann kann er sich eben diesen spezifischen Code, diese spezifische Templateinformation eben dann rausziehen, was es eben ermöglicht, dass man zum einen das Kontextmenü einfach deutlich kleiner reduziert. In letzter Zeit wurde ja viel darüber gesprochen, wie kann ich zum Beispiel bestimmtes Wissen auch in Skills auslagern, sodass ich nicht jedes Mal den gesamten MCP Kontext irgendwie mit in an das Model schicke. Und das ist natürlich dann auch eine schöne Möglichkeit zu sagen, okay, es lebt nicht alles in diesem großen Projekt Memory, sondern ich hab mir das sehr fein untergliedert. Ich hatte viel für mich früher zum Beispiel in Skills organisiert, wo ich dann immer gesagt hab, wenn Du in 'nem bestimmten Bereich von der App anfangs, dann naht dir diesen Skill, weil's damit eben auch möglich war, halt diese partiellen Informationskontext dann zu generieren. Und inzwischen hab ich halt vieles dieser Bereiche jetzt in die überführt, weil es halt eigentlich genau diesen Zweck erfüllt, dass ich sehr genau sagen kann, wie soll mein Code aussehen, den das Projekt generiert? Grade wenn ich halt wirklich mit Contact genering Engineering arbeite, ist es ja sehr wichtig, ihm ihm genau Vorgaben geben zu können, er eigentlich am Ende erzeugen soll, ich aber zum anderen halt dadurch nicht meinen Kontext eben komplett aufblehe, indem ich halt immer diese gesamten Informationen mitschicken kann, sondern sich eben die AI sehr gezielt oder in dem Fall sehr gezielt eben die Informationen rausholen kann, die's grad zu der Bearbeitung von diesen Tasks dann braucht. Deswegen absolute Empfehlung, falls ihr früher zum Beispiel Skills genutzt hattet oder eben das Problem hattet, dass einfach das geteilte Projektwissen immer größer wurde, sind eine sehr gute Ergänzung, das son bisschen weiter aufzuschlüsseln und für sich oder für das Team zu organisieren. Also gerade im Teamkontext ist es super relevant. Cool. Ich
Dennis: hab zum Glück noch mal zwischendurch geguckt und festgestellt, dass wir meinen Pick schon hatten. Aber ist egal, ich frisch ihn noch mal auf. Suno AI, ein Tool, Musik zu generieren. Ich weiß nicht, also ich meine, das gibt's jetzt auch schon relativ lange, war am Anfang auch schon beeindruckend. So im Hintergrund sind immer wieder neue Versionen der Modelle dort rausgekommen und ich hab's jetzt gerade frisch wieder 'n bisschen eingespielt und es ist schon einfach beeindruckend die Qualität mittlerweile. Und man fühlt sich son bisschen als Nichtmusiker dann so mal in der Lage, so ein bisschen Stimmung und Flirrics und so ein bisschen rumzuschrauben und einfach wirklich ganz coole Songs da rauszuholen, die irgendwo Ja, wenn sie dann eine gewisse Persönlichkeit haben, auch eine gewisse Emotion oder so aus hervorrufen können, obwohl sie, ne, trotzdem einfach so generiert sind. Auf jeden Fall, ja, weiterhin ein Tool zu empfehlen. Ich glaube, Dave hat das schon mal als Pick, aber dann,
Jojo: ja. Ich hab auch das Gefühl, gerade die Fünfer Version ist noch mal deutlich besser geworden. Wo ich immer son bisschen dran scheiter selber als Musiker ist wirklich, damit Texte schreiben zu wollen. Mhm. Auf der Oberfläche ist es okay, aber wenn Du wirklich was Gefühl transportieren willst irgendwie eine Message, fehlt einem son bisschen, glaub ich, dann so die das Besondere daran. Also dafür wird's, glaub ich, immer noch nicht ausreichend, also in meinen Augen noch nicht ausreichend sein. Und gefühlt ist auch son bisschen, dass man natürlich nach dieser handgemachten Musik son bisschen mehr sucht, weil man natürlich feststellt, wie gut inzwischen diese Modelle werden, die einfach diese Musik generieren können. Ja, sehr viel im Band Kontext damit rumexfrontiert und mir festgestellt, am Ende will ich's doch vielleicht lieber von Hand machen, obwohl's noch mal die große Herausforderung ist natürlich 'n Man kann sich sehr viel Inspiration? Inspiration, das hat das Wort weiß gesagt, Inspiration suchen, erst mal zu gucken, in welche Richtung kann es gehen und das dann son bisschen ausarbeiten. Also dafür nutzen wir wirklich sehr viel. Mhm. Aber wirklich dann so fertige Songs.
Dennis: Ja, aber ist das nicht auch was an, also ich meine Musik machen als Prozess ist ja irgendwie auch was, was Spaß macht. Ja, genau. Also ich mein, das glaube ich ja jetzt, wenn Du nicht irgendwo damit ne produzierst oder Geld machst oder was irgendwas ne veröffentlichst, ist ja erst mal das auch irgendwie dieser Prozess oder das gemeinsam irgendwie Musizieren der der große Spaß, der glaube ich auch nicht weggeht, egal wie viel oder egal wie gut Du Musik produzieren kannst so. Das Spielen ist glaube ich trotzdem dann auch irgendwie was Magisches und was was Eigenes. Auch kurz geht's ja auch nur darum,
Jojo: Ja. In meiner Musik zu Und
Dennis: was bei Livemusik ja eigentlich auch so ist. Ich mein, egal, wo Du irgendwo auf 'nem Volksfest oder sowas vorbeikommst, aber ich mein, Livemusik ist einfach immer irgendwie cool, egal ob das jetzt dein Stil ist oder nicht, aber es hat irgendwie was anderes. Mhm.
Marcel: Julius, was würdest Du denn sagen, wo sind denn die Grenzen von, also in einem bestimmten Genre? Also Du hattest ja gesagt, na ja, wenn Du dann handgemachte Musik machst, tatsächlich wollte ich das jetzt in den nächsten Tagen auch mal ausprobieren. Also ich spiel auch Schlagzeug und Gitarre und ich bin gerade dabei, mir 10 Songs drauf zu packen und ich sitze auf 'ner Cajon auf sonem Trommelhocker und dann links und rechts, also mit den Füßen mache ich simuliere ich das Schlagzeug und spiel Gitarre und sing dabei so. Da schauen wir viel gleichzeitig, was Das ist das ist das ist auch viel schwerer, als das aussieht Ja,
Jojo: ich weiß. Wie das aussieht. Allein schon Sing und Gitarre spielen zu koordinieren ist schon schwierig.
Marcel: Dann auch mit dem, da da gibt's so was von Schlagwerk. Oder wir wir läuten uns jetzt rein. Ich ich wollte nur verstehen, wo seht ihr und vielleicht sagst Du auch Dennis, welche Chance Du ausprobiert hast, wo seht ihr da die die Grenzen? Also wo sagt man so, ah, das klingt schon wie aus der Dose oder so, weil ich ich hab's noch gar nicht gemacht und ich hab so was im Kopf. Ich wollt mal so Blasersätze ausprobieren und so, Streich hab Blazer. Und das wollte da wollte ich mir 'n bisschen Inspiration holen, also ich bin wieder dabei. Und deswegen nur die Frage, wo hört's, wo sind die Grenzen aus eurer Sicht? Was habt ihr gemacht? Wo sind die Grenzen? Die 2 Fragen?
Dennis: Also ist jetzt nicht so, dass ich mich mega intensiv mit dem Tool beschäftigt habe. Jetzt in den konkreten Use Case, hat es ganz gut gepasst. Also ich wollte, ich hoffe die Folie, die die, meine Frau hört die sowieso nicht die Podcastfolgen. Also ihr ihr Verlobungsring ist kaputt gegangen und jetzt hab ich hier zum Geburtstag, sie hat nächste Woche Geburtstag einen neuen Ring gekauft. Und ich dachte irgendwie, ist ganz schön das ganze musikalisch noch zu untermalen. Ich war damals so kitschig bei ihrem bei meinem Antrag, gab's damals 'n Onlinedienst, wo man sich Musik schreiben lassen konnte und das wurde in 'nem Studio eingesungen, also aus der Old School praktisch, aber ähnlich, ne. Also die hatten halt, die hatten ein paar so Standardgenres und dann konnte man das auswählen. Dann hat ihnen die Geschichte geschickt, die haben Lyrics dazu geschrieben und Du hast es abgenickt und dann haben sie das eingesungen und das habe ich damals als Teil der Verlobung und deswegen dachte ich, passt das irgendwie ganz gut in das heutige Zeit, als wenn wir jetzt 10 Jahre später, sie erstens den Ring erneuert bekommt und zum zweiten nicht das mit 'nem mit 'nem Song, der halt persönlich ist, das bekommen und sie ist ein sehr großer Fan von Leonard Cohen und diese Beschreibung, also ich nutze meistens irgendwie dann noch mal, obwohl, also Du hast ja irgendwie unterschiedliche Modi, Du hast son freies Textfeld, wo Du einfach sagen kannst, ne, das soll mein Song sein oder Du hast son Kreativmodus, wo Du sehr genau so, das ist der Style, das sind die Lyrics, das kannst auch mittlerweile Stimmen und so weiter reproduzieren, also dass die gleichen gleichen ähnlichen Stimmen sind. Und da kommt man dann schon, finde ich, relativ nah an diesen an an diesen Style und da hat der einfach sehr gut, das war, ja, also Du hörst an der ein oder anderen Stelle, auch weil die Lyriks dann nicht passen oder so, nicht perfekt vom Timing sind, hörst es, dass es mal hier und da 'n bisschen reingequetscht ist. Also Du hörst schon, dass es AI Musik ist, aber wie gesagt, so, also eine gewisse Immunalität kommt trotzdem schon rüber und ja. Und ja, ich glaub, die Limits, also wie gesagt, da bin ich nicht tief genug eingestiegen. Mittlerweile gibt's glaube ich auch bei Sono son kompletten son Studio nennt sich das, wo man die ganzen Instrumente aufteilen kann und kann Parts rauslöschen und neu generieren. Also Du kannst wirklich so ins Musik machen reingehen und nicht mehr nur ich und ein Ding brummte raus. Also die haben sich auch deutlich weiterentwickelt, aber so tief hab ich's gar nicht genutzt.
Marcel: Mhm.
Jojo: War's denn der Text, der Du nur damals irgendwie die hast schreiben lassen, den Du jetzt einfach hast vertonen lassen? Also
Dennis: Nee, nee, nee. Das war 'n neuer Text. Genau, das ist jetzt 'n neuer Text, der son bisschen diese Geschichte Weiterfalls. Von dem Ring und der Form des neuen Rings aufgreift und son bisschen.
Jojo: Und den hast Du auch mit Sono geschrieben?
Dennis: Nee, den hab ich mit geschrieben oder Chachuity Germany, glaube ich, Germany.
Jojo: Ja. Ja. Also das ist, glaube ich, im Reneson Und
Dennis: aber auch, sorry, und auch, aber gesagt, im Style von Leonard Cohen, ne, also weil das natürlich schon irgendwo eine gewisse Menik und kurze Sätze und so. Also das passt dann schon ganz gut zusammen.
Jojo: Ja. Ich glaub, weißt Du grade für so was, was Dennis dir beschrieben hat, Du möchtest irgendwie so, es ist ja schon was Ernstes, aber irgendwie son Song haben, der den Du jetzt nicht irgendwie aufhören willst, was von großem Publikum. Dafür ist es irgendwie absolut ausreichend und sagen wir auch von der von den Texten und Inhalten und Übergängen und Reimschämen, die halt irgendwie aufgegriffen war. Also die Reimschämen sind oftmals sehr, sehr einfach. Mhm. Also dass Du halt dort irgendwie jetzt keine komplizierten Musik mit irgendwie 'n Überhang von bestimmten Worten vielleicht auch auf nächste Zeilen irgendwie bekommst. Und grade wenn Du halt wirklich versuchst, damit Musik zu produzieren, die Du halt irgendwie auflegen willst oder die Du halt aufführen möchtest, merkst Du halt immer, es hat einfach nicht diese, ich will nicht sagen das Herz, aber weißt Du, so diesen persönlichen Bezug und vielleicht auch etwas, was so, es ist schon gut, wie er's macht, es ist aber sehr, sehr oberflächlich von dem, was bei rauskommt. Und natürlich eher vom musikalischen ist es natürlich sehr versiert, was er inzwischen so generieren kann, aber auch da merkst Du irgendwann, okay, es ist sehr, ich will nicht sagen monoton, also er kann sehr viele unterschiedliche Bereiche rausgerien, aber Du merkst halt schon, es ist nichts, was irgendwie 'n Künstler vielleicht so machen würde. Mhm.
Marcel: Das kann man
Jojo: auch nicht verallgemeine. Also inzwischen haben sich die Modelle sehr viel weiterentwickelt. Ich hab, wir haben so für uns festgestellt halt wirklich, da mit für uns wirklich Musik zu produzieren. Man kann das wirklich als Ansätze nehmen. Da nutz ich halt eher auch wirklich andere AI Modelle, halt wirklich Text zu brainstormen. Und da hab ich mir entsprechend einfach halt son Sub Agent angelegt, der halt einfach weiß, wie mach ich das richtig? Was sind die richtigen Techniken dafür? Mhm. Und dann nutz ich eigentlich Suno nur noch, halt diesen fertigen Text dann eigentlich zu vertonen, da halt in eine bestimmte Richtung dann einfach mal Vorschläge generieren zu lassen, wie könnte man das irgendwie auszugestalten? So ist dann mein Prozess. Es soll inzwischen auch besser gehen, direkt mit den Texten zu arbeiten. Hab ich noch
Dennis: Ja, wie gesagt, also genau, all die neuen Funktionalitäten hier drin sind, hab ich auch selbst noch nie benutzt.
Jojo: Aber die Stile,
Marcel: die die verschiedenen Stile, also ob ich jetzt, was weiß ich, eine eine Band wie nehme oder ob ich deaf Punk simuliere oder so, das klingt, also allein vom Sound her. Ich bin son son son, also ich kann an Sound, wie wahrscheinlich jeder, der sich irgendwie für Musik, also ich würde mich jetzt nicht als Musiker, ich spiel halt Musikinstrumente einigermaßen,
Jojo: wenn ich
Marcel: jetzt Musiker, weiß ich nicht. Sag mal ich bin der Musiker so. Ja. Und wie jeder Musiker bin ich da so im Sound verhaftet und sag dann, ah guck mal hier, das klingt richtig und das das muss auch genauso klingen, da da da da da da da da und ich stell mir das dann vor so von wegen, dass man schon dann noch son Unterschied hört oder sagt dir. Ja, absolut.
Dennis: Du hast nicht diese Fidelity, die Du in Studio aufgenommenen Songs hast oder so. Es ist immer noch 'n gewisser 'n gewisses, also nicht rauschen ist das falsche Wort, aber 'n gewisser Matsch so, ne. Du hast nicht die Klarheit 1 1 aufgenommenen, 1 aufgenommenen Instrumentes, so, ist mein Eindruck. Aber ja. Ich weiß nicht, ist vielleicht auch die falsche Annahme. Ich würde irgendwie vermuten, da kommt jetzt nicht so der nächste Nummer 1 Hit raus. Also das ist vielleicht der der Prozess, der son bisschen dann noch da oben drüber ist, aber es funktioniert halt, dass gängige Musik gut rauskommen soll, die man so kennt.
Marcel: Da gab's doch diesen Country Typen irgendwie, der Platz 1 der Billboard Charts geworden ist. Das das war son fiktiven Ja, war
Dennis: das son, okay, Kenn sein,
Marcel: ja, okay. Von dem, was ich weiß, ich hab mir das nur angehört auf Spotify und ich dachte, ja. Es klingt son, ja, ich glaub, das bildet man sich dann, das bildet man sich dann auch ein, dass das so matschig klingt, sodass er da irgendwie ist das so, da kommen da da ist es, da höre ich irgendwie so leichte Dinge raus, weiß ich nicht, aber war, klang natürlicher als ich gedacht hätte.
Jojo: Mhm. Ja definitiv.
Dennis: Marcel, hast Du auch noch einen Pick?
Marcel: Ganz schön lange
Dennis: über unseren über Suno geredet hier. Spezialfolge.
Marcel: Muss ich muss ich nur einen Pick oder kann ich auch mehr?
Dennis: Du darfst auch 2, weil Du Gast bist. Okay.
Marcel: Dann möchte ich auf der zum einen Image picken. Image, das schreibt man IMMICH ist eine Software, die man sich selbst hosten kann, seine Fotos zu verwalten. Ich bin sehr traurig, lange mit Apple Fotos durch die Gegend gelaufen und das ist eine Sache, wenn man einen NAS hat, dann kann man damit das wunderbar verwalten, ist webbasiert, hat eine Face Recognition, ach, mal was Deutsches zu sagen. Also Gesichtserkennung und funktioniert von dem, was was was ich da so für für Vorstellungen habe.
Dennis: Was ist der Main Selling Point gegenüber iCloud Fotos? Oder Fotos aufm
Marcel: auf Ich. Auf Fotos ist so, bei bei Apple Fotos ist es ja so iCloud Fotos, hab ich überhaupt keine Ahnung von. Ich möchte nicht, dass meine, dass meine Fotos irgendwie bei bei Apple landen.
Jojo: Gut.
Marcel: Das ist erst mal der der Hauptfokus, ne. Also dass ich sage, ich hab das auf meinem Nas. Mhm. Da ist es drauf und fertig ist die Kiste. Mhm. Und dann ist
Jojo: es
Marcel: auch webbasiert, was es ja bei Apple Fotos nicht der Fall ist, weil wenn ich das offline benutzen möchte, dann renne ich durch die Gegend mit 'ner SSD und so weiter. Und das fällt dann auch flach, weil das einfach webbasiert ist. Ja, und das wars auch schon. Reicht mir aber dicke.
Jojo: Ja, okay.
Dennis: Aber ja. Muss auch kein Sellingpoint für mich sein, aber ich kenn's zumindest in Apfel. Okay. Ja.
Marcel: Das ist diese dieses Privacy Gedöns.
Dennis: Ja, Datenschutz hab ich's nicht so mit.
Jojo: Okay. Alles klar.
Marcel: Und jetzt muss ich mich entscheiden, ich hab nämlich noch 2 andere. Dann nehme ich tatsächlich auch noch was, nee, ich nehme das zweite. Und zwar würde ich noch NYXOS picken. NYXOS weiß ich, ob ihr, habt ihr schon mal davon gehört? NYXOS ist eine Linux Distribution, die mit 1 bestimmten Sprache beschrieben werden kann. Also wenn wenn man heutzutage hingeht und installiert ein Debian und hatte noch Ansible Playbooks beispielsweise und professioniert das irgendwie, es auch die Möglichkeit, das auf Basis von nix zu machen. Da gibt es eine bestimmte Sprache, die erinnert mich immer 'n bisschen an Elixier und Ruby. Obwohl's wo's geschweifte Klar, Klammern gibt ist ja wurscht, Aber man beschreibt letzten Endes seine Installation innerhalb von 1 Sprache. Das hängt direkt am Betriebssystem, das ist der Vorteil aus meiner Sicht im Vergleich zu Ansibel und Debian beispielsweise, sondern die Linuxsubstanz ist tatsächlich so, dass die Packages auch in dieser Sprache beschrieben sind. Und dass man sagen kann, ich hätte gerne meine Post Quest Datenbank und ich hätte gerne, was weiß ich, meine meine Engine X Installation. Ich hab da beispielsweise son Ackoma drin, das ist son Masodon Klon und NXOS bietet einfach die Möglichkeit zu sagen, ich hab meine Konfiguration, ich wende die an, ich kann das auf ich kann das wiederholen und ich hab nicht 2 Technologien, die irgendwie ineinandergreifen müssen und die fremd sind, sondern die tatsächlich aus einem aus einem Guss kommen.
Jojo: Mhm.
Marcel: Nix OS.
Jojo: Nachteil ist vielleicht son bisschen, ich muss halt alles auch sozusagen in dieser Konfigurationsdatei beschreiben. Es ist dann mein komplettes US. Also ich glaub, das ist nur das, was ich so gelesen habe. Es kann sehr auf seinlich sein, sich erst mal sozusagen sone erste Konfiguration zusammenzustellen. Die Leute, die's, glaub ich, dann gemacht haben, die schwören drauf und sagen, es ist einfach cool, dass Du so alles in der Hand hast, alles so plane dann eigentlich irgendwie runtergeschrieben, irgendwie dir anschauen kannst, wie dein System irgendwie konfiguriert ist und
Marcel: Also ich würde auch die Unterscheidung machen oder die Unterscheidung treffen, dass ich das nicht für mein Desktop System benutzen würde. Ich mach das deswegen so, weil ich bestimmte Server konfigurieren möchte und ich später auch noch wissen möchte, was hab ich da gemacht? Es gibt Leute, die schwören darauf mit, ah ja, ich hab hier meine ganzen verschiedenen Rechner et cetera. Da dafür halte es halte ich's einfach zu aufwendig. Also das würde ich nicht machen, Aber gerade wenn's Provisionieren geht von 1 Sache, die Du vielleicht in der Cloud auch hast, die Du noch mal neu aufbauen möchtest et cetera, da ist das eine eine gute Geschichte, weil Du's eben nachvollziehen nachvollziehen könntest. Und mir geht's meistens, wenn ich so Dinge tue, geht ja auch in in die Nachvollziehbarkeit. Mhm. Und deswegen halte ich das für eine gute Idee. Ja. Aufm Desktop würd ich's für mich nicht einsetzen.
Jojo: Mhm.
Dennis: Cool. Vielen Dank.
Marcel: Danke auch.
Dennis: Marcel, sehr cool, dass Du heute hier warst und uns bereichert hast mit dieser Folge über App. Wenn ihr da draußen Feedback habt, schreibt uns wie immer gerne an Podcast at Programmier Punkt bar. Juju, schön, dass Du mal wieder dabei warst.
Jojo: Okay, schon mal wieder dabei gewesen zu sein.
Dennis: Euch allen einen guten Start ins neue Jahr, je nachdem, wie diese Folge rauskommt, aber bestimmt irgendwann eher am Anfang des Jahres. Von daher genau, alles Gute für 20 26. Bis dann.
Marcel: Tschau. Tschüs. Tschau.