Warum TYPO3 in Deutschland und Österreich immer noch dominiert, trotz allem
TYPO3 in 2025: Warum ist es immer noch eine Sache?
Ab und zu kommt ein Projekt mit einem Briefing das verdächtig bürokratisch klingt. Der Klient besteht auf TYPO3, vielleicht weil es bereits in Verwendung ist, oder weil es von ihrer langjährigen Agentur empfohlen wurde. Die meisten Entwickler zucken bei der Idee zusammen. Die meisten modernen Growth Hacker und Marketer heben eine Augenbraue. TYPO3? Immer noch?
Aber es ist immer noch da. Besonders in Österreich und Deutschland powert TYPO3 weiterhin Regierungswebsites, Universitätsportale, öffentliche Informationsplattformen und ja, sogar eCommerce Shops. Und während es ein paar Gründe gibt die Sinn machen, basieren die meisten auf strukturellen Gewohnheiten statt technischem Merit.
Lass uns das aufschlüsseln.
Warum TYPO3 immer noch genutzt wird
1. Nationale Loyalität und Open Source Ideale
TYPO3 ist europäisch. Ursprünglich entwickelt vom dänischen Programmierer Kasper Skårhøj, wurde es primär von deutschsprachigen Contributors genurtured. In Ländern wie Österreich und Deutschland, wo Datenschutz, Souveränität und Skepsis gegenüber amerikanischen Cloud Giants tief laufen, ist TYPO3 ein Symbol von Unabhängigkeit geworden.
Öffentliche Institutionen, Regierungsstellen und traditionelle Corporations bevorzugen oft Software die Open Source, nicht gewinnorientiert und nicht von einem US basierten Cloud Stack abhängig ist. TYPO3 tickt diese Boxen.
Es gibt auch einen kulturellen Faktor. Viele Entscheidungsträger sind mit TYPO3 aufgewachsen. Es fühlt sich vertraut an, sogar vertrauenswürdig. Die Entscheidung geht oft weniger um Agilität oder Time to Market, und mehr um Kontrolle und Konformität.
2. Bürokratische Trägheit und langsame Beschaffung
TYPO3 gedeiht in Umgebungen wo nichts schnell geht.
Denk an Regierungs Procurement Zyklen, akademische Institutionen und Legacy Enterprises. Der Procurement Prozess selbst kann ein Jahr oder länger dauern. Softwareverträge laufen oft über ein Jahrzehnt. Die involvierten Teams haben denselben Stack seit 15 Jahren gesehen. Und niemand will verantwortlich sein für das Switchen von etwas das bereits funktioniert, selbst wenn es suboptimal ist.
Einmal ist TYPO3 drin, bleibt es. Die Switching Kosten sind mehr politisch als technisch.
Das bedeutet TYPO3 Sites können weiter existieren weit über ihr Ablaufdatum hinaus, mit mehr Features layered on wie Klebeband statt eines fundamentalen Rethinks des Stacks.
Das TYPO3 Agentur Ecosystem
Es gibt ein robustes Netzwerk von zertifizierten TYPO3 Agenturen, besonders in Deutschland und Österreich. Diese Agenturen sind tief in TYPO3 investiert. Es ist nicht nur ihre technische Präferenz, es ist ihr Geschäftsmodell.
Für sie bedeutet TYPO3 zu pushen ihre Spezialisierung, ihre Retainer und ihre Marktposition zu verteidigen. Viele ihrer Klienten sind nicht technisch, also wird die Empfehlung der Agentur zur De Facto Entscheidung.
Das erzeugt eine Echo Chamber wo TYPO3 als das Default Enterprise CMS gesehen wird, nicht weil es Alternativen outperformt, sondern weil es immer die sichere Wahl war.
TYPO3 eCommerce: ein schmerzhafter Kompromiss
Während TYPO3 nie für eCommerce designed war, haben verschiedene Extensions versucht diese Lücke zu bridgen. Aimeos, Cart, tt_products, diese Addons enablen Produktkataloge, Shopping Carts und Checkout Flows.
Aber sie sind awkward. Die Dokumentation ist sparse. Die Developer Experience ist frustrierend. Updates sind brittle. Und verglichen mit Plattformen wie Shopify, WooCommerce oder Solidus fühlen sich TYPO3 eCommerce Lösungen stuck in 2009 an.
Trotzdem wählen manche Organisationen TYPO3 für eCommerce einfach um alles unter einem Dach zu konsolidieren. Sie bevorzugen Content, Katalog und Transaktionen in einem einzigen System zu haben, selbst wenn das bedeutet technische Schulden zu akzeptieren.
TYPO3s Stärken liegen in seiner Backend Struktur. Es handlet:
- Multilingualer Content mit voller Granularität: TYPO3 supportet nested Language Trees und Per Element Language Fallback, was es einfacher macht konformen, ordentlich strukturierten multilingualen Content zu publishen, besonders wichtig in Regionen wie der Schweiz oder Belgien.
- Permissions und Workflow Approvals: Feingranulare Backend User Groups und konfigurierbare Content Approval Prozesse erlauben TYPO3 zu managen wer Content auf hoch detailliertem Level erstellen, editieren, approven oder publishen kann. Das macht es geeignet für Institutionen die Audit Trails und Editorial Oversight erfordern.
- Barrierefreiheit Anforderungen: TYPO3 hat lange Templates und Extensions supportet die helfen accessible Websites zu implementieren, inklusive semantischer Strukturierung, ARIA Support und Screen Reader Kompatibilität. Das ist crucial für öffentliche Institutionen die rechtlich verpflichtet sind WCAG oder EN 301 549 Standards zu meeten.
- DSGVO related Data Workflows: TYPO3 kann Consent Logs, Anonymisierungs Triggers und User Data Access Flows via Extensions oder Core Capabilities speichern und strukturieren. Das inkludiert die Fähigkeit Daten auf Request zu redacten oder löschen und Daten lokal unter strikten Data Sovereignty Regeln zu speichern.
- Transparenz Standards erforderlich von öffentlichen Institutionen: TYPO3 macht es einfach strukturierte Publikationsformate zu erstellen wie FOIA Portale, Funding Disclosures und Dokumentarchive mit Kategorisierung, Versionskontrolle und geplanter Veröffentlichung.
Andere Systeme können diese Dinge machen, aber TYPO3 hat sie in lange genutzte Extensions oder sein Core System integriert. Für manche IT Abteilungen macht das es ein simpleres Argument, selbst wenn die Frontend Experience oder Marketing Integration leidet.
Warum Entwickler es hassen
Frag irgendeinen modernen Entwickler der TYPO3 in den letzten fünf Jahren angefasst hat, und du wirst wahrscheinlich ein Seufzen bekommen. Die Probleme sind konsistent:
- TYPO3 nutzt seine eigene Templating Sprache (Fluid), seine eigene Config Sprache (TypoScript) und seine eigene Struktur, alles auf PHP gebolted.
- Du endest oft mit einem Mix aus PHP, Fluid, TypoScript und YAML, mit unklarer Dokumentation und fragiler Kompatibilität.
- Verglichen mit Rails, Laravel oder sogar WordPress fühlt sich TYPO3 langsam, brittle und overengineered an.
- Frontend Integration ist schlecht. Willst du React oder Vue nutzen? Bereite dich auf einen Kampf vor.
- Willst du mit Git und CI/CD Best Practices deployen? Das ist nicht der typische Workflow.
Kurz gesagt: TYPO3 macht einfache Dinge schwer. Und schwere Dinge noch schwerer.
Die fehlende Kultur von TDD und BDD
Eines der auffälligsten Issues mit TYPO3 Projekten ist der Mangel an Test Driven oder Behaviour Driven Development. TYPO3s Ecosystem hat nie wirklich TDD oder BDD Practices embraced, was bedeutet dass automatisierte Tests, Code Confidence und Release Stability oft fehlen.
Das resultiert in brittle Deployments wo Bugs unerwartet reinkriechen, und wo Updates oft gefürchtet statt embraced werden. In Environments wo Reliability essentiell ist, besonders für Commerce oder Integration heavy Plattformen, wird das ein echtes Business Risiko.
Im Kontrast dazu inkludieren moderne Frameworks wie Rails oder Node basierte Stacks Testing als Default, mit reichem Tooling für Behaviour Specification, Unit Testing und Continuous Integration. Das führt zu besser engineerter Software, schnellerem Debugging und cleanerem Handovers.
TYPO3 verhindert TDD oder BDD nicht, aber es encouraged es sicher nicht, und in der Praxis wird es selten gemacht. Das bedeutet mehr Reliance auf manuelle QA, mehr Projektrisiko und weniger Vertrauen in jedes Release.
Also warum schreibe ich das alles?
Weil ich an Projekten gearbeitet habe wo TYPO3 der Default war, und ich gesehen habe was es gekostet hat.
Teams haben Wochen damit verbracht Dinge zu bauen die woanders Stunden dauern würden. Basic eCommerce Flows brauchten Hacks. Tracking Scripts brachen jeden zweiten Monat. Niemand war sich ganz sicher wie Permissions funktionierten. Und Marketer waren davon ausgesperrt meaningful Änderungen zu machen weil die Agentur das machen muss.
Wenn du ein eCommerce Business baust, oder versuchst eine SaaS Plattform zu skalieren, oder einfach Ideen testen und schnell iterieren willst, ist TYPO3 die falsche Wahl. Außer du bist eine Gemeinde mit einer Fünfjahres Roadmap und keinem kommerziellen Druck, kannst du es besser machen.
Und ich sage das nicht als blanket Dismissal. Ich sage es als jemand der Systeme baut die Companies growen, nicht nur Compliance Boxen ticken.
Der bessere Weg
Was empfehle ich stattdessen?
- Solidus, Shopify oder sogar Magento (alles außer TYPO3 wirklich) für Commerce
- Next.js oder Rails für Content Driven oder Hybrid Apps
- Ein Backend wo Logic dokumentiert, getestet und clean deployed werden kann
- Ein Frontend wo Performance und Experience messbar sind
- Ein Growth Loop, kein Page Management System
Wenn du noch DSGVO, Lokalisierung, Workflow Approvals brauchst, können wir das bauen. Und wir werden es dokumentieren, testen und sicherstellen dass es skaliert.
TYPO3 mag noch eine Weile da sein, besonders in deutschsprachigen Institutionen, aber du musst nicht damit stuck sein.
Wenn du einen Rebuild planst oder versuchst etwas Altes und Clunky zu skalieren, zeige ich dir gern wie deine Optionen aussehen.