--- title: Wer an morgen denkt, pflanzt schon heute die Bäume url: "https://b13.com/de/wissen/wer-an-morgen-denkt-pflanzt-schon-heute-die-baeume" description: "Sind die Websites, die wir heute bauen, in hundert Jahren noch lesbar? Notizen zu Steven Pembertons Keynote auf der Open Source CMS 26 in Utrecht." image: "https://b13.com/fileadmin/_processed_/5/5/csm_b13-blog-header-03d-plant-the-trees-watering-3000x2000_be00078508.png" date: 2026-10-29 modified: 2026-10-29 lastUpdated: 2026-10-29 --- # Wer an morgen denkt, pflanzt schon heute die Bäume [ TYPO3 ](https://b13.com/de/wissen/typo3) [ Enterprise CMS ](https://b13.com/de/wissen/enterprise-cms) [ Events ](https://b13.com/de/wissen/events) Wer an morgen denkt, pflanzt schon heute die Bäume ==================================================== ![Lächelnder Mann mit kurzen Haaren und einem Bart, der ein rotes T-Shirt trägt, steht in einem gut beleuchteten Innenraum mit verschwommenem Hintergrund.](https://b13.com/fileadmin/_processed_/a/d/csm_david_71310b8880.webp) David Steeb 29. Oktober 2026 [ RSS Feed ](https://b13.com/de/rss.xml) ![Eine rote Gießkanne gießt Wasser auf eine kleine grüne Pflanze, mit einem Sonnenstrahlen-Hintergrund, der Wachstum und Pflege betont.](https://b13.com/fileadmin/_processed_/5/5/csm_b13-blog-header-03d-plant-the-trees-watering-3000x2000_d2ea810efb.webp) Steven Pemberton fragte den Saal voller CMS-Leute, ob die Websites, die sie heute bauen, in hundert Jahren wohl noch lesbar sind — und erklärte, warum viele es nicht sein werden. Tag zwei der [Open Source CMS 26](https://www.boye-co.com/conferences/opensourcecms26), der ersten Ausgabe der anbieterunabhängigen Konferenz von Boye & Company in Utrecht, Niederlande, startete am 21. Oktober 2026 mit Steven Pembertons Keynote „[Designing With the Future in Mind](https://homepages.cwi.nl/~steven/Talks/2026/10-21-opensource/)“. Steven ist Forscher am CWI in Amsterdam, Autor, Speaker und Moderator. Er hat ABC mitentwickelt, die Programmiersprache, auf der Python basiert, HTML, CSS und mehrere andere Webstandards mitgeprägt und war 1988 der erste Nutzer des offenen Internets in Europa. Wenn er über die lange Sicht spricht, weiß er also, wovon er redet. Als erstes ging es um ein Gebäude in Oxford. ![Ein Redner steht an einem Podium mit einem Laptop und spricht ein Publikum in einem Konferenzsetting an. Eine Präsentationsfolie ist im Hintergrund sichtbar.](https://b13.com/fileadmin/_processed_/f/f/csm_IMG_6540_d0618bbcd1.webp) Steven Pemberton spricht auf der CMS Conference 2026 in Utrecht. Die Eichenbalken von New College ---------------------------------- Steven fing mit Stewart Brands Buch *How Buildings Learn* an. Brands These: Architekten können nicht wissen, wie ein Gebäude im Laufe seines Lebens genutzt wird. Deshalb sollten sie nicht nur für heute planen, sondern die Zukunft gleich mitdenken. Eine Geschichte aus dem Buch handelt vom New College in Oxford, gebaut 1379. Das Dach des Speisesaals tragen riesige Eichenbalken. Als sie irgendwann ersetzt werden mussten, wusste niemand, wo man so große Eichen herbekommen sollte. Also fragte das College beim Förster der Universität nach. Seine Antwort, so erzählt es Brand: „New College? Na, eure Bäume hab ich.“ Schon als das College gebaut wurde, hatte man Bäume gepflanzt, damit sie bereitstehen, wenn man sie braucht. „So eine Haltung sieht man heute kaum noch“, sagte Steven. Er verlangte nicht, dass jemand 500 Jahre vorausplant. Hundert Jahre hielt er aber für einen sinnvollen Horizont. Und dann stellte er die Frage: Was heißt das für das Web? > So eine Haltung sieht man heute kaum noch. Steven Pemberton, Forscher am CWI Das Web hängt noch an der Vergangenheit ----------------------------------------- Zum Vergleich zog er den Buchdruck heran. Vor Gutenberg dauerte es Jahre, ein einziges Buch abzuschreiben. Mit dem Buchdruck wurden Bücher günstiger und leichter zu bekommen, und plötzlich lohnte es sich, lesen zu lernen. Bis 1500 hatten rund 1.000 Druckereien 35.000 Titel in 20 Millionen Exemplaren gedruckt. Weil Papier und Tinte so gut waren, können wir diese Bücher heute noch lesen. In den ersten 50 Jahren sahen gedruckte Bücher allerdings möglichst genauso aus wie Handschriften: Schriften, die Handschrift nachahmten, keine Seitenzahlen, kein Inhaltsverzeichnis, kein Register. Steven nannte das „den Skeuomorphismus des 15. Jahrhunderts“. Erst nach etwa 50 Jahren nutzten die Drucker das neue Medium für das, was es wirklich konnte. Beim Web sieht Steven uns an einem ähnlichen Punkt. Es hat Informationen günstig und massenhaft verfügbar gemacht und eine ganz neue Branche geschaffen, aber es ahmt immer noch nach, wie wir früher gearbeitet haben. Auch die Computertechnik ist noch jung. Vor 69 Jahren stellte die Stadt Norwich in England den ersten kommunalen Computer auf. Damit begann der Einsatz von Computern im öffentlichen Bereich. Als das Web kam, war das gerade einmal 34 Jahre her, und das Web selbst wird dieses Jahr 35. Wie wir Websites bauen, ist also noch längst nicht festgelegt, und die Entscheidungen, die wir heute treffen, werden uns lange begleiten. Deklarativ statt programmiert ------------------------------- Im technischen Teil des Vortrags ging es um deklarative Ansätze. Als Beispiel nahm Steven die Quadratwurzel. In der Schule lernst du: Die Quadratwurzel einer Zahl ist die Zahl, die mit sich selbst multipliziert die Ausgangszahl ergibt. Diese Definition ist deklarativ. Sie sagt dir, was etwas ist und woran du es erkennst, aber nicht, wie du es ausrechnest. Die prozedurale Variante, also der Algorithmus, der die Wurzel berechnet, ist viel schwerer zu lesen, zu prüfen oder zu ändern. HTML war anfangs weitgehend deklarativ. Ein `h1` sagt „Das ist eine Überschrift der obersten Ebene“, aber nichts darüber, wie sie aussieht. Ein Link-Element deckt in einem einzigen Tag eine Menge Verhalten ab: was beim Hovern passiert, wie man ihn aktiviert und wie er dargestellt wird. Auch CSS ist deklarativ. Für Steven ist das einer der Gründe, warum das Web so erfolgreich wurde, neben der Tatsache, dass es einfach und kostenlos ist. Seine Kritik: Die Browserhersteller, allen voran Google, machen HTML immer prozeduraler. Statt neuer Elemente für neue Anforderungen heißt die Antwort inzwischen: „Mach das mit JavaScript.“ Das Ergebnis sind seiner Meinung nach Dutzende JavaScript-Frameworks, jedes mit seiner eigenen Spielart von HTML. Wenn dein Framework stirbt, nicht mehr gepflegt wird oder seine Lizenz ändert, musst du deine Website neu bauen. Er zeigte auch, was das die Nutzer kostet. Der Government Digital Service in Großbritannien hat festgestellt, dass 1,1 % seiner Nutzer, also jeder 93., die JavaScript-basierten Verbesserungen nicht sehen, und damit auch nicht nutzen konnte. Als USA Today nach Einführung der DSGVO eine eigene EU-Version seiner Website ohne Tracking-Skripte und Werbung startete, schrumpfte die Seite von 5,2 MB auf 500 KB, und die Ladezeit sank von über 45 Sekunden auf 3 Sekunden. Barrierefreiheit braucht valides, semantisches Markup, und genau das fehlt vielen Seiten, die Markup mit Frameworks erzeugen. Das Web ist heute Teil unserer Infrastruktur. Oder wie Steven es sagte: „Eines Tages sind wir alle 80 und müssen das Web trotzdem noch nutzen können.“ > Eines Tages sind wir alle 80 und müssen das Web trotzdem noch nutzen können. Steven Pemberton Außerdem hat er nachgezählt, wie viele Seiten seiner eigenen Website kaputtgehen, weil Google angekündigt hat, einige deklarative Webtechnologien nicht mehr zu unterstützen: 3.501 von 6.136. Das ist fast 60 % seiner Website, obwohl sich am Inhalt überhaupt nichts geändert hat. Geändert hat sich nur die Plattform darunter. Die Geschichte von morgen aufbewahren --------------------------------------- Im letzten Teil des Vortrags ging es um Inhalte. Organisationen löschen ständig Dinge: alte E-Mails, Entwürfe, frühe Softwareversionen und Webseiten, die „nicht mehr gebraucht“ werden. Stevens Punkt: Du kannst heute nicht wissen, was später einmal wertvoll ist. Dass das CWI (Centrum Wiskunde & Informatica) Briefe von Einstein und Escher noch hat, ist reines Glück. Stevens eigenes Team hat einmal einen Apple Lisa weggeworfen, einen der ersten Computer für den Massenmarkt, weil er im Weg stand. Allein die Maus wäre heute über 500 US-Dollar wert. Ein Gigabyte Speicherplatz kostet ein paar Cent. Löschen spart also kaum etwas, kann aber viel kosten. Sein Rat: „Bewahrt heute auf, was morgen Geschichte ist.“ Und lasst Webseiten unter der URL, die sie schon immer hatten. Oder wie Tim Berners-Lee sagte: „Cool URLs don’t change.“ > Bewahrt heute auf, was morgen Geschichte ist. Steven Pemberton Er gab zu, dass man dann auch vieles aufhebt, was nie eine Rolle spielen wird. Aber herausfinden, was wichtig ist, kannst du nur, wenn du es lange genug aufbewahrst und abwartest. Was das für unsere TYPO3-Websites bedeutet -------------------------------------------- Wir würden HTML5 wohl etwas milder beurteilen als Steven. Immerhin hat es uns viele der semantischen Elemente gebracht, die wir täglich nutzen, und manches im Web braucht nun mal JavaScript. Im Kern deckt sich seine Argumentation aber mit dem, wie wir bei b13 schon lange Websites bauen. ### Inhalte leben länger als ihre Darstellung In TYPO3 werden Inhalte im Backend strukturiert und auf dem Server in HTML ausgegeben. Templates, CSS und das JavaScript, das die Seite verbessert, liegen obendrauf. Bei einem Relaunch kannst du sie austauschen, ohne die Inhalte anzufassen. Genau diese Trennung meinte Steven: Der deklarative Teil, also was der Inhalt ist, bleibt stabil. Die Darstellung ist der Teil, der sich ändern darf. Das gilt auch für die Rich-Text-Felder, in denen Redakteure schreiben. Wir konfigurieren den Rich-Text-Editor so, dass im gespeicherten Text nur deklaratives Markup landet: Überschriften, Absätze, Listen, Links und Hervorhebungen. Keine Farben, keine Inline-Styles, keine Schriftgrößen. Wie eine Überschrift oder ein Zitat aussieht, regelt das Template. So ergeben die Inhalte in der Datenbank auch nach dem nächsten Redesign noch Sinn, und nach dem übernächsten auch. ### Semantisches HTML vom Server als Standard Unsere Websites liefern echtes HTML aus. Überschriften sind Überschriften, Links sind Links, und die Navigation funktioniert, ohne dass erst ein Framework im Browser starten muss. Wir nutzen JavaScript, um eine Seite zu verbessern, aber zum Lesen brauchst du es nicht. So bleibt eine Website barrierefrei und schnell, und lesbar, auch lange nachdem der aktuelle Frontend-Stack ausgetauscht wurde. ### Weniger Abhängigkeiten, weniger Neuentwicklungen Jedes Framework, das du einbaust, ist eine Wette auf die Roadmap von jemand anderem. Das ist ein großer Grund dafür, dass wir „core-nah“ arbeiten: Je näher ein Projekt an den Konventionen von TYPO3 bleibt, desto weniger Fremdkomponenten können beim nächsten Upgrade etwas kaputt machen. Die langen Support-Zyklen von TYPO3 helfen nur, wenn das Projekt selbst keine Abhängigkeiten ansammelt, die viel kürzer leben. ### Archivieren statt löschen Bei einem Relaunch wollen viele Teams alte Inhalte loswerden. Manchmal ist das richtig. Oft lohnt sich aber die Frage, was archiviert werden sollte und auffindbar bleiben kann, nur eben nicht mehr in der Hauptnavigation. In TYPO3 ist das meist eine Frage des Seitenbaums und der Navigationseinstellungen, kein technisches Projekt. Und wenn sich URLs doch ändern, sorgt das Weiterleitungsmodul im TYPO3-Core dafür, dass die alten Adressen weiter funktionieren. Ob Inhalte verschwinden oder URLs sich ändern, sollte eine bewusste Entscheidung sein und kein Nebeneffekt des Relaunches. Wann dieser Ansatz nicht passt -------------------------------- Nicht jedes Projekt muss in hundert Jahren noch lesbar sein. Eine Kampagnen-Microsite, eine kurzlebige Eventseite oder ein internes Tool sollte für die Zeit gebaut werden, die es tatsächlich im Einsatz ist, ohne Overengineering. Manche Anwendungen, etwa ein Produktkonfigurator oder ein Dashboard, brauchen viel clientseitige Logik, weil sie eben keine Dokumente sind. Und alles für immer aufzubewahren, ist nicht immer erlaubt. Datenschutzvorgaben oder veraltete Informationen, die Leute in die Irre führen könnten, sind gute Gründe, Inhalte zu entfernen. Wir würden also nicht für „Nie JavaScript nutzen“ oder „Nie etwas löschen“ plädieren. Sondern dafür, bewusst zu entscheiden, welche Teile einer Website bleiben sollen, und genau diese Teile so zu bauen, dass sie lange halten. Was ich mitnehme ------------------ - Das Web ist jung. Die Konventionen, die wir heute festlegen, erben spätere Generationen. - Deklaratives, semantisches Markup überlebt die Frameworks, die es erzeugen, und das gilt auch für das Markup in deinen Rich-Text-Feldern. - Wähl Abhängigkeiten mit Bedacht, denn jede bindet deine Website an den Zeitplan von jemand anderem. - Löschen spart heute wenig und kann später viel kosten. Archivier bewusst und behalte deine URLs. - Pflanz die Bäume, bevor du die Balken brauchst. Du willst eine Website, die lange hält? ----------------------------------------- Planst du einen Relaunch und willst, dass die Website, die du jetzt baust, auch in zehn Jahren noch funktioniert, von hundert ganz zu schweigen? Dann denken wir das gern mit dir zusammen durch. [ Lass uns sprechen ](https://b13.com/de/kontakt) ### Geschrieben von: ![Lächelnder Mann mit kurzen Haaren und einem Bart, der ein rotes T-Shirt trägt, steht in einem gut beleuchteten Innenraum mit verschwommenem Hintergrund.](https://b13.com/fileadmin/_processed_/a/d/csm_david_cf042ebb7f.webp) Als b13-Gründer und CEO is David derjenige, mit dem Du es zu tun haben wirst, wenn Du mit uns zusammenarbeiten möchtest. Er eignet sich ständig neue Fähigkeiten an und bestimmt maßgeblich unsere hochmodernen Ansätze in der Frontend-Entwicklung. David Steeb CEO [ mehr von David Steeb ](https://b13.com/de/team/david-steeb)