I am building a retro-compatible CMS

My name is Jonathan Pablo Toledo M. I am a Computer Science engineer with technical training in electrical work, and I keep a collection of old computers - machines from the early 80s that still switch on.

My work has mostly been the web. The first professional site I built was in 2004, though I had been programming for a while before that - around 1999 I was writing software in a BASIC interpreter. But my biggest contributions have always been on the web side. I started when browsers barely managed text and a couple of images.

Capable machines, cut off from everything

That is why it saddens me that machines with 16-bit processors, machines that once connected to networks, are today completely cut off. It is not that they lack capability: they have more than enough power to receive information and put it on screen. What they lack is a site on the other end willing to speak a language they understand. The web stopped writing to them, not the other way around.

So I am taking my 25-plus years of experience and building a system to bring these devices out of isolation. Not emulation, not a museum replica: the same website, served in a shape a machine from 1985 can actually read.

First stage: a three-epoch MVP

The starting plan is deliberately small: an MVP with templates split into three epochs, and a spreadsheet-style database to publish content from.

EPOCH 1, EPOCH 2, EPOCH 3 + SPREADSHEET

Epoch 1, early - browsers from the first years, which get the basic HTML template
Epoch 2, middle - browsers that understand CSS1 and CSS2, which get the styled template
Epoch 3, modern - browsers with CSS3 and HTML5, which get the current template

The server reads the User Agent that arrives, decides which epoch it belongs to, and assembles the page out of that epoch's pieces. Every component - the container, the menu, the slider, the blog - exists three times, once per epoch, and an orchestrator combines them according to what the visitor can understand. Theme and language travel down the same path, so a single engine can serve a dark theme and a light one.

Why a spreadsheet?

Because for an MVP I do not need a real database, I need to be able to write. Routes, front-page content, blog summaries and full entries all live for now in a Google Sheets spreadsheet, and the server reads it through its API. It is a temporary decision and I know it, but it lets me concentrate on what actually matters right now: getting the page assembled correctly for each epoch. The database can always be swapped out later. The template engine is the hard part.

It is written in C, with no heavy dependencies, so it can run just about anywhere. If this goes the way I hope, at some point I will be able to open my own site from one of the machines on the shelf and read it end to end. That is the whole goal.