[Bürotalk] Ist unser Techstack noch aktuell?

Felix, grüß dich. Hi Kay. Mir ist letztens was durch den Kopf gegangen und ich dachte, ich frage dich einfach mal. Und zwar bin ich ja so im Internet unterwegs und da kommt man ja gar nicht umhin, festzustellen, dass ja jede Minute eine neue Technologie rauskommt, die der neu heiße Scheiß ist. Und ich weiß, wir sind da üblicherweise nicht so von gehypt. Aber jetzt ist mir doch aufgefallen, dass wir irgendwie schon, weiß ich jetzt gar nicht, das letzte Projekt vor zwei Jahren, vor drei Jahren aufgegleist haben. Und insbesondere in Sachen React, die ja schon viel passiert ist. Und Laravel machen auch immer neue Features, die wir nachsehen können.

Und meine Frage, die mir so im Kopf rumspukt ist, sind wir jetzt eigentlich technisch schon abgehängt? Aha, interessant. Also erstmal muss ich ja mal sagen, dass wir von allen neuen Sachen ziemlich gehypt sind. Aber das nicht gleich heißt, dass wir die auch in unseren Projekten einsetzen. Also ich sage immer, wir wollen abgehangene Sachen für produktive Sachen einsetzen beim Kunden.

Weil wenn man beim Kunden dann später feststellt, oh, was da jetzt so gehypt war, was so cool war, stellt sich jetzt doch raus, ist doch nicht so geil oder wird nicht mehr so viel verwendet. Das ist natürlich schlecht, das kann man den Leuten nicht antun. Aber so privat und untereinander sind wir schon begeistert von neuen Sachen, wenn die rauskommen. Ja, das stimmt schon. Und ich probiere natürlich auch dann so zu Hause und im Feierabend mal was aus. Aber ehrlicherweise so richtig einen Eindruck davon von neuen Sachen kriege ich da nicht mit. Das ist schon sehr viel effizienter, wenn man es wirklich mal in einem Projekt ausprobieren kann.

Aber gleichzeitig, wie du gesagt hast, ist das auch eine Gefahr, weil wenn sich die Technologie dann als Quatsch herausstellt oder nicht so langlebig, dann hat man damit halt ein produktives Projekt aufgesetzt. Also ein, wie sagt man, Production-Projekt. Und wir haben ja schon ein bisschen was umgestellt. Wir haben jetzt jüngst erst während der Projektlaufzeit von Create-React-App auf weit umgewechselt. Das war ganz schön abenteuerlich. Aber da entwickelt sich das ja auch weiter mit Next.js. Und ich meine, die Sachen, die wir benutzen, die funktionieren ja für uns, logischerweise. Ich bin mir noch nicht sicher, ob wir damit nicht zu diesen alten Eisen langsam werden, die sagen,

ja, aber das hat schon immer so funktioniert. Zu den jQuery-Verfechtern? Ja, zum Beispiel. Oder Typo 3, oder weiß ich nicht. Da können wir jetzt mal richtig reinreden. Oh, Typo 3. Ja. Ich habe letztens mir sagen lassen, dass Kongstar, das kann aber falsch sein, die Webseite und ihre Produkte mit Typo 3 machen. Also die Telekom-Tochter für Mobilfunk. Und da sind wir schon die Fußnägel hochgegangen. Ich habe jetzt natürlich auch lange nicht mehr in Typo 3 reingeguckt. Aber immer wenn ich wieder reingeguckt habe, ist es mir wieder gegraut. Ich wollte jetzt sogar nicht auf Typo 3 rumpacken. Nein, nein, ich aber.

Da sind wir, glaube ich, ein bisschen vorbelastet historisch. Aber ja, also am liebsten würde ich einfach zweimal im Jahr ein neues Projekt auf Gleis produktiv und das zur Möglichkeit nehmen, neue Projekte auszuprobieren. Ich weiß, wir haben mal Elektron ausprobiert für so ein kleineres Projekt. Muss ja nicht gleich immer so eine riesen Anwendung sein mit gigantischem Budget. Ja, ich weiß nicht. Ich habe so dieses Gefühl im Hinterkopf. Und ich dachte, ich stelle das mal zu dir hin und schaue, wie das resoniert. Ja, da habe ich natürlich jetzt ganz, ganz viele Gedanken zu im Kopf. Das Erste ist erstmal, du musst ja irgendwie auf den Pfad gekommen sein,

auf den Gedanken, dass wir abgehängt sind. Will heißen, du hast ja von irgendwas Neuem gelesen, was wir nicht machen. Was ist es denn? Ja, jetzt ganz konkret zum Beispiel ist Snacks.js, was ja inzwischen sogar von React selber als der Weg zu gehen benannt wird,

um so eine Anwendung zu starten. Da ist dann schon Routing mit dabei, da ist dann auch serverseitiges Rendering mit dabei und sowas. Das ist jetzt natürlich im Moment das allergrößte Eisen im Feuer und auch schon, glaube ich, über diese initiale Hype-Welle weg. Also das ist schon ganz schön abgehangen, könnte man sagen. Sag nochmal eben, was Next.js genau macht. Ja, das ist quasi, das wird immer, glaube ich, betitelt als das Full-Stack-Framework für React, wo React ja eigentlich nur eine Bibliothek ist. Und die kümmern sich eben, haben schon so ein integriertes Routing, was man sonst dazu buchen muss.

Also so Backend-mäßig auch. Ja, genau, Backend. Also die Idee ist, das ist ein Service, der im Backend läuft und der macht schon serverseitiges Rendering für dich, also liefert letzten Endes statische HTMLs aus, die mit React gebaut wurden. Und dann dynamisch, wie heißt das, hydriert werden können. Die machen dateibasiertes Routing und solche Sachen. Habe ich jetzt nicht alles mehr so genau im Kopf. Bilder, Optimierung, so ganz viele Dinge. Aber eben so ein Rundum-Sorglos-Paket, sage ich mal, für React-Anwendungen. Ja, diese Server-Side-Rendering-Geschichten, da bin ich ja nicht der allergrößte Fan von,

weil das Hauptargument dafür ist ja meistens dann die Performance. Und ich hatte bisher noch nie das Gefühl, dass wir in unserer Anwendung, egal wie groß, Performance-Probleme haben. Ich habe auch so ein bisschen das Gefühl, das ist dafür da, um Webseiten zu ersetzen. Also so klassische Webseiten, die statischen Text ausliefern. Aber wir machen ja wirklich mit React tatsächlich so Single-Page-Applications, also die dann auch gar nicht so viel serverseitig gerendert haben und wo das Routing auch nicht so Dateisystem-basiert geht. Aber guck mal, da weiß ich schon nicht genau, wie das funktioniert.

Also wo ich auf jeden Fall mal mitgehen würde, ist, dass wir das mal ausprobieren und da mal die Hand dran anlegen, wobei ich mir ziemlich sicher bin, dass du das vielleicht auch schon gemacht hast. Also wirklich nur einen Abend mal eine Stunde reingeschaut oder sowas. Aber das ist schon die Frage, wie probieren wir es aus in einem halbwegs professionellen Kontext? Weil ich glaube, wie kriegt man nur ein richtiges Gefühl für die Vor- und Nachteile, wenn man eben nicht so eine klassische To-Do-App nachbaut, sondern wirklich Kundenanforderungen versucht, damit umzusetzen, die auch ein bisschen spezieller sind.

Ja, aber ist denn der Weg, den man dann geht, das bei einem Live-Kundenprojekt auszuprobieren? Also im Sinne von, wir kriegen ein neues Projekt, wir probieren das aus, einfach weil wir Bock drauf haben, das mal zu testen und Lust auf neue Technologie haben, um dann hinterher festzustellen, vielleicht ist es nicht das Richtige. Oder müsste man das eher in einem Kontext machen von vielleicht einem Workshop oder einem Projekt, das man so nebenbei macht, wo man wirklich Technologie einfach ausprobiert oder holt man sich sogar externe Expertise rein und lässt sich was erzählen darüber, um dann zu bewerten, ob das das Richtige sein kann.

Weil das würde ja bei uns ein bisschen Laravel ersetzen, ne? Ja, das würde ich jetzt gar nicht mal erstmal sagen. Erstmal würde es, glaube ich, unser Frontend-Stake ersetzen oder ergänzen. Aber wie haben wir es denn, du hast gerade Laravel gesagt, wie haben wir es denn bei unseren anderen Technologien gemacht? Wir haben ja auch irgendwann mal in meiner Lebensspanne im Unternehmen angefangen, Laravel einzusetzen und React genauso. Da haben wir doch auch einfach gemacht, oder nicht? Ja, da waren schon Prozesse dahinter, ne? Also bei PHP, also wir haben ja früher ganz viel auch so auf CMS-Basis gemacht,

beispielsweise dann WordPress-Geschichten oder bei Shops dann Shopware, die ja so ein bisschen das Backend schon mitbringen und man das dann nur erweitert hat. Wir haben ein paar PHP-Anwendungen gemacht, wo wir entweder ohne Framework oder mit anderen Frameworks unterwegs waren. Ich kriege die jetzt nicht mehr ganz auf der Kette, was wir da alles... Der Code-Igniter gibt es noch, ne? Ja, aber das haben wir, glaube ich, nie so richtig eingesetzt. Es gibt Send, es gibt Cake-PHP, es gibt ganz viele. Also Namen fallen mir da schon ein. Ich kann mich aber nicht mehr ganz genau daran erinnern, was wir da alles so eingesetzt haben.

Aber dass man irgendwann an irgendeiner Stelle ein Framework benutzen muss für Frontend, für Backend, das ist ja relativ klar. Und ich weiß, dass wir in Laravel reingerutscht sind, weil wir Loom benutzt haben. Das ist ja diese abgespeckte Variante. Und dann haben wir schnell gemerkt, dass das für uns gut funktioniert und haben dann auf Laravel geswitcht. Und da muss man auch sagen, in dem Moment war Laravel wirklich schon einfach der Platzhirsch unter den PHP-Frameworks und dann gab es eigentlich auch keine Alternative dafür. Und bei React war es so, dass wir lange Zeit dann tatsächlich mit jQuery gearbeitet haben,

was ich auch sehr geliebt habe. Und da war es auch so, dass der Druck irgendwann einfach zu groß wurde von außen, dass alle Projekte, die gesucht wurden, da war nur noch von Angular dann damals noch viel die Rede von React. Vue gab es da, glaube ich, noch nicht. Und irgendwann hatte man ein ganz eindeutiges Gefühl, wenn wir jetzt nicht switchen auf ein Frontend-Framework, auf eine Frontend-Bibliothek, dann sind wir hier an der Stelle abgehängt. Und da ging es auch schon los, dass jQuery so ein bisschen verrissen wurde. Ja, und dann war React für uns ja das Framework der Wahl. Also ich sage jetzt mal, Framework ist eine Bibliothek, aber ihr wisst, was ich meine.

Und für React haben wir uns entschieden, weil das ja mit relativ viel nativen JavaScript auskommt. Und das fanden wir so die beste Idee eigentlich von Framework. Und ich finde, dass das bis heute auch ziemlich gut funktioniert. Und ich glaube auch nicht, dass wir mit React an sich abgehängt sind, sondern ich finde das immer noch extrem aktuell. Also Vue hört man halt wirklich noch sehr, sehr viel. React hört man noch ein bisschen mehr. Und Angular hört man nicht mehr so viel. Das ist so mein Eindruck von Frontend. Also ich habe jetzt auch nicht das Gefühl, dass wir mit React per se abgehängt sind.

Wobei natürlich schon immer neue Frameworks rauskommen, die interessante Konzepte anbieten, sag ich mal. Da ist ja dieses große Virtual DOM, was React eingeführt hat und so stark gemacht hat, inzwischen auch schon wieder veraltet. Aber es sind eher so Kleinigkeiten drumherum. Ich habe ja eh das Gefühl, das Web gleicht sich immer mehr aneinander an. Und auch die verschiedenen Frameworks machen alle irgendwie das Gleiche. So ein bisschen wie die Browser. Früher war jeder Browser super special und Glitzer. Und heute machen die im Kern alles dasselbe. Ja, wo ich ja nicht viel dagegen habe. Also weder die Frontend-Frameworks sich angleichen oder überhaupt die Frameworks.

Also im Backend ist dann klassisch diese MVC-Aufteilung, die man dann immer wieder sieht. Und bestimmte Design-Patterns, die man immer wieder trifft. MVC ist ja sogar eins. Und im Frontend, genau, du hast recht. Also da gibt es schon eine gewisse Ähnlichkeit. Und bei Browsern, da bin ich natürlich im Speziellen dankbar. Ich komme ja aus einer Zeit, wo wir noch den IE, tja, war es fünf, sechs. Also sechs auf jeden Fall. Aber wo man dann mit irgendwelchen CSS-Regeln jeden einzelnen Browser adressiert hat. Und sich darüber gefreut hat, dass Firefox irgendwelche schatten kann. Die Zeiten sind ja Gott sei Dank vorbei.

Ja, aber nichtsdestotrotz müssen wir da am Ball bleiben. Weil auch wenn es jetzt vielleicht noch nicht so ist, mag es in ein oder zwei Jahren so sein. Und dann komme ich wieder zur Ursprungsfrage zurück. Wie gehen wir das wirklich an? Weil ich glaube, so ein Workshop ist zwar vielleicht mal für einen Tag schön und gut. Haben wir schon mal so Workshops gemacht? Ich könnte mich gar nicht entsinnen. Vielleicht wäre das mal eine Idee. Aber auch da macht man ja dann eher so eine To-Do-App oder so niedrig hängende Früchte, die man versucht nachzubauen. Und ich bleibe aber dabei, dass man erst die Qualität von so einem Framework, nenne ich es mal,

wirklich erfährt, wenn man auch die Downsides mal feststellt. Und die werden in so klassischen To-Do-Apps ja üblicherweise nicht abgefragt. Nein, nein, die funktionieren immer super, egal was man macht. Hm. Tja, wie gehen wir da dran? Ja, dranbleiben müssen wir definitiv. Das haben wir in der Vergangenheit auch immer gemacht. Das heißt, wenn du was Neues hörst, immer reinwerfen, immer ausprobieren. Mindestens mal in einem kleinen Projekt so nebenbei. Jetzt habe ich leider nicht so viel Freizeit mehr in meiner Freizeit. Deswegen habe ich gerade extra nicht Freizeit gesagt. Ich hatte das Wort im Kopf, aber du hast natürlich völlig recht, das ist nicht das Richtige.

Sondern man muss sich in der Arbeitszeit Zeit dafür nehmen. Und dann reichen meist natürlich auch ein, zwei Stunden nicht, sondern dann musst du dir wirklich auch mal einen Tag nehmen, das auszuprobieren. Und mir ist es das wert. Also die Freiheit kannst du dir und können sich andere bei uns im Team definitiv nehmen. Vielleicht setzt man sich auch mal zusammen und guckt mal, dass man... Also das kann was für die Schublade sein, das muss nichts Produktives sein. Ja, umso besser wäre natürlich, wenn man wirklich ein Projekt hat. Aber da schwingt eben die Angst mit, dass man das verwendet. Einmalig, nie wieder und dann darf man es maintainen.

Und dann hat keiner die Expertise und dann verwendet man einfach irre viel Zeit drauf. Aber das soll trotzdem nicht unsere Innovationskraft hemmen und uns davon abhalten, neue Sachen einzusetzen. Also überhaupt nicht. Also in dem Moment, wo du das Gefühl hast, dass es was gibt, was ausprobierenswert ist, müssen wir das tun. Ich suche ja immer noch nach dem heiligen Gral, aber so richtig gefunden habe ich ihn noch nicht. Ja, also früher haben wir ganz viele relativ kleine Projekte gemacht. Und ich kann mich entsinnen, dass wir auch viele Sachen da mal ausprobiert haben, wie zum Beispiel so eine Elektronanwendung.

Das ist auch schon viele Jahre her, da war das alles noch ein bisschen komplizierter. Und du hast zwar schon recht, dass das möglicherweise dann dazu führt, dass man am Ende irgendwie so einen Technologie-Ast hat im Unternehmen, den man noch weiter maintainen muss. Aber gleichzeitig, dadurch haben wir den besten Eindruck davon bekommen, ob die Technologie was für uns ist. Und jetzt im Fall von Elektron haben wir gelernt, dass das eher nichts ist, womit wir uns näher beschäftigen wollen, aus verschiedenen Gründen. Ja, ich denke dann immer noch mit Freude an die Projekte, die wir noch am Laufen haben.

Mit Joomla, mit Shopify haben wir Sachen. Wir haben Shopware drin. Wir haben ganz viele verschiedene Sachen, auf die ich immer wieder stoße, wo ich mich jedes Mal wieder ein bisschen einlesen muss. Wobei das natürlich auch cool ist, dran zu bleiben und vieles gesehen zu haben. Dann kommt einem hinterher auch vieles bekannt vor. Aber nochmal zum Anfangsthema zurück. Was müssten wir denn jetzt für Technologien einsetzen, damit du das Gefühl hättest, wir sind am Zahn der Zeit? Also das klang jetzt ein bisschen reißerisch am Anfang. Ich glaube, wir sind da immer noch ganz gut up to date. Und das sieht man ja alleine daran,

dass die Dinge, die wir mit unserem Tech-Stack umsetzen, sehr gut funktionieren und dass sie immer noch, die Technologien, maintained werden. Also da gibt es jetzt, also Next.js war jetzt so ein Stichwort, aber da gibt es jetzt nicht noch zwei, drei andere, die du jetzt im Kopf hast, die wir jetzt unbedingt ausprobieren müssten. Ich bin ja insgesamt immer noch sehr unglücklich, wenn man so eine Full-Stack-Anwendung macht, dass man entweder einen Backend in JavaScript bauen muss oder einen Frontend mit Blade, wenn man zum Beispiel in Laravel unterwegs ist und dass es keine einfache Möglichkeit gibt, das zu kombinieren.

Und es gibt zum Beispiel HTMX. Das ist so ein neues Ding. Das geht so ein ganz klein bisschen eher Richtung JQuery. Ich glaube, da habe ich im Büro schon mal von erzählt. Also, dass man wirklich mit sehr simplen Auszeichnungen oder mit sehr simplen HTML-Attributen ein statisches Layout macht. Und das dann aber, also zum Angenommen, du hast einen Div und das bezeichnest du besonders aus. Und wenn man dann auf einen Button klickt, dann wird ein Request ans Backend geschickt. Das Backend schickt einen fertigen HTML-Block zurück und der wird Frontend in das Div eingesetzt zum Beispiel. Also, das Backend rendert fertige Teilbausteine zum Beispiel

und die werden im Frontend vom Framework, von diesem HTMX, nur noch eingesetzt. Und dadurch hast du die ganze Komplexität, also keine Komplexität mehr so sonderlich, sondern das Backend macht den Job und sowas. Das finde ich zum Beispiel einen ganz spannenden Ansatz, weil, also, React und JQuery als JavaScript als Sprache mag ich, aber dieses ganze Frontend-Dingen, das ist einfach super stressig und Bundler und alles Mögliche. Ich finde den Laravel oder generell den PHP-Tech-Stack super cool, der ist super entspannt, aber die können halt nicht so gut Frontend. Und da kommen halt immer andere, also immer neue Lösungen kümmern sich da drum,

weil so wie wir es jetzt machen mit einer klassischen React-Single-Page-Application und dann HTTP-Requests zum Backend, ist halt relativ aufwendig, weil du dann doppelte Typisierung hast. Dann hast du im Backend, in der Datenbank, hast du ein Model für einen User zum Beispiel und du musst es im Frontend nochmal nachbauen, damit du da eine entsprechende Typsicherheit hast. Und die allermeisten Projekte, die ich so sehe, was jetzt auch kein signifikanter Marktquerschnitt sein soll, die beschäftigen sich damit, das aufzulösen. Also mit irgendwelchen Tools, die dann automatisch Requests generieren,

automatisch Types generieren und solche Sachen. Und ich habe schon das Gefühl, dass wir da noch einen, ein Leidensdruck ist stark gesagt, aber dass das einfach unnötiger Aufwand ist, wenn man so eine Full-Stack-Application macht, wie wir das haben. Und dass es schon unser Ziel sein sollte, das irgendwann zu vereinheiteln, die große Lösung für die Web-Anwendung. Vielleicht auch mit demselben Tech-Stack, dass man nicht so PHP und JavaScript hat und solche Sachen. Also wo wir uns, glaube ich, einig sind, ist, dass das, was wir jetzt machen, PHP Laravel im Backend und JavaScript, Typescript, React im Frontend,

dass das nicht das Letzte ist, was wir jemals machen werden. Und ich bin mir ziemlich sicher, dass wir in zehn Jahren was anderes tun und es was anderes gibt. Die Frage ist nur, ab welchem Punkt sattelt man auf was anderes um? Und dass das dann das Letzte sein wird, glaube ich, auch noch nicht. Aber du hast genau richtig gesagt, im Frontend, das, was am meisten stört, ist, man verwendet eigentlich zehn Tools irgendwie gleichzeitig parallel, packt die zusammen, damit man von allen Welten so ein bisschen das Beste mitnimmt. Und das kann natürlich am Ende nicht so ganz richtig sein. Sag mir noch mal eben was zu Web Components.

Meinst du nativen Web Components? Ja, da hatte ich nämlich so das Gefühl, das ist mindestens mal was, was dadurch einfach, dass es nativ ist, so eine Daseinsberechtigung hat. Also ich, es ist jetzt nicht so, dass das der große Hype wäre, aber es gibt tatsächlich schon sinnvolle Anwendungsfälle. Also ich habe das eine Weile, also es ist schon länger her, dass ich mich damit beschäftigt habe und damals war das native Schreiben von so einer Komponente relativ auf, ist schon, wie gesagt, zwei oder noch mehr Jahre her. Und damals wurde schon geraten, dass man Bibliotheken verwendet, die eigentlich ein Rapper

für Web Components sind, die das ein bisschen abstrahieren und einfacher in der Benutzung machen. Aber die Idee finde ich nach wie vor super charmant, diese modulare und interaktiven Ansätze von React in native Sachen zu übertragen. Das ist ja ein bisschen so, immer irgendein cooles Projekt macht neue Sachen und dann so langsam aber sicher, wenn das so Common Sense ist, sage ich mal, wird das in den Standard übernommen. Ja, genau darauf wollte ich hinaus. Bei jQuery diese geile Dollar-Funktion, die man immer verwendet hat, warum man jQuery verwendet hat. Ja, und dann kann man einfach in JavaScript auch diesen

Query Selector All machen, wo man genau das Gleiche mitmachen kann. Und dann ist jQuery halt überflüssig. Jetzt haben wir ganz viel über jQuery gesprochen, aber in anderen Bereichen ist es auch so, oder in CSS, dann hatte man so Animations-Frameworks und alles. Und dann kommen die CSS-Animations dazu und Schatten, weiß ich noch, wie ich da damals so Slicing gemacht habe in Photoshop und so weiter. Aber genau, das rückt dann alles irgendwann in diesen nativen Code ein. Und deswegen ist für mich so Web Components, zumindest als ich das die ersten Male gelesen habe, habe ich immer gedacht, ah ja, das könnte so ein bisschen

die Überführung von den Frontend-Frameworks, die wir so nutzen und den Ideen dahinter so ein bisschen in diese Native rein. Es wird, glaube ich, tatsächlich in so riesigen Corporates verwendet, weil man dann grundlegende Basisbausteine in einer sprachagnostischen Sprache machen kann, in einem technikagnostischen Sprache, also mit nativen JavaScript schreiben kann. Und dann kann man die in seiner React-Komponente einbauen oder in seiner View-Komponente oder einfach so auf der Webseite. Und für so Corporate-Identity-Sachen wird das, glaube ich, schon sehr intensiv verwendet. Aber es behebt ja, glaube ich,

nicht dieses Kernproblem, wo zumindest ich die meisten Schmerzen habe, nämlich diese Frontend-Backend-Kommunikation. Weil wenn es nur darum geht, ein dynamisches Frontend zu bauen, da finde ich React einen super coolen Tech-Stack. Es macht voll Spaß. Es gibt viele Bibliotheken dafür. Ich finde, unsere Kombination zwischen mit React und Material UI, wir kriegen da so schnell effiziente und gut aussehende Dinge hin, wenn man weiß, was man tut. Ja, und vor allem auch backfrei. Also wenn ich mir überlege, die Oberflächen, die wir früher gebaut haben, entweder mit so kleineren CSS-Frameworks oder wirklich komplett auch selbst gebaut,

wo dann vorher noch ein Designer dran war und alles, da hattest du natürlich ständig, gerade im Responsive-Bereich oder so, dass du irgendwas auseinandergeflogen bist oder spätestens, wenn du auf Druck an sich gegangen bist und so mit Material UI. Damit kann man natürlich jetzt so ziemlich trockene Web-Anwendungen nur bauen, weil die natürlich alle ähnlich aussehen. Aber es funktioniert einfach like a charm. Ja, nur weil wir zu faul sind, das CSS da anzupassen. Aber es stimmt schon. Und ich glaube deswegen, diese Web-Components sind zwar eine gute Idee, aber die lösen nicht das Problem, das zumindest ich damit habe,

nämlich, dass die Kommunikation das eigentliche Problem ist. Und dafür habe ich auch noch keine so eine richtig gute Lösung gefunden. Also meine Traumvorstellung wäre, driften wir jetzt allerdings schon ein bisschen vom Thema ab, dass wir einen Laravel-Backend haben und React benutzen können um statt Blade. Auch von mir aus als statische Skriptsprache. Von mir aus kommt da auch statische Dinge raus. Aber das wäre so meine große Hoffnung. Und meine Hoffnung ist so ein bisschen, dass diese Server-Components, was ja wiederum ein anderes Feature von React ist, was jetzt neu ist, dass das uns auf lange Sicht dahin führt.

Aber ich fürchte, da sind wir noch nicht. Naja, aber ich glaube, am Ende sind zwei Sprachen, also PHP und TypeScript, auch nie die, also das letzte Ding, sondern irgendwann muss es, denke ich mal, eine Sprache sein. Und da führt von meinem Standpunkt aus bis jetzt auch nichts an JavaScript, in welcher Form auch immer vorbei. Es gibt ja so eine spannende, wie heißt das, von Laravel, ich hoffe, ich verwechsel das jetzt nicht, aber Inertia heißt das, glaube ich. Oder? Nee, Livewire. Habe ich beides schon mal von einer Begrifflichkeit gehört. Genau, Livewire ist das, was ich meine. Das wird jetzt, glaube ich,

sogar offiziell von Laravel übernommen. Das ist, da ist die Idee, dass du auch von der Syntax her Laravel- und Blade-Komponenten schreibst, die aber so aussehen und so funktionieren wie React, also wie so eine klassische React-funktionale Komponente, hast du vielleicht vor Augen, mit so einem State und dann kann man im Render-Teil, also im Template, kann man da drauf reagieren und sowas. Und das versucht, das so ein bisschen nachzustellen und sieht ganz fancy aus. Aber mein Hauptproblem ist, dass ich in Blade keine gescheite Autocomplete habe für Variablen und solche Dinge. Außer wenn ich so ein Paid-Plugin kaufe,

was ich irgendwie nicht einsehe. Habe ich übrigens vor zwei Tagen für David gekauft. Ja, das macht auch total Sinn für den. Aber ich finde es halt blöd, also ich möchte kein Paid-Plugin haben für Autocomplete. Das soll bitte aus der Sprache kommen und nicht aus dem Editor. Naja. Ja, ja, das ist schon richtig. Also viele spannende Dinge und worauf ich hinaus will ist, irgendwas würde ich da gerne mal ausprobieren und vielleicht auch wirklich so mal ein, jetzt habe ich schon mal wieder vergessen, Live-Wire-Dingen oder sowas. Aber mir scheint, da müssen wir einfach am Ball bleiben logischerweise und dann vielleicht wirklich mal,

wenn ein neues Projekt ansteht, objektiv und nicht vielleicht gehypt, wie ich das manchmal bin, evaluieren, was da der sinnvolle Tech-Stack ist. Hast du denn das Gefühl, das wäre für uns eine Idee zu sagen, wir machen uns einmal im Monat zum Beispiel so einen Technologie-Day, wo wir Sachen einfach ausprobieren können und da strecken wir einfach so ein bisschen die Fühle aus, was es so gibt. Das kann auch mehrfach hintereinander das Gleiche sein, dass man an einer Sache mal arbeitet und dass man sich das so anguckt und in dem Moment, wo man dann tatsächlich ein neues Projekt hat, schon mal einen Eindruck davon hat,

ob das passen könnte oder nicht, so dass man nicht ganz frisch in ein neues Projekt reingeht und sich immer wieder aktiv die Zeit nimmt, was auszuprobieren, um so ein bisschen das Beste aus beiden Welten zu bekommen. Finde ich ganz spannend. Also ich finde ja generell immer eine gute Idee, so ein bisschen Sachen anzubieten, um den Arbeitsalltag aufzulockern. Und wenn man sich dann gleichzeitig noch mit anderen Technologien beschäftigt, dann schadet das, glaube ich, also schadet das erstmal nie, außer natürlich, dass dann Arbeitszeit für andere Dinge nicht da ist. Aber das könnte sogar sein. Ich sage ja öfter mal auch,

dass es anderen Kolleginnen und Kollegen guttun würde, mal einen anderen Tech-Stack kennenzulernen. Alleine schon, um mal so ein Backend mit so einer Datenbank interagiert zu haben, um sich mehr mit Datennormalisierung auseinanderzusetzen. Das sind eigentlich klassische Backend-Themen, aber die helfen einem bei der Frontend-Entwicklung auch ungemein weiter, merke ich immer wieder. Und wenn wir da vielleicht so in der Firma einen Rahmen für schaffen, dass wir sagen, ja wirklich, vielleicht hätte es eben nur mal so in der Luft gegriffen, aber einmal im Monat nehmen wir uns einen Tag Zeit dafür und jeder bastelt mal was rum

und präsentiert es dann vielleicht nachher. Da wäre ich auf jeden Fall nicht abgeneigt. Hört sich gut an. Ich würde als Fazit nochmal mit rausnehmen, erstmal als allererstes, unser Tech, den wir aktuell haben, der funktioniert ja extrem gut. Also das, was wir tun, mit, wenn wir Backend machen, dann eben in Laravel. Die finde ich super sauber, richtig cool. Die React-Fontents, die wir machen, wir merken einfach, wir kriegen in sehr, sehr kurzer Zeit richtig gute Ergebnisse zusammen und können mega effizient, relativ fehlerfrei, gute Anwendungen entwickeln. Das heißt, eigentlich haben wir keinen Schmerz

und das Thema kommt jetzt wahrscheinlich so ein bisschen aber aus der Perspektive, wir wollen auch, dass das in Zukunft so bleibt und wir wollen natürlich bestenfalls noch komfortabler unterwegs sein und je nachdem, welchen Tech-Stack man so hat, damit hängt ja auch zusammen, ob man dann an Aufträge drankommt oder nicht und dann wollen wir nicht irgendwann so das Gefühl haben, oh, es werden auch Sachen angefragt, die wir nicht können. Da wollen wir natürlich dann schon auch am Ball bleiben. Das heißt, weiterentwickeln definitiv. Ich finde eigentlich diesen Tech-Tag einmal im Monat eine ganz gute Idee.

Lass uns da mal weiter drüber nachdenken, auch mit den anderen Mitarbeitenden. Und ja, bei einem neuen Projekt, das haben wir ja in der Vergangenheit auch immer so gemacht, wir denken immer drüber nach, was ist jetzt die richtige Technologie. Also wir würden ja nie ein Projekt starten und sagen, ah, Laravel React ist gesetzt und abfahrt, sondern wir gucken uns ja immer an, was sind die Anforderungen, was passt jetzt hier gut zu, was ist vielleicht auch schon da und wie können wir darauf aufbauen. Ja, ich glaube, da bin ich erstmal beruhigt. Da kann ich mich wieder heute Abend in das Eldorado der JavaScript-News stürzen.

Ich werde mir jetzt gleich erstmal noch ein bisschen was zur Next.js durchlesen. Sollen wir denn unseren Hörenden noch was über das neue Format erzählen, was wir heute gemacht haben? Ah, ja. Oder schmeißen wir die Leute ins kalte Wasser? Ist jetzt so die vierte Wand durchbrochen, ne? Ja, ja. Ja, genau. Also es ist jetzt mal eine Ausnahmefolge, nämlich ein Anliegen, das ich wirklich hatte, was schon länger bei mir im Kopf rumgesegelt ist und da habe ich mir gedacht, bevor wir jetzt da zwei Augen miteinander reden, was ich mit Felix ja eh schon regelmäßig mal mache, über genau solche Themen, lassen wir jetzt mal

was mitlaufen und vielleicht kann man da ja einen Mehrwert rausziehen. Ja, wunderbar. Für mich war das natürlich jetzt grausig, weil ich vorher nicht wusste, was für ein Thema auf mich zukommt. Also Kay hat mich wirklich absolut im Dunkeln gelassen. Ich hatte keine Idee davon, worum es heute geht und auch welches Format das wird und habe mir einen schönen Tee gemacht, der ganz hervorragend ist, den ich aber dann im nächsten Podcast offiziell anteasern werde und ihr dürft euch schon mal freuen. Okay. Ja, sehr schön. Dann bis jetzt gleich zum nächsten Meeting. Ja, wir hören uns gerne. Ich danke dir.