Deep Dive 166 –

IDE Development mit Jan-Niklas Wortmann

01.11.2024

// Podcast
// Deep Dive 166

Shownotes

Entwickler:innen verbringen unzählige Stunden ihres Lebens in Entwicklungsumgebungen (IDEs). Uns geht es da natürlich nicht anders. Grund genug, dass wir mal einen echten Profi einladen, um über IDEs, die Arbeit damit und daran, sowie die technischen Hintergründe zu sprechen.

Zusammen mit Jan-Niklas Wortmann von JetBrains sprechen wir über die Unterschiede von IDEs und Texteditoren, finden heraus, was ein Language Server eigentlich macht und diskutieren die perspektivische Rolle von AI in der Toolchain und im Alltag von Entwickler:innen.

Außerdem sprechen wir über Pricing und Vertrieb von Developer-Software und erfahren hier exklusive Neuigkeiten zu kommenden Änderungen an JetBrains’ Lizenzmodell.

Download

/transkript/programmierbar/deep-dive-166-ide-development-mit-jan-niklas-wortmann

Jan: Hallo und herzlich willkommen zu einer neuen Folge der programmier.bar. Heute wieder mit einem Deep Dive und mit mir in der linken Ecke des Podcaststudios ist heute der Dave, hallo. Wunderbar. Hi, Dave.
Dave: Sehr, sehr, sehr, sehr cool, hier zu sein. Ich freu mich.
Jan: Sehr schön. Schön, dich hier zu haben. Schön, dass Du wieder Zeit für uns hast. Dave, was ist cooler als Visual Studio Code?
Dave: Es gibt nur eine ganz klare Antwort und das ist jede IDI von Jet Braines. Gut.
Jan: Was ist cooler als ein Jan im Studio? Zwei Jans im Studio. Wunderbar, Dave. Wie abgesprochen, ja, alles funktioniert.
Dave: Haben wir tatsächlich nie abgesprochen. Ist wirklich wohl interessant, also wirklich abgesprochen und es hat verdammt gut funktioniert grade. Ich find's echt sehr krass.
Jan: Wunderbar. Wir wollten heute mit euch über ID Ease sprechen und da Dave und ich große Fans und Anhänger von JetBraints sind, haben wir uns jemanden von JetBraints mit ins virtuelle Studio geholt, nämlich den Jan Nicklas Wortmann von JetBraints. Hallo Jan, Willkommen.
Jan-Niklas: Hi. Hi Jan. Freut mich, hier zu sein.
Jan: Ich muss sagen, dass also es gibt ja nicht so viele Ecken, wo man so Podcastfame ausspielen kann, wenn man son Tech Nerd ist, ja. Aber als im Frühjahr irgendwie auf der Google Cloud Next oder so war und da am Jet Brain standgestanden hab, dacht ich, hey, hier kann ich's mal versuchen, ja. Wenn ich irgendwo Game hab, dann hier. Und dann hab ich mit jemandem aus eurem Team geschaut, hey, wir machen hier 'n Podcast in Deutschland, jeden Monat Zehntausende Downloads. Wir würden gerne mal mit jemandem von euch sprechen. Habt ihr jemanden, der Deutsch kann? So, ja. Und dann kurzes kurzes Zögern im Gesicht von deinen Kollegern so, ja, nein, da haben wir jemanden, wir machen da die Intro. Und deswegen freut mich, dass das geklappt hat.
Jan-Niklas: Das wirklich Witzige daran ist, wir haben bestimmt eine eine Handvoll von Kollegen in Deutschland, weil wir haben echt coole Büros in München und Berlin. Und ihr habt natürlich den Einzigen jetzt erwischt, der nicht in Deutschland sitzt.
Jan: Ja, Du bist also wahrscheinlich mit einer der Folgen, wo unsere Gäste von am am weitesten zu, ich mein, Kansas, was ist das so? Ne, so achttausend Kilometer oder so vielleicht von dir. Ich glaub, das Weiteste war die Folge, die wir mit Tokio gemacht haben. Das waren so dreizehn-, vierzehntausend Kilometer. Ja, okay. Da hat man doch langsam bei der Aufnahme gemerkt, dass so Latenz doch irgendwie auch 'n Problem ist, ja? Ja. Carlo hat im Schnitt viel gerettet. Ich glaub, beim Zuhören hat man's nicht mehr gemerkt, aber ja, hier ist jetzt alles cool. So, von daher freut mich, dass das dass das geklappt hat. Wie gesagt, Jan, Du arbeitest bei Jetbrans.
Jan-Niklas: Genau.
Jan: Aber bevor wir über dieses ganze IDI Thema sprechen, Du bist ja Developer Advokert. Wir hatten zwar schon mal eine Folge explizit über Developer Relations und dieses ganze Thema, aber das ist ja sone Rolle und sone Funktion, die eigentlich in jeder Firma son bisschen anders gelebt, ausgefüllt und definiert wird. Deshalb, vielleicht willst Du mal ganz kurz erklären, was Du so eigentlich den ganzen lieben langen Tag machst und wie Du dazu gekommen bist.
Jan-Niklas: Das ist eine witzige Frage. Und ich muss sagen, ich hab tatsächlich erst letztes Jahr mit Development Advocacy angefangen. Deswegen ich, ganz ehrlich zu sein, son bisschen finde ich noch selbst heraus, wie ich das ganze Ding machen möchte, weil auch innerhalb von Jet Braines haben wir, ich glaub, ungefähr dreißig Developer bei Advocarits und jeder führt diese Rolle sehr, sehr unterschiedlich aus. Das kann Also im Endeffekt, also das, wenn Du dir das anguckst, das offensichtlichste, was Du halt siehst, ist, ja okay, Du bist halt irgendwie Bindeglied zwischen dem internen Entwicklungsteam und dem deinen Nutzern, was in der Regel bei Developer Advokacy andere Entwickler sind. So, das ist so schwammig und kann halt von alles bis nichts bedeuten irgendwie. Das kann also sein, dass Du irgendwie Im Endeffekt sehe ich mich selbst son bisschen als Bindeglied zwischen ganz vielen internen Abteilungen, gerade Marketing, Sales und unserem Entwicklungsteam, aber auch als Brücke zwischen unseren Nutzern und unserem Entwicklungsteam, dass ich die tollen Sachen, was unser Team macht, irgendwie verstärke, dass die Community davon Bescheid weiß und darüber lernt. Aber auch zurückspielen, okay, was sind die Probleme, die unsere Nutzer haben? Was sind die Technologien, die grade interessant sind? Und das an unserem Team mitteilen. Also im Endeffekt verbringe ich ganz, ganz, ganz, ganz, ganz viel Zeit auf Twitter, leider auf Twitter, mit unseren Nutzern zu reden. Aber auch umgekehrt verbringe ich ganz, ganz, ganz, ganz, ganz viel Zeit in unserem Bug Tool, zu verstehen, okay, was sind die Probleme, neue Features zu beschreiben, aber auch gleichzeitig, wenn unser Team neue Features entwickelt hat, die direkt zu testen, hey, funktioniert das? Ist das 'n Use Case, den ich sehe? Und dann darüber hinaus versuchen, irgendwie Content zu generieren, das auch unseren Nutzer mitteilen zu können. Das ist, wie ich das mache. Ob das so richtig ist? Keine Ahnung.
Jan: Ich ich muss ja ehrlicherweise sagen, als ich nach meiner ersten Developer Relations Rolle einen neuen Job gesucht hab, hatt ich mich auch mal bei Jetbynes beworben, aber so sehr proaktiv, weil da war überhaupt gar nichts ausgeschrieben in dem Space und Okay.
Dave: Weiß
Jan: gar nicht, ob's das Team damals so formell schon irgendwie so gab oder in der Größenordnung, wie's jetzt unterwegs ist oder so. Und hab dann auch leider nur sone sehr vertrößten Antwort bekommen. Aber ich, also nach allem, was ich so gehört hab, das ist schon 'n sehr cooler Ort, zu arbeiten.
Jan-Niklas: Ja. Also ich ich muss sagen, ich muss sagen, ich bin wirklich sehr zufrieden in die Firma. Das macht echt coole Sachen und jeder hat irgendwie son Interesse daran, das Produkt weiterzutreiben. Das Ich hab halt vorher viel Consulting gemacht, deswegen da ist das einfach nicht, ne. Der Kunde sagt, hier komm, ich brauch die Software oder diese Lösung, dann machst Du die mehr schlecht als recht und wenn fertig ist, fertig. Und hier ist halt wirklich, okay, jeder hat persönlich Interesse, die Software weiterzutreiben und möchte halt auch, dass die Nutzer die bestmögliche Erfahrung haben. Deswegen, das ist echt eine echt eine coole Sache.
Jan: Ja, Product Company ist das eigentlich das coolste Arbeitsumfeld, was man so haben kann.
Jan-Niklas: Ah ja. Tru.
Dave: Ich find's interessant, Du hast grade gesagt, dass Du davor überwiegend im Consultingbereich gearbeitet hast. Wie kam's dann jetzt, weil Du gesagt hast, Du bist jetzt anderthalb Jahre dort, dass Du sagst, okay, let's go, ich mach jetzt hier diese Rolle bei Jet Braines?
Jan-Niklas: Also das große Ding war für mich tatsächlich, als Consulting war zu der Zeit, als ich das gemacht hab, hervorragend für mich, weil ich viele Projekte gesehen hab, viele Project Set ups auch und halt unter, also superviel gelernt hab in 'nem sehr kurzen Zeitraum. Mhm. Also mein erstes Projekt, wo ich Architekt war, war da war ich dreiundzwanzig Jahre alt. Also ich hab halt einfach superviel mitnehmen können. Auf der anderen Seite, wenn Du das lang genug machst, merkst Du irgendwann, okay, die Probleme, die die Kunden haben, sind in der Regel nicht softwaregetrieben, sondern firmgetrieben. Sprich, Du kämpfst halt mehr gegen Windmühlen, die Du als Externe nur so bedingt beeinflussen kannst. Das hat mich irgendwann sehr frustriert. Und zu 'nem gewissen Grad, wenn Du gerade in diesem Fortschritt fünfhundert Umfeld bist, ist das halt irgendwann sind die Anwendungen, die Du machst, alle gleich. Das sind halt irgendwelche businessinternen Anwendungen, wo halt welche Daten erfasst werden, bearbeitet werden, geteilt werden und das war irgendwann langweilig so. Und dann hab ich mir etwas oder mein großes Ding war, okay, ich brauch 'n Wechsel. Und eigentlich wollt ich zu dem Zeitpunkt dann für eine Produktfirma arbeiten, wie Du gesagt hast, weil ich ja keinen Bock mehr hatte, für eine andere Firma zu arbeiten. Und ich wollte halt an 'nem Produkt arbeiten, an der an das ich selbst halt glaube, an dem ich selbst irgendwie 'n Interesse hab. Und zu dem Zeitpunkt muss ich sagen, hab ich gar nicht so wirklich betrachtet, weil grade auch hier in den USA 'n bisschen eine problematische Rolle ist. Von daher, dass es grade im Start up Bereich das Erste ist, was in der Regel gehen gelassen wird, weil's nicht sehr auf offensichtlich ist, wo der Mehrwert generiert wird. Mhm. Deswegen, also Developer Advocacy war nie meine erste, weil ich hatte halt wirklich eher so gedacht, okay, Du bleibst hier irgendwie als Entwickler bei Spotify, Netflix,
Jan: was Darf ich da mal kurz reingrätschen? Ja. Wie ist es denn strukturell bei euch aufgebaut? Weil das ist ja immer sone sone große Glaubensfrage, ob Devirrell, Teil von Marketing oder Teil von der Engineering Abteilung. Wie ist wie ist das bei euch?
Jan-Niklas: Wir sind unabhängig tatsächlich.
Jan: Aha. Sehr schön.
Jan-Niklas: Ja, also das muss ich auch ganz ehrlich sagen, das ist was, was ich tatsächlich genieße. Also ich hab pfleg schon eine sehr, sehr gute Beziehung zu unserem Produktteam und auch zu unserem Marketingteam. Aber dass, ich hätte jetzt 'n ganz massives Problem, wenn Marketing mir sagen würde, okay, Du schreibst jetzt diesen Bockpost, der halt irgendwie viele Klicks generiert, das das denke ich, also eine gewisse Form von Authentizität ist sehr wichtig in der Adocacy. Und da behalte ich mir das dann auch vor, nein sagen zu können.
Jan: Aber wir wollten ja eigentlich über IDEs sprechen.
Jan-Niklas: Richtig, jetzt wolltest Du auch. Ach
Dave: so. Danke, Jan.
Jan: Ich bin ja, glaub ich, hier der Älteste mit in der Runde und ich hab noch Programmieren gelernt mit so Texteditoren, die quasi gar nix konnten. Aber Dave, was ist 'n für dich eigentlich sone IDI? Was macht das aus?
Dave: Ich find, das beste Beispiel dafür ist Notepad plus plus. Also eigentlich, also sehr trivial, ich find Highlighting ist wahrscheinlich so eines der der wichtigsten Sachen. Dann bisschen so auch immer sehr, sehr praktisch und für die Übersicht auch mal 'n bisschen Formatierung. Also das, wenn wenn das diese drei drei grundlegenden Bausteine erfüllt sind, denk ich mir so, ey, okay, damit kann ich arbeiten. Ach und und vielleicht noch mal was, grad in in Kollaboration mit anderen Entwicklern natürlich irgendwie sone sehr gute Git Anbindung. Das ist mir auch mittlerweile sehr, sehr wichtig. Also ich merke, wie sehr viel davon abstrahiert wird und ich gar nicht mehr diese alten git commands können muss und einfach alles bam bam durchpushen kann und es es funktioniert hervorragend einfach. Das ist mir auch sehr wichtig.
Jan: So, jetzt stell ich mal eine steile These auf und dann kann Jan Niklas dir sagen, ob ich recht hab oder nicht. Ich glaube, also das, was Dave grade gesagt hat, ist wahrscheinlich so wie neunzig Prozent da draußen irgendwie das auch sehen würden. Ja. Ich würde behaupten, das, was Dave grade beschrieben hat, ist immer noch 'n glorifizierter Texteditor,
Jan-Niklas: Ja, das find ich auch so.
Jan: Weil für mich zu 'ner IDI noch viel mehr eigentlich gehört, ja. Und wahrscheinlich ist es auch son bisschen das Koks an der Sache, weil das der Teil ist, der so nur relativ schlecht gesurfet wird ab und zu. So Sachen wie dein Testrunner irgendwie automatisch starten, ja. Ah, okay, Git hast Du angesprochen, glaube ich, Dave eben grade, ja. Aber auch so Sachen wie, wenn die Sprache, das Framework, was auch immer, womit Du arbeitest, das zulässt, son Debugger Stepper irgendwie drin zu haben, ja? Bisschen den machen zu können, ordentlicher Support fürn fürn Language Server vielleicht auch. True. Also halt halt super-, superviel, was so Ältere unter uns noch so schätzen und lieben gelernt haben, aber ich glaub, heute halt ganz oft von viel zu vielen Leuten links liegen gelassen wird. So, das ist meine These und jetzt kann der Jannick das was dazu sagen.
Jan-Niklas: Das ist eine hervorragende These. Also bei Jetbrains, wir differenzieren sehr stark zwischen dem Aspekt Codeditor und IDE. Ich ich bin ganz ehrlich, ich glaube, wir differenzieren da stärker als jeder andere, weil das eins unserer Unterscheidungsmerkmal ist. Aber das Ding, was State beschrieben hat, würden wir generell eher als Codeditor bezeichnen. Und es, Viaz Code ist da 'n gutes Beispiel für und gerade durch das Plug in System bei Viaz Code sind diese Linien sehr schwammig geworden. Weil im Endeffekt mit wir mit dem Plug in schwammig geworden. Weil im Endeffekt mit mit den Plug ins kannst Du Codes Codes zu 'ner vollständigen IDI machen. Das ist nicht ganz, wie wir uns das vorstellen, aber das jetzt mal einfach so als dahingestellt. So, bei, was uns wichtig ist wirklich bei IDE, ist der. Also dass wir halt möglichst viele Eigentlich die Idee wirklich ist, wenn Du als Softwareentwickler arbeitest, solltest Du ideal für acht Stunden coden? Das ist das, wo Du am meisten Mehrwert generierst? Ja, ich weiß nicht.
Jan: Alle lachen mal kurz da draußen so, ja.
Jan-Niklas: Ich weiß, dass das idealistisch ist, aber tendenziell ist das, wie es sein sollte. Und deswegen ist unsere Ambitionen eigentlich, Du solltest, wenn Du als Softwareentwickler arbeitest und produktiv arbeitest, solltest Du alles, was Du tust, in einem Programm machen können, damit Du halt keinen Kontextwechsel hast. Und das ist, was wir versuchen mit Chatbrains IDIs, da da gibt's natürlich auch Ausnahmen, wenn Du jetzt irgendwie 'n fancy Bug Tracker hast oder so was, der sich nicht gut integrieren lässt. Aber prinzipiell ist das erst mal die Ambition, okay, dein kompletter Softwareentwicklungsalltag sollte sich durch die ID abbilden können. Das jetzt erst mal so dahingestellt. Ob das jetzt so ist, hängt auch 'n bisschen davon ab, welche Tools man nutzt et cetera, aber das ist, wie wir uns das vorstellen. Eigentlich wollen wir, dass Du als Nutzer am produktivsten bist, indem Du halt ein Tool hast, was deinen kompletten Arbeitsalltag abbildet. Und wie wie Du gesagt hast, diese generellen Sachen, grade halt Syntax Highlighting, und so was, das sind in der Regel eher Code Editor Features und Testrunner, Debugging, deployment, Analysen, Analysen, was auch immer. Das sind halt eher Sachen, die wir so als Zusatzfeatures für unsere IDIs betrachten, die das halt differenzieren zu 'nem Code Editor. Macht das Sinn? Oder macht das Für mich
Jan: ja, aber stimmt mir ja auch in großen Teilen zu.
Jan-Niklas: Sehr gut. Eine Sache, die ich denke, die sehr interessant ist, die Du angesprochen hast, ist Und das ist son bisschen, ne, superspannend für mich, weil Language Server im Endeffekt wirklich so das Bindeglied zwischen, okay, ich hab 'n stink noch mal 'n Texteditor. Und wie mache, gebe ich dem ja jetzt möglichst viele Smart Features, irgendwie eine Sprache abbilden zu können? Und das ist tatsächlich ganz interessant, weil wenn Du zum Beispiel betrachtest, was nativ Language Server unterstützt, Neovim ist nichts anderes als 'n Texteditor. Ne, brauchen wir nicht diskutieren. Aber mit Language Service Feature kannst Du den halt zu 'ner definitiv 'nem Code Editor machen, könnte man sogar argumentieren, ob's eine IDI dann ist. Also
Jan: Den müssen wir vielleicht einmal erklären für alle da draußen, was eigentlich der Language Server macht und was er ist und wie er funktioniert.
Jan-Niklas: Das das ist 'n sehr guter Punkt. Language Server find ich immer sehr interessant, weil es gibt sone Handvollperson, mit denen ich mich unterhalte. Das kann jetzt auch an meinem sozialen Kreis liegen, die halt supertiefes Wissen von Server haben. Und dann bin ich auf 'ner Konferenz und red über Server und Leute gucken mich an, wie son angefahrenes Auto. Warum? Okay, bist Du da grade? Also im Endeffekt ist 'n Protokoll, was von Microsoft designt wurde, Features in VS Code abbilden zu können. Das ist jetzt erst mal so ganz pauschal. Das Schöne daran an diesem Protokoll ist, dass es sehr UI getrieben ist. Wenn Du jetzt also die UI von VS Code kennst, dass Du halt sagst, hey, ich hab hier irgendwie Auto Complete Pop-up oder so was, wird sich das Protokoll sehr schnell, wirst Du dich da so sehr schnell drin zurechtfinden. Du kannst also Das Ding, wie Language Server Protokoll funktioniert, ist, Du hast 'n Server und 'n Client. Der Server, wenn wir von Codes reden, kommt mit dem Plug in in der Regel, dass Du irgendwie sagst, okay, ich hab jetzt mein, hat zum Beispiel 'n, Du hast ein Plug in und das ship den Server als mit. Und dann hast Du gleichzeitig 'n Client, der Teil des Plug ins ist, der der quasi die Verbindung zu dem Server aufbaut und wie es Code dann sagt. Und Du teilst die Datei, die Du grade bearbeitest. Also in der Regel, Server arbeiten Datei pro Datei. Sprich, Du hast grade eine Datei offen. Dann sagst Du, hey, gib mir, mein Cursor ist grade an dieser Position, gib mir alle, die ich hierfür kriegen kann. Und wenn das jetzt type Script zum Beispiel ist, dann kriegst Du halt, keine Ahnung, was getippert, dann kriegst Du halt als, dot, dir, dort Error vorgeschlagen. Das sind halt Sachen, die dann der Server guckt, okay, das ist der Kontext, den ich zur Verfügung hab. Das sind die möglichen Vorschläge, die Du hier machen kannst. Und Language Server ist Protokoll, also Auto Complete und Autoimport sind so die ganz offensichtlichen Sachen. Das geht aber auch deutlich weiter wie zum Beispiel, ja, okay, ich hab jetzt ich hover hier grade übern Element und brauch halt irgendwie Dokumentation. Oder was Du jetzt in 'ner neueren Version von Language Servern hast, ist Semantik Highlighting. Also zum, Du könntest theoretisch sagen, hey, hier dieser Datentyp ist ganz superspecial für diese Sprache, deswegen gebt dem jetzt eine besondere Farbe zum Beispiel. Es ist eher unüblich und das ist auch 'n gängiges Missverständnis, es ist eher unüblich, dass komplett Syntax Highlighting über 'n Language Server abgebildet wird. Da gibt's in der Regel einfachere Ansätze für. Aber mit der neuen Semantik Highlighting API kannst Du halt so so ja, besondere Sachen machen. Also zum Beispiel einen Webstormen, wir benutzen das jetzt nicht per se, aber für Angela hat jetzt in der letzten Version sechzehn Uhr so Signals rausgebracht. 'N Signal ist halt 'n wichtiger Datentyp. Deswegen in Webstormen haben wir eine bestimmte Farbe fürs alles Signalvariable Variablen. Das Problem mit Language Servern ist, dass es halt 'n Protokoll ist, deswegen es versucht, sehr generisch zu sein, hat dadurch halt gewisse, oh, ich kann kein Deutsch mehr reden, Einschränkungen. Zum Beispiel, was Du vorhin angesprochen hast, Testrunner ist eine Sache, die jede Sprache in irgend 'ner Art und Weise hat mittlerweile, kann sich aber nicht durch 'n Language Serverprotokoll abbilden lassen. Deswegen wird halt solche Sachen dann über 'n anderes Plug in abgebildet, über zumindest 'n VHS Code oder generisch. Also grade im type Skript Kontext ist es dann einfach, dass es nativ type Skript ist. Und das sind halt son bisschen, was schade an dem Protokoll ist, es hat echt sehr viele coole Features. Es hat aber auch echt sehr viele Ecken und Kanten. Und das Ganze dazu, was dann halt auch noch dazukommt, Du hast halt eine Kommunikation zwischen Client und Server über Input Output. Und wenn Du dir das jetzt mal vorstellst, was so abgeht, wenn Du halt eine ganze Datei aufmachst, da da passiert einfach superviel gleichzeitig. Du hast also ganz, ganz hohe Asynchronität, parallele Prozesse und deswegen dieses gängige, gerade im type specote Kontext, ja, der type spec Server hat sich aufgegangen und ich muss den neu starten. Das kann oft passieren.
Jan: Da da hätt ich direkt mal so die erste Frage zu, weil also ja, auch mein type Skript Server hat sich schon mehrfach aufgegangen, muss neu gestartet werden. Und ich hab mich da immer gefragt, wieso ist das denn überhaupt 'n laufender Prozess? Weil ich stell mir das halt so sehr, sehr epemeral vor, was der eigentlich macht, ne. Du hast grade gesagt, so der kriegt eigentlich eine Datei und sagst, okay, gib mir mal alles, was ich damit machen kann. Wieso muss der denn überhaupt langlebig sein? Wieso muss der denn haben überhaupt?
Jan-Niklas: Der der Detailstreet Language Server ist da tatsächlich 'n bisschen speziell, weil er auch 'n bisschen anders arbeitet wie andere Language Server. Der, witzigerweise tatsächlich auch kurz kurze Zwischengeschichte. Der Teilestrip Language Server implementiert nicht das das LFP Protokoll. Der Typeshre language Server ist quasi der erste wirkliche language Server, der entwickelt wurde und darauf basierend wurde dann LSP als Protokoll definiert. Er ist aber nicht 'n Compliance LSP. Sprich, wenn Du einen nativen hast, so was wie neovim, kannst Du nicht einfach sagen, hey, benutzier den typecript Engagement Server. Okay, sorry, kurze
Jan: Ja, keine Ahnung.
Jan-Niklas: Ihr seid
Jan: da doch irgend 'n Proxy sozusagen davor. Ah. Oder irgend 'n Rapper, der das LSP konform macht, ja. Mhm.
Jan-Niklas: Genau. Das Ding mit typecript jetzt ist, type Script kannst Du eigentlich nicht nur auf Basis einer Datei analysieren. Was Du immer brauchst, sind alle Referenzen zum Beispiel, die Ist ja
Jan: bei vielen Sprachen so?
Jan-Niklas: Das kommt tatsächlich drauf an. Und deswegen, was der type School Language Server macht, ist, dass der, wenn er gestartet wird, sagst Du, hey, hier ist mein type School Projekt. Und dann werden alle, wird die komplette TS config eingelesen. Es wird der all, also es wird 'n Cash über alle Dateien abgelegt, dass Du halt möglichst schnell navigieren kannst. Das ist prinzipiell ähnlich, wie wir das am Webstore machen. Genau, deswegen, da da ist der type script Language Server 'n bisschen Special. Aber ja, prinzipiell hast Du das bei allen zu 'nem gewissen Grad mit allen Sprachen. Dieses Ding, dass Du halt wirklich die komplette und basierend darauf halt 'n ordentliches Modulsystem hast, vielleicht NoJs, vielleicht nicht NoJs, das ist das ist schon 'n bisschen Special. Und das ist weniger 'n Teileshrip Problem als mehr 'n Java Skript Problem.
Jan: Ja, ja. Richtig, ist richtig.
Dave: Ich fand einen Punkt, der interessant, den Du grade angesprochen hast, und zwar meinst Du ja grade so irgendwie grad beim Start, sehr viel asynchrone Sachen, parallele Prozesse, die laufen und so. Und ich bin dann immer sehr interessiert, was so immer die speziellen Herausforderungen in der Entwicklung sind. Also, bisschen so auch was von uns zu erzählen, wir haben ja täglich Millionen von Nutzern. Das heißt, die sehr viele Nutzer, die gleichzeitig halt unsere Systeme belassen, das heißt, wir müssen immer, wenn wir irgendwas entwickeln, immer direkt skaliert, optimiert, performant denken, dass halt es direkt auf sehr viele Nutzer ausgelegt ist, ne. Und wir können nicht einfach paar Nutzer, das ist jetzt nicht so kritisch, ne, sondern müssen immer denken, okay, was ist, ne, unsere Auslastung ist relativ hoch. Was sind denn jetzt bei der Entwicklung für IDIs, was sind da so die speziellen Herausforderungen,
Jan-Niklas: warum man immer denken muss? Das ganz offensichtlich ist Rendering Performance. Also alles, was in irgend 'ner Form und Weise gerendert wird, ist halt eine, es ist ja, ich mein es im Browser so, ist auf mobilen Applikationen. Im Endeffekt ist Rendering das performanceintensivste, was Du halt machen kannst. Mhm. Und das gilt halt auch für IDIs so. Deswegen, was wir zum Beispiel jetzt machen grade, ist, dass wir unterschiedliche Requests zu dem type Script Language Server priorisieren, so das Rendering zu beschleunigen. Wir brauchen gewisse Informationen übers Typ System, anbieten zu können zum Beispiel. Insofern ist dieser wird dann höher priorisiert als zum Beispiel, okay, ich brauch jetzt die Dokumentation zum Beispiel für dieses Feld. Klar. Das ist sone ganz gängige Sache. Das andere, was damit dann schnell einhergeht, ist, dass Du halt diesen Concurrency Aspekt hast. Okay, ich hab jetzt, auf der einen Seite will ich schnell rendern, ich muss aber auch gewisse Daten bereitstellen. Ich muss, und wenn wir, manche unserer Nutzer, hab ich gehört, hab ich noch nie gesehen, aber manche unserer Nutzer benutzen aber offensichtlich auch Windows, was einfach schlecht ist, pauschal.
Jan: Ihr seid lieb, sehr schön. Die Leute da draußen, die das auf Windows benutzen. Ich werd denen nachher E-Mails schreiben, ne. Also Ich hab's gehört offiziell von Jetbrans gehört so. Du solltest das
Dave: die das benutzen.
Jan-Niklas: Ich versteh das einfach nicht, dass Leute damit okay sind, wie langsam das Dateisystem ist. Also alles, was irgendwie eine Datei schreibt, sorry, ich direkte da ab.
Jan: Nee, also Performance ist auch das das ist 'n superinteressanter Punkt, weil also Ich find das auch richtig. Ich war auch mal unter auf Windows unterwegs so, ja, auch mit mit Judgements Produkten und ich muss tatsächlich sagen, dass die Performance da nicht so geil war, ja? Was natürlich für mich als als Endnutzer in in dem Moment superintransparent und schwierig nachzuvollziehen, ist das jetzt, weil, also was auch immer eure eure Projektierungsmethode oder eure da unter Windows ist halt irgendwie scheiße ist so, ja? Oder ist das, weil Windows was schwierig macht oder liegt das irgendwie an an Windows Subsystem für Linux, das da auch noch irgendwie halt mittendrin hängt so? Also was was was verursacht da diese Schmerzen so, ja?
Dave: Ich will ich will ich will dir nur kurz anmerken, Jan Niklas hat grade bei der Aussage, ob Windows so scheiße, das ist superhat genickt. Das war so ein krasses Kopfnicken, das war sehr sehr witzig.
Jan: Ich
Jan-Niklas: hatte gehofft, dass man das durch das Mikrofon hört, auch wenn das nicht auch Ich glaub, das war
Jan: so schnell, dass man das Rauschen vom vom Wind einfach so mit mit aufgenommen hat.
Jan-Niklas: Oder? Also das das ganz Wichtige ist einfach, ich ich versteh das nicht, dass Windows, das ist jetzt zwanzig, wahrscheinlich noch, na, ist locker älter, viel zu alt. Und das ist immer noch, dass alle Dateisystemoperationen, sei es Lesen, sei es Schreiben, grottig langsam sind im Vergleich. Also das ist einfach das pauschale Problem. Und grade wenn Du halt IDI oder alles Datei, also ne, Texteditor ist halt dateisystemgetrieben.
Jan: Mhm.
Jan-Niklas: Das ist superschmerzhaft. Und wenn wir jetzt auch noch damit in das Spiel nehmen, das ist einfach eine Vollkatastrophe. Weil da das Ich hatte immer gedacht so, ja okay, WSL, Du hast halt 'n Linux Hub System, aber im Endeffekt mein Verständnis war halt, okay, Du hast halt eine öffentliche Schnittstelle und damit arbeitest Du dann. Denkt man, dacht ich. Klingt cool. Aber als mir dann 'n Kollege gesagt hat, ja, wir haben hier 'n Bug mit WSL, weil die pathgenerierung innerhalb des Dateisystem, anders ist basierend, auf welcher Version Du bist. Also wo ich mir einfach
Jan: dachte, ja. Ja, ja. Ich weiß es so.
Jan-Niklas: Ist das wirklich 'n Problem, womit wir noch 'n, und ich mein, ich bin jetzt 'n Jahr bei Jet Brands, ne. Ist das wirklich noch 'n Problem, wo wir im Jahr zwanzig dreiundzwanzig, zwanzig vierundzwanzig uns mit rumschlagen müssen, ob ich jetzt zwei Slashes oder drei Slashes oder ein Slash hab. Also das das ist doch lächerlich, sorry, aber es also generell, also fair zu sein, das muss ich auch fairerweise sagen, wir wir innerhalb von Jet Braines benutzen wir viel. Sprich, wir benutzen, zu entwickeln, was halt ganz viele Probleme direkt für uns offensichtlich macht. Mhm.
Dave: Auf
Jan-Niklas: der anderen Seite, sorry für etwas vulgäre Sprache. Benutzen die meisten
Jan: Wir pflegen die Folge deinen iTunes irgendwie entsprechend.
Jan-Niklas: Danke für. Genau, deswegen, also die meisten unserer Entwickler benutzen entweder Mac oder Windows oder Linux. Mhm. Und deswegen sind diese Probleme für uns oft offensichtlicher. Das muss man jetzt auch fairerweise sagen. Das heißt nicht, dass wir kein Also wir haben 'n sehr großes Interesse daran, die Erfahrung auf Windows so gut wie möglich zu machen. Und grade seit WSL draußen ist, ist das auch massiv Arbeit reingeflossen, das kompatibel zu machen, grade halt für unsere Dot Net Produkte.
Jan: Ja, habt ihr da auch gemerkt, dass mit WSL tatsächlich auch der Windows User Share hochgegangen ist, weil das für viele Leute halt überhaupt erst mal sinnvoll möglich geworden ist, unter Windows zu arbeiten? Oder hat das für euch überhaupt nix gemacht?
Jan-Niklas: Müsste das tatsächlich jetzt nachgucken? Ich könnte mir vorstellen, dass das bei anderen Produkten nicht oder höher ist, bei Webstone, wo halt viele Webentwickler benutzen
Jan: Ja, das war wahrscheinlich schon alles möglich, da.
Jan-Niklas: Genau. Ja, aber das ist das ist eine interessante Frage. Ich könnt mir sehr gut vorstellen, dass grade bei der Dot Net Community, also unsere Produkte, dass da die Nutzerzahlen deutlich höher gegangen sind. Und auch bei könnte ich's mir vorstellen, weil einfach Java ist halt doch noch sehr traditionelles Business, deswegen könnte ich mir auch da vorstellen, dass viele von den größeren Firmen dann doch auf Windows setzen.
Jan: Mhm.
Jan-Niklas: Ja, ist eine interessante These. Hab ich mir mich so noch nicht mit auseinandergesetzt, weil im im Bereich eigentlich alle Macs benutzt.
Dave: Ja, kurze Frage, so was seh ich, weil weil Jan jetzt die Shares angesprochen hat. Hast Du da eine ungefähre Einordnung in die Größe, also Windows, Linux und Mac Nutzern, wie die Produkte von Jetbraines da verwendet werden?
Jan-Niklas: Nee, gar keine Ahnung.
Dave: Okay, also nicht mal in ungefähre Größenordnung, wer den großen Teil ausmacht. Das ist okay.
Jan-Niklas: Also ich bin bin mir ziemlich sicher, dass wenn ich unser Research Team frage, dass die das wissen. Mhm. Aber das war kam bei mir bis jetzt noch nicht, boah. Keine Ahnung, kann ich leider nicht sagen.
Jan: Cool. Jetzt ist ja das Betriebssystem nur ein nur eine der Umgebungsvariablen, die sich so laufend irgendwie ändern können für sone IDI. Grade weil Du den den Webbereich schon angesprochen hast, ist ja was, wo sich auch unglaublich viel tut, ja. Also ich kann mir vorstellen, dass jemand, der jetzt im Webstormen unterwegs ist, genauso wie 'n Visual Studio Code, ja, wahrscheinlich viel häufiger neue Frameworks, andere et cetera irgendwie ausprobiert als jetzt der durchschnittliche User zum Beispiel, ja. Wie ist es denn für euch dann, also was was tut ihr, da auch irgendwie immer hinterher zu sein? Ist das irgendwie was, was bei euch 'n 'n großer Punkt ist? Kommt das mehr aus der Community und die RNA nur? Wie wie schafft ihr es, dass wenn jetzt so was wie, ich sag mal, Dino die Ecke kommt, ja, als als neue type Skript Runtime, dass es dann irgendwie auch in Webstormen Spaß macht, damit zu arbeiten, so?
Jan-Niklas: Das ist tatsächlich 'n 'n ganz schwieriger Punkt, weil grade im JavaScript Ecosystem ist es halt super ne. Du hast unterschiedliche Sprachen, die alle fundamental anders funktionieren. Framework funktioniert ganz anders wie View, funktioniert ganz anders wie Astro, funktioniert ganz anders wie, funktioniert ganz anders wie. Deswegen da sind wir wirklich auf Experten Know how bei unseren Entwicklern angewiesen, okay, wie macht es Sinn, diese Sprache zu parsen? Wie macht es Sinn, diese Sprache zu verstehen und anbieten zu können für unsere Nutzer? So, ich bin ganz transparent jetzt hier, unser primärer Fokus sind die ganz großen Frameworks. Das teilt sich innerhalb vom Webstore mehr als achtzig Prozent Nutzerzahl.
Dave: Mhm.
Jan-Niklas: Insofern, das ist das, wo unser primärer Fokus draufliegt. So, das ist aber auch das Thema, okay, wir wollen trotzdem ja nicht einfach sagen, ja gut, wenn ihr jetzt halt Astro benutzt, dann nimm halt. Das ist ja auch nichts in der Sache. So, deswegen, was wir, wo wir jetzt mehr zu hingehen, ist das für diesen für diese neueren Sprachen, für diese Frameworks, die mal aufpoppen und wo's halt noch nicht klar ist, okay, wie sieht die Zukunft dafür aus? Ist das was, was sich durchsetzt? Da ist unser Ansatz jetzt mehr in die Richtung für zu gehen, dass wir halt Support haben, dass wir das anbieten können. Gleichzeitig aber auch tracken können, okay, wie viel wird 'n das überhaupt genutzt? Ist das was, wo es Sinn macht, mehr Zeit, Geld, Ressourcen rein zu investieren, bessere Support anbieten zu können, mehr Features zu etablieren? Das ist so grade, wo wir tatsächlich jetzt momentan im Umschwung sind. Weil was man halt berücksichtigen muss, im Endeffekt Webstone ist innerhalb der Jack Brain Produktfamilie. Sprich, das ist alles Monorepository und die die, das erste Produkt war halt Intellij, deswegen viel ist mit diesem Java Design quasi so architektonisch designt. Web ist einfach viel, viel komplexer als Java, fundamental. Deswegen, das war wirklich, als so zwanzig fünfzehn, zwanzig sechzehn, wo das anfing, ja ein Framework die Woche mehr oder weniger. Das war ganz schwierig für uns, da 'n guten Weg zu finden. Ich bin froh, dass wir nicht mehr zwanzig fünfzehn, zwanzig sechzehn haben. Wir haben etablierte Player mit Angio React View. Gleichzeitig haben wir aber auch neue Player. Und neu ist nicht ganz richtig, aber halt Produkte, die sich versuchen durchzusetzen, Svelt, Solid, Astrologie, hochgradig interessant sind, aber einfach nicht die Nutzerzahlen momentan haben, dass wir solide sagen können, okay, hier, Entwickler Hans Peter, bitte, Du machst jetzt ab morgen nur noch Astrosupport.
Jan: Aber jetzt hast Du ja vorhin gesagt, dass der Server nur bedingt das alles erfüllen kann so, ja? Und wenn ich, also Du hast ja gesagt, ne, so und so was und vielleicht auch Dokumentationen oder irgendwie durch den durch den Code navigieren, das kann ja alles wunderbar. Aber grade so was wie Syntax Highlighting wird ja wahrscheinlich öfter mal noch lokal gemacht, weil irgendwie son EST zusammenschrauben und so einfach, also Tokenizer ist irgendwie alles lokal irgendwie, Ja. Ich sag mal 'n gelöstes Problem, ne.
Jan-Niklas: Ja. Und dann ist
Jan: ja jetzt aber grade in diesem Webumfeld kommt ja häufig mal so was so, hey, wir machen jetzt JSX oder TSX oder MDX oder keine Ahnung, was er eben dann nicht mit dem Language Server so erschlagen werden kann wahrscheinlich, sondern ja doch auch Support von euch braucht, oder?
Jan-Niklas: Ja. Witzigerweise, ist 'n sehr guter Punkt, witzigerweise JSX wird vom unterstützt, aber das ist jetzt eine andere Geschichte. Da für für Syntaxylighken gibt's eigentlich zwei unterschiedliche Ansätze. Du hast entweder heißt das. Das ist, wie wie es macht. Sprich, Du definierst quasi oder ist quasi, wo Du sagen kannst, hey, wenn Du dieses Token findest, gib dem den Identifier und dann kannst Du wie eine JSON Datei anlegen. Wenn Du den Identifier hast, so wird der gehighlightet. Das ist das, wie wie er Skoda macht. Das ist das, wie Sublime das ursprünglich gemacht hat. Und das ist relativ einfach zu generieren. Ja, es ist reeckics, das muss man jetzt sagen, muss man können, kann ich nicht. Gehört son bisschen dazu. Und prinzipiell haben wir innerhalb von Jet Braines Textmade Support. Also wenn zum Beispiel, wenn man Marco das eBay Framework mal benutzt hat, da gibt's Dokumentationen, wie Du das in Via Code aufsetzt und wie Du das dann in Webstone aufsetzt. Die Dokumentation sagt dann, ja, hier ist halt das und so kannst Du's im Webstone Sprich, wir haben auch in Jetbrains IDEs Support dafür. Das wird von manchen auch genutzt. Und das wäre auch mein Ansatz tatsächlich für sonen ersten Wurf, weil diese Textmade Dateien werden in der Regel von den Frameworkwantainern bereitgestellt. Angior macht das, Astra macht das, View macht das. Und das im Endeffekt müssen die das machen, via Code Support anbieten zu können. Und darüber hast Du primär das Syntax Highlighting. Das Problem damit ist, da die die Möglichkeiten, die Du damit hast, sind halt relativ limitiert. Also was ich halt vorhin erwähnt hatte, dass Du halt irgendwie semantisches Highleting anbietet. Hey, das hier ist eine spezielle Variable. Das kannst Du halt über eine nicht abbilden. Plus, dass es auch son bisschen in Limitation geht, wenn Du jetzt irgendwie, grade im Webbereich gibt's ja dann das schon mal, dass Du halt irgendwie sagst, okay, ich leg hier eine Variable an und die hat halt oder so was, also CSS. Das lässt sich halt auch nicht gut abbilden. Das ist dann halt auf einmal nur noch 'n String. So. Das sind son bisschen die Limitationen, die Du hast und prinzipiell, wenn wir jetzt in Nuancen sprechen, ist langsamer als AST. Also wenn wir von Performance reden, hat da Limitation, auf der anderen Seite wahrscheinlich nicht genug, zu zu rechtfertigen für gewisse gewisse Technologien zu schreiben. Und ich kann da aus eigener Erfahrung reden, weil wir haben das für Astro gemacht. Astro ist quasi JSX, nur nicht so ganz. Und im Endeffekt hattest Du uns knapp drei Monate gebraucht, 'n 'n vernünftigen dafür zu schreiben. Und das jetzt im Vergleich zu setzen für, wir haben weniger als ein Prozent Nutzerzahlen in für Astro in Webstorm, das Kosten Nutzen Verhältnis steht einfach in gar keinem Verhältnis. Ja. Deswegen, da hätte man einfach meiner Meinung nach sagen müssen, okay, Astro ist eine interessante Technologie, wir wollen das anbieten. Lass uns die Textmetdatei benutzen, lass uns den LSP benutzen und das ist es halt für den ersten Wurf. Wenn die Nutzerzahlen steigen, kann man darauf aufbauen immer noch, und das ist jetzt son bisschen, was wir grade mit View und Angular und im Allgemeinen machen, wir haben noch keinen supercoolen Namen dafür, wie wir das bezeichnen, deswegen nenn ich das jetzt einfach mal Hybrid Mode, dass wir im Endeffekt Teile vom LSP benutzen, für zum Beispiel Korrektheit sicherstellen zu können, was halt Typevaluationen angeht. Dass wir einfach auch gewisse Features, die Nutzer erwarten, die der Language Server bereitstellt, auch unterstützen können. Gleichzeitig aber basierend dann auf unserem deutlich komplexere Refacturings anbieten können zum Beispiel, als dass das möglich ist in 'nem LSP. Oder zum Beispiel 'n 'n gängiges Ding im Webbereich ist, wenn das der Dateiname besonders wichtig ist. Der LSP als Protokoll hat keine, irgendwie, hey, der Dateiname hat sich hier geändert. Das funktioniert bei typecript so halbwegs, weil's kein LSP ist, aber wenn ich einfach 'n nativen LSP Client entwickeln Server entwickeln würde, kann ich nicht reagieren, hey, die Datei heißt jetzt nicht mehr, sondern. Und nun das ist son bisschen, wo wir dann darauf aufbauend halt in diesem hybriden Mode sagen können, okay, hier sind Features, die vom Language Server kommen, einfach als Baseline, gleichzeitig aber, hey, das sind Features, die wir bereitstellen, die Du als Mehrwert kriegst, dadurch, dass Du halt Webstormen oder andere JetBrainS Produkte nutzt. Punkt. Das Gefühl, ich hab mich jetzt für fünfzehn Minuten am Stück geredet.
Jan: Nee, sehr oft. Ja, aber dafür bist Du ja
Dave: hier, weißt
Jan: Du? Wenn die Leute nur noch was hören wollen würden, dann würden sie die normalen News folgen hören, so.
Jan-Niklas: Ja, stimmt.
Dave: So nämlich. Ich ja ich hab noch mal eine Frage und zwar vielleicht auch 'n bisschen Richtung in in deine Position bei Jet Braines. Du hast explizit grade auch Astro erwähnt, ne. Der Aufwand, er war gigantisch, er hat sich gar nicht gelohnt für diese einen Prozent. Und da geht's son bisschen auf wahrscheinlich, was deine Rolle auch sehr stark ausmacht, 'n bisschen so, wie evaluiert man Features, ne. Also natürlich sone IDI entwickelt sich logisch logischerweise immer weiter. Es gibt immer neue Anforderungen, neue Frameworks, neue Sprachen und so. Und wie stellt ihr da eigentlich sicher, dass neue Features oder auch Tools, die ihr entwickelt, dann auch den realen Bedürfnissen der User dann entsprechen so? Also Du hast ja gesagt, ihr ihr ihr messt zum Beispiel auch so Sachen was. Also habt ihr da gewisse Metriken und und Methoden, so was auszuwerten oder Ja. Oder entstehen die Features grade durch dich irgendwie in enger Kommunikation mit der Community? Also wie ist so dieser Prozess dahin?
Jan-Niklas: Das ist eine superspannende Frage, weil im Endeffekt, was man, wie Du das richtig gesagt hast, ne, im Endeffekt, wir stellen halt die die die Tools bereit, aber wirklich unsere Entwickler schreiben halt Java und Coptline Code und nicht Astrocode oder so was. Deswegen ist es teilweise halt schwierig zu identifizieren, okay, was macht Sinn? Das ist bei IntelliJ oder bei unserem IntelliJ Department ganz anders. Die nutzen Java, die nutzen Kotelyn, die nutzen IntelliJ. Für die ist das deutlich einfacher, da irgendwie festzustellen, oh, hier, das Pattern benutze ich siebzehnmal am Tag. Das wär irgendwie cool, wenn ich das einfacher machen würde. Mhm. So, deswegen, was für uns bei Webstone ganz wichtig ist, ist enger Austausch mit der Community. Deswegen bin ich auch über jeden Nutzer froh, der halt unsere, wir nennen die EIP Version, Early Access Programm, also quasi unsere Beta, bevor wir einen Release machen.
Dave: Mhm.
Jan-Niklas: Ich bin froh für jeden Nutzer, der das testet, weil einfach es gibt so viele unterschiedliche Kombinationen, die Du möglicherweise haben kannst. Das ist fundamental anders, wenn Du und fünf dot fünf benutzt, dann während Du und fünf Punkt vier benutzt zum Beispiel. Deswegen und diese Komplexität, welche Möglichkeiten Du hast, ist einfach fast nicht für uns abbildbar. Deswegen, das ist 'n ganz, ganz wichtiger Kommunikationskanal. Unsere existierenden Nutzer, Was machen die? Wie nutzen diese Software? Was sind die Probleme? Wie können wir deren Arbeit leichter machen? Das andere, was wir natürlich machen, ist, dass wir halt, wir haben 'n jährliches Survey, wo wir halt gucken, okay, was hättest Du gerne? Was brauchst Du? Was was fehlt dir? Welche Technologie nutzt Du? Das ist freiwillig und weil's, wir treiben das, im Endeffekt sind das bereits unsere Nutzer. Sprich, wir, es fehlt halt eine ganz große Menge von, okay, was sind andere Nutzer, die vielleicht auch irgendwelche Features bräuchten oder, ne? Klar. Das andere, was ich primär versuche, weil ich hab halt den Webentwickler Background im Gegensatz zu unseren Kollegen, die halt Java und Gotlin schreiben, ist, dass ich halt grade viel irgendwelche Sampleapplikationen schreibe, irgendwelche Testcode, irgendwelche Form von Beispielprojekten. Auf der einen Seite ist das cool, halt Content anbieten zu können, hey, hier ist das coole Feature in Webstome, was deine Arbeit deutlich leichter macht. Auf der anderen Seite bin ich dadurch halt im Endeffekt Nutzer null für gewisse Features. Zum Beispiel eine Sache, wir hatten im letzten Release für Routing. Also sprich, wenn Du irgendwie benutzt, da kannst Du Dateien anlegen, die ja, wenn die in 'nem gewissen Ordner sind, werden die einfach als Datei generiert. Das das Framework hat das so inhärent eingebaut. Wenn Du irgendwie, ich sag jetzt mal, im Page eine Indexdatei legst, dann wird das eine eigene Webseite, die Du halt direkt annavigieren kannst.
Dave: Mhm.
Jan-Niklas: So, wenn Du jetzt aber dann innerhalb des eines Projekts bist, kann ein Language Server nicht sagen, hey, das ist halt diese Datei, hier ist der Pfad dazu. Innerhalb der IDI können wir das halt schon. Deswegen, das war halt so sone Sache, okay, Du hast jetzt hier 'n Link und dann wird halt angezeigt, hey, möchtest Du zu der Datei navigieren? Und dann kannst Du halt auch über sagen, okay, springen direkt zu dieser Datei. Das war halt eine Sache, die ich dann direkt getestet hab mit mehreren Frameworks und dann halt festgestellt habe, okay, der Support, den wir anbieten, funktioniert leicht anders. Also zum Beispiel für Next funktioniert's 'n bisschen besser als für Remix, funktioniert 'n bisschen besser als für Next. Aber dieses Feedback hab ich dann genommen und unseren Entwickler mitgeteilt, sodass wir halt sagen können, okay, wir evaluieren jetzt, wie viel dieses Feature genutzt wird. Ist das 'n valides Feature? Ist das 'n valider Use Case, der halt Sinn macht, zu fine tunen zu verbessern? Genauso, was ich halt supercool fände, ist, wenn Du halt sagen würdest, hey, ich möcht hier, Du bist in deinem Link Tag, also deinem a-Tag oder was auch immer und ich möchte jetzt den, also Du sagst quasi auf den String, wo Du hinnavigierst. Wenn wir wissen, das mapt auch eine Datei, können wir genauso auch sagen, hey, wir nennen die Datei gleichzeitig
Dave: Klar.
Jan-Niklas: So, das wär zum Beispiel 'n super cooles Feature. Wenn aber jetzt kein Mensch dieses Feature nutzt, brauchen wir die Arbeit nicht da rein investieren. Und deswegen, was wir machen, am Anfang, wenn Du Webzone das erste Mal startest, kommt zum Pop up, hey möchtest Du Nutzerdaten teilen. Und mit diesem, wenn Du das machst, was ich sehr zu schätzen weiß, wenn Du das tust, können wir tracken, a zum Beispiel, was wir tracken, ist gewisse Frameworks, die benutzt werden. Darüber wissen wir zum Beispiel, type Script ist das dritt oder die dritthäufigste NPM Dependency, die wir im Workstorm haben. Gleichzeitig können wir aber auch darüber tracken, welche Features innerhalb der ID benutzt werden. Benutzt Du, benutzt Du? Wir haben zum Beispiel Live Templates und wie heißt nicht, dass Du sagen kannst, hey, generier mir hier direkt eine Komponente oder so was.
Jan: Aber das ist ja superfein granular. Also es gibt ja eine Quadrilliarden verschiedener Aktionen, die ich da drin ausführen kann.
Jan-Niklas: Das ist das Schöne, dass im Endeffekt wie architektonisch aufgebaut ist. Es ist halt sehr modular, dass Du halt sagen kannst, wirklich, also im Endeffekt Plug ins sind eigentlich nur Hooks in in gewisse Bereiche, dass Du dann sagen kannst, hey, ich hab hier eine Codeaction zum Beispiel und eine Codeaction ist eben in unserem Fall, sorry, Shift Enter. Sorry, ich hab mein mein, ich auf der auf dem Keyboard weiß ich genau, welche Tasten ich drücken muss.
Dave: Es ist immer nur, man hat man, aber man kann nie sagen, was es genau für Tasten sind.
Jan-Niklas: Kann Navigation Enter sein, aber ne, also im Endeffekt, wir haben halt gewisse Hooks und über diese Hooks kannst Du dann abbilden, okay, diese Hook wurde benutzt. Und was da auch dazukommt, ist halt GDPR. Insofern zum Beispiel, wir können nur als trackenlist tracken. Sprich, wir sagen halt explizit, oh, wir sind interessiert, wie sind die Nutzerzahlen für Angular? Gut. Wir können das aber nicht pauschal machen bei GDPR.
Jan: Interessant. Cool. Jetzt sind wir schon ganz schön lange unterwegs. Ich hab eigentlich noch zwei Themen, über die ich gerne sprechen wollte. Und ein Thema, über das wir natürlich irgendwie auch sprechen müssen, ist müssen, ist AI so, ja? Mhm. Ich hab da noch keine feste Meinung zu, glaub ich, ja? Ja. Aber ich befürchte, dass halt irgendwie AI jetzt einfach so in alle IDIs reinkommt und sie sich dann besonders dafür feiern. Und das aber eigentlich, wenn man da mal genau hinguckt, sehr große Unterschiede in der Implementierung und dann am Ende auch in der Qualität des Outputs und der Usability für den Entwickler irgendwie am Ende des Tages haben kann so, ja. Und da gibt's ein paar IDIs, die gehen da, ich sag mal, konservativer vor. Dann gibt's 'n paar, ich glaub, das darf man so sagen, so wie CursA, die da halt einfach all in und sich darüber so definieren, ja. Ja. Wo seht ihr euch denn irgendwie auf diesem Spektrum aktuell und vielleicht auch perspektivisch?
Jan-Niklas: Also ganz pauschal erst mal meine persönliche Meinung. Ich denke, ich sehe eher zum momentanen Zeitpunkt als eine Hilfsschütze, weil's einfach noch nicht die Qualität hat, die ich für meine Arbeit brauche. Ich denke aber, dass es perspektivisch 'n Tool ist, das wir als Entwickler nutzen werden müssen, konkurrenzfähig zu bleiben. Ist halt, zu 'nem gewissen Grad wird's irgendeiner eine Erwartung, dass Du 'n eine gewisse Form von Output lieferst. Und diese Form von Output wirst Du erreichen, a, entweder Du bist 'n extrem guter Softwareentwickler oder b, Du kannst gut mit deinen Tools umgehen und das Tool wird und eins dieser Tools wird der AI sein. Genauso wie halt heutzutage jeder erwartet, dass Du kannst, wird irgendwann meiner Meinung nach jeder erwarten, dass Du mit 'nem, dass Du AI nutzt und damit deine Effektivität steigerst. Das tut mir ganz furchtbar leid, grade für Juniorentwickler, weil ich glaube, dass das das deutlich härter für die macht. Aber das, glaub ich, ist grade, wo wir hinwandern.
Dave: Kurze Frage, inwiefern Hertha macht?
Jan-Niklas: Na ja, im Endeffekt, wie wie lernst Du eine, also wie zum Das kann jetzt sein, dass das meine persönliche Meinung ist, aber wie ich eine Programmiersprache lerne, ist Trial and Error.
Dave: Mhm.
Jan-Niklas: Und Trial and Error ist nicht gerade sonderlich effektiv.
Jan: Also ich ich glaub, warum Dave so so verwirrt war irgendwie von von der einen Erschrecknis her. Na ja, auch als Studioentwickler kannst Du ja prompton, so. Ja. Aber die also Und auch als Studioentwickler kannst Du halt mit 'nem prompt irgendwie schnell Code erzeugen, aber Du lernst halt nicht so viel dabei.
Jan-Niklas: Genau. Du wirst, dir wird das Verständnis fehlen. Und ja, Du wirst Code ausliefern können, aber der Code wird nicht funktionieren oder wird halt Fehler haben und dann wirst Du nicht in der Lage sein, diese Fehler ausarbeiten zu können. Mhm.
Dave: Okay, valider Punkt. Gleichzeitig kann man natürlich auch AI ein bisschen so nutzen von wegen so, hey, erklär mal, wie funktioniert das? Warum funktioniert das eben nicht und so? Und dann, dass Du da son bisschen in die Tiefe reingehst, aber also grundsätzlich versteh ich den Punkt schon.
Jan-Niklas: Ich glaube, da ist tatsächlich das son bisschen dasselbe, wie wenn Du selbst 'n Textlaut vorliest. Du hast keine Ahnung, Du Du konzentrierst dich so sehr auf das Lesen, dass Du nicht verstehst, was der Inhalt davon ist.
Dave: Mhm.
Jan-Niklas: Genauso glaub ich auch, wenn Du wenn dir jemand, wenn dir 'n Textprogramm erklärt, wo ist jetzt der Fehler und danach funktioniert's, glaub ich nicht, dass Du dir die Zeit nimmst, sich hinzusetzen, okay, wo war jetzt das eigentliche Problem und warum funktioniert's jetzt der neue Kurs? Du musst einfach nur sagen, oh ja, okay, jetzt funktioniert's.
Jan: Mhm.
Jan-Niklas: Bin ich ehrlich, ich würd's zumindest so machen. Ich würd da jetzt keinem irgendwelche falsche Vorstellungen geben, aber so würde ich's machen. Wenn's funktioniert, funktioniert's.
Dave: Ja, passenderfeld weiß ich.
Jan-Niklas: Sich dann zurückzunehmen und zu sagen, okay, warum funktioniert's jetzt? Weiß ich nicht.
Jan: Ja, ich glaub, ist halt schon so, ne? Also auch Junior Devs werden irgendwie produktiv aber sie werden halt irgendwie dreimal so lange brauchen wie heute, irgendwie Mitlevel oder Senior Devs zu werden, weil einfach superviel auf der Strecke bleibt. Und das wird halt sehr spät erst auffallen, weil jeder, der 'n neuen Junior Dev bekommt, sagt ja, ja, ja, er schreibt ja sein Zeug und irgendwie die Anwendung fällt am Ende raus und und und funktioniert. Und wenn Du nach drei Jahren dann fragst, dass er mal die Architektur von dem Stack irgendwie erklären soll und dann da blank zieht, das wird dann halt irgendwie das Problem.
Jan-Niklas: Ja. So, die die andere Frage, die Du gestellt hast, ist, okay, wie positionieren wir als Chef Brains zum Thema AI? Und ich bin ganz transparent, AI ist 'n sehr strategisches Ziel von uns, weil wir das eben wie wie schon gesagt, als son Tool, die Produktivität steigern zu können, betrachten. Ich will auch gleichzeitig sagen, die Features, die wir bis jetzt anbieten, sind primär, dem Markt momentan gerecht zu werden. Das sind nicht die Features, die ich denke, die sind, die wir wirklich erreichen wollen. Also was Du halt momentan viel hast, ist ja, okay, erklär mir mal den Code und so was und das ist cool. Das ist aber, glaub ich, nicht, wo die wo wirklich der Mehrwert von AI im Endeffekt steckt. Der Mehrwert von AI meiner Meinung nach ist zum Beispiel größere holistische. Dass er also, ne, wie wie Du in der Regel. Bist Du ja machst, ist, Du änderst eine Datei und dann möchtest Du 'n ähnliches Pattern auf siebzehn andere anwenden oder eben im im Enterprise Ecosystem vielleicht auch siebzehnhundert. So, das dieses Pattern anwenden, das ist was, wo AI extrem gut dran ist. Und grade wenn Du dann die notwendige UX hast, dass Du halt eben sagen kannst, hey, hier ist das vor und danach, glaube ich, wär, ist das wirklich 'n Use Case, wo wo's spannend wird. Genauso das das generelle Problem meiner Meinung nach ist halt trotzdem irgendwie die Qualität. Du hast halt, Du hast unterschiedliche Datensätze, wie wie gut eine 'n Model, sorry, wie wie gut 'n AI Model halt trainiert werden kann. Also ne, JavaScript ist da hervorragend. Du hast superviel Beispielcode und so und ganz viele Beispiele auf GitHub oder so, aber halt eine React neunzehn Anwendung sieht halt anders aus wie eine React achtzehn Anwendung, sieht halt anders aus wie eine React siebzehn Anwendung. Und diese Differenzierung, 'n Kollege von mir hatte das letztens angebracht und das fand ich ganz interessant, ob wir glauben, dass durch AI neue Sprachen weniger interessant sein werden. Also ne, und das ist auch 'n Problem, was wir bei Jebrance haben, für Rust gibt's einfach keinen, der der halt öffentlich zugänglich ist, sodass wir halt 'n guten Model trainieren könnten oder so was. Deswegen, die diese Fragestellung, okay, haben neue Programmiersprachen es demnächst schwerer, Fußzupassen im Ecosystem, weil sie nicht von r a unterstützt werden. Und deswegen halt vielleicht doch klassischere Sprachen, die halt lange unterwegs sind, PHP, Java, dot net, doch wieder mehr Interesse kriegen dahingehend, einfach weil das Tooling besser ist. Weiß ich nicht. Fand ich aber eine ganz interessante Fragestellung. Was meine das andere, was meine persönliche Meinung zum Thema AI ist, das das Problem ist halt son bisschen, Du musst zum gewissen Grad immer online sein und es muss zum gewissen Grad sehr viele Ressourcen zur Verfügung stehen. Das, wo diese Ressourcen herkommen, ob das jetzt irgendwo aus der Cloud ist oder so was, ist jetzt mal erst mal dahingestellt. Aber am Ende des Tages ist trotzdem immer eine asynchrone Prozedur. Hey, erklär mir den Text. Das geht zum Model. Das Model kommt zurück. Hier ist die Erklärung. So. Manche Sachen, die momentan als AI Features angeboten werden, brauchen keine AI. Das ist meine ganz persönliche Meinung. Also zum zum Beispiel, was war 'n das jetzt, ich glaub, CursA hatte das jetzt letzte Woche oder so was, dass die jetzt auch automatisch den Import passend von AI generieren lassen. Also wenn Du hier Code generierst, ist die auch automatisch den passenden Import dazu rausfinden. Als Du als vermutlich Webstore oder Jetberines, Du zerlass darüber, weil das halt einfach automatisch aufgrund von statischer Codeanalyse passieren kann. Aber das solche Sachen werden halt als AI Features verkauft momentan, wo ich denke, da dafür muss ich nicht auf eine asynchrone Operation warten, dafür muss ich nicht Strom und Energie und irgendwelche Rechenzentren belasten. Das ist halt so son bisschen die Sache, ich ich, mein Gefühl ist grade, ist wirklich sehr experimentell mit AI. Okay, was sind valide Use Cases? Und keiner weiß so richtig, was valide Use Cases sind. Und grade findet halt sehr viel Spekulation statt. Ich bleib aber dabei, ich glaube, dass das 'n Tool wird, was wir als Entwickler nutzen werden müssen.
Jan: Also ich kann für mich berichten, dass das Meister, was ich eigentlich mit a I in meiner ID e macht, superbanale Sachen sind und relativ wenig so komplette Koderzeugung, sondern eher so, weißt Du, ich bin in 'nem Projekt, das ich's nicht kenn oder in der Sprache oder 'nem Framework das nicht kenn. Also hey, hier ist ein, weiß nicht, ein Snippet in type Script und so will ich das jetzt machen. Kannst Du das mal bitte für mich irgendwie in Go portieren, dass es hier in diese Anwendungen passt? Weil ich ich ich als Entwickler kann ja quasi zum Ausdruck bringen, was ich möchte. Ich kann es vielleicht nur nicht in diesen Kontext passend übersetzen so. Und das kannst Du für mich eigentlich machen. Und das ist ja eigentlich was, wo ich mir perspektivisch vorstelle, wir eigentlich kein angepasstes Model brauchen, was auf 'nem riesen GPT vier o irgendwie aufbaut und eigentlich superviel schon mitbringt, sondern es können ja superkleine Instruct Models eigentlich sein, die halt sehr viel Syntax und Sprachfeinheiten beherrschen, aber die halt nicht komplett irgendwie auf dreihundert Billionen Tokens vorher trainiert worden sind.
Jan-Niklas: Das ist tatsächlich ganz spannend, dass Du das anbringst, weil das ist eine der Sachen, die wir mit in innerhalb von machen. Wir wir haben 'n Plug in, das heißt. Denn der Name ist 'n bisschen fragwürdig und hat viel Historie. Aber was wir da machen, ist im Endeffekt, wir identifizieren, okay, Du benutzt grade JavaScript oder was auch immer. Und dann installieren wir ein kleines Modell, was gewisse Features bereichert. Die werden dann völlig lokal ausgeführt. Und das kann halt zum Beispiel so was machen wie, hey, generieren wir einen variablen Namen zum Beispiel. Oder bei CSS funktioniert's hervorragend. Hey, ich hab hier, keine Ahnung, Du bist in 'nem Form und sagst, hey, fängst halt an irgendwie den ID Log in zu geben, dann kann der direkt impliziert sagen, okay, das ist eine Log in Form. Und grade halt, wie CSS funktioniert, CSS ist halt nur so so statisch analysierbar. Für solche Sachen find ich das ganz cool. Und da kannst Du tatsächlich auch mit kleineren, lokalen Modellen sehr gute Ergebnisse generieren. Ja, das ist eine der Sachen, womit wir grade 'n bisschen experimentieren, okay, was sind da die Limitationen? Wie groß sollte son Modell sein? Und das muss man jetzt auch fairerweise sagen, für JavaScript, was halt deutlich komplexer als CSS ist. Brauchst Du halt 'n bisschen 'n komplexeres Modell. Aber den Ansatz find ich ganz interessant halt zu sagen, okay, das sind die Sachen, die wir lokal anbieten können, die gut funktionieren. Das sind die Sachen, wo halt viel Kontext wichtig ist, wo viel Daten wichtig ist und das wird dann halt eben asynchron ausgeführt. Und grade wie Du das halt gesagt hattest zum Beispiel, hey, generier mir, hier konvertiere die Datei von Java auf Go oder so was. Das ist nichts, wo wo Du aktiv tipperst gerade. Sprich, das ist jetzt auch nichts, wo Du quasi keine Latenz erwartest. Also es sind halt so Sachen, die halt berücksichtigt werden müssen.
Jan: Ja. Ein Punkt, über den ich auch noch reden wollte, ist Geld. Alle reden nicht mehr über Geld.
Jan-Niklas: Mhm. Geld ist 'n guten Fall.
Jan: Dave guckt schon erwartungsvoll. Was kommt jetzt
Dave: hier an? Was kommt jetzt?
Jan: Nein, nein, nein, das es ist ja so. So, wenn Du hier dich irgendwie als Entwickler schön feierst, ja, und dir irgendwie einredest, dass Du irgendwie immer das neueste MacBook irgendwie kaufen musst, irgendwie produktiv zu sein und da gerne mal, also weiß nicht, ich glaub das MacBook, was neben mir steht, hat schon irgendwie viertausend Euro kostet oder so was, ne.
Jan-Niklas: Sank.
Jan: So, und das das machst Du irgendwie, ohne mit der Wimper zu zucken und so. Und dann wollen so Development Tools auf einmal auch Geld von dir und das sind, ich weiß ehrlicherweise grade nicht, was ich für meine Lizenz bezahle im Jahr, aber lass das vielleicht mal so zwischen zehn und zwanzig Dollar im Monat oder so was sein, Ja. Ja. Und dann so, oh, also das ist für für Software, das ist ja aber schwierig. So, die kostet ja quasi gar nichts in der Herstellung. Wie soll ich denn da irgendwie Geld für bezahlen so, ja? Genau. Und selbst wir als Entwickler, die alle irgendwie jeden Tag Software schreiben, tun uns ja irgendwie oftmals sehr schwer irgendwie Geld für Software auszugeben und auch Firmen, die mit Software Geld verdienen, tun sich oftmals sehr schwer für Software für ihre Softwareproduktion irgendwie Geld auszugeben, Ja, das wär so, wie als würd VW sagen, na ja, Autos verkaufen wir gerne, aber für diesen Stahl im Einkauf, das sehe ich irgendwie nicht ein, dass ich da irgendwie was was zahlen müsste oder so, ja? Ja. Und wie wie erlebt ihr das denn? Weil ihr verkauft ja primär, ich wollt grad sagen an Entwickler, aber das wahrscheinlich gar nicht richtig, weil ihr verkauft ja primär an Firmen so, ne, weil wahrscheinlich sind fünfundneunzig Prozent von einem Geschäft irgendwie große Volumenlizenzen oder so was, Ja. Wo man eben eine ganze Company überzeugen muss, sagen okay, guck mal, kauft doch mal hier für deine ganze Dev Abteilung irgendwie jetzt dieses IDI Produkt und dann sagt er, ja, aber die können doch auch Notepad benutzen oder oder Nano oder sollen sich mal nicht so anstellen, ja? Warum brauchen die überhaupt irgendwas? Wie wie wie läuft das Modell bei euch? Und dann können wir einmal darüber sprechen und dann vielleicht auch noch ganz kurz, weil ich das mein Lieblingsfeature eigentlich von jeder JetBiends ID ist das das Vollberg Licencing, aber vielleicht erst mal so über wie ist so Marketing und und Verkauf und und wie erklärt man diesen Wert eigentlich?
Jan-Niklas: Da da ich find diese Diskrepanz auch einfach faszinierend, bin ich ganz ehrlich. Weil grade wir halt als Entwickler sind doch in der Position, dass wir eigentlich, ne, wir grade auch in Deutschland, wir verdienen gutes Geld, kann man echt nicht anders sagen. Aber dann diese Diskrepanz zu sagen, ja, nee.
Jan: Moment, Manuel, was sagt der, als er in Amerika sitzt, so ja, wo irgendwie
Jan-Niklas: Ich ich hab auch in Deutschland
Jan: gearbeitet. Er ist wirklich auch schon in Amerika gearbeitet. Das ist so, ja, ist okay. Ich kann
Jan-Niklas: mich nicht beschweren. Aber
Jan: das
Jan-Niklas: ist nicht das Thema. Das das eigentliche Thema ist, ich find das ganz faszinierend, dass wir halt sagen, ja, wie Du's halt gesagt hast, ne, dreitausend Dollar fürn MacBook, gar kein Problem, ne. Hier ist hier ist meine Kreditkarte. Aber halt irgendwie, hey komm, hier ist eine Software, die ich acht Stunden am Tag benutze, idealerweise. Boah, dafür jetzt nur nur für fürs Recording, Webstome in der Individuallizenz, also wenn Du als Privatperson sagst, hey, das Tool ist so klasse, das will ich haben, sind sieben Dollar im Monat oder Euro. So. So, okay. Du bist bereit zu sagen, hey komm, dreitausend Dollar fürn MacBook, was, sind wir ehrlich, in der Regel zwei, drei Jahre, dann krieg kaufst Du dir Neues oder holst dir Neues oder kriegst Neues, wie auch immer, ne. Das sind deutlich mehr als sieben Dollar im Monat. Ich bin zu faul, dass Du
Jan: 'n halbes Netflix. Man muss es ja immer so rumsagen.
Jan-Niklas: Das 'n Kaffee bei Starbucks, ne. Also wenn man das einfach mal in diesem Vergleich setzt, weil ich versteh einfach diese Proportionen nicht,
Dave: dass Du sagst, hey, hier ist 'n Tool, das würde mich
Jan-Niklas: effektiver in meiner Arbeit machen. In der Arbeit, die ich acht Stunden am Tag mache, auch wenn wir nicht acht Stunden am Tag Software schreiben, sollte doch 'n Großteil im Endeffekt der Arbeit sein als Softwareentwickler, dass Du Software entwickelst. Und ich versteh das nicht, wo dieses Mindset herkommt. Und ich witzigerweise, ich hab vor zwei Wochen 'n Blogpost darüber geschrieben, weil mich das aufgeregt hat, dass Leute, also da war der konkrete Fall, NX hat 'n Teil deren Produkt, deren Produkt, was Open Source war, gesagt, hey, hier, wir bieten jetzt Enterprise Support dafür an und haben da 'n Preisschild drangeklebt. Und die Leute waren haben sich aufgeregt, ja, es war Open Source und jetzt jetzt ist da 'n Preisschild dran. Und ich so, ja, die das ist eine Firma, die muss Geld machen, haben Softwareentwickler, die bezahlt werden müssen, genauso wie Du. Und wenn da jetzt deine Firma irgendwie zwanzig Euro im Monat aufn Tisch schlägt, dann ist das okay. Ich ich versteh das nicht, wo dieses Mindset herkommt. Ich als Softwareentwickler möchte bezahlt werden, ich als Softwareentwickler möchte aber nicht für andere Software bezahlen. Und wir wir können gerne eine ganze Episode irgendwann über Open Source auch machen, wie warum das nicht funktioniert und warum da Geschäftsmodelle etabliert werden müssen. Aber das verstehe ich nicht. Gerade wenn Du halt Du kannst ja diese Rechnung, ist ja wirklich einfach, wenn Du halt sagst, hey, ne, Code ist ja doch in der Form messbar, wenn Du jetzt sagst, hey, ich kann mehr Features entwickeln in der gleichen Zeit oder ich kann mehr, selbst wenn Du auf Basis das runterbrichst, hey, ich kann mehr Zeilencode in weniger Zeit schreiben, dann ist die Rechnung, wann sich sieben Euro im Monat rentieren, relativ simpel. Und ich will jetzt auch für für Transparenz sagen, manche Leute kommen sehr gut mit Neovim, manche Leute kommen sehr gut mit VIS Code. Das ist alles valide, da will ich gar nicht sagen, aber wenn deine Argumentation ist, Webstorm ist mein das Tool, was ich denke, ist gut und das benutze ich und ich denke, dass mich das produktiver macht, dann sollten sieben Euro im Monat nicht der ausschlaggebende Faktor sein, wenn Du gar keinen Stress damit hast, dir ein MacBook zu kaufen. Also diese diese das Gespence versteh ich einfach nicht. Auf der gleichen Seite, was was Du vorhin gesagt hattest, das das stimmt natürlich. Also unsere Individuallizenzen, das sind, ich glaub, weniger als zwanzig Prozent von Nutzern, die wirklich privat sagen, hey, ich bezahl dafür privat unsere Firmenlizenzen, wo wir auch andere Konstrukte haben, das wie halt Lizenzen abgebildet werden und dass Du halt sagen kannst, okay, es ist nicht personengebunden, sondern firmengebunden und solche Sachen. Das sind achtzig Prozent. Insofern ja, unser primäres Geschäft kommt von Firmen, muss man einfach fairerweise sagen. Und ich bin auch ehrlich, wenn Du als Softwareentwickler eingestellt wirst, ich will nicht dein Geld haben. Ich denke nicht, also so wie ich halt denke, dass wenn halt 'n Handwerker irgendwo auf eine Baustelle geht, dass er 'n Hammer bereitgestellt bekommt von seiner Firma, denk ich auch, solltest Du 'n MacBook bereitgestellt bekommen, wenn das dich produktiver macht. Und Du solltest halt auch die Software bereitgestellt bekommen, die dich am produktivsten macht. Und wenn das besonders, sollte das halt eben auch sein.
Jan: Ja. Also ich kann sagen, dass ich tatsächlich privat meine Lizenz auch gekauft hab vor ewigen Jahren schon mal, ja. Und dass mir unter anderem durch das Lizenzmodell halt leichter gefallen ist so, ja? Weil ich tu mir ehrlicherweise immer sehr schwer mit diesem klassischen SAS Modell so. Ich bezahle hier Software, ich finanzier die Entwicklung, ich finanzier den den Vertrieb, ja, alles irgendwie mit. Und sobald ich aufhör zu bezahlen, war's das halt irgendwie so mit der Software. Also das war's irgendwie SAP und Adobe irgendwie groß gemacht haben so, ja? Dass das irgendwie, ich sag mal zumindest fragwürdig aus individueller Sicht. Für Firmen hat das noch mal andere Hintergründe bestimmt. Aber ich find halt euer Lizenzmodell zu sagen, na ja, wenn Du jetzt hier diese Software ein Jahr quasi bezahlt hast und jetzt aufhörst zu bezahlen, dann darfst Du zumindest den Stand, den Du bezahlt hattest, behalten. So, Du kriegst dann ab morgen halt keine Updates mehr. Aber das, was hier die Version war, die Du gekauft hast, die hast Du finanziell unterstützt. Da hast Du da einen Beitrag zu geleistet. Die kannst Du jetzt eben bis zum Sankt Nimmerleins Tag irgendwie weiter benutzen, so, ja. Und wenn dein Abo drei Jahre läuft und Du nach drei Jahren aussteigst, dann darfst Du halt die Version weiterverwenden, die am Ende deiner Laufzeit irgendwie da halt das das aktuelle oder das ein Jahr alt oder wie auch immer, genau, weiß ich jetzt auch nicht. Aber auf alle Fälle bekommst Du halt was, so, ja. Du stehst nicht mit leeren Händen da und das Mega fair. Find ich auf alle Fälle mehr gut. Ich würde mir wünschen, dass mehr Software das so machen würde, weil das a, wie Dave gesagt hat, irgendwie fair ist, ja, Du hast irgendwie 'n Beitrag geleistet. Du solltest irgendwas behalten können und am Ende ehrlicherweise ja auch dann euch nicht mehr groß wehtut. Ich mein, ihr habt damit Richtig. Geld verdient, ja. Ob ihr jetzt die eine Lizenz da überlastet oder nicht, sei mal dahingestellt. Und ja, wollt wollt ich nur noch mal 'n Shoutout geben. Jeder, der da draußen Software schreibt und grade über sein Geschäftsmodell vielleicht am Nachdenken ist, sollte sich das vielleicht da noch mal anschauen, ja.
Jan-Niklas: Danke. Nehm ich auf jeden Fall noch mal mit und werd das auch teilen, weil das ist, muss man fairerweise sagen, ist eine Sache, die wir halt regelmäßig diskutieren, weil es ist schon was, ja, andere Firmen machen's halt anders, warum machen wir das so? Aber ich ich seh das ganz genauso. Also ich denke, wir hätten mit 'nem bisschen besseren Namen die Ecke gekommen, weil es als Subscription das gängige Modell ist halt, wie Du halt sagst, bezahl einmal und wenn ich nicht mehr bezahle, hab ich halt nix mehr davon. Währenddessen, wir nennen das, was sind sehr für
Dave: klingt gut.
Jan-Niklas: Kriegst kriegst die Version, für die Du bezahlt hast, wenn Du nicht mehr bezahlt, kriegst halt nix mehr.
Jan: Das ist aber jetzt auch kein geiles Naming, ne, wenn Du das jetzt halt so auf die Website
Jan-Niklas: Ja, ich ich bin nicht Mark. Ich bin nicht Mark. Deswegen ich ich find das auch 'n 'n ganz charmantes Modell, weil Du so halt nicht dieses Gefühl hast, ey, okay, ich verlier jetzt was.
Dave: Ja. Ich ich find das ich find das sehr ich find das sehr schön, das Zitat dazu, und ne, zu der Frage, warum machen wir das so und die anderen anders so. Vielleicht muss man auch mit 'nem positiven Beispiel vorangehen. Das find ich eigentlich immer ganz gut.
Jan: Das das ist natürlich auch 'n 'n super Argument. Und was noch sagen wollt, den Kreis wieder zu schließen zu dem AI Thema eben, ja. Grade jetzt tun sich ja vielleicht auch noch andere Revenue