Transcript
[0:00] Ich hab von 2001 bis 2008 JavaScript gemacht. Da hatten wir nur noch keine Types, das war in der Anderthaler Zeit.
Nur da ist Typescript ein Riesenfortschritt.
Das ist schon schön, dass ich meine Types, meine Rückgabewerte hab.
Das hat aber den Sinn, dass erst mal eine Methode fertig werden muss, und dann kann die das weitergeben an die nächste, oder?
Genau. Genau. Das ist doch so die Grundidee dahinter. Genau, die Grundidee ist, weil Rust so low-level ist, möchtest du verhindern, zeitig irgendwas editieren können zum Beispiel.
[0:30] Music.
[0:55] Revision 583, Diese Revision von Working Draft wird euch präsentiert von Hörerinnen und Hörern wie euch. Auf patreon.com slash working draft könnt ihr uns ein paar Euro in den Hut werfen. Aus, euren Beiträgen und unseren gelegentlichen Werbeeinnahmen bezahlen wir allerlei teure Software-Abos und das Honorar unserer Audio-Producerin. Wenn ihr euch auch beteiligen wollt, könnt ihr das unter patreon.com slash working draft sehr gerne machen. Wir danken Wir bedanken euch tausendfach für die Unterstützung und fürs weitere Zuhören.
Wir sind heute zu dritt.
Revision 583: Kann man Rust für Cross-Plattform Frontend-Entwicklung verwenden?
[1:29] Da hätten wir aus dem Team einmal den Hans. Hallo.
[1:33] Ich bin der Shep und das bedeutet, wir haben wieder einen Gast da.
Und zwar den Benedikt der Hechte aus Hamburg. Grüß dich. Hey.
Hi. Bevor wir in unser Thema heute eintauchen. Du warst noch nie Gast bei uns.
Da würden wir dich fragen wollen, ob du dich mal ganz kurz unseren Hörerinnen und Hörern vorstellen magst.
Klar. Hi, ich bin der Benedikt. Ich hab 2001 oder so mit Webentwicklung angefangen, bin aber dann 2008 mit dem Aufkommen vom iPhone zu iOS, MacOS und so weiter gewechselt.
Und so seit 2017 versuche ich, mich davon wieder wegzubewegen, was aber nicht ganz so einfach ist.
Und mache seitdem Rust, wenn es halt so passt. Und jetzt gerade bei der Arbeit, wenn immer sich eine Möglichkeit eröffnet, wo ich halt nicht iOS machen kann, nutze ich sie. Zum Beispiel habe ich jetzt seit zwei Monaten so ein Typescript-Projekt.
Und das Ganze halt so ein bisschen, weil das iOS-Tooling mir wirklich gar nicht gefällt.
Und da versuche ich halt so ein bisschen zu schauen, was kann man stattdessen machen.
Und in meiner Freizeit entwickle ich halt viel Desktop-Anwendungen und Frontend-Anwendungen in Rust.
Und dazu kommen wir sicherlich vielleicht auch noch zu gehört, auch im Master und Client zum Beispiel.
Klingt sehr gut. Ich glaube, der Hans, der will fragen, was du an den Mac-Dev-Entwicklungsumgebungen Umgebung nicht so gut findest.
[2:55] Wir sprachen in der Vorbesprechung drüber, deswegen. Es ist auf jeden Fall immer interessant zu hören, was läuft eigentlich gut in der einen Plattform und auf der anderen nicht oder so.
Und wir haben ja grundsätzlich immer über Web-Tooling immer viel zu sprechen.
Aber dann ist auch mal interessant zu hören, was ist denn eigentlich bei iOS so los?
Warum findest du das doof?
Also, es gibt wie bei allem immer viel Gutes und viel Schlechtes.
Und das, also was für mich das störendste Problem ist, Bei Apple kommt ja alles aus einem Guss.
Und dazu gehört eben auch diese Entwicklungsumgebung, dieses Xcode.
[3:30] Und eine Entwicklungsumgebung zu bauen, die von der Komplexität mit IntelliJ zum Beispiel hinterherkommt, ist halt schon aufwendig.
Da fällt halt viel Zeit rein.
Neuerdings, in den letzten zwei, drei Jahren, gibt's wahnsinnig viele Tools, die man in seine Entwicklungsumgebung laufen lassen kann, so die Copilot zum Beispiel.
Oder andere, die einem das Entwickeln einfacher machen Und Xcode bietet das alles nicht.
Und hat auch kein Plugin-Interface.
Ich als Entwickler, was ich den ganzen Tag mache, ist ja, ich schreibe größtenteils Code oder ich lese Code, oder ich editiere Code.
Und da ist Xcode sehr nah an so einem Notepad von Windows. Also, die Autocompletion-Failure schlägt regelmäßig viel.
Du kannst Symbole nicht resolven. Du kannst nicht nach Symbolen suchen, das schlägt regelmäßig viel.
Es gibt Wim-Bindings, die sind wahnsinnig schlecht. Und für mich als alter Unix-Nerd ist es jedes Mal wieder frustrierend, Und das heißt, eine Anwendung starten, im Simulator laufen lassen, das ist eigentlich ganz cool und das funktioniert auch gut.
Der Debugger ist wirklich gut, aber das mache ich ja nicht den ganzen Tag.
Den Großteil der Zeit bin ich damit beschäftigt, Code zu editieren, Code zu lesen und Code zu schreiben.
[4:39] Genau dieser Prozess ist wahnsinnig schlecht und ich würde einfach gerne zu VSCode wechseln, das geht aber nicht.
Und ja, dann muss man halt eben was anderes ändern.
Und für mich ist es dann halt schön, regelmäßig mal ein Projekt zu machen, was ich in VSCode oder so machen kann, weil dann kann ich mich wirklich aus Programmieren fokussieren und ärgere mich nicht die ganze Zeit daran, dass das Tooling-Haltgefühl von 2010 ist.
Ja, das ist natürlich verständlich. So was ist sehr ärgerlich, wenn der technische Fortschritt auf der einen Seite irgendwie davon galoppiert, aber man selber irgendwie so hinten dran ist.
[5:10] Du hast es angesprochen, es hat viele Vorteile, die Xcode-Umgebung zu nutzen, Simulator und ähnliches.
Gibt es denn überhaupt Möglichkeiten, Simulator, auch beispielsweise mit einem anderen Editor, wie jetzt, du hast eben VS Code angesprochen, zu nutzen?
Du kannst, es gibt so Open-Source-Projekte, mit denen du im Terminal den Simulator steuern kannst.
Und du kannst auch die Builds im Terminal machen. Also sagen, ich hab jetzt irgendwie ein Projekt, was ich mir geschrieben hab.
Das nutzen halt auch so Sachen. Es gibt ja so Projekte, mit denen du Cross-Platform-Frameworks hast.
Und die nutzen halt auch dieses Tooling, um dein Simulator zu laufen zu lassen.
Es gibt auch ein VS Code-Plugin für Swift.
[5:51] Das funktioniert aber nicht so gut. Es ist halt alles so nicht gut, also noch schlechter als Xcode.
Es funktioniert, aber es ist nicht besser.
Und nicht irgendwie ein bisschen besser, sondern ein bisschen schlechter eher.
Und dann kommt man da halt auch nicht viel weiter mit.
Ja, klar. Und irgendwann muss man sich dann auch mal entscheiden, so lebe ich jetzt weiterhin damit und mache iOS-Entwicklung oder man macht es wie du und du sagtest gerade, machst TypeScript.
Wie ist so dein Eindruck von TypeScript? Also, die Art und Weise zu entwickeln und diese superschnelle Feedback-Loop zu haben, ist natürlich total toll im Vergleich zu allem, was ich bei iOS habe.
IOS versucht das auch so ein bisschen, und bei Rust habe ich es auch nicht, dass ich halt was schreibe, ich speichere und ich sehe dann den Output.
Das habe ich bei Rust nicht, weil da muss ich halt kompilieren und muss jetzt möglicherweise von Hand starten.
Das habe ich bei iOS auch, und für beide Sprachen gibt es halt auch so Facilities, die das so halbgar ermöglichen, aber halt so gut wie bei JavaScript, TypeScript ist es natürlich nicht.
Und ich hab ja wie gesagt von 2001 bis 2008 JavaScript gemacht.
Da hatten wir nur noch keine Types, das war nur noch in der Anderthaler Zeit.
Nur da ist TypeScript natürlich ein Riesenfortschritt.
Also das ist natürlich schon schön, dass ich ja meine Types, meine Rückgabewerte hab.
Also ich find's gut.
[7:04] Mir würden halt höhere Types noch mehr gefallen. Also im Vergleich zu Rust ist es natürlich schon so, dass es halt ein bisschen an der einen oder anderen Stelle fehlen mir halt spezifische Types.
Zum Beispiel der Rust-Enum, der ja so ein bisschen in TypeScript aufgeteilt ist, in den Enum und in so einen Union. Das ist halt bei Rust ein Ding und der ist deutlich expressiver.
Da kann man halt schon mehr mitmachen und den nutze ich halt sehr viel.
Und das sind so Sachen, das ist okay.
Das ist aber halt bei Rust noch ein bisschen typesafer, würde ich sagen.
Aber ich meine, im Vergleich zu JavaScript ist es natürlich weltenbesser.
Ja, und Rust ist ja auch dann sozusagen die Sprache, die du dir eher ausgesucht hast, also TypeScript läuft jetzt zwar nur so nebenher, aber du hast halt relativ viel in den letzten Jahren auch mit Rust gearbeitet, ne?
Wir hatten ja, glaube ich, eine Revision, ich weiß nicht genau, welche Nummer, aber vor ca. einem Jahr, da haben wir über Rust im Backend gesprochen, und du sagst es ja in der Vorbesprechung auch, Gerade mit deinem Mastodon-Client hast du dich ja auch viel damit beschäftigt.
Wie bekommt man eigentlich Rust-Code, den man in den Frontend reinbringt?
[8:15] Was waren da so deine Findings? Ich finde also, das Thema an sich finde ich halt spannend.
Weil in der klassischen Welt von vor 5 oder 6 Jahren war es halt so, du hattest eine iOS- oder eine Android-App.
[8:27] Und dann stellt sich natürlich die Frage, nutze ich sowas wie React Native oder nutze ich sowas wie Flutter, teile ich Code oder schreibe ich 2 native Apps?
Ähm, und wenn du aber jetzt sagst, okay, ich versuche, Code zu teilen, dann hast du ja keinen 200-Prozent-Gewinn.
Weil du hast natürlich ein bisschen zusätzlichen Code, den du schreiben musst für diesen geteilten Code.
Du hast pro Plattform noch so ein bisschen Aufwände, die du machen musst.
Das heißt, du gewinnst vielleicht 150 Prozent Zeit dadurch. Also, du gewinnst ein bisschen mehr, aber halt nicht das Doppelte.
[8:58] Und wenn man aber jetzt noch Linux und Windows und MacOS hinzunimmt dann hast du auch mal fünf Plattformen, und dann ändert das natürlich die Gleichung total.
Und dann stellt sich halt die Frage, wie kannst du einmal Code schreiben, gerade Logik-Code, bei dem du halt auch irgendwie Bugs haben kannst und so weiter, und den auf jeder Plattform verwenden?
Und da finde ich halt Rust spannend, weil es eben keine native ...
Es hat keine Heimat, ne?
Also, so Swift ist so eine Sprache, die läuft super am Mac, woanders geht's so.
Und, ähm, Kotlin ist eine Sprache, die läuft super unter Android und auch sicherlich einigermaßen gut unter anderen Plattformen, aber Rust hat halt keine richtige Heimat, wo es herkommt. Das läuft halt überall gut.
Und ist auch für alles optimiert. Und dadurch ist es halt so ein bisschen spannend zu sagen, okay, man könnte seine Logik da schreiben.
Und dann, NuVic macht man dann weiter. Also macht man das komplett in Rust oder macht man Teile davon in einer anderen Sprache und da experimentiere ich so ein bisschen drum.
Und bei diesem Mastern und Client habe ich dann wirklich die ganze App in Rust geschrieben.
Das Desktop-App läuft jetzt Linux, Windows, macOS und iPadOS zurzeit.
[10:04] Und theoretisch auch im Web. Aber da sind ein paar Dependencies, die ich noch pt'n müsste.
Halt alles aus einem Guss. Und das war auch total spannend.
Hat aber auch eben seine Nachteile. Weil es halt schon schwierig ist, die ganze Interaktion, die du auf einer Plattform haben kannst, mit...
Die einen User halt so hat, die halt über so ein generisches Interface abzubilden.
[10:28] Das ist, glaube ich, dieser spannende Punkt, über den man halt so bei so generischen Ansätzen ganz viel sprechen muss. Ich denke jetzt so als allererstes irgendwie, du willst irgendwie eine inner purchase machen, ja? Und dann hast du halt auf iOS spezifische Interfaces, die du ansprechen musst. Und der Art und Weise, wie das ja unter iOS funktioniert, ist ganz anders im Vergleich zu wie funktioniert das mit einer, mit der Google API sozusagen, also praktisch unter Android dann.
Oder wie funktioniert es auch mit Huawei, die sich ja dann mit der Android-Applikation dann vielleicht wieder ein bisschen mehr alignen?
[11:09] Wie abstrahiert man sowas? Kann man das überhaupt abstrahieren?
Bei React Native abstrahiert man das ja mit diesen Native-Plugins, wo du halt dann ein bisschen Kotlin-Code hast, und dann hast du ein bisschen Swift oder Objective-C-Code.
Und dann musst du halt darauf vertrauen, dass irgendjemand das Ding halt immer aktualisiert, wenn sich die APIs ändern.
Und das ist, glaube ich, der zurzeit so ein bisschen die beste Lösung.
Und ich glaube, ähnlich wird das ja auch bei Expo verwendet.
Dass man halt wirklich einfach sagt, wir haben halt unsere Plugins, da musst du aber darauf vertrauen, dass es da jemanden gibt, der das macht.
Der halt da irgendwie diese Sachen baut, der die regelmäßig pflegt, der da keine Bugs in seiner Implementierung hat, in seiner Portierung.
Und bei dem, was ich jetzt gemacht habe, habe ich halt den Code selber geschrieben in Objective-C oder in Rust und hab ihn halt dann entsprechend in der App gehostet.
Was aber hin dazu führt, dass die App am Mac einfach deutlich besser ist als unter Linux.
Oder unter Windows, weil ich am Mac halt einfach weiß, was ich mach und wie ich da halt die zusätzlichen Facilities nutze.
Und bei Windows müsste ich dann irgendwie diese Windows-32-API nutzen.
Versteh ich kein Wort. Und das guck ich mir halt auch nicht an. Ja.
[12:18] Ja.
Also ich glaube, eine richtig gute Lösung gibt es da tatsächlich nicht, weil du entweder darauf vertraust, dass jemand anders etwas für dich portiert oder du musst es selber machen, aber dann hast du halt auch deine eigenen liabilities.
Ja, das ist halt so ein bisschen das das das Thema irgendwie, wo man halt dann schaut, also wenn man das alles selber schreibt auch, dann ist man halt wieder bei dieser Rechnung, hat man dann noch diesen starken Gewinn, den man sich eigentlich.
[12:44] Sozusagen erhofft, wenn man halt einmal für alle Plattformen schreibt, wenn aber so wichtige Dinge, die vielleicht, keine Ahnung, 50 Prozent deiner App ausmachen, halt dann doch wieder nativ für jede Plattform sind, dann muss man sich das wieder draufschärfen.
Was sind denn dann die Teile, die man gut teilen kann vielleicht auch?
Also, was ich so ein bisschen festgestellt habe, was halt richtig gut funktioniert, ist, wenn du eine native App hast, Und du bindest halt dann, weil du kannst ja Rust zu WebAssembly kompilieren oder halt zu nativen Libraries.
Und so ein natives Library kannst du halt in so eine Android-App reinladen, das kannst du in eine Swift-App reinladen, in eine Linux-App.
Und dann hast du quasi deine ganze Logik in diesem Library und hast dann so einen, ich sag mal, so einen Event-Enum, der aus dem Library zurückkommt und der sagt dann halt deiner Native App, was sie zu tun hat.
Und das ist halt eine ziemlich gute Abstraktion, weil du dann halt, du brauchst natürlich immer noch einen Native-Entwickler, aber halt keine 10 vielleicht, und dann hast du halt eine relativ lightweight Container, das ist eine Native App, die malt halt das UI, und wenn zum Beispiel Inner Purchase, wenn halt dann der RAScode sagt, für diese Handlung mache ich jetzt einen Inner Purchase mit diesen und jenem Parametern, dann macht die Native App das halt.
Und wenn du das geschickt aufteilst, dann hast du sogar eine Struktur, die du vielleicht wiederverwenden kannst. Also ich glaube, das ist so ein bisschen die attraktivste Möglichkeit.
[14:10] Aber das macht natürlich auch nicht für jedes Projekt Sinn. Je nachdem, das ist so die Schwierigkeit bei diesem plattformübergreifendem Entwickeln, ist halt die Frage, die Anwendung, die ich hier entwickle, was macht hier überhaupt Sinn?
Da ist eine generische Antwort schon fast unmöglich, würde ich sagen.
Mhm.
[14:30] In meinem Kopf ist es halt irgendwie so, wenn man so sehr viel Anzeigelogik hat, sag ich mal, die halt irgendwie sehr generisch darstellbar ist, ne? Also, Mastodon Client nehmen wir mal als Beispiel.
Du willst eine Timeline darstellen irgendwie.
Du willst bestimmte Aktionen haben, wie jetzt jemandem folgen oder ähnliches.
[14:51] Das ist wahrscheinlich sehr gut abstrahiert darstellbar, stelle ich mir das so vor.
Ja. Also, in diesem Fall habe ich ein Rust-Framework genommen, das heißt Dioxys.
Und was die halt machen, das ist so wie React, aber komplett in Rust implementiert.
Die haben dann auch einen Virtual DOM, das ist komplett in Rust implementiert.
Mhm. Und wenn also dann, sagen wir mal, dein UseState geupdatet wird, dann berechnen die halt, was muss tatsächlich im DOM überhaupt noch aktualisiert werden.
Und dann haben die so einen Interpreter in TypeScript, der dann nur noch die minimalen DOM-Updates quasi an ein Webview gibt.
Und der wird dann aktualisiert. Und dadurch hast du halt den Vorteil, dass die ganze...
Was Performance-aufwendig ist, passiert halt eben im Rust-Teil.
Und im WebView wird dann wirklich nur ein ganz kleiner Patch applied normalerweise für die meisten Aktionen.
Und das hat so ein bisschen den Vorteil, dass du halt sehr performant, also du hast halt das React-Modell, aber du hast halt irgendwie eine unglaubliche Performance.
Also die kommen halt dann zu der JS ran, weil eben die so viel von dieser Abstraktion halt drübergeholt haben in Rust, aber gleichzeitig ist es genauso ergonomisch wie React quasi.
Das ist eine ganze Taktik.
[16:11] Also, klingt auf jeden Fall so ein Stück weit auch wie halt so das Virtual DOM halt auf React-Seite, ich glaube, früher gearbeitet hat.
Ich weiß gar nicht, ob die das heute immer noch genauso updaten.
Gab's irgendwann mal ja so einen, ich glaube, anderen Algorithmus, wie die das machen.
Aber da bin ich jetzt auch kein Experte für. Was halt spannend ist, ist halt, dass man dann ja als jemand, der halt das Frontend baut, im Endeffekt alles in Rust schreiben muss. Das heißt, man muss halt dann sich Rust draufschreiben, kann aber dann diese Vorteile halt nutzen, die man halt durch den Mechanismus, wie du ihn eben beschrieben hast, so, ja, hat.
Indem man halt für mehrere Plattformen gleichzeitig arbeiten kann.
Genau.
[17:03] Wie war das für dich, Rust zu lernen, als jemand, der eigentlich aus dem Objective-C- oder Swift-Kontext kommt?
Ich glaub, jetzt kommt etwas, was man schon oft gehört hat, fürchterlich.
Ähm, also, es ist halt so, Swift und Rust sind sich als Sprache total ähnlich.
Also, die verwenden dieselben Konzepte, der Enum funktioniert genauso, die Generics funktionieren genauso, das sind halt wirklich sehr ähnliche Sprachen.
Aber Rust hat halt eben diese zusätzlichen zwei Dinge. Es hat dieses Ownership-Modell, Das hat Zwift inzwischen auch bekommen, aber in eine einführendere Art und Weise.
Und es hat diese Lifetimes. Und diese Lifetimes machen es einem wirklich, wirklich schwer am Anfang.
Weil das auch kein Konzept ist, was man jetzt auch aus der anderen Sprache so kennt.
Das muss man erst mal lernen. Aber selbst wenn man es gelernt hat, heißt es halt nicht, dass man es auch verstanden hat und anwenden kann.
Und ich hatte einfach so viele Fälle. Und das Schlimmste dabei ist, dass du ...
Der Rust-Compiler geht in zwei Stufen vor. Der guckt halt erst, ob alles syntaktisch okay ist.
Und wenn dann alles okay ist, dann sagt er, so jetzt gucke ich mir mal die Lifetimes an.
Und wenn du halt eine Änderung machst, jetzt hast du eine etwas größere Codebase, dann wühlst du dich einmal durch deine ganze Codebase.
Du änderst irgendwie an 120 Stellen zwei und änderst den Code, bis dann alle Fehler weg sind. Und dann kommt er aber mit 500 Lifetime-Fehlern.
Weil die Idee, die du anfangs hattest, die funktioniert so nicht.
Aber das sagt er dir halt erst, nachdem du an allen Stellen alles geupdatet hast. Dann bekommst du die Information, dass dein Code gar nicht funktionieren kann.
[18:27] Willst du noch mal ganz kurz sagen, was das Konzept der Lifetimes ist?
Oder vielleicht auch der Ownership? Beide?
Ähm, klar, ich würde mit dem Ownership anfangen. Der ist, wie ich finde, einfacher zu verstehen.
Der Ownership ist halt einfach nur die Idee, dass eine Variable jemandem gehören kann.
Das bedeutet, als ganz einfaches Beispiel, du legst einen Integer an, hat den Wert fünf, und jetzt suchst du eine Methode auf, die heißt Hallo, und du übergibst halt diesen Integer, die Variable A, die den Wert fünf hat, und danach ist sie weg.
Weil die Methode, in dem Moment, wo du die Methode aufrufst und diesen Wert übergibst, ist es so ein bisschen so, als wenn du ihn da reinlegst und in die Methode, und er kommt nicht wieder raus, diese Variable.
Denn sie ist jetzt quasi aufgegessen. Ich seh das immer so ein bisschen so, Funktionen sind kleine Monster, die essen ihre Parameter auf.
Und das ist halt ownership. Und das hat aber den Sinn, dass irgendwie nicht alle möglichen Methoden zugleich auf so einer Variablen rumwursten, sondern dass erst mal eine Methode fertig werden muss und dann kann die das weitergeben an die nächste, oder?
Genau. Genau. Das ist doch so die Grundidee dahinter. Genau, die Grundidee ist, weil Rust ja so low-level ist, möchtest du halt verhindern, dass zwei Methoden gleichzeitig irgendwas editieren können, zum Beispiel.
[19:43] Und das ist halt auch einigermaßen einfach. Und du kannst halt dann aber eben auch Referenzen vergeben.
Du kannst halt dann sagen, diese Variable in die Methode zu geben, und sie ist dann weg, kannst du halt auch nur eine Referenz, also verleihen quasi, kannst sagen, ich geb diese Variable weiter, dann kannst du sie aber eben nicht editieren, wenn du sie halt nur verleihst.
Und dann ist sie so ein bisschen daran gebunden, dass du sie ja woanders noch hast.
Und dann musst du so ein bisschen Rust-Compiler versichern, dass das Original dieser Variable, dass die halt so lange bestehen bleibt, wie diese Methode halt auch immer irgendwas damit macht.
Und das ist dann so ein bisschen die Lifetime, Dass du halt sagst...
[20:22] Du kannst es dieser Methode nur geben, solange die Methode nicht länger benötigt, als der Code, wo sie herkommt.
Das heißt, wenn du in deiner Methode einen Thread aufmachst und da irgendwas machen willst, das geht halt nicht, dann sagt der Rust-Compiler, das kannst du aber jetzt nicht machen, weil ich weiß ja gar nicht, wie lange dieser Thread jetzt mit dieser geliehenen Variablen darum experimentiert ist.
Bis dahin kann die Stelle, wo sie herkommt, die Variable ja nicht mehr da sein.
Und bei einem Garbage-Collector hast du das natürlich nicht, weil der kümmert sich da, aber Rust hat eben keinen Garbage-Collector.
Und die Schwierigkeit bei Lifetimes ist dann eben, dass du manchmal Situationen hast, wo du eine Variable hast, die wird dir übergeben als Referenz, du wirst sie noch mal für anders verwenden, und jetzt ist es aber so, du musst dann dem Rust-Compiler den Proof geben, dass diese Variable lange genug überleben kann, aber sie kommt ja schon woanders her.
Und dann musst du halt das irgendwie alles nachweisen.
Und das ist halt manchmal sehr, sehr schwierig. Und gerade, sobald es um Threading geht, und um Async-Await ist es richtig schwierig.
Weil da implizit ja Threads gemacht werden, oder halt Green Threads, und da sind die Lifetimes halt tatsächlich echt manchmal so ein bisschen ein Nightmare.
Und was man dann halt einfach macht, ist, dann legt man stattdessen Kopien an. Das ist viel einfacher.
[21:39] Ja, vielen Dank für die Erklärung. Kann man gut verstehen. Vielleicht nach dem kleinen Ausflug da auch noch mal in die Interne Wenn wir noch mal zurückkommen zu dem Cross-Platform-Client, man möchte jetzt irgendwie den bauen.
Wieso sollte man sich denn vielleicht auch überlegen, Rust so mit in die Verlosung zu nehmen?
Ich meine, wir haben schon Flutter angesprochen, React Native, ja, gibt's ja.
Also warum ist Rust dann ein valider Partner daneben sozusagen?
Also ich glaube, so React Native und Flutter haben so ein bisschen ein anderes Ziel.
Weil da wird dir die komplette Anwendung abgedeckt.
Und da läufst du so ein bisschen eben in dieses Problem, dass du sicherstellen musst, dass es ein Plugin für deine Kamera gibt, was gut funktioniert.
Ich hatte jetzt ein Flutter-Projekt letztes Jahr. Und da gab's auf der Android-Seite kein vernünftiges Kameramodul, was die Funktionen hatte, die wir brauchen.
Und dann mussten wir dann ein Kotlin-Plugin schreiben und so was.
Und dann hast du jetzt schon zwei Sprachen in der Codebase. Und der Vorteil bei Rust ist, dass du ...
[22:48] Solange wie du nicht alles damit schreibst, sondern halt nur gewählte Funktionalitäten, wie gesagt, und immer noch so einen Native Core hast, bei dem du viel machst, kannst du dir sicher sein, dass das hoch performant ist.
Da der Rust-Compiler so genau ist, ist die Anzahl, dass du denkst, welche Bugs das hat, auch sehr gering.
Und es gibt gute Projekte. Zum Beispiel gibt es eins von Mozilla, das heißt Unify, die dir automatisch aus seinem Rust-Code Libraries für Android und iOS jetzt machen oder für Windows, glaube ich.
Und das heißt, du musst dich jetzt nicht damit auseinandersetzen, jetzt habe ich diesen Code, wie mache ich denn daraus was anderes?
Und das Abstraktionslevel ist eben nicht eine komplett andere App mit anderen Developer-Tools.
Du hast halt immer noch Xcode, du hast immer noch IntelliJ. Du teilst halt nur deinen Code zwischen den unterschiedlichen Plattformen, also deine Logik. Und das ist so ein bisschen, glaube ich, ein vorteilhafter Weg.
Ist natürlich nicht das, was ich bei diesem Master-on-Client gemacht habe, Aber da ging's mir auch darum, Erfahrungen zu sammeln.
[23:49] Lass uns noch schnell sagen, wie der heißt. Ich glaub, das haben wir noch gar nicht gemacht. Der heißt EBU.
Genau, und den hast du auch für alle denkbaren Plattformen am Start, ne? Ja, so ein bisschen.
Also, der läuft halt am besten unter MacOS, weil das nutze ich halt nativ.
Dann unter Windows hab ich ihn einmal gestartet, dann bin ich wieder rausgegangen.
Da halte ich mich nie lange auf.
Unter Linux läuft das auch, da ist es natürlich so, je nach Distribution muss man wissen, welche Pakete man installiert und so weiter.
Ich glaub, es gibt in der Readme Erklärungen für Debian, für Ubuntu logischerweise, für Arch und für noch irgendwas.
Da verliert man noch schnell den Überblick.
Und es läuft halt auch am iPad, aber so halb gar. Da hab ich jetzt einen Branch, der noch nicht fertig ist.
Also da läuft's, aber nicht gut.
Und da will ich aber nach und nach das dann noch optimieren.
Ich hatte jetzt im Sommer auch nicht ganz so viel Zeit, da reinzuschauen, seit das neue Zelda erschienen ist.
Oh ja, ja. Priorität. Lach mal.
[24:51] Dann hast du dich entschieden, genau diesen Client zu schreiben.
Du hast ja schon gesagt, hauptsächlich auch, um herauszufinden, kann man eigentlich Rust dafür so verwenden.
Was hast du denn sonst noch irgendwie für Vorteile festgestellt während der Entwicklung? Also, was hat dich überrascht vielleicht auch?
So ein bisschen überrascht hat mich, also, was heißt überrascht, aber was natürlich schon schwieriger ist, ist, dass, wenn ich jetzt so den React-Type-Written-Script-Vergleich nehme, Da ist es sehr angenehm, Komponenten zu definieren, weil du dich nicht mit Memory Management herumschlagen musst.
Und das nimmt einem dieses Dioxys halt auch ab, aber nur bis zu einem begrenzten Level.
Ab und zu gibt's schon Situationen, wo der Rust-Compiler sagt, das will ich jetzt aber nicht, weil ich da die Lifetime, wir hatten das Thema, nicht berechnen kann, und jetzt weiß ich nicht, wem das hier gehört.
Und das ist ein Context-Switch, der tatsächlich in der UI-Entwicklung sehr unangenehm ist.
Weil in dem Fall möchte ich ja quasi grade eine Struktur definieren und sehen, wie es im UI aussieht.
Und jetzt muss ich mir plötzlich Gedanken darüber machen, wo denn dieser Speicher hinkommt.
Und das ist so, das hatte ich halt bei anderen Sprachen so vorher noch nicht, weil auch Zwift eben zwar nicht Garbage-Collected, aber sehr ähnlich funktioniert.
Und da muss man sich halt dahin keine Gedanken zu machen. Und wenn man so ein Command-Line-Tool schreibt, ist das nicht so das Problem.
Aber mir ist aufgefallen, wenn du UI baust, dann ist das ein sehr unangenehmes Problem, weil du gerade vom Kontext her einfach was ganz anderes machst.
[26:20] Weil man sich halt nicht so viel mit der UI und dem Frontend beschäftigt, meinst du, sondern halt eher mit so ...
[26:28] Also, man wird aus dem Flow gerissen, so hab ich das verstanden.
Man will eigentlich was ganz anderes machen und muss sich dann erst mal um so einen Nebenkriegsschauplatz kümmern, um sozusagen die Grundlage zu schaffen, weitermachen zu können.
Genau, und eigentlich ist die Aufgabe kognitiv in mir in der Anderen gefühlt.
Mhm. erst mal so das Gehirn kurz stopp, umdrehen, Kehrtwende.
[26:53] Okay, also du hast erzählt, dass du sozusagen so eine Webview dann aber dennoch benutzt, wo du quasi so Diffs reinschickst, wo die UI gepatcht werden muss.
Also das ist tatsächlich, also es ist dann nicht so, dass das Rust dann sogar auch noch für das Zeichnen der Interface-Komponenten genutzt wird, Oder ist das nur jetzt bei Dioxys der Fall, dass die so ein Konzept haben?
Was Dioxys da macht, find ich, ist eigentlich ganz schlau.
Man muss halt dazu sagen, das Framework hat eine Version 0.4.
[27:30] Und die haben einen langen Zeitplan, was wir machen möchten.
Aber dieser WebView ist halt als Renderer definiert.
Und das ist halt derzeit der Standard-Renderer für Dioxys. Es gibt noch einen weiteren, der heißt Blitz.
Und Blitz nutzt WebGPU, um halt alles zu zeichnen. wirklich ein natives Zeichnen, denn diese leichten Patches, die da geschickt werden, die kann man prinzipiell ja auch mit einem anderen Renderer abdecken.
Das muss ja nicht der WebView sein, nur der funktioniert halt sehr gut.
Da sind halt Millionen an Performance-Optimierung reingeflossen in CSS und JavaScript und HTML, das kann man schon ganz gut verwenden.
Wenn man aber jetzt spezifische Anforderungen hat, kann man eben auch einen anderen Renderer verwenden.
Witzigerweise hat per Default Dioxos auch noch einen Terminal-Renderer.
D.h. du schreibst deine App, die läuft in WebView, du kannst sie in die Plattform schieben, du kannst auch eine Web-App draus machen, und sie läuft auch im Terminal.
Tatsächlich mit Flexbox und allem Pipapo und so begrenzten CSS.
Das ist halt so ein witziger Zeiteffekt, den man dann hat. Natürlich kann man nicht jede beliebige App da laufen lassen.
[28:36] Vor einer Komplexität her. Man könnte sogar einen Renderer schreiben, der die Messages abfängt und dann native Buttons hinsetzt. Das wird natürlich auch funktionieren, das hat nur noch keiner gemacht.
[28:51] Und ist es dann so, wenn die Webview nur sozusagen wie so ein Renderer ist, also so, ich weiß nicht, es gab ja auch mal Plugins für React, glaub ich, dass man in die Canvas reinrendern kann.
Ich glaub, Flipboard hatte das damals gemacht. Ähm, heißt das dann, dass du im Grunde auch ohne Webtechnologien auskommst?
Das heißt, eigentlich wüsstest du nicht, dass es eine Webview wäre, würdest du's wahrscheinlich gar nicht merken.
Also geht das so weit? Ja, das wär der Goldstandard.
Ähm, weil aber Vraxos und Diaxos so jung ist, musste ich an zwei, drei Stellen, du hast die Möglichkeit halt, ähm, JavaScript an den WebView zu schicken, um Dinge zu machen, und an zwei, drei Stellen musste ich das halt machen.
Ein Beispiel ist, jetzt seit der Version 0.4, die jetzt gerade rausgekommen ist, kannst du halt so ein Unmounted-Event bekommen, wo du halt mitbekommst, dass deine Komponente sichtbar wird.
Das gab's vorher nicht. Das war für mich aber wichtig, weil ich möchte ja sehen, wann der User etwas sieht, damit ich sagen kann, Er hat dieses Mastodon, wie nennt man das, Posts auch schon gesehen.
Und das habe ich dann über die JavaScript API gemacht, die dann quasi eine Message zurück an den Rust schickt.
Das ist halt ein bisschen umständlich.
Aber mir hätte es zu dem Zeitpunkt noch keine andere Lösung gegeben.
Ich glaube, der langfristige Plan ist halt, dass diese ganzen Interaktionen, die jetzt noch nicht abgedeckt werden, so bis zu 1.0 dann abgedeckt sind, oder dass du dann tatsächlich, auch wenn du theoretisch den WebView gegen was anderes austauschen könntest und du würdest es nicht merken.
[30:19] Und du hast ja gesagt, dass du deine Anwendungen für verschiedene Desktop-Betriebssysteme gebaut hast, aber auch unter anderem für das iPad.
[30:34] Und das ist ja insofern ganz interessant, als dass so Dinge wie, ähm.
[30:40] Wie heißt das? Elektron. Genau.
Dass es das zum Beispiel ja für mobile Geräte nicht gibt.
Genau, für mobile Geräte gab's ja dann hier Cordova, was aber letztlich, ja genau, das war einfach, das war wirklich fast nur WebView dann.
Das scheint ja bei dir anders zu funktionieren. Also, das ist ja wirklich, ich kann theoretisch meine Anwendung dann für jede beliebige Zielplattform, die eine WebView theoretisch laufen lassen kann, ausliefern.
Genau. In dem Fall ist es halt eben die Native WebView unter iOS.
Und da verwendet es ein anderes Flask-Projekt, von dem vielleicht schon mal der eine oder andere gehört hat.
Das heißt halt Taudi.
Und Taudi ist eine Electron-Alternative, die halt genau dasselbe macht.
Also, du schreibst in dem JavaScript-Framework deiner Wahl, deine App, und dann gibt es zusätzliche APIs, so wie bei Elektron, mit der du halt eben auf das Betriebssystem zugreifen kannst.
Und Taudi 2.0, das jetzt demnächst irgendwann erscheint, hat halt dann auch Android- und iOS-Support.
Und das ist, was Dijaxus unter der Haube verwendet, um eben diese Möglichkeit zu haben, auf die unterschiedlichen Betriebssysteme zu gehen.
Und das ist natürlich auch attraktiv, wenn man jetzt sagt, Ich will jetzt mit Rust gar nichts zu tun haben.
Ich hab aber jetzt meinen SolidJS oder so, und ich möchte aber jetzt doch ganz gerne iOS-App machen.
Das würde halt mit Tauri ohne Probleme gehen.
[32:05] Okay. Na, das ist auch gut zu wissen. Also, dass Tauri kein irgendwie Rust-Projekt ist, sondern im Prinzip so ein Elektron-Konkurrent oder wie auch immer man das sehen kann.
Ich glaub, bei Elektron ist es so, dass die sozusagen immer eine gewisse Chrome-Engine-Version mitliefern, was natürlich auch seine Vorteile hat, weil man weiß ja immer, was man kriegt.
Das ist ja auch nicht verkehrt. Und bei der nativen Webview wird das wahrscheinlich wieder so ein bisschen aus dem Leim gehen.
Die eine Plattform kann das, die andere kann das nicht. Also so das klassische Frontend rumgepopelt.
Genau, das ist auch so ein bisschen ein Problem, gerade weil ja auch ältere iOS-Versionen, dann zum Beispiel ältere Safari-Engines haben und dann noch mal weniger können und Windows verwendet dort auch kein Webkit, sondern Windows verwendet halt auch Blink, heißt sie glaube ich, die Chrome Engine, weil sie ja Edge rausgebracht haben und Edge ist ja Blink.
[33:10] Und da muss man dann schon irgendwie auch so ein bisschen drauf achten, dass das alles passt, aber das muss man ja eh, wenn man Frontend macht, wie du sagst.
Ja, na ja, genau. Das gehört ja so ein bisschen dazu. Ich musste auch so ein bisschen, als ihr eingangs sauber sprach, wie jetzt zum Beispiel man eine Zahlung anstoßen kann auf den verschiedenen Betriebssystemen, hab ich gedacht, ja, im Endeffekt bräuchte man da ja auch so was wie jQuery, aber eben für diese ganzen, dass quasi eine schöne API hat, dann hinten raus irgendwie umsetzt auf die verschiedenen Plattformen.
Ja, ich hoffe so ein bisschen, dass so langfristig sowas wie Taudi das hat bietet.
Anstatt halt nur die Funktionen, sagen wir mal, Taudi hat eine Funktion, um aufs Clipboard zuzugreifen. Und anstatt halt nur das zu haben, hat es eben auch eine Funktion, um zu sagen, öffnen Payment Screen oder öffne den Camera View oder öffne den den Album View, diese Sachen halt. Aber haben wir auch kurz am Anfang drüber geredet, dass es so schwer zu generalisieren, weil die Plattformen da halt so unterschiedlich agieren und dadurch unterschiedliche Daten zurückgeben und so.
Ja, definitiv. Ja, stelle ich mir auch schwierig vor. Ich würde noch mal einmal bei diesen Webviews nachfragen wollen.
Und zwar, wenn es um das Thema Performance geht. Also grundsätzlich habe ich irgendwie immer im Hinterkopf, gerade so eine Webview zu starten, zum Beispiel auf iOS, dauert eine gewisse Zeit.
[34:35] Und dann halt irgendwie dann den Content darauf anzuzeigen, ist jetzt auch nicht unbedingt immer so schnell wie im Safari nativ.
Sind diese Aussagen überhaupt richtig? Oder habe ich da was Falsches eigentlich im Kopf?
Nee, es ist schon richtig. Also, es ist halt so, dass der WebView, den du unter iOS hast, der kann kein Jett, außer in Safari, aus Sicherheitsgründen.
Das heißt, du kannst jetzt einen Speicherblock, wo jetzt dein JavaScript-Code einmal executed war, dann wird der normalerweise, wird der dann halt darunter kompiliert in eine schnellere Repräsentation, und dann wird der Speicherblock als executable markiert, und dann hast du plötzlich deinen schnellen JavaScript-Jettet.
Und das geht nur in Safari, das geht aber eben nicht in so einem Webview.
Und deswegen ist es halt traditionell langsamer.
Aber das Problem hast du natürlich bei Dioxos nicht, weil du ja gar keinen JavaScript-Code hast.
Sondern da läuft ja alles in Rust, bei Nativ. Und es wird ja nur das Letztelement der ganzen Kalkulationen wird halt in den Webview gehoben, mehr nicht.
[35:35] Und das eigentliche Starten ist inzwischen halt auch genauso schnell, weil ich meine, da stecken M1-Prozessoren drin.
Also klar, wenn man jetzt, ich hab's jetzt natürlich nur mit iPads versucht und auch nicht mit alten iPads, sondern nur mit dem, was ich gerade so zu Hause rumliegen hab, da war die Performance sehr, sehr gut.
Aber da will ich mich jetzt eigentlich nicht aus dem Fenster lehnen, weil ich jetzt mich irgendwie, zum einen ist Evo keine App, die irgendwie eine Million Objekte darstellt, und zum anderen hab ich halt mit zwei iPads getestet.
Also da ist... Testmenge noch relativ überschaubar, sagen wir mal, aber grundsätzlich ist das natürlich ein, also hat sich das ja auch weiterentwickelt, sehr wahrscheinlich.
Eine Sache, die ich halt beispielsweise jetzt so als Vergleich auch immer im Kopf habe, ist mit Flutter.
[36:16] Weiß ich auch nicht, wie es heutzutage ist. In der Vergangenheit war es so, dass es halt irgendwie auch immer gedauert hat, bis dieser Flutter-Core dann sozusagen hochgefahren war, bis die App dann sozusagen wirklich da war und benutzbar war, musste man ein paar Sekunden einplanen.
Und wenn man das halt, sag ich mal, parallel in der gleichen App mit einer nativen App oder einem nativen Teil-App sozusagen kombiniert hat, hatte man immer praktisch eine, das Problem, dass man diesen Flutter-Teil starten musste und bis diese Engine dann da war, hat halt gedauert und es war halt einfach nicht usable.
Ja, das konntest du halt vergessen, so. Und sowas, das sind immer so die Punkte, die ich irgendwie im Kopf hab.
Ja, das ist auch so ein bisschen, ähm, auf iOS eine Zeit lang ein echtes Problem gewesen.
Wir hatten eine Zeit lang, ich hab ja wie gesagt früher bei Xing gearbeitet, und wir hatten eine Zeit lang das Problem, dass die Xing irgendwie 10 Sekunden zum Laden gebraucht hat, und das war aber nicht so richtig unsere Schuld.
Das Problem war halt, dass, ähm, wenn man ein großes Unternehmen ist, teilt man dann seinen Code in mehrere Dependencies auf, und wenn du das aber bei iOS gemacht hast, mit jeder zusätzlichen Dependency ist die App quasi eine halbe Sekunde langsamer geworden.
[37:28] Und wenn du dann halt dein Unternehmen ein bisschen strukturiert hast, dann hast du halt auch mal diese Defendancies und das war dann echt ein Engineering-Aufwand damals, das zurückzuführen, dass wir halt irgendwie damit arbeiten konnten, aber auch eine schnelle Bootzeit hatten.
Das hat irgendwie ein paar Monate gedauert. Und also das sind halt auch manchmal so diese Side-Effekte von diesen komplexen Technologiestrukturen, die man sich da zusammenhäuft.
Also du würdest damit sagen, wenn ich das richtig verstehe, das ist nicht unbedingt ein Problem jetzt einer Technologie, wie beispielsweise dann, wenn man das Ganze mit mit Rust und jetzt habe ich den Namen vom Elektron Tauri Vergleich genau dann nutzt, sondern das ist dann eher ein Problem, wie man halt dann tatsächlich die Apps strukturiert und aufbaut.
Ja, so ein bisschen. Und die Geräte sind dann auch schneller geworden.
Und Apple hat diese Probleme, die dazu geführt haben, mal doch beruhmt, warum das so langsam gestartet ist.
Also, ich würde sagen, dass das heute nicht mehr der Fall ist.
Aber da habe ich jetzt auch noch kein Experiment gemacht.
Also, wenn dieses neue Taudi 2.0 das zur richtigen iOS-Support bietet, rauskommt, bin ich auch total interessiert, da mal was zu machen, um zu schauen, wie schnell bootet das, wie fühlt sich das an.
Eben wieder wegen dieser alten Fragestellung, Wie kann man im besten Code über mehrere Plattformen teilen?
[38:51] Ja, und, ähm, ich glaub, oder, Shep?
Äh, ich hab nur gleich ne andere Frage. Dann mach mal.
Dann mach mal. Genau, ich würde fragen, wenn man sowas mit so einem Setup entwickeln möchte, wie du es verwendest, also Rust sozusagen im Kern und Und dann eben Frontend möglicherweise über WebView dann gerendert und zukünftig über WebGPU und Co.
Würdest du sagen, Dioxys ist so das Framework, das man sich angucken sollte?
Also weil es irgendwie gut zu programmieren ist und vielleicht auch eine gute Dockwatt?
Oder was gibt's da noch für Konkurrenten, die dir aufgefallen sind, wo du sagen würdest, die sind einen Blick wert?
Also, Deoxys hat auf jeden Fall den Vorteil, dass es für ein Rust-Projekt ...
Angenehm zu programmieren ist. Also, du musst dich halt ...
Ich hab jetzt über die Lifetimes 4 geschimpft, aber sie tauchen in Dijexos Prinzip sehr selten auf.
Und Rust ist auch voll von Generics.
Die tauchen da auch sehr selten auf. Das heißt, da muss man sich jetzt gar nicht so mit rumschlagen.
Und es gibt halt zwei, drei andere Frontend-Rastprojekte, die auch ziemlich gut sind. Eins heißt Iced.
[40:19] Eins heißt Xelem, aber die sind teilweise dann nicht unbedingt so weit entwickelt.
Und da sind Unterschiede.
Also ich habe mit verschiedenen drum experimentiert. Und wenn jetzt das Ziel ist, eine App zu haben, die möglichst native Charakteristika an den Tag legt.
Also wo du sagst, ich hätte eigentlich, am liebsten hätte ich kein WebView, sondern so ein natives Zeichnen mit WebGPU.
Und wenn du dann vielleicht nur anfängst und dann später halt irgendwie was anderes, dann ist Dioxys schon sehr interessant.
Und da gibt's prinzipiell auch noch zwei, drei andere, aber die machen es halt eben ein bisschen schwieriger, wenn man so glaube ich aus der Web-Entwicklung kommt, weil ja auch die ganzen, weil Dioxys ja prinzipiell so wie React aufgebaut ist. Du hast ein UseState, du hast ein UseEffect.
Das heißt also, man ist relativ schnell, kommt, man weiß, man halt, was man macht und wie man die Dinge verwendet.
Dann ist es, glaube ich, schon insgesamt am angenehmsten.
[41:10] Okay, ja, die anderen werden wir auf jeden Fall auch verlinken, die es noch gibt.
Die kann man sich dann auf jeden Fall auch angucken in unseren Shownotes.
Wie auch die anderen Sachen wie Tauri und natürlich dein Mastodon-Client.
Kann man deinen Quelltext, deins Mastodon-Clients auch sehen?
Also ist der sozusagen offen? Ja, der ist komplett offen.
Ich hoffe immer, dass irgendjemand auch mal mitmachen will.
Aber das heißt, man kann auf jeden Fall auch in den Code reinschauen und sich sozusagen angucken, wie so eine Dioxys-getriebene App aussehen würde.
Genau. Wobei meine App da vielleicht nicht das beste Beispiel ist, weil ich noch so eine zusätzliche Abstraktionsebene dazwischen geschoben habe, die so ein Reducer-Modell implementiert.
Das hat Dioxys per Default nicht. Und ich fand's halt spannend, das zu machen.
Würde ich im Nachhinein ehrlich gesagt nicht noch mal machen.
Aber wie das oft so bei Entwicklungsentscheidungen ist, das klingt total gut.
Und zwei, drei Monate später klingt's nicht mehr so gut, aber es ist halt nun mal fertig.
[42:20] Worüber wir noch nicht gesprochen haben, das haben wir nur kurz berührt, die mit Dioxys entwickelte Anwendung, hast du gesagt, könnte man auch direkt quasi als Web-App, also als Compile-Target eine Web-Anwendung sich aussuchen.
Oder es wäre möglich, dass dann wahrscheinlich nach Wasm kompiliert.
[42:50] Hast du das auch gemacht? Ich weiß gar nicht. Ja, während der ganzen Entwicklungsphase hatte ich immer ein Wasm-Target.
Einfach weil ich dann halt den angenehmen Reload-Vorteil hatte.
Ich konnte dann meinen Code schreiben und der Browser hat direkt das UI aktualisiert.
Das war halt super angenehm.
Fundamental ist es halt eben eine Mastern-App. Und es gibt ein Mastern-Library, das die App verwendet.
Und das hat kein WASM-Compile-Target.
Das heißt, ich hatte halt während der Entwicklung dann immer so eine gemockte Version von diesem Library da drin. Und irgendwann...
[43:24] Habe ich das einfach rausgeworfen, weil es halt zu viel... weil ich einiges refactoren musste, und das ist halt dabei auf der Strecke geblieben.
Also, was ich halt irgendwann machen müsste, wäre, quasi diesen Teil wegzuabstrahieren, dass ich da nicht direkt dieses Masteron-Library verwende, sondern etwas, was halt dann alternativ auf einen Server zugreift oder eben dieses Library verwendet, weil die Web App an sich ja nicht direkt die Queries zum Masteron-Server machen kann, auf jeden Fall nicht mit diesem Library.
Oder halt das Library irgendwie auch WebAssembly-kompatibel machen.
Daran scheitert's ein bisschen, aber der ganze Rest der Anwendung, quasi das UI und alles, läuft natürlich im Web.
Nur eben nicht dieser eine Teil, das Masteron-Library. Und mir fehlt aber auch so ein bisschen die Lust, das zu machen, logischerweise.
Weil es gibt ja immer so viele Aufgaben, die man machen kann, und da seh ich jetzt nicht einen großen Mehrwert, weil es ja schon eine sehr gute UI für Masteron gibt.
Prinzipiell kann Dioxos das aber, und ein normales Dioxos-Projekt, wenn man jetzt nicht so Quatsch macht wie ich, kompiliert halt ohne Problem halt auch im Web.
Das heißt, du hast dann deine eine Anwendung, du kannst dann iPadOS, macOS, Linux, Windows.
[44:32] Terminal und Web kompilieren aus einer Codebase.
Und sehr cool. Das ist schon echt eine ganze Menge und kennt man so von anderen Projekten weniger. Also ich glaube, Projekt Native kann ja auch fürs Web kompiliert werden, meine ich, oder?
Ist aber nur so ein, meine ich, mich erinnern zu können, aber für das Terminal definitiv schon mal nicht.
[44:58] Das ist schon cool, auch wenn es eine Spielerei ist.
[45:02] Ich glaub, React Native hat so ein Plugin auf jeden Fall von Nicolas Gallagher entwickelt vor einigen Jahren.
Weiß aber nicht, ob das noch ...
Ich glaub, das heißt dann sogar React Native Web, glaub ich. Ja, genau.
Weiß nicht, ob das noch ein Thema ist. Was mich noch mal interessieren würde, Benedikt, wenn man jetzt sagen würde.
[45:22] Okay, ich würde gerne tiefer in dieses Thema einsteigen, Rust auch cross-Plattform zu verwenden als Frontend-App oder für die ausgeführten Tätigkeiten sozusagen.
Wie steigt man da am besten ein? Gibt es da irgendwie Artikel, die du empfehlen kannst?
Die Jungs von, also tatsächlich, würde ich jetzt einfach bei Dioxys bleiben.
Es gibt halt eben andere Projekte, zum Beispiel Peer Stories oder so, die sind dann Fullstack Rust Frameworks zum Beispiel, die halt auch durchaus gut sind, aber da hat man jetzt gleich dann, die verlinken wir dann, glaube ich, auch, aber dann hat man gleich noch mal fünf weitere Projekte, die man sich anschauen müsste.
Bei Dioxys, die haben ihre Documentation-Werte geupdatet.
Und die haben jetzt einen relativ guten Flow, da kann man sich durchlesen, da sind viele Sample-Projects.
Wenn man das GitHub-Repository auscheckt, da ist so ein Examples-Folder, der hat halt irgendwie, was weiß ich, 50 Projekte und alle von denen sind sehr klein.
Eins erklärt dann so ein bisschen Suspense, eins ist ein Calculator, eins zeigt, wie man irgendwie was drawt und so was, und da kann man so ein bisschen mit rumspielen, die modifizieren, wieder laufen lassen, das funktioniert eigentlich ganz gut.
Ich glaube, so zum Rumspielen und so ein bisschen da reinkommen, das ist schon ganz angenehm.
Und es gibt auch so ein Awesome Dioxys, wo dann halt andere Projekte verlinkt sind, wenn man sagt, okay, was machen denn Leute damit? Ich möchte mir den ZooScope mal ganz gerne anschauen.
Da kann man dann auch noch Mat einschauen.
[46:41] Cool, das sind ja auf jeden Fall schon mal sehr gute Quellen. Wir werden das auf jeden Fall verlinken. Wir haben auch noch ein paar andere Links, die du mitgebracht hast, glaube ich. Neben denen, wir haben über Tauri gesprochen und so weiter. Das werden wir auf jeden Fall besprechen. Hast du auch noch von einem Artikel von Colin Rufferts?
Ja, ich weiß auch nicht, wie man das pronunzt.
Auf jeden Fall über, ja, den verlinkt. Da geht's um die Bestimmung einer, was ist eigentlich eine native UI-Library?
[47:12] Genau, und also, ich war mir nicht sicher, inwiefern wir in dieses Thema gehen, weil man hat ja eben oft diese Kritik, dass ein WebView ja nicht richtig native ist.
Und, ähm... Ja, genau.
Genau, und was Herbert da sagt, ist so ein bisschen, richtig native ist auch einfach wahnsinnig schwer, weil es gibt eben auf der Rust-Seite viele Projekte, die versuchen, selber das UI zu malen, also mit Web-GPU oder mit anderen Methoden.
Aber das schwierige Kunststück ist, wenn du jetzt, nur ein Beispiel zu nennen, zwei Beispiele, sagen wir mal, wenn du jetzt ein Video darstellen willst, du möchtest halt, das ist ja nicht ungewöhnlich, dass eine App ein Video zeigen soll.
Und die Art und Weise, wie das bei einem modernen Betriebssystem halt läuft, dass es deine Anwendung, das Video ans Betriebssystem gibt, da hast du einen Compositor, der nimmt dieses Video, und dann nimmt der das, macht das, packt das in ein Texture in der GPU, dann nimmt er das Texture von deiner Anwendung, packt das auch in die GPU, und dann wird das zusammengefügt.
Dadurch ist die Performance halt sehr hoch. Und das heißt, wenn du also dann so ein Library machst, dann musst du diesen Compositing-Step, den musst du halt quasi mit unterstützen, und dann ist es wahnsinnig aufwendig und in jedem Betriebssystem komplett anders.
Und das zu machen, das schaffen schon die wenigsten, und wenigstens unter WebView kann das halt einfach.
Und wenn du halt irgendwie einen Button malen willst, der Default WebView-Button ist halt einfach mal ein Native-Button.
Das ist jetzt irgendwie so ein normaler Button im WebView. Der ist halt mehr native als der Button in Flutter oder in der anderen, weil das ist ein Native Besiegssystem Button.
[48:36] Und man lacht dann halt viel über den WebView, aber gleichzeitig ist dann auch CSS da so hoch optimiert, dass also in meinem Masterdom-Client, wenn ich da scrolle, das ist fünfmal schneller als SwiftUI, einfach weil das halt hoch native ist und da so viel rumoptimiert wurde.
Was halt dann weniger native ist, ist dann eben, wenn du halt den JavaScript-Code, sagen wir mal, ausführst, gejittet und so weiter, da geht natürlich Performance verloren.
Das Problem hast du bei der Yoxus gar nicht so sehr. Und dieser Artikel, der geht eben so ein bisschen darauf ein, Was ist denn überhaupt native und Schlussfolger halt auch damit so ein bisschen zu sagen, okay, du musst diese ganzen Sachen implementieren, das ist eine wirklich lange Liste, oder du nimmst einfach ein Webview, der kann das nämlich schon alles.
Also ein gutes Statement, den Webview einfach zu verwenden, also ich meine, für die allermeisten Entwicklerinnen und Entwickler, die hier zu hören, die sowieso viel im Web unterwegs sind, ist das wahrscheinlich auch gut zu hören.
[49:29] Ja, da will ich die Gelegenheit direkt nutzen und auf einen anderen Podcast verweisen.
Die Igalia Chats, die höre ich immer sehr gerne.
Und die, also Igalia ist ja so quasi sowas wie Söldner Programmierer, die dann in Browsern Features implementieren.
Also das machen die halt in allen Browsern. Und die haben vor ungefähr einem Monat eine Folge rausgebracht, First-Person-Scrollers, so das Thema, und da geht's quasi um die, um Browser und wie die es eben schaffen, also bei diesem komplexen Web, das wir haben mit den vielen Features, trotzdem eben alles in 60 Frames pro Sekunde zu rendern.
Und das ist sehr, sehr spannend, diese Folge zu hören, mit einem, in dem Fall dann einem Chrome-Engineer, der dann über die Render Engine spricht.
[50:25] Genau. Werden wir auch verlinken dann. Ich finde halt echt, dass der WebView da teilweise seinen Beruf zu Unrecht hat.
Ich glaube, oftmals auch einfach, weil man besucht dann so eine Webseite und die ist unglaublich langsam, aber das liegt halt daran, dass da 700 Tracking-Frameworks drin sind und Analytics-Frameworks und Plugins und man keine Zeit hat, da den Code aufzuräumen und das ist halt viel mehr das Problem als der WebView an sich, der glaube ich sehr schnell ist, wenn er halt besser verwendet werden würde.
Ja, also, liebe Hörerinnen und Hörer, schneidet euch davon auf jeden Fall nochmal eine Scheibe ab und überzeugt eure Marketingabteilung doch bitte jetzt diese Tracking-Pixel da rauszuhauen.
Wir kennen das Problem alle, ja.
Oder halt sich auf eines zu einigen. Also ich war noch nie im Unternehmen, was einfach nur ein Tracking-Framework hatte. Irgendwie mussten es immer fünf sein.
Ja. Ja, wobei ja auch viel, jetzt machen wir einen kleinen Ausflug, aber auch viel so Branchenlösungen dann natürlich spezielles Tracking nochmal beinhalten, ne?
Also, kannst halt nicht irgendwelche speziellen Branchenzahlen messen mit Google Analytics, weil du brauchst halt irgendein Nielsen-Tracking oder I don't know, ja?
Ja, ist richtig. Aber es macht die Situation trotzdem nicht besser.
Es ändert nichts an der Grundeinnahme. Da hast du vollkommen recht, ja.
Das war's. Bis zum nächsten Mal.
[51:44] Ich würde sagen, wir haben das Thema auf jeden Fall ganz gut beackert.
Das war auf jeden Fall ein toller Einblick in die Entwicklung mit Rust.
Und zwar die in dem Fall jetzt eher frontend-lastige Sicht auf die Dinge, nachdem wir ja damals viel über serverseitige Frameworks gesprochen haben und Rust auch sozusagen als Sprache.
Vielen, vielen Dank.
Wenn's Fragen gibt, kann man dich erreichen, nehm ich an. Ja, bei Masteron und auch noch bei Twitter, nein, halt X.
Ja.
[52:21] Genau. Übrigens, du hast ja gesagt, du hast bei Xing gearbeitet.
Irgendwie gibt's ja das Gerücht, dass in Zukunft das Twitternian, also Twitter nicht mehr toTweet ist, sondern Xing.
Ja. Da kommt noch was auf die zu.
Ja, genau. Ein weiterer, eine weitere juristische Auseinandersetzung.
Und der der Support der die armen Leute die bekommen immer die Mails von den von denen die nicht Xen können.
Ja ja sehr traurig alles genau vielen Dank liebe Grüße nach Hamburg ja danke bitte weitermachen danke für die Einladung war sehr schön hier zu sein war Spaß gemacht das freut uns sehr cool dass du da warst das kann man nur zurückgeben vielen Dank und an die Hörerinnen und Hörer vielen Dank fürs zuhören.
Und genau, dann hören wir uns nächste Woche wieder wahrscheinlich mit, was haben wir als nächstes, ja, Solid.js ist ein Thema nächste Woche.
Baut hier ein bisschen aufeinander auf, wie ihr merkt, ne? Wir haben ja vorhin Solid.js kurz angesprochen.
Absolut, ja, genau. Alles klar.
Alles klar, bis dahin. Dankeschön.
Tschüss. Ciao, ciao.
[53:35] Music.