Deep Dive 168 –
Low Code mit Till Schneider & Tobias Müller
13.12.2024
- // Podcast
- // Deep Dive 168
Shownotes
Die meisten Entwickler:innen schreiben gerne Code. Aber muss das wirklich immer sein? Und ist das in jedem Szenario wirklich sinnvoll?
In dieser Episode sprechen Garrelt und Jan mit Till und Tobias, den Köpfen hinter memoro.ai, über ihre Erfahrung mit Low-Code-Tools zur App-Entwicklung. Till und Tobias haben im Rahmen eines Hackathons die Idee für die Code-Minimierung entwickelt und anschließend ohne konventionelle Entwicklungsarbeit umgesetzt. Ein Beweis, dass man auch mit Low-Code-Tools moderne Apps an Endkund:innen ausliefern kann.
Wir unterhalten uns über die Erfahrungen, die sie auf ihrer Reise gemacht haben: Von der Auswahl der richtigen Tools über den Einstieg und die Lernkurve bis hin zur Kollaboration zwischen Entwickler:innen und Designer:innen erforschen wir alle Facetten des Projektes.
Aber wir beleuchten auch, wann und wie ein solcher Ansatz an seine Grenzen stoßen kann. Wir fragen uns, ob das unausweichlich ist und wie am besten damit umgegangen werden sollte. Außerdem stellen wir die alles entscheidende Frage: Können Till und Tobias den Ansatz wirklich empfehlen und würden sie es nochmal genauso machen?
/transkript/programmierbar/deep-dive-168-low-code-mit-till-schneider-tobias-mueller
- Jan
- Hallo und herzlich willkommen zu einem neuen Deepdive in der programmier.bar. Heute mit einem ganz besonders spannenden Thema, nämlich einem Thema, was immer die Gemüter spaltet. Wir sprechen einmal über No Code beziehungsweise Low Code Lösungen. Und mit mir im virtuellen Studio in der unteren rechten Ecke meines Screens sitzt der Garelt. Hi, Garelt. Hi. Garelt, wie oft hast Du schon mit so Low Code und Low Code Lösungen gearbeitet?
- Garrelt
- Oh, wir hatten das in der Schule. Da hatten wir was zum Zusammenklicken, das hieß Scratch. Da hab ich ein megageiles Spiel gemacht, hab eine Eins bekommen und meine Schülerkameraden haben auch eine Eins bekommen für Trash Spiele, aber na ja, ist nicht mein Ding.
- Jan
- Die Zuhörerinnen da draußen, die jetzt nicht sehen, wie jung Du noch aussiehst, fragen sich natürlich, wann warst Du in der Schule und hast Scratch programmiert? Wie lang ist das her?
- Garrelt
- Das war zweitausendvierzehn, also genau zehn Jahre.
- Jan
- Zweitausendvierzehn. Zweitausendvierzehn hatt ich schon meinen Uniabschluss in der Tasche, dementsprechend länger ist mein Informatikunterricht auch schon her, ja. Aber bei mir gab's keinen Low Code in der Schule. So Fernsehsieg gab's damals noch nicht, ja. Wir haben mit Tobi Pascal und c irgendwie programmiert. Und weil ich dementsprechend ganz wenig Ahnung von Low Code und No Code hab, sondern nur viel Meinung dazu, haben wir uns noch Leute eingeladen, die uns mit viel Wissen zur Seite stehen können. Wir haben hier Till und Tobias von Memoro. Hallo Till.
- Till Schneider
- Hi Jan.
- Jan
- Grüß dich. Hallo Tobias. Hi. Tobi passt übrigens. Tobi auch wunderbar, kein Thema. Ihr habt zusammen Memoro gemacht mit noch ein paar anderen Leuten. Vielleicht wollt ihr einmal ganz kurz erklären, was Memoro ist, wie ihr auf die Idee gekommen seid und dann sprechen wir einmal ans Eingemachte.
- Till Schneider
- Jawoll, gerne. Wir haben Memoro vor so eineinhalb Jahren circa gestartet auf 'nem Hackathon hier in Konstanz am Bodensee. Ich kam da mit der Idee die Ecke, dass ich doch gerne meine Gedanken und Gespräche aufnehmen will. Also ich hatte das Hauptproblem, dass ziemlich viel Projekte parallel liefen und ich nicht hinterherkam irgendwie mit der Organisation, mit der Strukturierung von allem. Und dann hab ich mir so angewöhnt, abends 'n Spaziergang zu machen und das einfach so mir von der Seele zu reden. Und dann hab ich das mal getestet, aufm iPhone einfach Sprachnotiz aufgenommen, Sprachnotiz hochgeladen, transkribieren lassen, das dann in Chat GPT reinkopiert und in Sachen gefragt über den Text. Und das kam mir gleich vor wie sone kleine Superkraft, weil man sich selber halt supergut reflektiert bekommt und und recht unstrukturiert reden kann und strukturiert das Ganze zurückbekommt und halt son Überblick bekommt. Also es war wie son 'n kleiner kleiner seelischer Doktor, kann man fast sagen. Jemand, der mir dann zuhört und dann konnte man sich einfach son bisschen entleeren. Und das hat sich einfach so toll angefühlt, dass ich das dann vorgestellt habe auf dem Heck gefahren, als einfach nur eine eine grobe Idee. Und dann hat sich direkt 'n Team aus fünf, sechs Leuten eigentlich die Idee formiert und wir haben zwei Tage lang gebrainstormt. Wir haben sehr viel waren sehr viel spazieren, haben sehr viel geredet, das ist natürlich alles direkt aufgenommen und hatten dann eigentlich 'n super Startschuss rein in die in das neue Start-up, da wir diese ganzen Gespräche festgehalten haben und direkt wussten, was wo wir hinwollen. Und Tobi war auch direkt von Anfang an dabei und wir zwei haben dann tatsächlich direkt gestartet. Wir sind das Kernteam, wir haben angefangen zu entwickeln, die anderen unterstützen son bisschen. Und wir hatten dann nach zwei Wochen eigentlich einen einen eine Alpha und haben die verteilt an Leute, haben die Menschen in die Hand gedrückt und haben gefragt, wie sie das Tool gerne nutzen könnten. Und dann kamen sehr viele Anfragen aus verschiedenen Industrien, aus verschiedenen Branchen, die 'n großen Mehrwert daran sehen. Und heute sind wir jetzt bei tausenddreihundert Nutzern, haben auch Paying Subscriber schon und haben 'n Stipendium gewonnen, was uns 'n Jahr lang finanziert und haben auch sehr viel Platz und Raum, uns mit neuer KI Technologie grundsätzlich auseinanderzusetzen.
- Jan
- Das, was Du jetzt natürlich nur so halb implizit gesagt hast, ist, dass ihr natürlich Memoro komplett mit Low Code No Code Toolchain gebaut habt, sozusagen, ja? Ja, genau. Darüber wollen wir einmal einmal sprechen. Deswegen meine erste Frage vielleicht so an Tobi. Was macht man als Entwickler in soner No Code Low Code Bude? So wird wird man da überhaupt gebraucht Fragezeichen,
- Tobias Müller
- ne? Tatsächlich ist es gar nicht so gar nicht so falsch, weil auch als Coder überlegt man sich, wie kommt man schnell zu Ziel? Und ich komm auch son bisschen ausm Start up Bereich oder auf Hecertons. Und da muss alles immer schnell gehen. Und da braucht man natürlich das das Verständnis für Code, wie Programme aufgebaut sind. Aber es hilft einem unglaublich, mit sonem No Code Low Code Bilder einfach mal schnell 'n Prototypen zusammenzuklicken. Und da das ergänzt sich, find ich, super. Das ist gar kein Widerspruch zueinander.
- Garrelt
- Würdest Du sagen, man ist mit Low Code, mit dem Zusammenklicken wirklich schneller, wenn man gleich gut das auch entwickeln könnte? Einfach vom Speed her, wenn man beides gut kann.
- Tobias Müller
- Man muss 'n bisschen differenzieren zu früh und heute. Heute hat man KI. Da ist vielleicht tatsächlich son bisschen die Überlegung, hat man mit 'ner KI vielleicht schneller mal 'n Projekt initiiert und schnell mal 'n Code druntergeschrieben, grade wenn's 'n bisschen was Spezielleres ist. Aber allgemein, wenn man einfach mal nur was darstellen will, das heißt ja so schön, Dann dann kann man einfach mal schnell 'n Gefühl dafür bekommen und auch einfach mal einfache Logiken damit umsetzen, keine Ahnung, Kalkulation oder irgendwelche Sachen zu generieren und so weiter. Und vielleicht schreibt man dann durchaus auch mal 'n Kostencode. Aber da geht's halt alles wirklich Geschwindigkeit. Im Hackathon hat man nicht viel Zeit.
- Till Schneider
- Was ich dann noch ergänzen könnte vielleicht, und das war eigentlich so auch, das, wir hätten gar nicht, ich hätte nicht anfangen können, Tobi zu helfen, wenn wir nicht mit Low Code, Low Code gestartet wären. Also ich bin vom Designhintergrund und gut, ich hab mal bisschen Tailwind HTML CSS son bisschen rumgewurstelt, aber ich hatte dadurch halt die Möglichkeit, superschnell das Frontend zu iterieren. Und wir haben dann im Endeffekt innerhalb von, was war's, 'nem Jahr oder hatten wir über vierhundert Versionsnummern durchgeschoben und da hat sich auch in jeder was geändert. Also da war dann 'n ordentlicher Druck im Kessel und now 2 be im wir haben mehr aufs mehr im Backend und guckt, dass das Zeug sauber funktioniert, hat dann ja in Python das Backend geschrieben, also Backend nicht nicht Low Cop, No Code. Wir haben mal Tests gemacht mit mit anderen Tools auch und haben kleine kleine Backends Low Carb, No Code technisch aufgebaut. Aber sonst hätt die Zusammenarbeit mit uns gar nicht, wir hätten gar nicht starten können, hätten wir den Stack nicht gewählt.
- Jan
- Genau. Vielleicht machen wir da noch mal zweieinhalb Schritte zurück. Jetzt warst Du schon bei den vierhundert Versionen, die ihr da irgendwie durchgeschippt habt. Aber bevor ihr angefangen habt, also ihr hattet, ne, über das Thema son bisschen gesprochen, ihr hattet irgendwie 'n grobes Konzept. So weit sind ja, ich sag mal, Codeentwicklung und No Code Entwicklung sich ja auch gleich und ähnlich, ja. Erst mal muss man darüber sprechen, was man so baut, bevor man anfängt, das hilft. Und dann wollt ihr irgendwann anfangen. Wie habt ihr euch denn für ein spezielles Tool entschieden? Weil also alle Entwickler kennen ja diese Diskussion, Du willst jetzt was bauen. Da ist erst mal die wichtigste Diskussion vorher so, was ist der Stack, was ist die Sprache, was ist das Framework, ja? Gab es da auch ähnliche Diskussionen so in diesem No Code Bereich, wo man sich überlegt, na ja, es gibt da halt zig verschiedene Tools da draußen, ja? Also wenn man einfach nur mal No Code oder Low Code googelt, da wird man ja jetzt zugeschüttet mit irgendwie Plattformen, die einem da was anbieten wollen und verschiedenen Wändern und basierend auf verschiedenen Technologien. Und wie habt ihr euch da überhaupt erst mal durchnavigiert, euch für eines von diesen Zehntausenden zu entscheiden? Und und was waren da ausschlaggebende Faktoren?
- Tobias Müller
- Was ich mal sagen kann dazu, ist, dass es auf jeden Fall Reibungspunkte auch da schon am Anfang gab. Weil ich als Entwickler hab natürlich meine Tools, die ich schon kennengelernt hab und so weiter. Und dann bleib ich natürlich auch gerne aus Gemütlichkeit bei dem, was ich schon kenne. Till war da schon deutlich offener am Anfang. Er guckt sich gerne aktuelle Berichte an, über was was für neue IDs es gibt, welche neuen Frameworks und so weiter. Er ist da deutlich offener, 'n bisschen weniger voreingenommen, würd ich sagen. Und da haben wir schon am Anfang auch schon angefangen zu diskutieren. Ja, und irgendwie kamen wir dann auf Flatterflow. Ich weiß gar nicht mehr so genau, wie's dazu kam. Weißt Du's noch, Tür?
- Till Schneider
- Ich glaube, wir hatten einfach verschiedene Test Testberichte gelesen. Ich bin 'n großer Youtube Videoanker und da verschiedenste Vergleiche mir reingezogen. Und ja, Flatterflow ordnet sich da einfach am Ende am am am am Ende zu Code eigentlich ein von den Low Code Tools. Also man kann sehr viel Custom Code mit einbauen und das das Tool eigentlich mehr und mehr erweitern. Und die anderen Low Code No Code Tools sind da eher noch mehr Low Code No Code, sag ich mal. Also wir haben uns dann so für diesen für für für das Komplexeste entschieden, was es gibt, haben dann auch geschaut, wo gibt's eine gute Community? Wo wo kann man Fragen stellen? Wo wird wo werden Features geschipped? Natürlich son bisschen, was ist der was ist grade heiß am Markt auch, aber was existiert auch schon länger? Also wir Flatterflor war damals schon 'n paar Jahre alt und und aufm Markt, heißt, auch da 'n bisschen auf die Langlebigkeit dann geschaut. Dann hat sich das so bisschen rauskristallisiert recht schnell eigentlich.
- Garrelt
- Aber Tobias, Du kannst aus nicht aus der Ecke Low Code, No Codes. Dein Setup vorher war reiner Code.
- Tobias Müller
- Also ich für mich selbst hab bisher weniger mit Low Code, No Code gearbeitet, klar. Und so weiter. Schon ein bisschen welche SDKs Frameworks kannst Du nutzen, wirklich 'n schnelles Ergebnis zu erzielen. Aber wirklich eingesetzt hatt ich's bisher dann noch weniger. Deswegen war jetzt halt auch son bisschen die die Diskussion, wo steigen wir ein? Und der große Punkt war, wie Till schon sagte, wie kann er halt auch mitentwickeln? Weil wenn wir jetzt wirklich mit Code anfangen, wird's halt schwierig. Und wir hatten dann auch getestet und angeschaut, inwieweit sind wir eingeschränkt? Wie viel Freiheiten haben wir? Und mit florida Flow war halt auch eben dies diese Möglichkeit, trotzdem noch eigenen Code einzufügen, was für uns auch notwendig war.
- Jan
- Das ist ja 'n spannender Punkt. Also wenn ihr relativ früh schon erkannt habt, okay, ist es halt notwendig, da auch Custom Logik oder UI Elementter oder so was zu machen. Wie lange ging es denn gut mit nur den Onboard Tools, ja, in eurem Prototyping, Bootstrapping Prozess? Und wann war so das erste Mal, wo ihr gesagt habt, okay, jetzt müssen wir mal hier Ärmel hochkrempeln und mal was Eigenes noch dazu bauen?
- Tobias Müller
- Eigentlich ging das ziemlich schnell, weil 'n Kerninhalt von unserer App ist halt die Audioaufnahme. Und Floodderflow bietet schon einen einfachen Recorder, aber sehr eingeschränkt. Also großes Kriterium ist bei uns, dass man's halt wirklich das Handy aufn Tisch legen kann und ohne drüber nachzudenken aufnehmen lassen kann. Und da darf halt die App nicht ins Sleep Mode gehen. Die der Screen muss gesperrt werden können. Und da muss man halt die Anforderungen von der jeweiligen Plattform erfüllen können. Dieser einfache Recorder, der hat dafür nicht ausgereicht. Das heißt, wir haben sehr schnell damit angefangen, wirklich den Recorder selbst zu implementieren.
- Jan
- Und was war das fürn Erlebnis? Also wie wie sehr arbeitet man da mit oder gegen die Plattform, wenn man dann da eigene Komponenten einbauen möchte?
- Tobias Müller
- Das war schon teilweise recht anstrengend. Man hat schon schmerzhafte Einschränkungen, würd ich sagen. Man hat halt wirklich nur, wie soll ich sagen? Man man kann Custom Actions, Custom Functions, Custom Widgets anlegen, aber man bewegt sich halt dann immer nur in einem Codebereich. Wenn man dann eben Sachen in die App integrieren muss, vielleicht direkt schon beim beim Starten der App mit initialisieren wird, dann wird's eben komplex und manchmal muss man dann auch Workaruns suchen. Wie kriegt man eben das integriert ohne diese Freiheiten? Wobei natürlich, man muss auch noch ergänzen, man könnte durchaus den Code verändern, aber dann wird's noch mal komplizierter.
- Garrelt
- Mhm.
- Jan
- Jetzt ist ja so auf Funktionalitätsebene das eine, aber auf Designebene ist ja das andere, ne. Also ich stell mir vor, wenn man da in sonem grafischen Editor arbeitet und sich da seine Elemente zusammenklickt, dann kommt man Till ja vielleicht auch relativ schnell an so dem Punkt so, das ist jetzt nicht so ganz Pixelperfekt, wie ich's eigentlich gerne hätte oder wie's in unserem Designentwurf aussah? Und gab es da auch Punkte, wo man da irgendwann so die die Edge Cases des Editors erreicht hat, sag ich mal und sich dann was anderes einfallen lassen muss?
- Till Schneider
- Würd ich nicht sagen. Also ich hab am Anfang noch angefangen, alles in Figma zu designen und wie die UI und UX da zu planen. Und dann war es auch son schleichender Prozess, dass dass halt Flatterflow im Grunde genommen so schnell funktioniert, dass ich eigentlich weniger und weniger die Sachen in Figma vorgescatcht hab und angefangen hab, wieder eigentlich direkt in Flatterflow Dinge auszuprobieren. Ist son schmaler Grat. Also manchmal hab ich's damals bereut, die Sachen nicht besser geplant zu haben in Figma. Manchmal war's eine gute Entscheidung, also da son bisschen der Mittelweg. Aber ich kam nie, also doch an ein, zwei Stellen, aber da würd ich sagen, also sehr, es gibt es gab dann gewisse Bereiche, die doch nicht funktioniert haben. Zum Beispiel wollt ich eine eine Liste am unteren Ende des Bildschirms haben und wenn auf die Liste getippt wird, sollte sie hochfahren und dann den ganzen Screen ausfüllen. Also quasi so wie eine Page Navigation, aber halt auf auf eigentlich in einer Seite contained, ging nicht. Solche Sachen wie wie Blur, haben Blurview, also auf iOS kennt man das ja, dass dann der der der Header zum Beispiel so so diesen, ja, ja, diese diesen Blur bekommt. Den konnte man nicht schön umsetzen beziehungsweise dann hat Flatterflow irgendwie im im Preview Mode dann rumgesponnen und wurde langsamer, wurde irgendwie slackgisch. Das gab's bei 'n paar Punkten, wo man wo man so, wenn man Sachen bauen will im Frontend, dass auch Flatter Flow es nicht mehr richtig gut handeln kann und man, ja, man eigentlich dann Abstriche machen muss. Was an sich okay war, glaub ich, weil im Grunde genommen sind halt die die Patterns, die User gewohnt sind, recht gut dargestellt darin. Und wenn man dann eigentlich an diese Grenzen kommt, sollte man sich vielleicht eher überlegen, ob das auch kein kein gewohntes Pattern ist, was man vielleicht auch anders bauen könnte.
- Jan
- Wie ist es denn in der in der täglichen Arbeit? Weil im Prinzip fahrt ihr ja zweigleisig, also oder auf zwei Ebenen, ne. Die die unterste Ebene ist das Betriebssystem iOS, Android, auf was auch immer ihr so deployed. Das verändert sich ja auch. Da kommen neue Versionen, neue Sales, neue raus. Und dann zwischen euch und dem Betriebssystem ist da diese Plattform, die es ja wahrscheinlich auch jetzt geändert hat so in der Zeit, in der ihr sie benutzt, ja auch mit mit neuen Features, mit neuen Funktionen, neue Widgets vielleicht out of the box bereitstellt oder so was. Was was macht es so mit dem Erlebnis?
- Tobias Müller
- Das hat aber auf jeden Fall dazu geführt, dass wir öfters mal zu plötzlich Errors hatten, die wir vorher nicht hatten. Und nach dem Debugging hat sich raus rausgestellt, okay, jetzt haben sich Dependencies geändert. Doch das ist son Beispiel gewesen. Entweder hat dann halt Flatterflow Updates gezogen oder ich hab dann irgendwie eine Dependency reingemacht, die halt auch nicht mehr mit 'ner anderen Version kompatibel war. Das war so 'n Problem, über das wir öfters gestolpert sind, was dann auch natürlich 'n bisschen frustrierend war, erst mal überhaupt rauszufinden, was ist denn da jetzt passiert? Auch von Android Seite gab's mal eine Änderung, dass man zusätzlich permissions grad mit dieser Backgroundaufnahme noch hinzufügen musste. Auch das war eine längere Recherche, dann wieder rauszufinden, okay, hier müssen wieder zusätzliche Angaben zu machen. Ja, da haben wir auf jeden Fall oder hab ich auch viel Zeit mit verbringen müssen mit dem Debugging, mit dem Recherchieren.
- Jan
- Mhm. Und was bringt denn sone Low Code Lösung am Ende alles mit? Also wir haben jetzt viel, ne, über so grafische Editoren für das Interface gesprochen und auf und Komponentenebene, die man selber bauen kann. Aber zu soner richtigen in Anführungszeichen App gehört ja oftmals noch viel mehr dazu, ne. Insbesondere wenn's irgendwie was kommerzielles ist, da braucht man irgendwie Usermanagement, da braucht man 'n 'n Payment oder Billing vielleicht auch, ja. Da braucht man irgendwie eine Art von Storage, die da dranhängen muss. Ihr habt schon über eure Aufnahmen gesprochen. Die werden ja auch irgendwo aufgerufen werden müssen. Ihr macht Transkcription, das wird irgendwo gemacht. Wie viel davon kann ich so alles in meinem Sandkasten machen? Und was muss ich selber extern zur Verfügung stellen? Und wie krieg ich das dann am Ende connected?
- Tobias Müller
- Ich glaube eben mal allgemein zu dem Low Code No Code Thema. Das ist auch der große Vorteil, weswegen man vielleicht das wählen kann, weil den meisten Low Code No Code Tools eben solche Integration schon mit drin sind. Da braucht man sich eben nicht darüber Gedanken machen, wie mach ich die das Setup? Was muss ich da beachten und so weiter? Und das war eben jetzt auch speziell bei Flood oflow sehr angenehm, weil da zum Beispiel Firebase schon komplett integriert ist mit dem der der und Firestore als Datenbank. Und das hat auch noch weitere Sachen wie zum Beispiel Superbase. Klar, schon eine gewisse Einschränkung. Es ist jetzt nicht alles drin, aber super zum Durchstarten, kein größeres Set-up kann man hat man direkt, was man braucht.
- Till Schneider
- Und auch weitergehen noch in Richtung eben, wie bekomme ich dir die Sachen denn in die Appstores rein? Wie bekomme ich das auf Testflight oder in den Play Store, Betatrack? Das ist alles eigentlich schon recht gut eingebaut. Das ist dann 'n ziemlich viel händisches Set-up, bis man mal eben den den Apple Developer Profil und den Android Developer Profil sauber aufgesetzt hat und da die recht alles alle Formulare ausgefüllt hat, bis man da überhaupt mal was reinpushen kann. Aber das ist im Grunde genommen alles schon eingebaut und dann auch Revenue Cat zum Beispiel, Integration, die dann die Payments handeln und und eigentlich den die App Store und Play Store Payments dann an einer zentralen Stelle wieder verwalten. Da musste, glaube ich, Tobi dann schon noch 'n bisschen was quasi auf Datenbankseite nachziehen, dass das wieder, dass dass wir auch die Daten sauber behalten und und das sauber abbuchen können sozusagen. Aber tatsächlich ging das jetzt in Flatterflow, dass wir die App dahin gebracht haben, dass sie inklusive in App Payments und Abomodell und so weiter vollkommen in Flatterflow entstanden mit viel Customcode dann geschippt werden kann. Und aktuell ist das immer noch die Version, die im App Store live ist.
- Garrelt
- Es klingt ja schon nach ziemlich viel Funktionalität. Und als ich mir das mal auf der Seite angeguckt hab, wirkte flutterflow auch sehr mächtig und auch für mich fast schon überladen. Wie ist denn so eure Erfahrung? Wie schnell seid ihr da reingekommen? War viel intuitiv für euch? Musstet ihr diese Software erst mal lernen, zu also überhaupt erst mal was machen zu können oder findet man eigentlich alles sehr schnell, was man braucht?
- Tobias Müller
- Also wenn man jetzt eben von diesen Integrationen redet, wie man die nutzt, auch UI Elemente, wie man die platziert, einfache Klickfunktionen und so weiter, ist es, denk ich, schon sehr einfach. Sobald's dann aber 'n bisschen Logiken geht, so das typische f F ifs, Schleifen, also ich red jetzt grade eher 'n bisschen über die algorithmische Ebene, da ist es dann vielleicht nicht mehr so intuitiv. Da hilft's dann's durchaus, sich auch 'n paar Tutorials anzuschauen, sich mal 'n bisschen damit zu beschäftigen, grade wenn man vielleicht jetzt nicht so die Codingerfahrung hat.
- Till Schneider
- Auch vom Frontend her finde ich, es gibt eine gewisse Lernkurve. Also man es ist wirklich 'n Tool, was was in Richtung, man muss schon Experte sein geht. Es hilft, wenn man Verständnis hat von Atomic Design System und weiß, wie man Komponenten richtig anlegt, einfach eine Konsistenz auch zu halten, sonst läuft es schon schnell ausm Ruder. Also ich musste da auch im Frontend dann immer wieder quasi refactern und mir überlegen, okay, wie krieg ich das jetzt einiger bisschen sauberer noch hin, dass ich hier nicht auf jeder Seite eine einzelne Header Komponente hab, sondern eine zentrale und da mach ich das halt mit Variablen. Also man, es wird schon recht schnell komplex. Also man braucht 'n gewisses Grundverständnis dafür. Und ich würde sagen, von den No No No No Go Tools eben hat es eine eine relativ steile Lernkurve.
- Jan
- Und wie habt ihr euch da geholfen? Also wie wie habt ihr diese Lernkurve gemeistert?
- Till Schneider
- Also in meinem Fall ist es tatsächlich Youtube Tutorials angucken. Flatterflow hat 'n supereigenen Channel, wo sie gute, auch lange Tutorials haben, wo sie mal eine ganze Applikation bauen. Oder sie haben solche solche Webinare, wo sie zusammen sich zusammenschalten und bisschen über Themen reden. Es war aber tatsächlich 'n extremes Gesuch. Also wir haben dann so zwei, drei Stunden lange Webinare und ich habe einen Fehler. Und der Fehler ist dann bei Minute dreiundfünfzig, wo sie genau darüber reden und erklären, dass das ja grad 'n Fehler ist in ihrer Software. Und man muss gucken, da muss man das so umbauen. Also es war schon oft son bisschen das Suchen nach der Nadel im Heuhaufen.
- Tobias Müller
- Also man merkt auch schon, es ist eine Community da, vermutlich auch größer wie bei anderen Tools, aber sie ist doch noch am Aufbauen. Also grad wenn's dann speziellere Dinge geht, ist es schon 'n bisschen an Gesuche und auch 'n bisschen mit Glück verbunden, ob denn tatsächlich schon mal jemand diese Frage überhaupt gestellt hat.
- Till Schneider
- Und und was ich noch ergänzen will, ist, dass wirklich diese diese zusätzliche Ebene, Abstraktionsebene, die halt Flatterflow noch mal auf Flatter draufsetzt, halt auch zu zu Problemen führt. Dann weiß man nie genau Und und auch die Flatterflow Community weiß nicht, ist das jetzt 'n Flatter Error oder entsteht das jetzt durch die Flatterflow Abstraktion noch mal, ist da der Fehler und es sorgt schon zu noch mehr Reibungen.
- Garrelt
- Aber die Community, mit der da im Austausch war, war schon auch die Flatter Community oder ist diese Flatterflow Community arg getrennt?
- Till Schneider
- Nur, Flatterflow hat selber eine Community, also auf Community, glaub ich, Punkt Flatterflow Punkt com oder wie auch immer die URL ist, gibt's eine eigene Community, die auch recht stark ist. Da gibt's 'n paar sehr, sehr tolle Members, die auch sofort antworten, die schnell antworten. Und wir haben uns dann, also ich mich fürs Frontend her, meistens darin bewegt. Tobi musste, glaub ich, noch öfters dann auch in auf die Flatterebene wechseln, gewisse Dinge zu verstehen oder zu debuggen.
- Garrelt
- Ich frag mich schon die ganze Zeit, also Till, Du sagst ja, Du kommst eher aus dem Design Background. Tobias, Du wärst so im Dev Background. Wie gut oder wie habt ihr euch so aufgeteilt aufgabentechnisch? Hat das gut funktioniert? Auch auch eine Frage in meinem Kopf ist, wie hat das mit Version Control funktioniert, weil das manchmal bei so Tools, glaub ich, 'n bisschen komplizierter sein kann. Und ich glaube, in meinem Kopf ist son Tool ja megastark, was so Design- und Entwicklungszusammenarbeit geht. So, was was sind da eure Erfahrungen? Was hat da gut funktioniert, was vielleicht nicht so gut?
- Tobias Müller
- Also flatterflow bietet schon eine git ähnliches Brunching mit ja, auch eine Versionskontrolle, aber die hat uns eigentlich nicht so wirklich geholfen. Meistens war eher der Prozessor. Till hat was eben UI mäßig umgesetzt, irgendwelche Elemente. Und nach ihm bin ich dann ran und hab irgendwelche Logiken dann dazu noch implementiert. Also es war schon irgendwie 'n getrenntes Arbeiten, da wir aber mehrere Baustellen hatten, hatten wir uns dann halt schon auch irgendwo aufgesplittet. Es war halt, das ist auch ein ein großes Problem, was wir eben auch mit Flatterflow hatten, son Bug könnte man sagen. Sobald man parallel auf einer Seite gearbeitet hat, was man theoretisch machen könnte, hat es oft dazu geführt, dass einfach Änderungen verschwinden sind. Till hat irgendwas gemacht, ich hab dann was eingefügt, dann
- Garrelt
- geh ich
- Tobias Müller
- in den Testmode und plötzlich ist es nicht mehr da. Und das war auch schon sehr frustrierend. Deswegen war dann einfach die Konsequenz, okay, wir müssen das halt etappenweise
- Garrelt
- machen. Also fast mehr Absprache nötig als sonst.
- Tobias Müller
- Genau, auf jeden Fall.
- Garrelt
- Ja. Und Till, Du konntest aber ohne viel Entwicklungs, nee, das weiß gar nicht, wie viel Entwicklungserfahrung hattest Du denn vorher? Oder bist Du da einfach wirklich aus dem reinen Designbackground eingestiegen und konntest da Dinge entwickeln?
- Till Schneider
- Also ich hab einmal eine eine Designlibrary eben mit mit Tellwind HTML, CSS irgendwie geschrieben. Das so Grundverständnisse waren eben da jetzt übers Boxmodel oder wie grundsätzlich die die die Dinge in in Code übersetzt werden. Aber tatsächlich war es dann doch eine recht steile Lernkurve eben noch mal eben viel, viel Tutorials angucken, dass man weiß, wie sich halt der flatterflow wieder verhält. Also ich wär dann wahrscheinlich schneller gewesen, hätt ich's dann in in mit irgendwie schreiben können. Ging an der Stelle aber nicht, weil andere Sachen wieder nicht gegangen wären. Und tatsächlich diese die Grenzen waren dann recht fließend. Also ich konnte dann halt auch über dieses dieses son System, wo man quasi die die Action Blocks dann einfügen kann, die irgendwelche Dinge triggern, wie zum Beispiel haptisches Feedback. Das waren für mich halt dann zwei Klicks, ein neue Note anlegen, sagen hier, haptisches Feedback auf, wenn der Button gedrückt wird. Und dann hat kann ich das supereinfach auch bewerkstelligen. Das wär auf Codebene dann wieder deutlich komplizierter gewesen, beziehungsweise hätt ich wahrscheinlich noch mehr Fehler gemacht. Also da konnte ich mich dann mehr Richtung Tobi auch arbeiten, sag ich mal, von der von der Funktionalität her. Auch Stück für Stück hab ich mich auch sicherer gefühlt, wie wie mach ich eine eine Firebase Datenbankabfrage und so weiter und so fort, weil der Flatterflow einfach das schon relativ verständlich macht für den Nutzer.
- Jan
- Das wär jetzt meine nächste Frage gewesen. Also selbst wenn Du dann durch diverse Tutorials und und so dich in dem Editor irgendwie wohlfühlst, musst Du ja trotzdem am Ende noch über kurz oder lang andere Services integrieren, sei es euer eigenes Firebase oder vielleicht habt ihr auch noch andere Services angebunden, keine Ahnung. Und wie schafft das denn son Tool an der Stelle, da sone Translation hinzubekommen zwischen, na ja, na ja, Du machst dir zwar eine Datenbankabfrage und da kommt irgend 'n 'n JSON Objekt vielleicht zurück am Ende des Tages. Aber wie sagt man dann, okay, und jetzt von diesem JSON Notizenobjekt hier an dieser Stelle den Titel anzeigen und hier den Inhalt und hier vielleicht, ne, also also wie wie ist dieser Connect so?
- Tobias Müller
- Ich glaub, da hat sich dann auch schnell gezeigt, wo so Grenzen dann liegen, was was trotzdem aber möglich ist. Einfache Updates, Datenbankabfragen und so weiter. Da kam Till auch super mit klar. Ich glaub, da braucht man nicht wirklich das Coding Verständnis, wenn's aber dann drum geht, wirklich mal Daten zu extrahieren, mehrere multiple Datensätze zu verändern oder auch in der UI ja berechnen und so weiter zu machen. Da musste ich dann schon einschreiten. Das ist nämlich auch flatterflow möglich, aber da gehört dann halt wirklich auch das Verständnis 'n bisschen dazu.
- Jan
- Und wie habt ihr euer euer Backend dazu gebaut? Weil ich nehm mal an, das macht man ja nicht in flatterflow.
- Garrelt
- Genau. Also wir hatten ja jetzt erst
- Tobias Müller
- mal über die Integration von Feuilleton zum Beispiel geredet. Jetzt kommt eben der Punkt unsere Verarbeitung bei Memoro, unsere unsere Prozesse, wie wir das natürlich aufgearbeitet ausgeben, das liegt alles an 'nem Backend. Und auch da bietet eigentlich Flatterflow 'n guten zentralen Punkt, wo man einfach seine Backend Route einfügt, seine Restcalls definiert und die dann auch als Action abfeuern kann. Aber auch da gibt's dann halt wiederum Limitierungen. Wir hatten jetzt Glück, dass wir jetzt da backend rotemäßig nicht nur hohe Komplexität haben, aber wir waren jetzt trotzdem auf ein back End eingegrenzt. Wir konnten so was wie On Preme und so weiter nicht umsetzen damit.
- Garrelt
- Was ich
- Till Schneider
- vielleicht noch ergänzen will an der Stelle, im Bezug auf die Datenbankabfragen, ist es son bisschen auch eine Blackbox gewesen. Also wir hatten dann im Endeffekt das Problem, dass wir in den Memory Leak reingelaufen sind und mussten dann ewig lang debuggen, woran liegt es? Wir haben's dann auch so halb rausgefunden, aber dann wieder doch nicht. Also es war irgendwie der Timer, den mussten wir dann Custom nachbauen, damit es besser funktioniert. Also drückst Aufnahme starten und dann zählt 'n Timer hoch und irgendwie der eingebaute Timer von Flatterflow hat diesen Memoryleak wohl verursacht, aber es war dann doch nicht, das war das Hauptproblem, aber da war noch mal 'n tiefer liegendes Problem und wir kamen da partout nicht dahinter. Und das war hat mich dann auch sehr verrückt gemacht. Ich als quasi, ich nutze Memoro am meisten, ich kipp da wirklich alles rein, ich nenn mein ganzes Leben damit auf. Ich find, das sind ganz essenzielle Metadaten. Da kann man ja dann irgendwann eine schöne eine KI mit personalisieren. Hatte dann die Probleme, dass das unglaublich langsam würde, die Oberfläche. Und ich hab jetzt im Verlauf von der Entwicklung von Nimuru, glaube ich, vier- oder fünfmal meinen Account gewechselt, weil einfach das das Ding so voll war, dass es dass es nicht mehr performant lief. Und wir hatten, wir wussten aber, es gibt eigentlich keine Lösung dafür. Wir haben ewig lange Schleifen gedreht in der Community, haben versucht, das rauszufinden, kamen dann halt aber zu der Erkenntnis, hey, wenn wir uns angucken, wie wie viel der Durchschnittsnutzer Memos hat, merkt er das Problem gar nicht. Also machen wir uns jetzt deswegen verrückt oder schieben wir das Problem vor uns her? Und wir waren dann an 'nem gewissen Punkt, war uns klar, okay, wir sollten den den den den Stack wechseln. Wir brauchen die Kontrolle über den ganzen Stack und dann haben wir dieses Thema einfach vertagt. Aber das hat uns sehr, sehr viele Bauchschmerzen bereitet.
- Jan
- Jetzt sprichst sprichst schon 'n wichtigen Punkt an so, diese Frage nach, ne, wann entwächst man halt so diesem Tool und wann muss man sich den Stack noch mal irgendwie grundlegend Gedanken machen. War das für euch von vornherein klar, dass ihr sagt, na gut, wir starten hier mit diesem No Code No Code Thema, einfach schnell sein zu können? Aber irgendwann werden wir's irgendwie selber bauen müssen, wenn alles gut läuft. Oder war eigentlich die Annahme, na ja, wir bauen das jetzt hier mit 'ner Flatterflow oder irgend 'nem anderen Tool und das kann uns auch bis zu den ersten zehn Millionen Usern tragen?
- Tobias Müller
- Ich glaub, gestartet sind wir schon 'n bisschen mit der Einstellung, dass wir das jetzt mal unlimitiert nutzen können. Natürlich trotzdem mit der Ungewissheit, welche Anforderungen wir noch haben werden. Wir haben aber auch schnell dann gemerkt, wir haben wirklich 'n Problem mit dem Faktor Zeit. Am Anfang eben diese diese Geschwindigkeiten, mit der uns wir uns bewegen, hat uns unglaublich geboostet. Wir konnten schnell iterieren. Wie Thuill schon sagte, unsere vierhundert Versionen, die wir da hatten, konnten direkt auf Feedback eingehen, konnten Sachen testen. Das hat uns sehr viel Geschwindigkeit gegeben, aber wir haben dann gemerkt, je komplexer das Projekt wurde, je größer hatten wir, je mehr hatten wir Probleme mit mit dem Thema Zeit ja bedingt durch. Zeiten, die teilweise bis zu zehn Minuten gingen, einfach nur, wenn man was in der UI ändert und hat dann eben dieses Hot Reload. Auch da sind die Zeiten bei so, keine Ahnung, eine halbe Minute. Und dann stimmt mal was nicht und man muss noch mal neu laden. Man will's aufm Device mal testen, ob da muss man dann wieder warten. Und Flatterflow, ja, kostet da halt leider viel Zeit. Und dann muss man halt irgendwann überlegen, ab welchem Punkt muss bringt man muss man zu viel Zeit für die Entwicklung aufbringen für diese Wartezeiten? Und wann wäre es es sinnvoller, eben auf 'ner anderen eigenen Stack zu wechseln?
- Till Schneider
- Wir hatten auch ein Problem. Wir haben ja die App dann direkt sehr mehrsprachig aufgebaut, also gleich vierundzwanzig Sprachen unterstützt von Anfang an. Da geht's eben auch drum, dass ausländische Fachkräfte ihr ihre Arbeit in ihrer Heimatsprache dokumentieren können per Sprache. Wir haben son bisschen son Speech to form System geschaffen dann in der App, da wir eben aus verschiedenen Industrien da Anfragen bekommen haben. Und da war einfach einen einen Bug in Flatterflow, dass ich hier die händisch oder ich ich hab einen Google Translate Button, der war erst mal super. Ich konnte oben die englische Sprache eintragen, dann hat er mir das übersetzt in die anderen dreiundzwanzig Sprachen. Erst mal war war da das Problem, dass Google Translate keinen Kontext mitgegeben bekommen hat. Also der wusste nicht, dass es eine UI Übersetzung hielt. Heißt, ich musste ganz viel dann, ich musste dann andere englische Wörter suchen, damit er besser versteht, dass es dass es sich eben eine App handelt. Das war schon 'n Krampf und dann gab's einfach einen Bug, dass er immer wieder die Übersetzung gelöscht hat. Und dann hatten wir sogar geschippte Versionen, wo dann wo er uns eine Seite, die wir überhaupt nicht angefasst hatten, wieder alle Übersetzungen zerschossen hat. Und da gab's, da haben wir auch eben Tickets für angelegt im in der Flatterfloor Community und und und. Kam aber nix. Also da gibt's, glaub ich, bis heute kein kein Fix dafür. Und wir hatten dann vermehrt genau dieses Problem der Hilflosigkeit eigentlich an der Stelle, wo wir wissen, okay, wenn wir das jetzt, hätten wir den Stack im Griff, könnten wir das lösen, aber wir können's grade nicht lösen. Und das waren dann so zwei, drei Baustellen und wo man dann mehr und mehr Bauchschmerzen bekommt und und dann halt eben die Zeit verliert. Weil auf einmal muss ich alle Seiten noch mal kontrollieren vor jedem Shipment und schauen, hey, ist da sind alle Übersetzungen drin. Also das ist genau der Punkt, Tobi meint so, diese die Zeit, am Anfang ging's unglaublich schnell und dann ging's unglaublich schnell unglaublich langsam.
- Tobias Müller
- Ja, und da haben wir halt schon früh gemerkt oder zu 'nem gewissen Punkt, wir müssen irgendwann den Absprung planen. Wir haben dann angepeilt, eine stabile Version zu haben, die wir in Ruhe lassen können. Und ab da dann eben zu sagen, okay, jetzt machen wir 'n Cut und jetzt wechseln wir auf unseren eigenen Stack. Also das haben wir schon früh angefangen zu planen.
- Garrelt
- Ja. Aber
- Jan
- das heißt ja natürlich oder vermutlich, in dem Fall ist das 'n kompletter, ne, weil son Tool wie Flatterflow sich wahrscheinlich nicht dafür anbietet zu sagen, wir machen hier son son hybrides Ding und ersetzen das so peu à peu vielleicht View by View oder Action by Action oder so was. Sondern Du musst im Prinzip, wie Du schon gesagt hast, ne, sone auch sone stabile Version mal kommen, die in Ruhe lassen und nebenbei dann im Prinzip komplett von vorne noch mal die ganze App bauen. Hat euch flutterfloda in irgend 'ner Art und Weise unterstützt? Also konntet ihr, weiß nicht, das Projekt, was ihr da hattet, exportieren und irgendwie dann im Code weiterbearbeiten? Oder habt ihr komplett auf der grünen Wiese angefangen? Wie wie läuft das? Oder habt ihr überhaupt schon angefangen oder plant ihr's grade nur? Vielleicht, das mal ganz vorne anzufangen.
- Tobias Müller
- Also also wir sind schon am Umbauen.
- Till Schneider
- Mhm.
- Tobias Müller
- Mhm. Also ich will nicht sagen, dass es nicht technisch möglich ist. Es ist durchaus technisch möglich, die Codebasis zu nehmen. Sobald man 'n Abo hat, hat man das Recht und kann man eben die die Codebasis nehmen und kann den Code auch selbst verändern. Aber dann kommt man, würd ich sagen, wirklich in Teufelsküche. Ich würde von abraten, weil dann noch mit wirklich der Flow Oberfläche noch Dinge zu verändern, fangt's an mit Merch Konflikten. Das geht So, nee,
- Jan
- dann hab ich's nämlich, glaub ich, falsch verstanden. Das ging mir nicht darum, parallel auch an der Codebase rumzuarbeiten, sondern die quasi zu nehmen und dann, also die Codebase einmal zu exportieren, flatterflow sozusagen abzuschalten, aber an der exportierten Codebase sozusagen weiterzuarbeiten einfach nur, ja? Dass man halt diesen Plattformlog in son bisschen umgehen kann.
- Tobias Müller
- Ja, okay. Ja gut, also prinzipiell gleiche Aussage, man hat den Code, man kann den nutzen, man könnte dann auch Vorurteile davon exportieren. Aber dadurch, dass halt flatterflow den Code selbst generiert und auch sein eigenes SDK dadrin nutzt, ist es, denke ich, nicht praktikabel. Also ich würde wirklich davon abraten, lieber die Logik, die dahintersteckt, nehmen und
- Garrelt
- aus der Logik die eigene App noch mal schreiben. Das geht ja
- Tobias Müller
- dann auch super mit KI heute. Da KI heute. Deine, Du schreibst deine Logik runter und sagst mir, erzeug mir daraus den Code. Viel effektiver als jetzt wirklich den Code da rauszuexrahin.
- Jan
- Aber das ist ja eigentlich 'n superwichtiges Learning, ne. Weil ich glaub, für ganz viele Leute ist so dieser Punkt, na ja, hab ich da 'n Plattformlog in oder kann ich am Ende meine App rausexportieren und mitnehmen?
- Garrelt
- Ja.
- Jan
- So, gibt ja gefühlte Sicherheit so eigentlich, ne, wenn Du damit anfängst. Und was Du jetzt ja eigentlich gesagt hast so durch die Blume ist, das hat eigentlich nichts wert, dieses Feature. Also es es gibt dir so sone gefühlte Sicherheit noch mit, aber 'n wirklich großen Nutzen außerhalb das zu retten, was Du hast, hast Du halt eigentlich nicht davon.
- Tobias Müller
- Ich ich kann mal kein Szenario vorstellen, wo das wirklich der Mehrwert größer wär als die Probleme, die man da durchkriegen würde.
- Till Schneider
- Ich würd das auch mal unter unter Marketing irgendwie verbuchen, weil wenn man wenn sich 'n Flatter Dev mal diesen Code anguckt, den man exportieren kann aus Flatterflow raus, dann wird der sagen, nee, nee, nee, wir müssen das so oder so komplett neu schreiben. Das entsteht halt aus aus diesem Low Code, No Code Ansatz, dass die halt das irgendwie zusammenschustern. Ich find da eine Parallele ganz spannend mit der Superbase, weil wir uns jetzt im im Sinne des auch damit beschäftigt haben, gehen wir auch aus diesem Log von Firebase raus. Und Superbase wirbt es ja ganz ähnlich an. Man kann da ja loslegen ganz einfach, aber sie sind ja Open Source und so weiter. Man kann es ja dann auch on prem hosten und selber hosten oder was auch immer. Ist halt dann aber doch nicht ganz der Fall, weil dieses ganze Tooling, was die Superbase so einfach macht, wenn man sie über deren Dienste nutzt, dann nicht mehr verfügbar ist. Und bei flut of floast, das würde ich sagen, noch extremer. Man vom Frontend her unglaublich wichtig, weil man konnte eben sehr viel Schleifen drehen. Das eine 'n Frontend nachzubauen geht verhältnismäßig einfach, es zu finden, ist ja das Schwierige. Also wo wo muss das Zeug hin? Wie wir deswegen, wir haben ganz schöne Screenshots von diesen vierhundert Versionsnummern und sehen genau, wie hat sich das verändert über die Zeit. Und dann haben wir eine eine gute Linie gefunden und die Linie jetzt nachzubauen, geht verhältnismäßig schnell dann. Aber ja, von der Codebasis, die mitzunehmen, nein. Und wir hatten ja nun dann auch eine Recherche gemacht und uns eigentlich auch gegen Flatter entschieden an der Stelle und haben auf REAC Native gesetzt.
- Jan
- Das ist jetzt noch mal 'n spannender Punkt, ne. Ich mein, jetzt habt ihr ja im Prinzip die ganze App schon mal in Flatter gebaut oder zumindest den Teil, den ihr custom gebaut gebaut habt davon, der ist ja vermutlich 'n Datenflatter gebaut in Flatterflow so, ja. Ja. Wieso seid ihr dann davon quasi weg, wo ihr dann Also da könnt ihr ja noch weniger recyceln, sag ich mal.
- Till Schneider
- Ja. Ja. Also ich finde da da auch lange lange recherchiert, mich reingefuchst irgendwie und die Es ist, glaub ich, relativ egal. Also es gibt in in Europa auch die größere Flatter Community. Ich kenn sehr viele Flatter Devs, die produktive Apps haben in Flatter gebaut. Und ich glaube, von der Größe der Community her, von der Menge der Packages her und dem Support her schenkt sich das wenig. Ich fand ich fand rig Native einfach deutlich interessanter, weil sie's jetzt erst, glaub ich, seit 'nem halben Jahr auch auch geschafft haben, aus einer zentralen Codebasis eine performante Web App hinzubekommen. Und Flatter, da es ja aus vom Canvas Model herkommt und eigentlich nicht aus der Webentwicklungsseite her, wird das wahrscheinlich nie schaffen, dass die wirklich performant wird, die Webseite. Wirklich eine Codebasis haben und damit auf alle Plattformen schippen können. Und da ist Reggnative meiner Ansicht nach jetzt 'n guten Schritt weiter plus Tobi und ich haben mehr Erfahrung von der vom Web Development Seite her. Deswegen fällt uns auch da die die, sag ich mal, die Sprache leichter. Es kommt kommt uns bekannter vor. Plus natürlich von Microsoft, Microsoft nutzt es immer mehr. Jetzt kam erst vor zwei, drei Wochen einen einen Riesenupdate. Wir haben eine neue neue Architektur geschipp, geschipped, weil Meta ist ja von Meta React auch in den in den Quests nutzt, also in ihren VR Headsets, das dort für die Oberfläche nutzt. Heißt, sie mussten extrem jetzt die Performance hochschrauben, dann Drop Frame in VR natürlich zu Motion Sickness führt und geht überhaupt nicht. Heißt, da ist einfach 'n megades Backing dahinter. Und vor allem, das war eigentlich der der entscheidende Punkt, man bekommt alle Plattformen performant bespielt.
- Jan
- Und als wie realistisch hat sich der Plan herausgestellt zu sagen, ihr habt eine stabile Version in Flatterflow, die ihr nicht mehr anfassen müsst. Und parallel arbeitet ihr quasi an dem an dem. Aber ich mein, das ist sone Situation, die haben wir da draußen, glaub ich, alle schon mal erlebt. Der hat's da also, hey, dieses alte Produkt fassen wir jetzt nicht mehr an. Und wir bauen hier einfach nebenbei das Neue. Ja. Und dann kommt halt doch irgendwie jemand die Ecke und sagt, könnt ihr können wir dich noch mal da eine Kleinigkeit ändern? Und da ist noch 'n Bug, der müsste irgendwie noch mal gemacht werden, weil bis das Neue kommt, dauert's irgendwie noch so lange. Und dann ist ja doch dieses Ziel, auf das man hinarbeitet, doch deutlich beweglicher, als man vorher gedacht hat, sag ich mal.
- Tobias Müller
- Ja, man muss die Sachen, glaub ich, einfach 'n bisschen runterschlucken und sich drauf fokussieren, dass man ja grade daran arbeitet. Weil dann hört man eben, ja hey, das und das geht nicht. Zu den Leuten, die eingeweiht sind, denen sagt man dann so, ja, das wissen wir. Die neue Version kommt bald. Zu den Externen sagt man, oh, vielen Dank, das nehmen wir uns zu Herzen, da arbeiten wir direkt dran. Also ja, wir arbeiten direkt dran, aber halt an 'ner komplett neuen App.
- Till Schneider
- Es war wirklich, dass wir's geschafft haben, die App noch an den Stand zu bekommen, an der sie jetzt ist. Und wir haben sie jetzt wirklich seit 'n paar Monaten nicht mehr angefasst. Und der letzte Schritt für uns war die Monetarisierung, dass wir dass wir's monetarisiert haben, dass die Leute da sich 'n Abo ziehen können. Diese letzte Versionsnummer war wirklich, also war wie im waren wir. Das, weil gefühlt ist ist uns mehr auseinandergefallen von jeder neuen Version, als dass es wieder funktioniert hat. Und es war wirklich, würd ich sagen, Glück, dass wir das noch mal rausgeschoben bekommen haben und es einfach auf 'nem guten Stand ist. Weil wie gesagt, Flatterflow auf einmal entschieden hat, hier, wir löschen euch Übersetzungen, wir löschen machen irgendwelche Hintergründe kaputt oder so. Das das war wirklich 'n Kampf dann am Ende gegen gegen gegen das Framework, sag ich mal.
- Tobias Müller
- Ja, es war es war, glaub ich, so gefühlt 'n bisschen Glück, dass wir genau jetzt zum wichtigen Zeitpunkt den Absprung geplant haben, weil's wirklich schlimm wurde jetzt.
- Till Schneider
- Ja, ja. Knappe Kiste. Okay.
- Jan
- Das forciert natürlich son bisschen die spannende Frage. Wenn ihr jetzt Memoro noch mal bauen würdet oder in ein paar Jahren ein anderes Start-up macht oder was auch immer, ein anderes Produkt im im selben Space, würdet ihr das noch mal genauso machen?
- Garrelt
- Zu Anfang drüber.
- Tobias Müller
- Ja, wir haben 'n bisschen differenzierte Meinung. Also mal allgemein find ich immer noch, ist valide. Für jemanden, der keine Codingerfahrung hat, eine eigene eine einfache App machen will, keine Ahnung, Du machst Schmuck und willst dann unbedingt auf eine App anbieten. Hey, dann, damit wirst Du glücklich, denk ich, mit flatterflow. Das wirst Du damit gut hinkriegen. Aber so was wie mit Moreo grade heute würd ich nicht mehr mit Flatterflow starten. Und genau, ich glaub, da kann ich Herrn Till übergeben zu seiner Meinung.
- Till Schneider
- Ich find das eine eine unglaublich spannende Frage, weil ich mach mir da viel Gedanken drüber, was wir denn jetzt eigentlich die letzten eineinhalb Jahre so gemacht haben und dann was wir so gearbeitet haben. Und vor allem haben wir uns, weil wir son kleines Team sind und eigentlich auch nicht das Budget haben, groß zu wachsen in dem Sinne. Und ich halte auch viel von organischem Wachstum, ich halte relativ wenig von riesenschnellen VC und wir sammeln viel Geld und wir machen hier. Das das find ich alles 'n bisschen eigentlich kontraproduktiv. Wir haben uns extrem drauf konzentriert, wie werden wir besser? Wie wie können wir noch schneller bauen? Also Tobi und ich, wie arbeiten wir besser zusammen und wie enhanzen wir uns noch mehr mit KI? Meine persönliche Meinung ist, ich würde nicht mehr mit Flatterflow starten, weil die Lernkurve eben so steil ist, dass meiner Ansicht nach heute, wenn man sich 'n Cursor nimmt oder 'n Windsurf nimmt, wenn man sich diese IDIs hernimmt, die wirklich gepimpt sind mit KI, man eigentlich schneller vom Fleck kommt. Und wir haben jetzt über die letzten drei, vier Monate, glaube ich, fünf, sechs, sieben neue Applikationen geschaffen, die alle in in 'ner guten Alphaphase sind, auch intern. Und wir haben unsere Webseite auch zum Beispiel, die jetzt mit NextJS und so, hab ich komplett mit mit Curcer damals komplett mit KI neu geschrieben und so. Das die liest die Marktdown Dateien aus, baut sich über Marktdown Dateien auf und so weiter und so fort. Man kann die dann recht einfach befüllen. Wir haben sehr viel experimentiert mit verschiedenen Sachen und ich glaube, es macht keinen Sinn mehr, diese Dependency und diese Probleme, die diese Dependencies eigentlich mit sich bringen, einzugehen. Man sollte mehr und mehr sich drauf konzentrieren, den Stack selber im Griff zu haben und grundsätzlich weniger Dependencies, weniger kleine Pakete für für irgendwelche kleinen Helferfunktionen und so weiter nutzen, sondern es die KI schreiben lassen. Und langsam sind die Tools, ich mein, die Zeit arbeitet da ja für uns und die das Tooling wird besser. Ich hab das Gefühl, die KI ist noch nicht so richtig in der Endanwendung angekommen, sondern es es passiert ganz viel im im Tooling, diese Tools zu bauen. Aber es ist 'n ganz neues Medium und wie bei jedem Mediumswechsel, die erste Fernsehsendungen, die liefen, da haben sie halt Radioshows abgefilmt, weil sie wussten ja auch nicht, was sie jetzt erfüllen sollen. Also man nimmt irgendwie so die alten Dinge auch noch mit, auch ausm UI Design und so weiter. Da hinken wir eigentlich hinterher, da gibt's extremes Innovationspotenzial. Meiner Ansicht nach hat hat AI 'n großes UX UI Problem eigentlich, wieder leere leere URL Zeile wie Anfänge des World Wide Webs und wir haben einfach wir haben einen unglaublichen Drang zu bauen. Also Tobi hat dann irgend eine Idee, wo er wo er sich 'n kleines Helfertool bauen will und baut es halt einfach. Und damals haben wir das noch in Bildship zusammengesetzt und und in in Flatterflow tatsächlich haben wir die ersten Prototypen gebaut und jetzt machen wir das einfach in Code. Und es geht meiner Ansicht nach schneller, aber wir wissen ja auch, dass das ist es heißt, es ist langfristiger. Wir haben den Stack im Griff und wir können dieses Tool jetzt mit anderen Tools verbinden. Und jetzt kommen Enterprise Customer und wollen das on prem haben oder unsere Schweizer Kunden wollen das in der Schweiz gehostet haben, die Deutschen in Deutschland und dann ist das möglich. Also wir sind viel, viel flexibler und wir bauen halt gleich was auf auf 'nem guten Fundament. Und langsamer geht es, glaub ich, nicht mehr.
- Jan
- Aber der Punkt, den Du gemacht hast mit, die die Zeit spielt ja dir in die Karten. Das gilt ja auch für so Tools wie Flatter, Flow oder wahrscheinlich analog auch für vergleichbare Tools. Vielleicht hab mir das eben nur mal so kurz nebenbei aufgemacht. Und da gibt's jetzt auch AI Funktionen, die so, ja, wo Du halt son bisschen schnell was malst und da generiert dir dein dein Widget daraus oder Nicht
- Till Schneider
- gut. Also leider ist das es ist es wirklich einfach nicht gut. Also Aber
- Jan
- aber wie Du gesagt hast, das ist ja jetzt das Schlechteste, was es jemals sein wird, so, ja? Also auch da ist ja die Frage, ne, weil Du dieses UI Thema auch so angesprochen hast, also da Also ich versteh deine Abwägung jetzt vollkommen, so. Ich frag mich halt, ob das in fünf Jahren immer noch genauso ist. Weil was ich immer seh, wenn Leute mit AI Code generieren oder UIs generieren oder so, es ist superschnell, solange diese diese menschliche Sprache als und funktioniert, ja? Wenn Du jetzt schreibst, hey, ich brauch 'n Login Screen und ich will hier 'n Userfeld und 'n Passwortfeld und 'n Login Button und 'n Registrieren Button und 'n, weiß ich nicht, Button oder so was, ja? Und dann wird das erstellt und alles cool. Und dann kommt so diese diese kleinen Details, ne. Ich brauch hier mein mein Logo drin und ah, nee, ich brauch's irgendwie anders. Das sitzt noch nicht so ganz richtig, wo man halt eigentlich in sonem grafischen Editor, ne, wenn wenn die Grundlage mal erzeugt, das würde man eigentlich viel lieber mit der mit der Maus mal so hingehen und das son bisschen bewegen oder ziehen oder noch mal noch mal anpassen. Und solang ich aber immer 'n neues prompt irgendwie schreiben muss so, ah, mach's doch noch mal 'n bisschen anders und schiebst's mal mehr dahin oder versuch's mal so und so. Das ist, glaub ich, beim Iterieren noch ziemlich mühselig grade. Was man, glaub ich, eigentlich haben will, ist doch son sone Toolchain, wo der Initialzustand quasi AI generiert wird und ich dann aber trotzdem 'n grafisches Interface hab, die letzten null Komma eins Prozent irgendwie Feintuning noch zu machen, ja. Ich will ja nicht in den Code gehen, nur Margin irgendwie anpassen zu müssen.
- Garrelt
- Weißt Du,
- Jan
- was ich mein?
- Garrelt
- Ich weiß, was Du meinst, aber das Problem der aktuellen No Code No Code No Go Tools ist eben, dass sie diese zusätzliche Abstraktionsebene ein
- Till Schneider
- aktuellen Tools ist eben, dass sie diese zusätzliche Abstraktionsebene einführen und sie dich nicht an den ganzen Stack ranlassen. Du hast nicht die komplette Kontrolle über deine Tools. Also da braucht's, glaub ich, einfach eine neue Generation von Tools, die Ja, vielleicht. Im Grunde genommen auf voll mit KI gebaut sind und diese Abstraktionsebene einfach weglassen. Die können mir das ja dann anzeigen visuell und ich kann meinen Button verschieben, wobei das auch 'n bisschen 'n Wunschtraum ist, dass man dann die Margin anpasst, weil wie verhält sich das dann in der responsivness? Also das ist dann alles gar nicht so einfach. Son visueller Editor bringt auch Probleme mit sich auf der anderen Seite, aber ich glaube, da braucht's, man braucht die Kontrolle über den Stack. Und diese flatte Flow Ebene bringt halt Performance Issues mit sich, bringt eben mit sich und so weiter und so fort. Also zum jetzigen, ist wär schön, wenn wir das hätten, dass jetzt quasi, aber das das muss dann 'n VS Code bringt dann halt irgendwie eine eine Möglichkeit, dass man da auch visuell 'n bisschen rumschieben kann. Da seh ich das dann eher, dass dass sich eigentlich die Code Editoren in die Richtung bewegen, anstatt dass diese Low Code No Code Tools mehr wie die Code Editoren werden. Mhm. Mhm.
- Garrelt
- Ich
- Tobias Müller
- glaub, das ist dann auch son bisschen unsere differenziertere Ansicht, weil ich finde, es gibt trotzdem noch valide Argumente für die Low Code No Code Editoren. Ja, es würd, denk ich, schon einiges sich noch ändern. Aber wie gesagt, hast Du diesen ganz ganz einfache Anforderungen oder hast auch überhaupt keine Ahnung von Design oder so. Oder willst einfach nur schnell mal 'n Prototypenen zusammenklicken, find ich, hattest Du durchaus schon noch seine Existenzberechtigung, ich persönlich.
- Jan
- Also ich muss auch sagen, in meinem vorherigen Job hatten wir auch No Code No Code Tools benutzt, so interne Sachen einfach zusammenzubauen, ja? Und ich sag mal, für so das interne Dashboard zur Eventplanung, ja, wo jetzt auch Design mal komplett zweitrangig ist und es eigentlich mehr son glorifiziertes ist für so einfache Update Delete Operationen und 'n bisschen Auswertungen oder so. Dafür wird es, glaub ich, auch auf sehr lange Sicht nicht zu schlagen sein. So ja, weil das halt noch Weiten mächtiger ist als son Excel Spreadsheet so und deutlich billiger zu machen als irgend eine Custom Softwarelösung, so. Ja, ich glaube, das wird vielleicht die Nische, die Sie da so lang- und mittelfristig besetzen können. Aber wahrscheinlich hast Du recht, Tobias, ja, es gibt gibt auch genug andere Use Cases, wo's sich vielleicht dann dann auch nicht lohnt.
- Till Schneider
- Sehe ich genauso. Aber sobald's, glaub ich, Customer Facing wird und man will man will in eine gewisse Skalierung reingehen und man will einfach das beste die beste User Experience bieten, was man ja für interne Tools nicht muss. Da geht's nicht drum. Da weiß jeder irgendwie, was er da jetzt machen soll, das Sommerfest zu planen und dann dann ist das super. Aber ja, vielleicht geht dann da so, trennt sich da die Spreu vom Weizen. Als Tobi und ich uns dann irgendwann, das war recht spät in dem Prozess, mal angeguckt haben, was sind denn so die ganz tollen Flatterflow Apps, die so die live sind, waren wir dann auch sehr ernüchtert, weil also die die das, was die da alles showkasen an an den den erfolgreichen Flatterflow Apps, die sind auch gar nicht so gut und und gar nicht so erfolgreich und und und. Also ich glaub auch, es ist sone Frage von von für wen ist es dann gedacht am Ende.
- Garrelt
- Ich glaube, ihr habt das schon beantwortet, aber das heißt, am Anfang seid ihr eingestiegen mit, es ist cool für Prototyping und wenn's schnell gehen soll. Aber wenn ich das richtig verstehe, wenn ihr jetzt in dem Hacker fahren seid, würdet ihr auch eher auf cursor a I gehen und das so erstellen. Hab ich das richtig verstanden?
- Tobias Müller
- Ich glaub, das war dann tatsächlich der Punkt, wo wir anfangen zu diskutieren, wo Till wahrscheinlich ironischerweise Till, der nicht Und dann ist der Herr der Podcast hat
- Jan
- vorbei nach zwei Tagen diskutiert.
- Garrelt
- Das ist
- Jan
- schon fatal.
- Till Schneider
- Genau. Ich ich
- Tobias Müller
- glaub, das ist 'n bisschen die Ironie. Till eben, der nicht dann Code schreibt, der wird dann vielleicht eher zu Cursor oder Windsurf tendieren und ich vielleicht eher dann tatsächlich zu Flatterflow, der eigentlich coaten kann. Keine Ahnung, aber ja.
- Till Schneider
- Ich glaube für für Leute, die, also ich persönlich würde es so machen, dass ich dann mit Cursor oder oder Wünsdorf anfange, aber anderen Menschen würde ich da vielleicht schon noch 'n Low Code No Code Tool empfehlen. An der Stelle vielleicht jetzt nicht Flatterflow, weil's einfach noch komplexer ist. Da gibt's eben andere Low Code No Code Tools, die deutlich simpler daherkommen und für einen Hacker Thorn dann besser geeignet sind. Aber ja, für uns persönlich macht es keinen Sinn mehr, in diese Abstraktion reinzugehen, weil wir jetzt weil wir uns halt auskennen und schneller sind, wenn wir es selber coden. Aber für jemand ohne Erfahrung hat seine Tobi, ich
- Jan
- stell mal eine These in den Raum, weil ich würde mich, glaub ich, dir auch anschließen und auch eher zu dieser zu sonem grafischen Interface Code, nicht Nicht Code Editor tendieren für son Setting. Aber weil ich bei mir persönlich auch immer so das Risiko seh, wenn ich das jetzt in sonem HTML mache und egal, ob das auto generiert ist und oder weiß nicht, Du nimmst fertiges Template ausm Netz oder so was, keine Ahnung, ne. Man verliert sich dann halt doch so ganz schnell in diesen kleinen Sachen so, oh, hier, das könnt ich schon mal weg abstrahieren und hier könnt ich irgendwie noch mal das 'n bisschen eleganter machen als diese Vorlage oder dieses Generierte. Und das ist natürlich sone Falle, in die man in 'nem No Code, in einer No Code Umgebung halt nicht so reinfällt. Ja, man hat jetzt okay, ich klick jetzt mein Interface zusammen und vielleicht ist der Button noch nicht perfekt, aber für mich, dann mein ich jetzt mich, Jan, ja, der im Prinzip null grafischen Gestaltungsanspruch hat, weil ich zwei linke Hände hab, was so was angeht, da reicht das halt. Dann bin ich halt viel, viel schneller so, mal zusammen zu klicken sozusagen, anstatt irgendwie eine IDI aufzumachen und nach zwei Stunden zu merken, dass diese eine CSS Klasse irgendwie immer noch nicht so will, wie ich will, ja. Und halt wieder nur viel Zeit verschenkt hab. Ach, Ja, ich ich ich glaube,
- Tobias Müller
- das ist 'n valides Argument, ja. Der da da triggert dann son bisschen der Perfektionismusdrang. Den sieht man halt nicht bei sonem Editor.
- Till Schneider
- Deswegen, das ist sone spannende Diskussion, weil ich glaub auch nur, dass dass dass das meine Meinung ist, weil ich eben keine Erfahrung hab im Coden. Also Ja, Verständnis ist. Ja und das ist aber eine ganz spannende Herangehensweise. Also ich bin ich bin ich bin fest davon überzeugt, ich kann die ich kann die Dinge anders entwickeln. Ich denk anders über sie nach, weil mir ist es egal, wie gut der Code aussieht, da jetzt eben der Wechsel von Curser to Windsurve, vielleicht für meinen schon for shadowing für meinen Pick des mein mein Pick des Tages, finde ich ganz spannend, weil mich Ich les den Code auch nicht mehr. Wirklich, das interessiert mich nicht, was im Coach steht. Ich les den nicht. Ich ich drück aufn Knopf und dann drück ich zehnmal noch mal aufn Knopf. Und wenn ein Ärger rauskommt,
- Jan
- dann Zu viel Lehrer aus dem sehen gerade nicht, wie hochgaret die Augenbrauen gezogen hat. Die sind quasi zum zum Hinterkopf.
- Till Schneider
- Ich weiß, Du weißt die. Aber es hängt halt davon ab, was man baut. Und wir bauen deswegen sehr viel neue Tools, damit wir die die vom vom Funktionsumfang sehr abgespeckt halten können. Und mir geht es nicht die Codequalität. Mir geht's darum, dass ich 'n fertiges Produkt hab, was ich den Leuten schippen kann. Und und was da drunter für 'n Müll ist, da ist ja Code ist ja 'n Code nicht perfekt, ist nie perfekt. Das ist eher Gerade nur eine größere war, sonst läuft der irgendwann ausm Ruder. So, das das das entbrase ich von vornherein, das Chaos. Ich weiß noch nicht, wie Oh, okay. Wo das denn gelang ist? Schwierig. Ich
- Jan
- ich kann da ganz kurz eine eine Anekdote zu erzählen aus Ja. Aus 'nem Consultingprojekt von jemandem, die mal ein ein Interface, ein Frontend in Auftrag gegeben haben, irgendwo offshoring mäßig. Mhm. Und das haben wir dann zurückbekommen in irgend sonem Javascape Framework und und und bla. Und dann mussten da noch 'n paar Änderungen gemacht werden, weil es halt nicht so ganz dem Design entsprochen hat in allen Details. Und dann sind wir da 'n paar Wochen vergangen und das gab eine neue Auslieferung von dem Interface. Und wenn man da mal den Code reingeholt hat, hat man halt gemerkt so, das hat kein Stein auf dem anderen geblieben. Ja. Und dann wurde da so nachgefragt, so, wieso habt ihr denn das ganz? Also wieso ist denn da so viel geändert und so, ja, weil wir das halt komplett neu gebaut haben so. Also bevor wir uns die Mühe machen, hier den Leuten quasi zu erklären, das ist der Stand, das muss geändert werden, gibst Du halt dieselben Specs Ja. Noch mal fünfzig anderen Offshore Arbeitern so. Und das ist halt einfach noch mal komplett neu iterieren, So.
- Till Schneider
- Keine Techdap, keine Legacy Code, wie
- Jan
- Ja, genau, einfach komplett bei null an.
- Garrelt
- Das ist
- Jan
- halt viel einfacher für die, wenn Arbeitskraft quasi nix kostet. Und im Prinzip ist ja das mit AI genauso, ja? Wenn Arbeitskraft nix kostet, ist ja jede Iteration umsonst sozusagen. Und kannst das dir dann halt auch erlauben. Aber meine meine abschließende Frage an Gareth wär eigentlich gewesen, nach dieser Diskussion jetzt hier, Gareth, ja. Wenn Du jetzt bei 'nem Hackathon anfangen müsstest, ja, für was würdest Du dich denn entscheiden?
- Garrelt
- Ja, also ich glaub, mein Fazit ist so, das kommt aufs Team an, weil ich hab schon das Gefühl zum Beispiel, es ist es ist eine arge Zielgruppenfrage, dieses Thema, nutzt man dieses Tool oder nicht? Und mein Gefühl war eigentlich, Till und das wollte ich dich auch noch fragen, dass es für dich gefühlt eigentlich 'n cooles Tool war, weil Du so von Design supergut auch ins Entwickeln einsteigen kannst, so. Und so der Weg darüber in meinem Kopf halt 'n schöner ist und 'n guter, weil man eben so viel schon sieht und an manchen Stellen einsteigen kann, technisch, wenn man will, es aber auch erst mal weglassen kann oder von anderen machen lassen kann. Und deswegen wär, glaub ich, meine Entscheidung so, hab ich jetzt nur Entwickler in meinem Hacker vom Team? Dann wahrscheinlich nicht. Aber hab ich auch Designer, die auch Lust haben, nicht nur zu designen, sondern das auch direkt zu bauen, was ja auch dann den Entwicklern erst mal auch Arbeit abnimmt und eine bessere Zusammenarbeit ermöglicht. Auf jeden Fall, find ich's total sinnvoll. Und ja, wahrscheinlich und mein zweites Learning wär dann, haben wir gewonnen, ist es eine coole App, wollen wir daraus 'n Produkt machen, direkt weg von No Code. Das wär, glaub ich, so mein mein Learning.
- Jan
- Das ist, glaub ich, 'n sehr schönes Fazit. Das das kann man so stehen lassen als letzten Satz. Aber das ist ja noch nicht ganz der letzte Satz, weil wir haben ja noch unsere. Und Gerald, weil Du grade son schönes Fazit gezogen hast, ja, darfst Du auch anfangen mit deinem. Sehr gerne.
- Garrelt
- Ich habe einen Artikel mitgebracht, den ein Kollege vor Kurzem geteilt hat mit uns, der heißt von Iven Smith. Und das ist im Prinzip ein sehr ausführlicher Artikel, gibt auch einen Talk dazu, also kann man sich auch anschauen, wen man möchte. Darüber, wie er Kenntnis als Entwickler lebt sozusagen. Also wie kann man, ja, Kenntnis, Freundlichkeit, nee, wie übersetzt man das Deutsch? Ja, ja doch. Freundlichkeit. Wie kann man das als Entwickler in seinem Arbeitsplatz ausleben und fördern und andere Leute da so auch mitreißen? Er beleuchtet das von verschiedenen Sichtweisen und ich find es sehr schön gemacht. Es ist 'n sehr schöner.
- Jan
- Nice. Wunderbar. Tausend Dank. Dann Tobi, was hast Du im Gepäck?
- Tobias Müller
- Ich hab 'n kleines Open Source Tool, das heißt Local Sand. Da bin ich drauf gestoßen, das hilft mir hin und wieder, weil ich eben durch die Crossplattformenentwicklung aufn Mac wechseln musste, bin aber eigentlich eher von der Android Linux Site und so weiter gekommen. Ich hab also immer noch 'n Android Phone und da kann ich halt keinen Airdrop nutzen. Und Local Sand ist 'n Open Source Tool, womit man einfach wirklich auf allen Plattformen schnell mal Dateien oder Texte auch verschlüsselt im lokalen Netzwerk senden kann. Also ich hab irgendwie 'n, ich bau grad eine APK, nämlich Local Sand, Shicks aufm Handy. Auch hab ich 'n iPhone hier liegen, kann ich auch darüber schnell was schicken. Also superpraktisch und vor allem die Oberfläche ist super minimalistisch und intuitiv.
- Jan
- Wenn das Open Source ist, wie krieg ich das auf mein iPhone drauf? Gibt's auch im Store oder muss ich mir das selber bauen und kompilieren oder wie wie wie wie komm ich da dran?
- Tobias Müller
- Ich vermute, dass es im Store ist. Ich kann's dir grade nicht sagen. Doch, ich ich hab grad geguckt.
- Garrelt
- Entweder im Store oder Package Manager haben, das gibt's auf verschiedenen Plattformen verschiedene Links.
- Till Schneider
- Okay. Cool.
- Jan
- Wunderbar. Till, was hast Du im Gepäck?
- Till Schneider
- Genau, ich habe Windsurf mitgebracht. Ich eben als als Nichtcoder bin dann von Cursor gewechselt zu Windsurf jetzt vor, also ich benutz beide Tools noch parallel, aber primär jetzt eigentlich Windsurf, ist eben eine neue IDE, die viel ist als Cursor, also die die dreht selber Denkschleifen, schlägt selber die nächsten Schritte vor und ist gefährlich. Also ich würde das wirklich in 'nem neuen Projekt testen, da die wie son, es ist wie 'n breiter Pinsel. Das ist wie man wirft Farbe auf die Leinwand, wo man mit Curseern noch noch zielgerichteter an Probleme rangehen kann, fängt es immer an, gleich die ganze Codebasis in in in Hinblick zu haben. Man muss zum einen keine Dateien mehr referenzieren, sondern der sucht sich die selber raus. Es ist von der von meiner Developer Experience her, wenn man davon sprechen kann, ist es komisch, weil man drückt drauf und dann geht's drei Minuten und man weiß jetzt nicht, was man in den drei Minuten machen soll. Mit mit Cursor kam ich noch schön in einen Tunnel rein und konnte konnte mir überlegen, während der das diesen eine Änderung jetzt macht, okay, wo könnten wir jetzt weiter weitermachen? Also es erfordert 'n bisschen ein Umdenken. Ich find's aber extrem spannend, weil es einfach so der, find ich, die noch mal der nächste Schritt ist in Richtung, KI kann auch in größeren Code Codebasen gut unterwegs sein, kann einem Dinge, kann Probleme finden, die die irgendwo versteckt sind und hat mich jetzt noch mal ermöglicht, Dinge noch schneller zu bauen eigentlich und auch andere Sachen noch besser zu referenzieren. Also fand ich jetzt eine 'n tolles Tool und zeigt son bisschen, find ich, die die die deutet die Zukunft an, wo's hingeht.
- Jan
- Ich hab bei diesen ganzen AI Tools immer so zwei Fragen. So a, was was ist das Pricing? Und gibt's die Möglichkeit, das auch irgendwie zumindest teilweise lokal bei mir laufend zu haben?
- Till Schneider
- Tatsächlich weiß ich bei CursOR nicht, ob man seine eigenen API Keys einbinden kann. Ich weiß, dass es also bei kostet ja zwanzig Euro im Monat, wenn man das pro Tier hat. Ich hab da aber ständig auch neue dazukaufen müssen, also ich zahl da eher achtzig Euro im Monat für. Und bei, ja, aber das genau, also das ich hab da überhaupt keinen Schmerz, weil anders könnt ich ja gar nicht arbeiten. Also für mich ist es ja quasi essenziell notwendig, Nein,
- Jan
- nein, nein, alles cool.
- Garrelt
- Ich ich
- Jan
- bin nur drüber gestolpert, weil wir hatten, ich hatte vor Kurzem 'n Gespräch mit Fabi, als wir 'n Gastauftritt im Engineering Kiosk, kleines Shoutout, gehabt haben, da haben wir nämlich auch über Cursor gesprochen. Dann hab ich nämlich Also Fabi hat Cursor gepitcht. Und das war nämlich genau meine Frage, so dieses Pricing Model, wenn ich's für mich so sehe, ne. Null, zwanzig und Teamplan, so ohne Preis sozusagen, was wir da auf der Webseite haben. Und dann stand da so dabei, Du hast irgendwie, weiß ich nicht, zweihundert Autokomplicions im Monat oder keine Ahnung, was Du da für zwanzig Euro kriegst. Und das war für mich als als Entwickler, als Endkunde gefühlt vollkommen intransparent, weil wenn Du mich fragen müsstest, wie viel Autokomplicions brauchst Du denn überhaupt? Also ich Keine Ahnung. Keine Ahnung, so, ja. Vielleicht fünfzig, vielleicht fünftausend? Keine Ahnung.
- Till Schneider
- Ja. Also ich brauch dann dementsprechend achthundert im Monat oder so circa. Und dann zahl ich meine achtzig dafür.
- Jan
- Ja, das ist schon schlauer als ich
- Till Schneider
- Und also Windsurf kostet weniger. Windsurf kostet 'n Zehner im Monat, aber Du hast da wieder, ich bin jetzt, was ist, zwei Wochen Free Trial. Jetzt haben sie mir für Thanksgiving noch mal 'n Monat, glaub ich, oder zwei Monate Free Trial geschenkt, also wie's halt so ist. Sie sie hocken dich, aber sie haben mich schon lange gehook, also an der Stelle hätten sie mich jetzt eigentlich auch schon zur Kasse bitten können. Aber ich bin ja bin ich froh drum. Genau, heißt, es ist 'n bisschen günstiger. Ich bin mir nicht sicher, ob Du deine eigenen API Keys einbauen kannst. Genau, aber fand ich fand ich 'n sehr, sehr schönes Tool. Gleich gleiche Geschichte, Fork von VS Code. Genau.
- Jan
- Aber auch mit 'nem API Key wär's ja immer noch bei irgendjemand anderem gelaufen. Ich so, weißt Du, ich such noch son Editor, wo ich auch so lokale Modelle irgendwie am Start hab. Ja. Und das gibt's gefühlt
- Till Schneider
- noch nicht. Noch nicht.
- Jan
- Wirklich so.
- Garrelt
- Ja. Cool. Da aber
- Tobias Müller
- 'n Tipp, wenn Du Cursor nutzt, kannst Du zum Beispiel auf auf eine eigene deine eigene GPT Instanz hosten. Das ist ja dann auch DSGVO konform. Das kommt zumindest mal 'n bisschen Richtung Datenschutz und Sicherheit in die Richtung. Und dann kannst Du auch den API key dafür nutzen.
- Jan
- Tatsächlich, so blöd es jetzt klingt, aber Datenschutz ist nicht mein Main Console. Mein Main Console ist eher so, ich sitz im Zug oder im Flugzeug oder keine Ahnung, Du hast ja aber einfach kein Netz braucht, weißte? Ja. Was die die perfekte Überleitung zu meinem Pick ist, mein Pick ist nämlich Air Fly. Ich weiß nicht, wer von euch Air Fly kennt, das ist son kleines Hardware Ding. Wer öfter mal im Flugzeug sitzt, so wie ich das in letzter Zeit viel getan habe, ärgert sich vielleicht manchmal, dass wenn er irgendwie son Onboard Film gucken will, diese komischen Headsets von irgendwelchen Airlines oder so benutzen muss. Und die coolen Kopfhörer, die man selber dabei
- Till Schneider
- hat, meistens nicht funktionieren, weil das ja in der Regel alles Bluetooth Sachen sind, die wir so haben.
- Jan
- Mhm. Und Airfait, in der Regel alles Bluetooth Sachen sind, die wir
- Tobias Müller
- so haben. Mhm.
- Jan
- Und Air Fly ist, ich hab jetzt mal kurz, ich hab mal son kleines Dongle, was man im Prinzip an son Audioanschluss hängen kann. Und das macht im Prinzip einen kleinen Bluetooth Anschluss da dran und man kann seine Lieblings Kopfhörer, AirPods, meine Bose Kopfhörer, was auch immer kann ich dann eben benutzen, ohne dass da irgendwie Bluetooth schon dabei sein muss. Und warum grade der Airflight irgendwie so cool ist, Weil er zwei besondere Features hat, die mir immer noch weiterhelfen. Zum einen kann ich mehrere Kopfhörer dadran koppeln. Das heißt, wenn meine Frau, meine Tochter, wie auch immer im Flugzeug mitgucken wollen, können sie im Prinzip auch ihre Kopfhörer dranhängen. Und ich hab wie im Prinzip wie son Splitter dann noch drin. Und man kann dasselbe Gerät nehmen und nicht nur als Transmitter für Bluetooth benutzen, sondern auch als Receiver. Das heißt, wenn ihr am im Urlaub angekommen seid und ihr habt dann quasi einen Mietwagen, der vielleicht auch kein Bluetooth hat und dann steckt ihr das Ding in den Kopfhörer oder in den AUX Eingang von dem Auto, könnt ihr euer Handy quasi so rum daran connecten und habt auf einmal Freisprecheinrichtungen und könnt eure Musik hören und keine Ahnung was. Also es ist einfach 'n superkleines praktisches Gerät. Das ist immer bei mir in der Reisetasche drin und es ist auch in eigentlich jedem Urlaub irgendwie in in Verwendung so. Es ist leider 'n bisschen teuer, ich glaub, es kostet so sechs sechs oder siebzig Euro. Gibt auch eine kleinere Variante davon, die ist 'n bisschen billiger, wenn ich alle Features brauch, aber so oder so. Kann ich nur empfehlen, hat mir schon viel Urlaub gerettet, weil es einem auf einmal ermöglicht, mit Noise Cancelling im Flugzeug zu sitzen und trotzdem 'n coolen Film zu
- Garrelt
- gucken. Ja. Das ist bei denen sehr spannend. Die haben ein Pro für fünfundfünfzig Euro und ein Duo, was alles kann wie der Pro plus mehr Akkulaufzeit für achtundvierzig Euro.
- Jan
- Und es gibt noch 'n s e, was irgend 'n Feature nicht hat, was auch noch mal 'n bisschen billiger ist. Aber ja, Ich ich hab den Pro, keine Ahnung, schon vor fünf Jahren oder so gekauft oder was weiß ich, als er rauskam. Bin bis dahin eigentlich sehr, sehr zufrieden. War damals ganz happy, weil das der Erste war, der auch so USB-c charging hatte und Und schon seit Längerem dabei bin, so mein ganzes Travel Equipment auf USB-c umzustellen und nicht mehr mit irgendwelchen komischen Adaptern rumreisen zu müssen, nur noch eine Sorte von Kabel dabei zu haben. Ist auch sehr befreiend. Ja.
- Tobias Müller
- Das das fühl ich mit den Anschlüssen. Das ist fast schon das größte Argument von allen.
- Jan
- Ja, also das war auch damals, als ich mein mein iPhone fünfzehn gekauft hab, war so, weißt Du, Kamera, Action Buttons, komplett egal. Hauptsache gib mir halt son USB-c-Anschluss. Endlich einheitliche und
- Till Schneider
- ich kann Lightning wegschmeißen, ja.
- Jan
- Ja, genau. Cool. Dann Till, Tobias, danke für die Zeit. Danke, dass ihr da wart. Danke, dass ihr uns viel über Low Code und No Code und Vor- und Nachteile erzählt habt. Ich glaub, das war superspannend auch für alle, die da draußen dazu gehört haben. Danke, Garelt, für die Zeit. Danke an euch da draußen fürs Zuhören. Wenn ihr Fragen, Anmerkungen, Kritik, wie auch immer habt, dann immer gerne an Podcast at Programmier Punkt bar eine E-Mail schicken oder das Kontaktformular auf der Webseite benutzen oder Kommentare hinterlassen auf Youtube, Spotify oder irgendwelchen anderen Plattformen. Lesen immer fleißig mit und wir freuen uns auch immer über Bewertungen über den Podcast bei iTunes zum Beispiel, wenn ihr uns da hört, findet, gefunden habt, wie auch immer. Ansonsten bleibt nicht mehr viel zu sagen, außer dass wir uns hier bald wiederhören. Und tschau tschau. Tschau.