Deep Dive 218 – Deno Desktop mit Leo Kettmeir

0:07SPEAKER_01:Hallo und herzlich willkommen zu einem neuen Deep Dive hier in der Programmierbar und ich glaube, wir machen was, was wir so ganz selten bisher gemacht haben. Wir sprechen nämlich heute über Dino Desktop und nicht, dass wir selten über Dino sprechen, das ist ganz und gar nicht der Fall. Wir sprechen halt häufig über Dino, aber wir widmen uns tatsächlich hier in diesem Deep Dive einem Thema, was vor gar nicht allzu langer Zeit schon mal bei uns in den News war.

0:31SPEAKER_01:Und zwar haben wir in den News 26, 2026 schon über Dino Desktop gesprochen. Damals war es gerade frisch erschienen und wir haben so unsere ersten Eindrücke und Meinungen dazu geteilt. Und es ist ja ganz interessant, dass heute man sich vielleicht nochmal im Detail anschauen. Und weil ich, der Jan, hier nicht den ganzen Tag nur Dino machen kann und mir Dino Desktop auch nicht so in hundertprozentiger Tiefe anschauen kann, habe ich mir Verstärkung dazu geholt.

1:00SPEAKER_01:Und wir haben heute den Leo Kettmeier von Dino. Also sagt man von Dino oder sagt man von Dino Land? Leo, wie sagt ihr das?

1:06SPEAKER_00:Ja, von Dino, also Dino. Also wie es auch überhaupt ausgesprochen wird, das ist auch noch ein ganz anderes Thema.

1:13SPEAKER_01:Sehr gut, da kommen wir dann bitte direkt gleich dazu. Weil das ist auch bei uns manchmal so Stein des Anstoßes hier so, ja. Aber dann auf alle Fälle, Leo, herzlich willkommen, schön, dass du bei uns bist, dass du Zeit genommen hast, um einmal über Deno-Dino, wie auch immer, zu sprechen. Du bist angestellt bei besagter Firma, aber warst vorher auch schon so Open Source Freiwillig-Contributor und hast dann den Sprung in die Vollzeitstelle quasi dazu geschafft.

1:44SPEAKER_01:Wie musst du mir das vorstellen?

1:46SPEAKER_00:Ja, also anderthalb Jahre hatte ich dann Open Source Contribution gemacht. Das war einfach zufällig, habe ich Dino gefunden. Über einfach eine YouTube Recommendation von dem Talk, so Ten Years, no, Ten Things I Regret About Note.

2:04SPEAKER_01:Den habt ihr auch gesehen damals?

2:05SPEAKER_00:Ja, ja, genau. Und ja, das hatte ich mir einfach dann mir angeschaut, habe ich ein bisschen recherchiert, bin dann die Community beigetragen, äh, beigetreten und dann wollte ich ein paar Features haben, die einfach nicht gehabt und weil ich irgendwie Discord-Bots machen wollte. Weil das ist ja, was man, wenn man ein bisschen JavaScript machen will und nicht viel weiß, das ist irgendwie dann so, dass große Projekte immer das einige machen und das, ja, damals konnte ich sehr wenig JavaScript und TypeScript.

2:39SPEAKER_00:Fangen wir nicht mal an mit Rust und sowas. Da wusste ich nicht mal, dass es, was Rust überhaupt war. Und dann, ja, hat sich halt einfach das ein bisschen entwickelt. Ich wollte Features haben, habe ich angefangen, ein paar Sachen zu lernen.

2:51SPEAKER_01:Und ja. Du bist uns heute zugeschaltet aus Rotterdam. Das ist, wie der Zufall es so will, ja in den Niederlanden. Und kleine Notiz am Rand, so Pet Peef von mir ist ja so, wenn Leute immer Holland sagen, wenn sie Niederlande meinen. Aber Rotterdam ist wirklich Holland, oder? Es ist Südholland.

3:12SPEAKER_00:Weil Hauptland ist. Es gibt Holland zweigeteilt. Also offiziell, also wenn ich meine Adresse eingeben muss, muss ich Südholland sagen, weil das einfach eine andere Region ist als Nordholland. Und ja, es gibt Holland, aber das ist einfach die zwei zusammengeworfen. Offiziell gibt es, sag ich mal, nicht.

3:30SPEAKER_01:Und du bist ja auch nicht der erste von euch, der hier bei uns ja programmierbar ist. Der Luca auch von Denodino war ja auch schon ein paar Mal bei uns. Der sitzt ja auch in den Niederlanden, aber das ist jetzt nur ein Zufall. Man muss nicht in den Niederlanden sitzen, um für euch zu arbeiten, oder?

3:46SPEAKER_00:Nee. Es ist einfach, ich glaube, außerhalb Amerika ist Niederlanden, wo wir einfach am meisten Leute jemals hatten. Das ist einfach ein pures Zufall.

3:58SPEAKER_01:Purer Zufall. Oder da tummeln sich vielleicht einfach die richtigen Leute. Also vielleicht ist das ja auch so ein Thema. Aber ich habe auch gesehen, du sitzt nicht nur in Rotterdam, du sitzt auch in den TC39 und 55 für Dino und werkelst da quasi vollkommen übergreifend auch noch an der Zukunft von JavaScript-Respektive TypeScript mit. Genau. Das ist ja auch ganz abgefallen.

4:21SPEAKER_00:Ja, ja, das ist, da bin ich eigentlich erst seit Neuerns dabei. Das war dieses Jahr das erste Meeting, das ich dabei war. Und daher, dass dann Luca ja von Deno weggegangen ist, mussten wir jemanden haben, der das übernimmt. Und daher, dass ich schon ein bisschen Involvement mit Standards hatte über Deno, habe ich dann das einfach übernommen. Und das, jo, da kann man schon interessante Sachen lernen und machen.

4:48SPEAKER_01:Das finde ich immer cool. Also, wir hatten vor kurzem auch ein Deep Dive gemacht mit jemandem vom W3C so, ja. Und da quasi zu sehen, dass, also ohne da jetzt irgendjemandem zu nahe zu reden, ne, aber das sind auch ganz normale Menschen. So, ja. Man denkt ja immer, das sind so alte, weise Männer mit langen Rauschenbären, also den langen Bart hast du schon, ja. Also das bringst du vielleicht mit, der ist noch nicht ganz so weiß, wie man sich das dann vielleicht klischeemäßig vorstellt.

5:12SPEAKER_01:Aber es ist halt nicht so, oder? Es sind Leute, ich sag mal so wie du und ich, aus der Praxis, die dann da irgendwie einfach zusammensitzen und mit, ich sag mal, bestem Wissen und Gehwissen irgendwie daran arbeiten, wie das halt so weitergehen könnte. Und das da mal so ein kleines Spotlight irgendwie drauf finde ich eigentlich auch ganz cool.

5:29SPEAKER_00:Ja, ne, und also die Standards-Bodies, da lernt man, da trifft man Leute natürlich auch. Man kann zur Sprache Sachen hinzufügen, aber man muss nicht sein. Ich kenne einige, die einfach dort sind, aber zum Zuhören oder einfach um Ideen zu verbreiten, dass man vielleicht ein bisschen etwas machen könnte. Aber da sind sehr viele verschiedene Firmen. Man muss jetzt nicht irgendwie eine Riesenfirma sein. Da kannst du auch ein kleines Unternehmen mit fünf Leuten sind dabei.

5:55SPEAKER_00:Also alles Mögliche.

5:58SPEAKER_01:Nice. Bevor wir gleich ans Eingemachte gehen, lass uns doch ganz kurz über die Deno-Dino-Diskussion sprechen.

6:06SPEAKER_00:Also, wie sagst du es denn? Es kommt mir sehr zufällig raus. Also, ob es Deno oder Dino ist, das spriche ich immer ein bisschen anders aus, wie Lust und Laune ist, aber ich habe gerade eben hier unsere Docs, unsere Docs-Website aufgerufen und weil da haben wir es aufgeschrieben, wie man es aussprechen soll. Und das ist ein Dino.

6:31SPEAKER_01:Okay, so habe ich mir das auch irgendwie immer gedacht. Ich habe auch ganz lange mit Dino gesagt, so, ja. Aber nachdem ja euer Logo auch so ein Dino ist, ja, muss man muss man, glaube ich, dann auch einfach Dino sagen. Vielleicht in 30 Sekunden für alle da draußen, die noch nichts mit Dino zu tun hatten, wie würdest du Dino beschreiben? Was ist Dino?

6:53SPEAKER_00:Dino ist eine Alternative zu Node.js, so aber ein bisschen verbessert, sag ich mal, also nicht vielleicht verbessern, aber einfach moderner. Ein paar modernere Ideen reinbringt in der Runtimes, aber auch einfach ein All-in-One-Iclusive Toolkit. Also du bekommst einfach Linterformatter, Bundling, Desktop-Apps, Doc Generation, also sehr viele verschiedene extra Features, die einfach nicht nur die Runtime selbst sind, sondern einfach Sachen herum und auch TypeScript out of the box.

7:30SPEAKER_00:Aber auch eines der wichtigen Sachen für uns ist, wie gesagt, Standards und deswegen folgen wir auch sehr viel die Browser-Standards. Das heißt, also, wenn du ein Websocket machen willst, benutze nicht irgendwie unsere WebSocket API. Nee, du benutzt einfach die Browser WebSocket API und die ist genau implementiert wie in einem Browsern. Also du kannst einfach dein Knowledge von Browser-Usage einfach wieder weiter benutzen in Dino.

7:59SPEAKER_01:Ich muss sagen, das war auch das, was mich damals da so ein bisschen hingezogen hat. Zum einen als jemand, der zu dem damaligen Zeitpunkt zumindest nicht hauptsächlich mit TypeScript gearbeitet hat, zu sagen, okay, es gibt hier eine Runtime, die dir im Prinzip diese ganze Transpellation und Linter und was du halt irgendwie so alles brauchst, um aus so, so wie man halt früher TypeScript erstmal zu JavaScript komplett hat und dann das irgendwie ausgeführt hat, so das alles nicht mehr machen zu müssen, und sich damit auch überhaupt gar nicht auseinandersetzen zu müssen.

8:29SPEAKER_01:Das war natürlich cool und einfach für mich. Und dann, wie du halt sagst, halt nicht irgendwelche proprietären Custom APIs irgendwie lernen zu müssen, sondern zumindest so, wenn man halt eine API lernen muss, also natürlich muss man immer noch lernen, wie irgendwie ein Websocket funktioniert, aber du lernst halt den Standard so und du lernst es so, wie du es danach auch genau im Browser machen kannst und hoffentlich ja dann auch irgendwie in anderen Runtimes, die sich halt auch an diesem Standard orientieren, halt auch machen kannst.

8:55SPEAKER_01:Das heißt, das Wissen, was du aufbaust, bleibt halt so ein bisschen portabler gefühlt. Wie gut das in der Praxis dann immer klappt, kann man nochmal diskutieren, aber zumindest der Ansatz ist ja irgendwie lobenswert und es fühlt sich dann einfach so ein bisschen besser an, wenn man da Arbeit reinsteckt. Also mein Ersteindruck.

9:15SPEAKER_00:Stefan ja auch damals. Also, wenn ich erst angefangen hatte und Deno gesehen habe, fand ich das einfach, was mich auch da richtig reingebracht hat in Deno, dass ich das so haben will, dass ich einfach mein Wissen weiter nutzen kann.

9:30SPEAKER_01:Wir haben, wie gesagt, in den News schon einmal über Dino Desktop gesprochen, so eure, ich sag mal, Alternative zu Elektron vereinfacht. Wenn man sich anguckt, was Dino noch irgendwie gerade alles macht, alles kann, alles ist, da gibt es zum einen Dino die Runtime, es gibt irgendwie JSR, was eure Package Registry ist, es gibt Fresh, das Webframework, es gibt Dino Deploy als Infrastrukturangebot, es gibt Dino Desktop als irgendwie Rapper für Desktop-Apps und es gibt dann noch so ganz an der Seite irgendwie Cloud Patrol, über das wir auch mal irgendwann, glaube ich, in den News gesprochen haben.

10:05SPEAKER_01:Und ich schaue da ehrlicherweise so ein bisschen drauf und ich frage mich dann so, was ist eigentlich gerade so euer Fokus? So, ja, weil am Anfang war die Story, glaube ich, noch eine sehr einfache, wie du sagst hast, ne, was haben wir irgendwie aus Node gelernt und wie kann man irgendwie eine elegantere Runtime vielleicht auch bauen? Und mittlerweile gibt es Webframeworks und Infrastruktur und Desktop-Rapper und die Registry. Was ist so die überragende Mission da oben drüber?

10:32SPEAKER_00:Also Deno, ich würde sagen, ist keine JavaScript-Firma. Deno ist eine Tooling-Firma. Was wir machen, ist Tooling für Entwickler. Deswegen, also am Anfang natürlich, hat es mit JavaScript angefangen. Aber es hat sich einfach ein bisschen verbreitet, weil also jetzt zum Beispiel auch mit AI haben wir dann halt ja Claw Patrol, weil wir das einfach intern brauchten für ein paar Sachen und einfach sehr hilfreich war und haben wir entschieden, dass wir das einfach dann richtig als ein richtiges Projekt freigeben.

11:02SPEAKER_00:Also sehr viele Sachen, die am Ende wir einfach selber benutzen wollen und brauchen, machen wir dann einfach öffentlich. Weil, warum für uns selbst alles zu behalten? Bringt ja nichts.

11:15SPEAKER_01:Okay. Fair und lobenswert vielleicht. Ich habe eben schon gesagt, so kurz gefasst ist Dino Desktop irgendwie eure Alternative zu Elektron. Jetzt gibt es ja schon Alternativen zu Elektron, ja. Und manche, die auch gar nicht so unähnlich sind zu dem, was ihr mit Dino Desktop macht. Und bevor wir da jetzt in die Details reingehen, vielleicht einmal so neben Elektron, Taure, Elektrobannen und was das so alles da draußen irgendwie gibt. Wieso habt ihr auf diesen Markt geguckt und gesagt, so, da fehlt noch eine Lösung?

11:50SPEAKER_01:Also, man hätte ja auch sagen können, da gibt es schon sehr viel, da ist irgendwie vielleicht wenig Potenzial zur Ausdifferenzierung irgendwie da. Was mal so ausschlaggebend für euch um sagen, so, nee, da braucht es auch noch unsere Lösung.

12:05SPEAKER_00:Gute Frage, also es hat sich, es ist ein Projekt, was ich seit sagen wir mal jetzt vier Jahren ungefähr her, ja, das ich immer wollte. Also ich wollte eine Möglichkeit, um Desktop-Apps zu machen und ich fand Elektron, sagen wir mal, zum Kotzen, weil es einfach, ja, wenn man es benutzt, fand ich immer ein bisschen kompliziert. Ein bisschen zu viele Konzepte und alles, muss man ein bisschen alles so viel Verschiedenes lernen. Und dann war einfach auch der Fall, dass mit Deno kann man Elektron nicht benutzen, weil Elektron, sagen wir mal, ziemlich ein Fork ist von Node.js.

12:48SPEAKER_00:Also es bundelt sein eigenes, äh, sein eigenes Runtime. Da kann man dann nicht irgendwie einfach Deno einfach ersetzen. Deswegen brauchten wir einfach eine andere Lösung.

13:02SPEAKER_01:Und vielleicht auch da, bevor wir über die Details sprechen, was ist so euer Elevator-Pitch für Dino-Desktop? Was ist das Alleinstellungsmerkmal?

13:13SPEAKER_00:Also, das ist kompliziert, weil einfach wir sehr viele verschiedene Sachen machen damit. Aber die Idee ist einfach, wie alles bei Deno, alles einfacher machen für Entwickler. Man muss nicht irgendwie alles irgendwie konfigurieren, machen, bla bla bla. Nee, du kannst einfach Dino-Desktop, wenn du zum Beispiel sagen wir mal, du hast eine Webseite mit irgendwie Next.js, kannst einfach nur einen Dino-Desktop exekutieren in der Command-Line und das gibt dir einfach eine Desktop-App.

13:44SPEAKER_00:Muss keine Code-Änderungen machen überhaupt. Also es ist, würde ich sagen, einfach, wie einfach es ist zu nutzen.

13:51SPEAKER_01:Und als Runtime selbstverständlich dann quasi Dino zur Laufzeit, ja. Was nutzt ihr da im Rendering?

14:00SPEAKER_00:Also, das ist halt das Interessante, wo wir uns etwas ändern von den anderen Lösungen. Und das ist, dass du entscheiden kannst, was du willst zum Rendern. Bei Default ist es, glaube ich, halt die System WebView. Das macht einfach, dass dann die Binary relativ klein sein wird von der Desktop-Welt-App, weil es einfach dann das benutzt, was auf dem System ist. Aber dann gibt es auch Ceph, was Chrome-Embedded-Framework ist. Also das heißt Chromium ziemlich ähnlich wie Elektron es macht.

14:34SPEAKER_00:Und das macht halt natürlich, dass alles ein bisschen größer sein wird von Binary Size, aber dafür bekommst du ganz Chromium, sage ich mal, dabei. Also du kannst alles die ganzen APIs, die vielleicht nur bei Chrome sind oder einfach, dass es Consistent Rendering über die anderen verschiedenen Operating Systems ist. Und ja, das ist halt, musst du sehen, was du am besten brauchst und willst, ob dir Binary Size wirklich wichtig ist oder Consistency wichtig ist, aber wenn du zum Beispiel in der Firma bist und ihr habt alle nur Macs und ihr braucht eine interne App, da würde wahrscheinlich einfach dann nur die WebView reichen, weil da weißt du, dass du nicht irgendwie bei Linux dann bist und dann funktioniert die Hälfte nicht.

15:19SPEAKER_01:Aus der praktischen Erfahrung kommt, was ist für die meisten Leute eher das ausschlaggebende Argument, vielleicht doch auf Chromium zu setzen? Ist es eben genau diese Consistency, weil sie sagen, okay, ich liefere hier mein Chromium mit und damit weiß ich ganz genau, wie das überall aussieht. Und auch wenn jetzt so Sachen wie, ich sag mal, Fontrendering, Kernning so ein bisschen unterschiedlicher noch sind von Betriebssystem zu Betriebssystem, so die groben Features sind zumindest irgendwie gleich, ja.

15:42SPEAKER_01:Oder ist es tatsächlich eher dieses, boah, ich brauche hier APIs, die es halt gerade nur in Chromium gibt und mein, weiß nicht, macOS, WebKit, Safari-Ding tut es halt hier irgendwie einfach nicht.

15:55SPEAKER_00:Also ich würde schon sagen, es ist hauptsächlich Consistency und einfach, weil Leute sehr damit halt Chromium hat ja was, was sagen wir mal, 90, 96 Prozent Market Share. Einfach das ist, was Leute sich damit wohlfühlen. Und ja, es gibt halt ein paar APIs. Chrome fügt schon ein bisschen mehr und schneller hinzu als die anderen Browsern. Aber die anderen Browser machen auch keine schlechte Arbeit. Ein paar haben vielleicht auch sogar APIs, die Chromium noch nicht hat.

16:22SPEAKER_00:Also das ist schon, würde ich sagen, Consistency ist the key. Weil ja, bei den anderen Browsern auch, man könnte auch, sag ich mal, Firefox-based Backend haben für Dino-Desktop, könnte man theoretischerweise implementieren. Aber bringt, sag ich mal, nicht allzu viel, weil einfach Leute Chromium wollen.

16:47SPEAKER_01:Okay, jetzt hast du eben schon gesagt, dass so Dino-Desktop das ist, was du schon seit vier Jahren eigentlich haben willst. Wie sah denn dieser Schaffensprozess aus? Weil ich nehme mal jetzt nicht an, dass irgendwie zwei Wochen vor dem 2.9-Release jemand eingefallen ist, so dieses Desktop-Ding, das sollten wir vielleicht mal bauen, lass uns noch kurz ein paar Nächte um die Ohren schlagen und dann schippen wir das noch schnell mit. Und dann wird ja vielleicht so ein bisschen mehr Konzeptionsarbeit und Planung und die ein oder andere Diskussion irgendwie noch eingeflossen sein.

17:16SPEAKER_01:Nimm uns da doch mal mit, so auf eine kleine Zeitreise, so, wie hat sich Dino Desktop entwickelt?

17:23SPEAKER_00:Ja, also wie gesagt, es hat vor vier Jahren aus eine Idee angefangen, haben wir dann leider nie gemacht, weil einfach es ein sehr komplexes System wäre und wir keine richtige Lösung gefunden hatten, wie wir das machen könnten. Und das hat da aber auch alles angefangen, wann ich mit ein paar Leuten von Taure getroffen habe und wir dann ein bisschen zusammen konzentisiert haben für eine Lösung für Dino Desktop und Taure, sagen wir mal, auszunutzen zu können damit.

17:53SPEAKER_00:Aber das wurde dann einfach nichts. Einfach wie gesagt, wir hatten die Infrastruktur, dass wir das bauen können und dass wir das auch so machen wollen, wie wir es haben wollen, ging es halt leider nicht. Und dann, ja, hatten wir das, sag ich mal, immer versucht, so einmal im Jahr wieder als Projekt kurz für eine Woche vielleicht, hey, können wir das doch bauen? Haben wir nie dann eine gute Lösung gefunden. Bis zu, naja, diesem Jahr. Da hatten wir dann endlich, hat mein Kollege DeW hat ja eine gute Lösung gefunden, wie wir das am besten bauen können.

18:26SPEAKER_00:Dass wir einfach auch das größte Problem ist bei Desktop-Apps ist, dass normalerweise brauchst du, dass der Renderer das Hauptprozess ist. Es kann nicht sein, dass ein Dino das Hauptprozess ist, weil das macht alles Mögliche ein Problem. Da gehen meiste APIs zum Beispiel auf dem Mac dann nicht. Du kannst irgendwie nicht mal eine Window, glaube ich, kreieren, wenn du nicht das Hauptprozess bist.

18:52SPEAKER_01:Ah, okay.

18:53SPEAKER_00:Ja, das macht es einfach. Deswegen ist es nicht so eine einfache Sache. Aber da haben wir halt Lösungen dann gefunden und da haben wir dann angefangen zu bauen. Und ja, das war schon ein paar Monate. Dann, während wir angefangen haben, kamen dann auch Elektrobonnen raus, also dass das angesagt wurde. Und es hat schon ein paar Sachen ähnelt sich ab. Wir haben ein paar Sachen dann am Ende auch etwas, sag ich mal, abgeschaut von Elektrobannen. Wir haben natürlich auch Sachen von Elektron, von Tauri, haben wir ein bisschen kopiert, weil einfach, die haben nicht schlechte Konzepte am Ende des Tages.

19:30SPEAKER_00:Die sind ja gute Projekte, sonst wären die ja nicht so beliebt. Aber ja, da haben wir ein bisschen und auch das ein bisschen das Dino draufgespringelt. Einfach, dass wir selber unseren eigenen Flair, den Dino-Flair, hinzufügen.

19:47SPEAKER_01:Okay, was ist denn der Dino-Flair an Dino-Desktop? Wo merke ich den denn in der Verwendung?

19:53SPEAKER_00:Ja, ich würde, wie gesagt, sagen, einfach, wie einfach es ist zu nutzen. Also es ist einfach echt, es ist sehr einfach, APIs sehr übersichtlich, würde ich sagen. Also ein paar Sachen sind halt kompliziert, weil am Ende des Tages brauchst du immer noch eine Desktop-App und leider ist das ganze System mit Desktop-Apps halt leider relativ kompliziert. Aber APIs haben wir versucht, so ähnlich wie möglich zu Browser-APIs zu nachmachen. Also Events, die du aus dem Browser kennst, wie Mouse-Move und Klick und sowas, ist alles, sagen wir mal, eins zu eins gemappt.

20:31SPEAKER_00:Und das ist einfach, dass Leute, mit was die schon kennen, einfach das ausbauen können. Und ja, halt Ease of Views und sagen wir mal, modernere Konzepte und Ideen, wie man ein paar Sachen machen kann.

20:50SPEAKER_01:Wenn ich jetzt mit Dino Desktop meine erste eigene App bauen will, dann brauche ich da wahrscheinlich nicht viel mehr als einen TypeScript-File und das macht im Zweifelsfall auch erstmal nicht mehr, als irgendwie ein Window zu öffnen und was deines irgendwie reinzumalen. So mein kleiner Hello World-Case, ja. Und dann sage ich einfach, hey, Dino Desktop, hier ist mein Main. TS, Intro. Hier ist das File. Da kannst du alle anderen von da aus finden und zusammenschrauben.

21:18SPEAKER_01:Und dann fällt so ein Binary raus und das kann ich aufmachen. Was tut denn aber Dino Desktop, um dieses Binary zu bauen? Also wenn ich hier tippe Dino Desktop Main.

21:33SPEAKER_00:Also, Dino Desktop funktioniert, das ist einfach, wir haben Pre-Build-Binaries auf dem Bucket irgendwo und das muss es halt das runterladen. Diese Binaries sind etwas unterschiedlich von der Haupt-Dino-Binary, die du benutzt, wenn du einfach Dino benutzt. Also das ist, sag ich mal, hat die Subcommands nicht, hat einfach ein paar Sachen weggenommen, aber dafür hat es auch.

22:00SPEAKER_01:Binaries, dann sind das die Runtime-Binaries, ja?

22:02SPEAKER_00:Genau. Okay. Und ja, dafür hat aber diese spezielle Binary, die runterlädt, halt die ganzen Dino-Desktop APIs und die ganzen Features dazu. Weil wir wollen nicht, dass Dino selbst auch irgendwie Dino-Desktop APIs selbst hat. Wir wollen, also für uns Deno ist immer ein Headless Runtime. Also alles, was du machst mit Dino, muss auf ein Headless-System funktionieren. Und das natürlich funktioniert nicht mit Desktop. Das ist ein ziemlich Konflikt.

22:41SPEAKER_00:Deswegen kriegst du eine separate Binary, die einfach nur die APIs hat. Und das lädt hier runter und dann bandelt es deine App zusammen, also deine ganzen Typefit-Files, deine Assets und sowas, das wird alles zusammengebundelt und dann am Ende dieser Binary einfach zugeworfen, sage ich mal so. Das ist einfach, wir haben so einen Magic Header am Ende von der Dino-Binary. Wenn es sieht, dass es irgendwo dieser Header dann doch da ist und Code danach, also irgendwie unserem Format, sieht, dass dann noch weitere Dateien noch weitere Bytes danach sind, dann benutzt es diese alle Bytes nach diesem Magic-Header und benutzt das, um Dino zu exekutieren.

23:28SPEAKER_01:Das heißt, der Buildprozess sozusagen ist nichts anderes, als dieses spezielle Runtime-Binary zu nehmen und meine zusammengepackte Anwendung quasi hintendran an dieses Binary zu schreiben, sodass es quasi eine konkettete Datei sozusagen wird. Genau.

23:46SPEAKER_00:So funktioniert auch Dino-Compile. Also wir haben sehr viel Infrastruktur damit einfach wieder benutzt. Okay.

23:57SPEAKER_01:Und also wahrscheinlich den Anwendungsgrafen da zusammenzubauen, das ist ja eh was, was ihr schon könnt, weil das brauchst du ja eh, um einen ganz normalen Dino-Prozess irgendwie schon zu starten. Passiert da noch irgendwas anderes Spezifisches im Sinne von, weiß nicht, muss das komprimiert werden, muss das signiert werden? Passiert also irgendwas, was es von einem normalen, ich sag mal, Dino-Server-Prozess unterscheidet?

24:23SPEAKER_00:Ja, also komprimiert ist eine Option, da gibt es eine Flag, das Compress. Dann gibt es Signing, das ist halt mit Desktop-Apps, du willst halt natürlich deine App signiert haben, damit die auf einen App Store gehen kann oder einfach nicht, dass dann irgendwie, wenn du auf Mac bist, der sagt, hey, diese App kenne ich nicht, die will ich nicht öffnen. Also ja, es sind noch ein paar extra Sachen, die noch möglich sind für Users, aber im Normalfall, also wenn du nichts weiteres machst, einfach nur Dino-Desktop, nee, da machst einfach nur das einfach.

25:01SPEAKER_01:Und ganz blöd gefragt, muss meine Dino Desktop-App ein GUI mitbringen? Weil ich könnte, also der Bildprozess, wie du ihn gerade beschrieben hast, den könnte ich ja auch analog zu Dino Compile quasi nutzen, um jetzt nur CLI-Tools zum Beispiel zu bauen. Oder ist es quasi schon so, dass da auf Biegen und Brechen irgendwo erwartet wird, okay, du musst jetzt hier mal ein Fenster zeichnen, sonst ist irgendwas schiefgelaufen.

25:24SPEAKER_00:Ja, das ist schon der Fall. Also muss eigentlich nicht genau sein Fenster. Du kannst auch zum Beispiel nur ein Tray-Icon haben, also da im Tray. Oder einfach ein Dock-Icon. Also es muss schon irgendetwas geben, weil sonst geht das System dann, hä, was ist denn hier denn los? Weil, ja, dann solltest du echt Dino Compile selbst nutzen und nicht Dino Desktop. Das ist dann ein bisschen.

25:52SPEAKER_01:Okay, ähm. Wie? Oder andersrum. Du hast am Anfang gesagt, ihr seid eine Tooling Company. Ja. Ihr baut das, was ihr glaubt, was die Leute daraus brauchen, oder vielleicht auch das, was ihr selber braucht und stellt es dann den anderen zur Verfügung. Welchen Use Case hast du denn selbst mit Dino Desktop bedient? Also, du hast ja gesagt, du wolltest es haben, als es dann da war. Was war das, was du mit Dino Desktop gebaut hast?

26:22SPEAKER_00:Um ehrlich zu sagen, gar nichts. Es war einfach, also ich will eine Möglichkeit haben, dass du Leute. Genau. Nee, und wir haben in der Community über die Jahre immer gesehen, es gab sehr viele Leute, die sehr enthusiastisch drauf waren, eine Möglichkeit für Desktop-Apps zu haben. Leute haben versucht, extern einfach eine Möglichkeit zu haben, für Desktop-Apps zu bauen. Da gab es irgendwie drei große Projekte, die das versucht haben und gemacht haben.

26:51SPEAKER_00:Ist halt natürlich aber nicht dasselbe, als wenn das richtig in der Runtime integriert ist. Und ich fand es einfach ein interessantes Problem. Ich damals vor vier Jahren war ich schon ein bisschen Elektron-Apps am Bauen, aber heutzutage dann doch nicht mehr. Und jetzt habe ich keine Zeit, um irgendeine App zu bauen. Ich habe ja nur Zeit, das System um die App zu bauen, zu bauen.

27:15SPEAKER_01:Na gut, Arbeitsteilung, ne? Irgendjemand anderes musste halt die App bauen. Wir nehmen diese Folge Mitte, Ende August auf. Die Dino-Version 2.9, das ist noch der aktuellste Release, das ist auch der Release, mit dem Dino Desktop quasi erstmalig erschienen ist. Das kann, bis die Folge raus ist. Ich sag mal, die kommt so Ende September, Mitte Oktober, da kann vielleicht schon eine neue Dino-Version da sein, aber unabhängig davon, in den Release-Notes zu 2.9 steht, Dino Desktop ist experimental, the Surface Described here is stabilizing and some features are still landing.

27:51SPEAKER_01:Was ist denn der aktuelle Zustand von Dino Desktop? Was fehlt vielleicht noch komplett? Was könnte sich vielleicht nochmal ändern? Was ist noch so ein bisschen im Flux? Wo fühlt ihr euch schon gut mit? Wie sieht es aus?

28:06SPEAKER_00:Also, wir bekommen relativ viel noch Issues von Leuten, die einfach das System noch ausprobieren. Es kommen immer wieder ein paar Bugs und dort. Richtig, Features, die fehlen, muss ich sagen, fällt mir jetzt nichts ein, außer wenn ich jetzt durch unseren Issue-Tracker gehe und da vielleicht ein paar Sachen rausfinde. Aber generell würde ich sagen, das System ist halt gebaut, es funktioniert. Es ist vielleicht, was einfach fehlt, ist einfach halt ein bisschen Refinement und ein paar Sachen einfach, ja, ich würde sagen, eigentlich hauptsächlich die Bugfixes.

28:41SPEAKER_00:Das ist schon das Größte. Es gibt halt ein paar Kleinigkeiten hier und dort, die ich gerne hätte, aber das sind dann auch vielleicht ein paar Sachen, die mehr Long-Term sind. Weil zum Beispiel habe ich eine Branch mit einem weiteren Backend, Servo, dass man Server nutzen kann dann. Aber Server ist halt sehr experimentell noch und ich rede mit den Leuten von Server ab und zu und ja, die fügen schon ein paar Sachen. Server ist das originelle Projekt, das überhaupt Rust für erfunden wurde.

29:14SPEAKER_00:Das ist ein alternative Browser-Engine, die von Mozilla angefangen wurde. Und Firefox eigentlich benutzt ein paar Sachen von Server selbst und Server benutzt ein paar Sachen von Firefox. Die teilen sich schon ein paar Sachen hier und dort, aber es ist halt ein, sag ich mal, experimentelles, komplett in Rust gebautes Browser. Und das geht schon seit vielen Jahren weiter, aber ja, es ist halt. Browser-bauen ist nicht einfach, sag ich mal so. Da gibt es sehr viele Sachen.

29:47SPEAKER_01:Das hat ja schon einen Grund, warum die letzten 20 Jahre gefühlt kein neuer dazugekommen ist. Genau. Okay, also im Prinzip so ein bisschen, ich sag mal, was Modularität angeht. Vielleicht, ne, irgendwie Runtime tauschen können. Renderer ist ja schon tauschbar, haben wir eben schon gesagt.

30:06unknown:Gut.

30:07SPEAKER_01:Jetzt gibt es ja, wenn man sich die anderen anguckt, Elektron, Elektro One, Tauri, wir haben sie vorhin schon mal genannt, zum Beispiel auch ganz andere Use Cases, die dann noch abgedeckt werden. Ich glaube, Tauri hat ja in seiner 2.0er Version dann auch angefangen, so Mobile-Apps zu unterstützen, zum Beispiel. Ist das was, was ihr euch auch anguckt, oder heißt es nicht umsonst Dino-Desktop?

30:29SPEAKER_00:Ja, also vielleicht, Dino Desktop war vielleicht nicht der beste Name, weil wir haben schon ein bisschen herumgeschaut von wegen Mobile-Apps auch.

30:37SPEAKER_01:Dino Mobile ist vielleicht noch frei, branding-mäßig.

30:41SPEAKER_00:Ja, vielleicht noch machbar, ja. Vielleicht einfach nur ein Alias für den Desktop-Subcommand am Ende. Aber ja, nee, also wir haben jetzt iOS-Bilds, sind machbar. Ich weiß nicht, ob Desktop-Apps mit iOS schon jetzt funktionieren oder ich zweifle es. Vielleicht, wenn diese Folge rauskommt, dann vielleicht schon dann. Aber Dino kann jetzt für iOS gebaut werden und ich glaube, Android geht auch langsam vielleicht. Da bin ich mir leider nicht 100% sicher.

31:09SPEAKER_00:Aber nee, also Mobile Apps ist schon etwas, was für uns interessieren, dass das eine Möglichkeit ist.

31:17SPEAKER_01:Cool. Wie, also wir haben ja in den News auch über Dino-Desktop gesprochen. Was war so das Feedback, was bei euch so initial dazu aufgeschlagen ist? War es mehr so ein Boah, cool, ich habe da schon super lange drauf gewartet und endlich kann ich die Desktop-Apps bauen, die ich die ganze Zeit nicht bauen konnte? Oder war es mehr so ein verwirrtes so wieso? Oder was war so das Feedback, was ihr bekommen habt?

31:48SPEAKER_00:Feedback war überraschenderweise nicht viel, aber nicht in einer schlechten Nacht. Normalerweise, wenn man nicht viel Feedback bekommt, heißt es, ach scheiße, Leute benutzen es nicht. Aber das war eigentlich nicht der Fall. Leute haben es benutzt, ich habe es gesehen in der Community. Leute haben es sehr gemocht und wir haben relativ wenige Issues bekommen. Was ich sehr überraschend fand, aber ich sah Leute, die haben Sachen gebaut. Ich habe DMs bekommen, ich habe auf uns im Discord gesehen, ich habe Leute auf Twitter gesehen, die Sachen bauen waren.

32:18SPEAKER_00:Also anscheinend haben wir einfach nur relativ Glück gehabt, dass er nicht zu viele Bugs hatten, sage ich mal so. Vielleicht, also es gibt natürlich immer noch einige Bugs. Sehen wir mal, wir sind so bei 34 Open Issues gerade bei Dino-Desktop bei uns. Also es sind ein paar Features auch noch dazwischen. Aber ich sag mal, für so ein System nur 34 Issues bin ich ziemlich froh mit. Es kommt natürlich immer etwas Neues dazu, aber initiellerweise sehr, würde ich sagen, sehr gut, wurde es sehr gut akzeptiert.

32:51SPEAKER_00:Ich hatte am gleichen Tag oder den Tag davor, dass wir released haben, war ich halt bei einer Konferenz und habe ich einen Truck gegeben und Leute waren sehr interessiert. Also es scheint das einfach, ja, Leute brauchen was.

33:08SPEAKER_01:Was waren so die interessantesten Use Cases, die du so gesehen hast, was denn Leute damit gemacht haben?

33:14SPEAKER_00:Oh Gott, gute Frage. Was haben Leute damit gebaut? Da bin ich mir gerade leider nicht sicher. Da fällt mir gerade nichts im Kopf ein. Aber definitiv einiges war, sagen wir mal, mehr Herumexperimentierung. Natürlich gibt es das halt leider sehr viel. Ich sag leider, weil das heißt, dass am Ende doch vielleicht nicht eine richtige App wurde oder einfach nur so ein Side-Projekt wurde. Aber ja, also dass jetzt eine vollständige App von jemandem gebaut wurde und die in Nutzung ist, weiß ich nicht.

33:52SPEAKER_00:Kann ich aber mir vorstellen, dass da vielleicht ein paar herumgehen.

33:55SPEAKER_01:Also ich habe ja auf alle Fälle noch so eine Electron-App, die werde ich vielleicht bei Gelegenheit mal portieren. Die hat nämlich damals, als ich sie benutze, also ist einmal gebaut, ich benutze die jetzt nur für mich so durchgehend, von daher habe ich es ganz lange auch nicht mehr angefasst. Damals war das Problem, dass sie unter Linux super schlecht funktioniert hat, weil das Rendering da so ein bisschen komisch war. Das wird dann mein Test Case für Dino Desktop, das entsprechend besser funktioniert.

34:22SPEAKER_01:Ich brauche eigentlich nur zwei Features dafür. Ich brauche transparente Fenster. Könnt ihr sowas?

34:27SPEAKER_00:Ja, das ist macht.

34:28SPEAKER_01:Das ist schon ein Feature. Und ich brauche Path-Through-Click-Events. Also das ist im Prinzip den Klick nicht Capture in meinem Window. Okay. Wenn ihr es noch nicht habt, ist das jetzt hier meine Gelegenheit, ein Feature-Request zu platzieren so. Aber vielleicht mal schnell auf.

34:49SPEAKER_00:Ich bezweifle es, dass wir es haben. Aber ich werde es mir mal anschauen.

34:56SPEAKER_01:Weil was ich nämlich machen muss mit meiner App, ich lege so ein transparentes Fenster über den kompletten Desktop sozusagen und kann natürlich dann nicht alle Klicks capturen. Ich muss im Vordergrund sein für das, was ich machen will, aber du sollst ja trotzdem dein Zeug benutzen können. Und dementsprechend müssen die Klicks durchgehen. Und wie gesagt, Elektron Contest damals mit so ein bisschen rumgehacke. Wenn Dino Desktop das kann, dann fängt Claude morgen an, die App zu portieren.

35:20SPEAKER_00:Perfekt. Ja, also ich glaube, dass du. Okay, ich kenne die APIs nicht, wie das, sag ich mal, wirklich funktionieren würde, systemweise, aber ich kann mir nicht vorstellen, dass das allzu kompliziert sein könnte.

35:33SPEAKER_01:Ich schoss mich schon mal an. Wie Extendable, würde ich gerade sagen, erweiterbar ist das Ganze denn, also wenn ich jetzt, ne, ich habe jetzt hier diesen Use Case und wir stellen uns vor, es würde jetzt so gar nicht unterstützt werden von Dino Desktop, wie einfach oder wie offen seid ihr denn da für so ein Pair, wenn ihr jetzt sagt, okay, ich kümmere mich darum, eine API dafür zu bauen, ich kümmere mich um die Native-Implementierung auf Renderer-Seite und hier ist mein Pull-Request.

36:05SPEAKER_00:Kannst du kurz nochmal wiederholen?

36:08SPEAKER_01:Also wenn mir jetzt quasi dieses Click-Through-Feature fehlen würde, ja, und ich sage, okay, ich gestalte die API dafür in Dino Desktop, ich kümmere mich um die Implementierung in dem Renderer und ich mache einen Pull-Request für euch, damit ihr das Feature quasi haben könntet. Seid ihr da offen für, baut ihr das eher alles noch gerade eher so selbst? Wie sieht das aus?

36:29SPEAKER_00:Also wir bekommen schon ein paar Pull-Requests, jetzt nicht allzu viele, weil es halt am Ende des Tages ja schon, sagen wir mal, ein sehr komplexes System ist, aber bekommen wir und werden gemerged. Also habe gestern ein paar gemerged. Also ja, ja, würde schon akzeptiert. Also wenn das eine gute Pull-Request ist, natürlich.

36:48SPEAKER_01:Es gibt nur gute Pull-Requests. Für das Dino-Team, was ja doch irgendwie großteils aus dem Web irgendwie kommt und dem Web zu Hause ist, ja. Was war das denn für eine Umstellung, sich im Prinzip jetzt auch mit diesen ganzen Native-Themen zu beschäftigen? Ich meine, jetzt mein Beispiel ist ja nur eins von vielen, ja, weil du hast ja vorhin zum Beispiel auch gesagt, man kann auch Menü-Bar- oder Doc-Apps irgendwie dazu bauen. Da musst du dich ja auch beschäftigen.

37:14SPEAKER_01:Das ist ja was, was jedes Betriebssystem quasi komplett unterschiedlich handelt. So in Windows gibt es diese Tray-Icons, im Mac OS ist irgendwie so ein Doc-Ding, in Linux hängst du halt hart an deinem Desktop irgendwie dran, wie das dann integriert und dargestellt wird. Und das sind ja alles so Fragen, mit denen ihr euch vorher so quasi überhaupt nicht beschäftigen musstet. Und auf einmal musst du dich so um Native App Development kümmern. Wie näher, also wie kommt man da rein?

37:40SPEAKER_00:Also ich werde, ich würde sagen, das ist nicht so unterschiedlich, zu was wir zuvor gemacht haben. Halt ja, wir haben uns nicht mit irgendwie Desktop-Systemen wirklich bekannt gemacht zuvor, aber am Ende des Tages, Dino ist ja eine Runtime, die auf, sagen wir mal, Linux, Windows, Mac funktionieren und wir mussten schon Sachen bauen, die einfach sehr unterschiedlich am Ende des Tages funktionieren under the Hood, aber gleich sich gleich sein müssen für Users, auch wenn die auf verschiedenen Systemen komplett anders sind.

38:15SPEAKER_00:Also es ist jetzt nicht irgendwie etwas, das wir mit nicht schon ein bisschen uns mal durchgesetzt haben mussten, dass einfach Sachen nicht funktionieren gleich auf verschiedenen Systemen. Ist halt natürlich bei Desktop-Apps und das ganze Environment schon ein bisschen, sag ich mal, aggressiver, ein bisschen schlimmer, dass da schon die APIs sehr, sehr anders sind. Aber ja, also wie gesagt, war jetzt nichts etwas, was wir nicht irgendwie schon ein bisschen kennen.

38:48SPEAKER_00:Und ja.

38:51SPEAKER_01:Welches Betriebssystem war denn da am, oh Gott, ich will das nicht wertend formulieren. Welches Betriebssystem hat die größte Herausforderung für euch dargestellt? In dieser Vereinheitlichung, ne? Weil das ist, man kennt es ja, man will so eine einheitliche API irgendwie schaffen, der ist okay, ich habe hier, weiß ich nicht, für Linux Map das irgendwie ganz gut, Windows passt da auch irgendwie so rein und bei Mac OS ist es irgendwie wieder alles anders.

39:15SPEAKER_01:Jetzt müssen wir diese ganze API irgendwie so weit auseinanderbiegen, dass er diese drei irgendwie so beherbergen kann. Gab es da eines, wo du sagst, okay, das war schon immer mehr herausfordernd oder war das so, in jedem Use Case irgendwie wieder ein anderer, der da am schlimmsten war?

39:30SPEAKER_00:Ja, ich würde schon sagen, verschiedene Use Cases, andere Systeme am schlimmsten. Also das eine, was ich mich erinnere, was echt anstrengend war, war Notifications auf macOS. Das ist Chaos, pures Chaos. Also, das war, glaube ich, irgendwie zwei, anderthalb Woche oder so war es, nur das irgendwie zum Laufen zu bekommen. Irgendwie ganz, ganz pingelig, wie es sein genau gemacht werden muss. Sonst würde ich sagen, aber generellerweise das schlimmste OS ist wahrscheinlich Linux.

40:04SPEAKER_00:Weil es einfach kein ist. Weil das Desktop fragmentiert ist? Ja, weil es so fragmentiert ist und einige APIs nicht gibt, vielleicht ein paar Environments und auch einfach generell ein paar Sachen schon anders funktionieren. Also ein paar Features, die Dino-Desktop habe, funktionieren auf Linux nicht. Jetzt sag nicht viele, aber ich glaube, Spray-Icons, ein paar Sachen sind limitiert, wenn mich richtig erinnere, weil das einfach alles ganz anders funktioniert und dann geht doch nicht.

40:34SPEAKER_00:Also gibt es ein paar Sachen.

40:36SPEAKER_01:Es gibt ja gar nicht so dieses eine Linux. Ich meine, es gibt da verschiedene Distributionen, es gibt verschiedene Desktops. Wie habt ihr denn irgendwie das Target dafür überhaupt festgelegt, um zu sagen, okay, das ist die Art von Linux, die Kombination von Distro und Desktop, die wir irgendwie supporten wollen?

40:53SPEAKER_00:Gute Frage. Also es ist einfach, wir benutzen das.

40:58SPEAKER_01:Oder ist das so der eine Engineer, der halt irgendwie, weiß ich nicht, Fedora am Laufen hat und bei dem muss dann irgendwie alles probiert werden und wenn es da läuft, dann ist schon okay.

41:06SPEAKER_00:Ja, sagen wir mal, es geht schon sowas in der Nähe. Also wir versuchen nicht auf so viele verschiedene unterschiedliche Systeme, aber ich glaube, weil wir haben unseren CI automatisiert, dass wir richtig Tests end-to-end testen können und ich glaube, unser CI ist Ubuntu, wenn ich mich kritische GitHub, einfach ein GitHub Runner, ich glaube, die sind Ubuntu. Und dann ich habe Arch mit KDE. Also ich teste es da drauf. Und ja, wenn das funktioniert, dann funktioniert es.

41:37SPEAKER_00:Wenn nichts funktioniert, dann macht irgendjemand eine Issue auf und da muss ich irgendwie herausfinden, wie ich das zum Laufen bekomme, wenn ich nicht deren System habe. Und das ist dann auch schon ein bisschen eine Aufgabe. Aber generellerweise sind APIs schon, sag ich mal, ein bisschen standardisiert. Also es ist, es gibt ja, habe ich ja X11 und Wayland. Und wir haben uns, glaube ich, auf X11 am Anfang basiert. Und ich glaube, jetzt funktioniert Wayland auch.

42:07SPEAKER_00:Also ja, wenn Deef 2 funktionieren, dann funktioniert es eigentlich, sag ich mal, so 90%, wenn noch nicht mehr von Linux-User. Das ist ja gut genug.

42:18SPEAKER_01:Du hast eben den CI-Prozess angesprochen, lass uns vielleicht da einmal kurz drüber sprechen. Wie kann ich dir, oder muss ich mir das denn vorstellen, wenn du so ein Testing-Setup aufsetzen willst für das Framework und die Runtime selbst, ja? Und du dich quasi auch, eigentlich kannst du dich auf nichts verlassen und nichts trauen. So, du musst ja alles irgendwie validieren, so geht dieses Fenster auf, wenn ich das irgendwie caller, ja, erscheint da ein, also weiß ich, erscheint ein Tray-Icon und ist da das richtige Bild drin, so ungefähr, ja.

42:52SPEAKER_01:Da wüsste ich jetzt irgendwie gar nicht, wie ich das testen wollen würde. Also du musst ja, weiß nicht, macht man da viel so Visual Testing, man macht einfach so ein Screenshot und guckt, ob das richtige Icon da drin auftaucht. Wie ist euer Setup?

43:06SPEAKER_00:Also das ist schon ein interessantes Problem zum Lösen, weil ich hatte dann mit jemand von Tauri gesprochen und weil ich wollte wissen, wie die das machen. Und da wurde mir gesagt, wir testen solche Sachen überhaupt nicht. Wir machen Live-Testing mit den Usern. Bananensuftware. Weil es so kompliziert ist, überhaupt etwas richtig end-zu-end zu testen, weil das Einzige, was du machen kannst, wirklich ist, A, Screenshots und B, APIs anfragen auf dem System und checken, hey, ist diese auch nur sehr beschränkt irgendwie was?

43:44SPEAKER_01:Also natürlich kannst du so ein System fragen, ist dieses Fenster da und ist es groß genug und bla, aber halt dann den Inhalt von dem Fenster oder in den Prozess reinzugucken, dass du die Interprocess Communication irgendwie läuft, das kannst du ja von außen, also per Design ja eigentlich auch nicht. Das ist ja Teil des, also das ist ja ein Feature vom Betriebssystem, dass du in den laufenden Prozess nicht unbedingt reingucken kannst.

44:04SPEAKER_00:Genau. Also wir haben ein paar verschiedene Lösungen, um Sachen zu testen. Eins ist, wir haben einfach ein, sagen wir mal, ein Backend, was nicht wirklich da ist für das einfach so ein Testing-Backend, sag ich mal. Das funktioniert komplett anders, das ist einfach nur irgendwie ein Harness und sieh, dass alles wirklich so gecollt ist, wie es gecot werden soll, ist halt immer noch nicht komplett richtig, weil dann kannst du immer noch nicht komplett wissen, ob alles funktioniert.

44:35SPEAKER_00:Also vor ein paar Tagen, glaube ich, habe ich jetzt irgendwie eine Issue gesehen, hey, ich bekomme überhaupt keine Events, wenn V-Sizen auf diesem System und dachte, hä, warum das denn? Und da muss ich jetzt noch weiter schon in den nächsten Tagen, was da los ist. Aber das ist, solche Sachen sind sehr schwierig zu testen und dafür haben wir auch keine Lösung gehabt. Also wenn Taurus nicht geschafft hat, die einzige, die ich noch fragen werde, wahrscheinlich ist Elektron, wie die das machen, weil das kann ich mir nicht vorstellen, dass ein Projekt so groß wie Elektron nicht irgendwie eine Infrastruktur dafür hat.

45:07SPEAKER_00:Und wenn nicht, dann wäre es vielleicht mal Zeit, dass die OSS mal etwas hinzufügen, dass wir Sachen richtig testen können, weil das ist schon nicht ideal. Ich finde, Sachen müssen testbar sein. Und wenn nicht, dann gibt es ein Problem.

45:22SPEAKER_01:Ja, das ist ein super Punkt. Also wir haben ja auch schon eine Folge über Tauri gemacht und da habe ich gar nicht nachgefragt, wie die das handeln, aber du hast vollkommen recht. Da gibt es halt irgendwie nichts. Ja. Crazy. Okay, lass uns vielleicht, bevor wir über die Zeit rennen, noch so ein bisschen den Vergleich anstellen, ohne jetzt irgendwie nur auf Elektron oder Tauri rumzubashen oder irgendwas. Wie würdest du denn sagen, ist da Dino aktuell so positioniert im Vergleich, was vielleicht so Performance, Bildkomplexität, Bundle-Size, also die üblichen Metriken, auf die ich halt so gucke, wenn ich mir so eine App zusammenschrauben will, wo seht ihr euch da gerade?

46:08SPEAKER_00:Also dafür haben wir sogar eine Seite in unseren Docs, in unseren Dino-Desktop-Docs, da gibt es eine Comparison-Seite und da gibt es eine schöne Tabelle, die man sich anschauen kann. Verlinken wir auch direkt. Perfekt. Und ja, also es ist nicht, dass irgendwie Dino-Desktop jetzt das perfekte System ist. Es gibt nie perfektes System natürlich. Aber ich würde sagen, also App-Size sind wir mittelprächtig drauf. Es ist am Ende, hängt ab, ob du WebView benutzt oder Chromium benutzt, weil Chromium ist halt schon massiv.

46:45SPEAKER_00:Deswegen, da sind wir dann schon größer als zum Beispiel Tauri. Tauri am Ende ist ja nur WebViews und am Ende auch eine Rust-App. Du hast keine ganze JavaScript-Runtime dabei. Also da ist Tauri natürlich viel kleiner. Aber dafür haben wir halt die ganzen Dino-Features wie so Node-Compatibility, aber das wollen ja am Ende des Tages ja eh alle. Ja, Cross-Compilation ist halt eins der größten Sachen, würde ich sagen, noch, die wir machen. Weil, soweit ich weiß, gehen bei allen anderen Systemen das nicht, außer Elektron.

47:20SPEAKER_00:Die haben halt ein System dafür, aber das ist auch nicht perfekt. Also Dino kann ja schon seit, also schon Dino Compilen konnte damals, wann wir es rausgebracht haben, auf andere Targets zu kompilieren, weil am Ende des Tages, wie vorhin gesagt, wir müssen einfach nur eine People-Binary runterladen und dann einfach Sachen am Ende anhängen.

47:45SPEAKER_01:Weil ihr quasi sozusagen auf dem Bildsystem gar nicht kompiliert, sondern ja nur concettet und dann ist quasi das Binary schon gebaut.

47:53SPEAKER_00:Genau, deswegen können wir cross-compilen überall. Also du kannst eine Dino-Desktop-App von Mac auf Windows bauen. Es gibt ein paar Limitations, sag ich mal. Wir haben auch Installers, also du kannst MSI-File oder App-Image für Linux oder dort DMG. Und da die, also ich glaube, MSI geht nur auf Windows, also das geht leider nicht cross-kompilierbar. DMG definitiv nicht, weil das irgendwie ein spezielles Tool braucht, was nur auf Mac leider ist.

48:29SPEAKER_00:Also da sind ein paar Limitations, aber generellerweise, ja, eine App selbst kann schon cross-kompiliert werden.

48:40SPEAKER_01:Und du hast gerade schon gesagt, ne, in manchen diesen Zahlen liegen da unterschiedliche von diesen Playern irgendwie so vorne. Und am Ende ist das ja, glaube ich, auch immer so eine Prioritätenabwägung. Also Tauri legt das halt hart darauf an, irgendwie ultra klein zu sein und liefert halt dafür halt irgendwie keinen eigenen Renderer mit. Was sind denn so eure ein, zwei Prinzipien, Prioritäten, die so die Entwicklung von Dino Desktop beeinflusst haben und auch zukünftig beeinflussen werden?

49:13SPEAKER_01:Was ist euch denn am wichtigsten bei dem Produkt? Ja, weil offensichtlich ist es ja nicht, dass ihr das kleinste Binary sein wollt oder den schnellsten Coldstart oder keine Ahnung, was da irgendwie so alles gibt. Aber woran orientiert ihr euch? Was ist so euer Polarstern, Nordstern, was auch immer, Stern?

49:33SPEAKER_00:Das ist eine sehr gute Frage, die ich nicht sehr gut antworten kann, weil wir haben kein richtiges Konzept, sag ich mal, was vielleicht sich ein bisschen blöd anhört, aber wir wollen einfach ein Tool bauen, was funktioniert und unsere, sag ich mal, Ideen und Konzepte einfach, die das Dino-Lair hat, sag ich mal so.

49:51SPEAKER_01:Aber das ist ja das ist ja ein Konzept. Also ich meine, natürlich ist es jetzt nicht so in einen catchy Satz irgendwie zu bringen, aber zu sagen, so, Dino Desktop soll sich halt am, ne, wie vorhin schon, soll sich halt nach Dino anfühlen. Genau. Dann ist es vielleicht einfach das. Ja. Ja, dann. Ja, kann man so sagen, genau. Okay. Ja, ich glaube, ich bin hier mit meinen Fragen gut durchgekommen. Meine Lieblingsfrage am Schluss ist immer, welche Frage habe ich dir nicht gestellt?

50:26SPEAKER_01:So, über welches Thema wolltest du unbedingt reden, hast dich vorbereitet und hast gesagt, so Mensch, der Jan hat mich jetzt gar nicht zu, weiß ich nicht, Interprocess Communication befragt. Da wollte ich unbedingt so gerne noch drüber reden. Oder er hat mich gar nicht zu dem Dev- und Debug-Tooling oder keine Ahnung, so deine Chance. Welches Thema haben wir so gar nicht gestrichen und wo fehlt uns noch was?

50:49SPEAKER_00:Ja, also eigentlich Dev-Setups, sag ich mal, wäre wahrscheinlich das Größte, weil wir haben komplett ein ganzes Hotmodul-Reloading-System. Du kannst deine App einfach komplett, du musst nicht die ganze Zeit neu bauen, kannst einfach dash-HMR, glaube ich, ist es. Oder dash-dev, ich kann mich gerade nicht erinnern. Und ja, du kannst einfach deine App bauen. Ob du jetzt irgendwie ein Framework benutzt, dann benutzt es den Framework, also es erkennt Frameworks und es kann dann sehen, was es machen muss mit dem Framework.

51:22SPEAKER_00:Und du kannst einfach dann Dino Desktop callen und dash-dash immer und bekommst einfach alles hot, module reloaded und auch nicht-Modules, einfach auch alle Assets und sowas. Also alles ist schon, sag ich mal, sehr komplett integriert, dass einfach du nichts machen musst. Du kannst einfach nur bauen. Das ist halt die Idee am Ende des Tages für Dino-Desktop. Du musst nicht so viel überlegen, über wie das System funktioniert. Wir machen alles für dich.

51:55SPEAKER_01:Und wahrscheinlich sind ja auch so Dev-Tools irgendwie schon mit drin. Also ich nehme an, dass mindestens, wenn man den Chrome-Renderer nutzt, dann wird man irgendwie auf die Chrome-Dev-Tools kommen. Aber wahrscheinlich gibt es ja auch einen Analog zu, wenn ich das native Web-Rendering nehme, dann gibt es ja auch immer irgendeine Art von Dev-Framework dazu, oder?

52:16SPEAKER_00:Ja, also genau, du kannst die Dev-Tools vom System, also vom Renderer benutzen. Also sagen wir mal jetzt den Chrome-Inspector, wenn du mit Chrome bist oder Firefox-Dev-Tools oder Apple, was auch immer. Aber am besten funktioniert, würde ich sagen, Dino-Desktop mit dem Chrome-Renderer, weil am Ende des Tages Dino ist halt auf V8 basiert. Das heißt, wir benutzen den gleichen DevTools-Setup als Chrome und da können wir schon ein paar nice Sachen machen.

52:51SPEAKER_00:Zum Beispiel kannst du einfach nur mit einem DevTools-Window von Chrome beides den Renderer inspektieren und gleichzeitig aber auch den, sag ich mal, den Server-Coder. Ist ja kein Server wenn du des Tages, aber kannst, sagen wir mal, den Dino-Code inspektieren. Alles in einer Window und das ist alles komplett integriert, dass du.

53:16SPEAKER_01:Wie würde ich das machen, wenn ich jetzt nicht die Chrome-Renderer nehme, sondern irgendwas anderes? Wie komme ich dann an den Konsolen-Output von meinem Hauptprozess dran?

53:27SPEAKER_00:Also dann musst du Dino-Desktop oder Dino generell hat immer eine Dash-Inspect Flag und dann würdest du halt zwei separater haben. Dann würdest du die vom Browser, was auch immer, also wie gesagt, sagen wir mal, Firefox-Dev-Tools und dann halt brauchst du halt dann eine Chrome-Inspektor offen für Dino selbst.

53:48SPEAKER_01:Und wo kommt dieser Chrome-Inspector her? Weil der ist ja nicht in der Dino Runtime drin, oder?

53:55SPEAKER_00:Also du musst, also um Chrome-Inspector zu nutzen, musst du schon Chrome installiert haben.

54:02SPEAKER_01:Okay, und das macht dann quasi einfach nur so eine Remote-Session, also eine Connection in den Prozessor.

54:08SPEAKER_00:Was am Ende des Tages Inspectors noch, also jedenfalls im Falle von Chrome und V8 und sowas ist, ist einfach nur ein WebSocket-Server, das einfach ein bestimmtes Protokoll hat und ein paar weitere Sachen noch. Und das erkennt dann halt Chrome.

54:25SPEAKER_01:Okay, okay. Das ist gut, dass wir nochmal drüber gesprochen haben. Tut Dino irgendwas in seinem, oder Dino Desktop irgendwas in seinem Compile-Schritt, um diese ganzen Debug-Tools und Flags irgendwie auszubauen? Oder zu deaktivieren oder wie auch immer, oder könnte ich, wenn ich jetzt, wenn du gibst mir jetzt eine Dino-Desttop-Anwendung, ja, und ich starte die mit Dash-Dash-Inspect bei mir lokal, ist das dann immer noch alles drin? Oder ist das quasi in dem fertig kompilierten Produkt nicht mehr?

54:56SPEAKER_00:Das ist immer noch drin, weil einfach, halt wir können es nicht aus dem Renderer rausnehmen, natürlich, weil der Render ist der Renderer, wir werden jetzt nicht irgendwie aus Chromium versuchen, irgendwie Sachen zu löschen. Das wäre alles zu kompliziert. Und der Inspektor in Deno selbst, der ist auch immer noch dabei, weil das einfach ein Teil, sagen wir mal, von V8 ist und da gehen er auch jetzt nicht rein, also am Ende des Tages. Es ist immer noch dabei.

55:19SPEAKER_01:Aber ihr könntet dann eine Runtime schippen, die zumindest die Flags einfach nicht mehr anbietet.

55:24SPEAKER_00:Genau. Das wäre eine Möglichkeit, ja. Aber wenn du Dino Desktop eine Binary rausbekommst, gehen eh keine Flags mehr. Also deswegen kannst du, würde ein User das irgendwie nicht möglich haben, überhaupt, sag ich mal, die Flags zu enablen, dass die irgendwie den Inspektor irgendwie magischerweise wieder anmachen, wenn die nicht irgendwie die Entwickler der Apps sind. Also vielleicht wäre es irgendwie. Naja, vielleicht gäbe es eine Möglichkeit, aber da musst du dann wirklich in die Binary reingehen und Sachen ändern.

55:55SPEAKER_00:Also da, da bin ich mir jetzt nicht hundertprozentig, aber ich glaube, da kann man nicht viel machen.

56:02SPEAKER_01:Und selbst wenn, also auch ein geändertes Binary, dann ist es im Zweifelsfall nicht mehr signiert und bla bla auch alles nicht so ganz trivial. Und also am Ende gilt ja aber wahrscheinlich auch für eine Dino-Desttop-App, genauso wie für alle Elektron und sowas Apps ja auch. Was man da schippt, ist ja eigentlich ein Webfrontend. Und im Zweifelsfall muss man ja immer damit rechnen, dass egal was da im Quelltext oder in deinem Debug-Output oder im Logstatement oder irgendwo drin ist, ist halt kein Secret.

56:34SPEAKER_01:Mit genug Wollen und Energie kommt man da ran, ja, es ist nicht irgendwie da reinkompiliert, sondern es ist halt am Ende immer noch, in Anführungszeichen, nur TypeScript. Ein bisschen obfuscated und komprimiert oder keine Ahnung was, aber am Ende ist es halt immer noch lesbar. Genau. Bytecode oder so. Und selbst den kann man zurückkompilieren. Genau. Alright. Cool. Dann haben wir, glaube ich, alles. Und wir können zu unserer letzten Kategorie übergehen.

57:07SPEAKER_01:Wir können nämlich sprechen über die Pixel of the Day. Du bist Gast, du hast anfangen. Leo, was hast du für uns heute im Gepäck? Oh, wow, ich bin.

57:34SPEAKER_00:Meine Güte. Also bleiben wir schon noch immer noch beim Programmieren, würde ich sagen, eigentlich ZB Search. Also ZB Search. Da kommst du wahrscheinlich an ein paar andere Sachen, wenn du einfach nur googelst. Also zbesearch.dev ist das. Und das ist einfach eine Open Source Library für Search. Hört sich sehr banal und langweilig an, ist aber halt Search-Systeme sind nicht einfach. Und ich bin damit ein bisschen herumexperimentieren und finde im Moment sehr interessant und bin am Denken, vielleicht ein paar von unseren Sachen darüber raufzuwechseln.

58:14SPEAKER_00:Vielleicht sogar auch GSR komplett, das benutzen werden soll.

58:20SPEAKER_01:Aber ja, sieht einfach interessant aus. Was ist da aktuell für die Suche? Ebena? Was benutzt ihr da aktuell für die Suche in TSA? Benutzen im Moment Algolia. Ah ja, das nutzen wir auch bei der Programmierbar. Also ehrlicherweise muss man sagen, so als Lösung für, du musst überhaupt nicht viel darüber nachdenken und es funktioniert einfach, sind die schon sehr gut.

58:41SPEAKER_00:Ja, aber das Problem ist einfach, wir wollen ein paar spezielle Sachen mit JSR machen, von wegen Search und das geht leider nicht in den Limits von Algolia, was die uns umsonst gegeben haben als Open Source Projekt. Wir bräuchten nämlich irgendwie mindestens, glaube ich, 20-fach der Nutzung. Wenn nicht so, für was wir machen wollen. Also da wollten, dass die wie einen Kontrakt signieren und schön was bezahlen, was für JSA nicht eine Option ist, weil es am Ende des Tages einfach ein Open Source Projekt ist.

59:18SPEAKER_01:Okay, dann, wenn du schon so ein Coding-Pick hast, dann nehme ich auch ein Coding-Pick. Ich hatte ja hier zwei zur Auswahl, was der andere war, werden wir nie erfahren. Und ich bringe als Pick mit, ich hoffe, ich hatte das noch nie, Scraps. Ich weiß nicht, ob du Screeps kennst, das ist ein Strategiespiel. Und ich hatte das, glaube ich, vor, oh Gott, das ist schon sehr, sehr lange her, mal auf Kickstarter gebackt und mittlerweile gibt es das auch auf Steam oder so zu kaufen.

59:45SPEAKER_01:Und was der Clou an der Sache ist, für jede deiner Einheiten oder jeden deiner Einheiten-Typen musst du in JavaScript, ja, der Kreis schließt sich, das Verhalten quasi selbst programmieren. Das heißt, es spielt sich auch so ein bisschen MMOR-PG-mäßig, im Sinne von, du kannst aus deiner Session disconnecten und weil alle deine Einheiten ja wissen, was sie tun müssen und wie sie agieren sollen und bla, läuft quasi dieses Spiel auch ohne dein Zutun weiter.

1:00:19SPEAKER_01:Du hast auch gar keine Möglichkeit, wenn du drin bist, irgendwas zu machen und so, weiß ich nicht, Age of Empires oder Commandant Conquer mäßig zu sagen, so, ich markiere diese Einheiten und ich schicke sie dahin und nein, das Einzige, was du machen kannst, sagst du, okay, ich nehme mir diese Einheit und ich tausche quasi ihr Skript aus und dann fängt sie halt an, sich anders zu verhalten an. Das ist alles, was du machst. Und das ist im Prinzip eine Echtzeitstrategie für Developer und das fand ich damals schon ganz cool, ich finde es immer noch ganz cool.

1:00:47SPEAKER_01:Ich habe leider nicht so viele Leute, mit denen ich das spielen kann, weil das schon auch nicht, es hat so eine gewisse Hürde. Also du fängst halt an und keine Einheit macht gar nichts. Und dann fängst du da an und sagst, okay, jetzt programmiere ich mal hier so ein bisschen los. Mittlerweile gibt es, glaube ich, auch so Cross-Compilation zu, du kannst es auch in, weiß ich nicht, Python, Rust, PHP irgendwie hochladen und sie schieben das dann irgendwie zu, also ich glaube, das Spiel macht immer noch, also die Engine macht immer noch nur JavaScript-Evaluation, also es wird irgendwie dann transpiliert oder sowas.

1:01:16SPEAKER_01:Aber ja, mega cool. Und wenn ihr da Bock habt, Bock habt, das zu spielen, dann meldet euch bei mir und dann spiele ich das nämlich endlich auch mal wieder, wenn es ja noch ein paar andere Leute finden.

1:01:27SPEAKER_00:Ja, ich habe das vor einigen Jahren schon mal gehört, aber ich habe nie wirklich zu tief reingeschaut. Vielleicht wäre das mal Zeit, dass ich mal ein bisschen tiefer reingehe.

1:01:36SPEAKER_01:Ja, es hat halt leider, wie gesagt, also du musst halt dann so ein bisschen natürlich auch die API lernen, im Sinne von, ne, wie kannst du, was ist halt so die API, wie fragst du ab, wo so eine Einheit ist, was um sie rum ist, was sind so die Commands, du dir geben kannst, das ist nicht alles ganz trivial, aber es macht halt Spaß, wenn es dann mal läuft. Und man hat halt immer so diesen, weiß ich, diesen angenehmen Facts, du guckst da drauf und denkst so, ja, das habe ich gemacht.

1:02:04SPEAKER_01:Keine andere Einheit auf dieser Welt verhält sich so wie meine. Im Guten wie im Schlechten. Wunderbar. Das als mein Pick of the Day, Screeps. Oder also dass die MMORPG-Variante davon heißt, Screeps World. Es gibt auch Screeps Arena, wo man einfach nur so skirmish gegeneinander spielt, aber Scrips World ist eigentlich das, was man haben will. So. Cool. Dann, Leo, danke dir für die Zeit. Danke für die ganzen Insights und Insider-Stories zu Dino Desktop und Dino im Allgemeinen.

1:02:40SPEAKER_01:Eine allerletzte Frage vielleicht noch, weil die wird mir ab und zu irgendwie immer gestellt, so aufs Spaß bei uns in den News. Immer wenn ich anfange über Dino zu reden, kommt dann Dave rein und sagt so, und, Jan, was ist dein Lieblingsdino? Also, Leo, letzte Frage für heute. Was ist dein Lieblingsdino? Wie meinst du?

1:02:57SPEAKER_00:Achso, okay. Du musst mal um die Ecke denken. Ich muss, also die Sache ist, Dino selbst, das Mascott, ist leider kein richtiger Dinosaurier basiert. Das ist so mehr konzeptuell. Aber ich glaube, was am nächsten, na, Stegosaurus ist schon mal nicht richtig. Das fehlt ja dann die Stecheln hin auf den Rücken dran. Also, gute Frage. Was wäre, weil, also ich selbst habe jetzt nicht unbedingt ein Lieblings-Deno, muss ich sagen. Oder Dino. Da würde ich einfach gehen mit, was Dino selbst ist, aber leider ist es vollkommen fair.

1:03:37SPEAKER_01:Dein Lieblingsdino ist der Deno. Genau. Wunderbar. Dann, wie gesagt, danke dir. Schön, dass du da warst. Bis bald, hoffentlich. Danke mal mindestens zweimal im Leben. Und danke an alle da draußen, die wieder zugehört haben. Wenn ihr Fragen, Anregungen, Kritik zur Folge habt, dann immer gerne eine E-Mail an podcast.programmier.bar oder schreibt uns auf Social Media, hinterlasst einen Kommentar, wo auch immer ihr diese Folge gerade hört. Wir lesen alles mit und wir freuen uns.

1:04:07SPEAKER_01:Und bis zur nächsten Woche. Bis dann. Ciao, ciao.