Technologieentscheidungen

Martin
Ja, hallo und willkommen zurück zum Sandpapier, die Episode Nr. 5. Wir sind auf halbem Weg zur Zweistelligkeit. Das Sandpapier ist unser Sandstorm Weekly, in dem wir wöchentlich Themen und Herausforderungen und Experimente besprechen wollen, denen wir so begegnen als Softwareentwickler in einer kleinen Agentur. Und heute habe ich mir ein Thema rausgesucht, das mich persönlich ganz besonders interessiert und das ist, wie wir eigentlich Technologieentscheidungen treffen unter dem Stichwort Surviving the Hypes. Also ich habe das jetzt schon öfter mal gelesen und musste jedes Mal schmunzeln, dass man so links und rechts mal schauen soll und beide, die da sitzen, werden in den nächsten drei Monaten ein Front-end-Framework veröffentlichen. Man muss sich nur entscheiden, welches man da nimmt. Und um das mal zu besprechen und tiefer zu erörtern, habe ich mir, wie immer, zwei Gäste eingeladen. Das ist zum einen der Manuel Lehner. Manuel, hi.

Manuel
Hi, Martin, grüß dich.

Martin
Und der Theo Salzmann. Theo, hi.

Theo
Hiho, sei gegrüßt!

Martin
Okay, lasst uns direkt hineinspringen in das Thema. Mich würde mal interessieren, ihr seid beide eher im Frontend unterwegs, ihr kennt euch aus mit diesem doch sehr hype getriebenen Umfeld. Wie geht ihr das an? Was ist für euch essentiell, wenn ihr euch Gedanken darüber macht, okay, wir kommen jetzt in ein neues Projekt rein, wir haben hier grüne Wiese, wir können bauen, was immer wir wollen. Und jetzt geht es los. Soll ich irgendwas im JavaScript-Bereich nehmen? Soll ich da vielleicht irgendwas Typisiertes nehmen oder doch lieber Elm? Oder nehme ich vielleicht was ganz anderes? Oder war CoffeeScript eigentlich super geil und nehme ich das einfach wieder? Oder ich weiß nicht, Manuel, vielleicht hast du Lust, uns da einfach mal ein bisschen Einblick zu geben.

Manuel
Ja genau, also das ist ja jetzt so eine spezielle Situation. Grüne Wiese ist ja eigentlich Optimalfall, wenn man sich komplett austoben kann. In der Regel gibt es ja meistens irgendwelche Rahmenbedingungen, an die man sich halten muss und man spricht eigentlich mit dem Kunden, was er eigentlich will, was er braucht und dann kann man erstmal so ein paar Sachen abstecken, welche Technologien vielleicht überhaupt gar nicht in Frage kommen oder was vielleicht ein bisschen besser geeignet ist. So dann hat man ja selber so ein paar Präferenzen meistens, was man gerne macht oder was man vielleicht gerade in so einem Kontext mit der Grüne Wiese, was man aber gerne ausprobieren würde und zum Beispiel für so in der Anbahnungsphase von Projekten, vielleicht sogar schon in der Angebotsphase, bauen wir ja oft Prototypen als Teil des Angebots und das ist eigentlich auch immer eine sehr gute Möglichkeit, Sachen einfach mal auszuprobieren, also so vielleicht neue Technologien, die wir, wo wir schon mal so ein bisschen rumgespielt haben und denken, das könnte sich gut eignen und das eignet sich dann gut, um sowas zu evaluieren. Und ja, ansonsten guckt man auch so aufs Team, welche Entwickler sind beteiligt an dem Projekt und was haben die für Voraussetzungen, also oder was haben die für Präferenzen, weil im Optimalfall sollte das Team dann schon so eine einheitliche Sprache sprechen oder da irgendwie zusammen auf eine Technologie gut abgestimmt sein.

Martin
Okay, Theo, wie gehst du das an?

Theo
Also ganz grundsätzlich bin ich da bei Manu, also ich glaube, wenn wir jetzt tatsächlich ganz konkret in den Frontend-Bereich gucken, dann ist beispielsweise so eine Technologie, die sich bei uns relativ stark etabliert hat, React, also zumindest wenn es in Richtung Frontend-Anwendungen geht, ich würde tatsächlich der Fragestellung ein bisschen anders begegnen wollen in der Hinsicht, also dieses Surviving the Hypes und dieses jeden Tag kommt ein neues JavaScript-Framework drauf. Mein Gefühl ist tatsächlich, dass das eine ziemlich krasse Übertreibung ist. Also natürlich ist es so, dass es ganz, ganz viele Libraries gibt, die da tagtäglich irgendwie rauskommen, aber es ist jetzt nicht so, dass es tagtäglich ein neues Framework gibt, auf das man sich einstellen müsste, meiner Meinung nach. Zwar wird da exploriert mit verschiedensten Variationen, sei es, wie du schon gesagt hast, sowas wie Elm oder eben auch einfach nur, dass das statische Typisierung mit in die JavaScript-Welt kommt durch Flow und TypeScript, aber auf der anderen Seite gibt es, meiner Meinung nach, zum Beispiel im Bereich Single-Page-Applications einfach eine ganze Reihe an total etablierten Libraries und Frameworks, also namentlich beispielsweise Angular, React, Vue.js ist auch relativ groß geworden in den letzten Jahren. Und das sind Sachen, die halten sich seit inzwischen, ich glaube React ist glaube ich fünf oder sechs Jahre inzwischen alt, super mature, hat ein tolles Ökosystem. Also ich habe gar nicht den Eindruck, dass da so wahnsinnig viel passiert und ich glaube wichtig ist eigentlich nur, dass man die Fühler so ein bisschen ausgestreckt hält, also dass man immer mal guckt und dafür versuchen wir ja bei Sandstorm auf verschiedenen Ebenen Räume zu schaffen im Sinne von, dass wir einerseits quasi uns einfache selbst, wenn wir Lust haben auch mal hier oder da mal eine Stunde oder zwei mit einem Thema zu beschäftigen, dann wie Manu schon sagte, dass wir tatsächlich auch einfach Prototypen nutzen, um Dinge auszuprobieren und was wir gerade aktiv als Projektmanagement-Konzept noch mit eingeführt haben, ist die Cool-Down-Woche, das ist gerade so ein Experiment, was wir mal starten wollen und auch da kann man beispielsweise einfach wieder mal sagen, hey, lass mich doch mal eine Woche im ausprobieren und gucken, was da mein Gefühl ist. Also das ist quasi die Art und Weise, wie wir neue Dinge finden, meiner Meinung nach und bei der Evaluation, das war, ich habe jetzt einen ziemlich großen Bogen gespannt, die Evaluation selbst, da kommt es mir drauf an, kann man das Tool sinnvoll verwenden, kann man damit sinnvoll wartbaren Code schreiben, ich behaupte, dass das sowohl bei einem Vue.js als auch bei einem Angular als auch bei einem React möglich ist und dann ist für uns halt relevant, was ist die Technologie, die unseren Denkmuster noch am nächsten ist, wo haben wir gegebenenfalls die meisten Leute, die damit leicht on zu boarden sind, wer hat da Bock bei uns drauf und dann starten wir da. Wir würden jetzt wahrscheinlich kein Framework nehmen, was erst seit gestern auf dem Markt ist, da ist einfach das Risiko zu groß, also in einem großen Projekt, das würden wir dann in einem kleinen vielleicht mal ausprobieren.

Martin
Ich würde da gerne mal ein Thema herausgreifen, das habt ihr beide erwähnt. Das ist das Prototyping. Wie stelle ich mir so ein Prototyping vor? Ich meine, das ist ja am Ende klar, kommt irgendwie ein Prototyper heraus. Das sollte jetzt niemanden verwundern. Aber da gibt es ja auch Vorgeschichte dazu. Wir setzen uns ja nicht einfach hin und schreiben was. Manuel, du hast das Thema aufgebracht mit dem Prototyping. Das ist ja genau der Punkt. Wann entscheiden wir, mit welcher Technologie wir das Ding jetzt angreifen?

Manuel
Also das macht man eigentlich spätestens dann, wenn man irgendwie versuchen will, rauszufinden, wo viel technisches Risiko drinsteckt im Projekt, bei dem Versuch, irgendein Kernproblem der Anwendung zu lösen. Und dann findest du raus mit dem Prototyp, ob es das tut.

Martin
Genau, kurz gesagt, dann hast du ja den Prototypen.

Manuel
Ein kurzer Dank.

Martin
quasi schon konzipiert. Also wo, ich will da ein bisschen reinbohren in das ganze Thema, das ist mir noch nicht, noch nicht genau genug. An irgendeinem Punkt muss ja eine Diskussion stattfinden, wenn du es jetzt nicht komplett alleine machst. Welche Werkzeuge du tatsächlich in die Hand nimmst, um das technische Risiko daraus zu hebeln.

Manuel
Ja, also wenn du zum Beispiel dir unsicher bist, also du hast zum Beispiel mehrere Optionen. Du kannst dir vorstellen, ja, du kannst das mit Technologie A lösen, das Problem, oder mit Technologie B und du bist ja unsicher und dann probierst du es halt einfach mal aus mit, gehst einen Weg und entweder funktioniert es oder du stößt irgendwie über Probleme, Hürden und hast dann noch die Möglichkeit, eine Alternative auszuprobieren. Also dafür eignet sich der Prototyp eigentlich ziemlich gut, dass du halt so früh wie möglich erkennst, dass irgendwas besser oder schlechter geeignet ist.

Martin
Also wenn ich dich richtig verstehe, Richtung exploratives Programmieren, tatsächlich eins von beiden in die Hand nehmen und losarbeiten und gucken, ist das Ergebnis das, was ich mir vorstellen kann oder sollte ich die andere Technologie vielleicht doch auch mal ausprobieren? Hätte ich das richtig verstanden?

Manuel
Genau, also gerade bei den Technologien, wo man vielleicht selber jetzt noch nie so viel Erfahrung gesammelt hat, die noch neu sind oder die man vielleicht jetzt irgendwie in dem Rahmen, wie das Projekt das jetzt vorgibt, noch nicht verwendet hat.

Martin
Würdest du das so unterschreiben Theo?

Theo
Ja, durchaus. Ich glaube, der letzte Punkt, den Manu gerade angesprochen hat, der ist sehr wichtig. Generell ist es ja so, dass wir versuchen, den kritischen Pfad zuerst zu gehen bei einer technischen Lösung. Das heißt, wir versuchen immer, das technische Risiko in irgendeiner Form rauszubekommen, sei es jetzt mit bewährten Technologien, sei es mit neuen Technologien. Aber natürlich ist es so, dass wenn wir bewährte Technologien wie ein React einsetzen, dann haben wir einfach sehr viele Leute, die sich damit sehr gut auskennen und die im Zweifelsfall sagen können, ja, da könnte es vielleicht die oder die Schwierigkeit geben, wo dieser explorative Teil gegebenenfalls gar nicht mehr so zwingend notwendig ist, weil wir schon eine relativ klare Vorstellung davon haben, was wir tun wollen. Und im Vergleich dazu, wenn wir jetzt einen Elm ausprobieren wollen, dann bedeutet es schon, dass wir gucken müssen, hey, wo braucht man denn jetzt überall JavaScript, Interop und was kann man denn tatsächlich nativ mit Elmen lösen beispielsweise. Und da kommt das Explorative dann ins Spiel, glaube ich.

Martin
Okay, was mir noch so ein bisschen fehlt, ist die Diskussionskultur, die ich persönlich sehr, sehr schön finde und die ich auch immer wieder sehr stark wahrnehme in den Phasen, bevor wir überhaupt anfangen, Code zu schreiben. Also gerade wenn es halt darum geht, auf der grünen Wiese anzufangen und oder nicht mal unbedingt auf der grünen Wiese. Da auch, aber auch wenn du jetzt ein Projekt erweiterst, beispielsweise um ein neues Modul, ein neues, vielleicht auch eine ganz neue Dimension. Auch da treffen wir ja zum Teil sehr abweichende Technologieentscheidungen von dem, was wir vorher gemacht haben. Und für mich der wichtigste Punkt hier ist eigentlich immer die Diskussionskultur. Ich habe das am Anfang, als ich bei ZenStorm angefangen habe, manchmal ein bisschen sehr stark wahrgenommen. Inzwischen habe ich es sehr zu schätzen gelernt, dass hier durchaus viel diskutiert wird. Ich habe jetzt bei euch ein bisschen vermisst. Habt ihr das Gefühl, dass das ein wichtiger Punkt bei der Erfindung ist oder ist das für euch so normal, dass ihr da drüber springt?

Manuel
Ne, nie. Also diskutiert wird eigentlich immer. Das ist das Wichtigste, dass man überhaupt drüber redet. Das bedeutet ja nie, dass man unterschiedlicher Meinung sein muss immer, aber gerade wenn man mal mit jemand anderem oder überhaupt anderen Leuten so über solche Sachen spricht, dann kommst du ganz schnell auch mal auf andere Ideen, die du vielleicht wurden oder so Gedanken, die du vorher einfach noch nie hattest. Und das kann ziemlich fruchtbar sein. Ich würde mal noch ein Beispiel machen, so ein bisschen abstrakter. Es gibt jetzt einen Entwickler, der würde vielleicht die Technologie verwenden, die er in dem Projekt vorher kennengelernt hat und damit gut zurechtkommt, sich da inzwischen auskennt und wohlfühlt. Und bei dem anderen Entwickler wäre es jetzt genau andersrum. Und wenn man dann spricht und versucht, rauszufinden, wo gibt es jetzt von der Technologie die Vor- und Nachteile und bei der anderen, dann kann das für das Projekt irgendwie ziemlich unterschiedlich sein. Also verstehst du, ich kann das irgendwie gerade schlecht formulieren, aber...

Martin
Ja, ich versuche es mal zusammenzufassen, also gerade in dem Bereich, wo zwei Entwickler aufeinandertreffen, die vorher nicht zusammengearbeitet haben und jeder so seine Technologie mitbringt, da sind die Diskussionen dazu besonders fruchtbar, weil sie recht tief gehen können, weil beide halt mit der Technologie relativ vertraut sind. Dann habe ich das richtig mitgenommen.

Manuel
Ja, ich denke, das ist so ungefähr das, was ich sagen wollte.

Martin
Okay, Theo, mich würde mal interessieren, du bist auch jemand, der sehr gerne diskutiert. Was? Wie bereitest du dich auf so eine Technologie-Diskussion auch vor?

Theo
Na ja, also das kommt ganz drauf an. Also wir haben ja bei Sensorm so ein bisschen, wir folgen ja den Ansatz, bescheiden zu sein. Also das heißt, für mich ist so die wichtigste mentale Vorbereitung, dass ich nichts Konkretes durchdrücken will, sondern ich will tatsächlich, wie du schon gerade gesagt hast, so den optimalen Weg finden, der aus so einer Diskussion fruchten kann. Und das aber finde ich persönlich ein Mindset, was ich vorher immer erstmal auch so ein bisschen anlegen muss, weil natürlich hat man so seine persönliche Präferenz und natürlich hat man schon eine klare Vorstellung davon, wie man am liebsten arbeiten würde. Oft wird das aber auch daher, dass man die andere Seite nicht so gut kennt. Also ich beispielsweise bin jemand, bei mir ist so mein mentales Modell funktioniert sehr, sehr gut mit so bestimmten Anleihen an die funktionale Programmierung und ich tue mich immer wieder ein bisschen schwer, wenn es um Objektorientierung geht, weil es mir einfach schwerer fällt, in der Stateful-Welt zu denken. Gleichzeitig heißt das aber nicht, dass für jedes Problem der funktionale Ansatz zwingend der bessere sein muss. Und ich habe natürlich den funktionalen Ansatz einfach auch viel stärker verfolgt, deswegen fühle ich mich da viel, viel wohler und das ist dann so das gemachte Nest, in das man sich gerne setzen würde. Es kann aber total helfen, sich weiterzuentwickeln, indem man mit seinem Gegenüber beide Formen beispielsweise erörtert und ich glaube, die Vorbereitung ist für mich das Wichtigste, ist die Offenheit in das Gespräch mit reinzugehen und zu verstehen, was ist mir denn tatsächlich wichtig.

Martin
Wir haben ja nun bei uns den großen Vorteil, dass es bei uns niemanden gibt, der sagt, nein, du musst jetzt die Technologie a, verwenden, weil ich dir das so sage. Also Hierarchie ist ja bei uns eher kleingeschrieben. Das ist ja in anderen Unternehmen durchaus anders. Ich würde da gerne mal aus Sandstorm hinausgreifen. Ich weiß nicht, wie eure Erfahrungen da sind aus der Vergangenheit. Aber habt ihr das kennengelernt, wie Technologie Entscheidungen, also Technologie Entscheidungen auch vor Vorgesetzten so rechtfertigen? Ich weiß nicht, ob Theo vielleicht, vielleicht magst du anfangen.

Theo
Also bei mir war es tatsächlich so, dass ich bei meinem ehemaligen Arbeitgeber relativ stark verargumentiert habe, was beispielsweise das für Bedeutung hätte, wenn wir React benutzen würden, statt eine riesengroße Anwendung in Manila JavaScript zu schreiben. Was letztendlich, also ich hatte zu dem Zeitpunkt halt auch schon ein bisschen Grunderfahrung mit React, also ich hatte eine ganz gute Vorstellung davon und es war bei meinem ehemaligen Arbeitgeber generell so, dass wir ganz, ganz oft massive Probleme mit technischer Schuld hatten, sehr schlecht gepflegten, gewarteten Projekten, also das heißt auch so Sachen wie Testabdeckung und so gab es de facto gar nicht. Es gab keine Git Repositories, also generell keine Versionskontrolle in dem Sinne, das sind so Sachen, die ich mehr oder weniger mit etabliert habe und das hat für uns ganz gut funktioniert. Das heißt, ich hatte sowieso schon Gehör und konnte, indem ich das Ganze sozusagen auf eine gewisse Art und Weise monetär verargumentiert habe und tatsächlich aufzeigen konnte, was hat denn das, sag ich mal, für einen Zeitimpakt, wenn wir sozusagen jetzt hier uns etwas selbst zusammenfrickeln, quasi ein eigenes kleines Framework bauen, anstatt eine wohlgebaute Lösung zu nutzen. Das hat letztendlich so dafür gesorgt, na gut, dann probieren wir es mal aus, die Ergebnisse waren zufriedenstellend und das hat dann dafür gesorgt, dass wir es für weitere Projekte mehr oder weniger mit verwendet haben.

Martin
Ich würde jetzt mal interessieren, Manu, in deiner Richtung, und zwar, es ist ja nun so, wir haben niemanden, der uns vorgesetzt ist, vor dem wir Dinge rechtfertigen müssen, aber wir haben den direkten Kontakt zum Kunden und dem gegenüber sind wir ja durchaus so transparent, dass wir ihm, soweit ihn das interessiert, auch unsere Technologien mitteilen, unsere Technologieentscheidungen ihm gegenüber direkt vertreten wollen und müssen. Wie gehst du das an?

Manuel
Naja, also wenn wir uns für eine bestimmte Technologie entscheiden für das Projekt, das wir für den Kunden machen wollen, dann hat das ja immer auch gute Gründe. Oder wir haben uns da selbst Gedanken gemacht und schon miteinander gesprochen, sodass wir das auf jeden Fall immer gut vertreten können, sofern der Kunde da überhaupt das interessiert. Das ist ja auch manchmal gar nicht der Fall. Der will einfach nur, dass es dann am Ende funktioniert und wie, egal.

Martin
Ja, okay, habe ich verstanden. Mich würde jetzt mal interessieren. Vielleicht so zum Abschluss noch. Ihr seid jetzt vollkommen frei, ihr habt eine grüne Wiese vor euch und ihr habt ausschließlich mit euch selbst zu diskutieren. Welche Technologie würdet ihr jetzt gerne mal einsetzen, was aktuell so euer Fokus ist? Theo, was ist so das, wo du sagst, ich würde jetzt, wenn ich jetzt ein Projekt hätte, eine komplett grüne Wiese, das würde ich jetzt damit bauen, weil.

Theo
Also im Frontend, muss ich gestehen, bin ich mit React TypeScript aktuell ziemlich happy. Ich hätte da nichts dagegen mal auch mal was mit Elm oder so zu machen, aber ich bin mir da, was das Ökosystem betrifft, nicht so sicher. Deswegen, also was mich wirklich reizen würde, wäre eher backhand-seitig tatsächlich mal mit einer Sprache wie Haskell oder Erlang Elixir tatsächlich da mal tiefer einzutauchen. Da hätte ich richtig richtig Bock drauf.

Martin
Okay, jetzt meine Frage dazu, was braucht es dafür?

Theo
Du meinst, damit das im Sans-Sum-Kontext passiert, oder? Jo. Naja, also ich sag mal so, wir evaluieren durchaus gerade den Erleihungsdeck, also da hast du ja auch maßgeblich, sag ich mal, so ein bisschen Input mit reingebracht. Aktuell aus meiner Sicht fehlt es da bei uns einfach noch so ein bisschen an Expertise, weil das Denkmodell einfach ein anderes ist, als wir es zum Großteil gewohnt sind. Das heißt, aus meiner Sicht fehlt aktuell ein bisschen Expertise und dann eigentlich im Grunde nur noch das richtige Projekt, wo die Technologie passt. So, das ist für mich an der Stelle entscheidend und ansonsten sehe ich da jetzt keine großen Hürden, ehrlich gesagt.

Martin
Okay. Manu, deine Lieblingstechnologie und warum würdest du sie gerne einsetzen?

Manuel
Das sind zwei Sachen. Das erste ist Neos. Ich würde unglaublich gerne mal was mit Neos machen, das hat sich irgendwie komischerweise einfach noch nie so richtig ergeben. Und React. Ich habe schon lange nicht mehr mit React gearbeitet, obwohl mir das eigentlich auch sehr, sehr viel Spaß macht und in Verbindung mit TypeScript auch noch nie. Das würde ich gerne mal machen. TypeScript. Also, weil das, was ich bisher so immer am Rand mitbekommen habe, das tönt mich schon ganz schön an. Da hätte ich echt mal richtig Bock dazu.

Martin
Okay. Jetzt noch eine Frage und dann wirklich zum Abschluss. Und zwar würde mich interessieren, was ist so ein Hype, der euch gerade tierisch auf die Nerven geht? Vielleicht fängst du einfach mal an, diesmal, Manu.

Manuel
Ich überlege gerade, eigentlich fällt mir da gar nichts ein, was mir auf die Nerven geht. Das ist eine echt gute Frage. Mir geht nichts auf die Nerven.

Martin
Theo, hast du noch irgendwas?

Theo
Ein Hype, der mir auf die Nerven geht, boah, nö, eigentlich gibt es da nichts. Ich habe gerade überlegt, ob ich irgendeine lustige Reaktion darauf habe, aber ehrlich gesagt, nein, keine Ahnung, ich nehme diese Hypes ehrlich gesagt auch, wie gesagt, gar nicht so krass wahr. Es gibt so eine laute Mehrheit, gerade im JavaScript-Bereich, die alle immer schreien. Es gäbe so wahnsinnig viele Hypes. Ich glaube, es gibt sehr viele JavaScript-Entwicklerinnen und natürlich probieren die sich halt auch aus und jeder möchte halt auch selber mal eine Library schreiben. Die Wahrscheinlichkeit, dass es dann in JavaScript passiert, ist recht hoch, aber das sind alles so Sachen, die sich auf so kleiner Flamme bewegen, dass ich nicht das Gefühl habe, dass ich da jetzt hinterher rennen müsste. Deswegen verstehe ich auch ehrlich gesagt oft nicht, warum da sozusagen so laut geschrien wird, dass da jeden Tag ein neues Framework rauskommt. Das ist aus meiner Sicht einfach Quatsch, also weiß ich nicht.

Martin
Also dich nervt der Hype um dich.

Theo
Hypes quasi. Ja doch, ja das kann man so sagen. Also mich nervt der Hype um die angeblichen Hypes.

Manuel
Martin, welcher Hype geht dir denn auf den Nerven? Ich habe dich gerade gefragt, woher die Frage kommt. Anscheinend gibt es da irgendetwas.

Martin
Ich habe mich gerade gefragt, woher die Frage kommt. Es ist anscheinend, gibt es leider irgendwas. Nein, tatsächlich ist es bei mir fast so ähnlich oder fast genauso wie beim Theo. Ich lese das immer wieder. Also auch dieser Witz, den ich ganz am Anfang versucht habe zu rezitieren, dass quasi jeder Zweite irgendwie anfängt, sein eigenes JavaScript Framework zu schreiben. Ich glaube, es ist genau dieses Geschrei nach neu, neu, neu, alles muss neu und neu. Irgendwie die Sprachen, mit denen ich mich persönlich am Wurzeln fühle, sind irgendwie uralt und irgendwie 20, 30, 40 Jahre alt. Und deswegen geht mir, glaube ich, einfach das Gehype an sich auch auf die Nerven. Also, so ein bisschen dieses... Ich glaube, ich bin da ein bisschen beim Theo. Es gibt eigentlich gar nicht so viel, worüber man hypen könnte, aber es wird viel drüber gesprochen. Das ist, glaube ich, das, was mich nervt.

Theo
Ich würde vielleicht auch, weil mir das tatsächlich am Herzen liegt, weil ganz oft, also ich kenne diese Diskussion, was ist denn jetzt besser Angular, React oder Vue, das ist so im Freundinnenbereich so eine Diskussion, die immer wieder geführt wird und wo ich nur sage, Leute benutzt das, womit ihr euch wohlfühlt, also ich glaube, das ist vielleicht so für die Hörer als Takeaway noch echt ganz, ganz, ganz relevant, in all diesen drei Frameworks bzw. Libraries mit deren respektivem Ökosystem kann man total gut Anwendungen schreiben, wichtig ist, dass es für euch funktioniert, die lassen sich alle voneinander inspirieren, Konkurrenz belebt das Geschäft, alles super, aber es gibt nicht das eine Framework oder die eine Library, die über alle Zweifel erhaben ist und auch bis ans Ende ihrer Lebenszeit sein wird. Guckt, was für euch funktioniert, so, das ist mein Herzen.

Martin
doch, Elm, oder? Nein, mach das fachlich auf. Spaß beiseite. Also ich fasse noch mal zusammen, um die Hypes zu überleben, ist es wichtig, quasi erst mal zu ignorieren, dass es so was geben sollte. Und zum anderen geht es halt tatsächlich darum, eine informierte Diskussion zu führen über das Problem, was man auf der Hand hat und nicht darüber, womit man gerne das nächste Problem verschlagen wollen würde, egal was das für ein Problem ist.

Theo
Ja, das klingt für mich sehr plausibel.

Martin
Hab ich was Wichtiges vergessen?

Theo
Hm... Ich denke nicht. Sagt du es mir?

Martin
Dann würde ich sagen, das ist eine Folge und ich danke euch für's dabei sein.

Theo
Das ist eine Folge.

Martin
Ja, vielen Dank, auch vielen Dank an die Hörer. Es hat mir sehr viel Spaß gemacht und wir sehen uns nächste Woche wieder.

Manuel
Bis dann!

Theo
Danke schön, bis dann, ciao!