Deep Dive 218 –

Deno Desktop mit Leo Kettmeir

13.10.2026

// Podcast
// Deep Dive 218

Shownotes

Electron, Tauri, Electrobun – braucht es wirklich noch eine weitere Lösung, um aus dem Web-Stack heraus Desktop-Apps zu bauen? Mit Deno Desktop hat Deno seit Version 2.9 genau das gewagt und Leo Kettmeir, Software Engineer bei Deno, nimmt uns mit hinter die Kulissen dieses neuen Features.

(Hinweis: Nach der Aufnahme dieses Gesprächs hat Deno Land Inc., die Firma hinter Deno und Deno Desktop, bekannt gegeben, dass sie von Cloudflare übernommen wird. Was das konkret für die Weiterentwicklung von Deno Desktop bedeutet, ist aktuell noch unklar.)

Im Gespräch zeigt Leo, warum Deno sich selbst längst nicht mehr nur als JavaScript-Firma versteht, sondern als Tooling-Company, die Entwickler:innen das Leben leichter machen will. Sei es mit der Runtime selbst, der Package Registry JSR, dem Webframework Fresh oder eben mit Deno Desktop als Antwort auf Electron.

Erst dieses Jahr fand das Team eine praktikable Architektur für das Projekt, wobei sich Deno Desktop bewusst Konzepte von Tauri und Electrobun abgeschaut und mit dem eigenen „Deno-Flair“ kombiniert hat: einfache Nutzung, Browser-APIs statt proprietärer Schnittstellen und ein Befehl reicht, um aus einer bestehenden Webseite eine Desktop-App zu machen.

Technisch spannend ist die Bauweise: Deno Desktop lädt eine spezielle Runtime-Binary herunter, hängt die eigene, gebündelte App per Magic Header einfach dahinter, ähnlich wie es Deno Compile schon macht, und erzeugt so eine einzige Binary. Weil dabei nichts kompiliert, sondern nur zusammengefügt wird, lässt sich fast überall für jede Zielplattform cross-kompilieren. Beim Rendering kann man zwischen der schlanken System-Webview und dem Chromium Embedded Framework wählen.

Auch bei der Developer Experience zeigt sich der Anspruch: Hot Module Reloading, automatische Framework-Erkennung und ein einziges Chrome-DevTools-Fenster, in dem sich gleichzeitig Renderer und Deno-Prozess inspizieren lassen.

Ganz fertig ist die Reise aber nicht. Deno Desktop gilt in 2.9 offiziell als experimentell und laut Leo geht es aktuell vor allem um Bugfixes statt fehlender Kernfunktionen. Auch beim Testen von Desktop-Apps gibt es branchenweit keine wirklich guten Lösungen, selbst Tauri verlässt sich hier eher auf Live-Feedback der Nutzer:innen als auf automatisierte End-to-End-Tests.

Ausblick gibt es trotzdem: iOS-Builds sind schon möglich, Android ist in Arbeit, weshalb der Name „Deno Desktop“ langfristig vielleicht zu eng gefasst ist.

Download

/transkript/programmierbar/deep-dive-218-deno-desktop-mit-leo-kettmeir

Jan: Hallo und herzlich willkommen zu einem neuen Deep Dive hier in der programmier.bar und ich glaub, wir machen was, was wir so ganz selten bisher gemacht haben. Wir sprechen nämlich heute über Dino Desktop und nicht, dass wir über selten über Dino sprechen, das ist ganz und gar nicht der Fall. Wir sprechen natürlich häufig über Dino, aber wir widmen uns tatsächlich hier in diesem Deep Dive in 'nem Thema, was vor gar nicht allzu langer Zeit schon mal bei uns in den News war. Und zwar haben wir in den News 26, 20 26 schon über Dino Desktop gesprochen. Damals war es grade frisch erschienen und wir haben so unsere ersten Eindrücke und Meinungen dazu geteilt. Ja, das ist ja ganz interessant, das sollte man sich vielleicht noch mal 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 hundertprozentigativer anschauen kann, habe ich mir Verstärkung dazu geholt und wir haben heute den Leo Kettmeier von Dino, also ich sag man von Dino oder sagt man von Dino Land? Leo, wie sagt ihr das?
Leo: Ja, ja von Dino, also Dino. Gott, also wie es auch überhaupt ausgesprochen wird, das ist auch noch 'n ganz anderes Thema, aber
Jan: Sehr gut, da kommen wir dann bitte direkt gleich dazu. Okay. Weil das weil das ist auch bei uns manchmal so Stein des Anstoßes hier ist so, ja. Aber dann auf alle Fälle Leo, herzlich willkommen. Schön, dass Du bei uns bist, dass Du Zeit genommen hast, einmal über Dino, Dino, wie auch immer zu sprechen. Du bist angestellt bei Besag der Firma, aber warst vorher auch schon so Open Source Freiwillig Contributer und hast dann den den Sprung in die in die Vollzeitstelle quasi dazu geschafft. Wie wie muss ich mir das vorstellen?
Leo: Ja, also ja, also anderthalb Jahre hatte ich dann Open Source Contribution gemacht. Das war einfach zufällig hab ich die nur gefunden über einfach eine Youtube von dem Talk so node. Mhm. Ja, den
Jan: Den hab ich auch gesehen damals?
Leo: Ja, ja, genau. Und ja, das hatt ich einfach dann mir angeschaut, hab ich 'n bisschen recherchiert, bin dann die Community beigetragen beigetreten und dann wollte ich 'n paar Features haben, die einfach nicht gab und weil ich irgendwie Discord Bots machen wollte. Weil das ist ja was man, wenn man 'n bisschen JavaScript machen will und nicht viel weiß, das ist irgendwie dann so das das große Projekt immer, dass einige machen und das ja, damals konnt konnte ich sehr wenig für JavaScript und Typescript. Fangen wir nicht mal an mit Rust und so was. Da wusste ich nicht mal, dass es was Rust überhaupt war. Und dann ja, hat sich halt einfach das 'n bisschen entwickelt. Ich wollte Features haben, habe ich angefangen, 'n paar Sachen zu lernen und ja.
Jan: Du bist uns heute zugeschaltet aus Rotterdam. Das ist wie der Zufall des Sojiarsia in den Niederlanden und kleine kleine Notizen am Rand so, Pet Peef von mir ist ja so, wenn Leute immer Holland sagen, so ne, wenn sie Niederlande meinen. Aber Rotterdam ist wirklich Holland, oder?
Leo: Es ist Süd Holland, weil Also es gibt Holland sind zweigeteilt. Also offiziell, also wenn ich meine Adresse eingeben muss, muss ich Süd Holland sagen, weil das einfach eine andere Region ist als Nord Holland. Ja, es gibt Holland, aber da ist einfach die 2 zusammengeworfen. Offiziell gibt's, sag ich mal,
Jan: nicht. Und Du bist ja auch nicht der 1. Von euch, der hier bei uns in der programmier.bar ist, der Luca auch von DenoDino, war ja auch schon 'n paarmal bei uns. Der sitzt ja auch in den Niederlanden. Aber das ist jetzt nur 'n Zufall. Man muss nicht in den Niederlanden sitzen, für euch zu arbeiten, oder?
Leo: Nee. Es ist einfach, ich glaube, außerhalb Amerika ist Niederlanden, wo wir einfach am meisten Leute jemals hatten. Ist einfach 'n pures Zufall,
Jan: purer Zufall. Oder da tummeln sich vielleicht einfach die richtigen Leute. Also vielleicht ist das ja auch so 'n Thema, ne. Ja.
Leo: Er weiß.
Jan: Aber ich hab auch gesehen, Du sitzt nicht nur in Rotterdam, Du sitzt auch in den TC 39 und 55 für Dino und werkelst da quasi vollkommen übergreifend auch noch an der Zukunft von Javascript respektive typecript mit. Genau, das ist ja auch ganz abgefahren. Ja, ja, das ist,
Leo: da bin ich eigentlich erst seit Neujahrs dabei. Das war dieses Jahr das 1. Meeting, dass ich dabei war und daher, dass dann Luca ja von Deno weggegangen ist, mussten wir jemand haben, der das übernimmt. Und daher, dass ich schon 'n bisschen mit Standards hatte über Deno, hab ich dann das einfach übernommen. Und das, ja, da kann man schon interessante Sachen lernen und machen.
Jan: Das find ich immer cool. Also wir hatten vor Kurzem auch 'n Deep Dive gemacht mit jemandem vom W 3 c so, ja. Und da quasi zu sehen, dass, also ohne da jetzt irgendjemanden
Leo: zu nahe zu reden, aber
Jan: das sind auch ganz normale Menschen so, ja. Man man denkt da immer, das sind so alte, weise Männer mit langen Rausch... Also langen Bart hast Du schon, ja, also das das Problem vielleicht mit, ist und ich ganz so weiß, wie man sich das dann vielleicht klischeemäßig vorstellt. Aber es ist halt nicht so, ne? Es 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 son kleines Spotlight irgendwie drauf find ich eigentlich auch ganz cool.
Leo: Ja. Nee und... Also die Standard Bodies, da da lernt man, da trifft man Leute natürlich auch. Man kann zur Sprache Sachen hinzufügen, aber man muss nicht sein, aber ich kann einige, die einfach dort sind, aber nur zum Zuhören oder einfach Ideen zu verbreiten, dass man vielleicht 'n bisschen etwas machen könnte. Aber da sind sehr viele verschiedene Firmen. Man muss jetzt nicht irgendwie eine Riesenfirma sein. Da kennst Du auch 'n kleines Unternehmen mit 5 Leuten sind dabei. Also alles Mögliche.
Jan: Nice. Bevor wir gleich ans Eingemachte gehen, lass uns doch ganz kurz über die Deno Denodiskussion sprechen. Wo?
Leo: Also wie
Jan: wie sagst Du es denn?
Leo: Es kommt mir sehr zufällig raus. Also ob es Deno oder Dino ist, das spreche ich immer 'n bisschen anders aus, wie Lust und Laune ist. Aber ich hab grad eben hier die unsere Docks unsere Docks Website aufgerufen und weil da haben wir's aufgeschrieben, wie man es aussprechen soll und es ist 'n Dino.
Jan: Okay, so hab ich mir das auch irgendwie immer gedacht. Ich hab auch ganz lang eine Dino gesagt so, ja. Aber nachdem ja euer Logo auch son Dino ist, ja, muss man muss man, glaub 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?
Leo: Dino ist eine Alternative zu node j s, so aber 'n bisschen verbessert, sag ich mal. Also nicht vielleicht verbessern, aber einfach moderner, 'n paar modernere Ideen reinbringt in der im Run Times, aber auch einfach ein Toolkit. Also Du bekommst einfach Linder, Vormeter, Bondling, Desktop Apps, Dockgeneration, also sehr viele verschiedene Extrafeatures, die einfach nicht nur die selbst sind, sondern einfach Sachen darum und auch type Script out of the box. Aber auch 1 der wichtigen Sachen für uns ist, wie gesagt, Standards und deswegen folgen mir auch sehr viel die Browserstandards. Das heißt also, wenn Du 'n Websocket machen willst, benutzen nicht irgendwie unsere Websocket API. Nee, Du benutzt einfach die Browser Websocket API und die ist genau genau implementiert wie im in den Browsern. Also kannst einfach deinen Knowledge von Browser Browseruser einfach wieder weiter benutzen in in Dino.
Jan: Ich muss sagen, das war auch das, was mich damals da son bisschen hingezogen hat. Zum einen als jemand, der zu dem damaligen Zeitpunkt zumindest nicht hauptsächlich mit Hypestrip gearbeitet hat, ja. Zu sagen, okay, es gibt hier eine, die dir im Prinzip diese ganze Transpilation und Linder und was Du halt irgendwie so alles brauchst, aus so, so wie man halt früher type Skript erst mal zu zu JavaScript komplett hat und dann das irgendwie ausgeführt hat so, das alles nicht mehr machen zu müssen, ja und sich damit auch überhaupt gar nicht auseinandersetzen zu müssen. 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 wenn man halt eine API lernen muss, ne. Also natürlich muss man immer noch lernen, wie irgendwie 'n Websocket funktioniert, aber Du lernst halt den Standard so. Und Du lernst das so, wie Du's 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. Das heißt, dass das Wissen, was Du aufbaust, bleibt halt son bisschen portabler gefühlt, so. Ja, genau. Wie gut das in der Praxis dann immer klappt, kann man noch mal diskutieren, aber zumindest der Ansatz ist ja irgendwie lobenswert und das es fühlt sich dann einfach son bisschen besser an, wenn man in der Arbeit reinsteckt. War so mein mein Ersteindruck.
Leo: Sehr von hier auf
Jan: der Welt.
Leo: Also wenn ich erst angefangen hatte und den noch gesehen habe, fand ich das war einfach, was mich auch da richtig reingebracht hat in den und dass ich das so haben will, dass ich aber meine mein Wissen weiter nutzen kann.
Jan: Wir haben wie gesagt in den News schon einmal über Dino Desktop gesprochen, so eure, ich sag mal, Alternative zu Electron vereinfacht, ja. Wenn man sich anguckt, was Dino noch irgendwie grade alles macht, alles kann, alles ist, ja, da gibt es zum einen Dino, die Runtime. Es gibt irgendwie JSR, was eure Package Registry ist. Es gibt fresh, das Web Framework. Es gibt Dino Deployer als Infrastrukturangebot, es gibt Dino Desktop als irgendwie Rapper für für Desktop Apps und es gibt dann auch so ganz an der Seite irgendwie Claw Patrol, über das wir auch mal irgendwann, glaub ich, in den News gesprochen haben so, ja. Und ich schau da ehrlicherweise son bisschen drauf und ich frag mich dann so, was ist eigentlich gerade so euer euer Fokus so, ja? Weil am Anfang war die Story, glaube ich, noch eine sehr einfache, wie Du gesagt hast, ne. Was haben wir irgendwie aus Node gelernt und wie kann man irgendwie eine 1 elegantere Runtime vielleicht auch bauen, ja? Und mittlerweile gibt es Web Frameworks und Infrastruktur und Desktop Rapper und die Registure so. Was ist so die überragende Mission da oben drüber?
Leo: Also Deno, ich würd ich 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's mit Javascript angefangen. Aber es hat sich einfach 'n bisschen verbreitet, weil also jetzt zum Beispiel auch mit AI haben wir dann halt ja, klar, weil wir das einfach intern brauchten für 'n paar Sachen und einfach sehr hilfreich davon haben wir entschieden, dass wir das einfach dann richtig als ein richtiges Projekt freigeben. 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 nix.
Jan: Okay, fair und und lobenswert vielleicht. Hab eben schon gesagt, so kurz gefasst ist Dino Desktop irgendwie eure Alternative zu Electron. Jetzt gibt es ja schon Alternativen zu Electron, 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 Electron, Tauri, Elektrobanden 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? Also, ne, man hätt ja auch sagen können, da gibt es schon sehr viel, da ist irgendwie vielleicht wenig Potenzial zur zur Ausdifferenzierung irgendwie da. Was war so ausschlaggebend für euch, zu sagen so, nee, da da braucht es auch noch unsere Lösung?
Leo: Gute Frage. Also es hat sich es ist 'n Projekt, was ich seit, oh Gott, sagen wir mal jetzt 4 Jahren ungefähr her, ja, das ich immer wollte. Also ich wollte eine Möglichkeit, Desktops, Apps zu machen und ich fand Electron, sagen wir mal, zum Kotzen, weil es einfach ja, wenn man's benutzt, das ist fand ich immer 'n bisschen kompliziert. Bisschen zu viele irgendwie Konzepte und alles, muss man 'n bisschen alles so viel Verschiedenes lernen. Und dann war einfach auch der Fall, dass mit Deno kann man Electron nicht benutzen, weil Electron Sami mal ziemlich ein Fork ist von now js. Also also es wandelt sein eigenes seine eigene Rundime. Da kann man dann nicht irgendwie einfach deno einfach ersetzen. Deswegen brauchen wir einfach eine andere Lösung.
Jan: Und vielleicht auch da, bevor wir übers über die Details sprechen, was ist so euer Elevator Pitch für den und Desktop? Was ist das Alleinstellungsmerkmal?
Leo: 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 den oder Desktop, wenn Du zum Beispiel, sagen wir mal, Du hast eine Webseite mit irgendwie Next Jares, kannst einfach nur den oder Desktop exhibieren im in der Command Line und das gibt ja einfach eine Desktop App. Muss keine Codeänderungen machen überhaupt. Also es ist, würd ich sagen, einfach, wie einfach es ist, zu nutzen.
Jan: Und als selbstverständlich dann quasi Dino zur Laufzeit, ja. Was nutzt ihr da im im Rendering?
Leo: 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, glaub ich, halt die System Web View. Das macht einfach, dass dann die bei relativ klein sein wird von der Desktop App, weil es einfach dann das benutzt, was aufm System ist. Aber dann gibt's auch, was Chrome Embedded Framework ist, also das heißt Chromium, ziemlich ähnlich wie wie Electron es macht. Und das macht halt natürlich, dass alles 'n bisschen größer sein wird von binary Size, aber dafür bekommst Du ganzen Chromium, sag ich mal, dabei. Also Du kannst alles die ganzen APIs, die vielleicht nur bei Chrome sind oder einfach, dass es Consistenant Rendering über die andere verschiedenen Operating Systems ist. Und ja, das ist halt, da musst Du sehen, was Du am besten brauchst und willst, ob dir Biney Size wirklich wichtig ist oder Consistency wichtig ist, aber wenn Du schon mal in eine Firma bist und ihr habt alle nur Macs und ihr braucht eine interne App, da würde wahrscheinlich einfach dann nur die View reichen, weil weißt Du, dass Du nicht irgendwie bei Linux dann bist und dann funktioniert die Hälfte nicht.
Jan: 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 zu sagen, okay, ich liefer hier mein Chromium mit und damit weiß ich ganz genau, wie das überall aussieht und auch wenn jetzt so Sachen wie, ich sag mal, ne, Fund Rendering, Curning son bisschen unterschiedlicher noch sind von Betriebssystem zu Betriebssystem, so die die groben Features sind zumindest irgendwie gleich, ja? Oder ist es tatsächlich eher dieses, boah, ich brauch hier APIs, die es halt grade nur in in Chromium gibt und mein, weiß nicht, macOS Webkit Safari Ding tut's halt hier irgendwie einfach nicht.
Leo: Also ich würde schon sagen, es ist hauptsächlich Consistenance hier und einfach weil Leute sehr damit halt... Chrome 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 'n paar APIs und Chrome fügt schon 'n bisschen mehr und schneller hinzu als die anderen Browsern. Aber die anderen Browser machen auch keine schlechte Arbeit. 'N paar haben vielleicht auch sogar APIs, die Promi noch nicht hat. Also das ist schon, würd ich sagen, ist the key, weil ja, bei den anderen Browsern auch, es könnte man könnte auch, sagen wir mal, Firefox Base Backend haben für den Oolesklub, könnte man theoretischer implementieren, aber bringt, sag ich mal, nicht allzu viel, weil einfach Leute Promiom wollen.
Jan: Okay. Jetzt hast Du eben schon gesagt, dass so Dino Desktop das ist, was Du schon seit 4 Jahren eigentlich haben willst. Wie sah denn dieser Schaffensprozess aus? Weil ich nehm mal jetzt nicht an, dass irgendwie 2 Wochen vor dem 2 Punkt 9 Release jemand eingefallen ist, oh, dieses Desktop Ding, das sollten wir vielleicht mal bauen. Lass uns noch kurz 'n paar Nächte die Ohren schlagen und dann schippen wir das noch schnell mit. Und dann wird ja vielleicht son bisschen mehr Konzeptionsarbeit und und und Planung und die ein oder andere Diskussion irgendwie noch eingeflossen sein. Nimm uns da doch mal mit so auf eine kleine Zeitreise, so wie wie hat sich Dino Desktop entwickelt?
Leo: Ja, also wie gesagt, es hat vor 4 Jahren erst eine Idee angefangen. Haben wir aber dann leider nie gemacht, weil einfach es 'n 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 'n paar Leuten von Tauri getroffen habe und wir dann 'n bisschen zusammen konzentriertisiert haben für eine Lösung für Linodesktop und Tauri, sagen wir mal, auszunutzen zu können damit. Aber das wurde dann einfach nichts. Einfach wie gesagt, wir hatten die Infrastruktur, dass wir das bauen können und dass wir das auch ja so machen wollen, wie wir es haben wollen, ging's halt leider nicht. Und dann ja, hatten wir das ja, 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 na ja, diesem Jahr. Da hatten wir dann endlich, hat mein Kollege, der hat ja eine gute Lösung gefunden, wie wir das am besten bauen können, dass wir einfach auch... Weil das größte Problem ist bei Desktop Apps ist, dass normalerweise brauchst Du, dass der Renderer das Hauptprozess ist. Es kann nicht sein, dass Dino das Hauptprozess ist, weil das macht alles Mögliche Problem. Da gehen meiste APIs zum Beispiel aufm Mac dann nicht. Da kannst Du irgendwie nicht mal eine Window, glaub ich, kreieren, wenn Du nicht das Hauptprozess ist, weil...
Jan: Ah, okay. Mhm.
Leo: Ja. Das macht's einfach. Deswegen ist es so nicht sone einfache Sache. Aber da haben wir halt Lösungen gefunden und da haben wir dann angefangen zu bauen. Und ja, das war schon 'n paar Monate. Dann während wir angefangen haben, hatten kamen dann auch Elektro Elektrobanner raus, also dass das angesagt wurde. Und es hat schon 'n paar Sachen ähnelt sich ab. Wir haben 'n paar Sachen dann am Ende auch etwas, sag ich mal, abgeschaut von Elektrobanden. Wir haben natürlich auch Sachen von Electron, von Tavori, haben wir mal 'n bisschen kopiert, weil einfach die haben nicht schlechte Konzepte am Ende des Tages. Die das sind ja gute Projekte, sonst wären die ja nicht so beliebt. Aber ja, da haben wir 'n bisschen und auch das 'n bisschen das Dino drauf gesprenkelt, einfach dass wir selber unseren eigenen Flair, den Dinoflare hinzufügen.
Jan: Okay, was ist denn der Dinoflare an Dino Desktop? Wo wo merke ich den denn in der Verwendung?
Leo: Ja, ich würde, wie gesagt, sagen einfach, wie einfach ist es zu nutzen. Also es ist einfach echter, es ist sehr einfach, APIs sind sehr übersichtlich, würde ich sagen. Also 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 ja versucht, so ähnlich wie möglich zu Browser APIs zu nachmachen. Also Events, die Du ausm Browser kennst, wie Mausemove und Klick und so was, ist alles, sagen wir mal, 1 zu 1 gemappt. Und das ist einfach, dass Leute, mit was die schon kennen, einfach das ausbauen können. Und ja, halt und sagen wir mal modernere Konzepte und Ideen, wie man 'n paar Sachen machen kann.
Jan: Wenn ich jetzt mit Dino Desktop meine 1. Eigene App bauen will, dann brauch ich ja wahrscheinlich nicht viel mehr als einen und das macht im Zweifelsfall auch erst mal nicht mehr, als irgendwie ein Windows zu öffnen und was dein ist irgendwie reinzumalen, so mein mein kleiner, ja. Und dann sag ich einfach, hey, Dino Desktop, hier ist mein t s Intro t s whatever, hier hier ist das File, ne. Da kannst Du alle anderen von da aus finden und zusammenschrauben. Und Dann fällt son binary raus und das kann ich aufmachen. Was tut denn aber Dino Desktop, dieses zu bauen? Also wenn ich hier tippe Dino Desktop Main t s und Enter drücke und dann 'n paar Sekunden warte, bis es gebaut ist, was macht Dino?
Leo: Also Dino Desktop funktioniert, das ist einfach... Wir haben auf dem Bucket irgendwo und das muss es halt das runterladen. Diese binaries sind also sagen wir mal da etwas unterschiedlich von der Haupt, die Du benutzt, wenn Du einfach benutzt. Also das ist, sag ich mal, hat zum, die Sub Commands nicht, hat einfach 'n paar Sachen dann weggenommen, aber dafür hat's auch Wenn Du
Jan: sagst, dann sind das die, ja?
Leo: Genau. Mhm, okay. Und ja, dafür hat aber diese spezielle, 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 also für uns Dino ist immer ein Headless Run Time. Also alles, was Du machst mit Dino, muss aufn Headless System funktionieren. Und das natürlich funktioniert nicht mit Desktop. Das ist ziemlich Konflikt. Deswegen Biney, die einfach nur die APIs hat. Und das lädt die runter und dann wandelt es deine App zusammen, also deine ganzen typetetfiles, deine Assets und so was. Das wird alles zusammengebandelt und dann am Ende dieser binary einfach zugeworfen, sag ich mal so. Das ist einfach, wir haben son Magic Header am Ende von 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 noch weitere danach sind, dann benutzt es diese alle Bytes nach diesen Magic Header und benutz das, die Not zu exekutieren.
Jan: Das heißt, der der Bildprozess sozusagen ist nichts anderes als mir als dieses spezielle zu nehmen. Und meine zusammengepackte Anwendung quasi hinten dran an dieses Binary zu schreiben, sodass es quasi eine komplette Datei sozusagen wird.
Leo: Genau. So funktioniert auch Dino Compile, also wir haben sehr viel Infrastruktur, damit einfach
Jan: wieder benutzt. Okay, und also wahrscheinlich den den Anwendungsgrafen da zusammenzubauen, das ist ja was, was ihr schon könnt, weil das brauchst Du ja 'n ganz normalen Siloprozess 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 'nem normalen, ich sag mal, Dino Serverprozess unterscheidet?
Leo: Ja, also komprimiert ist eine Option. Da gibt's eine Flag, Dar Slash Compress. Dann gibt's ja son Signing, das ist halt mit dir mit Desktop Apps. Du willst halt natürlich die deine App signiert haben, damit die aufn App Store gehen kann oder einfach nicht, dass dann irgendwie, wenn Du auf Mac bist, dir sagt, hey, diese App kenn ich nicht, die will ich nicht öffnen. Also ja, es sind noch 'n paar extra Sachen, die noch möglich sind für Useres, aber im Normalfall, also wenn Du nix Weiteres machst, einfach nur Dino Desktop. Nee, da macht's einfach nur das einfach.
Jan: Mhm. Und ganz blöd gefragt, muss meine Dino Desktop App einen GUI mitbringen? Weil ich könnte, also der Bildprozess, wie Du ihn grade beschrieben hast, den könnte ich ja auch analog zu Dino Compile quasi nutzen, jetzt nur Sales Tools zum Beispiel zu bauen. Oder ist das quasi schon so, dass da auf Biegen und Brechen irgendwo erwartet wird, okay, Du musst jetzt hier mal 'n Fenster zeichnen, sonst ist irgendwas schiefgelaufen. Ja,
Leo: das ist schon der Fall. Also muss eigentlich nicht genau sein Fenster. Du kannst auch zum Beispiel nur eine Tray Icon haben, also da in im Tray oder einfach eine 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 bisschen...
Jan: Mhm, mhm. Mhm. Okay, wie oder oder anders so, Du hast am Anfang gesagt, so, ihr ihr seid eine 1 Touling Company, so. Ja. Ja? Ihr 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 so. Als es dann da war, was war das, was Du mit Dino Desktop gebaut hast?
Leo: Ehrlich zu sagen, gar nix. Es war einfach, also ich will eine Möglichkeit haben, das
Jan: Die Leutesprinzip.
Leo: Genau. Nee und wir haben in der Community über die Jahren immer gesehen, es gab sehr viele Leute, die sehr enthusiastisch drauf waren, eine Möglichkeit für Desktop Apps zu haben. Die Leute haben versucht, extern einfach eine Möglichkeit zu haben, für Desktop Apps zu bauen. Da gab's irgendwie 3 große Projekte, die das versucht haben und gemacht haben. Ist halt natürlich aber nicht dasselbe, als wenn das richtig in der Runtime integriert ist. Und ich fand's einfach 'n interessantes Problem. Ich damals, vor 4 Jahren war ich schon 'n bisschen Electron Apps am Bauen, aber heutzutage dann doch nicht mehr. Und jetzt hab ich keine Zeit, irgend eine App zu bauen. Ich hab eher nur Zeit, das System die App zu bauen zu bauen.
Jan: Na gut, Arbeitsteilung, ne. Irgendjemand anderes musst Du halt die die App bauen. Wir nehmen diese Folge Mitte, Ende August auf, weil die Dinoversion 2 Punkt 9, das ist noch der aktuellste Release, das ist auch der Release, mit dem Dino Desktop quasi erstmalig erschienen ist. Das 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 Punkt 9 steht, Dino Desktop ist experimentell. Was ist denn der aktuelle Zustand von Dino Desktop? Was fehlt vielleicht noch komplett? Was könnte sich vielleicht noch mal ändern? Was ist noch son bisschen im Fluchs? Wo fühlt ihr euch schon gut mit? Wie sieht's aus?
Leo: Also wir bekommen relativ viel noch von Leuten, die einfach das System noch ausprobieren. Es kommen immer wieder 'n paar Bugs hier 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 paar Sachen rausfinde. Aber generell würd ich sagen, das System ist halt gebaut. Es funktioniert. Es ist vielleicht, was einfach fehlt, ist einfach halt 'n bisschen und 'n paar Sachen einfach. Ja, ich würde sagen, eigentlich hauptsächlich die Bugfixes. Das das ist schon das Größte. Es gibt halt 'n paar Kleinigkeiten hier und dort, die ich gerne hätte, aber das sind dann auch vielleicht 'n paar Sachen, die mir long term sind. Weil zum Beispiel habe ich ein Branch mit einem weiteren Backend Server, dass man Server nutzen kann dann. Aber Server ist halt sehr experimentell noch und ich red mit den Leuten von Server ab und zu und ja, die fühlen das alles. Was ist das
Jan: für alle da draußen?
Leo: Server ist das originelle Projekt, das überhaupt Rust für erfunden wurde. Das ist 'n eine alternative Browser Engine, die von Mozilla angefangen wurde. Also und Firefox eigentlich benutzt 'n paar Sachen von Server selbst und Server benutzen 'n paar Sachen von Firefox. Die teilen sich schon 'n paar Sachen hier und dort, aber es ist halt 'n, sag ich mal, experimentelles, komplett in Rost gebautes Browser. Und das geh ich schon seit vielen Jahren weiter, aber ja, es ist halt Browser bauen ist nicht einfach, sag ich mal so. Da gibt's sehr viele Sachen. Das
Jan: hat ja schon 'n Grund, warum die letzten 20 Jahre gefühlt kein neuer dazugekommen ist. Genau. Okay, also im Prinzip son bisschen, ich sag mal, was was Modularität angeht. Vielleicht ne, irgendwie, Run Time tauschen können, Renderer ist ja schon tauschbar, haben wir eben schon gesagt. Gut. Jetzt gibt es ja, wenn man sich die anderen anguckt, Electron, Elektrobannen, Tauri, wir haben sie vorhin schon mal genannt, Zum Beispiel auch ganz andere Use Cases, die dann noch abgedeckt werden. Ich glaub, Tauri hat ja in seiner 2 Nuller Version dann auch angefangen, so Mobile Apps zu unterstützen zum Beispiel, ja. Ist das was, was ihr euch auch anguckt oder heißt das nicht umsonst Dino Desktop? Ja, also vielleicht, Denodesktop war vielleicht nicht der beste Name,
Leo: weil wir haben schon 'n bisschen herumgeschaut von wegen Mobile Apps auch. Wir haben Deno
Jan: Mobile ist vielleicht noch frei, brandingmäßig.
Leo: Ja, vielleicht noch machbar, ja. Vielleicht
Jan: einfach nur
Leo: 'n Alias für den Desktop Desktop Command am Ende. Aber ja, nee, also wir haben jetzt iOS Builds sind machbar. Ich weiß nicht, ob Desktop Apps mit iOS schon jetzt funktionieren oder ich ich zweifel es. Vielleicht, wenn diese Folge rauskommt, dann vielleicht schon dann. Aber Dino kann jetzt für iOS gebaut wählen und ich glaub, Android geht auch langsam vielleicht. Da bin ich mir leider nicht 100 Prozent sicher. Aber nee, also Mobile Apps ist schon etwas, was wir uns interessieren, dass das eine Möglichkeit ist. Mhm.
Jan: Cool. Wie, also wir haben ja in den in den News auch über über Dino Desktop gesprochen. Was war so das Feedback, was bei euch so initial dazu aufgeschlagen ist? War's mehr so ein, boah cool, ich hab da schon superlange drauf gewartet und endlich kann ich die Desktop Apps bauen, die ich die ganze Zeit nicht bauen konnte. Oder was mir so einfällt, ist so, wieso oder also was war was war so das das Feedback, was wir bekommen haben?
Leo: Feedback war überraschenderweise nicht viel, aber nicht in 'ner schlechten Art. Normalerweise, wenn wir nicht viel Feedback bekommen, heißt es, ach scheiße, Leute benutzen das nicht. Aber das war eigentlich nicht der Fall. Leute haben's benutzt. Ich hab's gesehen in der Community. Leute haben's sehr gemocht und wir haben relativ wenige Ishys bekommen. Was ich sehr überraschend fand. Aber ich sah Leute, die haben Sachen gebaut. Ich hab DMs bekommen, ich hab auf unseren Discord gesehen. Ich hab Leute auf Twitter gesehen, die Sachen bauen waren. Also anscheinend haben wir einfach nur relativ Glück gehabt, dass da nicht zu viele Bugs hatten, sag ich mal so. Vielleicht, also es gibt natürlich immer noch einige Bugs. Sehen wir mal, wir sind so bei 34 Open Issues grade bei den oder Desktop bei uns. Also das sind 'n paar Features auch noch dazwischen. Aber ich sag mal, für son System nur 34 Issuits bin ich ziemlich froh mit. Es kommt natürlich immer etwas Neues dazu, aber initialerweise sehr, würd ich sagen, sehr gut, wurde es sehr gut akzeptiert. Ich hatte am gleichen Tag oder einen Tag davor, dass wir releast haben, war ich halt bei 'ner Konferenz und hab ich 'n Druck gegeben und Leute waren sehr interessiert. Also es scheint, dass einfach, ja, Leute brauchen was.
Jan: Was waren so die interessantesten Use Cases, die Du so gesehen hast, was dann
Leo: die Leute da mitgemacht haben? Oh Gott, gute Frage. Was haben Leute damit gebaut?
Jan: Da bin
Leo: ich mir grad leider nicht sicher. Da hab ich jetzt fällt mir grad nix im Kopf ein. Aber definitiv einiges war, sagen wir mal, mehr Herumexperimentierung. Natürlich gibt's 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 son Side Projekt wurde. Aber ja, also dass jetzt eine vollständige App von jemand gebaut wurde und die in Nutzung ist, weiß ich nicht. Kann ich aber mir vorstellen, dass da vielleicht 'n paar haben gehen.
Jan: Also ich hab ja auf alle Fälle noch son sone Electron App, die werd ich vielleicht bei Gelegenheit mal portieren. Die hat nämlich damals, als ich sie, ja, ich mein, die benutzt, also ne, ist einmal gebaut. Ich benutz die jetzt nur für mich so durchgehend, von daher hab ich sie ganz lang auch nicht mehr angefasst. Damals war das Problem, dass die unter Linux superschlecht funktioniert hat, weil das Rendering da son bisschen komisch war. Das wird dann mein Test Case für für Dino Desktop, das entsprechend besser funktioniert. Ich brauch eigentlich nur 2 Features dafür. Ich brauch transparente Fenster. So. Ja. Könnt ihr so was?
Leo: Ja. Das ist macht das ist schon
Jan: 'n Feature. Und ich brauch. Also das ist im Prinzip der den Klick nicht capture in meinem Window. Okay. Wenn ihr das noch nicht habt, ist das jetzt hier meine Gelegenheiten, 'n Feature requests zu platzieren so. Aber vielleicht
Leo: Ich schreib mir geputzt an meiner Stelle so auf. Ich ich bezweifle es, dass wir es haben. Aber ich werd's mir mal anschauen.
Jan: Weil was ich nämlich machen muss mit meiner App, ne? Ich leg son transparentes Fenster über den kompletten Desktop sozusagen und kann natürlich dann nicht alle Klicks capturn. Ich muss im Vordergrund sein für das, was ich machen will, aber ich Du sollst ja trotzdem dein Zeug benutzen können und dementsprechend müssen die Klicks durchgehen. Und wie gesagt, Electron konnte das damals mit son bisschen rumgehecke. Wenn Dino Desktop das kann, dann fängt Claude morgen an, die App zu portieren. Perfekt.
Leo: Ja, also ich glaube, dass Du ich okay, ich kenn die APIs nicht, wie das, sagen wir mal, wirklich funktionieren würde systemweise, aber ich kann mir nicht vorstellen, dass das allzu kompliziert sein könnte doch mal so. Ich schau's mich mal an. Wie
Jan: extendable wollt ich grad sagen. Erweiterbar, wer ist das Ganze denn? Also wenn ich jetzt, ne, ich hab jetzt hier diesen Use Case und wir stellen uns vor, es würde jetzt so gar nicht unterstützt werden von Denodesktop. Wie einfach oder wie offen seid ihr denn da für son PR, wenn ihr jetzt sagt, okay, ich kümmer mich darum, eine API dafür zu bauen. Ich kümmer mich die Native Implementierung auf Renderer Seite und hier ist mein.
Leo: Kannst Du kurz noch mal wiederholen? Muss.
Jan: Also wenn wir wenn wir jetzt quasi dieses Feature fehlen würde, ja? Ja. Und ich sag, okay, ich ich gestalte die API dafür in denodestop. Ich kümmer mich 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 grade eher so selbst? Wie wie sieht das aus?
Leo: Also wir bekommen schon paar Pull Requests, jetzt nicht allzu viele, weil das halt im Moment des Tages ja schon, sag ich mal, 'n sehr komplexes System ist, aber bekommen wir und werden gemerged. Oder habt gestern ein paar gemerged. Also ja, ja, würde schon akzeptiert. Also wenn es Nur.
Jan: Eine gute ist natürlich. Gibt nur gute Podcastpresse. Für das Dino Team, was ja doch irgendwie großteils aus aus 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 mein, jetzt mein Beispiel ist ja nur 1 von vielen, ja, aber Du hast ja vorhin zum Beispiel auch gesagt, man kann auch Manubar oder Dock Apps irgendwie dazu bauen. Dann musst Du dich ja auch beschäftigen, ne. Das ist ja was, was jedes Betriebssystem quasi komplett unterschiedlich handelt. So im in Windows gibt's diese Tray Icons, im macOS ist es irgendwie son Dock 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, so. Und auf einmal musst Du dich so Native App Development kümmern, so. Wie wie näher, also wie kommt man da rein?
Leo: 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, die auf, sagen wir mal, Linux, Windows, Mac funktionieren. Und wir mussten schon Sachen bauen, die einfach sehr unterschiedlich am Ende des Tages funktionieren unter der Hood, aber gleich sich ja gleich sein müssen für Users, auch wenn die auf verschiedenen Systemen komplett anders sind. Also das ist jetzt nicht irgendwie etwas, das wir mit nicht schon 'n bisschen uns mal ja, durchgesetzt haben mussten, dass einfach Sachen nicht funktionieren gleich gleich auf verschiedenen Systemen. Ist halt natürlich bei Desktop Apps und das ganze Environment schon 'n bisschen, sag ich mal, aggressiver, 'n 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 'n bisschen kennen. Und ja.
Jan: 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 in dieser Vereinheitlichung, ne? Weil das ist, man kennt es ja, man will so eine einheitliche API irgendwie schaffen, dann ist okay, ich hab hier, weiß ich nicht, für Linux mappt es irgendwie ganz gut. Windows passt da auch irgendwie so rein und bei MacO ist das irgendwie wieder alles anders. Jetzt müssen wir diese ganze API irgendwie so weit auseinanderbiegen, dass er diese 3 irgendwie so beherbergen kann so. Gab's da 1, wo Du sagst, okay, das war schon immer mehr herausfordernd oder war das so in jedem Use Case irgendwie wieder 'n anderer, der da am schlimmsten war? Ja,
Leo: 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.
Jan: Das ist
Leo: Chaos, pures Chaos. Also das war, glaub ich, irgendwie 2 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 US, er ist wahrscheinlich Linux, weil es einfach kein
Jan: Und weil es so fragmentiert ist?
Leo: Ja, weil es so fragmentiert ist und einige APIs nicht gibt, vielleicht 'n paar Environments und auch einfach generell paar Sachen schon anders funktionieren. Also 'n paar Features, die die nur Desktop Hub funktionieren auf Linux nicht. Jetzt sag ich viele, aber ich glaube, Spray Icons, 'n paar Sachen sind limitiert, wenn mich richtig erinnere, weil das einfach alles ganz anders funktioniert und dann geht doch nicht. Also gibt's 'n paar Sachen. Es gibt
Jan: ja gar nicht so dieses eine Linux, ne. Ich mein, es gibt da verschiedene Distributionen, es gibt verschiedene Desktops so. Wie habt ihr denn irgendwie das Target dafür überhaupt festgelegt, zu sagen, okay, da das ist die Art von Linux, die Kombination von Distro und Desktop, die wir irgendwie supporten wollen?
Leo: Gute Frage. Also es ist einfach, wir benutzen Oder oder ist
Jan: das so der eine Engineer, der halt irgendwie, weiß ich nicht, für Dora am Laufen hat und bei dem muss dann irgendwie alles probiert werden und wenn's da läuft, dann ist schon okay.
Leo: Ja, sag ich mal, es geht schon so was 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 glaub, unser CI ist Ubuntu, wenn ich mich retier in eurer GitHub, einfach in GitHub runon. Das, ich glaub, die sone Ubuntu und dann... Ich habe Arch mit KDE. Also ich teste es da drauf. Und ja, wenn das funktioniert und funktioniert's. 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 'n bisschen eine Aufgabe. Aber generellerweise sind APIs schon, sag ich mal, 'n bisschen standardisiert. Also es ist gibt ja, habt ihr hier Excel und Wailland. Und wir haben uns, glaub ich, auf Excel am Anfang basiert. Und ich glaube, jetzt funktioniert Waillant auch. Also ja, wenn die 2 funktionieren und dann funktionieren eigentlich, sag ich mal, sei so 90 Prozent, wenn noch nicht mehr von Indexuser. Das ist ja gut genug.
Jan: Du hast eben den den CI Prozess angesprochen. Lass uns vielleicht da einmal kurz drüber sprechen. Wie kann ich mir oder muss ich mir das vorstellen, wenn Du son Testing Setup aufsetzen willst für das das Framework und die die Runtime selbst, ja? Und Du dich quasi auch, eigentlich kannst dich ja auf nichts verlassen und nichts trauen, so. Du musst ja alles irgendwie validieren, so okay, dieses Fenster aufwendig ich das irgendwie corde, ja, erscheint da ein, also weiß ich nicht, erscheint ein Trail Icon und ist da das richtige Bild drin so ungefähr, ja? Da wüsst 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 son Screenshot und guckt, ob das richtige Icon dadrin auftaucht. Wie wie ist euer Set-up?
Leo: Also das ist schon 'n interessantes Problem, das man zum Lösen, weil ich hatte dann mit jemand von Tower gesprochen und die ist, 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, weil das einfach
Jan: Das ist
Leo: so so. Weil es so kompliziert ist, überhaupt Ja. Etwas richtig End zu End zu testen. Weil das Einzige, was Du machen kannst wirklich, ist a Screenshots und b ja APIs Anfragen aufm System und checken, hey, ist diese da geht
Jan: ja auch nur sehr beschränkt irgendwie was, ne? Also natürlich kannst Du son 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 so 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 'n Feature vom Betriebssystem, ja, dass Du in laufenden Prozess nicht unbedingt reingucken kannst, so.
Leo: Genau. Also wir haben 'n paar verschiedene Lösungen, Sachen zu testen. 1 ist, wir haben einfach ein, sagen wir mal 'n Backend, was nicht wirklich da ist für, dass einfach son Testing Backend, sag ich mal. Das ist halt funktioniert komplett anders. Das ist einfach nur irgendwie 'n Hahn ist und sieht, dass alles wirklich so gecrollt ist, wie es gecrollt werden soll. Ist halt immer noch nicht komplett richtig, weil dann kannst Du nicht mal immer noch nicht komplett wissen, ob alles funktioniert. Also vor 'n paar Tagen, glaube ich, hab ich jetzt irgendwie eine Geschichte gesehen, hey, ich bekomm überhaupt keine Events, wenn Resison auf diesen System. Und dachte, hä, warum das denn ne? 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 Electron, wie die das machen, weil das kann ich mir nicht vorstellen, dass im Projekt so groß viel Electron nicht irgendwie eine Infrastruktur dafür hat 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's 'n Problem.
Jan: Ja, das ist 'n super Punkt. Also wir haben ja auch schon eine Folge über Tauri gemacht und da hab ich gar nicht nachgefragt, wie die das handeln, aber Du hast vollkommen recht, ne. Hast da da gibt es halt irgendwie nichts, so. Ja. Crazy. Okay, lass uns vielleicht, bevor wir über die Zeit rennen, noch son bisschen den Vergleich anstellen, ohne jetzt irgendwie nur so. 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 guck, ne, wenn ich mir sone sone App zusammenschrauben will, wo seht ihr euch da grade?
Leo: Also dafür haben wir sogar eine Seite in unseren Docks, in unseren sogenannten Dino Desktop Docs. Da gibt's 'n Comparison Seite und da gibt's eine schöne Tabelle, die man sich anschauen kann. Und Ist
Jan: ja grade offen, verlinken
Leo: wir auch direkt. Perfekt. Und ja, also es ist nicht, dass irgendwie DINo Desktop jetzt das perfekte System ist. Es gibt nie 'n 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. 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. Hast keine ganze JavaScript Run Time dabei, also da ist Story natürlich viel kleiner. Aber dafür haben wir halt die ganzen Dino Features wie so Note Compatability, aber das wollen ja am Ende des Tages ja alle. Ja, Cross Compilation ist 1 1 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 Elektronen, die haben halt 'n System dafür, aber das ist auch nicht perfekt. Also DINo kann ja schon seit, also schon DINo Compilekon Konto damals, weil wir's rausgebracht haben, auf andere Targets zu kompilieren, weil man des Tages wie vorhin gesagt, wir müssen einfach nur eine runterladen und dann einfach Sachen am Ende anhängen.
Jan: Weil ihr quasi sozusagen auf dem auf dem Bildsystem gar nicht kompiliert, sondern ja nur concated und dann ist quasi das Mobile ja schon gebaut. Mhm.
Leo: Genau, deswegen können wir Cross compilen überall, also kannst deine DIN- oder Desktop App von Mac aufn Windows bauen. Es gibt 'n paar Limitations, sag ich mal. Wir haben auch Installers, also kannst msi File oder App Image für Linux oder Dot DMG. Und da die also ich glaube, MSI geht nur auf Windows, also das geht leider nicht cross Compolt Wearbor. DMG definitiv nicht, weil das irgendwie 'n speziell 'n Tool braucht, was nur auf Mac leider ist. Also da sind 'n paar Limitations, aber generellerweise ja, eine App selbst kann schon cross Compleiert werden.
Jan: Und Du hast grade schon gesagt, ne, in in manchen diesen Zahlen liegen da unterschiedliche von diesen Playern irgendwie so vorne und am Ende ist das ja, glaube ich, auch immer sone Prioritätenabwägung, ja? Also Tauri legt das halt hart darauf an, irgendwie ultralein zu sein und liefert halt da dafür halt irgendwie keinen eigenen Render mehr mit so, ja. Was sind denn so eure ein, 2 Prinzipien, Prioritäten, die so die Entwicklung von Dino Desktop beeinflusst haben und auch zukünftig beeinflussen werden. So, was ist euch denn am wichtigsten bei dem Produkt, ja? Weil offensichtlich ist es ja nicht, dass ihr die das kleinste sein wollt oder den den schnellsten Callstart oder keine Ahnung, was da irgendwie so alles gibt's, aber woran orientiert ihr euch? Was ist so euer euren Polarstern, Nordstern, was auch immer, Stern?
Leo: 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 'n bisschen blöd anhört. Aber wir wollen einfach 'n Tool bauen, was funktioniert und unsere, sag ich mal, Ideen und Konzept einfach die das Dino leer hat, sag ich mal so. Aber das ist
Jan: ja also das ist ja ein ja. Natürlich ist es jetzt nicht so in einen touchie Satz irgendwie zu bringen, aber zu sagen so, 'n Dino Desktop soll sich halt am, ne, wie vorhin schon mal so, soll sich halt nach Dino anführen. Genau. Dann ist es vielleicht einfach das.
Leo: Ja. Ja, dann, ja, kann man so sagen. Genau.
Jan: Okay. Ja, ich glaub, ich bin hier bin hier mit meinen Fragen gut durchgekommen. Meine Lieblingsfrage am Schluss ist immer, welche Frage hab ich dir nicht gestellt? So über welches Thema wolltest Du unbedingt reden, hast dich vorbereitet und hast gesagt, oh Mensch, der Jan hat mich jetzt gar nicht zu, weiß ich nicht, befragt. Da wollt ich unbedingt so gerne noch drüber reden. Oder er hat mich gar nicht zu dem Dev- und Debug Tooling oder keine Ahnung. Also deine Chance, welche welches Thema haben wir so gar nicht gestrichen und wo fehlt uns da was?
Leo: Ja, also eigentlich Dev Set ups, sag ich mal, wäre wahrscheinlich das Größte, weil wir haben komplett ganzes Hotmody Reloading System. Du kannst deine App einfach komplett, musst muss nicht die ganze Zeit neu bauen. Kannst einfach, glaub ich, ist es oder, ich kann mich grad nicht erinnern. Und ja, Du kannst einfach deine App bauen, ob Du jetzt irgendwie 'n Framework benutzt, dann benutzt es den Framework, also es erkennt Frameworks und es kann dann sehen, was es machen muss mit dem Framework. Und kannst einfach dann Dino Desktop holen und und bekommst einfach alles und auch Nicht Moduls. Einfach auch alle Assets und so was. Also alles ist schon, sag ich mal, sehr komplett integriert, dass einfach Du nix machen musst. Du kannst einfach nur bauen. Das ist halt die Idee am Ende des Tages für die Desktop. Musst nicht zu viel überlegen, über wie das System funktioniert. Wir machen alles für dich. Mhm.
Jan: Und wahrscheinlich sind ja auch so Dev Tools irgendwie schon mit drin. Also ich nehm mal an, dass mindestens, wenn man den den Chrome Render nutzt, dann wird man irgendwie auf die Chrome Dev Tools kommen. Aber wahrscheinlich gibt es ja auch 'n Analog zu, wenn ich das native Web Rendering nehm, da gibt's ja auch immer irgend eine Art von von Dev Framework dazu, oder?
Leo: Ja, also genau. Du kannst die Dev Tools vom System, also vom vom Render benutzen. Also sagen wir mal jetzt den Chrome Inspektor, wenn Du mit Chrome willst oder Firefox Dev Tools oder Apple, was auch immer. Aber am besten funktioniert würd ich sagen, mit dem Chrome Renderer, weil am Ende des Tages Dino ist halt auf basiert. Das heißt, wir benutzen den gleichen Dev Tools Set-up als Chrome. Und da können wir schon 'n paar nice, nice Sachen machen. Zum Beispiel kannst Du einfach nur mit ein Dev Tools, Windows von Chrome, kannst Du beides den Renderer inspirieren und gleichzeitig aber auch den, sag ich mal, den Servercodel. Ist ja kein Server, wenn Du das Tages, aber kannst da, sagen wir mal, den den Dino Code investieren. Alles in 1 Windows und das ist alles komplett integriert, dass Du
Jan: Wie würde ich das machen, wenn ich jetzt nicht die Chrome Renderer nehme, sondern irgendwas anderes? Wie komm ich dann an die an den Konsolen Output von meinem Hauptprozess ran?
Leo: Also da musst Du Dino, Desktop oder Dino generell hat immer eine Dashboard und das ist, dann würdest Du halt 2 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.
Jan: Und wo kommt dieser Chrome Inspektor her? Weil der ist ja nicht in der drin, oder? Als
Leo: Du musst also Chrome Inspektor zu nutzen, musst Du schon Chrome installiert haben.
Jan: Okay, und das macht dann quasi einfach nur sone Remote Session, also eine 1 Connection in den in den Prozess Ja,
Leo: weil was am Ende des Tages Inspektors noch, also jedenfalls im Falle von Chrome und V8 und so was ist, ist einfach nur 'n Websocket Server, das einfach 'n bestimmten Protokoll hat und 'n paar weitere Sachen noch. Und das erkennt dann halt Chrome.
Jan: Okay, okay. Da das ist ja gut, dass wir noch noch mal drüber gesprochen haben. Tut Dino irgendwas in sei oder Dino Desktop irgendwas in seinem Compile Schritt, diese ganzen Debug Tools und Flex irgendwie auszubauen oder oder zu deaktivieren oder wie auch immer oder könnte ich, wenn ich jetzt, wenn Du gibst mir jetzt eine Dino Desktop 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 fertigkomplilierten Produkt nicht mehr?
Leo: Das ist immer noch drin, weil einfach... Weil wir können's nicht ausm Renderer rausnehmen natürlich, weil der Render ist der Renderer. Da wir werden jetzt nicht irgendwie aus Chromium versuchen, irgendwie Sachen zu löschen. Das wäre alles zu kompliziert. Und Dan Spector in Deno selbst, der ist auch immer noch dabei, weil das einfach 'n Teil, sagen wir mal, von V8 ist. Und da gehen wir auch jetzt nicht rein, also am Ende des Tages. Es ist immer noch Aber ihr könntet
Jan: dir da eine Runtime schippen, die zumindest die Flex einfach nicht mehr anbietet.
Leo: Genau. Das wäre eine Möglichkeit, ja. Aber wenn Du Dino Desktop eine Beine rausbekommst, gehen keine Flags mehr. Also deswegen deswegen kann's 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 Entwicklerapp sind. Also vielleicht wär Da geborene ich
Jan: schon drauf hinaus so, ja.
Leo: Na ja, vielleicht gäbe es eine Möglichkeit, aber da musst Du dann in die reingehen und Sachen ändern. Also da da bin ich mir jetzt nicht hundertprozentig, aber ich glaube, da da kann man nicht viel machen.
Jan: Und selbst wenn also auch 'n geändertes, dann ist es im Zweifelsfall nicht mehr signiert, dann war da auch alles
Leo: nicht nicht so ganz trivial.
Jan: Und also am Ende gilt ja aber wahrscheinlich auch für eine Dino Desktop App, genauso wie für alle Electron- und so was Apps ja auch, was man da ship, ist ja eigentlich ein 1 Web Frontend, so, ja? Ja und im Zweifelsfall muss man ja immer damit rechnen, dass egal, was da im Quelltext oder in deinem Debug Output oder im Log Statement oder irgendwo drin ist, ist halt kein Secret. So. Mit genug Wollen und Energie kommt man da ran, ja, es ist nicht irgendwie da rein kompiliert, sondern es ist halt am Ende immer noch in Anführungszeichen nur type Script. Bisschen und komprimiert oder keine Ahnung was, aber am Ende ist es halt immer noch lesbar, so. Genau. Oder so. Und selbst den kann man zurück komplett merken. Genau. Alright. Cool, dann haben wir, glaub ich, alles und wir können zu unserer letzten Kategorie übergehen. Wir können nämlich sprechen über die. Du bist Gast, Du bist Du darfst anfangen. Leo, was hast Du für uns heute im Gepäck?
Leo: Oh wow, ich bin... Ah, meine Güte. Also bei mir schon noch immer noch beim Programmieren würde ich sagen eigentlich Sibi Search, also z b Search. Mhm. Da kommst Du wahrscheinlich 'n paar andere Sachen, wenn Du einfach nur googelst. Also z b Search Punkt dev ist das. Und das ist einfach eine Open Source 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 find es im Moment sehr interessant. Und bin am Denken vielleicht 'n paar von unseren Sachen da drüber rauf zu wechseln. Vielleicht sogar auch GSR komplett, dass das wer benutzen werden soll.
Jan: Aber ja,
Leo: sieht einfach alles was aus.
Jan: Aktuell für die Suche? Wie bitte? Was benutzt er aktuell für die Suche in GSR?
Leo: R? Benutzen im Moment Algolia.
Jan: Ah ja, das nutzen wir auch bei der Programmier bei. Also es... Also ehrlicherweise muss man sagen, so als Lösung für, Du musst überhaupt nicht viel darüber nachdenken und das funktioniert einfach, sind die schon sehr gut, so.
Leo: Ja. Aber das Problem ist einfach, wir wollen 'n paar spezielle Sachen mit JSR machen, von wegen Search und das geht leider nicht in den Limits von Algoliya, was die uns umsonst gegeben haben als Open Source Projekt. Wir bräuchten nämlich irgendwie mindestens, glaub ich, zwanzigfach der Nutzung, mindestens will nicht so.
Jan: Oh, Oli, Oli, Oli, Oli, Oli, Oli, Oli, Oli, Oli, Oli, Oli, Oli, Oli, Oli, Oli, Oli, Oli, Oli, Oli, Oli, Oli,
Leo: Oli, Oli, Oli, ja. Für was wir machen wollen, also da wollten wir, dass die wir 'n Kontrakt signieren und schön was bezahlen, was für GSR nicht eine Option ist, weil es am Ende des Tages einfach 'n Open Source Projekt ist.
Jan: Okay, dann wenn wenn Du schon son Coding Pick hast, dann nehm ich auch 'n Coding Pick. Ich hatte ja hier zur Auswahl, was der andere war, werden wir nie erfahren. Und ich bring als Pick mit, ich hoffe, ich hatt das noch nie, Screps. Ich weiß nicht, ob Du Screps kennst, das ist ein Strategiespiel. Und ich hatte das, glaub
Leo: ich, vor, oh Gott, das ist
Jan: schon sehr, sehr lange her, mal auf Kickstarter gebackt und mittlerweile gibt es auch auf Steam oder so zu kaufen. Und was der Clou an der Sache ist, für jede deine Einheiten oder jeden deiner Einheiten Typen musst Du in JavaScript, ja, der Kreis schließt sich, das Verhalten quasi selbst programmieren. So. Okay. Und das heißt, es spielt sich auch son bisschen MMRPG mäßig im Sinne von, ne, 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. Du hast auch gar keine Möglichkeit, wenn Du drin bist, irgendwas zu machen und so, weiß nicht, Age of Empires oder Command und Conquer mäßig zu sagen so, ich markiere diese Einheiten und ich schicke sie dahin und bah, nein. So das Einzige, was Du machen kannst, sagen so, okay, ich nehm mir diese Einheit und ich tausche quasi ihr ihr Skript aus, so. Und dann fängt's halt an, sich anders zu verhalten an. Das ist alles, was Du machst, so. Und das ist im Prinzip eine Echtzeitstrategie für Developer und das fand ich damals schon ganz cool. Ich find's immer noch ganz cool. Ich leider nicht so viele Leute, mit denen ich das spielen kann, weil das schon auch nicht, es hat sone gewisse Hürde, ja? Also Du Du fängst halt an und keine Einheit macht gar nix. Und dann fängst Du halt da an und sagst, okay, jetzt programmier ich mal hier son bisschen los. Mittlerweile gibt's, glaube ich, auch so Cross Compelation zu. Du kannst es auch in, weiß ich nicht, Python Rust PHP irgendwie hochladen und sie schieben das dann irgendwie zu... Also ich glaub, das Spiel macht immer noch, also die Engine macht immer noch nur Javascript Evaluation, also das wird irgendwie dann transplantiert oder so was. Aber ja, megacool. Und wenn ihr da Bock habt, da Bock habt, das zu spielen, dann meldet ihr euch bei mir und dann spiel ich das nämlich endlich auch mal wieder, wenn's dann noch 'n paar andere Leute finden.
Leo: Ja, ich hab das vor einigen Jahren schon mal gehört, da ich hab nie wirklich zu tief mal reingeschaut. Vielleicht wär das mal Zeit, dass ich mal 'n bisschen tiefer reingehe.
Jan: Ja, es hat halt leider, wie gesagt, ne, also Du musst halt dann son bisschen natürlich auch die API lernen im Sinne von, ne, wie kannst Du, was was ist halt so die API? Wie fragst Du ab, wo sone Einheit ist, was Sie rum ist? Was sind so die Commands, Du dir geben kannst? Das ist nicht alles ganz trivial, aber es macht halt Spaß, wenn's wenn's dann mal läuft. Und man hat halt immer so diesen diesen, weiß nicht, diesen angenehmen Facts, Du guckst da drauf und denkst so, ja, das hab ich gemacht, so.
Leo: Ja, genau.
Jan: 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 Screps oder also dass die MMORPG Variante davon heißt Screps World. Es gibt auch Screps Arena, wo man einfach nur so skirmisch gegeneinander spielt, aber Screps 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. Eine allerletzte Frage vielleicht noch, weil die wird mir ab und zu irgendwie immer gestellt, so aus Spaß bei uns in den News, ne. Immer wenn ich anfange über Dino zu reden, kommt dann Dave frei und sagt so und Jan, was ist dein Lieblingsdino? So, also Leo, letzte Frage für heute, was ist dein Lieblingsdino?
Leo: Wie? Mal 1, ach so, okay.
Jan: Ja. Ah, guter Frage. Die Ecke denken.
Leo: Ich muss also die Sache ist, Dino selbst, das Maskott, ist leider keine richtige Dinosaurierbasiert. Das ist so mehr konzeptuell. Aber ich glaube, was am nächsten, na, Stenosaurus ist schon mal nicht richtig. Da das fehlt ja dann die Stechen hin aufn Rücken dran. Also mhm, gute Frage. Was wäre... Weil also ich selbst hab jetzt nicht unbedingt 'n Lieblingsdeno, muss ich sagen oder Dino. Da würd ich einfach gehen mit, was Dino selbst ist, aber leider ist es Was?
Jan: Vollkommen fair. Dein Lieblingsdeno ist der Dino.
Leo: So. Genau.
Jan: Wunderbar. Dann, wie gesagt, danke dir. Schön, dass Du da warst. Bis bald hoffentlich. Ja, danke vielmals. 2 in meinem 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 at Programmier Punkt bar oder schreibt uns auf Social Media, hinterlasst einen Kommentar, wo auch immer ihr diese Folge grade hört. Wir lesen alles mit und wir freuen uns und bis zur nächsten Woche. Bis deine. Tschau, tschau.

Deno Desktop mit Leo Kettmeir

Shownotes

Picks of the Day

Screeps

ZBSearch

Speaker Info

Leo Kettmeir