Was macht man mit TYPO3? Es ist PHP-basiert. Im Prinzip können eben die Redakteure
da ihre Inhalte eingeben, also ihre Bilder hochladen, Texte eintippen.
Ja, und dann wird daraus eine Internetseite gerendert.
Also es ist eigentlich ein fertiges System, um Webseiten damit zu bauen.
Man kann entweder sagen, TYPO3 ist mein Headless-CMS und rendert kein HTML mehr raus.
Oder man kann eben so Mischlösungen fahren und kann sagen, sagen,
ich will, dass weiterhin das HTML rausgerendert wird, aber für einen bestimmten
Teil in der Seite baue ich mir dann so eine, das nennt sich ja heutzutage Interactive Island,
wo man dann seine, wenn man so will, Single-Page-Application an der Stelle einfügt.
Music.
Revision 602.
Diese Revision von Working Draft wird euch präsentiert von Midwald.
Next Level Hosting für deine Projekte.
Jetzt fragt ihr euch bestimmt, wie kann sowas langweiliges wie Hosting Next
Level sein? Ganz einfach.
Mitvalds hochperformantes Cloud-Hosting ist perfekt abgestimmt auf die Anforderungen
von Freelancern und Agenturen.
Es gibt zum Beispiel ein smartes Rollensystem für die Zusammenarbeit mit euren
Projektpartnern und Mitvald hat mit M-Studio auch eine sehr schöne moderne Verwaltungsoberfläche
gebaut, mit der das Arbeiten Spaß macht.
Aber jetzt mal ehrlich unter uns Nerds. Sachen anklicken? In einem User-Interface?
Muss das sein? Nein, muss es nicht.
Denn bei Mitvald gibt's die M-Studio CLI. Mit der könnt ihr euer Hosting komplett
über die Kommandozeile verwalten und natürlich auch entsprechend automatisieren.
Von Nerds für Nerds bringt euch Mittwald die optimale Developer-Experience,
wenn es ums Hosting geht.
Und deshalb jetzt auf zu mittwald.de slash workingdraft.
Denn da wartet auf euch exklusiv als Hörer von Working Draft das Angebot,
den Tarif pro Space für 30 Tage kostenlos zu nutzen.
Das war nochmal mittwald.de slash workingdraft.
Wir danken Mittwald für die Unterstützung von dieser Revision von Working Draft.
Hallo und herzlich willkommen zur Revision 602 von Working Draft.
Wir sind zu viert heute. Zwei Leute vom Team sind mit dabei. Hi Shep. Hi.
Ich bin's, der Hans und wir haben uns zwei Gäste eingeladen.
Hallo Florian, hallo Simon. Cool, dass ihr dabei seid.
Wir wollen heute ein bisschen über das Thema Typo 3 sprechen.
Da gehen wir gleich aufs Detail ein. Aber bevor wir das machen,
wollen wir natürlich erstmal rein starten und von euch wissen, wer seid ihr denn.
Simon, du bist ganz neu dabei, warst noch gar nicht am Start.
Vielleicht willst du ja einfach mal anfangen, ein bisschen was zu dir zu erzählen.
Wer bist du, wo kommst du her?
Ja, sehr gerne. Das ist übrigens mein Podcasting-Debüt, also was ganz Besonderes.
Oh, herzlichen Glückwunsch, cool. Ja, danke.
Genau, mein Name ist Simon, Simon Pretorius. Ich mache Typo3 seit,
glaube ich, mittlerweile 14 Jahren noch ein bisschen länger das ganze Webzeug,
also eher so HTML, CSS, ein bisschen PHP früher gemacht.
Ursprünglich komme ich aus Baden-Württemberg, also eher Süddeutschland.
Mich hat es mittlerweile aber nach Hamburg verschlagen.
Und habe da jetzt die letzten sechs Jahre in einer Agentur gearbeitet und bin
jetzt seit einem halben, dreiviertel Jahr selbstständig als TYPO3-Entwickler
und auch so ein bisschen Consulting-mäßig unterwegs.
Cool. Das heißt, vorher Festanstellung und jetzt dann entsprechend selbstständig
unterwegs ist natürlich immer ein großer Schritt sowas,
aber gerade wenn man so wie du jetzt das 14 Jahre mit TYPO3 da schon unterwegs
ist, Da kennt man das System natürlich und die Community.
Und so habt ihr, Florian, euch ja dann, glaube ich, auch kennengelernt,
wenn ich das aus dem Vorgespräch richtig in Erinnerung habe.
Du warst ja bei uns schon ein paar Mal dabei oder einmal dabei,
glaube ich. Wir haben mal Glücksrad zusammengespielt. Ich glaube zweimal, oder?
Also einmal Glücksrad und dann das andere war eben mein Themenvorschlag mit
den lernfreundlichen Organisationen.
Und da war ich dann aber selber krank und deswegen nicht in der Aufnahme drin.
Von dir stammt auch der Tipp, die Transkripte mit OpenAI Whisper zu machen,
was sehr gut funktioniert hat und seitdem haben wir hier Transkripte.
Dankeschön. Sehr schön.
Erzähl nochmal, was du machst und wer du bist.
Ja, genau. Also bei der letzten Aufnahme mit dem Glücksrad, die war so spontan,
dass ich, also ich glaube, komplett
die Vor-Selbst-Vorstellung irgendwie übersprungen habe oder viel zu kurz.
Und ich bin Florian Geierstanger, ich komme aus München.
Ich habe erst neulich meine erste Webseite wiedergefunden, die ist von 97,
die gibt es auf archive.org.
Und ich habe also das sehr früh so als Schüler angefangen, Internetseiten zu
machen und dann gleich die nächste, die es auch da archiviert gibt,
da war schon der erste Kunde drauf.
Das war eben so ein großes Hotel aus Oberstdorf. Also ich bin aus diesem Ort
da in den Allgäuer Bergen,
Und habe dann dafür ganz viele Hotels und Ferienhäuser im Internetseiten als Schüler gemacht.
Mit wahrscheinlich Frontpage oder vielleicht später Dreamweaver.
Also so alles in Großbuchstaben.
Das war ganz schön. Und dachte dann, okay, das kann ich eigentlich machen.
Einfach. Und habe dann Kunst studiert und Dokumentarfilm. Habe dann ganz was anderes gemacht.
Dann auch ganz viel unterrichtet. Also hauptsächlich zum Thema Film,
ganz viel mit Lehrern, Lehrerfortbildungen gemacht zum Dokumentarfilm und zum
Experimentarfilm und Filmfestivals kuratiert.
Und irgendwie, wie dann die Geschichte so läuft, bin ich dann wieder mehr ins
Grafikdesign reingeraten und habe ganz viel Grafik gemacht, Printgrafik und online auch.
Und aber die spannendsten Sachen waren irgendwie immer dann doch wieder die
Web-Projekte und dann als die Pandemie losging,
da dachte ich, okay, jetzt ist der richtige Zeitpunkt, dann nochmal irgendwie
zu switchen und habe mir eine Stelle, habe Stellen gesucht und habe dann vor
zweieinhalb Jahren bei einer Agentur angefangen,
und das war eine Typo-3-Agentur.
Ich wusste das gar nicht, ich konnte mit dem Wort gar nichts verbinden,
verbinden, habe dann beim ersten Arbeitstag zum ersten Mal den Admin-Bereich,
das sogenannte Typo3-Backend geöffnet und diese ganzen.
Tausenden Einstellungen und bin dann in zweieinhalb Jahren irgendwie,
ich habe das Gefühl, ziemlich gut reingeraten.
Also ich war auch erst skeptisch, dachte irgendwie, was ist das,
wenn irgendwie meine Kollegen haben dann immer gesagt, ja, das ist alles ist historisch gewachsen.
Ich fragte, warum ist es so? Ja, ist historisch, hat historische Gründe und
da gibt es ziemlich viele historische Sachen, aber trotzdem,
also, sie hatten dann auch eben recht, die Kollegen, dass nach einer Zeit irgendwie
bin ich da auch ganz gut reingekommen und,
nicht nur in die Technik von TYPO3 und in den Stacks, sondern auch in die TYPO3-Community.
Also, ich kannte die natürlich auch vorher nicht, aber da gibt es eben eine
ganze, hauptsächlich auf Deutschland zentrierte Community,
die sich um dieses Thema dreht und irgendwie, das war sehr schön,
da so Stück für Stück immer weiter reinzukommen und da, jetzt schließt sich
sozusagen der Kreis wieder zurück zum Simon, da bin ich dem Simon begegnet.
Erst, ich denke, online und dann irgendwann auch mal auf der TYPO3-Entwicklerkonferenz
in Karlsruhe dann auch mal haben wir uns so tatsächlich dann kennengelernt.
Und jetzt sind wir zusammen im Podcast.
Cool. Ja, diese TYPO3-Entwicklerkonferenzen, wenn ich mich da richtig erinnere,
vor zehn Jahren oder ein bisschen länger her noch, war ich da ja auch mal ein
bisschen in dem Bereich unterwegs und da war das schon immer so der Connection
Point, wo man so sehr viele Leute,
Core-Contributorinnen und Contributor kennengelernt hat und alles sehr nahbar,
was ich immer sehr, sehr interessant fand.
Aber bevor wir da zum Thema Community sprechen, fangen wir vielleicht nochmal an ganz vorne.
Was ist eigentlich Typo 3 jetzt? Typo 3, wie auch immer, ihr könnt mir gerne
sagen, wie man es dann richtig sagt, gibt ja auch immer die Diskussionen zu.
Was macht man mit Typo 3? Ist es
ein CMS? Das wissen wahrscheinlich die allermeisten Hörerinnen und Hörer.
Vielleicht könnt ihr da nochmal ein Stück weit zu sagen. Florian,
willst du einfach mal anfangen?
Ja, also es ist ein CMS, ein Content-Management-System, man hat halt ein,
ich meine, der beste Vergleich ist vielleicht, was die meisten kennen, ist WordPress,
es stammt auch aus derselben Zeit, also ist auch, ich glaube,
Typo3 und WordPress sind beide so 2001 rumgestartet, beide Projekte,
Simon schüttelt so halb den Kopf. Ich schüttel nicht den Kopf.
Aber ich glaube, TYPO3 ist noch ein bisschen älter. Ich glaube,
so Ende der 90er irgendwann. Ich habe jetzt die Zahlen nicht genau im Kopf.
Aber so Ende der 90er ist es entstanden, genau.
Es ist PHP-basiert, MySQL-Datenbank. Und im Prinzip können eben,
die Redakteure da ihre Inhalte eingeben, also ihre Bilder hochladen, Texte eintippen. und.
Ja, und dann wird daraus eine Internetseite gerendert.
Also es ist eigentlich ein fertiges System, um Webseiten damit zu bauen.
Und das Interessante ist eben an dem System, was es schon alles mitbringt.
Und da ist zum Beispiel bei TYPO3 so, es bringt die komplette Mehrsprachigkeit mit.
Also du kannst in allen Sprachen eine Webseite in zig Sprachen anlegen und die
auch so miteinander verknüpfen. Also auf Seitenebene oder sogar auf Block-Ebene.
Oder es bringt auch ein ganzes Benutzermanagement-System mit.
Also welcher Benutzer kann sich einloggen und kann da Inhalte ändern?
Auf was hat er Zugriff? Welche Seiten kann er ändern? Man kann ganze Gruppen
von Benutzern anlegen, die verschiedene Rechte haben.
Und das ist wahnsinnig feinkönig. Also bis hin zu welchen Blog auf welcher Seite,
welcher Blog-Typ, da wer Zugriff drauf hat,
Lesezugriff oder Schreibzugriff oder er kann ihn auch nur anlegen oder nicht anlegen.
Also das kann man alles ganz, ganz feinkönig einstellen. Das ist einfach alles
schon Teil dieses Typo 3 System.
Ja, ich würde auch sagen, das sind so ein bisschen die Unterschiede zu sowas wie WordPress.
Also WordPress war ja ursprünglich mal ein Blogging-System und ist mittlerweile
so mehr in Richtung, hat sich mehr in Richtung CMS entwickelt,
wurde so ein bisschen aufgebohrt. Bei Typo3 hat es halt wirklich als Content-Management-System angefangen.
Das heißt, von Anfang an mit den Features eben nicht auf einem Blog konzentriert,
sondern auf Content-Management.
Und das zeigt sich auch ein bisschen daran, bis heute halt, was da für Features
drin sind, die man zum Beispiel bei WordPress eben dazu installieren muss mit Plugins.
Also diese ganze Berechtigung der Seitenbaum. Seitenbaum ist, glaube ich, so ein...
Ich weiß nicht, ob Alleinstellungsmerkmal, aber auf jeden Fall im Vergleich
zu WordPress komplett anders.
Es funktioniert eben über einen Seitenbaum und weniger über so eine Auflistung
von Blogposts oder Seiten, wie das bei WordPress eher der Fall ist.
Es geht ganz viel über diesen Seitenbaum im Backend, der auch eigentlich die
ganze Zeit bei der Bearbeitung sichtbar ist.
Und es ist halt, nennt sich selber auch Enterprise Content Management System,
also hat halt viel so Features, die auch bei großen Webseiten nötig werden.
Also die Mehrsprachigkeit hat Florian ja schon angesprochen,
die ganzen Berechtigungsfunktionen, auch zum Beispiel, dass man mehrere Websites
aus einem Typo 3 betreiben kann,
dann Daten quasi über diese Websites hinweg teilen kann, also dass man eine
zentrale Stelle hat, wo irgendwelche Datensätze liegen, die dann in allen fünf
Sites, die daraus generiert werden, verwendet werden.
Denn lauter solche Sachen, bis hin zu so Freigabe-Workflows,
das nennt sich dann Workspaces, wo man sagen kann, es gibt irgendwie einen Redakteur,
der darf bearbeiten, aber das nicht auf die Website publizieren,
sondern es gibt eben noch Chefredakteure in der Mitte, die sagen,
ist okay so oder müsst ihr nochmal bearbeiten.
Du hast es eben erwähnt, ganz kurz im Zusammenhang mit WordPress,
nämlich das Thema Plugins, beziehungsweise Erweiterungen.
Einen Punkt, den ich von damals noch kenne, ist, dass gerade Themen,
die jetzt noch nicht abgearbeitet wurden von dem Core CMS, nenne ich es jetzt mal,
waren halt immer sehr gut ergänzbar durch Plugins oder Module oder wie auch
immer man es dann im Type of Three Kontext nennt.
Ist das immer noch so ein Thema oder hat sich mehr in den Core verschoben?
Das ist wahrscheinlich so eine Mischung. Also es gab so ein paar Dinge,
die einfach so Basic Features waren, die die ganze Zeit gefehlt haben.
So was wie die URLs aufgebaut werden.
Also zum Beispiel, wenn man jetzt irgendwie einen News Post hat,
dass dann eben der Titel des News Posts auch Teil der URL wird und das nicht
irgendeine kryptische URL, Index.php, Fragezeichen, ID gleich 1, 2, 3 ist.
So war das nämlich bis zu, ich glaube bis Typo 3, 8 war das so,
dass der Core von sich aus erstmal keine schönen URLs generiert hat und man
dann eben schon Plugins oder bei TYPO3 heißt es Extensions gebraucht hat.
Und da gibt es halt so ein paar quasi Essentials, die dann in den Core reingewandert
sind, wo man quasi sich eine schönere, erweiterbare Lösung überlegt hat.
Aber es gibt immer noch einen riesen Fundus an Extensions, die auch relativ gut gepflegt werden.
Es gibt mittlerweile auch sowas, das nennt sich Verified Extensions,
die dann auch sich so ein bisschen an den Release-Zyklus von TYPO3 angepasst
haben und sich da dran binden, sodass man eigentlich relativ sicher sein kann,
dass man die auch verwenden kann mit der neuen TYPO3-Version relativ schnell
und nicht irgendwie zwei Jahre warten muss, bis der Entwickler halt dann Zeit hatte,
die quasi auf die neue Version anzupassen.
Ein Thema, was ich immer im Kopf hatte, ich glaube, du hast jetzt gerade nicht
erwähnt, sind Formulare gewesen.
Da gab es ja immer, sagen wir mal jetzt Kontaktformular, was man so erstellen will oder ähnlich.
Da gab es dann immer irgendwelche Spezial-Extensions, die man hart konfigurieren muss.
Ist das immer noch eine Extension, die da sozusagen dazugeladen werden muss
oder ist das jetzt sozusagen Teil des CMS geworden?
Es ist Teil des CMS, es gibt aber auch immer noch Extensions dafür.
Das heißt, wenn man die Core-Lösung nicht will oder die irgendwas nicht kann,
was man haben will oder so, kann man immer noch die Extensions,
auch teilweise wirklich die von früher, die wurden halt weiterentwickelt,
kann man immer noch verwenden.
Aber mit der Core-Version kann man relativ viel machen. Das ist so ein Formular-Editor im Backend.
Wenn man das will, kann man sogar den Redakteuren sagen, ihr könnt eure Formulare
selber zusammenklicken und dann speichern und daraus dann zum Beispiel eine
Mail generieren oder sowas.
Also das ist mittlerweile Teil des Cores.
Wenn ihr jetzt mal so sagen würdet, was sind so die Haupt,
sag ich mal jetzt Konkurrenten, hört sich schon so belastet an,
aber so die Haupt-Competitors trotzdem von Type of Three, was gibt es noch so
für andere CMS, die so in dem Bereich angesiedelt sind?
Also so aus der Open-Source-Welt würde ich sagen, ist so ein Drupal,
vielleicht eher für die größeren Seiten ein Competitor und für die kleineren
Seiten eher so die WordPress-Richtung oder halt so diese Website-Baukästen wie Squarespace oder so.
Also die graben natürlich von unten auch wahrscheinlich zurecht da ein bisschen ab,
weil halt nicht jeder irgendwie eine Agentur braucht, um eine Website für dann,
was weiß ich, den Blumenladen nebenan zu bauen, sondern da reicht halt dann so ein fertiges System.
Und ich glaube, im großen Bereich sind das halt dann auch die kommerziellen
Sachen, also irgendwelche Adobe-Lösungen oder so.
Da kann Typo3 mithalten, Aber, ja,
da gibt es halt dann auch diese kommerziellen Lösungen und da ist dann eben
die Entscheidung vom Kunden,
wollen wir eher auf eine Open-Source-Variante stecken, wo dann unser Geld eher
in die Eigenentwicklung reingesteckt wird oder wollen wir eher so eine riesen
kommerzielle Lösung haben,
wo man dann halt die Lizenzgebühren zahlen muss.
Es gibt ja jetzt auch viel die Bewegung dann in Richtung, sagen wir mal,
Headless CMS, ich nehme jetzt mal einen Storyblock, Contentful oder ähnliches.
Wie positioniert sich da Type of 3 dazu oder wie steht da Type of 3 dazu?
Also ursprünglich ist Typo3 ein CMS, was quasi das HTML rausrendert, also nicht Headless.
Es gibt mittlerweile aber eine relativ bekannte Extension, die Headless Extension,
die das umsetzt und man kann auch relativ flexibel da irgendwelche JSON-APIs
mitbauen und so. Also das geht mittlerweile echt gut.
Das heißt, man kann entweder sagen, Typo 3 ist mein Headless CMS und rendert
kein HTML mehr raus oder man kann eben so Mischlösungen fahren und kann sagen,
ich will das weiterhin, dass HTML rausgerendert wird, aber für einen bestimmten
Teil in der Seite baue ich mir dann so eine,
das nennt sich ja heutzutage Interactive Island,
wo man dann seine, ja, wenn man so will, Single Page Application an der Stelle
einfügt und dann eben die Daten über eine JSON-API. die ihr aus dem Typo 3 rauskriegt.
Simon, du hast ja die Typo 3 Entwicklerumfrage gemacht, oder, im Sommer.
Und wenn ich mich richtig erinnere an die Ergebnisse, dann war es aber doch so,
dass die meisten Entwickler angegeben haben,
sie setzen aktuell nicht solche Headless-Varianten ein, sondern sehr klassisch
einfach die Templating-Sprache, Fluid, und rendern damit eben die HTML-Seiten
raus auf dem Server mit PHP.
Genau. Also vielleicht zum Hintergrund.
Ich habe auf der letzten TYPO3-Entwicklerkonferenz einen Vortrag gehalten zu
verschiedenen Frontend-Ansätzen, also ein bisschen vorgestellt, was gibt es da alles,
verschiedene Varianten, also entweder halt so Single-Page-Application und Headless
oder halt eher so den modularen Ansatz, wo man sich sein Frontend dynamisch
zusammenbaut und halt vom Server HTML auch rendern lässt.
Test oder so ein Ansatz, wo man quasi so ein fertiges Theme,
wenn man so will, davor hat. Bei Typo3 ist es meistens Bootstrap.
Da gibt es halt eine fertige Extension, wo alle Content-Elemente schon mit Bootstrap gestylt sind.
Das sind so die drei Varianten. und nach dem Talk habe ich dann eine Umfrage
gestartet, Online-Umfrage und da haben 93 Leute daran teilgenommen und von denen
waren jetzt nur sieben, haben gesagt,
ja, ich verwende aktuell den Headless-Ansatz.
Es gab aber relativ viele, die gesagt haben, ich möchte mir das jetzt mal anschauen.
Also wenn man diesen Zahlen trauen darf, dann geht es von sieben auf 26 bei dem Headless-Ansatz.
Also es scheint schon so zu sein, dass da so ein bisschen der Trend auch ankommt,
aber es gibt immer noch relativ viele, die sagen,
nö, eigentlich ist es ja genau die Stärke von dem System, dass man halt damit
das HTML auf dem Server generiert und dann einfach ausliefert,
schön gecached und schnell und so.
Ja, ich glaube, sowas ist wahrscheinlich dann spannend, wenn man Seiten baut,
die sich ihren Inhalt aus verschiedenen Quellen zusammenziehen.
Also dann ist es ja ideal, wenn man verschiedene APIs hat, die man anzapfen kann.
Ich wollte noch eine Sache sagen, die ja auch irgendwie so Typo3-spezifisch
ist, nämlich die Tatsache, dass es zwar von einem Dänen entwickelt wurde,
aber eigentlich so seine größte Community und Fanbase und auch die meisten Einsätze
so im deutschsprachigen Raum hat.
Also ich glaube, es gibt viele Ecken auf dem Globus, da kennt man Typo3 halt auch gar nicht.
Und Drupal ist ja dann auch eher so vielleicht so Niederlande,
Benelux so, da kommt das her und ich glaube, da wird das auch viel eingesetzt,
also das ist schon, ich habe den Eindruck, dass eben die ganzen,
die wichtigen Entwickler und die ganzen,
Community-Leute eben dann auch,
greifbar sind, weil sie eben hier aus der Ecke kommen, sozusagen.
Ja, kann man wahrscheinlich genauso sagen. Es gibt da schon Bestrebungen,
das das ein bisschen noch mehr zu internationalisieren, also irgendwie in Richtung
USA vielleicht sogar zu gehen.
Es gibt auch einige Projekte in Afrika, gerade so im öffentlichen Bereich,
also Regierungen oder irgendwelche NGOs oder so.
Das ist halt auch so ein Steckenpferd, auch in Deutschland, dass halt viele
so Regierungen oder Stiftungen oder so was oder Universitäten auf Typo 3 setzen.
Und da gibt es jetzt halt auch Bestrebungen, das zum Beispiel in Afrika zu machen.
Es gibt auch eine kleine, aber doch ganz stattliche Community in Indien zum
Beispiel, die TYPO3 einsetzen, also ein paar TYPO3-Agenturen in Indien.
Also es ist jetzt nicht so, dass es gar nicht gibt, aber der Fokus liegt schon
sehr klar auf Deutschland.
Und das sieht man, das wirkt sich wahrscheinlich dann auch so ein bisschen auf
die CMS-Wahl in Deutschland aus, dass halt vielleicht so ein mittelständisches
Unternehmen dann halt sagt, okay, Typo 3 ist ja gar keine schlechte Wahl,
weil wenn ich irgendwie mit der Agentur, mit der ich jetzt zusammenarbeite,
nicht mehr klarkomme, dann gibt es ja noch genug andere in Deutschland. Land.
Und das macht's halt dann irgendwie ganz attraktiv, sowas wie Typo 3 einzusetzen,
weil man eben nicht so ein, ja, so ein Orchideen-CMS hat.
Genau, ich glaub auch, dass, ich weiß nicht, ist das immer noch der Fall,
dass der Matthias Schreiber so viel von der Entwicklung von Typo 3 lenkt oder macht er das nicht mehr?
Der kommt hier nämlich aus Düsseldorf und.
Macht er immer noch? Macht er jetzt nicht mehr, aber die Typo 3,
also es gibt ja mittlerweile eine Typo 3 GmbH, die so ein bisschen so kommerziellen
Bereich macht, also so Long-Term-Support-Lizenzen und so.
Und da war er lange tätig in der Typo 3 GmbH, ist er mittlerweile nicht mehr,
aber der hat da ganz viel gemacht in den letzten Jahren auf jeden Fall. Ja.
Aber die Typo 3 GmbH ist da jetzt mittlerweile echt sehr aktiv und stellt auch
ganz viel finanzielle Ressourcen halt zur Weiterentwicklung bereit,
die dann zum Beispiel so querfinanziert werden über so längere Support-Zeiten.
Also jede Typo-3-Version hat drei Jahre normalen Support, also Bug-Fixing und so weiter.
Und nach drei Jahren kann man sich dann noch weitere drei Jahre so immer in
Einser-Schritten dazukaufen als Support und kriegt dann eben noch Patches für
die älteren Versionen auch,
auch wodurch man halt dann bis zu sechs Jahre auf einer Typo-3-Version bleiben
kann, was schon gar nicht schlecht ist.
Ja, so ein bisschen wie Microsoft das ja auch macht.
Also für Windows-Versionen oder so. Ja, das ist schlau.
Vielleicht könnt ihr noch mal was zum Governance-Modell im Allgemeinen sagen.
Ihr habt ja schon gesagt, es handelt sich um eine Open-Source-Software.
Du hast jetzt aber eben auch Lizenzen erwähnt und jetzt gibt es halt da diese
Firma, die damit halt irgendwie Kohle macht und dadurch aber auch wieder die
Entwicklung unterstützt, wie ich das jetzt verstanden habe.
Würde mich mal interessieren, also wie ist das mit den Contributions,
woher kommt die Kohle dafür, wird das finanziert, ja, so dieses ganze Konglomerat.
Ja, also ich glaube, ganz im Detail kriege ich es jetzt auch nicht alles zusammen.
Im Groben gibt es die TYPO3-Association, das ist quasi der nicht kommerzielle
Teil und die TYPO3-GmbH, die aber eng zusammenarbeiten.
Und mittlerweile ist es halt so, dass die TYPO3 GmbH durch solche längerfristigen
Support-Modelle so viel Geld
einnimmt, dass sie eben die komplette Core-Contribution finanzieren kann,
also die ganze Core-Entwicklung, das ist ganz cool. Cool.
Was da noch dazu kommt, ist, dass es halt relativ viele Association-Member gibt,
so heißt es dann, von ganz großen Agenturen, die dann so ein Platinum-Membership haben,
bis zu einzelnen Entwicklern, die dann irgendwie für 7 Euro oder 5 Euro im Jahr
dort Mitglied sein können.
Und das sind jetzt mittlerweile über tausend Mitglieder in dieser Association,
die dann eben auch bis zu einem gewissen Grad mitentscheiden können,
was dann mit dem Geld passiert,
mit diesem Jahresbudget, die auch je nachdem auch Möglichkeiten haben,
zum Beispiel zu Code Sprints zu gehen und dann das Geld sich zurück erstatten lassen können.
Also da gibt es dann halt finanziellen Support für Leute, die eben mitwirken
können, aber es zum Beispiel rein finanziell irgendwie nicht hinkriegen oder
irgendwie ihre Zugtickets dann erstatten lassen können oder sowas.
Genau. Ja, und es ist halt dann dieses Zusammenspiel von diesen beiden Organisationen,
die einen eher so auf der kommerziellen Seite und die anderen eher auf der nicht kommerziellen Seite.
Und ich glaube, bei der TYPO3 GmbH ist halt noch interessant,
dass sie jetzt nicht auf dem Agenturmarkt tätig werden.
Also die machen den TYPO3 Association Mitgliedern jetzt keine Konkurrenz,
sondern versuchen eher, die zu unterstützen und halt solche Sachen anzubieten
wie längere Supportzeiten. Brauchzeiten.
Das ist so ein bisschen die Abgrenzung, weil sonst wäre es natürlich schwierig,
wenn dann irgendwie das Produkt selber sich Kunden sucht, das wäre nicht gut,
aber das ist explizit nicht der Fall.
Und es gibt auch ein paar Core-Entwickler, die tatsächlich bei der TYPO3 GmbH
arbeiten, Vollzeit am TYPO3 Core.
Das hilft natürlich auch, wenn man da so ein paar Personen hat,
die da so die Man- und Woman-Power in die Entwicklung reinstecken können,
ohne immer durch irgendwelche Kundenprojekte rausgerissen zu werden.
Das ist gerade bei so paar elementaren Leuten schon echt praktisch.
Wie viele feste Entwickler sitzen da, sitzen jetzt am TYPO3-Core? Weißt du das?
Nicht ganz aus dem Kopf. Also es gibt welche in der TYPO3 GmbH und es gibt aber
auch teilweise Agenturen, die Entwickler zu 100 Prozent einstellen, nur für den Core.
Und die werden dann finanziert von der TYPO3 GmbH auch?
Oder ist das dann sozusagen das Eigeninteresse dieser Agenturen,
das System weiterzubringen? Also finanzieren die das dann selber?
Genau, letzteres. Also die finanzieren das selber. Natürlich,
da wird es bestimmt mal irgendwie Fälle geben,
dass irgendein Kunde in eine besondere Richtung was vom Core haben will und
dann halt in die Richtung auch ein bisschen die Core-Entwicklung gelenkt wird.
Aber es ist jetzt nicht so, dass die auf Kundenprojekten arbeiten,
sondern sie arbeiten im Wesentlichen eigentlich nur für den Typo-3-Core und
haben dann halt vielleicht so ein bisschen Fokus von der Agentur geprägt.
Ja, das gibt es ja bei Browsern auch. Also gibt es ja hier zum Beispiel die Firma Igalia,
die letztendlich nichts anderes ist als so Programmierfirma,
die man anheuern kann und Bloomberg macht das zum Beispiel und die implementieren
dann in allen möglichen Browsern irgendwelche Features, die Bloomberg haben will.
Und am Ende bringt es aber dann alle voran.
Es werden halt die Prioritäten dann ein bisschen anders gesetzt vielleicht,
aber das geht ja dann alles upstream an alle.
Also das ist ja dann kein exklusives Ding, finde ich super.
Ich glaube, es gibt auch so ein paar Core-Entwickler, die jetzt nicht bei einer
Agentur sind, sondern zum Beispiel so wie ich irgendwie als Freelancer unterwegs,
die man aber dann zum Beispiel anheuern kann, um einen Core-Bug zu fixen oder
irgendwie solche Sachen.
Das ist halt auch ein Modell, wie das funktionieren kann, dass man das halt nicht für lau macht,
aber natürlich lebt das ganze Produkt halt auch von ganz vielen Freiwilligen,
die das in ihrer Freizeit machen und das dann entweder quasi für ihre eigenen
Projekte und dann halt Open Source stellen, so wie ich es jetzt zum Beispiel häufiger mache,
oder halt einfach nur was entwickeln, weil sie Spaß dran haben,
ohne jetzt ein konkretes Projekt zu haben.
Das heißt, das ist dann wirklich quasi eins zu eins sponsern,
also ihre Zeit sponsern, sagen wir so. Ja, genau.
Und was so die Historie von Typo 3 angeht, da erinnere ich mich dran,
das ist aber auch schon lange her, dass es da irgendwann mal so ein bisschen
zu einem Stillstand kam und dann waren ja hier so diese Bestrebungen, alles neu zu machen.
Der ursprüngliche Plan ist ja dann nicht aufgegangen und das Neue hat nicht
das Alte ersetzt, sondern daraus sind dann ja sozusagen zwei Schienen geworden.
Neos ist dann dieses, was eigentlich Typo 3 ersetzen sollte.
Und ich glaube, dann fing es eben wieder an mit der Entwicklung von Typo 3.
Und ich glaube, dass das alles danach auch so ein bisschen professionalisiert
und besser strukturiert wurde.
Genau. Also zu der Zeit war ich noch nicht so sehr in der Community drin und
habe das eher nur so am Rande verfolgt als jemand, der halt Typo 3 einsetzt.
Aber man hat dann deutlich, also zu dem Zeitpunkt, als dieses Split-Thema war,
hat man das gemerkt, dass es so ein bisschen Stillstand war,
weil halt ganz viele Ressourcen in das neue fancy Neos gingen und alle das ...
Klar, es lohnt sich ja dann auch nicht, das alte noch groß weiterzuentwickeln. Genau.
Und dann haben sich so ein bisschen zwei Philosophien, würde ich sagen, rausentwickelt.
Die einen, die halt versuchen, das Alte weiterzubringen, zu modernisieren und so weiter.
Und die anderen, die halt auf der modernen Code-Basis von Nios natürlich viel
schneller, schlagkräftiger neue Features und so weiter einbauen konnten,
auch mal irgendwie was wegwerfen, was halt ja noch nicht so lange da war.
Wohingegen, wenn man bei Typo 3 was wegwirft, dann muss man halt sich sehr gut
überlegen, was mit den ganzen Installationen ist, die da draußen sind.
Und in der Zeit ist dann auch dieser feste Release-Zyklus entstanden mit diesen,
es gibt immer so Sprint-Releases bis zu einem LTS-Release.
Und dieser LTS-Release hat dann eben diese drei Jahre Support-Zeitraum und dann
nochmal drei Jahre, die man sich dazu kaufen kann, wenn man das dann haben will.
Und das bedeutet, dass es jetzt einmal im Jahr ... Oder wie oft gibt es jetzt neue Typo-3-Releases?
Ui, ui, ui. Ich glaube, alle anderthalb, meine ich.
Kann ich jetzt nur schieflegen. Ich glaube, anderthalb, ja. Ja, okay.
Und du hast ja gesagt, Typo-3 lebt ja auch von den vielen Contributions der Leute.
Das ist natürlich dann auch eine Herausforderung, das zu managen,
das so alles zu koordinieren und in eine Richtung zu lenken.
Aber das macht wahrscheinlich, machen die Menschen, die in der Typo 3 GmbH sind,
wahrscheinlich sozusagen hauptberuflich, dass sie so ein bisschen,
dass sie vielleicht irgendwie die Roadmap abstimmen und festlegen,
dass sie irgendwie die Aufgaben und Teams so ein bisschen einteilen,
koordinieren und Contributions vielleicht auch, auch, ich weiß nicht, in Augenschein nehmen?
Tatsächlich ist es nicht genau so. Also es gibt eine Gruppe von Leuten,
die Core-Merger heißen die.
Die dürfen halt im Prinzip alles mergen, haben aber zumindest teilweise Fokus
auf bestimmte Bereiche von Typo 3.
Und dann gibt es einen, der...
Ich weiß nicht, wie sein Titel genau ist, der quasi der Head of Development ist, der Benni Mack.
Und der arbeitet nicht für die TYPO3 GmbH, sondern der ist CTO einer TYPO3-Agentur aus Stuttgart.
Und der koordiniert quasi so die gesamte Weiterentwicklung, Roadmap-Entwicklung
und so weiter. Aber natürlich viel Support von außen und auch von der TYPO3 GmbH.
Also letztendlich ist es so ein Team-Effort, mit ein paar Einzelpersonen,
die halt da deutlich mehr reinstecken, mehr Zeit reinstecken als andere.
Vielleicht gehen wir mal noch ein bisschen in Richtung Technik. Was haltet ihr davon?
Können wir machen. Ja, genau. Wir hatten ja schon mal ein bisschen über das
Thema Frontend jetzt gesprochen und die unterschiedlichen Ansätze, die man da verfolgt.
Also wenn ich das nochmal resümiere, dann war es ja so, man kann Type of Three
als irgendwie Headless-System verwenden, Machen nicht so viele Leute bisher,
vielleicht wollen es ein paar mehr machen.
Der Hauptanwendungsfall ist aber halt, als integrative Lösung sozusagen Templates
innerhalb von Typo3 zu schreiben. Wie macht man das denn?
Ja, gute Frage. Genau, jetzt kommen wir nämlich auch dem her,
wir wollten ja eigentlich keine so eine Allround-Typo3-Sendung machen,
sondern eben auf die Frontend-Entwicklung und in Typo3 fokussiert.
Genau, es gibt eine Template-Sprache, die heißt Fluid,
typo3-fluid, und damit schreibt man eben HTML-Dateien, mit diesem Fluid-Syntax
übergibt man denen Daten und dann eben auch,
was man noch braucht zum Frontend, also CSS und JavaScript-Dateien.
Vielleicht, sorry, wenn ich da ganz kurz reingrätschen darf,
nochmal dieses Fluid, kannst du das nochmal ein bisschen genauer erklären,
also das, mit was kann ich das vergleichen, wenn ich das jetzt gar nicht kenne?
Ja, die Frage geht an Simon. Doppelpunkt anfangen, also so einem XML-Namespace.
Es gibt da sowas wie f-doppelpunkt-if, womit man dann eben eine Condition machen kann.
Es gibt f-doppelpunkt-format-punkt-date, um ein Datum zu formatieren.
Also sprich, es ist so eine Template-Sprache, wo man im Template Formatierung
auch einzelne Sachen auslagert.
Es nennt sich dann Partials, wo man quasi eine Sache, die fünfmal verwendet
wird, eben nur in einer Datei drin hat und die dann an verschiedenen Stellen verwenden kann.
Also eigentlich eine relativ mächtige Sprache und dazu ist sie eben auch erweiterbar.
Das heißt, man kann seine eigenen, das nennt sich dann View-Helper,
schreiben, das ist dann eine PHP-Klasse, die dann nachher als so ein XML-Tag
im Template aufgerufen werden kann.
Und ich meine mich zu erinnern, dass Fluid auch die Möglichkeit bietet,
glaube ich, Daten irgendwie lazy reinzuziehen.
Ich habe nur einmal mit Fluid Templates gearbeitet. Genau, die Syntax ist halt
gewöhnungsbedürftig, einfach aus dem Grund,
weil wir ja sonst eher so was an Moustache-Angelehntes verwenden oder vielleicht
irgendwie Nunchucks oder so.
Genau, und XML haben wir ja lange nicht mehr gesehen im Frontend, würde ich sagen.
Da muss man einfach irgendwie erstmal drüber wegkommen.
Genau, und die Leute, die eben mit U3 arbeiten, die hatten mir das eben erzählt,
dass das irgendwie möglich ist, aber vielleicht, oder ich hab's falsch verstanden,
aber das fand ich irgendwie ganz cool,
weil das ja letztendlich bedeutet,
dass die Daten eben, die können das Rendern nicht so einfach blockieren,
wenn das denn stimmt, sondern man kann eben schon mal losrendern und die Daten
kommen dann irgendwie später rein.
Ja, also generell läuft das ja auf dem Server ab. Insofern muss man sowieso
warten, bis das Rendern fertig ist.
Egal, ob das jetzt asynchron oder synchron ist. Vielleicht, wo sie drauf angespielt
haben damals, war so Datenbank-Queries.
Also, dass man, wenn man jetzt irgendwie eine Liste generieren will und auf
jeder Seite sind nur zehn Einträge, es sind aber hundert in der Datenbank,
dass man dann sich vorher nicht Gedanken machen muss, wie viel lade ich denn
jetzt aus der Datenbank,
sondern erst beim Aufruf das sagt und dann im Hintergrund nochmal das Query
angepasst wird, weil das zu dem Zeitpunkt noch gar nicht ausgeführt worden ist,
wenn man vorher alles richtig gemacht hat.
Das ist sowas und das hieß früher Widgets und mittlerweile ist es aber auch ein bisschen anders.
Aber das ist, glaube ich, eher so eine Detailimplementierung,
die jetzt weniger mit der Template-Sprache zu tun hat an sich.
Okay. Also letztendlich funktioniert es halt dadurch, dass man eben eigene Funktionalitäten
in Form von diesen View-Helpern hinzufügen kann, relativ einfach.
Also man muss halt dann irgendwie eine PHP-Klasse schreiben,
Und dann in dieser PHP-Klasse sagen, welche Sachen gibst du mir rein und was mache ich damit?
Und hat damit relativ breite Möglichkeiten, die man natürlich dann auch falsch nutzen kann, wie immer.
Also zu viel Intelligenz sollte in der Vue ja da nicht stattfinden,
aber ist halt auch sehr mächtig.
Da kommen wir vielleicht später auch noch dazu, wenn wir über die Komponentenerweiterung reden.
Noch eine frage zu der template engine wäre es
theoretisch möglich von fluid auf eine andere zu wechseln also es gibt ja also
so am verbreitetsten im php raum ist vielleicht trick und dann gibt es ja noch
blade in den hier laravel geschichten wäre das möglich oder ist das nicht so möglich.
Prinzipiell ist es möglich. Es ist im Moment noch nicht so schön,
wie man es gern haben will.
Das ist aber eine Bestrebung, die im Core gerade so ein bisschen reift.
Also dass man mal die Möglichkeit schafft, da weitere anzubinden.
Gleichzeitig ist es aber so, dass in Fluid halt relativ viel auch Typo-3-nahes weiterverarbeiten.
Also irgendwie die spezielle Link-Syntax, um zu sagen, ich möchte jetzt auf
diese Typo3-Seite im Backend verlinken.
Solche Sachen sind halt alle in Fluid implementiert und die müssten dann für
die jeweilige Template-Engine in deren Syntax, was auch immer,
wie man die eben erweitert, dann halt nachimplementiert werden.
Aber im Prinzip ist es möglich und es wird wahrscheinlich irgendwie in nächster
Zeit noch einfacher möglich werden, sodass dann Leute von außerhalb sagen können,
ich möchte jetzt aber Twig verwenden oder Blade oder was auch immer.
Im Moment ist es de facto in den Projekten ist es so, dass halt immer Fluid
im Einsatz ist und es höchstens vielleicht so vorgelagerte Dinge gibt,
dass man dann irgendwie sein HTML in so einem externen Style Guide baut und
dann nachher irgendwann in Fluid rein integriert.
Das ist, glaube ich, ein Prozess, der häufiger da ist. Ja.
Das ist jetzt eigentlich auch genau dein Themenbereich, Simon, oder?
Weil du bist seit einigen Monaten auch einer von, ich glaube,
drei Maintainern von der Templating-Sprache, von Fluid.
Ja, zusammen mit, weil das ja sonst zu langweilig wird, sich nur selbstständig
zu machen, habe ich auch gleichzeitig auch noch gesagt, ich will einer von den
Fluid-Maintainern werden.
Und das entstand so ein bisschen daraus, weil ich in dem Job vorher bei der
Agentur ein Projekt losgetreten habe, das nennt sich Fluid Components,
was Fluid um so komponentenbasierte Arbeitsweise erweitert hat.
Das ist eigentlich relativ naheliegend, weil da ja schon eine XML-basierte Syntax ist.
Das heißt, man kann sich dann seine Komponenten, die dann aber halt serverseitig
generiert werden oder gerendert werden und nicht wie so Web-Components kleinzeitig,
man muss sich quasi seine eigenen HTML-Tags zusammenbauen und die eben auch
dann wieder in HTML nur definieren.
Das heißt, man muss nicht irgendwelches PHP schreiben, um eine Komponente zu
bauen, sondern man kann die eben in reinem Fluid zusammenbauen.
Genau, und das war dann halt der Grund, als ich dann gesagt habe,
okay, ich mache mich selbstständig, dass ich halt gesagt habe,
ich möchte einer von den Maintainern werden und mal schauen,
ob man irgendwie so in die Richtung auch was direkt in Fluid reinbauen kann,
anstatt das dazu obendrauf irgendwie zu bauen.
Genau, und ein Teil davon ist eben auch, dass man in Typo 3 eben auch andere
Template Engines einsetzen kann.
Das gehört auch so ein bisschen dazu. Ja, und Florian, du benutzt wahrscheinlich
dieses Komponentensystem.
Und hast du den Simon dann kennengelernt wahrscheinlich?
Genau, das war tatsächlich, ich hatte schon darüber gelesen, dass es das gibt.
Das war bei den Projekten von der Agentur nicht im Einsatz bisher oder damals.
Und dann vor zwei Jahren, eineinhalb Jahren auf der Entwicklerkonferenz steht
eben der Simon auf der Bühne und stellte nochmal das vor, eben seine Extension,
eine dieser wahrscheinlich hunderten oder tausenden Extensions.
Und er hat eben diese Fluid Components Extension vorgestellt.
Und ich war also sofort, ich kannte vorher Vue und andere komponentenbasierte
einfach Herangehensweise.
Es ist doch ganz anders, wenn man das so in einem... Und in deiner Agentur war
es vorher so, sodass dann ganze Seiten als Vorlage dann zusammengeschraubt wurden am Stück.
Genau, da war das eben sehr schön getrennt, aber es war eben nicht getrennt
nach Komponenten, sondern es war getrennt nach Sprachen.
Also da war der Ordner mit den HTML-Dateien und da war der Ordner mit den CSS-
oder SCSS-Dateien und dann der JavaScript-Ordner und es war so aufgetrennt.
Und eigentlich, ich glaube, mittlerweile sind sich ja alle einig,
dass diese Aufteilung eigentlich keinen Sinn macht.
Also es macht ja Sinn, eine Aufteilung zu machen in kleine Stücke, aber eben nicht nach.
Komponenten und das gab's bis dahin eben im Typo 3 nicht, sondern man konnte
schon auch aufteilen, also hat dann eben, das hat ja Simon vorher erwähnt,
es gibt dann Layout-Dateien und,
die kann man dann wieder in kleinere Partial-Dateien auf aufteilen,
wenn man da irgendwie wiederkehrende Sachen hat.
Aber mit den Komponenten macht es einfach noch mal viel klarer in der Struktur.
Die sind wahrscheinlich auch intelligenter als die Partials.
Also ich stelle mir unter Partials jetzt vor, dass man im Grunde genommen wirklich
eine Template einfach nur an der Stelle einsetzt.
Und die kapselt keine eigenen Daten, sondern die nutzt dann die Daten,
die dann in dieser View drin sind.
Und bei den Komponenten, also so empfinde ich das, da kannst du dann so eine
Art Prop-Drilling machen.
Also du reichst bestimmte Daten rein, die dann in dieser Komponente vielleicht
auch unter ganz anderen Keys dann liegen.
Und genau so kannst du die halt überall einsetzen, weil die in sich ein geschlossenes
Ding ist und die einfach bestimmte Schnittstellen nach außen hat.
Genau, also ich glaube, die Schnittstelle zusammen mit dem,
was Florian gesagt hat, mit der Co-Location, wenn man es so nennen will,
also das halt HTML, CSS, JavaScript, JavaScript vielleicht noch irgendwie eine
Doku zu der Komponente in einem Ordner legt.
Die API ist halt das, was es eigentlich so mächtig macht, weil die Partials,
die es da gibt, die haben, also da weiß man nicht von außen,
was brauchen die denn, um sich darstellen zu können.
Im Zweifelsfall ist dann halt eine Variable leer und dann ist er halt leer.
Und bei den Komponenten kann man eben sagen, diese Komponente braucht einen
Parameter Title und der soll bitte vom Typ String sein.
Und wenn da kein String reinkommt oder wenn der Parameter fehlt,
dann gibt es halt einen Fehler.
Und das ist das, was sie halt dann wirklich wiederverwendbar macht.
Genauso wie in der Frontend-Welt, also das ist wirklich eins zu eins aus der
Frontend-Welt übernommen, so dieses Paradigma, aber halt in die Typo-3-Welt
überführt, in dieses, in die Fluid-Denke und in das Server-Side-Rendering, ja, genau.
Genau, und dann war halt die andere Idee zu sagen, okay, dann,
wenn wir da schon einen Ordner haben mit einer HTML-Datei drin,
dann legen wir die anderen Sachen auch noch daneben und dann muss man sich halt
ein Frontend-Building-Bundling,
zusammenbauen, was halt dann die Dateien zusammensammelt und daraus irgendwie
ein großes Bundle macht oder wie auch immer man es denn gern haben will.
Das war dann so der Ansatz. Das gab es ja wahrscheinlich vorher auch schon,
wenn man dann da die CSS-Ordner hatte und JavaScript-Ordner,
wo dann da alles reingewandert ist.
Wobei das wahrscheinlich meistens eher so statisch dann definiert war.
Also es gibt dann irgendwie eine
Main-SCSS und die inkludiert halt dann Variables, SCSS und was auch immer.
Wohingegen bei den Komponenten, zumindest wir das bei uns dann so gemacht haben,
dass es halt sehr dynamisch ist.
Das heißt, man legt einfach einen Ordner an mit einer HTML, einer SCSS oder
was auch immer Datei und der Bildprozess sammelt die automatisch zusammen,
ohne jetzt, dass man jedes Mal wieder die Main-SCSS anpassen muss. Ja, macht Sinn.
Und geht das dann auch so weit, dass man so was wie eine Component-Library sich
auch anzeigen lassen kann, wo man dann vielleicht eine Übersicht hat über die
Komponenten, so wie man das von Storybook kennt,
vielleicht auch mit verschiedenen Ausprägungen der Komponente und der Doku.
Genau, das war dann irgendwie der nächste logische Ansatz, zu sagen,
okay, wir bauen da noch so ein, wir nennen das dann Fluid Style Guide und da
läuft der eben über alle Komponenten drüber.
Wir haben dann so eine JSON-Datei daneben gelegt mit den Demodaten,
siehst dann irgendwie Fixtures,
JSON und da konnte man dann sagen, es gibt eine Default-Ausprägung und eine
Small- und eine Big-Ausprägung und dann hat man da eben seine Demodaten reingetan
und dann hat der Style Guide die alle aufgelistet.
Und auch mit Detailseite, wo man dann auch zum Beispiel den Titel einfach manuell ändern konnte.
Dann hat er refreshed und dann konnte man sehen, wie sich das direkt auswirkt.
Genau, das war so die nächste logische Folgerung daraus und ist halt ein total
mächtiges Tool auch so zur Entwicklung.
Also speziell, wenn man jetzt mit einem Projekt neu anfängt,
dann halt so ein Frontend-Workshop zu haben,
wie das Brad Frost nennt, wo man halt die Komponenten bauen kann,
bevor das Typo3-Backend komplett fertig ist.
Das war halt in den Projekten damals bei uns immer so das Problem,
dass halt die Frontendler lang rumsaßen, bis sie dann mal anfangen konnten.
Und mit diesem neuen Ansatz konnte man halt quasi von Tag 1 anfangen.
Und wenn das Backend fertig war, dann war das Frontend schon lang fertig.
Und dann musste man es nur noch zusammen kombinieren, integrieren und dann war
die Seite insgesamt fertig. Und man hat ja halt auch eine Stelle,
wo die Komponente definiert ist und nicht fünf Stellen.
Und wenn man was ändern will, muss man an fünf Stellen wieder das HTML anpassen. Ja, macht total Sinn.
Ich finde auch dieses Umgedreht, das ganze Aufzäumen total gut,
weil am Ende ist es ja so, dass so die Daten, die eine Komponente braucht,
ergeben sich so ein bisschen daraus, wie sie funktioniert.
Und manchmal ist das auch den Entscheidern oder Konzeptern nicht so hundertprozentig
klar und man baut dann Dinge und dann merkt man später, dass man aber ja noch
ein paar mehr Daten doch braucht hier und da.
Und so kann man erstmal diese Komponente fertig entwickeln, dass sie so funktioniert,
wie man sie haben will. Und dann weiß man eben, okay, so jetzt wissen wir,
wie wir das haben wollen.
Das heißt, wir brauchen diese Daten und kann das dann so diesen Wunsch dann
ans Backend weiterreichen.
Und die müssen dann auch nicht irgendwie im gleichen Zuge die ganze Zeit anpassen,
während man die Komponente noch fein justiert und umbaut.
Und das, was ihr gerade beschrieben habt, das war dann Teil deiner Extension,
die du damals gebaut hattest.
Und du bist jetzt gerade dran, das in den Core rein zu portieren?
Genau, also aus dieser Zeit in der Agentur sind eben zwei Extensions entstanden.
Einmal, das heißt Fluid Components, das entweitert quasi Fluid um diese Komponenten-Funktionalität.
Und dann gibt es noch den Fluid Style Guide, den man eben verwenden kann oder
eben auch nicht. Die funktionieren unabhängig voneinander.
Die beiden sind dann entstanden. Und als ich dann aus der Firma weggegangen
bin, habe ich mich halt entschieden, in das Core-Team von Fluid zu wechseln.
Und jetzt sind wir erstmal so am überlegen, wie man das denn da sauber reinkriegt,
weil die Variante, die ich gebaut habe, die funktioniert super, auch auf großen Seiten,
kleine bis große Seiten haben wir das alles eingesetzt, aber ist jetzt nicht
die sauberste Implementierung, das heißt, wenn man das richtig schön und zukunftsfähig
in Fluid reinkriegen will,
dann muss man erstmal noch ein bisschen unten drunter aufräumen und da sind
wir gerade so ein bisschen dabei,
Sachen hin und her zu schieben, auch zum Beispiel diese Trennung zwischen Typo
3 und Fluid als Template-Sprache noch ein bisschen glatter zu ziehen.
Auch zum Beispiel dieses, dass man andere Template-Sprachen verwenden kann.
Das ist gerade noch so ein bisschen im Fokus.
Aber perspektivisch würde ich sehr gerne dann natürlich dieses Komponententhema
noch mal aufgreifen und so richtig schön sauber in Fluid reinbringen.
Ja, macht Sinn. Ich glaube, das ist dann auch so ein bisschen so ein Alleinstellungsmerkmal.
Also ich habe neulich mal so ein bisschen recherchiert und bei Twig ist es bis
jetzt zum Beispiel halt auch nicht drin.
Da gibt es auch nur so eine Extension. Ich glaube, bei Blade haben sie da sowas
in der Art, aber da ist man dann schon wieder in der PHP-Welt.
Das heißt, man schreibt seine Komponenten häufig dann doch wieder in PHP,
was ich halt nicht so schön finde, wenn man als Frontendler da irgendwas für
Typo 3 oder für was auch immer bauen soll, dann plötzlich ins PHP reingeworfen zu werden.
Das war halt das Schöne an der Fluid-Lösung, dass die wirklich nur mit XML funktioniert.
Man muss natürlich dann ein bisschen über Datentypen Bescheid wissen,
aber das kriegt man dann immer noch hin.
Aber letztendlich war es dann nur HTML und Fluid. Und eben kein PAP.
Und Florian, du hast das dann in eure Agentur reingetragen und was haben deine
Kolleginnen dazu gesagt?
Also es ging nicht über Nacht. Ich war praktisch sofort verkauft an die Idee.
Ich war wirklich so Feuer und Flamme. Und es hat dann tatsächlich eigentlich,
man kann sagen, ein Jahr gedauert von diesem Vortrag von Simon in Karlsruhe,
bis dann wir tatsächlich,
bis ich alles soweit überzeugt hatte, dass wir diesen Weg gehen,
bis irgendwie so und so viele Prototypen gemacht wurden.
Irgendwann hat mir jemand erklärt, wie ich Typo3 selber installieren kann und
das war für mich so ein totales Aha-Erlebnis.
Okay, jetzt kann ich selber das installieren.
Es dauert ein bisschen länger, man braucht ein bisschen mehr Sachen wie bei WordPress.
Also ganz in fünf Minuten schafft man es nicht, aber wenn man es dann zweimal
gemacht hat, dann hat man in 10 Minuten ein neues Typo3-Projekt installiert
und ich habe dann ganz viele Prototypen gemacht eben mit den Components und.
Auch mit Web-Components und also in unterschiedlichste Richtungen mit Tailwind
und so weiter und einfach so verschiedene Sachen ausgetestet und das war irgendwie sehr so gut,
das dann selber machen zu können und das hat dann tatsächlich am Schluss da
in der Agentur eigentlich dann doch alle überzeugt, dass der Components-Ansatz der richtige ist.
Und über was wir jetzt gar nicht gesprochen haben, das sind eigentlich die Side-Packages.
Also es ist ja Composer, PHP-Composer basiert, Typo3.
Also quasi der Package-Manager von PHP?
Genau. Und man installiert eben dann erstmal den Typo3-Core und der bringt seine
eigenen Dependencies mit.
Und dann für das eigentliche Projekt oder für den eigenen Code macht man ein eigenes Package.
Und jetzt habe ich gerade vergessen, wieso ich das erzähle eigentlich. Die Side-Packages.
Ist, was nie öffentlich ist, das sind die Site-Packages, also die ganzen Projekte,
wie die gebaut sind, das ist eigentlich alles hinter verschlossenen Türen.
Also man kann eigentlich nie schauen, ja, wie machen es eigentlich die anderen?
Okay, das heißt also, wenn man mit Hypo3 eine Webseite baut,
jetzt als Agentur oder sowas, dann sind die,
spezifischen Anpassungen, die man, oder die Ausgestaltung, die genaue für den
jeweiligen Kunden, das alles verpackt man in so ein Site-Package,
was was wiederum letztlich ...
Per Composer reingehängt wird. Und so kann man wahrscheinlich dann den TYPO3-Core
auswechseln und dann wieder das Side-Package reinhängen.
Und idealerweise funktioniert das dann mit der neuen Version auch.
Also man hat aber auf jeden Fall das sozusagen separat verpackt.
Ja, also üblicherweise ist es, zumindest bei uns war es so, dass das Side-Package
wirklich zu dem Projekt-Repro dazugehört.
Das heißt, es gibt ein, ich würde vielleicht sagen, so ein Multi-Repo oder sowas, wo dann mehrere,
also eins oder mehrere Pakete, also erstmal der Typo3-Core mit der ganzen Konfiguration
von dem Grundsystem und dann gibt es einen Ordner, der heißt zum Beispiel Packages
und darin liegen dann Unterordner und zum Beispiel eben das Side-Package.
Aber auch wenn jetzt für diesen einen Kunden ein Feature gebaut wurde,
was bei keinem anderen Kunden eingesetzt wird, dann liegt da eben noch ein zweites
Package, das heißt Products oder sowas. Und da sind dann eben die Produktsachen drin.
Und in dem Side-Package findet halt alle Individualisierung vom TYPO3 Core statt
für diesen Kunden. Das heißt, die sind auch sehr individuell und im Prinzip
ist eigentlich bei jedem Projekt ein anderes.
Bei kleineren Projekten sind die wahrscheinlich ähnlicher,
bei größeren Projekten eher sehr unterschiedlich und deswegen gibt es da halt
auch nicht irgendwie eine Sammlung von allen möglichen Side-Packages,
auch wenn es sehr interessant ist, natürlich da einfach reinzuschauen.
Gibt es ab und zu mal so Vorträge, wir zeigen unser Side-Package,
es gibt auch so ein Tutorial, wie man sich so ein Side-Package zusammenbauen
kann, aber das ist halt nur so der Kickstarter so ein bisschen und dann ist
man irgendwie auf sich allein gestellt und muss halt dann.
Aus Erfahrung, aus anderen Projekten schauen, was brauche ich denn jetzt,
was sind denn die Anforderungen, wie kopiere ich mir das zusammen und wenn man
da so als Nicht-PAP-Entwickler reingeworfen wird, ist das natürlich schon ein
bisschen hart und als Nicht-Typo3-Entwickler, weil da irgendwie YAML-Dateien drin liegen,
Typoscript-Dateien, eine eigene Konfigurationssprache, die es nur im Typo3-Umfeld
gibt und dann halt HTML, CSS,
JavaScript, alles liegt da irgendwie mit drin.
Das heißt, man hat da so eine wilde Mischung aus Konfiguration und PHP-Klassen auch.
Also wenn man jetzt irgendwie ein Event im Core verwendet, um da noch spezielle
Dinge zu tun, dann liegt das da auch üblicherweise drin.
Also es ist eine wilde Mischung. Und insofern kann das je nach Größe des Side-Packages
auch ein bisschen abschreckend sein.
Genau. Und die Agentur macht natürlich nicht bei jedem Projekt immer wieder
alles von vorne und installiert TYPO3 wieder neu und fängt wieder von Null an,
sondern hat natürlich üblicherweise, ich denke mal, Simon,
du kannst es vielleicht bestätigen, hat ein Grundpackage, auf dem sie immer wieder aufbauen.
Und was wir eben jetzt im letzten Jahr dann gemacht haben,
eben so ein für die Agentur ein neues Basispaket sozusagen aufzubauen und das
baut eben schon auf den Fluid Components auf und das ist ein sehr schönes,
klares Projekt jetzt geworden.
Also da das dann wirklich gut funktioniert, dass man die einzelnen Content-Elemente,
also die einzelnen Blöcke sozusagen,
die die Redakteure platzieren können, dass die jeweils eine eigene Komponente
sind, die dann vielleicht wiederum aus anderen Subkomponenten zusammengesetzt ist.
Und so ist es sehr schön modular und auch hat auch so eine Art Dokumentationsfunktion,
weil ja jede Komponente ihre Parameter, die übergeben werden sollen.
Irgendwie auch definiert und benennt und typisiert und,
Beispieldaten mitliefert in diesen Fixture-Files, die dann im Style Guide auftauchen.
Und so, ja, also es hat sich für mich sehr gut, ich bin immer noch total begeistert
von der Arbeit von Simon, von diesen beiden, von dem Style Guide und von Fluid Components.
Also das hat die, also für mich Frontend-mäßig die Arbeit im Typo 3 also 100% verbessert.
Was ich dann ganz spannend fand, waren eben diese Demos, die du aufgesetzt hast.
Also da gab es ja irgendwie mehrere, die sind dann auch immer auf GitHub gelandet
und irgendwie über Social Media so ein bisschen verteilt worden.
Und dann haben dann halt so die Frontend-Technologien, in denen ich nur so oberflächlich
drin stecke, einfach mal da mit reingeworfen und mal geschaut,
wie weit kommt man denn damit.
Und dann hast du auch im Zweifelsfall irgendwie jemanden angesprochen,
Und wenn du irgendwie Hilfe brauchtest oder irgendwo in dem Typo-3-Sumpf so
als Außenstehender nicht weitergekommen bist,
genau, und so sind wir ja dann nachher auch bei diesem Vite-Thema gelandet,
das da mit reinzubringen.
Aber das war halt ein total anderer Ansatz, als ich zum Beispiel verfolgen würde.
Ich würde halt dann sagen, ja, ich baue meine Extension perfekt auf Typo 3 angepasst und so,
wohingegen du aus der Frontend-Sicht gesagt hast, ich schaue mal,
wie weit ich mit den Frontend-Technologien im Typo 3-Bereich komme,
die da vielleicht nicht so häufig eingesetzt werden.
Oder wenn sie eingesetzt werden, dann von Agenturen, die halt ihr eigenes Site-Package
haben, was aber nicht öffentlich ist.
Das war ganz spannend auf jeden Fall.
Das bedeutet, genau, du hast versucht, Florian, du hast versucht,
dich bei deinen Experimenten, sagen wir mal, so unabhängig wie möglich von Typo 3 zu machen.
Und Simon, du würdest eher direkt auf Typo 3 Schützenhilfe zurückgreifen und
ihr habt euch dann sozusagen in der Mitte getroffen. Was habt ihr mit Vite gemacht?
Also nutzt ihr das dann als Bundler, der dann diese ganzen Dateien,
die wir eben thematisiert hatten, aus den verschiedenen Foldern zusammensucht
und konkateniert und minifiziert?
Oder wie nutzt ihr das? Oder für Hot, weiß ich nicht, Hot Fluid Template Reloading oder so? so?
Ja, genau. Also irgendwie muss man ja die Frontend, die Frontend-Dateien umgehen,
also mit dem SCSS, das SCSS kompilieren und JavaScript bundeln, minifizieren.
Ich hatte dann auch ein Projekt mal vor zwei Jahren,
das hatte dann doch ziemlich viel Interaktivität im Frontend und da war man
dann irgendwann mit dem, es war dann irgendwie klar, der, also nur mit JavaScript,
das wird zu kompliziert, also man braucht ein bisschen mehr und ich habe dann,
ein View, da eine kleine View-App eingebaut in die Typo3-Seite,
in eine Seite, die hat eben jetzt,
als kleine Insel eine View-App drin und dann aber wie wird das View,
wie wird aus den Singlify-Components von View,
wie werden die prozessiert und,
Was ist halt in den bisherigen Agenturprojekten eben, ich habe dann auch geschaut,
was gibt es, und es gab halt ganz viele Pipelines mit Galp.
Und es gab Sachen mit Webpack, die aber irgendwie sehr kompliziert waren zu konfigurieren.
Ich kannte vorher eben von den eigenen Vue-Sachen schon Vite,
und es war aber nicht so ganz irgendwie klar, klar, wie kann man das,
wie passt das zu diesem serverseitigen Rendern von Typo 3 dazu.
Es gibt dann tatsächlich in der VIT-Dokumentation eine Anleitung,
wie man das in ein Backend integriert.
Und da gab es aber damals vor eineinhalb Jahren sowas ungefähr,
gab es eben kein Beispiel für Typo 3.
Und ich dachte, das ist doch für die Entwicklerkonferenz das ideale Thema.
Ich sage das irgendjemandem, ich gehe da hin und sage das, ja komm,
das bauen wir ein und dann schreien die alle Juhu und eine halbe Stunde später ist es fertig.
Das hat nicht ganz so geklappt, also es hat viel länger gedauert und keiner
hat mir auch richtig irgendwie,
hat sich mit mir eine halbe Stunde hingesetzt und immer nur so eine kleine Stelle
gezeigt und so, ja okay, also hier, da musst du einfach diese PHP-Sache schreiben
und dann geht es da weiter und dann so Stück für Stück.
Und auf der Zugfahrt nach Hause war es dann tatsächlich gelaufen,
also sowohl das Bundeln für so ein Production-Bild als auch der Development-Server von Vite.
Dass der mit Typo 3 zusammenarbeitet und eben von Vue bis React alles behandeln kann,
das TypeScript und auch den Browser neu lädt oder sogar nur einzelne Module,
wenn die bearbeitet werden.
Und das ist dann jetzt auch in dieses Paket reingewandert?
Also nicht in dieses, also es hat dann erst mal überhaupt niemand interessiert.
Ich dachte ja, ich habe jetzt wirklich den Joker gezogen und jetzt sind da alle
begeistert, überhaupt niemand interessiert.
Und ich habe dann aber, jetzt kommen wir vielleicht auf dieses Community-Thema nochmal zurück.
Also es gibt eben in München auch ein Typ 3 Meetup einmal im Monat und ist auch
gerade zufällig heute Abend.
Und da habe ich vorgeschlagen, ob ich das Thema VIT und TYPO3 mal vorstellen
soll und habe das dann gemacht und daraufhin haben sich dann mehrere Leute doch
dafür interessiert, die fanden das dann ganz interessant und,
dann Simon, kannst du weiter erzählen, wie du den Faden aufgenommen hast?
Ja, ich weiß nicht, ich bin irgendwie dann durch Zufall über diese Demo gestolpert.
Also du warst gar nicht in der Nee, ich war nicht in München.
Ich glaube, es hatte damit zu tun, dass man wird selbstständig und muss plötzlich
seine eigene Website bauen.
Und dann habe ich gedacht, okay, ich habe jetzt die ganzen, das Side-Package
unserer Agentur habe ich jetzt nicht mehr, weil ich bin ja jetzt nicht mehr bei der Agentur.
Und habe dann nochmal einfach von vorne angefangen und mal geschaut,
wie würde ich es denn klein, schlank irgendwie machen und habe mich dann in
irgendwelchen Frontend-Systemen.
Konfigurationswahnsinn begeben als eher Backend-Entwickler. Webpack hatte ich
relativ schnell aussortiert, weil es einfach zu komplex wurde. So.
Und bin dann irgendwie bei Vite gelandet und dann habe ich gedacht,
ah, da ist doch mal irgendwann was bei Mastodon durch meine Timeline durchgerutscht
und habe mir das dann angeschaut und dann sind wir irgendwie in Kontakt gekommen und haben dann das,
was da prototypisch war in dem Projekt, habe ich dann in eine Typo3-Extension
überführt und dann auch relativ schnell eigentlich released.
Florian hat die auch noch getestet und so. Und da haben wir so ein bisschen
Feedback-Loops untereinander gemacht.
Ja, und seitdem haben wir die immer weiter wie entwickelt.
Oder ich hab die immer weiterentwickelt. Immer noch so Kleinigkeiten dazugebaut.
Da gibt's dann immer irgendwelche Ecken, wo es halt noch nicht funktioniert.
Also gerade zum Beispiel kann man das Ganze noch nicht im TYPO3-Backend verwenden.
Also wenn man jetzt ein Modul für die Redakteure baut, dann geht das halt einfach noch nicht.
Aber für den ganzen Frontend-Bereich ich bis hin zum Fluid-Style-Guide haben
wir jetzt eigentlich überall Möglichkeiten, wo man das verwenden kann,
inklusive diesem ganzen Hot-Module Replace, Hot-Module Replacement heißt es, glaube ich.
Das funktioniert alles. Was ich jetzt bewusst nicht eingebaut habe,
ist, dass der den Browser reloadet, wenn ein Fluid-Template sich ändert,
weil man halt ganz schwer feststellen kann.
Ist denn dieses Fluid-Template gerade auf der Seite, die da angezeigt wird,
oder lädt der mir gerade einfach alle fünf Seiten neu, die ich halt gerade zufällig offen habe.
Das heißt, so ganz tief ist die Integration nicht, aber für die ganzen Frontend-Assets
funktioniert es mittlerweile ganz gut.
Was ich erstaunlich fand, bei dieser Umfrage, habe ich dann natürlich auch ein
bisschen eigennützig gefragt, was verwendet ihr denn für Build-Tools?
Und da war Vite zumindest nach ja gut, NPM war auf Platz 1 logischerweise.
Ich habe einfach mal so wilde Mischungen gefragt, Webpack auf Platz 2,
Galp auf Platz 3 und auf Platz 4 schon Beat.
Also insofern ist es schon was, was so ein bisschen Fahrt aufgenommen hat.
Ich glaube, wahrscheinlich aufgrund von der initialen Demo und der Präsentation
in München und dann vielleicht auch auf Basis der Extension.
Ja, könnte ganz cool werden, wenn sich das so weiterentwickelt.
Ja, cool. Hört sich gut an.
Wenn ich hier durch unsere durch unsere Stichworte noch durchgehe,
dann sehe ich auf jeden Fall noch eine Sache, die ich spannend finde,
wo ich noch mal fragen muss, was das ist.
Und zwar, es gibt so was wie Hotwire für Type of Three.
Das hat dann im Grunde wahrscheinlich nichts mit euren spezifischen Projekten zu tun.
Aber ich mag dieses Konzept sehr.
Florian, du hast wahrscheinlich damit rumgespielt schon, oder?
Also ich hatte es immer auf der Liste und habe es aber noch nicht ausprobiert.
Aber mir leuchtet das Konzept auch total ein.
Ja, möchtest du nochmal kurz erklären, was da passiert?
Genau, also da lagert nun praktisch die Interaktivität, die im Browser passiert, an den Server aus.
Also man klickt irgendwo drauf und anstatt, dass JavaScript ausgeführt wird
und die ganze Logik findet im Browser statt,
stattdessen wird ein Request an den Server geschickt und es wird dort bearbeitet,
zum Beispiel ein Inputfeld validiert, ob die Daten richtig eingegeben wird,
nachdem was erwartet wird.
Und dann kommt die Antwort wieder zurück vom Server und es kommt aber nicht
eine ganze Seite zurück, sondern nur ein kleines Parschel, nur ein kleines HTML-Fragment,
das dann wiederum ein Teil auf der Seite ersetzt.
Also ein bisschen JavaScript ist dabei, das diese abschicken und das wieder ersetzen macht,
und ich habe, weil ich es noch nicht ausprobiert habe, habe ich auch da ein
bisschen so ein Fragezeichen mit der Barrierefreiheit, weil was passiert,
wenn im Browser plötzlich irgendwie Sachen ausgetauscht werden?
Also kriegt das der Screenreader mit zum Beispiel? Solche Fragen.
Aber das ist die grundsätzliche Idee, denke ich, von dem Hotwire Turbo.
Also es gibt verschiedene, das hat so verschiedene Teile. Eins ist auch, dass die,
wenn man auf den Link klickt, dann die nächste Seite geladen wird,
aber nur per JavaScript und der ganze Header sozusagen,
man bleibt auf der gleichen Seite, nur der innere sozusagen,
der Datei wird ausgetauscht.
Man macht eigentlich keine richtige Navigation, sondern, und das hat so einen
Geschwindigkeitsvorteil einfach, weil man zum Beispiel das CSS nicht nochmal
rennen muss oder solche Sachen.
Okay, aber dann spielt denn sowas wie Topwire vielleicht auch mit diesem Komponentensystem zusammen,
dass man quasi dann dank dieses Komponentensystems auch nur solche Anfragen
an den Server macht, die dann nur eine Komponente zurück rendern?
Wahrscheinlich, oder? Ja.
Das ist auf jeden Fall potenziell möglich. Also man muss dazu sagen,
das ist auch wieder eine Typo-3-Extension.
Die ist, glaube ich, im Moment noch im Beta-Status. Aber es gab jetzt schon
mehrere Vorträge dazu von dem Entwickler. Der heißt Helmut Humme.
Und der entwickelt das jetzt gerade weiter. Der hat, glaube ich,
gerade jetzt heute einen Vortrag dazu.
Beim Typo-3-Meetup in München. Beziehungsweise Remote.
Und ja, der macht im Prinzip etwas Ähnliches, wie ich mit Vite gemacht habe,
nämlich halt die Frontend-Technologie verbinden mit dem Backend von Typo3.
Das heißt, dass das Typo3 in die Lage versetzt wird, einzelne Content-Elemente,
einzelne Templates oder was auch immer für sich auszuliefern,
ohne alles außenrum mit auszugeben, um eben dann die Stärken von dem Ansatz zu nutzen.
Und da gab es auch relativ eindrückliche Demos, also zum Beispiel,
dass man so ein News-Plugin hat mit irgendwie einer Blätterfunktion und die
Blätterfunktion halt einfach so durchklicken kann, ohne dass man ständig ein
Page-Reload zwischendrin hat.
Das funktioniert ziemlich cool und da gibt es auch schon so eine Demo-Seite
dafür und ich würde mal vermuten, dass er jetzt so ein bisschen auf der Zielgerade
ist, das wirklich zu releasen und ich glaube, dann gibt es echt viel Potenzial und ich Ich glaube,
das war auch der Vortrag, der auf der TYPO3-Konferenz prämiert wurde,
also auf der Entwicklerkonferenz, als der beste Vortrag in dem Jahr.
Insofern, ich glaube, das hat auch Potenzial, da im Frontend noch mal einiges
durchzuwirbeln und halt so ein bisschen eine Alternative zu dem Headless-Ansatz
zu sein, der ja quasi dann das ganze Bisherige wegwirft.
Wohingegen der Ansatz sich ganz gut kombinieren lässt mit anderen Ansätzen und
halt trotzdem die Stärken von dem Server-Side-Rendering irgendwie nutzt,
die ist da einfach schon seit Jahrzehnten, die wir ja alle immer gemacht haben, bis vor ein paar Jahren,
wo dann plötzlich das mit den Single-Page-Applications aufkam.
Ja, genau. Gestern haben wir auch kurz darüber gesprochen, dass das ja auch
so ein Zyklus ist und man dann irgendwann im Grunde genommen wieder da landet,
wo man vor zehn Jahren war,
mit natürlich so, also nicht identisch, aber aber so von den Konzepten her.
Was aber wahrscheinlich immer daran liegt, dass man immer sieht,
was sind so die Probleme, wie kann ich die lösen? Ah, cool, hab ich gelöst.
Oh, jetzt hab ich wieder ein neues Problem.
Und so bewegt man sich dann durch diesen Raum, um dann ...
Am Ende wieder beim gleichen Konzept wie vor zehn Jahren anzukommen.
Ja, und so Hypes helfen dann halt auch nicht so richtig.
Wenn man da so einen Hype drin hat mit, wir machen jetzt alles nur noch damit,
ist halt meistens nicht die richtige Lösung, sondern muss sich halt das Problem anschauen.
Ja, und ich würde, mein Bauchgefühl wäre, wenn man Typo3 als Content-Management-System
nimmt, dann gibt es bestimmt Ansätze, wo Headless Sinn macht.
Aber ich würde behaupten, das System kann schon seine Vorteile am meisten ausspielen,
wenn es halt doch selber auch einen Großteil der Seite selber rendert und dann
vielleicht nur einzelne Teile darin interaktiv sind.
Weil es halt keine, meistens halt doch keine Web-Applications sind,
sondern Content-getriebene Webseiten, wo der Redakteur ganz viel selber gestaltet
in Form von Layout und ja. Ja.
Und jetzt haben wir ganz viel über diese ganzen Sachen gesprochen.
Wochen. Was wäre denn, wenn ein Frontend-Mensch, das ist ja sozusagen die Mehrheit, die uns hört,
wenn die Interesse daran hätte, so mal Komponenten zu bauen für Typo 3,
könnte man dann zum Beispiel deinen Fluid Style Guide stand-alone installieren
und dann darin anfangen zu entwickeln?
Also wie könnte man da gut starten oder braucht man dann dann tatsächlich ein
komplettes Typo 3, um das eben machen zu können, um entwickeln zu können,
um Frontend entwickeln zu können.
Ja, also im Moment ist es von der Architektur leider so, dass es doch sehr auf Typo 3 basiert.
Mein Wunsch wäre eigentlich ursprünglich gewesen, dieses Komponententhema an
Fluid dran zu binden, was auch ein eigenständiges Paket ist.
Das ist leider nur aufgrund von irgendwelchen Implementierungsdetails war das
nicht möglich und dann habe ich es halt an Typo 3 rangebunden und damit auch den Style Guide.
Und ich, ja, also es würde glaube ich schon ein bisschen komplexer machen,
weil so nutze ich halt das ganze Routing und so weiter, alles von Typo 3 mit,
um diesen Style Guide darzustellen.
Das heißt, es gibt im Moment tatsächlich keine Standalone-Version,
sondern man muss sich halt ein nacktes Typo 3 installieren, muss aber glaube
ich kein einziges Mal im TYPO3-Backend gewesen sein, um den Style Guide dann
direkt verwenden zu können.
Da könnte man natürlich auch nochmal so einen Kickstarter sich bauen,
also quasi ein leeres Typo 3 mit installiertem Style Guide und Komponenten,
um da schneller loslegen zu können, vielleicht irgendwie als Docker-Image oder
was auch immer. Das wäre auf jeden Fall eine Idee.
Genau, ja, ich denke mal, also ich denke mal, Hörerinnen und Hörer,
die damit starten wollen, die werden ja wahrscheinlich in einer Agentur sein
oder mit Leuten zusammenarbeiten, die Typo 3 verwenden.
Andernfalls, warum sollten sie das jetzt mit Fluid machen?
Weil Fluid kann man ja jetzt auch nicht, kann man ja wahrscheinlich nicht,
kann man das sonst mit anderen Zinsen benutzen?
Kann man, aber wenn man ehrlich ist, wird das aktuell nur mit, von Typo 3 verwendet.
Und ein bisschen noch von Neos, aber wirklich nur noch ganz minimal,
also die verwenden das auch nicht wirklich.
Insofern ist es schon ein Typo-3-Ding und die Konsequenz daraus ist halt,
oder war für uns auch immer, diese Fluid Components machen nur für Projekte
sind oder für einen Kunden sind, der in der Typo-3-Welt komplett lebt.
Wenn man jetzt einen Kunden hat, der hat irgendwie fünf Systeme,
jedes einen anderen Stack drunter, dann würde ich halt eher irgendwas verwenden,
was unabhängig von dem Ganzen ist, sowas wie Pattern Lab oder so.
Und dann halt diese Integration wohl oder übel machen in die Einzelsysteme,
aber nicht von vornherein sagen, ja, TYPO3 ist unsere Wahrheit und ihr müsst
euch alle mit TYPO3 auseinandersetzen. Das macht keinen Sinn.
Das macht, glaube ich, nur Sinn für reine TYPO3-Projekte, aber es macht,
glaube ich, schon eigentlich für jedes TYPO3-Projekt Sinn, egal,
wenn es jetzt auch kleiner ist.
Weil diese komponentenbasierte Arbeitsweise, wenn man die einmal hat,
hat, dann will man es halt eigentlich nicht ohne haben.
Ja, genau. Und eigentlich ist
es ja auch nicht mehr Arbeit. Ich überlege gerade, was dagegen spricht.
Also wenn man vielleicht irgendwie Projekte baut, die nicht über lange Zeit
gepflegt werden müssen, ob das dann irgendwie ob man dann.
So, sagen wir mal, dirty arbeitet und komplette, also ganze Views baut,
ob man da einen Vorteil von hat.
Aber ich wüsste jetzt auch nicht so genau, was für einen Vorteil man davon hätte. Also, ja.
Ich glaube, der einzige Nachteil ist halt so ein bisschen, dass es nicht Teil
vom Core ist und man deswegen sich halt, wie bei jeder von diesen Extensions
oder auch bei WordPress-Plugins oder was auch immer, sich halt von mehreren
Stellen abhängig macht.
Und wenn die halt nicht auf die neue Version das anpassen, dann ist halt blöd.
Das ist halt so ein Punkt. Und dadurch setzen sich solche Sachen halt auch nicht
in der kompletten Community von einem Tag auf den anderen durch,
weil sie halt eine Third-Party-Extension sind.
Ja, genau. Da will man sich dann auch nicht noch eine Abhängigkeit mehr ans
Bein binden vielleicht. Ja, genau.
Ja, cool. Und genau, das heißt,
wahrscheinlich findet man, dann hast du eine eigene Seite für deine Projekte,
also die Fluid Components und Fluid Style Guides,
oder würde man das über die Typo3-Seite finden,
indem man die Extensions-Unterseite durchsucht?
Geht beides. Also diese ganzen Sachen liegen halt alle auf GitHub.
Im Prinzip alle Extensions von Typo3 sind mehr oder weniger auf GitHub.
Es gibt ein Typo3-Extension-Repository, wo alle Extensions auch drin sind, wo man drin suchen kann.
Und für die Fluid Components, Fluid Style Guides, haben wir damals so eine kleine
Micro-Site gebaut, die, glaube ich, ein ganz guter Einstieg ist,
wo man so ein bisschen einen High-Level-Überblick kriegt.
Die Zielgruppe war eher so ein bisschen, weiß nicht, Entscheider,
Projektmanager oder so, also nicht so direkt die Technikdröhnung.
Wenn man die Technikdröhnung haben will, dann geht man eher in die Readme auf GitHub.
Okay. Ja, aber es gibt auch die beiden Vorträge, von denen es jemanden oder
den einen über die über den Style Guide und über die Components und den anderen
auch über die Vite-Integration.
Ich denke, die sind, zumindest die Slides davon sind beide auf deiner Website.
Genau, es gibt auch von einzelnen Vorträgen Aufzeichnungen. Wenn halt die Konferenz
aufgezeichnet habt, dann sind die auch auf meiner Seite.
Versuchen wir mal in die Shownotes zu packen. Vielleicht könnt ihr da nochmal
die Links reinpacken. Habt ihr vielleicht sogar schon gemacht.
Da haben wir noch ein paar andere Links auf jeden Fall zu Themen,
die wir heute angesprochen haben.
Grundsätzlich jetzt Meetups sind vielleicht für die eine oder andere Person auch interessant.
Und wir haben die TYPO3-Developer-Konferenz angesprochen. Da werden wir auch
mal einen Link noch reinpacken.
Habt ihr von eurer Seite sonst noch spezielle Links oder Hinweise,
die ihr vielleicht den Hörerinnen und Hörern noch geben wollt, Florian und Simon?
Also jetzt erstmal nicht. Ich glaube, was halt wirklich, was wir vorher schon
gesagt haben, eine Stärke ist halt diese lokale Vernetzung von Typo3.
Das heißt, diese Meetups sind wirklich offen für jeden. Da muss man nicht Typo3-Crack sein,
um dort hinzukommen, sondern da sind von Anfänger bis Profis vertreten,
von Projektmanager über Frontend-Entwickler über alle möglichen Leute. Leute.
Es gibt auch so User-Groups, die eher so ein bisschen auf den losen Austausch,
also ohne Vorträge und so spezialisiert sind.
Also da kann man an allen Ecken und Enden sich irgendwie an die Community andocken.
Auch bei so Codesprints kann man durchaus, wenn man jetzt gerade am Anfang ist
von Typo 3, kann man da durchaus hinkommen und dann wird einem immer geholfen.
Also die Community ist wirklich sehr hilfsbereit.
Insofern einfach mal machen. Ja, und auch online gibt es natürlich die Typo3-Community,
hauptsächlich in einem Slack, in einem eigenen Slack-Projekt.
Aber auch ist es über, in meiner Wahrnehmung, gewandert von Twitter nach Mastodon.
Also kann sein, dass es auf Twitter immer noch weitergeht. Ich habe es nicht mehr verfolgt.
Aber es sind genug rübergewandert auf Mastodon,
dass es da eben einen Austausch, einen lebendigen Austausch gibt und eben auch
Feedback und irgendwie Anstöße und Sachen werden geteilt,
wie jetzt eben zum Beispiel neuerdings die Hotwire-Integration.
Ja, also gerne Anschluss suchen, sich trauen,
auch als Frontend-Entwickler vielleicht auch mal so in die Welt hineinzuschauen,
weil man sich ja eh sowieso, man braucht ja beides. Ja.
Cool.
Alles gut. Genau, wenn es noch Fragen gibt, wir werden in den Show Notes,
werden wir auch genug Hinweise auf euch verstecken, dass man euch auch fragen
kann, wenn die verlinkten Ressourcen nicht reichen.
Und genau, viel Erfolg bei dem Projekt Fluid und dem langsamen Umbau in Richtung,
Komponenten basiert, auch im Core.
Ja, danke. Schauen wir mal. Ja, und vor allem danke an euch.
Genau, Shep, du wolltest sagen, viele Grüße. Genau, nach Hamburg und München.
Vielen Dank. Und ja, an die Hörerinnen, vielen Dank fürs Zuhören.
Und wir hören uns dann nächste Woche wieder.
So machen wir es. Danke euch. Danke. Cool, dass ihr da wart.
Tschüss. Macht's gut. Ciao, ciao. Ciao. Ciao.
Music.
Bis zum nächsten Mal.