--- title: Plant the Trees Before You Need the Beams url: "https://b13.com/knowledge/plant-the-trees-before-you-need-the-beams" description: "Will the websites we build today still be readable in a hundred years? Notes from Steven Pemberton’s keynote at 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 --- # Plant the Trees Before You Need the Beams [ TYPO3 ](https://b13.com/knowledge/typo3) [ Enterprise CMS ](https://b13.com/knowledge/enterprise-cms) [ Events ](https://b13.com/knowledge/events) Plant the Trees Before You Need the Beams =========================================== ![Bild von David Steeb](https://b13.com/fileadmin/_processed_/a/d/csm_david_71310b8880.webp) David Steeb 29 October 2026 [ RSS Feed ](https://b13.com/rss.xml) ![A red watering can pours water onto a small green plant, with a sunburst background emphasizing growth and nurturing.](https://b13.com/fileadmin/_processed_/5/5/csm_b13-blog-header-03d-plant-the-trees-watering-3000x2000_d2ea810efb.webp) Steven Pemberton asked a room full of CMS people whether the websites they build today will still be readable in a hundred years, and explained why many of them won’t be. Day two of [Open Source CMS 26](https://www.boye-co.com/conferences/opensourcecms26), the first edition of Boye & Company’s vendor-neutral conference in Utrecht, Netherlands, opened on 21 October 2026 with Steven Pemberton’s keynote “[Designing With the Future in Mind](https://homepages.cwi.nl/~steven/Talks/2026/10-21-opensource/).” Steven is a researcher at CWI in Amsterdam, an author, public speaker, and broadcaster. He co-designed ABC, the programming language Python is based on, helped shape HTML, CSS, and several other web standards, and was the first user of the open internet in Europe in 1988. When he talks about the long term, he speaks from experience. He started with a building in Oxford. ![A speaker presents at a podium with a laptop, addressing an audience in a conference setting. A presentation slide is visible in the background.](https://b13.com/fileadmin/_processed_/f/f/csm_IMG_6540_d0618bbcd1.webp) Steven Pemberton speaking at CMS Conference 2026 in Utrecht. The Beams of New College -------------------------- Steven opened with Stewart Brand’s book *How Buildings Learn*. Brand argues that architects can’t know how a building will be used over its whole life, so they should design with the future in mind as well as the present. One story from the book is about New College, Oxford, built in 1379. Its dining hall has huge oak beams in the roof. When the beams eventually needed replacing, nobody knew where to find oak of that size, so the college asked the university forester. His answer, as Brand reports it: “New College? Well, I’ve got your trees.” Around the time the college was built, trees had been planted to be ready for when they’d be needed. “We don’t see that sort of attitude much these days,” Steven said. He wasn’t asking anyone to plan for 500 years, but he did think a hundred years was a reasonable horizon. And then he asked what that means for the web. > We don’t see that sort of attitude much these days. Steven Pemberton, Researcher at CWI The Web Still Imitates the Past --------------------------------- His comparison was printing. Before Gutenberg, producing a single copy of a book took years. Printing made books cheaper and easier to get, and it gave people a reason to learn to read. By 1500, around 1,000 print shops had produced 35,000 titles in 20 million copies. Because the paper and ink were good, we can still read those books today. For the first 50 years, though, printed books looked as much like manuscripts as possible: handwriting fonts, no page numbers, no table of contents, no index. Steven called it the 15th-century version of skeuomorphism. It took about 50 years before printers started using the new medium for what it could do. Steven sees the web in a similar place. It made information cheap and plentiful and created a whole new industry, but it still copies the way we used to do things. Computing is also still young. Public computing started 69 years ago, when the city of Norwich in England installed the first municipal computer. When the web was introduced, public computing was only 34 years old, and the web itself turns 35 this year. The conventions for how we build websites are still being set, and the decisions we make today will be around for a long time. Declarative Instead of Programmed ----------------------------------- The technical part of the talk was about declarative approaches. Steven used the square root as an example. In school, you learn that the square root of a number is another number that, multiplied by itself, gives the original number. That definition is declarative: it tells you *what* something is and how to recognize it, but not how to calculate it. The procedural version, the algorithm that computes it, is much harder to read, check, or change. HTML started out largely declarative. An h1 says “this is a top-level heading,” nothing about how it looks. A link element covers a lot of behavior in a single tag: what happens on hover, how you activate it, and how it’s presented. CSS is declarative, too. Steven counts that among the reasons the web succeeded, alongside being simple and free. His criticism is that browser makers, led by Google, have been changing HTML into something more and more procedural. Instead of new elements for new needs, the answer became “do it in JavaScript.” In his view, the result is dozens of JavaScript frameworks, each of them its own flavor of HTML. If your framework dies, stops being updated, or changes its license, you have to rebuild your website. He also showed what that costs users. The UK’s Government Digital Service found that 1.1% of its users, one in every 93, didn’t receive JavaScript-based enhancements. When USA Today launched a separate EU version of its site without tracking scripts and ads after GDPR, the page weight dropped from 5.2 MB to 500 KB, and the load time from more than 45 seconds to 3 seconds. Accessibility depends on valid, semantic markup, which many framework-generated pages don’t have. The web is part of our infrastructure now, and as Steven put it: “One day we will all be 80, and still need to be able to use the web.” > One day we will all be 80, and still need to be able to use the web. Steven Pemberton He also counted how many pages on his own website will break because Google announced it will drop support for some declarative web technologies: 3,501 out of 6,136. That’s almost 60% of his site, and the content didn’t change at all. Only the platform underneath it did. Plan to Keep Your Future History ---------------------------------- The last part of the talk was about content. Organizations delete things all the time: old emails, drafts, early versions of software, and web pages that are “no longer needed.” Steven’s point was that you can’t know today what will be valuable later. The CWI (Centrum Wiskunde & Informatica) only has letters from Einstein and Escher by luck. Steven’s own team once threw away an Apple Lisa (one of the first mass-market computers) because it was in the way. Today, the mouse alone would sell for more than USD 500. One gigabyte of disk space costs a few cents, so deleting saves very little and can lose a lot. His advice: “Plan to keep your future history.” And keep web pages at the URL they always had. As Tim Berners-Lee put it: “cool URLs don’t change”. > Plan to keep your future history. Steven Pemberton He admitted that this means keeping a lot of things that will never matter. But the only way to find out what matters is to keep it long enough and wait. What This Means for How We Build TYPO3 Sites ---------------------------------------------- We’d probably judge HTML5 a little more kindly than Steven does, since it also gave us many of the semantic elements we use every day, and some things on the web do need JavaScript. However, the core of his argument matches how we’ve built websites at b13 for a long time. ### Content Lives Longer Than Its Presentation In TYPO3, content is structured in the backend and rendered into HTML on the server. Templates, CSS, and the JavaScript that enhances the page sit on top of it, and you can replace them in a relaunch without touching the content. That’s the separation Steven talked about: the declarative part, what the content *is*, stays stable, and the presentation is the part you expect to change. The same goes for the rich text fields that editors write in. We configure the rich text editor so that the stored text contains declarative markup only: headings, paragraphs, lists, links, and emphasis. No colors, no inline styles, no font sizes. How a heading or a quote looks is the template’s job. That way, the content in the database still makes sense after the next redesign, and the one after that. ### Server-Rendered, Semantic HTML Is the Default Our sites deliver real HTML. Headings are headings, links are links, and navigation works without a framework starting up in the browser. We use JavaScript to improve a page, but you don’t need it to read one. That keeps a site accessible and fast, and readable long after the current frontend stack has been replaced. ### Fewer Dependencies, Fewer Rebuilds Every framework you add is a bet on someone else’s roadmap. That’s a big part of why we work in a way we call “core-near”: the closer a project stays to TYPO3’s own conventions, the fewer third-party pieces can break it on the next upgrade. TYPO3’s long support cycles only help if the project itself doesn’t collect dependencies with a much shorter life span. ### Archive Instead of Delete In a relaunch, many teams want to get rid of old content. Sometimes that’s right. Often, though, it’s worth asking what should be archived and kept findable, just no longer in the main navigation. In TYPO3, that’s usually a matter of page tree structure and navigation settings, not a technical project. And when URLs do change, the redirects module in the TYPO3 core keeps the old addresses working. It should be a deliberate decision, not a side effect of the relaunch. When This Is the Wrong Approach --------------------------------- Not every project needs to be readable in a hundred years. A campaign microsite, a short-lived event page, or an internal tool should be built for its lifespan, without over-engineering. Some applications, like a product configurator or a dashboard, need a lot of client-side logic because they aren’t documents. And keeping everything forever isn’t always allowed. Privacy rules, or outdated information that could mislead people, are good reasons to remove content. So we wouldn’t argue for “never use JavaScript” or “never delete anything.” We’d argue for deciding which parts of a site are meant to last, and building those parts so they can endure in the long run. What I’m Taking Home ---------------------- - The web is young. The conventions we choose today are the ones later generations will inherit. - Declarative, semantic markup outlives the frameworks that generate it, and that includes the markup in your rich text fields. - Choose dependencies carefully, because each one ties your site to someone else’s timeline. - Deleting content saves little today and can cost a lot later. Archive on purpose, and keep your URLs. - Plant the trees before you need the beams. Building a website that’s meant to last? ------------------------------------------ If you’re planning a relaunch and want the site you build now to still work in ten years, let alone a hundred, we’d be happy to think it through with you. [ Let’s talk ](https://b13.com/lets-connect) ### Written by: ![Bild von David Steeb](https://b13.com/fileadmin/_processed_/a/d/csm_david_cf042ebb7f.webp) b13 Founder and CEO, David, is someone you’ll meet if you’re thinking about working with our agency. He is constantly learning new skills and is an influential part of our cutting-edge frontend practice. David Steeb CEO [ more from David Steeb ](https://b13.com/team/david-steeb)