Anmelden

Working Draft

On Tour @ #t3con – Frontend State of TYPO3 mit Thomas Maroschik

Dienstag, 6. Januar 2026 · 22 min

MP3

Shownotes

Dieses Interview ist Teil der Serie On Tour @ #t3con. T3CON (t3con.typo3.com) ist die jährliche Konferenz, bei der es um alle Themen rund um TYPO3 geht. Wir waren am 25. November 2025 in Düsseldorf beim Community Day vor Ort und haben die Stimmung und einige Interviews mitgenommen.

Frontend State of TYPO3

Mit Thomas Maroschik (linkedin.com/in/thomas-maroschik-6aba0019b) konnten wir ein TYPO3 Board Member für uns gewinnen. Er gibt uns Einblicke, wie Frontend Technologien in TYPO3 gerade ein neues Hoch erfahren, wie man TYPO3 als Headless CMS nutzen kann und wie KI TYPO3 beeinflusst.

Auf YouTube findest du das Video zu unserem Gespräch (youtube.com/watch?v=b5BcAAqpsY4).

Diskutiert die Folge mit uns in unserem Community-Slack: draft.community

Transkriptvom Podcast bereitgestellt · Zeitmarken springen hin

Jahre haben wir gerade eben nochmal festgestellt. Sehr lange, ja. Ich freue mich, dass wir uns wiedersehen. Ja, ich mich auch. Und wir sind eben schon ins Gespräch gekommen, haben ein bisschen über Frontends gesprochen. Natürlich hier unser Schreckenpferd und dachten, wir können doch vielleicht mit dir mal ein bisschen was auch zum Thema Frontend. Wie entwickelt sich das gerade bei TYPO3?

Sprechen, aber bevor wir dazu kommen, vielleicht kannst du ein paar Worte zu dir selbst sagen, wenn bist du? Ja, sehr gerne. Ich bin Thomas Marschick. Ich bin, aktuell bin ich im Vorstand der TYPO3 Association. In meinem Hauptjob bin ich technischer Leiter bei der BV-GNH. Wir machen Typo 3 jetzt seit 18 Jahren dort.

Typo 3 persönlich mache ich jetzt schon seit über 20 Jahren. Ich glaube, jetzt 21 Jahre oder so. Das heißt, ich kenne das schon ziemlich lange, muss ich sagen. Ich habe auch, glaube ich, die ganze Evolution des Webs und des Systems auch mitverfolgen dürfen. Ja, was gibt es noch, was mir zu sagen? Ich glaube, ich bin ein Full-Tech-Entwickler aus Zwang, weil ich immer irgendwie so ein Vakuum gesogen werde.

Da ist ein Varkom entstandener Firma, wir müssen das lösen, dann bin ich halt da drin. Ja, und zwangsläufig werden halt irgendwie Systeme wachsen und jetzt machen wir auch eine Architektur-Rolle rein, dann mache ich halt irgendwie jetzt alles. Und jetzt auch nehmen wir irgendwie Management und dann irgendwie auch noch Vorstand und ja, alle Sprechpartner für alles Mögliche letztendlich in der TIP-3 Association, aber auch natürlich in der eigenen Firma.

Das ist natürlich eine coole, diverse Rolle, weil da viele Sachen einfach passieren. Ja, aber für uns ist natürlich das Frontend ganz interessant du hast eben schon kurz angesprochen das so ein bisschen wie der. Engineer eigentlich auch noch siehst, neben den anderen Aufgaben. Und wenn ich so bei TYPO3 ans Frontend denke, dann war das auch immer so viel BA.

Ich muss ja auch irgendwie mit PHP hantieren und halt viel damit arbeiten. Wie ist denn da der Status? Also tatsächlich, technisch gesehen muss man nicht mit PHP hantieren. Das Stack ist natürlich PHP-Besend. Das heißt, wenn man eine lokale Entwicklungsumgebung hat, hat man natürlich auch PHP am Start, aber mittlerweile durch BDEF und Kortionalisierung und sonst was ist das gut wegabsorhiert.

Das heißt, das kann man auch gut und man kann ein Frontend auch nur in der Template-Wahl schreiben, ohne irgendeine PHP-Kennweise. Die Template-Engine ist ein bisschen eigen, aber sie ist sehr fähig und die ist auch seit 15 Jahren zum Kader, glaube ich, gut im Einsatz im Projekt. Die kommt aus der Flow- und Neos-Entwicklung raus. Als Spin-Off hat es dann bei uns irgendwie auch ein System geschaffen, die seitdem ist da vertreten.

Das heißt, technisch gesehen müsste man kein PHP schreiben, wenn man auch Frontend-Engine-Zielen möchte. Aber ihr kommt natürlich aus einer anderen Ecke schon. Wir kommen natürlich aus der JavaScript-Ecke und haben jetzt irgendwie, keine Ahnung, ich habe es vorhin zu dir gesagt, ich habe so ein Experiment gemacht, gerade ist die Sendung dazu live gegangen, habe mir mal angeschaut, okay, was machen denn die ganzen AIs und welchen Stack verwenden die denn, wenn die Frontend bauen?

Alle verwenden irgendwie React mit TypeScript und Next.js, das sind so die Sachen, über die wir halt auch viel reden. Es ist immer das Gleiche. Es ist immer das Gleiche, nicht? Letztlich so eine Art de facto Standard gefühlt jetzt über die nächsten Jahre wahrscheinlich durch, weil jeder Frontend-Gumpli mit der AI unterstützt macht.

Genau, und deswegen ist das natürlich eine gewisse Gap sozusagen zwischen, ich will jetzt PHP-basierte Template-Sprache nutzen, zu, ah, eigentlich bin ich doch in JavaScript beheimatet, oder? Stellt ihr das bei euch auch fest? Ja, also wir stellen das natürlich fest, was die Staffing-Frage angeht. Das heißt, wenn eine Agentur Leute einstellt, dann hat er natürlich Schwierigkeiten, Leute, also diese Typenrei-Integratoren nennen wir die normalerweise, zu finden, die dann quasi das Frontend integrieren.

Also früher war der Prozess so, man hat halt keine Ahnung, man hat einen Photoshop-Layout bekommen, man hat das halt umgesetzt an HTML und dann gab es, also da gab es halt Frontend-Mail, in Anführungszeichen, und dann gab es den Integrator, den das, den das, den das, Ja, dann gab es so ein End-Off und die hatten quasi keine direkte Verbindung, also es gab keinen Kanal mehr.

Und wenn die der aktualisiert hat, dann musste jemand aus dem Integrationsbereich hingehen und die Änderungen auch noch mal portieren. Und das hat sich ja doch stark entwickelt, sage ich mal an der Seite. Die Spezialisierung in Front- und Back-End ist ja viel, viel steig aus der Nunge gegangen. Aber auf der anderen Seite sind auch die Grenzen drauf, ist ja total verschwommen, weil du im Front-End jetzt überhaupt mit sehr, sehr viel serverseitiger Technologie, Aber wie heißt es, Isomorphous, was du halt in deinem Backhand- und Fronthand-Stack zusammen hast.

Das sind halt ganz neue Anforderungen und ja, das bringt auch natürlich ganz neues Fachgebiet. Mit denen man sich dann auch erst mal konfrontieren muss. Ich sage mal so, im CMS-Bereich, in dem wir sind, ist das etwas, was jetzt noch nicht so ganz so populär ist. Die Nachfrage ist da, weil letztendlich jeder, der jetzt irgendwie in den jüngeren Jahren jetzt im EJS lernt, oder in Frontal Stack und demnächst ist, der kennt halt das Frontal Stack nur für sich genommen. Der kennt halt letztendlich diese Backend-Service nicht.

Und wenn, dann gibt es inzwischen immer einen Vertrag und das ist eine A-B. Und diese A-B, die haben wir halt in der Form noch nicht so wirklich. Die haben wir über Third-Party-Tools oder Third-Party-Extensions letztendlich innerhalb des CMSs. Wir haben auch intern seit Jahren eine Headless-Rudiziatriebe, die da auch so einen Versuch zu den Brücken zu schlagen.

Ich glaube, die Arbeit wird auf weitgehend genutzt. Aber man kann auch andere Dinge tun, einen Anflaschen. Aber trotzdem muss man so ein bisschen den CMS quasi seine Use-Cases definieren, die man dann irgendwie in seinem Front-Extrecker auch konsumieren möchte. Was ist nicht unbedingt das Schlechteste ist, weil spätestens bei so Sachen wie Formeingaben oder sowas, jemandem dann wieder Zweck entgeben muss, wird es dann immer meistens ziemlich eklig.

Deswegen, das sind so die Experimente, sagen wir so, die es bisher gab. Besetzt zu haben. Aber so im Rahmen des Rutsch-Strategie-Prozesses innerhalb des CMS haben wir auch gemerkt, dass es ein ganz großer Bedarf da ist. Eben, wie gesagt, einfach nur wenigstens. Und ich denke, da wird es das im nächsten Jahr auch hinunwickelt und da arbeiten wir auch in den Teams aktiv dran.

Aber es sind natürlich immer Freiwillige und wir können auch niemanden dazu zwingen und wir möchten auch niemanden dazu zwingen, weil wir sind, wie gesagt, Community-Drift in Open Source, das ist kein Unternehmen da, sondern nur Also Mitglieder, die uns irgendwie das Resultat, ihre Mitgliedsweite geben, Sponsoren vielleicht, gewisse Features sponsern, aber am Ende hat letztendlich das Core-Team über zu entscheiden, ob das dann irgendwie in so ein Produkt reingeht oder nicht.

Aber ich sage mal, durch unsere Extension-Plattformen gibt es auch sehr, sehr Vernehmlichkeiten, noch Dinge dran zu verschenken. Aber die sind halt dann wieder alle sehr BAB-orientiert und furchtet, damit sie es auch wieder so ein Team von Leuten geben, das alle Seiten verstetigen, dass sie es wieder aussehen.

Wie macht ihr das strategisch? Also du hast jetzt gesagt, da gibt es ein paar Experimente, wo man sich hin entwickeln will, weil man dann gesehen hat, okay, im Stuffing haben wir ein Problem, wir kriegen die Leute oder die Agenturen, die Type 3 verwenden, die Freelancer haben nicht das notwendige Wissen, sozusagen einfach mit dem Frontend zu arbeiten.

Wie kommt denn da jetzt dahin, dass ihr sagt, okay, das Frontend muss sich in eine andere Richtung entwickeln? Das ist eine schwierige Frage, aber eine gute Frage. Wie kommen wir da hin? Also wir kriegen das natürlich über den Feedback-Kanal aus der Amitur mit. Wie die arbeiten wollen und welche Schwierigkeiten die natürlich beim Onboarding von Rollenmitarbeitern haben.

Und das kriegen wir auch besonders mit durch das neu aufgelegte Partner-Programm. Das muss dann von der Turbo 3. Genau, das ist ja quasi der kommerzielle Zweig oder die Service-Gesellschaft der Turbo 3. Das ist ja schon für die Amitur-Mitur-Mitur. Über die kriegen wir das mit, zum ersten Mal gibt es auch so Dialogkanal zurück, der nicht über die Kernentwickler geht, die zwangsläufig ihre Interessen ja schon irgendwie im PHP-Stackbereich haben, weil sonst würden sie dann nicht anfangen, mehr Patches zu befreien.

Daraus haben wir dann entsprechend die Momentlichkeit gesehen, daraus haben sich dann auch Initiativen, Es ist aber natürlich schwer, glaube ich, für die meisten Agenturen in ihrem Alltag so richtige große Core-Features mit reinzubringen, auch konzeptionell mit reinzubringen, weil das braucht einen starken Dialog zwischen der Kernentwicklung.

Man muss das ganze System kennen, man muss dann vielleicht auch die Rope im nächsten Jahr kennen, die bei viel vielleicht noch internalisiert ist, auch im Core-Team, die gar nicht so formalisiert ist. Jeder hat eine Vorstellung, wo es in den nächsten Jahren hin geht. Aber die muss man halt alles zusammenbringen.

Und dann merken wir einfach, dass dieses Zusammenbringen von der richtigen Leuten halt genau, beziehungsweise unsere Aufgabe, sagen wir so in den letzten Jahren ist, die wir sehr, sehr viel ernster nehmen müssen, weil einfach auch der Markt viel, viel kompetitiver ist. Einfach der CMS-Markt und Contentful, wie gesagt, die letzten Händler-Systeme, die sehr, sehr stark, die sehr Venture-getrieben, sehr große Marketing- Budgets haben, die überall Präsenz auf, React und sonst was, wenn man über die Venture denkt.

Wie hoch ist das Gebäck und wie wollen wir das jemals refinanzieren, wie wollen wir das rausziehen? Also da gibt es eine fantastische Berichtung, aber das sind wir halt Wir sind halt eigentlich ein sehr professionelles, aber ein kleines, und da müssen wir dann schauen, dass wir im Rahmen uns die Möglichkeiten nur das anbieten können, was dann auch geht.

Manchmal dauert es dann halt ein bisschen länger und wir warten halt ab, was der Markt wirklich braucht. Oder auch der Schmerz dann so groß ist, dass sich dann einfach genügend Agenturen zusammentun und das dann halt in einer Zusammenfassung ins Kooperativ wird. Ja, es ist halt anders wie bei einem kommerziellen System, wo man sagen würde, guck mal, wir wetten da jetzt drauf, dass es nächstes Jahr gebraucht wird, wickel-wickel-wickel, das ist eigentlich mal.

Und das wird dann unser Wettbewerbsvorteil sein. Das können wir halt so nicht bieten, aber dafür bieten wir halt immer sehr, sehr lange Stabilität, wenn es dann mal da ist. Ja, ich denke mal, dass so ein Umbau dann auf den Invect und auf eben den Upgrade fahrt, beispielsweise die Schmerzen, die man da hätte, wenn, was ich mir vorstellen würde, dass ihr müsstet ja, also es geht ja nur, ich glaube, dass ihr ein Headless-System, entwerft und ihr müsstet ja im Prinzip alle Funktionen, die ihr anbietet.

In Form von REST API oder GraphQL anbieten. Du hast ja schon zwei Technologien, da gibt es ungefähr 50 weitere, sag ich mal so. Was ist denn die richtige jetzt? Was ist denn jetzt der, sagen wir mal so, der beste Weg, der Happy Path, den man dann entwickelt hat. Den gibt es sowieso nicht. Genau. Aber dann sind wir halt wieder in einem demokratischen Projekt, nenne ich es mal so, in dem es dann einfach schwierig wird zu sagen, das ist jetzt die Richter.

Und wir haben oft, und das wirkt vielleicht auch fragmentiert, sagen wir so, für unseren Weg, aber wir haben halt oft Ansätze, die im Wettbewerb stehen und über die Jahre entwickelt sich dann halt ein Kompliment und ein Amt ein Ding. Und. Ja, da schauen wir auch ein bisschen oder haben wir auch ein bisschen abgewartet, was sich da jetzt irgendwie entwickelt.

Du sagst, das REST-API, ja, sowas brauchen wir jetzt einfach auch für KI-Integrationen, sonst läufig, aber ob das MCP-Schnittstellen sind oder sonst irgendwas oder grundsätzlich einfach für eine höhere Internet-Connectivity mit weiß der Geier, welchen Gartensystem, ob das interne ERP-Systeme sind, wo man nachher mal, keine Ahnung, Artikelbestände noch über das CMS-Domben rausgehen möchte.

Also die Rolle des CMS ist gerade eben, wie sagen wir so, auf dem Prüfstand für sehr, sehr viele. Und dann muss man erst schauen, entwickelt man das CMS weiter oder redefiniert man die Zielgruppe. So im Strategieprozess haben wir beides gemacht. Wir haben so die Zielgruppe für uns definiert. Das ist so natürlich der öffentliche Sektor, deswegen ist auch stark, stark vertreten.

Weil da ist das Problem natürlich sehr, sehr viele Inhalte, sehr, sehr lange Zeiten zu verballen. Sehr, sehr stabil, sehr getrennt von Design und allem. Es waren ein wenig viele Video-Designs und Technologienwandel. Der Wunsch ist ja sehr, sehr präsent und richtig. Aber natürlich auch, wenn wir die ganzen kleinen Änderungen haben.

Das ist auch auf den anderen Aspekten, die ja auch von der eigenen Solidarität in allem wenig Bender-Lock in den SaaS oder sonst irgendwas ja auch profitieren möchten. Und die ganze Bandbreite müssen wir dann halt letztendlich abbilden. Das haben wir jetzt auf der Fahne geschrieben. Jetzt müssen wir mal schauen, wie. Dann müssen wir halt schauen, wo passt der Headless rein?

Welche Agenturgröße? Welche Projektgröße? Weil, ich sag mal, wenn ich ja einen Fullstack-Entwickler habe, der kann ein Projekt relativ effizient und auch ökonomisch, sag ich mal, so selber umsetzen. Wenn ich aber auch ein Team mit zehn Leuten da habe, dann will das Team ja auch ausuntersuchten. Dann habe ich ja zwangsläufig auch mehr Kommunikation, auch technologische Risiken.

Das ist dann halt natürlich schwierig. Ja, diesen Mittelweg zu finden, zu sagen, das eine funktioniert, aber wir brauchen auch das andere. Jetzt haben wir Technologien angesprochen, GraphQL, REST, wahrscheinlich, wenn man beide Schnittstellen irgendwie hat, wenn man sich die CMS anschafft. Ich meine, wir haben vorhin über Contentful angekommen, Storyblock, andere CMS, die halt funktionieren und die beides dann bieten.

Und das ist natürlich auch ein Riesenaufwand, die AI-Thematik, die da halt auch noch mit reinspielt. wie kann ich vielleicht mein CMS halt auch in N8N beispielsweise integrieren, sowohl um Daten einzuspielen als auch den anderen Weg raus. Ja, und wir belegen jetzt tatsächlich auch die Grundsteine dafür.

Wir haben dort eine Zwicklung vorgeschrieben, was wir quasi in AI-Ready-Inters herstellen, aber wir brauchen natürlich all dem, auch diese exzellen Schrittstellen. Wir konnten das schon bewerben und sehr gut auf andere Systeme zugreifen, aber wir haben selten die eigenen Anhalte angeboten. Einfach auch gegeben durch das sehr strikte User-Management oder Rechte-Management, was man hat.

Welche Rolle hat denn jetzt dieser Agent, der da von außen auch die Daten zugreift? Dann gibt es halt Workspaces und Sachen, die dann irgendwie von einem in den anderen, Zustand überführt werden, Publishing zu können, alles mögliche. Das muss dann halt letztendlich auch alles über eine AP bereitgestellt werden.

Das ist schon auch aufwendig. Und die Implikationen des Daten hat. Es wirkt immer so einfach, komm, stell da einfach was hin. Wenn REST API für die Daten, die dahinter ist, egal was da davor ist und wenn Prozesse da passieren, aber es ist halt. Im Detail ist das schon heftig und man möchte sicher auch nicht einen riesen Sicherheitsschirm mit Ihrem Stück ziehen.

Und wir sind halt schon als System bekannt davor, dass wir eigentlich sehr stabil und sicher sind. Einfach auch, ja, vielleicht auch ein bisschen zurückhalten, was neuere Technologien gibt. Man kann immer nicht so alles gleichzeitig haben. Wir hätten Logitech ja alles ganz langsam sehen. Vielleicht können wir als Frontend-Podcast noch einmal kurz heilsprechen, dass ja jetzt das Release der Version 14 stattgefunden hat, glaube ich.

Mit dem heutigen Tag, glaube ich, werden wir so. Das wird, glaube ich, später passieren. Genau. Also, wenn ihr das hier hört. Nein, wobei, das ist ja, ich muss sagen, das ist ein 14.0-Release. Ja. Unser eigentliches Release ist eigentlich immer das Long-Term-Submode-Release, was erst im April anstieg.

Das heißt, mit der 14.0 werden viele Features reingesetzt und vor allem alle alten Deplicated-Sachen draus geschwusst. Das heißt, das ist eigentlich immer der Beginn einer Release-Interruption. Also wenn wir jetzt dann bis April durchführen, dann mit der letzten Version aus so einem Release-Tyklus, das ist dann die Version, die dann drei Jahre unterstützt. Ja, auch sehr.

Also deswegen, das ist schon ein Tauchenschlag heute, weil wir ganz viele alte Zöpfe abschneiden und quasi viele neue Kleinigkeiten mit einbringen. Aber jetzt mit der 1, 2, 3, 4, 2, 1, 2 Reifen, die noch kommen werden, werden noch weiteres sein. Aber ihr lüftet ja zumindest den Vorhang über sozusagen die Pläne, die ihr mit der 14er-Version habt.

Und Teil dieser Version ist ja, glaube ich, auch eine neue FUT-Version. Das ist ja die Terminatik, die ihr nutzt. Also wurde gesagt, die ist ja aus dem Neos-Projekt sozusagen abgeholt. Die wird tatsächlich noch so ein semi-gemeinsam entwickelt, wenn ich so mal so zwischen beiden vertreten. Also die ist sowohl im Neos nutzbar als auch in dem YouTube 3.

Das wurde früher auch mal als eigenes Produkt bezeichnet, aber im Modell ist das, ich muss mal sagen, ist mittlerweile vorgelegt und zeigt nicht auf dem Leben. Da habt ihr ein paar Verbesserungen eingefüßen lassen. Also die unterhanden dem Caching, zum Beispiel kommen. Teilweise haben die so Edge-Cases, die seid ihr angegangen, wo irgendwie Inline, CSS und JavaScript je nachdem auch mal zu Programmer-Parser-Problemen geführt haben, einfach weil die in zwei Sprachen sehr viele geschweifte Klammern nutzen, die auch nutzen und so. Ja, genau.

Also ist alles besser und robust geworden. Ja, auch unbedingt. Also da freut mich aber richtig drauf, das zu nutzen. Ich bin sehr gespannt, was noch zum nächsten Mal Ich weiß, ein paar Sachen, die kommen, aber ich darf natürlich auch nicht zu Facebook. Aber vielleicht da eine Frage nochmal nach dem Ausblick. Also wir haben über die Headless-Nationalität gesprochen.

Das ist ein Experimental-Stat, das hast du gesagt. Kann man da schon absehen, wo wir da zeitlich auch hinkommen, wenn man das vielleicht stabiler nutzt? Also was ich fast versprechen kann, ist, dass es mit Sicherheit keine Ready-Made-Lösung. Also Verkopplung mit irgendeinem Frontex, speziell Frontex-Decky gibt.

Und gesagt, das ist jetzt genau das 1.1, was wir empfehlen. Da sind wir, wir werden die Schnittstellen anbieten, dass du eigentlich mit jedem Frontend-Stack, das du hast, das anbinden kannst. Vielleicht gibt es dann auch noch bei uns Contribute, die dann vielleicht in einen kleinen Library oder so einstellen von uns ganz.

Es gibt eine bestimmte Sicherheit mit Dokumentationen oder Houtos oder Tutorials, Abworks oder was gehen. Oder vielleicht auch offizielle Pakete mit Dokumentationen bei uns, die dir sagen, wie du das mit deinem Next.js verkoppelst oder wie du das mit dem Webinarium hast. ist. Also wir zum Beispiel sind sehr, sehr großer und gerne, wir nutzen sehr gerne das ganze Lit und Web Component Stack, weil wir da einfach die Zukunftspflichtigkeit sehen und einfach auch die Stabilität, die gut zum CMS passt und natürlich auch was sagen wir so, und den Hand-Off zwischen serverseitiger Logik und frontal-seitiger Logik ergibt.

Der ist gut abgetrennt von einem Nuggets. Es passt einfach auf. Wir denken an hinten und hier auf der Seite denken wir halt PHP-basierten Komponenten. Aber wie wir das mit der AutoConnect machen, das wird sich zeigen. Deshalb sind wir auch dann ein bisschen in das Agentur gefragt, dass die das auch rausfinden. Aber wir wollen denen natürlich die Schnittstellen anbieten, dass sie es überhaupt können.

Und ist das denn schon ein Thema dann für die LTS-Version, die dann im April kommt? Oder denkst du eher, das wird dann sich noch ein Stück weit danach ziehen? Also es wird auf jeden Fall eine Schnittstelle geben. Eine Headless-Schnittstelle denke ich nicht. Okay, das heißt, da muss man sich dann noch ein bisschen geduldigen, beziehungsweise auf die Experimental Features mal zurückgreifen, beziehungsweise vielleicht sich auch selbst einbringen.

Ja, genau, das meine ich eigentlich. Das finde ich einen sehr, sehr guten Einwand, den wollte ich nämlich jetzt auch gerade bringen. Wir sind ja Community-Driven, das heißt, wir sind von unseren Konfliktoren abhängig. Das heißt, ohne die geht es nicht. Und was wir brauchen, sind. Willige und begabte Wolle. Wie jeder eigentlich in jedem Unternehmen auch braucht.

Aber wir brauchen es als Projekt besonders. Wir haben natürlich auch viel zu bieten. Ich glaube, das merkt man auch in der Veranstaltung. Wir haben sehr viel Community-Spirit. Wir haben eine gute Gesellschaft. Also die Leute in die Community kommen, die bleiben auch für der Top 20 Jahre groß. Das ist das Beispiel, steht vor uns. Ja, also es gibt viele alte auch bei uns, die das Leben.

Es ist nicht nur ein Hobby, Das ist nicht nur noch die Begegnung. Meine Frau fragt mich auch immer, du bist ja immer auf der Arbeit. Da sage ich, es ist sehr schwer abzuglässt. Was ist gerade Arbeit, was ist Hobby, was Freizeit ist, und was meine Ehrenamtlichsten Interesse sind. Aber das ist eine sehr, sehr schöne Entgebung, die man sich toll einbringen kann, wie man sich auch fühlen kann.

Deswegen, ich freue mich über jeden Fall, wenn man unter den Universitäten übergefunden hat, brauchen wir so Sprints oder auch Camps, die wir auf der Gnade im Tanz dort schon haben. Da kann man sich eigentlich überall einbringen. Wir brauchen aber auch natürlich auch das Feedback, wie könnten wir in einer Headless-Umgebung denn eine tolle Rolle übernehmen.

Wir haben einige coole Futures, glaube ich, die andere. Modernere Systeme, die sind trotzdem da, aber die halt jünger auf dem Markt sind, die haben wir nicht. Wir haben sie, umgekehrt nicht auch. Wir müssen aber auch nicht alles rüberkucken. Am Ende ist es vielleicht auch Teil deiner Gesamto-Strategie, welche Komponenten kann man aus welchem System nehmen. Deswegen macht man ja auch ein Äbnis.

Wir nehmen das Stammdaten aus dem System, wir nehmen hier unsere Artikel, also Artikelstammdaten aus dem Tim, wir nehmen hier irgendwie 10 Landingpages aus dem Investment dezentlich, super machen wir da. Das ist ja irgendwie auch populär, das so zu ergänzen. Aber nochmal, um auf den Call-to-Action zu kommen, also auch für die Leute, die jetzt vielleicht Type-3 mal in Betracht gezogen haben, aber gesagt haben, okay, wir haben es jetzt noch nicht verwendet, weil Frontend-seitig passt das nicht für uns oder ähnliches.

Einfach mal vorbeischauen, auf sich mal angucken, was es schon gibt und dann aber gerne auch einbringen. Auch für die Leute, die das vielleicht in Stack vielleicht ein Stück weit ändern wollen, die halt sagen, okay, eigentlich würde ich lieber in Richtung halt Headless-System arbeiten, damit ich im Frontend machen kann, wie ich will, mit Angular oder was weiß ich.

Genau, und da dann auch gerne mal mit einbringen. Ich glaube, wir werden da auch nochmal was zu verlinken, sodass ihr da nochmal nachgucken könnt, wie ihr euch denn da auch einbringen könnt, weil Feedback vielleicht auch vor allem weiß. Also wie gesagt, wir haben diese Headless Extension jetzt mal so für uns.

Mit der kann man auf jeden Fall heute schon ein Headless System bauen. Aber die hat auch einen gewissen vorgeschriebenen Weg. Und die musst du dich dann halbwegs halten. Aber es funktioniert nicht. Also es gibt sehr viele Live-Projekte da draußen, wie das auch der Live-Projekt ist. Und damit auch 16.

Ja, schlussendlich muss man sich auch mal fragen, ja, Headless genau wie jeden Preis, welches Problem löst es? Muss man es haben? Vielleicht muss man es probieren. Gute Fragestellung, die man sich auch nochmal sicher angehen kann. Welche Größe des Teams haben wir angesprochen. Ich würde sagen, wir machen hier mal einen Deckel drauf.

Vielen Dank, Tom, für deine Zeit, für deine Einblicke. Mega interessant auf jeden Fall. Und ja, wir entspannen uns jetzt, hätte ich beinahe gesagt, noch ein bisschen auf der Tetra. Gucken wir uns mal die interessanteren Stände noch an und die Talks, alles, was halt so kommt, ne? Danke.

Anmelden oder registrieren

Jetzt

0:00 / 0:00