Deep Dive 175 –

Jaspr mit Kilian Schulte

28.03.2025

// Podcast
// Deep Dive 175

Shownotes

Nachdem Kilian Schulte uns mit seinem Talk auf dem Flutter Day 2024 begeistert hat, holen wir ihn jetzt in unser Podcast-Studio, um euch dieses Framework vorzustellen – egal, ob ihr auf unserer Konferenz wart oder nicht.

Kilian ist Autor des Dart-Web-Frameworks „Jaspr“. Sein Ziel hinter dem Framework ist, Flutter-Entwickler:innen einen Einstieg in die Webentwicklung zu bieten, ohne dass sie dabei ein neues mentales Modell erlernen müssen. Und so hat er – inspiriert von Flutters Widget-System – ein Komponenten-System geschaffen, mit dem sich schnell Webseiten erstellen lassen.

Mit Jaspr lassen sich statische und interaktive Webseiten und Webseiten mit Backend-Funktionalität erstellen. Wir sprechen mit Kilian darüber, welche Gedanken und Herausforderungen bei einem so vielseitigen Projekt eine Rolle spielen.

Mit JasprPad hat Kilian außerdem eine Online-Sandbox geschaffen, in der alle Entwickler:innen das Framework selbst ausprobieren und die Syntax kennenlernen können.

Außerdem beleuchten wir, wie auch Neulinge schnell den Einstieg in Jaspr und Dart schaffen können. Was die Zukunft für Jaspr bereithält, erzählt Kilian am Ende der Folge und berichtet dabei, woher er Inspiration für neue Features bekommt – und welche er aus guten Gründen ablehnt.

Download

/transkript/programmierbar/deep-dive-175-jaspr-mit-kilian-schulte

Jan: Hallo und herzlich willkommen bei 1 neuen Deepdive Folge der programmier.bar. Und heute ist nicht nur der Jan hier im Studio, sondern auch mal wieder der Jojo. Jojo, schön, dass Du da bist.
Jojo: Hi, schön mal wieder hier zu sein.
Jan: Immer, wenn der Jojo bei uns im Studio ist, geht es Flatter, mehr oder weniger heute. Und heute besprechen wir ein Thema, das wir auch schon auf unserem Flatterday letztes Jahr hatten. Ich versprech auch hier noch mal, dass die Talks dazu zeitnah auch veröffentlicht werden, wer sie sich noch mal anschauen möchte. Aber damit ihr nicht so lange warten müsst, haben wir den coolen Content einfach noch mal in den Podcast geholt. Und zwar haben wir uns heute den Kilian eingeladen. Hallo Kilian.
Kilian: Hi.
Jan: Kilian, Du hattest auf unserem Flatter Day einen Talk erhalten. Worüber?
Kilian: Über Jasper, ein Web Framework, was ich entwickelt habe.
Jan: Wunderbar. Und das hat quasi nur bedingt was mit Flatter zu tun, weil der Titel von dem Talk war, glaub ich, so sieht aus wie Flatter, ist es aber nicht, ne?
Kilian: Ja, genau. Es ist 'n bisschen, ja, nicht kompliziert, aber ja, es ist also 'n 'n Framework in Dart, also der Programmierfahrer von Flatter und es ist auch designt, dass es sich sehr ähnlich anfühlt wie Flatter, aber es ist eben nicht Flatter, sondern 'n alleinstehendes Framework, Webseiten zu bauen.
Jan: Wunderbar. Und wenn Du nicht grade in Podcasts rumhängst, bist Du dann hauptberuflich Webentwickler und wolltest schon immer mal Flatter und Dart benutzt und hast deshalb 'n Web Framework geschrieben oder wie bist Du zu diesem Thema gekommen und was machst Du eigentlich sonst den ganzen Tag?
Kilian: Ich glaub, andersrum. Ich bin Flatterentwickler und wollt schon immer Webseiten schreiben. Also Okay. Eigentlich bin ich als Webentwickler gestartet, dann aber relativ schnell zu Flatter gekommen und war dann immer mit so einem Auge so, hm, Website, also so Web an sich hat mir immer Spaß gemacht, JavaScript nicht so sehr. Mhm. Und als ich dann irgendwann rausgefunden hab, dass man eben mit Dart auch Webseiten machen kann, ist aber noch nicht wirklich so Es gab halt noch kein Framework oder es gab noch nicht son High Level, ja, System, was das irgendwie 'n bisschen angenehmer macht. Es war alles sehr, sehr low level, sehr manuell, so stellt man sich vor, JavaScript vor 20 Jahren, wie man damit Webseiten gebaut hat, so war das eben in Dart. Genau und dann hab ich mal, ja, mehr so aus 'ner reinen Challenge, die ich mir selbst gesetzt hab, mal son bisschen experimentiert, Prototypen gebaut und dann ist da irgendwie son Framework draus geworden.
Jojo: Ja, superspannend. Weil das war irgendwie das Gleiche irgendwie, dass ich auch irgendwie damals diesen Schritt irgendwie hatte. Also ich hab hab früher sehr viele verschiedene Web Frameworks irgendwie genutzt, dann irgendwie natürlich so der Schwenk zu flatter. Und hab mir danach immer gesagt, ich möchte auch irgendwie sozusagen diesen Flatteransatz, den ich jetzt irgendwie kenne und irgendwie schätzen gelernt habe, wieder auf das Web anwenden. Und ich glaub, es war schon anders als das, was ich jetzt im Jazzback kenne, aber es hat eigentlich genau in die gleiche Richtung eigentlich irgendwie gemünzt, dass man versucht natürlich Ansätze, die man so aus anderen Web Frameworks kennt, also mit 'nem virtuellen Dom irgendwie zu übersetzen und letztendlich am Ende dann in Daten und Webseite schreiben zu können. Ja, ich bin nie so weit gekommen wie Du, deswegen war's superspannend, den Tag dazu zu sehen. Aber es ist natürlich auch so, dass man irgendwie so diesen diesen Need irgendwie spürt, irgendwie als Dart Entwickler nicht mehr irgendwie auf JavaScript Code zurückgehen zu müssen und die ganzen Vorteile und die Schönheit irgendwie von Dart irgendwie auch dann für das Schreiben von Webseiten nutzen zu können.
Jan: Jetzt hast Du ja schon gesagt, Kilian, das fühlt sich son bisschen an wie so vielleicht die Node Welt vor vor 20 Jahren. Aber wie rudimentär muss ich's mir denn vorstellen? Also musstest Du deinen also deinen eigenen Network Stack da irgendwie erst mal reinbauen, deinen eigenen Webserver? Musst Du dich Ports und und Sockets und so was kümmern oder was was bringt quasi Daten mit und was war der Teil, den Du dann noch oben draufsetzen musstest?
Kilian: Also an sich, vielleicht auch für für die, die nicht so familiär mit Dart und Web sind, Dart oder was das Ganze enablet, ist ja, dass DAT zu JavaScript kompiliert werden kann. Also als als ein ein möglicher Target der Compilierung kann eben ja JavaScript ausgespuckt werden. Ist 'n bisschen komisch die Vorstellung. Es ist tatsächlich eine eine eine Kompilierung nach der Definition des Wortes. Also das ganze Dart Programm wird halt analysiert, dann ganz viele weitere Steps, die ich gar nicht so wirklich kenne, aber am Ende wird eben JavaScript rausgespuckt und das kann man ganz normal im Browser dann ausführen. Und was Dart vom vom SDK her mitbringt, sind Bindings zu den ganzen Standard Browser APIs. Also alles, was irgendwie wirklich die Window API und Document und wirklich sich sich HTML Notes ziehen und die irgendwie verändern oder auf den Navigator zugreifen oder solche Sachen, dafür gibt's eben alles Bindings. Aber das war's. Also zumindest eben zurückgedacht vor zweieinhalb Jahren, als ich experimentiert hab. Du konntest halt damit Webseiten schreiben, indem Du sagst, document get Element by ID, holst dir dein Element, machst dann da irgendwie attachged Click oder so was, aber ist halt super im Prinzip Website eben sogar noch vor jQuery so ungefähr.
Jojo: Genau und
Kilian: da hatte ich halt überlegt, okay, an sich alle Tools sind da, ne. Ich hab ich hab die Sprache, ich hab die APIs. Wie wär das denn sone Art Flatter Slash react in dazu bauen und wie wird das überhaupt funktionieren?
Jan: Ich glaube, hier müssen wir vielleicht einmal noch ausholen, Missverständnisse da draußen vorzubeugen. Das ist ein ein Web Framework. Da gibt es ja verschiedene Ausprägungen davon. Mhm. Ja, wenn man's jetzt mal anguckt, was es ansonsten an Web Frameworks gibt und dann deswegen die Frage so an dich oder vielleicht es da einzuordnen. Es gibt Web Frameworks, die rendern dir im Prinzip eine statische Seite raus und die sind mehr son Autoring Tool, im Prinzip HTML zu produzieren, ja? Es gibt Web Frameworks, die kümmern sich darum, dass deine Webseite sich verhält wie eine wie eine Anwendung und son bisschen und Interaktivität reinbringt, ja? Da sind wir dann bei bei View und und und und wie sie so alle heißen, ja? Ja? Und es gibt Web Frameworks, die im Prinzip die ganze Webanwendung, also den Webserver und Backend und Frontend und im Prinzip das alles bereitstellen und quasi ein kontinuierlich laufender Prozess sind, aber eben auch HTTP Response ausspucken können, wo dann deine Webseite mit ausgeliefert wird. Was davon ist denn Jasper?
Kilian: Sehr gute Frage. Also ich glaub am am nächsten dran, wenn ich es jetzt vergleichen würde mit etwas aus der JavaScript Feld, dann wär das plus ein halbes Next JS.
Jojo: Mhm.
Kilian: Ein halbes, weil Also erst mal Jasper an sich und und im Kern macht es eben dieses, ich hab 'n Virtual DOM, ich hab meine deklarativen Komponenten mit 'ner, in Jasper heißt Bildmethode, den React heißt Rendermethode und dann da deklariere ich im Prinzip mein mein HTML oder meine Elemente, die ich geändert haben möchte und das Framework übersetzt das eben dann in die die DOM Updates, die ausgeführt werden müssen. Aber dann, was hin noch in Zukunft, was eben bei react dann auf auf Next und andere Frameworks fällt, bei Jasperbaby auch schon mit drin ist, ist bisschen Server Side Rendering und auch Static sytegeneration. Deswegen halbes Next, das ist natürlich lang noch nicht so ausgereift wie jetzt wirklich die existierenden JavaScript Frameworks oder Meta Frameworks, aber es geht son bisschen in die Richtung.
Jan: Das heißt aber, wenn ich eine eine Jasper Webseite deploye, dann deploye ich schon quasi eine langlaufende Anwendung, die auch der Server und das Backend dafür ist?
Kilian: Also es gibt 3 Modi bei Jasper. Der erste ist oder. Der generiert dir eben wirklich eine eine statische Website, die Du einfach nur mit HTML, CSS und JavaScript Dateien auf irgend 'n Webserver packen kannst. Der zweite ist dann Servermode, klassisches Serverside Rendering. Du hast wirklich 'n 'n long running Server irgendwo oder auch oder Serverlist auch, geht natürlich auch. In Dart sieht es so aus, dass halt Dart dann kompiliert zu irgend 'ner native binary und die kannst Du dann in 'n Docker Container so packen.
Jojo: Mhm.
Kilian: Das ist das und dann der dritte Mode ist ist Clientmode, was dann rein nur Client Side Rendering und also klassisch Single Page Applikationen oder so wäre.
Jan: Okay. Und weil ich keine Ahnung von Dat hab, sei mir die Frage verziehen, aber wenn ich das compilier in Binary, ich überhaupt keine keine Abhängigkeiten. Brauch ich dann eine irgendwas, was ich da mitnehmen muss oder ist das einfach stand alone und fertig?
Kilian: Das ist, genau, das ist sonst komplett stand alone. Also da brauchst Du keine keine weitere mehr, genau.
Jojo: Du hast ja auch die Möglichkeit zu sagen, weißt Du, Du kannst auch 'n anderes nehmen, also das ist sozusagen in der hast Du die immer mit drinne. Du könntest aber auch 'n als Snapshot oder 'n Körner Modul letztendlich dann ausspucken. Dann brauchst Du wieder die, dieses oder den auszuführen. Aber an sich ist es natürlich, sagen wir mal so, vom Start-up auch das sinnvollste zu sagen, okay, Du hast das einfach komplett überführt letztendlich in eine, die ist ja superschnell zu starten, deswegen kannst Du's auch sehr gut letztendlich, das irgendwie aufzubringen. Und brauchst dann keine mehr, die irgendwie in dem oder wo auch immer lebt. Okay, cool. Cool. Glaub, was auch noch spannend ist so so als als Unterschied, weißt Du, wenn, weil Du hattest ja gesagt irgendwie, es ist natürlich eine Möglichkeit, jetzt mit Dart letztendlich Webseiten zu schreiben und da vielleicht auch für einen Flatterentwickler so diesen Unterschied zu sehen, okay, weil natürlich auch Flatter ja verspricht irgendwie zu webkompiliert zu werden. Und was ist da wirklich so der Unterschied, weil ja, mit Flatter würde man natürlich irgendwie die Möglichkeit haben, die App, die ich vielleicht schon auf Native irgendwie implementierter, genauso ins Web zu bringen, aber ist natürlich in dem Fall eher wirklich sonen App Ansatz. Und ja, was würdest Du denn sagen, was ist sozusagen dann der Vorzug, den es jetzt bedingen würde, dass man dann Jasper irgendwie eher nutzt als jetzt eine Flatterweb App an der Stelle?
Kilian: Also wenn man jetzt aus der Flatterseite kommt, also man sagt, okay, ich bin jetzt 'n Flatterentwickler, ich hab vielleicht wenig oder gar keine Erfahrung mit Web,
Jojo: Mhm.
Kilian: Dann ist die Story so, dass Du natürlich erst mal in der Sprache, in dem Environment, in deinem Package Ecosystem und so weiter bleiben kannst, aber wirklich richtige Webseiten baust. Richtige Webseiten ist 'n bisschen Oder was richtige Webseiten hier heißt, ist halt, dass anders als bei Flatterweb, wo halt die Flatter App irgendwie als im Canvas gerendert wird, hier mit Jasper Du halt einfach wirklich normales HTML und CSS am Ende hast, was ausgespuckt wird und damit auch alle alle Vorteile, die das eben hat, also schnelles Laden, SEO und so weiter, Mhm. Halt hast, wie jede andere normale Website so.
Jojo: Also das ist auf jeden Fall 'n Vorteil, dass es halt eher wie eine Webseite dann aussieht, sodass eben auch Standardtools wie, Du sagtest grade SEO natürlich damit umgehen können. Das ist ja etwas, was letztendlich bei 'ner Flatter Web App irgendwie noch mal speziell eigentlich drübergelegt werden muss, dass ich son bisschen semantische Informationen eigentlich mit reinbringe, was wird auf dieser Seite jetzt dargestellt? Weil wie Du's gesagt hast, eigentlich zeichnet natürlich Flatter erst mal direkt in Canvas. Es gab früher son HTML Renderer, der aber auch inzwischen gar nicht mehr unterstützt wird. Und das ist natürlich auch, was ich da als Vorteil sehe, dass man, wenn man diese Notwendigkeit hat, eben halt ja diesen Teil eben noch nutzen kann, aber in seinem Eco System eben bleiben kann.
Kilian: Genau, ja. Du würdest mit oder Du solltest mit Flatterweb nie eine so was wie eine Landingpage oder so was bauen, einfach was was halt nah und schnell am Nutzer sein muss. Das ist einfach nicht nicht die richtige Wahl des Tools in in Ja. In dem Bereich.
Jojo: Du hast an der Stelle ja auch immer letztendlich das Flatter Framework oder letztendlich, sag mal, die Komponenten, die Du brauchst, also auf jeden Fall 'n gewisses Code, der unten drunter liegt, der natürlich auch so was wie eine Landingpage dann entsprechend verzögern wurde. Und es läuft natürlich auch rein auf dem Client. Also das ist natürlich auch 'n großer Vorteil, dass Du in Jasper letztendlich diese Möglichkeiten bietest, eben schon vorgerendere Teile von dem Server auszuliefern und die dann eventuell nur reaktiv dann auf dem Client zu machen.
Kilian: Ja, ja. Ich glaube auch. Also dieses dieses oder Server Side Rendering ist, glaub ich, aktuell mit das das stärkste Argument für Jasper, wenn man von Flatter kommt, eben dieses, okay, ich lade meine Website und der Content ist schon da, so ungefähr. Und und das eben zu haben, genau.
Jan: Das klingt für mich son bisschen nach, man sollte vielleicht einfach daran unterscheiden, hast Du eine Webseite, deren Stärke oder Fokus halt auf Content liegt?
Jojo: Mhm.
Jan: Boah, dann ist es vielleicht eher son son Jasper Ding, ja? Hast Du eine Webseite, die eigentlich eine Webanwendung ist und dann vielleicht noch eine relativ Komplexe dazu? Dann ist es vielleicht eher son Flatter Thema.
Kilian: Ja, voll. Das Flatter Team oder auch in der Dokumentation von Flatter ist eigentlich immer war schon immer recht gut aufgezeigt, für was Du Flatterweb nutzen solltest und für was eben auch nicht, was genau dieses ist. Also alles, was irgendwie viel Content hat, schnell laden soll, SEO braucht oder so, damit da solltest Du kein Flatterweb verwenden. Das ist einfach einfach nicht das Tool dafür und auch nicht gedacht dafür. Also von daher, da gibt's auch wenig, ja Ambitionen vom Flatterteam, das irgendwie zu ändern. Genau.
Jan: Aber es könnte ja trotzdem im im Flatter Ökosystem eine coole Rolle einnehmen. Ich mein, wie viele Projekte brauchen oder wie viele Packages brauchen eine Landingpage, brauchen eine gehostete Dokumentation, ja, was ja im Prinzip auch alles statisches HTML ist. Und wenn ich mir so was für mein Flatter Projekt bauen kann, ohne im Prinzip meinen Stack wechseln zu müssen, das ist natürlich schon auch cool.
Kilian: Das ist auch absolut die Zielgruppe, die ich aktuell angehe damit, ne? Also ich ich mach mir keine Illusion, dass jetzt irgendwie ein guter React Developer jetzt irgendwie umsteigen würde, sondern es ist eben genau gedacht, Du kommst schon aus dem Dart Eco System, Du willst vielleicht für deine App oder irgendwie noch nebenbei eine kleine Landingpage bauen oder so was. Das ist aktuell auf jeden Fall so der der Haupt Use Case dafür.
Jan: Ja, wer weiß, vielleicht gibt's auch Leute, die sich mit Web schon sehr gut auskennen, aber von Dart überhaupt keine Ahnung haben und dann Jasper als Einstieg in die Dart Welt sehen, so also
Kilian: Ja, könnte könnte auch passieren. Ich mein, es gibt ja auch viele Leute, die JavaScript nutzen, aber das nicht freiwillig machen.
Jan: Ja, kenn ich kenn ich son
Kilian: paar. Irgendwann glaube ich auf jeden Fall. Ich denk schon, dass das auch breitere Zielgruppen ansprechen kann irgendwann. Aktuell muss man sagen, ist es natürlich auch einfach featurtechnisch noch nicht so weit wie vergleichbare Frameworks aus der JavaScript Welt. Von daher, da da muss ich natürlich oder bin ich auch noch dran, das natürlich weiter zu dran zu arbeiten, das zu momentan. Aber irgendwann, wer weiß, an sich bin ich voll überzeugt davon, dass eben JavaScript Dart als als Sprache und als Ecosystem super, super viele Vorteile hat, gerade was irgendwie Produktivität angeht. Mhm. Und auch irgendwie Scalability im Sinne von, dass Du halt mit mit 'ner 'ner typesafe und nul Safe language viel besser Projekte machen kannst eigentlich und da auf der sicheren Seite bist.
Jan: Jetzt hast Du ja vorhin schon angesprochen, es gibt auch einen Modus in Jasper, im Prinzip ein Backend zu betreiben, Server Side Rendering schon zu machen. Ist das auch ein Modus, in dem ich für meine vielleicht Flatter App auch ein richtiges Backend und eine API anbieten könnte oder ist es eher dafür gedacht, einfach nur, einfach in Anführungszeichen, ne, einfach nur HTML und Content auszuliefern?
Kilian: Es spielt zumindest mit da rein. Also Jasper selbst, wenn Du jetzt, also wenn Du den Servermode nimmst, hat Jasper selbst nicht die die Ambitionen, jetzt 'n komplettes Backend Framework zu werden. Stattdessen bin ich die Route gegangen, dass ich Jasper kompatibel gemacht hab mit anderen Dart Backend Frameworks. Also ich mein, Dart im Backend ist ja auch noch mal gleich son son Thema, was auch grad irgendwie son bisschen am Kommen ist, aber natürlich auch noch sehr sehr nischig. Du kannst eben Backends in in dort schreiben. Es gibt auch so 2, 3, 4 schon verschiedene Frameworks oder Anbieter, die das machen und ich hab zum Beispiel mit ServerPort, was was ein ein größeres in dem Bereich ist, Backend Framework für Dart, eine Integration gemacht, dass Du eben Jasper und ServerPort zusammen integrieren kannst und dann halt eben auch dein Backend für deine Website oder deine Flatter App auch in Daten schreiben kannst.
Jojo: Mhm.
Kilian: Und dann Jasper übernimmt dann wirklich nur den den Serverset Rendering Part und nicht den Part für irgendwie API oder Database Kommunikation oder so was.
Jojo: Ja, Du hast das eben schon angesprochen. Ich mein, diese Erfahrung haben wir gemacht. Wir haben unsere gesamtes Backend Architektur auf DAT umgezogen und genau, es gibt halt irgendwie verschiedene Frameworks, die es abbilden. Es gibt natürlich auch immer Shell, letztlich, was die Grundlage aller anderen Frameworks eigentlich auch ist und eigentlich 'n sehr ähnliches API oder sone Mittelware Ansatz wie Express j s koh einbietet, also was man eigentlich aus der JavaScript Welt auch kennt, mit dem man sehr schnell letztendlich solche APIs eben sich bauen kann. Das große Problem, was wir eben festgestellt hast, eben eben, dass das Ökosystem da wirklich noch sehr jung ist und grade so was wie Anbindung zu Datenbanken, zu Postgress oder zu anderen Google Services teilweise auch. Also das ist son bisschen die Frage, es ist 'n Google Produkt, aber irgendwie so die Anbindung von Google Services ist doch noch sehr rudimentär, den man dort irgendwie auf der Startseite findet. Und das war die größte Herausforderung oder der größte Invest, den wir eigentlich da tätigen mussten, selber diese Anbindung zu schreiben. Ansonsten ist es wirklich 'n sehr coole Sprache oder auch sone Sache, dass natürlich man in der gleichen Sprache kann, sein Front und sein Backend zu entwickeln. Also wir sind sehr froh, dass wir diesen Schritt gegangen sind, aber es hat halt in initial halt 'n entsprechenden Invest gedauert. Und ich glaube, das wird aber auch noch mehr kommen. Aber das merkt man so auf allen Konferenzen, dass es eigentlich immer 'n Thema wird, was immer größer wird, dass größere Frameworks auch entstehen, die versuchen, das besser zu kapseln. Deswegen denk ich auch, dass es da interessant ist und gut ist, dass es da Jasper auch in diesem Umfeld gibt, das vielleicht mit zu unterstützen und zu sagen, das kann ein Aspekt letztendlich sein, den man für ja letztendlich Dart insgesamt im Web dann letztendlich nutzen kann.
Jan: Zwischenfrage an Jojo. Ist das 'n Ansatz, den ihr weiterempfehlen würdet, jetzt wo ihr einmal durchgegangen seid?
Jojo: Es kommt immer bisschen drauf an letztendlich, was die Anforderungen sind und was letztendlich die Schnittstellen sind, die man nach außen hat. Also was man sich einfach bewusst werden muss, es gibt für letztendlich die Hyperscaler, also Google AWS gibt es, die sie bereitstellen, die in Darts sind, die man nutzen kann, zum Beispiel eine Authentifizierung zu machen. Man hat auch zum Beispiel auf der Google Seite komplett eben diese dieses Google APIs Package, wo alle ja Services letztendlich von der Google Cloud abgebildet sind. Aber man kann zum Beispiel jetzt nicht irgendwie 'n optimierten Transport über anderes Protokoll. Man geht da jetzt nicht immer über die Schnittstelle und kann auch eben nicht nutzen, was halt dann schon in gewissen Impact hat. Also bei uns war es so, es waren 5 Services, 6 Services, die von der Google Cloud jetzt in dem Kontext gebraucht haben. Wir wissen, dass wir das erweitern. Es ist relativ einfach, das letztendlich über die Google anzubieten anzubieten, ist es dann 'n gewisses Schema. Aber man muss es erst mal son bisschen durchdringen. Also gefühlt fehlt da son bisschen, find ich, auch von der Google Seite so die Unterstützung, dass sie das bisschen besser aufbereiten, wie man das eigentlich nutzen könnte. Und vielleicht auch da natürlich investieren, so was wie in die Google oder in separaten Package dann eben anzubieten. Mhm. Mhm. Okay.
Kilian: Es braucht auf jeden Fall mehr mehr Zeit und mehr Investitionen, wie Du meintest, Jojo. Ja. Es ist einfach, dass dass Dart grade im Backend noch superjung ist, dass Ökosystem natürlich noch nicht noch nicht da ist in der in der Masse, wo es vielleicht in in Javascript oder so da ist an an Packages und an Tools. Ich bin der Überzeugung, dass das irgendwann kommen wird, aber natürlich, man muss sich im Klaren sein, wenn man jetzt sein backet of dart umstellt, man schon wahrscheinlich in einigen Aspekten Punkten kommen, wo es vielleicht noch keine Out of the Box Lösung gibt, sondern man eben 'n bisschen selbst mal ran muss.
Jojo: Mhm. Aber das, was man bekommt, ist auf jeden Fall ziemlich cool. Also von der Performance her ist es wirklich unschlagbar, ähnlich zu 'ner Go Run time. Also das ist halt der große Vorteil, den Dart eigentlich da bietet, dass wir da wirklich Vergleiche gemacht haben mit unserem Java Backend oder auch teilweise unseren Node JS Backends, wo man einfach sieht, was einfach Dart als Sprache und der Ansatz natürlich zu der IOT Compellierung natürlich da da bietet.
Jan: Jetzt, wo wir darüber gesprochen haben, was Jasper ist und was es sein will und was es vielleicht nicht sein will, stellt's ja vielleicht für alle da draußen auch die Frage, wie fang ich denn damit an und wie funktioniert das so unter der Haube? Also wenn ich jetzt voll begeistert aus diesem Podcast komme und ich sag mal, ich will auch mal irgendwas in in Jasper bauen. Wie fange ich denn an?
Kilian: An sich supersimpel. Du Du installierst es über die Dart CLI und dann es ist 'n normales Darts Projekt an sich und es ist son bisschen vom vom Aufbau her eben so, dass es ähnlich wie Flatter ist. Also Du hast halt, also es heißt, funktionieren erst mal ungefähr wie Widgets. Du hast Stateless, Stateful und Inharted Components und baust damit eben erst mal deine UI auf. Der Unterschied kommt dann, wenn Du die die ActionUI UI Elemente einbauen willst, was eben in Jasper HTML Elemente sind, wie div Button und so weiter und eben nicht wie in Flatter, keine Ahnung, Columm oder Row oder Container oder so. Also diesen diese diese sind eben in Jasper HTML und auch das Styling funktioniert erst mal über über CSS. Aber genau, an sich ist es, glaube ich, supersimpel. Du kannst über die CLI eine eine Starterapp erstellen und hast dann schon mal erst mal eine Website, die am Laufen ist.
Jojo: Mhm. Ich find das auf jeden Fall schon sehr komfortabel, dass es diese CLI gibt. Also die übernimmt da schon sehr viel, auch man kann letztendlich das einfach surfen als Webserver, als Devserver, Entwicklungsserver oder auch letztendlich diesen ganzen Bild damit anstoßen. Und find ich, da bietest Du einem schon sehr viel Komfort letztendlich, das Projekt so zu starten, anzulegen und dann natürlich auch dann auszuführen. Das ist cool.
Kilian: Man hat auch 'n paar Auswahlmöglichkeiten am Anfang, also eben über die SLI, wenn Du jetzt 'n Projekt erstellst. Also a kannst Du deinen Modus auswählen von den 3 genannten. Aber dann auch zum Beispiel, ob Du ob Du Routing haben möchtest, wie Du Routing haben möchtest, ob Du jetzt eben 'n 'n zum Beispiel 'n Backend im Server Mode verwenden möchtest oder nicht. Genau und dann hast Du schon mal son son Grundgerüst, was eben auch für dich schon son bisschen zugeschnitten ist, womit Du dann starten kannst.
Jan: Das heißt, Jasper bringt so einiges an primitives mit. Du hast grad gesagt, ne, so alle HTML Elemente sind dann da mit drin. Irgendein Verständnis von von CSS ist auch mit drin, aber das ist ja dann erst mal nur in Code beziehungsweise in Memory. Und irgendwann muss da ja so richtiges HTML draus werden. Und wie funktioniert das?
Kilian: Also es funktioniert so, also ungefähr konzeptionell so wie react. Du hast eben einen beziehungsweise aus der Flatterwelt kennt man das als und. Und in Jasper hast Du eben genau diese diese Bäume an Komponenten, Elementen und Renderobjekts. Und diese Renderobjekts sind dann die tatsächlichen Dom Notes. Und was passiert ist, wenn Du eben die die wenn die Bildmethode aufgerufen wird, wird eben verglichen mit dem aktuellen Stand, also was wie ist das Dom aktuell mit dem neuen Stand im Prinzip was hat die buildmethode return? Was was soll es jetzt sein? Und dann gibt's halt 'n Algorithmus, der sehr präzise reingeht und schaut, was hat sich tatsächlich geändert und auch noch nur die Sachen anpasst, die sich die sich geändert haben. Also wenn Du jetzt irgendwie 'n 'n größeren Baum hast mit 'ner tieferen HTML Struktur, nur irgendwo ganz tief drin, änderst Du ein Attribut. Dann schaut eben Jasper auch, dass nur dieses eine Attribut tatsächlich im Dom angepasst wird und geändert wird.
Jojo: Mhm.
Kilian: Was eben also vom vom Approach her, wenn man aus der Webwelt kommt, ist das nichts Neues. Das hat mit, also React hat das, glaub ich, erfunden oder zumindest groß gemacht diesen Ansatz und genau, Desper macht eigentlich genau das.
Jan: Jetzt hast Du zwar gesagt, React hat das erfunden und das ist per se nix Neues, aber das von Grund auf mal selber zu bauen, ist ja schon auch nicht trivial, also.
Kilian: Das auf jeden Fall, ja. Es war ja auch für mich, also ich wusste so grob, was also ich wusste, was Virtual Don oder sagen wir, ich kannte den Begriff, so.
Jan: So immer meine Realität, ich werd's so. Ich ich ich kannte das, ich wusste ich hab's schon mal gehört, so. Ja.
Kilian: Es war auf jeden Fall eine eine eine ziemlich große, aber auch coole Challenge, mal sich wirklich reinzufuchsen und zu schauen, wie funktioniert das tatsächlich. Weil natürlich immer, wenn man drüber redet, ist es ja alles noch sehr so gerade so an der Oberfläche Und das wirklich mal selbst zu bauen, war schon eine krasse Lernerfahrung so. Was auch Das
Jan: wäre jetzt auch meine Frage gewesen so. Also was, also ich stell mir das erst mal so sehr romantisch verklärt vor, voll cool. Du hast mal so was gebaut, was sonst nur so die großen Frameworks da draußen irgendwie bauen. Ich befürchte aber, dass es auch sone sehr erdende Erfahrung an vielen Stellen vielleicht ist, weil man dann wahrscheinlich auch in viele Löcher fällt, die ja alle anderen da draußen auch schon mal erfahren haben so, ne. Also verschiedene Browserimplementierungen, irgendwie komisches Verhalten im HTML Standard oder so was, ja. Was sind son paar Pit Falls, über die Du da gestolpert bist?
Kilian: Es geh es ging tatsächlich in beide Richtungen. Also natürlich die eine Richtung ist, oh Gott, ist das kompliziert und oh Gott, gibt's da viele Edge Cases, die man irgendwie alle bedenken muss und und dauernd findet noch irgendwer irgendwelche Bugs, die man dann fixen muss, aber ich hatte auch einige Momente auf der in die andere Richtung, wo so war, okay, ich hab das jetzt wirklich mal super low Level mich mit der Implementierung befasst und das mal selbst geschrieben und eigentlich ist das gar nicht so kompliziert. Also gerade zum Beispiel für mich, gerade der Moment Server Side Rendering war so, okay, ich dachte irgendwie, das ist komplizierter, weil also ganz ganz runtergestrippt. Das eigentlich das Einzige, was Du ja machst, ist, Du hast deinen deinen deine Baumstruktur an Components und dann machst Du eben iterierst Du über den Baum und spuckst halt einfach nur 'n String aus. Ja, also wenn's jetzt eine diffnote ist, dann spuckst Du halt den String diff aus und wenn und dann gehst Du, iterierst Du über die Attribute und iterierst Du über die Children Und am Ende hast Du einfach nur 'n String und den String sendest Du als Response zurück an an den Client. Und das war das war zum Beispiel ein Moment für mich, wo ich dachte, okay, natürlich kommt dann danach noch super viel, was dann irgendwie dazukommen, was man noch dazu bauen muss, aber irgendwie im im Grunde einen sehr augenöffnender Moment so. Aber eben, genau, also das war ein Beispiel in die Richtung. Es gibt viele Beispiele in die andere Richtung. Ich hab's auch für mich oder für mich wars auch wirklich son son Ding, okay, ich mach's auch eben genau, das das zu lernen, diese Challenge zu haben, mal wie wie verrückt wär das denn, 'n ganzes Framework selbst zu bauen? Beziehungsweise ich hatte am Anfang auch nie die Ambition, da jetzt son ganzes Framework draus zu machen. Das dann stand wirklich aus dem rein, ich mach 'n Prototyp für rein dieses dieses deklarative Rendering und diesen diesen Diffing Algorithmus und das das ich dachte eigentlich, das war's so. Ich dachte, das ist son kleines Experiment, was ich mal mache und dann son kleinen Prototypen hab, aber dann, ich hatte ja nie damit geplant, dann irgendwie son ganzes Framework daraus zu bauen.
Jojo: Wie ist es dazu gekommen, dass es dann doch son Framework geworden ist? Ist einfach so, dass Du sagst, okay, Du haust das jetzt nur mal raus, ich will's dann doch in die Öffentlichkeit tragen und es gab dann genug Response oder war es sone eigene Motivation, die sich dazu bewegt hat, das weiterzuführen?
Kilian: Es war eigentlich genau das. Also ich hab's ich hab's dann mal veröffentlicht, einfach 'n paar paar Leuten gezeigt, auch mal irgendwie auf Reddit gepostet. Da war die die Response eigentlich immer superpositiv, also so Leute meinten so, hey, das wär doch richtig cool, das zu haben und dann hab ich 'n bisschen weitergemacht. Irgendwann haben's Leute angefangen zu nutzen, also selbst im Superexperimental Status schon und ab dem Moment bis war ich halt so, okay, jetzt nutzen's Leute schon, jetzt kann ich's schwer irgendwie aufhören, das das weiterzumachen. Und also es war es war schon eine Challenge, also das das das Schwierige war nicht die Idee zu haben oder den Prototypen zu bauen, sondern das Schwierige war jetzt über wirklich zweieinhalb Jahre am Ball zu bleiben und und das irgendwie mal weiterzumachen. Ich hatte auch Phasen, wo ich nicht so viel dran gemacht hatte, wo die Motivation fehlte, aber dann immer irgendwie sich sich Motivation zu holen, sich selbst zu motivieren, da irgendwie weiterzumachen und das war immer sehr hing immer sehr viel damit zusammen, was so an Responces kamen und immer wenn ich wieder von Leuten gehört haben, die das die das genutzt haben oder eine eine Seite gebaut haben, die sie dann geshared haben oder in anderen Bereichen ich eine Podcast Einladung bekommen hab oder so was. Das war schon immer, natürlich zählte da schon immer viel mit rein, dann irgendwie doch doch weiterzumachen und das so als mein mein großes Projekt so weiterzuführen.
Jojo: Mhm. Ja. Cool. Ich hatte mich gefragt, als Du gesagt hast, okay, das war dann irgendwie so, dass man versucht hat, das zu implementieren und grade so dieses Iterieren über etwas, was war auch son Teil, den ich in meinem Ansatz auch schon so vervollständigt hatte. Aber grade, wenn Du natürlich auch versuchst, irgendwie das Server Side Branding irgendwie zu implementieren, dann hast Du ja auch diesen diesen Komplex der Hydration, wie sich das nennt. Und war das etwas, was dann eher son bisschen aufwendiger war oder vor Herausforderungen Ja. Dich gestellt hat? Weil zumindest ist das so in meiner Wahrnehmung, wenn's irgendwie die großen Web Frameworks wie NUXT oder Next geht, dass da sehr viele Bugs in diesem Bereich zu finden waren und es immer wieder Iterationen gab und Verbesserungen gab, wie die Hydration dann funktioniert. Vielleicht ist es erst mal gut, auch zu erklären, was Hydration eigentlich ist, weil ich hab's, glaub ich, auch jetzt irgendwie in der Vorbereitung vom Podcast zum ersten Mal wirklich so vollständig verstanden, dass es auf was es sich eigentlich bezieht. Also willst Du oder kannst Du dazu irgendwie was sagen, was das eigentlich ist und was dann passiert? Ja.
Kilian: Also ja, es war eine riesengroße Challenge. Was es ist, also Du hast Du hast jetzt die 2 Teile. Du hast a aufm Server das Server seit Rendering, was wie schon gesagt eben eigentlich nur 'n String ausspuckt, der dann zurück als als HTML String zurück an den Client gesendet wird. Und dann separat davon hast Du eben im Client deine deinen Virtual DOM und den Diffing Algorithmus, der eben schaut, wenn jetzt hier ein Kompononetr erinnert werden soll, wie muss ich das DOM manipulieren und anpassen, damit es eben effizient ist, aber auch wirklich die die Änderungen dann umsetzt. Und Hydration ist jetzt der Step zwischen der Browser hat das das HTML vom Server empfangen und fängt jetzt an mit dem Client Side Rendering und damit eben im Prinzip die Website interaktiv zu machen, also irgendwie, was ja fast ja noch komplett fehlt vom vom Server Side Rendering ist irgendwie die die Vend Händlers für irgendwelche Elemente und die die zum Beispiel zu attachion jetzt. Und Hydration macht da im Prinzip das, was der Diffing Algorithmus auch schon so ungefähr macht. Es schaut sich an, wie ist die HTML Struktur, die ich jetzt schon habe, vom Server bekommen habe und wo muss ich da jetzt meine ansetzen und wo muss ich da vielleicht noch irgendwas ändern? Im Idealfall müsste, also im Idealfall ändert man da gar nichts, außer nur eben Eventhändler anzusetzen und dann eben deine deine ganze, ja, dein dein Programm, deine Components und so weiter an die existierenden Dom Elemente irgendwie anzuheften und zu zu verbinden.
Jojo: Mhm. Also da musst Du dich das so vorstellen, klar, ich hab erst mal sozusagen diesen reinen String, den ich jetzt irgendwie zurückgesendet bekomme, aber alles andere, was natürlich irgendwie laufen muss in Dart oder Javascript auf dem Client, muss ja da irgendwie drübergelegt werden und einfach sozusagen dieses Matching an der Stelle hinzubekommen. Mhm.
Kilian: Ja. Und dann gibt's ja noch so tolle Sachen. Also der der erste Step oder die die erste Iteration von von Hydration ist einfach nur, ich hab ich hab jetzt das das HTML bekommen und ich starte jetzt meine App im Client und die geht noch mal überall drüber und im Prinzip, ich starte die App als Gesamtes einmal aufm Client. Die zweite Iteration davon ist, es hat verschiedene Namen, manchmal heißt's irgendwie Islands, meist manchmal heißt's, dass Du nur bestimmte Teile der Website jetzt interaktiv machst und nur in bestimmten Teilen die vornimmst, also zum Beispiel gerade für irgendwie, Du hast eine mehr oder weniger statische Seite, eine Landingpage oder so weiter und nur irgendwo ganz unten hast Du jetzt irgendwie eine eine Kontaktform, dann ist es, brauchst Du nicht die komplette Seite jetzt hydraten und interaktiv machen, sondern eigentlich interessiert dich nur diese diese Kontaktform jetzt irgendwie zu hydraten. Und dann kannst Du eben präzise reingehen und sagen, ich möchte nur nur den Teil jetzt oder mehrere Teile hydraten.
Jan: Das ist
Kilian: son bisschen der nächste Step und dann gibt's ja mittlerweile auch schon von von einigen Framemap. Next Jayce ist auch son bisschen Vorreiter noch noch ganz crazy Modelle mit irgendwie, dass Du jetzt mit Servercomponents irgendwie serverseitigem Code mit kleinseitigem Code vermischt und da ist es dann richtig kompliziert, das hat aber Jasper auch noch nicht mit drin.
Jojo: Okay. Also das, was man jetzt sozusagen bei diesem Serverset Rendering ist, hat es, es gibt halt irgendwie Komponenten, die, Du sagtest grade, die auf dem ausgeführt werden und wahrscheinlich auch nicht nur auf dem, sondern auch auf dem Server ja vorher schon eigentlich was bereitstellen müssen, aber dann sozusagen in dem wieder Interaktivität das mit Leben füllen. Aber es gibt auch solche Server Componys, die eigentlich nur sozusagen beim Initialen Erstellen dann auf dem Server erstellt werden. Und das kann ich dann irgendwie unterscheiden, wenn ich irgendwie Jasper schreibe, also.
Kilian: Genau, in Jasper ist das so implementiert, dass Du eine Annotation hast, die Du auf ein machst, die heißt at Client und die macht eben, die sorgt dafür, dass dieser dann auch im Client hyrated wird. Du hast also sowohl Server Side Renderd, also im Prinzip alles wird immer Server Side Renderd
Jojo: Mhm.
Kilian: Und dann hast Du die annotierten Componits, die dann im Client hydrated wird und eben auch, was es zusätzlich macht, ist eben auch die die Kompilation zu JavaScript, dass eben dieser Komponente dann zu JavaScript kompiliert wird und im Client dann ausgeführt wird.
Jan: Wenn ich jetzt anfange, Server und kleinen Komponenten zu mischen und und zu kombinieren, Du hast ja auch grad schon angesprochen, wie wie Nex das macht und und und Remix und so machen wir's ja ähnlich, ja, bietet Jasper da auch sone Art Hilfsmittel? Weil das Coole an next, Next, Remix und so weiter ist ja, dass ich, wenn ich quasi Frontend Funktionalität mit mit Backend State und Funktionalität vermischen will, in diesen Frameworks mich nicht mehr API Design kümmern muss, soweit diese Kommunikation zwischen Backend und Frontend halt Teil des Frameworks ist. Ich hab dann eine, weiß ich nicht, onload- oder on Change Methode oder so und das Framework macht für mich da hinten dran, HTTP Calls und updated state vorne und hinten und so was. Ist so was auch bei bei Jasper dann schon mit dabei?
Kilian: Ein bisschen, aber nicht so in der Form, wie es jetzt mittlerweile zum Beispiel bei NextDRS ist. Also wer's kennt, weiß vielleicht mit den Begriffen Server Components und Server Actions was anzufangen, was genau dieses ist. Das Framework hat sehr starke Abstraktionen über diese ganze kleinen Serverkommunikation gestrickt. Das also direkt den Vergleich, dass hat Jasper jetzt noch so noch nicht, aber was Jasper hat, ist son bisschen dieses, Du möchtest Daten vom Server zum Client synchronisieren und eben als Teil des Server Renderd HTMLs irgendwie kannst Du Daten mitschicken. Zum Beispiel, wenn Du, keine Ahnung, Du hast im Knopf, 'n Button, der jetzt irgendwie 'n Counter hochzählt und Du möchtest irgendwie 'n initialen Account, 'n initialen Status dafür haben. Dann brauchst Du das eben nicht nur als als Server Render hat HTML, sondern irgendwie auch als Daten musst Du diesen Bankaccount mitschicken und sowas kann Jasper schon. Aber eben dieses wie wie Nächstes macht, es mit Server Components noch nicht. Was ich dazu aber noch sagen kann, ist, ich hab das, weil ich find das vom Konzept supercool. Ich hab das mal als als Experiment auf einem auf einem Development Branch von DESPA auch mal ausprobiert, das das so zu implementieren. Und an sich funktioniert es, aber ich hab mich bisher dagegen entschieden, das irgendwie zu zu veröffentlichen oder auch also bei Jasper als als Feature mit reinzunehmen, weil wenn man sich jetzt noch mal zurück oder ich muss mich da zurückorientieren an meine Zielgruppe und da ist das Ding, dass teilweise, wenn jetzt Flatter Entwickler kommen, die noch so gut wie gar keine Webefahrung haben, schon genug angestrengt damit sind, erst mal generell zu verstehen, was ist überhaupt Server Side Rendering, was ist überhaupt Client Side Rendering und wie funktioniert überhaupt Hydration. Und dadrauf jetzt noch mal im Prinzip 'n ganz neues Konzept, was ja auch selbst in der React Welt am Anfang zu sehr viel Fragezeichen gesorgt hat. Das jetzt auch noch einzuführen, ist, glaube ich, eher kontraproduktiv mit der aktuellen Zielgruppe, weil das einfach noch zu viel Verwirrung und Komplexität mit reinbringen würde.
Jan: Du sprichst da 'n wichtiges Thema an, find ich. Also viele von uns haben ja vielleicht schon mal 'n Library veröffentlicht oder Maintenine 1 oder so. Da ist man ja auch immer son bisschen besorgt so mit Breaking Changes und wann führt man was ein und so. Aber bei 'nem Library ist das ja 'n relativ kleiner Scope. So. Bei 'nem Framework ist es ja noch mal was ganz anderes. Also krass formuliert, hättest Du ja die Möglichkeit, Jasper mit 'nem Major Release so komplett einmal auf links zu drehen und alles funktioniert jetzt anders und alle Konventionen sind zum Fenster raus und Du musst deine ganze Anwendung im Prinzip einmal neu strukturieren und so was. Wie wie fühlt sich das so an, ja? Wie präsent ist das so in deinem Alltag und was für Gedanken macht man sich so darum?
Kilian: Es ist schon sehr präsent, genau. Gerade als als oder Package Autor ist das was, wo man eigentlich immer wieder drüber nachdenkt. Meistens hat man viele Sachen, die man gern verbessern würde oder anpassen würde, aber es ist wirklich immer auch einen Faktor, der mit reinzählt, okay, was ist der Aufwand für die Nutzer, das jetzt irgendwie umzustellen? Ist das ist das auch erst mal eine intuitive API? Macht's das jetzt besser oder schlechter? Und gerade bei sonem sonem großen Projekt wie Jasper ist das natürlich was, wo ich wo ich auch immer 'n Auge drauf habe und haben muss, weil Du kannst nicht Du kannst nicht mit jedem Release das komplette System umstellen und von Leuten erwarten, ihre Website dann komplett neu zu schreiben oder halt komplett zu refactern. Gut, Jasper ist noch nicht stable, also es ist immer noch in 0 Punkt, ich glaub, 17 aktuell. Von daher, jeder meiner Release ist, kann aktuell noch Breaking Changes haben, aber das sind, also ich änder aktuell nichts mehr an jetzt irgendwie dem dem Grund Componensystem oder so was, ja. Das sind halt eher kleinere Sachen.
Jan: Und wenn Du sagst, das ist noch im im restable grade, was ist so deine deine Roadmap? Wann willst Du vielleicht mal sone stabile 1 0 veröffentlichen? Wo willst Du mit Jasper insgesamt noch hin?
Kilian: Es ist das ist eine sehr gute Frage. Die die die größer zugrunde liegende Frage ist ja generell, wie enthält man langfristig son Open Source Projekt? Wo ich auch immer wieder am Überlegen bin, weil klar, JazzPare ist free and Open Source so. Ich mach das in meiner Freizeit. Bei mir ist auch aktuell die Situation, dass ich bald 'n neuen Job anfange, der wahrscheinlich 'n bisschen mehr demanding als der davor wird und natürlich ist für mich auch die Frage, wie kriege ich das in Jazzper Waltersmoment hin? Also die Frage ist nicht ob, sondern die Frage ist wie. Ich hab keinerlei Tendenzen, das jetzt irgendwie stehenzulassen. Aber natürlich muss man sich fragen, ja, wie wie schafft man es irgendwie, dass dass dass auch irgendwie nachhaltig mainable bleibt Mhm. Für für die nächste Zeit und auch für die nächsten Jahre im Idealfall.
Jan: Und nur, den den Kontext da herzustellen, Du maintainst jetzt grade noch alleine?
Kilian: Ja, also als als Hauptminainer, ja. Also es gibt natürlich Contribuiter, die aber mehr so hin und wieder mal kleinere Sachen machen. Was jetzt Core Martenness angeht, bin ich da aktuell alleine, ja. Hab noch keinen gefunden, der verrückt genug wäre, mich da zu unterstützen.
Jojo: Rück genug. Ja, das ist auf jeden Fall immer, weißt Du, eine gewisse Anforderung. Das ist mit jeder, wie Du's gesagt hast, Jan, irgendwie die man vielleicht veröffentlicht hat irgendwie so, dass man merkt, also klar kommen dann irgendwelche und je größer das ist, desto mehr schlägt vielleicht auch auf. Und grad bei 'nem Framework ist es natürlich sehr viel, was da irgendwie passieren kann. Deswegen ist es natürlich gut, wenn man nur vorangeht, aber man muss sich halt immer fragen, weißt Du, wie kann ich's letztendlich auch irgendwie sinnvoll noch mit abbilden und welche, wie viel Zeit kann ich da rein investieren? Und deswegen grade solche Überlegungen, die vielleicht irgendwie doch eine höhere wie Server Actives irgendwie einbringen würden, ist das wirklich etwas, was jetzt so benötigt wird für den Ansatz, den eigentlich Jasper versucht hat zu verfolgen? Oder ist das etwas, was man auch ganz gut anders lösen kann? Also das ist etwas, wo Du aktuell sagst, okay, die Zukunft ist son bisschen, Du versuchst letztendlich diesen Zustand zu erweitern oder gibt es da wirklich son Punkt, wie Jan vielleicht ihm das Erfahrung bringen wollte, wo Du sagst, jetzt ist es wirklich so der erste Label Release und den Funktionsumfang, den ich für Jasper eigentlich jetzt sehe, ist damit jetzt beinhaltet? Also gibt's da große Punkte, an denen Du gerade arbeitest, die jetzt kommen?
Kilian: Also gerade ist ist Fokus eher wirklich auf 'n bisschen oder also Stabilität und son bisschen Polishing. Mhm. Was schon Richtung 'n 'n Stable Release geht, aber ich kann das noch nicht absehen, wann das sein wird. Genau, deswegen also Haupt Hauptding ist wirklich, ja, wie schaffe ich's weiter Zeit einfach da rein zu investieren und wie schaffe ich's vielleicht auch, dass son bisschen sich das Projekt auch finanziert, ja? Mhm. Ja, große Fragen.
Jojo: Ja, wenn sich jemand da irgendwie dran beteiligen will, dann auf jeden Fall ja, man kann sich beteiligen. Es ist einfach Open Source. Du hast letztendlich da irgendwie 'n Bereich, wo Du irgendwie drauf eingehst, wie man sich irgendwie beteiligen kann. Und wenn jemand Interesse dran dann dran hat, steigt er gerne mit ein. Was
Jan: Wer sind denn so die aktuell großen oder größten dir bekannten Nutzer oder Use Cases von Jasper?
Kilian: Also viel oder oder die die meisten sind irgendwelche wirklich Flatterentwickler, die ihre entweder Personal Websites oder Webseiten von, wenn sie Freelancer sind, von ihrem Freelance Business oder so machen. Es gibt 'n paar irgendwie so so Community Seiten von von Flatter Communities, die damit gemacht sind. Also man merkt alles schon immer noch sehr oder sehr nah an der Flatter Community natürlich. Ist ja auch ganz ganz natürlich. Genau, das sind das sind so die großen Seiten. Es gibt vereinzelnd vereinzelnd 1, 2 auch so als, tatsächliche Web Apps oder Webseiten von irgendwelchen Start ups oder sowas.
Jojo: Mhm.
Kilian: Genau, aber hauptsächlich wirklich so so ja private Developer, die für sich selbst irgendwelche Seiten machen.
Jojo: Mhm. Gut. Mögt mich vielleicht auf einen ganz guten anderen Punkt. Das finde ich nämlich spannend. Wenn ihr das wirklich mal ausprobieren wollt, Du hast eine Abwandlung von dem Dartpad geschrieben, Jasperpad nennt sich das, wo man das einfach mal ausprobieren kann, wie man letztendlich eine Jasper Seite irgendwie bauen würde. Das findet man auch letztendlich in der Dokumentation oder auf dem Bereich. Wie baut man so was? Also ist es einfach möglich, da das Dartpad zu nehmen und das irgendwie abzuwandeln? War das kompliziert oder ist das eigentlich son einfaches Ding, son
Kilian: Mhm. Das also als ich das gemacht, ich hab das relativ am Anfang gemacht, eben auch als also a als Playground, b auch als als Showcase, weil es ja auch selbst mit Jasper gebaut ist. Das war noch zu 'ner Zeit, wo Dartpad selber noch mit Dart Web gebaut war. Also mittlerweile ist es ist es ist Dart pad eine Flatter Web App, aber vor so 2 Jahren war das noch eine Dart Web App. Aber eben genau in diesem Modus, es werden die die rohen Browser APIs genutzt, irgendwie da 'n paar DOM Manipipulations zu machen. Und das da hab ich eben den den Code genommen, der auch Open Soices und eben auf Jasper umgewandelt und dann neu neu veröffentlicht, genau.
Jan: Das klingt so trivial, wenn Du das so erzählst, aber ich glaub, Jasperpad, das ist schon 'n megacooles Tool mit superviel Potenzial, den Leuten das mal so näherzubringen, weil wie Jojo schon sagt, nur Du machst jetzt den Browser auf. Ich hab auch eben mal son bisschen rumgespielt. Ich hab keine Ahnung von von Jasper oder von Dart oder von Flatter. Und selbst ich konnt ja irgendwie mal so ganz schnell noch 'n paar Elemente hinzufügen und Reinfolgen ändern und und und bla bla bla. Und das ist, glaub ich, superhilfreich, vielleicht sone initiale Skepsis irgendwie abzubauen, son bisschen neugierig zu machen, son bisschen Lust auch dran zu machen. Also das vielleicht, wenn wir sonst nichts anderes mitnehmen von dieser Podcastfolge, dann wenigstens einmal irgendwie auf Jasperpad gehen und 'n bisschen rumspielen.
Kilian: Ja, nee, das das war auch genau das war die Intention oder die Idee, die ich am Anfang hatte, mal was zu haben, wo man halt einfach schnell mal rumspielen kann und mal sehen kann, wie das denn aussehen würde, ohne dass man sich das jetzt direkt installieren muss und irgendwie sein Environment aufsetzen muss.
Jan: Vielleicht noch mal zu der Frage zurückzukommen, wo es so mit Jassper hängen sollte. Wenn Du jetzt losgelöst von all diesen Constrins, ne, keine Zeit und gucken, wie sich's finanziert und überhaupt alles, wenn Du dir so mit dem Zauberstab eine Sache wünschen könntest, die Jasper jetzt anders machen sollte oder 'n Feature, was noch fehlt oder so, was was würdest Du dir dazu wünschen? So ganz ohne Rücksicht auf Verluste.
Kilian: Also wer ich's mir wünschen könnte, da würde ich tatsächlich auch in diese diese Server Component Serveraction Richtung gehen.
Jojo: Mhm.
Kilian: Losgelöst von, dass es wahrscheinlich mehr Fragezeichen kosten würde, als es lösen würde, weil ich's einfach technisch super-, super-, supercooles Ding finde, was was die da, ja, geschaffen haben. Und das andere ist, woran ich aktuell 'n bisschen arbeite, ein mehr für mehr Richtungen, also 'n 'n, wie sagt man, Woran ich aktuell arbeite, ist ein ein ein weiteres Package, was mehr die unterstützt, also für irgendwie Content Management und son so irgendwie Seiten aus Marktdown generieren und die das Thema. Was son bisschen in Richtung von Astro vielleicht geht für, wenn man den Vergleich ziehen möchte, da 'n bisschen auch eben eine eine bessere Store zu haben.
Jojo: Cool.
Jan: Also ich glaub, dass grad das Letztere wird ja auf alle Fälle noch mal mehr User Cases einbringen. Und ich glaub, für das Erste, für dieses Serversite Ding oder die die Kommunikation da ist ganz, das glaub ich viel mehr sone Developer Experience Challenge, ne. Also wie kannst Du son Feature halt einbauen, ohne es halt zwangsweise nutzen zu müssen und wie schafft man das dann halt so Discoveryability davon irgendwie einfach zu haben, sodass man sagen kann, okay, Du kannst Jasper nutzen, ohne das jemals berühren zu müssen und Du kannst trotzdem machen oder vielleicht auch kleine Interaktivität Sachen schon. Aber dann trotzdem den Schritt dahin halt relativ angenehm zu gestalten so. Das glaube ich viel mehr die Challenge als die die technische Implementierung davon.
Kilian: Ja, absolut. Es ist 'n aber auch generell Jasper als Projekt. 'N Großteil ist auch so Education Challenge. Leute beizubringen, wie das funktioniert, was man gebaut hat, gerade wenn's eben ja Developer aus 'nem anderen Bereich kommen oder in dem Bereich vielleicht noch nicht so viel Erfahrung haben. Ein ein großes Thema ist auch schon seither Styling, weil ich komm nicht drum herum, ich hab zumindest noch keinen Weg gefunden, drum herum zu kommen, dass Developer CSS schreiben müssen. Was natürlich, wenn Du von Flatter kommst, Du entweder nicht kennst oder Du kennst es und willst es nicht nutzen. Aber da eine sinnvolle Abstraktion drum zu bauen, ist super-, super-, superschwierig. Und da hab ich wirklich bisher noch keine Lösung gefunden, die irgendwie meinen Ansprüchen gerecht wird, dass es halt auch ja, von 'ner Developer Experience und so weiter gut ist.
Jojo: Ich mein, was Du ja bietest, ist ja letztendlich mit diesem package, dass Du halt direkt irgendwie integrieren kannst, nutzen kannst. Also das ist zumindest das, was ich so auch in meinem Umfeld sehe, dass eigentlich alle Entwickler eigentlich Tailwind nutzen und weißt Du gar nicht wirklich CSS schreiben, sondern eher vorgefertigte Styles irgendwo dran setzen. Und ja, ich find auf jeden Fall den Support, den Du dafür schon hast, ist auf jeden Fall gut und erleichtert das letztendlich damit damit umzugehen.
Kilian: Das war auch son bisschen mein mein Approach aufgrund des dieses Problems, dass ich gesagt hab, okay, ich nutz doch das, was da ist irgendwie. Wenn ihr keinen CSS selber schreiben wollt, dann nutzt irgendwie Tailwind oder nutzt irgendwelche CSS Frameworks. Da gibt's ja auch einige, wo Du dann nur noch Klassen schreiben musst und die vorgefertigte haben.
Jojo: Mhm.
Kilian: Genau. Das ist aktuell so der Ansatz auch in der Dokumentation, wo ich sag, okay, da gibt es schon genug Möglichkeiten, das das zu integrieren. Und da Jasper im Endeffekt nur eine normale Website ist, kann man eigentlich auch alles nutzen, was Du auch in der normalen Website nutzen kannst an an irgendwelchen CSS Lösungen oder eben nicht CSS Lösungen. Genau, da gibt's schon da gibt's schon genug Auswahl auch.
Jan: Jetzt hat ja Flatter im Prinzip 'n ähnliches Problem, ja? Flatter muss ja auch Layout irgendwie integrieren und am Ende rausrändern Und die machen das ja einfach sehr stark an die Widgets dran gekoppelt. So, also im Prinzip gibst Du ja jedem Widget mit, wie es aussehen soll, wie es sich verhalten soll und so weiter. Und das ist ja im Prinzip, wenn man jetzt mal Flatter für Web Apps anguckt, eine komplette Wegabstraktion von CSS. So. Was hält dich denn davon ab, son ähnliche Route zu gehen, ja? Dass, wenn Du jetzt hier son h 1 Element hast, dass es halt im Prinzip für jedes CSS Property, das es haben kann, auch 'n Dart Property sozusagen analog dazu bekommt?
Kilian: Des das große Problem ist der Unterschied, dass HTML und CSS getrennt voneinander lebt, aber eben in Flatter das Styling und das Theming eben nicht getrennt von den Widgets lebt, sondern in den Widgets mit drin. Und die, dass dass, wenn ich sag, ich möchte 'n 'n eine CSS Abstraktion am liebsten entwickeln, dann ist das, dass es so aussieht wie in Flatter, dass Du halt in deinen Widgets direkt irgendwie die die Properties, die Silent Properties mitgibst. Die große Schwierigkeit dabei ist eben, dass ich natürlich ganz am Ende, was Jasper ausspuckt, soll immer noch sehr gutes und cleanes HTML und CSS sein. Heißt, ich muss irgendwie die Styling Properties aus den Components raus extrahieren und in CSS packen, was Jasper dann generieren müsste. Und das ist super schwierig, weil die dieses CSS zu erstellen muss ja at Compiltime funktionieren. Also weil es es macht wenig Sinn und es ist auch nicht so Performance CSS irgendwie at Run Time zu generieren, sondern Du willst ja schon, wenn Du die Website lehnst, dein komplettes CSS Skript haben und dann nur dadurch, dass Du irgendwelche Klassen anwendest, deine Elemente stylen.
Jan: Also, ich glaub, das ist 'n sehr löblicher Ansatz und ich versteh die die puristische Blickwinkel, wo er herkommt, aber wenn man sich mal anguckt, wie andere Frameworks das heutzutage machen, dann hat man sich, glaub ich, auch schon son bisschen davon verabschiedet. Ja, also ich glaub, die Grundidee, möglichst viel CSS vorher schon zur Verfügung zu stellen, ist nach wie vor richtig. Aber selbst in oder in View wird ja immer noch auf dem einzelnen Element rumgeschrieben. So auch während der Runtown. Und ich glaube
Kilian: Wissen Sie das?
Jan: Ja, ja. Also das führt jetzt vielleicht in in zu viele Details, aber ich glaube, Du kommst nicht drum rum, so beides irgendwie zu machen. Also alles, was Du raus extrahieren kannst, super cool, superperformant, sollte man machen, aber gerade, weil ja auch diese diese Properties dann dynamisch zur Laufzeit sich ändern können und so, musst Du ja auf den einzelnen Knoten rumschreiben.
Kilian: Ja, genau. Für die, die sich ändern ja, aber eben für alles andere nicht. Ja. Also halt für das für das eigentlich restliche gesamte Layout willst Du halt nicht irgendwie Inline Styles jetzt nutzen. Da das ist zumindest da ist zumindest mir nichts bekannt, was jetzt irgendwie großflächig Inline Styles nutzen würde.
Jan: Nee, nee, nee. Also auf jeden Fall hast Du recht so, ne? Aber dadurch, dass Du ja Inline Styles nutzen musst, zumindest für die, die sich ändern, muss man, glaub ich, nicht so viel Sorge haben, dass man das 100 Prozent vermeiden kann, weil das geht, glaub ich, nicht.
Jojo: Ich geh geh geh natürlich da die Herausforderung, weißt Du, natürlich ist es etwas CSS, was sich ständig weiterentwickelt. Und das müsste natürlich auch immer so weiterführen und alles Natürlich. Natürlich abbilden. Und das ist natürlich 'n super Aufwand, deswegen find ich eigentlich den Ansatz zu sagen, okay, das ist natürlich eine andere Welt und flatter geht an anderen Ansatz. Und klar könnte man sich irgendwann überlegen, oberhalb von Jasper irgendwie sone zu zu schreiben, die das son bisschen irgendwie weiter abstrahiert, aber eigentlich erst mal so diese Freiheit zu haben und zu sagen, dann steht's mir frei, welche Lösung und dann nutz ich eine CSS Utility Framework, nutz ich 'n CSS Framework Framework und hab dann wirklich komplette Komponenten, bietet man natürlich sehr viel Freiheit. Und klar, es ist sehr unterschiedlich zu dem, wie Flatter macht, aber in Flatter hat man natürlich auch die Möglichkeit, am Ende alles auf dem Canvas zu zeichnen, was man will. Und das ist natürlich etwas, was CSS einem so auch bietet. Und ich glaube, das wär ja, auf jeden Fall 'n Riesenaufwand natürlich, das irgendwie kontinuierlich fortzuführen und zu pflegen und mitzuarbeitern.
Kilian: Das ist 'n guter Punkt, den Du damit auch angesprochen hast. Als ich Jasper, sag ich mal, erdacht habe zuerst, aber auch jetzt weiterführen mainted habe, eine Schwierigkeit oder eine Überlegung, die ich auch immer wieder mache, ist, was welche Teile mache ich so, wie sie in Flatter sind und welche Teile mache ich so, wie sie nah an der Webplattform sind? Weil eben, okay, ich möchte, dass es irgendwie familiär für Flatter Developer ist, aber ich möchte auch nicht die komplette Webplattform web abstrachieren, weil das wird auch irgendwie den Purpose wieder wegnehmen, weil dann kann man auch wieder Flatter Web nutzen. Der Purpose von Jasper ist ja, dass Du wirklich mehr oder weniger nah an der Webplattform bist und und wirkliche wirkliche Webseiten schreiben kannst. Heißt es immer ist auch immer wieder eine Schwierigkeit, wo nutze ich Flatter APIs und wo nutze ich vielleicht eben auch nicht Flatter APIs, sondern lass die die Abstraktion mehr oder weniger weg oder mach nur eine sehr leichte Abstraktion auf der auf der auf den Web APIs. Mhm. Was immer wieder natürlich auch eine Balance ist, die gehalten werden muss und auch man ganz unterschiedliches Feedback kriegt, was es dann nicht leichter macht, weil natürlich kriegst Du für beide Seiten Feedback, dass dass die einen sagen, bitte mach alles so, wie es in Flatter ist und abstrahiere alles, was irgendwie mit Web zu tun hat und die anderen sagen, sie kommen vielleicht mehr aus der Webrichtung, bitte abstrahiere bloß nicht zu viel vom Web weg und lass die ganzen Flattersachen lieber sein. Und daraus zu filtern, was jetzt das Richtige ist, ist auch schwierig.
Jojo: Ja, glaub ich. Absolut. Und Jan, wie Du's gesagt hast, am Ende kann man auch natürlich Flatterweb dazu nutzen, wenn Du halt wirklich so diesen reinen Flatterweg gehen willst und diesen Ansatz eben. Mhm.
Jan: Cool. So. Wir nähern uns hier dieser magischen Ein Stunden Marke, die wir immer versuchen zu halten und dann grandios drüber hinwegschlettern. Aber ich will das ja hier auch nicht abwürgen, aber ich hab noch eine Frage an Key lern und zwar meine Standardschussfrage ist, welche Frage haben wir dir nicht gestellt? So. Worüber wolltest Du unbedingt noch reden? Was wolltest Du unbedingt noch von Jasper erzählen? Und hast dir gedacht so, Mensch, weder der Jan noch der Jojo haben mich hier gefragt, da wär's das son geiles Thema. Und jetzt haben wir gar nicht drüber gesprochen.
Kilian: Wir hatten's im Vorhinein kurz erwähnt, aber es kam jetzt nicht zur Sprache, und zwar die Jasper Website. Oh
Jan: ja. Mhm.
Kilian: Wenn die Folge rauskommt, wird es wahrscheinlich eine Jasper Website geben. Zum Zeitpunkt der Aufzeichnung gibt es aktuell noch keine Jasper Website im Sinne von eine Landingpage, die Jasper vorstellt. Was wo ich mir der Ironie sehr bewusst bin, dass es ein Web Framework ist, was keine Website hat. Irgendwie bin ich die letzten 2 Jahre nicht dazu gekommen. Es gab immer immer anderes, immer Features, immer irgendwas anderes, was gemacht werden wollte, aber aktuell oder ich hab mich jetzt als auch als Neujahrsvorsatz mal wirklich drangesetzt und die sollte jetzt in den nächsten Wochen eigentlich dann, also nächsten Wochen nach nach Aufzeichnung, aber wenn's dann ausgestrahlt wird, schon schon da sein.
Jan: Du musst es ja 'n bisschen positiver formulieren, weißt Du? Jasper einfach das einzige Web Framework, das es gar nicht nötig hatte, eine eigene Webseite zu haben, so, ja.
Kilian: Ja, ja, kann man so formulieren. Nee, aber ist ja natürlich auch mit mit Jasper gebaut, die Website dann und auch Teil des Repositories Also auch wieder was, was man sich vielleicht anschauen kann, wenn man ein ein Beispiel sehen möchte. Mhm.
Jan: Genau. Und das ist, glaub ich, superviel wert. Also ne, ob Du jetzt eine Landing Page brauchst oder ob sone sone GitHub Seite irgendwie reicht, da kann, glaub ich, jeder da draußen eine eigene Meinung zu haben. Aber ich find's immer superwichtig, grade bei größeren Libraries und Frameworks, dass man sich mal angucken kann, nicht nur, wie funktioniert das und und wie ist das so zusammengesteckt, sondern wie benutzen es auch die Leute, die das geschrieben haben so, ne? Also was ist eigentlich so die der der philosophisch richtige Weg, das ein oder andere Problem vielleicht anzugehen? Und da nimmt man, glaub ich, immer superviel noch noch mit raus, so. Und von daher, den Zweck wird's auf jeden Fall erfüllen.
Kilian: Ich find's auch superwichtig, sein als als Autor seine eigenen Packages und sein eigenes Zeug irgendwie zu nutzen und zu Dogfuden. Es ist ja es ist ja auch nicht die erste Website, die ich jetzt mit Jasper selber schreibe, sondern eben, es kam ja auch zur Sprache Jasper Pad und und andere Sachen. Aber genau, ich find's auch superwichtig, seine eigenen seine eigenen Produkte zu nutzen und und auszuprobieren und weil man findet auch immer wieder Sachen, die man dann doch irgendwie verbessern möchte, die man, also ging's zumindest mir so, dass ich Sachen gefunden hab, die ich verbessern wollte, die ich halt so, wo ich so nicht drauf gekommen wär, wenn ich's nicht selbst mal in tatsächlich 'ner 'ner App irgendwie genutzt hätte.
Jan: Ja. Wahre Worte, wahre Worte. Jojo, hast Du noch eine letzte Frage?
Jojo: Meine Frage sind alle beantwortet.
Jan: Alle Fragen beantwortet wunderbar. Dann kommen wir jetzt zu unserer letzten Kategorie. Und zwar müssen wir noch über sprechen. Und damit die anderen beiden noch kurze Bedenken haben, worüber sie sprechen wollen, fang ich einfach mal an und stell erst mal eine Frage. Ich hab einen Hardware Pick und ich hab einen Software Pick. Was soll ich nehmen? Hardware.
Jojo: Bin ich auch der Firma.
Jan: Okay. Also so viel Hardware ist das gar nicht, aber ich bin ja immer gerne auf Reisen und da viel unterwegs und versuch immer so das ganze Zeug, was ich mit mir rumschleppe, so minimalistisch zu halten wie möglich und hab mir jetzt 1 von diesen Mini Wallets gekauft, die man so hinten an sein iPhone dran klemmen kann über MacSafe. Und das per se ist es ja nicht so spektakulär, ne, da passen irgendwie son paar Kreditkarten rein oder deinen Personalausweis, den Führerschein, whatever. Aber warum ich ausgerechnet diese genommen hab von ISR, das ist son mittlerweile einigermaßen bekannter Smartphone Zubehörhersteller, ist, dass da auch son son Support eben drin ist. Ja, das heißt, wenn dieses Ding irgendwie abgeht oder ich's im Rucksack liegen lasse oder mir sonst irgendwie abhandenkommt, kann ich's auch mit dem Apple Findmy Network wiederfinden. Und das ist tatsächlich superpraktisch und hat den angenehmen Nebeneffekt, dass wenn ich das Ding einfach nur so in meinem Rucksack liegen hab, ohne dass er an meinem Handy grade klebt, auch mein Rucksack irgendwie dann damit ortbar ist. So, das kostet irgendwie, weiß nicht, ich glaub paar 20 Euro hab ich dafür bezahlt. Also ist jetzt auch nicht überragend teuer, wenn man überlegt, was allein diese find my Beakons sonst irgendwie so kosten. Mhm. Und das war ja, war 'n cooles Weihnachtsgeschenk und kann ich kann ich bisher nur weiterempfehlen,
Jojo: so. Was für Karten führst Du dann so mit deinem Handy mit? Also was für Karten sind in diesem Case dann drinne?
Jan: Ja, das ist natürlich superspannend. Das passen so viel rein. Wir müssen da schon so sehr selektiv sein, ne? Ja und Jo Jo, wir fahren ja wir fahren ja die Woche Ski gemeinsam, ja? Da hab ich jetzt auch noch mal 'n bisschen was für angepasst, aber ich hab hab eigentlich immer dabei so mein meinen Personalausweis, meinen Führerschein, mein Ticket für hier, ne, wie heißt das? Deutschland Ticket Kombiding, das ist ja auch son NFC Ticket bei uns in den Verkehrsbetrieben. Und dann noch eine EC Karte, so. Damit man auch 'n bisschen Geld dabei hat. Wobei ich Karten eigentlich fast gar nicht mehr benutzt zu bezahlen, weil ich das mittlerweile fast alles mit Apple Pay mach. Ja. Es funktioniert sehr gut hier.
Jojo: Das war auch nämlich letzte Erfahrung, dass meine Karte abgelaufen ist, weil versucht, weil ich nur mit Apple Pay bezahle, war ich hier so völlig verdutzt, so was, die Karte ist abgelaufen, irgendwie schon wochenlang und monatelang nicht mit der Hand gehabt. Und ja, irgendwie hat meine Bank verpasst es mir irgendwie eine neue zuzuschicken.
Jan: Wunderbar. Das also mein Pick Link gibt's wie immer in den Shownotes, kann ich nur empfehlen. Was habt ihr so mit dabei?
Jojo: Ich geh mal vor, ich hab noch einen Punkt, wo ich dann doch dachte, das ist irgendwie sinnvoll und richtig, die zu bringen. Das ist 'n Buch, was ich grade jetzt zum dritten Mal lese und irgendwie feststelle, dass es wieder so passend ist. Es nennt sich Bewusstseinskultur von Thomas Mitsinger. Thomas Mitsinger, ich weiß nicht, ob es jemand schon mal 'n Begriff ist, ist 'n deutscher Philosoph, der sich sehr viel letztendlich mit Bewusstseinsstrukturen irgendwie beschäftigt, sehr viel letztendlich auch, wie grundsätzlich natürlich unser Gehirn funktioniert, hat sehr lange letztendlich in der Forschung gearbeitet und der sehr stark dafür plädiert, dass man einfach in diesen Zeiten, die natürlich entstehen, wo so was wie Klimakrise irgendwie immer bewusster einig wird oder immer weniger letztendlich weggeschoben werden kann, dass man sich sehr stark letztendlich damit beschäftigt und auch natürlich auch sein Bewusstsein trainiert, irgendwie wie man Dinge irgendwie wahrnimmt und realisiert. Und ich stell immer wieder fest, wie essenziell das Buch ist und jedem, den ich's jetzt auch inzwischen geschenkt habe, sagt, das war für für ihn so 1 der der wichtigsten Bücher, die sie in der letzten Zeit bekommen haben, gelesen haben, weil es son bisschen natürlich auch Möglichkeiten auf zeigt, wie man dem Ganzen begegnen kann, was zum Beispiel Tools sind wie Meditation, die einfach helfen, einen anderen Zugang zu unbewussten Zuständen zu haben, die natürlich, wenn sich Dinge stressiger werden, sich irgendwie potenzieren oder man irgendwie auch merkt, natürlich irgendwie ist momentan einfach sehr viel Veränderung so in der Welt da draußen, sich also son bisschen auf sich selbst besinnen zu können und zu realisieren, was eigentlich wichtig ist. Deswegen kann ich jedem nur empfehlen, wer da Interesse hat oder vielleicht auch irgendwie das Gefühl hat, er könnte da son bisschen Unterstützung gebrauchen. Ist 'n sehr, sehr hilfreiches Buch.
Jan: Und was ist jetzt genau der Schwerpunkt? Das klang son bisschen zwiegespalten zwischen, na ja, auf der einen Seite so erklärend, wie das so alles funktioniert so innerlich, ja? Und auf der anderen Seite hast Du ja auch grade viel über so Coping Mechanismen gesprochen. Aber aber was ist der eigentliche der eigentliche Punkt von dem Buch?
Jojo: Also der eigentliche Punkt ist eigentlich, dass er aufzeigt, was natürlich so passiert, also 'n bisschen das natürlich irgendwie erklärt, da natürlich auch auch Ansätze bietet, wie ich grade gesagt hab, Meditation. Er spricht natürlich auch da, wenn man sagt, dass es sehr viel Forschung natürlich grade im Bereich von psychedelischen Substanzen gibt, die man irgendwie nutzen kann, da eben anderes anderen Bezug zu bekommen oder dass das eigentlich und Bewusstseinszustände sind, die man eigentlich fördern sollte. Also er spricht sich eben sehr stark dafür aus und natürlich eben so die Erfahrung aus der Meditation, dass man sich mehr mit dem beschäftigt, was eigentlich und ja so passiert. Also ich würde sagen, der Schwerpunkt ist eigentlich versuchen, da 'n gewissen Ausblick zu geben, obwohl er da auch eine sehr kritische Meinung hat letztendlich, was in Zukunft eben passieren kann und auch eher negativ ist. Aber dass man sagt, okay, wir sind jetzt eigentlich in diesem Zustand und es geht darum, das irgendwie noch zu gestalten und nicht einfach zu realisieren, okay, wir haben da gar keine Möglichkeit mehr beim Klimawandel irgendwie zu reagieren, sondern dass es immer noch Möglichkeiten gibt, ohne jetzt konkret Möglichkeiten aufzuzeigen, aber zu zeigen, was sind eigentlich
Jan: Mehr so die Grundhaltung sozusagen.
Jojo: Die Grundhaltung, die eigenen Zustände, die ich eigentlich kultivieren kann, den Ganzen besser zu begegnen und besser damit umgehen zu können. Wunderbar. Kilian, was hast Du im Gepäck?
Kilian: Ich hab einen Serienpick.
Jan: Ja, immer gerne.
Kilian: Arkane, zweite Staffel. Ist jetzt nicht so super frisch draußen, aber für mich schon, weil ich hatte die erste Staffel gesehen, als sie rauskam und dann aber irgendwann mein mein Netflixaccount gekündigt. Und dann als die zweite rauskam, war ich so Shit, ich kann jetzt die die nicht schauen. Aber jetzt habe ich mir von 'ner Freundin ein ihr Netflix Passwort geschnorrt und hol die jetzt nach.
Jan: Und was geht?
Kilian: Ich find die Serie einfach super super stark. Es ist die Serie, also sie spielt im League of Legends Universum. Ich muss sagen, ich hab's nie gespielt, deswegen weiß ich gar nicht, wo da wo da die Parallelen der Story sind.
Jan: Aber trotzdem kann man das genießen. Das wäre nämlich jetzt auch meine Frage, weil ich ja auch nie in League of Legends gespielt.
Kilian: Nee, absolut. Also Okay. Ich hatte nicht das Gefühl, dass man irgendwelche Vorkenntnisse brauchte und es ist Also das Stärkste an der Serie finde ich neben der Story den den Animationsstil. Also es ist eine animierte Serie, aber mit 'nem ganz, ganz eigenen Stil und super-, super stöhnen und künstlerisch gemacht und ja, also einfach sehr, sehr bildgewaltig und für für sone animierte Serie finde ich noch mal echt was was ganz Eigenes. Und von daher, jeder, der irgendwie gute, schönen schöne animierte, ja, Serien oder Filme wertschätzen kann, ist das auf jeden Fall eine Empfehlung.
Jan: Cool. Dann danke für den Pick. Dann bleibt uns eigentlich gar nicht viel zu sagen, außer noch mal allgemeines großes Danke. Danke an alle, die zugehört haben. Danke an Jojo. Danke an Kilian, dass Du heute unser Gast warst. Zum zweiten Mal nach dem Flatter Day hier noch mal Zeit für uns genommen hast. Wunderbar.
Kilian: Ja, vielen vielen Dank für die Einladung. Ich hab, freut mich immer, über Jasper zu erzählen.
Jan: Ich hoffe, es war nicht das letzte Mal. Wir sehen uns bestimmt noch mal noch mal wieder. Und dann können wir vielleicht über die dann fertige Jasper Homepage sprechen und wie das so war, den Jasper zu bauen.
Kilian: Sehr gerne.
Jan: Ansonsten, wenn ihr da draußen noch Fragen, Anmerkungen, Kritik oder sonstiges Feedback habt, könnt ihr uns gerne erreichen unter Podcast at Programmier Punkt bar oder ihr schreibt uns auf Masadon, Blue Sky, Instagram, LinkedIn, wo auch immer ihr uns findet. Youtube Kommentare lesen wir auch gerne mit. Spotify Kommentare antworten wir auch alles. Und ansonsten bleibt uns nicht viel zu sagen, außer bis bald und wir hören uns in spätestens 2 Wochen wieder. Tschau, tschau. Tschau. Tschau.