WEBVTT

00:00:00.017 --> 00:00:06.857
Ich hab von 2001 bis 2008 JavaScript gemacht. Da hatten wir nur noch keine Types, das war in der Anderthaler Zeit.

00:00:06.917 --> 00:00:09.297
Nur da ist Typescript ein Riesenfortschritt.

00:00:09.357 --> 00:00:12.792
Das ist schon schön, dass ich meine Types, meine Rückgabewerte hab.

00:00:13.057 --> 00:00:16.717
Das hat aber den Sinn, dass erst mal eine Methode fertig werden muss,

00:00:16.777 --> 00:00:19.615
und dann kann die das weitergeben an die nächste, oder?

00:00:19.957 --> 00:00:26.017
Genau. Genau. Das ist doch so die Grundidee dahinter. Genau, die Grundidee ist, weil Rust so low-level ist,

00:00:26.077 --> 00:00:29.707
möchtest du verhindern, zeitig irgendwas editieren können zum Beispiel.

00:00:30.000 --> 00:00:54.160
Music.

00:00:54.697 --> 00:00:56.297
Revision 583,

00:00:59.621 --> 00:01:03.217
Diese Revision von Working Draft wird euch präsentiert von Hörerinnen und Hörern wie

00:01:03.217 --> 00:01:07.859
euch. Auf patreon.com slash working draft könnt ihr uns ein paar Euro in den Hut werfen. Aus,

00:01:08.377 --> 00:01:11.657
euren Beiträgen und unseren gelegentlichen Werbeeinnahmen bezahlen wir allerlei teure

00:01:11.657 --> 00:01:16.017
Software-Abos und das Honorar unserer Audio-Producerin. Wenn ihr euch auch beteiligen

00:01:16.017 --> 00:01:20.377
wollt, könnt ihr das unter patreon.com slash working draft sehr gerne machen. Wir danken

00:01:20.377 --> 00:01:23.027
Wir bedanken euch tausendfach für die Unterstützung und fürs weitere Zuhören.

00:01:23.377 --> 00:01:28.915
Wir sind heute zu dritt.

00:01:29.377 --> 00:01:31.841
Da hätten wir aus dem Team einmal den Hans. Hallo.

00:01:32.732 --> 00:01:36.377
Ich bin der Shep und das bedeutet, wir haben wieder einen Gast da.

00:01:36.377 --> 00:01:40.987
Und zwar den Benedikt der Hechte aus Hamburg. Grüß dich. Hey.

00:01:41.377 --> 00:01:47.377
Hi. Bevor wir in unser Thema heute eintauchen. Du warst noch nie Gast bei uns.

00:01:47.377 --> 00:01:52.366
Da würden wir dich fragen wollen, ob du dich mal ganz kurz unseren Hörerinnen und Hörern vorstellen magst.

00:01:52.924 --> 00:02:00.377
Klar. Hi, ich bin der Benedikt. Ich hab 2001 oder so mit Webentwicklung angefangen,

00:02:00.377 --> 00:02:07.377
bin aber dann 2008 mit dem Aufkommen vom iPhone zu iOS, MacOS und so weiter gewechselt.

00:02:07.377 --> 00:02:12.377
Und so seit 2017 versuche ich, mich davon wieder wegzubewegen,

00:02:12.377 --> 00:02:14.376
was aber nicht ganz so einfach ist.

00:02:14.583 --> 00:02:19.517
Und mache seitdem Rust, wenn es halt so passt. Und jetzt gerade bei der Arbeit,

00:02:19.517 --> 00:02:22.838
wenn immer sich eine Möglichkeit eröffnet, wo ich halt nicht iOS machen kann,

00:02:23.136 --> 00:02:26.857
nutze ich sie. Zum Beispiel habe ich jetzt seit zwei Monaten so ein Typescript-Projekt.

00:02:27.007 --> 00:02:31.297
Und das Ganze halt so ein bisschen, weil das iOS-Tooling mir wirklich gar nicht gefällt.

00:02:31.297 --> 00:02:35.127
Und da versuche ich halt so ein bisschen zu schauen, was kann man stattdessen machen.

00:02:35.334 --> 00:02:40.744
Und in meiner Freizeit entwickle ich halt viel Desktop-Anwendungen und Frontend-Anwendungen in Rust.

00:02:41.041 --> 00:02:43.857
Und dazu kommen wir sicherlich vielleicht auch noch zu gehört,

00:02:43.857 --> 00:02:45.326
auch im Master und Client zum Beispiel.

00:02:46.109 --> 00:02:51.857
Klingt sehr gut. Ich glaube, der Hans, der will fragen, was du an den Mac-Dev-Entwicklungsumgebungen

00:02:51.857 --> 00:02:53.697
Umgebung nicht so gut findest.

00:02:55.121 --> 00:03:00.151
Wir sprachen in der Vorbesprechung drüber, deswegen. Es ist auf jeden Fall immer interessant zu hören,

00:03:00.151 --> 00:03:04.231
was läuft eigentlich gut in der einen Plattform und auf der anderen nicht oder so.

00:03:04.391 --> 00:03:10.031
Und wir haben ja grundsätzlich immer über Web-Tooling immer viel zu sprechen.

00:03:10.298 --> 00:03:13.755
Aber dann ist auch mal interessant zu hören, was ist denn eigentlich bei iOS so los?

00:03:13.998 --> 00:03:15.791
Warum findest du das doof?

00:03:15.943 --> 00:03:19.778
Also, es gibt wie bei allem immer viel Gutes und viel Schlechtes.

00:03:19.967 --> 00:03:26.430
Und das, also was für mich das störendste Problem ist, Bei Apple kommt ja alles aus einem Guss.

00:03:26.692 --> 00:03:29.833
Und dazu gehört eben auch diese Entwicklungsumgebung, dieses Xcode.

00:03:30.411 --> 00:03:38.251
Und eine Entwicklungsumgebung zu bauen, die von der Komplexität mit IntelliJ zum Beispiel hinterherkommt,

00:03:38.291 --> 00:03:39.651
ist halt schon aufwendig.

00:03:39.711 --> 00:03:41.311
Da fällt halt viel Zeit rein.

00:03:41.428 --> 00:03:45.391
Neuerdings, in den letzten zwei, drei Jahren, gibt's wahnsinnig viele Tools,

00:03:45.451 --> 00:03:49.991
die man in seine Entwicklungsumgebung laufen lassen kann, so die Copilot zum Beispiel.

00:03:50.268 --> 00:03:54.951
Oder andere, die einem das Entwickeln einfacher machen Und Xcode bietet das alles nicht.

00:03:55.031 --> 00:03:56.871
Und hat auch kein Plugin-Interface.

00:03:57.245 --> 00:04:02.223
Ich als Entwickler, was ich den ganzen Tag mache, ist ja, ich schreibe größtenteils Code oder ich lese Code,

00:04:02.728 --> 00:04:03.791
oder ich editiere Code.

00:04:03.851 --> 00:04:09.991
Und da ist Xcode sehr nah an so einem Notepad von Windows. Also, die Autocompletion-Failure schlägt regelmäßig viel.

00:04:10.051 --> 00:04:13.791
Du kannst Symbole nicht resolven. Du kannst nicht nach Symbolen suchen,

00:04:13.851 --> 00:04:15.311
das schlägt regelmäßig viel.

00:04:15.601 --> 00:04:21.671
Es gibt Wim-Bindings, die sind wahnsinnig schlecht. Und für mich als alter Unix-Nerd ist es jedes Mal wieder frustrierend,

00:04:21.671 --> 00:04:30.671
Und das heißt, eine Anwendung starten, im Simulator laufen lassen, das ist eigentlich ganz cool und das funktioniert auch gut.

00:04:30.671 --> 00:04:33.671
Der Debugger ist wirklich gut, aber das mache ich ja nicht den ganzen Tag.

00:04:33.671 --> 00:04:38.171
Den Großteil der Zeit bin ich damit beschäftigt, Code zu editieren, Code zu lesen und Code zu schreiben.

00:04:38.989 --> 00:04:43.839
Genau dieser Prozess ist wahnsinnig schlecht und ich würde einfach gerne zu VSCode wechseln, das geht aber nicht.

00:04:43.839 --> 00:04:47.839
Und ja, dann muss man halt eben was anderes ändern.

00:04:47.839 --> 00:04:52.839
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,

00:04:52.839 --> 00:04:59.604
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.

00:05:00.171 --> 00:05:09.524
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.

00:05:10.200 --> 00:05:16.114
Du hast es angesprochen, es hat viele Vorteile, die Xcode-Umgebung zu nutzen, Simulator und ähnliches.

00:05:16.546 --> 00:05:25.305
Gibt es denn überhaupt Möglichkeiten, Simulator, auch beispielsweise mit einem anderen Editor, wie jetzt, du hast eben VS Code angesprochen, zu nutzen?

00:05:25.648 --> 00:05:32.339
Du kannst, es gibt so Open-Source-Projekte, mit denen du im Terminal den Simulator steuern kannst.

00:05:32.339 --> 00:05:37.071
Und du kannst auch die Builds im Terminal machen. Also sagen, ich hab jetzt irgendwie ein Projekt,

00:05:37.359 --> 00:05:38.476
was ich mir geschrieben hab.

00:05:38.971 --> 00:05:44.339
Das nutzen halt auch so Sachen. Es gibt ja so Projekte, mit denen du Cross-Platform-Frameworks hast.

00:05:44.339 --> 00:05:48.306
Und die nutzen halt auch dieses Tooling, um dein Simulator zu laufen zu lassen.

00:05:48.747 --> 00:05:50.339
Es gibt auch ein VS Code-Plugin für Swift.

00:05:50.863 --> 00:05:55.274
Das funktioniert aber nicht so gut. Es ist halt alles so nicht gut, also noch schlechter als Xcode.

00:05:55.661 --> 00:05:57.795
Es funktioniert, aber es ist nicht besser.

00:05:57.858 --> 00:06:00.839
Und nicht irgendwie ein bisschen besser, sondern ein bisschen schlechter eher.

00:06:00.839 --> 00:06:02.548
Und dann kommt man da halt auch nicht viel weiter mit.

00:06:02.839 --> 00:06:05.839
Ja, klar. Und irgendwann muss man sich dann auch mal entscheiden,

00:06:05.839 --> 00:06:13.839
so lebe ich jetzt weiterhin damit und mache iOS-Entwicklung oder man macht es wie du und du sagtest gerade, machst TypeScript.

00:06:13.839 --> 00:06:24.339
Wie ist so dein Eindruck von TypeScript? Also, die Art und Weise zu entwickeln und diese superschnelle Feedback-Loop zu haben,

00:06:24.339 --> 00:06:27.079
ist natürlich total toll im Vergleich zu allem, was ich bei iOS habe.

00:06:27.079 --> 00:06:29.619
IOS versucht das auch so ein bisschen, und bei Rust habe ich es auch nicht,

00:06:29.619 --> 00:06:32.444
dass ich halt was schreibe, ich speichere und ich sehe dann den Output.

00:06:32.699 --> 00:06:37.219
Das habe ich bei Rust nicht, weil da muss ich halt kompilieren und muss jetzt möglicherweise von Hand starten.

00:06:37.219 --> 00:06:42.259
Das habe ich bei iOS auch, und für beide Sprachen gibt es halt auch so Facilities,

00:06:42.259 --> 00:06:46.259
die das so halbgar ermöglichen, aber halt so gut wie bei JavaScript,

00:06:46.259 --> 00:06:48.259
TypeScript ist es natürlich nicht.

00:06:48.459 --> 00:06:52.186
Und ich hab ja wie gesagt von 2001 bis 2008 JavaScript gemacht.

00:06:52.499 --> 00:06:55.259
Da hatten wir nur noch keine Types, das war nur noch in der Anderthaler Zeit.

00:06:55.259 --> 00:06:57.259
Nur da ist TypeScript natürlich ein Riesenfortschritt.

00:06:57.480 --> 00:07:00.946
Also das ist natürlich schon schön, dass ich ja meine Types, meine Rückgabewerte hab.

00:07:01.259 --> 00:07:02.980
Also ich find's gut.

00:07:04.177 --> 00:07:12.099
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

00:07:12.259 --> 00:07:15.259
an der einen oder anderen Stelle fehlen mir halt spezifische Types.

00:07:15.259 --> 00:07:18.979
Zum Beispiel der Rust-Enum, der ja so ein bisschen in TypeScript aufgeteilt ist,

00:07:18.979 --> 00:07:25.519
in den Enum und in so einen Union. Das ist halt bei Rust ein Ding und der ist deutlich expressiver.

00:07:25.519 --> 00:07:27.759
Da kann man halt schon mehr mitmachen und den nutze ich halt sehr viel.

00:07:27.759 --> 00:07:29.546
Und das sind so Sachen, das ist okay.

00:07:29.681 --> 00:07:33.255
Das ist aber halt bei Rust noch ein bisschen typesafer, würde ich sagen.

00:07:33.399 --> 00:07:36.874
Aber ich meine, im Vergleich zu JavaScript ist es natürlich weltenbesser.

00:07:37.963 --> 00:07:53.978
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?

00:07:54.133 --> 00:08:05.762
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,

00:08:06.185 --> 00:08:10.013
Gerade mit deinem Mastodon-Client hast du dich ja auch viel damit beschäftigt.

00:08:10.013 --> 00:08:13.936
Wie bekommt man eigentlich Rust-Code, den man in den Frontend reinbringt?

00:08:14.692 --> 00:08:20.013
Was waren da so deine Findings? Ich finde also, das Thema an sich finde ich halt spannend.

00:08:20.013 --> 00:08:27.013
Weil in der klassischen Welt von vor 5 oder 6 Jahren war es halt so, du hattest eine iOS- oder eine Android-App.

00:08:27.466 --> 00:08:34.013
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?

00:08:34.013 --> 00:08:39.753
Ähm, und wenn du aber jetzt sagst, okay, ich versuche, Code zu teilen,

00:08:39.753 --> 00:08:41.933
dann hast du ja keinen 200-Prozent-Gewinn.

00:08:42.176 --> 00:08:47.593
Weil du hast natürlich ein bisschen zusätzlichen Code, den du schreiben musst für diesen geteilten Code.

00:08:47.593 --> 00:08:49.833
Du hast pro Plattform noch so ein bisschen Aufwände, die du machen musst.

00:08:49.833 --> 00:08:58.065
Das heißt, du gewinnst vielleicht 150 Prozent Zeit dadurch. Also, du gewinnst ein bisschen mehr, aber halt nicht das Doppelte.

00:08:58.335 --> 00:09:04.833
Und wenn man aber jetzt noch Linux und Windows und MacOS hinzunimmt dann hast du auch mal fünf Plattformen,

00:09:04.833 --> 00:09:07.393
und dann ändert das natürlich die Gleichung total.

00:09:07.393 --> 00:09:11.273
Und dann stellt sich halt die Frage, wie kannst du einmal Code schreiben,

00:09:11.273 --> 00:09:15.393
gerade Logik-Code, bei dem du halt auch irgendwie Bugs haben kannst und so weiter,

00:09:15.393 --> 00:09:17.393
und den auf jeder Plattform verwenden?

00:09:17.393 --> 00:09:21.393
Und da finde ich halt Rust spannend, weil es eben keine native ...

00:09:21.393 --> 00:09:23.393
Es hat keine Heimat, ne?

00:09:23.393 --> 00:09:27.393
Also, so Swift ist so eine Sprache, die läuft super am Mac, woanders geht's so.

00:09:27.393 --> 00:09:33.693
Und, ähm, Kotlin ist eine Sprache, die läuft super unter Android und auch sicherlich einigermaßen gut unter anderen Plattformen,

00:09:33.693 --> 00:09:36.856
aber Rust hat halt keine richtige Heimat, wo es herkommt. Das läuft halt überall gut.

00:09:36.993 --> 00:09:42.993
Und ist auch für alles optimiert. Und dadurch ist es halt so ein bisschen spannend zu sagen,

00:09:42.993 --> 00:09:45.273
okay, man könnte seine Logik da schreiben.

00:09:45.393 --> 00:09:49.493
Und dann, NuVic macht man dann weiter. Also macht man das komplett in Rust

00:09:49.493 --> 00:09:51.493
oder macht man Teile davon in einer anderen Sprache

00:09:51.493 --> 00:09:53.663
und da experimentiere ich so ein bisschen drum.

00:09:53.893 --> 00:09:58.893
Und bei diesem Mastern und Client habe ich dann wirklich die ganze App in Rust geschrieben.

00:09:58.893 --> 00:10:03.593
Das Desktop-App läuft jetzt Linux, Windows, macOS und iPadOS zurzeit.

00:10:04.151 --> 00:10:09.173
Und theoretisch auch im Web. Aber da sind ein paar Dependencies, die ich noch pt'n müsste.

00:10:09.173 --> 00:10:12.946
Halt alles aus einem Guss. Und das war auch total spannend.

00:10:13.180 --> 00:10:17.173
Hat aber auch eben seine Nachteile. Weil es halt schon schwierig ist,

00:10:17.173 --> 00:10:20.868
die ganze Interaktion, die du auf einer Plattform haben kannst, mit...

00:10:21.471 --> 00:10:26.836
Die einen User halt so hat, die halt über so ein generisches Interface abzubilden.

00:10:28.376 --> 00:10:57.646
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.

00:10:58.524 --> 00:11:00.883
Oder wie funktioniert es auch mit Huawei,

00:11:01.153 --> 00:11:07.599
die sich ja dann mit der Android-Applikation dann vielleicht wieder ein bisschen mehr alignen?

00:11:08.598 --> 00:11:11.695
Wie abstrahiert man sowas? Kann man das überhaupt abstrahieren?

00:11:12.100 --> 00:11:17.446
Bei React Native abstrahiert man das ja mit diesen Native-Plugins,

00:11:17.600 --> 00:11:22.074
wo du halt dann ein bisschen Kotlin-Code hast, und dann hast du ein bisschen Swift oder Objective-C-Code.

00:11:22.166 --> 00:11:26.046
Und dann musst du halt darauf vertrauen, dass irgendjemand das Ding halt immer aktualisiert,

00:11:26.046 --> 00:11:28.046
wenn sich die APIs ändern.

00:11:28.151 --> 00:11:32.846
Und das ist, glaube ich, der zurzeit so ein bisschen die beste Lösung.

00:11:32.846 --> 00:11:34.939
Und ich glaube, ähnlich wird das ja auch bei Expo verwendet.

00:11:35.335 --> 00:11:37.846
Dass man halt wirklich einfach sagt, wir haben halt unsere Plugins,

00:11:37.846 --> 00:11:40.232
da musst du aber darauf vertrauen, dass es da jemanden gibt, der das macht.

00:11:40.637 --> 00:11:43.346
Der halt da irgendwie diese Sachen baut, der die regelmäßig pflegt,

00:11:43.346 --> 00:11:46.290
der da keine Bugs in seiner Implementierung hat, in seiner Portierung.

00:11:46.353 --> 00:11:53.346
Und bei dem, was ich jetzt gemacht habe, habe ich halt den Code selber geschrieben in Objective-C oder in Rust

00:11:53.346 --> 00:11:57.026
und hab ihn halt dann entsprechend in der App gehostet.

00:11:57.026 --> 00:12:00.426
Was aber hin dazu führt, dass die App am Mac einfach deutlich besser ist als unter Linux.

00:12:00.426 --> 00:12:08.466
Oder unter Windows, weil ich am Mac halt einfach weiß, was ich mach und wie ich da halt die zusätzlichen Facilities nutze.

00:12:08.466 --> 00:12:11.263
Und bei Windows müsste ich dann irgendwie diese Windows-32-API nutzen.

00:12:11.983 --> 00:12:16.862
Versteh ich kein Wort. Und das guck ich mir halt auch nicht an. Ja.

00:12:18.050 --> 00:12:20.106
Ja.

00:12:19.671 --> 00:12:29.132
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.

00:12:29.654 --> 00:12:43.644
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.

00:12:44.418 --> 00:12:49.387
Sozusagen erhofft, wenn man halt einmal für alle Plattformen schreibt,

00:12:49.738 --> 00:12:55.068
wenn aber so wichtige Dinge, die vielleicht, keine Ahnung, 50 Prozent deiner App ausmachen,

00:12:55.113 --> 00:13:00.082
halt dann doch wieder nativ für jede Plattform sind, dann muss man sich das wieder draufschärfen.

00:13:00.415 --> 00:13:03.764
Was sind denn dann die Teile, die man gut teilen kann vielleicht auch?

00:13:04.034 --> 00:13:10.408
Also, was ich so ein bisschen festgestellt habe, was halt richtig gut funktioniert, ist, wenn du eine native App hast,

00:13:10.669 --> 00:13:17.861
Und du bindest halt dann, weil du kannst ja Rust zu WebAssembly kompilieren oder halt zu nativen Libraries.

00:13:17.979 --> 00:13:21.981
Und so ein natives Library kannst du halt in so eine Android-App reinladen,

00:13:21.981 --> 00:13:23.956
das kannst du in eine Swift-App reinladen, in eine Linux-App.

00:13:24.217 --> 00:13:30.068
Und dann hast du quasi deine ganze Logik in diesem Library und hast dann so einen, ich sag mal, so einen Event-Enum,

00:13:30.312 --> 00:13:34.876
der aus dem Library zurückkommt und der sagt dann halt deiner Native App, was sie zu tun hat.

00:13:35.137 --> 00:13:39.481
Und das ist halt eine ziemlich gute Abstraktion, weil du dann halt, du brauchst natürlich immer noch einen Native-Entwickler,

00:13:39.481 --> 00:13:45.881
aber halt keine 10 vielleicht, und dann hast du halt eine relativ lightweight Container, das ist eine Native App,

00:13:46.381 --> 00:13:53.401
die malt halt das UI, und wenn zum Beispiel Inner Purchase, wenn halt dann der RAScode sagt, für diese Handlung

00:13:53.401 --> 00:13:57.441
mache ich jetzt einen Inner Purchase mit diesen und jenem Parametern,

00:13:57.441 --> 00:13:59.335
dann macht die Native App das halt.

00:13:59.479 --> 00:14:02.881
Und wenn du das geschickt aufteilst, dann hast du sogar eine Struktur,

00:14:02.881 --> 00:14:07.680
die du vielleicht wiederverwenden kannst. Also ich glaube, das ist so ein bisschen die attraktivste Möglichkeit.

00:14:09.552 --> 00:14:15.362
Aber das macht natürlich auch nicht für jedes Projekt Sinn. Je nachdem, das ist so die Schwierigkeit

00:14:15.402 --> 00:14:21.562
bei diesem plattformübergreifendem Entwickeln, ist halt die Frage, die Anwendung, die ich hier entwickle,

00:14:21.602 --> 00:14:23.162
was macht hier überhaupt Sinn?

00:14:23.202 --> 00:14:25.739
Da ist eine generische Antwort schon fast unmöglich, würde ich sagen.

00:14:27.017 --> 00:14:27.548
Mhm.

00:14:30.078 --> 00:14:36.602
In meinem Kopf ist es halt irgendwie so, wenn man so sehr viel Anzeigelogik hat, sag ich mal,

00:14:36.766 --> 00:14:42.960
die halt irgendwie sehr generisch darstellbar ist, ne? Also, Mastodon Client nehmen wir mal als Beispiel.

00:14:43.338 --> 00:14:45.598
Du willst eine Timeline darstellen irgendwie.

00:14:46.129 --> 00:14:50.036
Du willst bestimmte Aktionen haben, wie jetzt jemandem folgen oder ähnliches.

00:14:51.323 --> 00:14:55.482
Das ist wahrscheinlich sehr gut abstrahiert darstellbar, stelle ich mir das so vor.

00:14:56.103 --> 00:15:01.919
Ja. Also, in diesem Fall habe ich ein Rust-Framework genommen, das heißt Dioxys.

00:15:02.459 --> 00:15:07.322
Und was die halt machen, das ist so wie React, aber komplett in Rust implementiert.

00:15:07.428 --> 00:15:10.111
Die haben dann auch einen Virtual DOM, das ist komplett in Rust implementiert.

00:15:10.399 --> 00:15:16.178
Mhm. Und wenn also dann, sagen wir mal, dein UseState geupdatet wird,

00:15:16.322 --> 00:15:21.322
dann berechnen die halt, was muss tatsächlich im DOM überhaupt noch aktualisiert werden.

00:15:21.322 --> 00:15:28.322
Und dann haben die so einen Interpreter in TypeScript, der dann nur noch die minimalen DOM-Updates quasi an ein Webview gibt.

00:15:28.322 --> 00:15:33.322
Und der wird dann aktualisiert. Und dadurch hast du halt den Vorteil, dass die ganze...

00:15:33.322 --> 00:15:36.782
Was Performance-aufwendig ist, passiert halt eben im Rust-Teil.

00:15:36.782 --> 00:15:42.582
Und im WebView wird dann wirklich nur ein ganz kleiner Patch applied normalerweise für die meisten Aktionen.

00:15:42.702 --> 00:15:50.422
Und das hat so ein bisschen den Vorteil, dass du halt sehr performant, also du hast halt das React-Modell,

00:15:50.422 --> 00:15:52.582
aber du hast halt irgendwie eine unglaubliche Performance.

00:15:52.582 --> 00:15:58.622
Also die kommen halt dann zu der JS ran, weil eben die so viel von dieser Abstraktion halt drübergeholt haben

00:15:58.622 --> 00:16:02.742
in Rust, aber gleichzeitig ist es genauso ergonomisch wie React quasi.

00:16:02.742 --> 00:16:03.647
Das ist eine ganze Taktik.

00:16:10.624 --> 00:16:19.822
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.

00:16:19.822 --> 00:16:23.022
Ich weiß gar nicht, ob die das heute immer noch genauso updaten.

00:16:23.452 --> 00:16:29.342
Gab's irgendwann mal ja so einen, ich glaube, anderen Algorithmus, wie die das machen.

00:16:29.808 --> 00:16:39.422
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,

00:16:39.773 --> 00:16:46.327
im Endeffekt alles in Rust schreiben muss. Das heißt, man muss halt dann sich Rust draufschreiben,

00:16:46.939 --> 00:16:55.896
kann aber dann diese Vorteile halt nutzen, die man halt durch den Mechanismus, wie du ihn eben beschrieben hast, so, ja, hat.

00:16:56.328 --> 00:16:59.335
Indem man halt für mehrere Plattformen gleichzeitig arbeiten kann.

00:17:00.803 --> 00:17:01.451
Genau.

00:17:03.098 --> 00:17:09.112
Wie war das für dich, Rust zu lernen, als jemand, der eigentlich aus dem Objective-C- oder Swift-Kontext kommt?

00:17:09.724 --> 00:17:13.550
Ich glaub, jetzt kommt etwas, was man schon oft gehört hat, fürchterlich.

00:17:14.207 --> 00:17:18.762
Ähm, also, es ist halt so, Swift und Rust sind sich als Sprache total ähnlich.

00:17:19.005 --> 00:17:24.288
Also, die verwenden dieselben Konzepte, der Enum funktioniert genauso, die Generics funktionieren genauso,

00:17:24.328 --> 00:17:26.450
das sind halt wirklich sehr ähnliche Sprachen.

00:17:26.708 --> 00:17:31.168
Aber Rust hat halt eben diese zusätzlichen zwei Dinge. Es hat dieses Ownership-Modell,

00:17:31.446 --> 00:17:34.908
Das hat Zwift inzwischen auch bekommen, aber in eine einführendere Art und Weise.

00:17:34.908 --> 00:17:39.440
Und es hat diese Lifetimes. Und diese Lifetimes machen es einem wirklich, wirklich schwer am Anfang.

00:17:39.530 --> 00:17:43.468
Weil das auch kein Konzept ist, was man jetzt auch aus der anderen Sprache so kennt.

00:17:43.468 --> 00:17:46.568
Das muss man erst mal lernen. Aber selbst wenn man es gelernt hat,

00:17:46.568 --> 00:17:49.968
heißt es halt nicht, dass man es auch verstanden hat und anwenden kann.

00:17:49.968 --> 00:17:53.862
Und ich hatte einfach so viele Fälle. Und das Schlimmste dabei ist, dass du ...

00:17:53.907 --> 00:17:59.868
Der Rust-Compiler geht in zwei Stufen vor. Der guckt halt erst, ob alles syntaktisch okay ist.

00:17:59.868 --> 00:18:03.620
Und wenn dann alles okay ist, dann sagt er, so jetzt gucke ich mir mal die Lifetimes an.

00:18:03.868 --> 00:18:07.868
Und wenn du halt eine Änderung machst, jetzt hast du eine etwas größere Codebase,

00:18:07.868 --> 00:18:09.868
dann wühlst du dich einmal durch deine ganze Codebase.

00:18:09.868 --> 00:18:11.868
Du änderst irgendwie an 120 Stellen zwei und änderst den Code,

00:18:11.868 --> 00:18:15.868
bis dann alle Fehler weg sind. Und dann kommt er aber mit 500 Lifetime-Fehlern.

00:18:15.868 --> 00:18:19.868
Weil die Idee, die du anfangs hattest, die funktioniert so nicht.

00:18:19.868 --> 00:18:23.868
Aber das sagt er dir halt erst, nachdem du an allen Stellen alles geupdatet hast. Dann bekommst du die Information,

00:18:23.868 --> 00:18:25.868
dass dein Code gar nicht funktionieren kann.

00:18:27.314 --> 00:18:30.664
Willst du noch mal ganz kurz sagen, was das Konzept der Lifetimes ist?

00:18:30.704 --> 00:18:33.112
Oder vielleicht auch der Ownership? Beide?

00:18:33.841 --> 00:18:38.664
Ähm, klar, ich würde mit dem Ownership anfangen. Der ist, wie ich finde, einfacher zu verstehen.

00:18:38.936 --> 00:18:42.906
Der Ownership ist halt einfach nur die Idee, dass eine Variable jemandem gehören kann.

00:18:43.404 --> 00:18:47.930
Das bedeutet, als ganz einfaches Beispiel, du legst einen Integer an, hat den Wert fünf,

00:18:48.281 --> 00:18:54.044
und jetzt suchst du eine Methode auf, die heißt Hallo, und du übergibst halt diesen Integer, die Variable A,

00:18:54.084 --> 00:18:55.942
die den Wert fünf hat, und danach ist sie weg.

00:18:56.544 --> 00:19:01.104
Weil die Methode, in dem Moment, wo du die Methode aufrufst und diesen Wert übergibst,

00:19:01.334 --> 00:19:07.401
ist es so ein bisschen so, als wenn du ihn da reinlegst und in die Methode, und er kommt nicht wieder raus, diese Variable.

00:19:07.584 --> 00:19:11.744
Denn sie ist jetzt quasi aufgegessen. Ich seh das immer so ein bisschen so,

00:19:11.784 --> 00:19:14.944
Funktionen sind kleine Monster, die essen ihre Parameter auf.

00:19:14.984 --> 00:19:20.344
Und das ist halt ownership. Und das hat aber den Sinn, dass irgendwie nicht alle möglichen Methoden

00:19:20.384 --> 00:19:26.884
zugleich auf so einer Variablen rumwursten, sondern dass erst mal eine Methode fertig werden muss

00:19:26.884 --> 00:19:30.105
und dann kann die das weitergeben an die nächste, oder?

00:19:30.384 --> 00:19:36.020
Genau. Genau. Das ist doch so die Grundidee dahinter. Genau, die Grundidee ist, weil Rust ja so low-level ist,

00:19:36.384 --> 00:19:42.303
möchtest du halt verhindern, dass zwei Methoden gleichzeitig irgendwas editieren können, zum Beispiel.

00:19:43.384 --> 00:19:49.384
Und das ist halt auch einigermaßen einfach. Und du kannst halt dann aber eben auch Referenzen vergeben.

00:19:49.384 --> 00:19:54.258
Du kannst halt dann sagen, diese Variable in die Methode zu geben, und sie ist dann weg,

00:19:54.366 --> 00:19:57.464
kannst du halt auch nur eine Referenz, also verleihen quasi,

00:19:57.464 --> 00:20:01.844
kannst sagen, ich geb diese Variable weiter, dann kannst du sie aber eben nicht editieren,

00:20:01.844 --> 00:20:03.648
wenn du sie halt nur verleihst.

00:20:03.844 --> 00:20:07.807
Und dann ist sie so ein bisschen daran gebunden, dass du sie ja woanders noch hast.

00:20:08.644 --> 00:20:14.084
Und dann musst du so ein bisschen Rust-Compiler versichern, dass das Original dieser Variable,

00:20:14.084 --> 00:20:18.044
dass die halt so lange bestehen bleibt, wie diese Methode halt auch immer irgendwas damit macht.

00:20:18.044 --> 00:20:21.121
Und das ist dann so ein bisschen die Lifetime, Dass du halt sagst...

00:20:22.201 --> 00:20:26.954
Du kannst es dieser Methode nur geben, solange die Methode nicht länger benötigt,

00:20:27.279 --> 00:20:29.351
als der Code, wo sie herkommt.

00:20:29.351 --> 00:20:33.051
Das heißt, wenn du in deiner Methode einen Thread aufmachst und da irgendwas machen willst,

00:20:33.051 --> 00:20:35.451
das geht halt nicht, dann sagt der Rust-Compiler, das kannst du aber jetzt nicht machen,

00:20:35.451 --> 00:20:41.351
weil ich weiß ja gar nicht, wie lange dieser Thread jetzt mit dieser geliehenen Variablen darum experimentiert ist.

00:20:41.351 --> 00:20:45.238
Bis dahin kann die Stelle, wo sie herkommt, die Variable ja nicht mehr da sein.

00:20:45.454 --> 00:20:48.351
Und bei einem Garbage-Collector hast du das natürlich nicht,

00:20:48.351 --> 00:20:50.982
weil der kümmert sich da, aber Rust hat eben keinen Garbage-Collector.

00:20:51.396 --> 00:20:58.451
Und die Schwierigkeit bei Lifetimes ist dann eben, dass du manchmal Situationen hast, wo du eine Variable hast,

00:20:58.451 --> 00:21:01.751
die wird dir übergeben als Referenz, du wirst sie noch mal für anders verwenden,

00:21:01.751 --> 00:21:09.851
und jetzt ist es aber so, du musst dann dem Rust-Compiler den Proof geben, dass diese Variable lange genug überleben kann,

00:21:09.851 --> 00:21:11.129
aber sie kommt ja schon woanders her.

00:21:11.251 --> 00:21:13.751
Und dann musst du halt das irgendwie alles nachweisen.

00:21:14.126 --> 00:21:18.251
Und das ist halt manchmal sehr, sehr schwierig. Und gerade, sobald es um Threading geht,

00:21:18.474 --> 00:21:22.331
und um Async-Await ist es richtig schwierig.

00:21:22.453 --> 00:21:30.571
Weil da implizit ja Threads gemacht werden, oder halt Green Threads, und da sind die Lifetimes

00:21:30.571 --> 00:21:32.410
halt tatsächlich echt manchmal so ein bisschen ein Nightmare.

00:21:32.571 --> 00:21:36.740
Und was man dann halt einfach macht, ist, dann legt man stattdessen Kopien an. Das ist viel einfacher.

00:21:38.514 --> 00:21:46.131
Ja, vielen Dank für die Erklärung. Kann man gut verstehen. Vielleicht nach dem kleinen Ausflug da auch noch mal in die Interne

00:21:46.131 --> 00:21:50.771
Wenn wir noch mal zurückkommen zu dem Cross-Platform-Client,

00:21:50.771 --> 00:21:52.931
man möchte jetzt irgendwie den bauen.

00:21:52.931 --> 00:21:58.611
Wieso sollte man sich denn vielleicht auch überlegen, Rust so mit in die Verlosung zu nehmen?

00:21:58.611 --> 00:22:02.991
Ich meine, wir haben schon Flutter angesprochen, React Native, ja, gibt's ja.

00:22:04.251 --> 00:22:08.410
Also warum ist Rust dann ein valider Partner daneben sozusagen?

00:22:08.563 --> 00:22:14.411
Also ich glaube, so React Native und Flutter haben so ein bisschen ein anderes Ziel.

00:22:14.604 --> 00:22:18.151
Weil da wird dir die komplette Anwendung abgedeckt.

00:22:18.475 --> 00:22:23.891
Und da läufst du so ein bisschen eben in dieses Problem, dass du sicherstellen musst,

00:22:23.891 --> 00:22:26.651
dass es ein Plugin für deine Kamera gibt, was gut funktioniert.

00:22:26.651 --> 00:22:33.251
Ich hatte jetzt ein Flutter-Projekt letztes Jahr. Und da gab's auf der Android-Seite kein vernünftiges Kameramodul,

00:22:33.251 --> 00:22:35.591
was die Funktionen hatte, die wir brauchen.

00:22:35.591 --> 00:22:38.451
Und dann mussten wir dann ein Kotlin-Plugin schreiben und so was.

00:22:38.451 --> 00:22:46.967
Und dann hast du jetzt schon zwei Sprachen in der Codebase. Und der Vorteil bei Rust ist, dass du ...

00:22:48.497 --> 00:22:53.347
Solange wie du nicht alles damit schreibst, sondern halt nur gewählte Funktionalitäten, wie gesagt,

00:22:53.347 --> 00:22:56.347
und immer noch so einen Native Core hast, bei dem du viel machst,

00:22:56.347 --> 00:22:59.347
kannst du dir sicher sein, dass das hoch performant ist.

00:22:59.347 --> 00:23:05.124
Da der Rust-Compiler so genau ist, ist die Anzahl, dass du denkst, welche Bugs das hat, auch sehr gering.

00:23:05.347 --> 00:23:10.347
Und es gibt gute Projekte. Zum Beispiel gibt es eins von Mozilla, das heißt Unify,

00:23:10.347 --> 00:23:17.169
die dir automatisch aus seinem Rust-Code Libraries für Android und iOS jetzt machen oder für Windows, glaube ich.

00:23:17.347 --> 00:23:19.827
Und das heißt, du musst dich jetzt nicht damit auseinandersetzen,

00:23:19.827 --> 00:23:22.347
jetzt habe ich diesen Code, wie mache ich denn daraus was anderes?

00:23:22.347 --> 00:23:27.587
Und das Abstraktionslevel ist eben nicht eine komplett andere App mit anderen Developer-Tools.

00:23:27.587 --> 00:23:35.707
Du hast halt immer noch Xcode, du hast immer noch IntelliJ. Du teilst halt nur deinen Code zwischen den unterschiedlichen Plattformen,

00:23:35.707 --> 00:23:39.135
also deine Logik. Und das ist so ein bisschen, glaube ich, ein vorteilhafter Weg.

00:23:40.134 --> 00:23:42.747
Ist natürlich nicht das, was ich bei diesem Master-on-Client gemacht habe,

00:23:42.747 --> 00:23:45.671
Aber da ging's mir auch darum, Erfahrungen zu sammeln.

00:23:48.747 --> 00:23:52.683
Lass uns noch schnell sagen, wie der heißt. Ich glaub, das haben wir noch gar nicht gemacht. Der heißt EBU.

00:23:54.079 --> 00:24:00.747
Genau, und den hast du auch für alle denkbaren Plattformen am Start, ne? Ja, so ein bisschen.

00:24:00.747 --> 00:24:04.747
Also, der läuft halt am besten unter MacOS, weil das nutze ich halt nativ.

00:24:04.747 --> 00:24:08.747
Dann unter Windows hab ich ihn einmal gestartet, dann bin ich wieder rausgegangen.

00:24:08.747 --> 00:24:10.616
Da halte ich mich nie lange auf.

00:24:10.747 --> 00:24:15.627
Unter Linux läuft das auch, da ist es natürlich so, je nach Distribution muss man wissen,

00:24:15.687 --> 00:24:17.927
welche Pakete man installiert und so weiter.

00:24:18.286 --> 00:24:24.182
Ich glaub, es gibt in der Readme Erklärungen für Debian, für Ubuntu logischerweise, für Arch und für noch irgendwas.

00:24:24.344 --> 00:24:26.527
Da verliert man noch schnell den Überblick.

00:24:26.892 --> 00:24:32.887
Und es läuft halt auch am iPad, aber so halb gar. Da hab ich jetzt einen Branch, der noch nicht fertig ist.

00:24:32.947 --> 00:24:34.868
Also da läuft's, aber nicht gut.

00:24:35.174 --> 00:24:38.087
Und da will ich aber nach und nach das dann noch optimieren.

00:24:38.087 --> 00:24:44.487
Ich hatte jetzt im Sommer auch nicht ganz so viel Zeit, da reinzuschauen, seit das neue Zelda erschienen ist.

00:24:45.500 --> 00:24:49.983
Oh ja, ja. Priorität. Lach mal.

00:24:51.333 --> 00:24:55.583
Dann hast du dich entschieden, genau diesen Client zu schreiben.

00:24:55.583 --> 00:24:59.840
Du hast ja schon gesagt, hauptsächlich auch, um herauszufinden,

00:25:00.209 --> 00:25:03.414
kann man eigentlich Rust dafür so verwenden.

00:25:03.523 --> 00:25:10.913
Was hast du denn sonst noch irgendwie für Vorteile festgestellt während der Entwicklung? Also, was hat dich überrascht vielleicht auch?

00:25:11.192 --> 00:25:14.683
So ein bisschen überrascht hat mich, also, was heißt überrascht,

00:25:14.683 --> 00:25:21.083
aber was natürlich schon schwieriger ist, ist, dass, wenn ich jetzt so den React-Type-Written-Script-Vergleich nehme,

00:25:21.083 --> 00:25:23.583
Da ist es sehr angenehm, Komponenten zu definieren,

00:25:23.643 --> 00:25:26.783
weil du dich nicht mit Memory Management herumschlagen musst.

00:25:27.144 --> 00:25:31.783
Und das nimmt einem dieses Dioxys halt auch ab, aber nur bis zu einem begrenzten Level.

00:25:31.843 --> 00:25:35.023
Ab und zu gibt's schon Situationen, wo der Rust-Compiler sagt,

00:25:35.083 --> 00:25:40.123
das will ich jetzt aber nicht, weil ich da die Lifetime, wir hatten das Thema, nicht berechnen kann,

00:25:40.183 --> 00:25:42.196
und jetzt weiß ich nicht, wem das hier gehört.

00:25:42.898 --> 00:25:47.283
Und das ist ein Context-Switch, der tatsächlich in der UI-Entwicklung sehr unangenehm ist.

00:25:47.343 --> 00:25:52.683
Weil in dem Fall möchte ich ja quasi grade eine Struktur definieren und sehen, wie es im UI aussieht.

00:25:52.864 --> 00:25:57.683
Und jetzt muss ich mir plötzlich Gedanken darüber machen, wo denn dieser Speicher hinkommt.

00:25:57.683 --> 00:26:03.683
Und das ist so, das hatte ich halt bei anderen Sprachen so vorher noch nicht, weil auch Zwift eben zwar nicht

00:26:03.683 --> 00:26:06.655
Garbage-Collected, aber sehr ähnlich funktioniert.

00:26:06.727 --> 00:26:11.683
Und da muss man sich halt dahin keine Gedanken zu machen. Und wenn man so ein Command-Line-Tool schreibt,

00:26:11.683 --> 00:26:13.683
ist das nicht so das Problem.

00:26:13.812 --> 00:26:17.683
Aber mir ist aufgefallen, wenn du UI baust, dann ist das ein sehr unangenehmes Problem,

00:26:17.683 --> 00:26:18.646
weil du gerade vom Kontext her einfach was ganz anderes machst.

00:26:19.744 --> 00:26:24.523
Weil man sich halt nicht so viel mit der UI und dem Frontend beschäftigt,

00:26:24.588 --> 00:26:27.099
meinst du, sondern halt eher mit so ...

00:26:28.251 --> 00:26:31.523
Also, man wird aus dem Flow gerissen, so hab ich das verstanden.

00:26:31.563 --> 00:26:37.416
Man will eigentlich was ganz anderes machen und muss sich dann erst mal um so einen Nebenkriegsschauplatz kümmern,

00:26:37.603 --> 00:26:40.903
um sozusagen die Grundlage zu schaffen, weitermachen zu können.

00:26:40.943 --> 00:26:45.797
Genau, und eigentlich ist die Aufgabe kognitiv in mir in der Anderen gefühlt.

00:26:45.977 --> 00:26:52.045
Mhm. erst mal so das Gehirn kurz stopp, umdrehen, Kehrtwende.

00:26:53.215 --> 00:27:01.065
Okay, also du hast erzählt, dass du sozusagen so eine Webview dann aber dennoch benutzt,

00:27:01.065 --> 00:27:07.065
wo du quasi so Diffs reinschickst, wo die UI gepatcht werden muss.

00:27:07.065 --> 00:27:18.065
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,

00:27:18.065 --> 00:27:21.685
Oder ist das nur jetzt bei Dioxys der Fall,

00:27:21.745 --> 00:27:23.345
dass die so ein Konzept haben?

00:27:23.405 --> 00:27:26.485
Was Dioxys da macht, find ich, ist eigentlich ganz schlau.

00:27:26.545 --> 00:27:29.566
Man muss halt dazu sagen, das Framework hat eine Version 0.4.

00:27:29.885 --> 00:27:33.985
Und die haben einen langen Zeitplan, was wir machen möchten.

00:27:34.045 --> 00:27:38.385
Aber dieser WebView ist halt als Renderer definiert.

00:27:38.649 --> 00:27:44.005
Und das ist halt derzeit der Standard-Renderer für Dioxys. Es gibt noch einen weiteren, der heißt Blitz.

00:27:44.065 --> 00:27:51.465
Und Blitz nutzt WebGPU, um halt alles zu zeichnen. wirklich ein natives Zeichnen, denn diese leichten Patches,

00:27:51.465 --> 00:27:56.045
die da geschickt werden, die kann man prinzipiell ja auch mit einem anderen Renderer abdecken.

00:27:56.213 --> 00:27:59.045
Das muss ja nicht der WebView sein, nur der funktioniert halt sehr gut.

00:27:59.045 --> 00:28:08.545
Da sind halt Millionen an Performance-Optimierung reingeflossen in CSS und JavaScript und HTML, das kann man schon ganz gut verwenden.

00:28:08.636 --> 00:28:13.045
Wenn man aber jetzt spezifische Anforderungen hat, kann man eben auch einen anderen Renderer verwenden.

00:28:13.326 --> 00:28:17.045
Witzigerweise hat per Default Dioxos auch noch einen Terminal-Renderer.

00:28:17.045 --> 00:28:21.545
D.h. du schreibst deine App, die läuft in WebView, du kannst sie in die Plattform schieben,

00:28:21.545 --> 00:28:24.930
du kannst auch eine Web-App draus machen, und sie läuft auch im Terminal.

00:28:25.045 --> 00:28:28.545
Tatsächlich mit Flexbox und allem Pipapo und so begrenzten CSS.

00:28:28.545 --> 00:28:35.418
Das ist halt so ein witziger Zeiteffekt, den man dann hat. Natürlich kann man nicht jede beliebige App da laufen lassen.

00:28:36.045 --> 00:28:40.045
Vor einer Komplexität her. Man könnte sogar einen Renderer schreiben,

00:28:40.045 --> 00:28:49.385
der die Messages abfängt und dann native Buttons hinsetzt. Das wird natürlich auch funktionieren, das hat nur noch keiner gemacht.

00:28:51.307 --> 00:28:56.417
Und ist es dann so, wenn die Webview nur sozusagen wie so ein Renderer ist,

00:28:56.477 --> 00:29:00.021
also so, ich weiß nicht, es gab ja auch mal Plugins für React,

00:29:00.137 --> 00:29:02.837
glaub ich, dass man in die Canvas reinrendern kann.

00:29:02.897 --> 00:29:06.897
Ich glaub, Flipboard hatte das damals gemacht. Ähm, heißt das dann,

00:29:06.957 --> 00:29:10.477
dass du im Grunde auch ohne Webtechnologien auskommst?

00:29:10.537 --> 00:29:14.100
Das heißt, eigentlich wüsstest du nicht, dass es eine Webview wäre,

00:29:14.262 --> 00:29:16.540
würdest du's wahrscheinlich gar nicht merken.

00:29:17.017 --> 00:29:19.286
Also geht das so weit? Ja, das wär der Goldstandard.

00:29:19.577 --> 00:29:22.877
Ähm, weil aber Vraxos und Diaxos so jung ist,

00:29:22.877 --> 00:29:25.866
musste ich an zwei, drei Stellen, du hast die Möglichkeit halt,

00:29:26.244 --> 00:29:31.017
ähm, JavaScript an den WebView zu schicken, um Dinge zu machen,

00:29:31.017 --> 00:29:32.744
und an zwei, drei Stellen musste ich das halt machen.

00:29:33.017 --> 00:29:37.017
Ein Beispiel ist, jetzt seit der Version 0.4, die jetzt gerade rausgekommen ist,

00:29:37.017 --> 00:29:41.717
kannst du halt so ein Unmounted-Event bekommen, wo du halt mitbekommst, dass deine Komponente sichtbar wird.

00:29:41.717 --> 00:29:44.217
Das gab's vorher nicht. Das war für mich aber wichtig,

00:29:44.217 --> 00:29:46.707
weil ich möchte ja sehen, wann der User etwas sieht,

00:29:46.842 --> 00:29:51.357
damit ich sagen kann, Er hat dieses Mastodon, wie nennt man das, Posts auch schon gesehen.

00:29:51.357 --> 00:29:57.877
Und das habe ich dann über die JavaScript API gemacht, die dann quasi eine Message zurück an den Rust schickt.

00:29:57.877 --> 00:29:59.022
Das ist halt ein bisschen umständlich.

00:29:59.157 --> 00:30:04.357
Aber mir hätte es zu dem Zeitpunkt noch keine andere Lösung gegeben.

00:30:04.357 --> 00:30:08.037
Ich glaube, der langfristige Plan ist halt, dass diese ganzen Interaktionen,

00:30:08.037 --> 00:30:11.357
die jetzt noch nicht abgedeckt werden, so bis zu 1.0 dann abgedeckt sind,

00:30:11.357 --> 00:30:18.340
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.

00:30:19.484 --> 00:30:32.744
Und du hast ja gesagt, dass du deine Anwendungen für verschiedene Desktop-Betriebssysteme gebaut hast, aber auch unter anderem für das iPad.

00:30:33.545 --> 00:30:39.834
Und das ist ja insofern ganz interessant, als dass so Dinge wie, ähm.

00:30:40.396 --> 00:30:43.826
Wie heißt das? Elektron. Genau.

00:30:44.042 --> 00:30:48.822
Dass es das zum Beispiel ja für mobile Geräte nicht gibt.

00:30:49.182 --> 00:30:57.446
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.

00:30:57.951 --> 00:31:06.474
Das scheint ja bei dir anders zu funktionieren. Also, das ist ja wirklich, ich kann theoretisch meine Anwendung

00:31:06.474 --> 00:31:10.274
dann für jede beliebige Zielplattform,

00:31:10.274 --> 00:31:13.714
die eine WebView theoretisch laufen lassen kann, ausliefern.

00:31:13.714 --> 00:31:18.114
Genau. In dem Fall ist es halt eben die Native WebView unter iOS.

00:31:18.323 --> 00:31:23.314
Und da verwendet es ein anderes Flask-Projekt, von dem vielleicht schon mal der eine oder andere gehört hat.

00:31:23.314 --> 00:31:24.165
Das heißt halt Taudi.

00:31:24.314 --> 00:31:28.954
Und Taudi ist eine Electron-Alternative, die halt genau dasselbe macht.

00:31:28.954 --> 00:31:35.954
Also, du schreibst in dem JavaScript-Framework deiner Wahl, deine App, und dann gibt es zusätzliche APIs,

00:31:35.954 --> 00:31:39.739
so wie bei Elektron, mit der du halt eben auf das Betriebssystem zugreifen kannst.

00:31:39.954 --> 00:31:44.954
Und Taudi 2.0, das jetzt demnächst irgendwann erscheint, hat halt dann auch Android- und iOS-Support.

00:31:45.329 --> 00:31:49.954
Und das ist, was Dijaxus unter der Haube verwendet, um eben diese Möglichkeit zu haben,

00:31:49.954 --> 00:31:51.892
auf die unterschiedlichen Betriebssysteme zu gehen.

00:31:52.045 --> 00:31:57.454
Und das ist natürlich auch attraktiv, wenn man jetzt sagt, Ich will jetzt mit Rust gar nichts zu tun haben.

00:31:57.494 --> 00:32:02.634
Ich hab aber jetzt meinen SolidJS oder so, und ich möchte aber jetzt doch ganz gerne iOS-App machen.

00:32:02.674 --> 00:32:03.694
Das würde halt mit Tauri ohne Probleme gehen.

00:32:05.449 --> 00:32:10.634
Okay. Na, das ist auch gut zu wissen. Also, dass Tauri kein irgendwie Rust-Projekt ist,

00:32:10.674 --> 00:32:17.294
sondern im Prinzip so ein Elektron-Konkurrent oder wie auch immer man das sehen kann.

00:32:17.521 --> 00:32:23.794
Ich glaub, bei Elektron ist es so, dass die sozusagen immer eine gewisse Chrome-Engine-Version

00:32:23.794 --> 00:32:28.794
mitliefern, was natürlich auch seine Vorteile hat, weil man weiß ja immer, was man kriegt.

00:32:28.794 --> 00:32:35.794
Das ist ja auch nicht verkehrt. Und bei der nativen Webview wird das wahrscheinlich wieder so ein

00:32:35.794 --> 00:32:37.794
bisschen aus dem Leim gehen.

00:32:37.794 --> 00:32:47.794
Die eine Plattform kann das, die andere kann das nicht. Also so das klassische Frontend rumgepopelt.

00:32:47.794 --> 00:32:51.794
Genau, das ist auch so ein bisschen ein Problem, gerade weil ja auch ältere iOS-Versionen,

00:32:51.794 --> 00:32:56.934
dann zum Beispiel ältere Safari-Engines haben und dann noch mal weniger können und Windows

00:32:56.934 --> 00:33:02.614
verwendet dort auch kein Webkit, sondern Windows verwendet halt auch Blink, heißt sie glaube ich,

00:33:02.614 --> 00:33:07.614
die Chrome Engine, weil sie ja Edge rausgebracht haben und Edge ist ja Blink.

00:33:09.879 --> 00:33:12.729
Und da muss man dann schon irgendwie auch so ein bisschen drauf achten,

00:33:12.729 --> 00:33:16.108
dass das alles passt, aber das muss man ja eh, wenn man Frontend macht, wie du sagst.

00:33:17.234 --> 00:33:24.729
Ja, na ja, genau. Das gehört ja so ein bisschen dazu. Ich musste auch so ein bisschen, als ihr eingangs sauber sprach,

00:33:24.729 --> 00:33:29.711
wie jetzt zum Beispiel man eine Zahlung anstoßen kann auf den verschiedenen Betriebssystemen, hab ich gedacht,

00:33:29.810 --> 00:33:38.729
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,

00:33:38.729 --> 00:33:42.872
dann hinten raus irgendwie umsetzt auf die verschiedenen Plattformen.

00:33:45.060 --> 00:33:48.109
Ja, ich hoffe so ein bisschen, dass so langfristig sowas wie Taudi das hat bietet.

00:33:48.309 --> 00:33:52.529
Anstatt halt nur die Funktionen, sagen wir mal, Taudi hat eine Funktion, um aufs

00:33:52.529 --> 00:33:55.749
Clipboard zuzugreifen. Und anstatt halt nur das zu haben, hat es eben auch eine

00:33:55.749 --> 00:34:04.109
Funktion, um zu sagen, öffnen Payment Screen oder öffne den Camera View oder öffne den den Album View, diese

00:34:04.109 --> 00:34:08.389
Sachen halt. Aber haben wir auch kurz am Anfang drüber geredet, dass es so schwer

00:34:08.573 --> 00:34:13.269
zu generalisieren, weil die Plattformen da halt so unterschiedlich agieren und dadurch

00:34:13.269 --> 00:34:17.269
unterschiedliche Daten zurückgeben und so.

00:34:16.288 --> 00:34:23.838
Ja, definitiv. Ja, stelle ich mir auch schwierig vor. Ich würde noch mal einmal bei diesen Webviews nachfragen wollen.

00:34:23.976 --> 00:34:28.784
Und zwar, wenn es um das Thema Performance geht. Also grundsätzlich habe ich irgendwie immer im Hinterkopf,

00:34:29.207 --> 00:34:34.167
gerade so eine Webview zu starten, zum Beispiel auf iOS, dauert eine gewisse Zeit.

00:34:34.842 --> 00:34:41.891
Und dann halt irgendwie dann den Content darauf anzuzeigen, ist jetzt auch nicht unbedingt immer so schnell wie im Safari nativ.

00:34:42.332 --> 00:34:46.878
Sind diese Aussagen überhaupt richtig? Oder habe ich da was Falsches eigentlich im Kopf?

00:34:47.301 --> 00:34:53.378
Nee, es ist schon richtig. Also, es ist halt so, dass der WebView, den du unter iOS hast,

00:34:53.621 --> 00:34:58.118
der kann kein Jett, außer in Safari, aus Sicherheitsgründen.

00:34:58.118 --> 00:35:03.998
Das heißt, du kannst jetzt einen Speicherblock, wo jetzt dein JavaScript-Code einmal executed war,

00:35:03.998 --> 00:35:09.318
dann wird der normalerweise, wird der dann halt darunter kompiliert in eine schnellere Repräsentation,

00:35:09.366 --> 00:35:14.478
und dann wird der Speicherblock als executable markiert, und dann hast du plötzlich deinen schnellen JavaScript-Jettet.

00:35:14.478 --> 00:35:18.260
Und das geht nur in Safari, das geht aber eben nicht in so einem Webview.

00:35:18.503 --> 00:35:20.898
Und deswegen ist es halt traditionell langsamer.

00:35:21.213 --> 00:35:24.913
Aber das Problem hast du natürlich bei Dioxos nicht, weil du ja gar keinen JavaScript-Code hast.

00:35:25.078 --> 00:35:32.578
Sondern da läuft ja alles in Rust, bei Nativ. Und es wird ja nur das Letztelement der ganzen Kalkulationen

00:35:32.578 --> 00:35:34.338
wird halt in den Webview gehoben, mehr nicht.

00:35:34.941 --> 00:35:39.178
Und das eigentliche Starten ist inzwischen halt auch genauso schnell,

00:35:39.178 --> 00:35:41.171
weil ich meine, da stecken M1-Prozessoren drin.

00:35:41.603 --> 00:35:46.778
Also klar, wenn man jetzt, ich hab's jetzt natürlich nur mit iPads versucht und auch nicht mit alten iPads,

00:35:46.778 --> 00:35:51.082
sondern nur mit dem, was ich gerade so zu Hause rumliegen hab, da war die Performance sehr, sehr gut.

00:35:51.244 --> 00:35:54.778
Aber da will ich mich jetzt eigentlich nicht aus dem Fenster lehnen, weil ich jetzt mich irgendwie,

00:35:54.845 --> 00:35:57.978
zum einen ist Evo keine App, die irgendwie eine Million Objekte darstellt,

00:35:57.978 --> 00:36:00.418
und zum anderen hab ich halt mit zwei iPads getestet.

00:36:00.643 --> 00:36:07.378
Also da ist... Testmenge noch relativ überschaubar, sagen wir mal, aber grundsätzlich ist das natürlich ein,

00:36:07.378 --> 00:36:10.218
also hat sich das ja auch weiterentwickelt, sehr wahrscheinlich.

00:36:10.218 --> 00:36:15.478
Eine Sache, die ich halt beispielsweise jetzt so als Vergleich auch immer im Kopf habe, ist mit Flutter.

00:36:16.117 --> 00:36:32.196
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.

00:36:32.682 --> 00:36:37.732
Und wenn man das halt, sag ich mal, parallel in der gleichen App mit einer nativen App

00:36:38.164 --> 00:36:46.626
oder einem nativen Teil-App sozusagen kombiniert hat, hatte man immer praktisch eine, das Problem, dass man diesen Flutter-Teil

00:36:46.716 --> 00:36:52.548
starten musste und bis diese Engine dann da war, hat halt gedauert und es war halt einfach nicht usable.

00:36:52.548 --> 00:36:58.086
Ja, das konntest du halt vergessen, so. Und sowas, das sind immer so die Punkte, die ich irgendwie im Kopf hab.

00:36:58.518 --> 00:37:04.268
Ja, das ist auch so ein bisschen, ähm, auf iOS eine Zeit lang ein echtes Problem gewesen.

00:37:04.268 --> 00:37:07.268
Wir hatten eine Zeit lang, ich hab ja wie gesagt früher bei Xing gearbeitet,

00:37:07.268 --> 00:37:11.268
und wir hatten eine Zeit lang das Problem, dass die Xing irgendwie 10 Sekunden zum Laden gebraucht hat,

00:37:11.268 --> 00:37:13.268
und das war aber nicht so richtig unsere Schuld.

00:37:13.462 --> 00:37:17.268
Das Problem war halt, dass, ähm, wenn man ein großes Unternehmen ist,

00:37:17.268 --> 00:37:24.268
teilt man dann seinen Code in mehrere Dependencies auf, und wenn du das aber bei iOS gemacht hast, mit jeder zusätzlichen Dependency

00:37:24.268 --> 00:37:26.920
ist die App quasi eine halbe Sekunde langsamer geworden.

00:37:27.586 --> 00:37:43.268
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.

00:37:43.268 --> 00:37:53.268
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.

00:37:53.990 --> 00:38:17.567
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.

00:38:18.071 --> 00:38:21.328
Ja, so ein bisschen. Und die Geräte sind dann auch schneller geworden.

00:38:21.393 --> 00:38:24.768
Und Apple hat diese Probleme, die dazu geführt haben, mal doch beruhmt,

00:38:24.768 --> 00:38:26.605
warum das so langsam gestartet ist.

00:38:26.668 --> 00:38:29.168
Also, ich würde sagen, dass das heute nicht mehr der Fall ist.

00:38:29.225 --> 00:38:30.926
Aber da habe ich jetzt auch noch kein Experiment gemacht.

00:38:31.386 --> 00:38:35.004
Also, wenn dieses neue Taudi 2.0 das zur richtigen iOS-Support bietet,

00:38:35.464 --> 00:38:38.048
rauskommt, bin ich auch total interessiert, da mal was zu machen,

00:38:38.048 --> 00:38:41.261
um zu schauen, wie schnell bootet das, wie fühlt sich das an.

00:38:42.314 --> 00:38:47.887
Eben wieder wegen dieser alten Fragestellung, Wie kann man im besten Code über mehrere Plattformen teilen?

00:38:50.849 --> 00:38:55.699
Ja, und, ähm, ich glaub, oder, Shep?

00:38:57.384 --> 00:39:02.300
Äh, ich hab nur gleich ne andere Frage. Dann mach mal.

00:39:02.930 --> 00:39:11.699
Dann mach mal. Genau, ich würde fragen, wenn man sowas mit so einem Setup entwickeln möchte,

00:39:11.699 --> 00:39:13.417
wie du es verwendest, also

00:39:13.699 --> 00:39:25.336
Rust sozusagen im Kern und Und dann eben Frontend möglicherweise über WebView dann gerendert und zukünftig über WebGPU und Co.

00:39:25.699 --> 00:39:34.563
Würdest du sagen, Dioxys ist so das Framework, das man sich angucken sollte?

00:39:34.699 --> 00:39:40.699
Also weil es irgendwie gut zu programmieren ist und vielleicht auch eine gute Dockwatt?

00:39:40.699 --> 00:39:46.999
Oder was gibt's da noch für Konkurrenten, die dir aufgefallen sind, wo du sagen würdest,

00:39:47.039 --> 00:39:48.409
die sind einen Blick wert?

00:39:49.439 --> 00:39:54.603
Also, Deoxys hat auf jeden Fall den Vorteil, dass es für ein Rust-Projekt ...

00:39:55.845 --> 00:39:58.879
Angenehm zu programmieren ist. Also, du musst dich halt ...

00:39:58.919 --> 00:40:01.339
Ich hab jetzt über die Lifetimes 4 geschimpft,

00:40:01.379 --> 00:40:04.059
aber sie tauchen in Dijexos Prinzip sehr selten auf.

00:40:04.099 --> 00:40:06.519
Und Rust ist auch voll von Generics.

00:40:06.738 --> 00:40:10.939
Die tauchen da auch sehr selten auf. Das heißt, da muss man sich jetzt gar nicht so mit rumschlagen.

00:40:10.939 --> 00:40:17.730
Und es gibt halt zwei, drei andere Frontend-Rastprojekte, die auch ziemlich gut sind. Eins heißt Iced.

00:40:19.170 --> 00:40:22.439
Eins heißt Xelem, aber die sind teilweise dann nicht unbedingt so weit entwickelt.

00:40:22.439 --> 00:40:23.939
Und da sind Unterschiede.

00:40:23.939 --> 00:40:28.439
Also ich habe mit verschiedenen drum experimentiert. Und wenn jetzt das Ziel ist, eine App zu haben,

00:40:28.439 --> 00:40:30.939
die möglichst native Charakteristika an den Tag legt.

00:40:30.939 --> 00:40:35.439
Also wo du sagst, ich hätte eigentlich, am liebsten hätte ich kein WebView,

00:40:35.439 --> 00:40:37.939
sondern so ein natives Zeichnen mit WebGPU.

00:40:37.939 --> 00:40:46.939
Und wenn du dann vielleicht nur anfängst und dann später halt irgendwie was anderes, dann ist Dioxys schon sehr interessant.

00:40:46.939 --> 00:40:51.939
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

00:40:51.939 --> 00:40:59.939
kommt, weil ja auch die ganzen, weil Dioxys ja prinzipiell so wie React aufgebaut ist. Du hast ein UseState, du hast ein UseEffect.

00:40:59.939 --> 00:41:05.939
Das heißt also, man ist relativ schnell, kommt, man weiß, man halt, was man macht und wie man die Dinge verwendet.

00:41:05.939 --> 00:41:08.673
Dann ist es, glaube ich, schon insgesamt am angenehmsten.

00:41:10.096 --> 00:41:14.930
Okay, ja, die anderen werden wir auf jeden Fall auch verlinken, die es noch gibt.

00:41:15.569 --> 00:41:19.665
Die kann man sich dann auf jeden Fall auch angucken in unseren Shownotes.

00:41:19.946 --> 00:41:25.480
Wie auch die anderen Sachen wie Tauri und natürlich dein Mastodon-Client.

00:41:25.946 --> 00:41:29.946
Kann man deinen Quelltext, deins Mastodon-Clients auch sehen?

00:41:29.946 --> 00:41:33.717
Also ist der sozusagen offen? Ja, der ist komplett offen.

00:41:33.946 --> 00:41:37.589
Ich hoffe immer, dass irgendjemand auch mal mitmachen will.

00:41:37.946 --> 00:41:52.902
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.

00:41:52.974 --> 00:41:56.646
Genau. Wobei meine App da vielleicht nicht das beste Beispiel ist,

00:41:56.646 --> 00:42:00.946
weil ich noch so eine zusätzliche Abstraktionsebene dazwischen geschoben habe,

00:42:00.946 --> 00:42:02.579
die so ein Reducer-Modell implementiert.

00:42:02.946 --> 00:42:07.966
Das hat Dioxys per Default nicht. Und ich fand's halt spannend, das zu machen.

00:42:08.026 --> 00:42:11.140
Würde ich im Nachhinein ehrlich gesagt nicht noch mal machen.

00:42:11.326 --> 00:42:15.466
Aber wie das oft so bei Entwicklungsentscheidungen ist, das klingt total gut.

00:42:15.526 --> 00:42:19.089
Und zwei, drei Monate später klingt's nicht mehr so gut, aber es ist halt nun mal fertig.

00:42:20.386 --> 00:42:25.327
Worüber wir noch nicht gesprochen haben, das haben wir nur kurz berührt,

00:42:25.715 --> 00:42:34.806
die mit Dioxys entwickelte Anwendung, hast du gesagt, könnte man auch direkt quasi als Web-App,

00:42:35.212 --> 00:42:42.486
also als Compile-Target eine Web-Anwendung sich aussuchen.

00:42:42.837 --> 00:42:48.046
Oder es wäre möglich, dass dann wahrscheinlich nach Wasm kompiliert.

00:42:49.859 --> 00:42:55.406
Hast du das auch gemacht? Ich weiß gar nicht. Ja, während der ganzen Entwicklungsphase

00:42:55.406 --> 00:42:57.526
hatte ich immer ein Wasm-Target.

00:42:57.526 --> 00:43:02.526
Einfach weil ich dann halt den angenehmen Reload-Vorteil hatte.

00:43:02.526 --> 00:43:05.926
Ich konnte dann meinen Code schreiben und der Browser hat direkt das UI aktualisiert.

00:43:05.926 --> 00:43:07.296
Das war halt super angenehm.

00:43:08.061 --> 00:43:12.931
Fundamental ist es halt eben eine Mastern-App. Und es gibt ein Mastern-Library, das die App verwendet.

00:43:13.067 --> 00:43:16.577
Und das hat kein WASM-Compile-Target.

00:43:16.749 --> 00:43:22.438
Das heißt, ich hatte halt während der Entwicklung dann immer so eine gemockte Version von diesem Library da drin. Und irgendwann...

00:43:23.924 --> 00:43:30.801
Habe ich das einfach rausgeworfen, weil es halt zu viel... weil ich einiges refactoren musste, und das ist halt dabei auf der Strecke geblieben.

00:43:31.269 --> 00:43:35.513
Also, was ich halt irgendwann machen müsste, wäre, quasi diesen Teil wegzuabstrahieren,

00:43:35.513 --> 00:43:41.262
dass ich da nicht direkt dieses Masteron-Library verwende, sondern etwas, was halt dann alternativ auf einen Server zugreift

00:43:41.460 --> 00:43:42.972
oder eben dieses Library verwendet,

00:43:43.602 --> 00:43:48.513
weil die Web App an sich ja nicht direkt die Queries zum Masteron-Server machen kann,

00:43:48.513 --> 00:43:49.652
auf jeden Fall nicht mit diesem Library.

00:43:49.913 --> 00:43:52.993
Oder halt das Library irgendwie auch WebAssembly-kompatibel machen.

00:43:53.181 --> 00:43:56.393
Daran scheitert's ein bisschen, aber der ganze Rest der Anwendung,

00:43:56.393 --> 00:43:59.978
quasi das UI und alles, läuft natürlich im Web.

00:44:00.491 --> 00:44:05.733
Nur eben nicht dieser eine Teil, das Masteron-Library. Und mir fehlt aber auch so ein bisschen die Lust,

00:44:05.733 --> 00:44:07.017
das zu machen, logischerweise.

00:44:07.621 --> 00:44:11.793
Weil es gibt ja immer so viele Aufgaben, die man machen kann,

00:44:11.793 --> 00:44:15.705
und da seh ich jetzt nicht einen großen Mehrwert, weil es ja schon eine sehr gute UI für Masteron gibt.

00:44:16.033 --> 00:44:21.268
Prinzipiell kann Dioxos das aber, und ein normales Dioxos-Projekt, wenn man jetzt nicht so Quatsch macht wie ich,

00:44:21.655 --> 00:44:24.500
kompiliert halt ohne Problem halt auch im Web.

00:44:24.572 --> 00:44:31.113
Das heißt, du hast dann deine eine Anwendung, du kannst dann iPadOS, macOS, Linux, Windows.

00:44:32.323 --> 00:44:34.942
Terminal und Web kompilieren aus einer Codebase.

00:44:36.149 --> 00:44:43.853
Und sehr cool. Das ist schon echt eine ganze Menge und kennt man so von anderen Projekten weniger. Also ich glaube,

00:44:43.853 --> 00:44:47.906
Projekt Native kann ja auch fürs Web kompiliert werden, meine ich, oder?

00:44:49.022 --> 00:44:56.197
Ist aber nur so ein, meine ich, mich erinnern zu können, aber für das Terminal definitiv schon mal nicht.

00:44:57.709 --> 00:45:00.293
Das ist schon cool, auch wenn es eine Spielerei ist.

00:45:01.877 --> 00:45:09.267
Ich glaub, React Native hat so ein Plugin auf jeden Fall von Nicolas Gallagher entwickelt vor einigen Jahren.

00:45:09.307 --> 00:45:11.007
Weiß aber nicht, ob das noch ...

00:45:11.067 --> 00:45:15.307
Ich glaub, das heißt dann sogar React Native Web, glaub ich. Ja, genau.

00:45:15.347 --> 00:45:19.927
Weiß nicht, ob das noch ein Thema ist. Was mich noch mal interessieren würde, Benedikt,

00:45:19.967 --> 00:45:21.079
wenn man jetzt sagen würde.

00:45:21.727 --> 00:45:28.020
Okay, ich würde gerne tiefer in dieses Thema einsteigen, Rust auch cross-Plattform zu verwenden als Frontend-App

00:45:28.326 --> 00:45:31.566
oder für die ausgeführten Tätigkeiten sozusagen.

00:45:31.710 --> 00:45:36.554
Wie steigt man da am besten ein? Gibt es da irgendwie Artikel, die du empfehlen kannst?

00:45:36.725 --> 00:45:41.147
Die Jungs von, also tatsächlich, würde ich jetzt einfach bei Dioxys bleiben.

00:45:41.147 --> 00:45:47.147
Es gibt halt eben andere Projekte, zum Beispiel Peer Stories oder so,

00:45:47.147 --> 00:45:51.647
die sind dann Fullstack Rust Frameworks zum Beispiel, die halt auch durchaus gut sind,

00:45:51.647 --> 00:45:53.226
aber da hat man jetzt gleich dann,

00:45:53.647 --> 00:45:56.647
die verlinken wir dann, glaube ich, auch, aber dann hat man gleich noch mal fünf weitere Projekte,

00:45:56.647 --> 00:45:57.647
die man sich anschauen müsste.

00:45:57.647 --> 00:46:00.527
Bei Dioxys, die haben ihre Documentation-Werte geupdatet.

00:46:00.647 --> 00:46:03.647
Und die haben jetzt einen relativ guten Flow, da kann man sich durchlesen,

00:46:03.647 --> 00:46:05.647
da sind viele Sample-Projects.

00:46:05.928 --> 00:46:11.383
Wenn man das GitHub-Repository auscheckt, da ist so ein Examples-Folder, der hat halt irgendwie, was weiß ich,

00:46:11.843 --> 00:46:14.647
50 Projekte und alle von denen sind sehr klein.

00:46:14.647 --> 00:46:17.647
Eins erklärt dann so ein bisschen Suspense, eins ist ein Calculator,

00:46:17.647 --> 00:46:22.647
eins zeigt, wie man irgendwie was drawt und so was, und da kann man so ein bisschen mit rumspielen, die modifizieren,

00:46:22.647 --> 00:46:24.647
wieder laufen lassen, das funktioniert eigentlich ganz gut.

00:46:24.851 --> 00:46:26.647
Ich glaube, so zum Rumspielen und so ein bisschen da reinkommen,

00:46:26.647 --> 00:46:28.308
das ist schon ganz angenehm.

00:46:28.749 --> 00:46:32.407
Und es gibt auch so ein Awesome Dioxys, wo dann halt andere Projekte verlinkt sind,

00:46:32.407 --> 00:46:35.843
wenn man sagt, okay, was machen denn Leute damit? Ich möchte mir den ZooScope mal ganz gerne anschauen.

00:46:36.127 --> 00:46:37.436
Da kann man dann auch noch Mat einschauen.

00:46:40.605 --> 00:46:59.672
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?

00:46:59.852 --> 00:47:01.922
Ja, ich weiß auch nicht, wie man das pronunzt.

00:47:02.093 --> 00:47:11.795
Auf jeden Fall über, ja, den verlinkt. Da geht's um die Bestimmung einer, was ist eigentlich eine native UI-Library?

00:47:12.401 --> 00:47:16.195
Genau, und also, ich war mir nicht sicher, inwiefern wir in dieses Thema gehen,

00:47:16.195 --> 00:47:20.495
weil man hat ja eben oft diese Kritik, dass ein WebView ja nicht richtig native ist.

00:47:20.584 --> 00:47:22.618
Und, ähm... Ja, genau.

00:47:22.726 --> 00:47:27.156
Genau, und was Herbert da sagt, ist so ein bisschen, richtig native ist auch einfach wahnsinnig schwer,

00:47:27.201 --> 00:47:29.895
weil es gibt eben auf der Rust-Seite viele Projekte, die versuchen,

00:47:30.226 --> 00:47:33.565
selber das UI zu malen, also mit Web-GPU oder mit anderen Methoden.

00:47:33.735 --> 00:47:40.135
Aber das schwierige Kunststück ist, wenn du jetzt, nur ein Beispiel zu nennen, zwei Beispiele, sagen wir mal,

00:47:40.135 --> 00:47:42.135
wenn du jetzt ein Video darstellen willst, du möchtest halt,

00:47:42.135 --> 00:47:44.135
das ist ja nicht ungewöhnlich, dass eine App ein Video zeigen soll.

00:47:44.323 --> 00:47:47.295
Und die Art und Weise, wie das bei einem modernen Betriebssystem halt läuft,

00:47:47.295 --> 00:47:54.175
dass es deine Anwendung, das Video ans Betriebssystem gibt, da hast du einen Compositor, der nimmt dieses Video,

00:47:54.175 --> 00:47:59.303
und dann nimmt der das, macht das, packt das in ein Texture in der GPU,

00:47:59.546 --> 00:48:04.425
dann nimmt er das Texture von deiner Anwendung, packt das auch in die GPU, und dann wird das zusammengefügt.

00:48:04.635 --> 00:48:10.235
Dadurch ist die Performance halt sehr hoch. Und das heißt, wenn du also dann so ein Library machst,

00:48:10.235 --> 00:48:13.335
dann musst du diesen Compositing-Step, den musst du halt quasi mit unterstützen,

00:48:13.335 --> 00:48:17.035
und dann ist es wahnsinnig aufwendig und in jedem Betriebssystem komplett anders.

00:48:17.035 --> 00:48:22.159
Und das zu machen, das schaffen schon die wenigsten, und wenigstens unter WebView kann das halt einfach.

00:48:22.664 --> 00:48:27.156
Und wenn du halt irgendwie einen Button malen willst, der Default WebView-Button ist halt einfach mal ein Native-Button.

00:48:27.335 --> 00:48:32.935
Das ist jetzt irgendwie so ein normaler Button im WebView. Der ist halt mehr native als der Button in Flutter oder in der anderen,

00:48:32.935 --> 00:48:34.772
weil das ist ein Native Besiegssystem Button.

00:48:35.879 --> 00:48:41.253
Und man lacht dann halt viel über den WebView, aber gleichzeitig ist dann auch CSS da so hoch optimiert,

00:48:41.460 --> 00:48:46.529
dass also in meinem Masterdom-Client, wenn ich da scrolle, das ist fünfmal schneller als SwiftUI,

00:48:46.682 --> 00:48:49.832
einfach weil das halt hoch native ist und da so viel rumoptimiert wurde.

00:48:50.093 --> 00:48:55.093
Was halt dann weniger native ist, ist dann eben, wenn du halt den JavaScript-Code, sagen wir mal, ausführst,

00:48:55.093 --> 00:48:57.538
gejittet und so weiter, da geht natürlich Performance verloren.

00:48:57.593 --> 00:49:02.593
Das Problem hast du bei der Yoxus gar nicht so sehr. Und dieser Artikel, der geht eben so ein bisschen darauf ein,

00:49:02.593 --> 00:49:12.086
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.

00:49:13.463 --> 00:49:27.246
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.

00:49:29.046 --> 00:49:33.153
Ja, da will ich die Gelegenheit direkt nutzen und auf einen anderen Podcast verweisen.

00:49:33.153 --> 00:49:35.546
Die Igalia Chats, die höre ich immer sehr gerne.

00:49:35.735 --> 00:49:42.393
Und die, also Igalia ist ja so quasi sowas wie Söldner Programmierer,

00:49:42.393 --> 00:49:45.016
die dann in Browsern Features implementieren.

00:49:45.241 --> 00:49:52.633
Also das machen die halt in allen Browsern. Und die haben vor ungefähr einem Monat eine Folge rausgebracht,

00:49:52.633 --> 00:49:58.133
First-Person-Scrollers, so das Thema, und da geht's quasi um die,

00:49:58.817 --> 00:50:06.633
um Browser und wie die es eben schaffen, also bei diesem komplexen Web, das wir haben mit den vielen Features,

00:50:06.633 --> 00:50:11.133
trotzdem eben alles in 60 Frames pro Sekunde zu rendern.

00:50:11.133 --> 00:50:18.633
Und das ist sehr, sehr spannend, diese Folge zu hören, mit einem, in dem Fall dann einem Chrome-Engineer,

00:50:18.633 --> 00:50:23.375
der dann über die Render Engine spricht.

00:50:24.635 --> 00:50:32.278
Genau. Werden wir auch verlinken dann. Ich finde halt echt, dass der WebView da teilweise seinen Beruf zu Unrecht hat.

00:50:32.404 --> 00:50:37.445
Ich glaube, oftmals auch einfach, weil man besucht dann so eine Webseite und die ist unglaublich langsam,

00:50:37.445 --> 00:50:40.119
aber das liegt halt daran, dass da 700 Tracking-Frameworks drin sind

00:50:40.285 --> 00:50:45.405
und Analytics-Frameworks und Plugins und man keine Zeit hat, da den Code aufzuräumen

00:50:45.405 --> 00:50:49.405
und das ist halt viel mehr das Problem als der WebView an sich, der glaube ich sehr schnell ist,

00:50:49.405 --> 00:50:51.183
wenn er halt besser verwendet werden würde.

00:50:51.993 --> 00:51:01.761
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.

00:51:02.490 --> 00:51:04.642
Wir kennen das Problem alle, ja.

00:51:05.405 --> 00:51:12.275
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.

00:51:12.870 --> 00:51:16.465
Ja. Ja, wobei ja auch viel, jetzt machen wir einen kleinen Ausflug,

00:51:16.465 --> 00:51:21.825
aber auch viel so Branchenlösungen dann natürlich spezielles Tracking nochmal beinhalten, ne?

00:51:21.825 --> 00:51:28.425
Also, kannst halt nicht irgendwelche speziellen Branchenzahlen messen mit Google Analytics,

00:51:28.425 --> 00:51:33.863
weil du brauchst halt irgendein Nielsen-Tracking oder I don't know, ja?

00:51:34.115 --> 00:51:37.653
Ja, ist richtig. Aber es macht die Situation trotzdem nicht besser.

00:51:38.202 --> 00:51:41.857
Es ändert nichts an der Grundeinnahme. Da hast du vollkommen recht, ja.

00:51:42.208 --> 00:51:42.829
Das war's. Bis zum nächsten Mal.

00:51:44.396 --> 00:51:48.617
Ich würde sagen, wir haben das Thema auf jeden Fall ganz gut beackert.

00:51:49.392 --> 00:51:54.379
Das war auf jeden Fall ein toller Einblick in die Entwicklung mit Rust.

00:51:54.647 --> 00:52:00.528
Und zwar die in dem Fall jetzt eher frontend-lastige Sicht auf die Dinge,

00:52:00.834 --> 00:52:08.693
nachdem wir ja damals viel über serverseitige Frameworks gesprochen haben und Rust auch sozusagen als Sprache.

00:52:09.147 --> 00:52:10.484
Vielen, vielen Dank.

00:52:11.240 --> 00:52:17.866
Wenn's Fragen gibt, kann man dich erreichen, nehm ich an. Ja, bei Masteron und auch noch bei Twitter, nein, halt X.

00:52:18.964 --> 00:52:19.378
Ja.

00:52:20.666 --> 00:52:23.867
Genau. Übrigens, du hast ja gesagt, du hast bei Xing gearbeitet.

00:52:23.907 --> 00:52:27.336
Irgendwie gibt's ja das Gerücht, dass in Zukunft das Twitternian,

00:52:27.453 --> 00:52:30.987
also Twitter nicht mehr toTweet ist, sondern Xing.

00:52:31.288 --> 00:52:33.638
Ja. Da kommt noch was auf die zu.

00:52:34.601 --> 00:52:38.867
Ja, genau. Ein weiterer, eine weitere juristische Auseinandersetzung.

00:52:38.867 --> 00:52:46.097
Und der der Support der die armen Leute die bekommen immer die Mails von den von denen die nicht Xen können.

00:52:47.285 --> 00:53:06.739
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.

00:53:07.018 --> 00:53:19.081
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.

00:53:19.837 --> 00:53:24.787
Baut hier ein bisschen aufeinander auf, wie ihr merkt, ne? Wir haben ja vorhin Solid.js kurz angesprochen.

00:53:24.787 --> 00:53:28.957
Absolut, ja, genau. Alles klar.

00:53:29.362 --> 00:53:31.287
Alles klar, bis dahin. Dankeschön.

00:53:32.441 --> 00:53:34.079
Tschüss. Ciao, ciao.

00:53:34.800 --> 00:53:57.840
Music.