How To Write Code That Will Last Forever 🔊

fagnerbrack.com 7 min read

11 Aug '26, 10:02current

Summary (TL;DR)

The article argues that writing code to a format (like HTML) rather than to a specific structure ensures long-lasting, backward-compatible systems. It criticizes modern practices like returning tightly coupled JSON from servers, which breaks when structure changes. The author proposes using a markup language (DML) and a native client (like Jasonette) to build apps that update without redeploying. The key is coding for capabilities and message formats, making systems robust like the Space Jam website from 1996, which still works due to HTML's format adherence.

How To Write Code That Will Last Forever 🔊

A picture from the rocky shore of the Dolphin Point Lookout in Noosa National Park, Queensland, Australia. The water is so transparent that the rocks and the sand in the bottom are clearly visible. Parks like this have strategic lookouts carefully designed for the public so that their beauty can last for a long time.

A great designer doesn't create the perfect masterpiece. They build strong foundations to support an environment where building a masterpiece becomes inevitable.

Do you remember the movie Space Jam?

The website for the movie was created in 1996. Today, 22 years later, it looks exactly the same as it did in the past.

How's that even possible?

Even though the HTML format has changed over time, browsers still know how to support old elements, such as the center and frame tags. That allowed the Space Jam website to remain backward compatible for decades.

The reason browsers are backward compatible by default is that their code is written primarily to interpret HTML. They write code to a format that can represent the state of the page in a way the browser doesn’t need to know how the page is structured.

They just need to write code once that understands the format, nothing else.

Here's an example:

The code representing the internals of a dummy browser. There’s a “page content” variable representing the root of the page. The variable calls a method to retrieve each “child element.” For each “child” element, it runs a function called “render element and children.” The code for the function checks if the element is a “script”, “container”, “text node” or “input.” If it’s a “container”, it traverses all the elements again, recursively. For all the other types, it just renders them accordingly.

It makes sense for a browser to code against HTML. If they were to code to the specific structure of a website, they would have to write things like this:

The code representing the internals of a dummy browser. It gets the first element of type "container", then the first element of type "input" that is assumed to exist inside the "container." It's wrapped in a conditional that only runs if the website is "google.com."

The code above assumes that a “container” exists on the page. It also assumes the "container" has an “input” child. If the website changes the structure to remove the container, every browser would have to be updated.

The element types “container”, “script”, “text node” and “input” don't represent exactly how browsers define elements internally. Real browsers need to worry about performance and support different kinds of elements.

The point here is to show that you can write code once that can parse anything without having any knowledge of how another system is structured. The idea is to build capabilities, not just write some pretty code to workaround an immediate problem.

You can write code once that can parse anything, as long as you code for capabilities.

In "modern" Front-End development, it's a very common practice to return a JSON from the server with a structure that is bound to the exact website it's operating on:

The runnable code representing two server-side responses parsed as JSON and rendered in a client-side HTML template. The first response contains a property called "user." The "user" property holds an Object Literal containing a property called "name." The value for the "name" property is a String called "Mary." The second response contains only one property called "user name." The value for the "user name" property is also a String called "Mary." The client-side HTML template renders the "name" property from the "user" Object Literal model. If you change the response from the server, the client will render the String "undefined."

In a previous post, I have presented how that's being coded in websites out there and being labeled as “Single Page Apps”.

The problem is if the structure of the server response is changed, the client-side code breaks.

That's extremely fragile.

If you start to apply the principles of building capabilities for websites that re-create HTML with JavaScript and JSON, you'll end up reinventing HTML.

If that's the case, then just return HTML from the server!

Cool, HTML is great for a browser. However, if you send HTML from your server, you're effectively writing code that only works for browsers! That seems pointless if you have to support things like mobile clients unless you want to put your website in a "web view."

Exactly!

HTML is the only format browsers can parse efficiently. It's a format that was created before controls such as "swap", "touch" or "shake" existed. In order to access those controls in the browser, you have to write custom JavaScript.

The concept of “web view” exists on both Android and iOS. It allows you to load a website into a native mobile app. It's very easy to create a website that works in the browser and load the same codebase into a "web view." If you do that, you can avoid writing yet another front-end for your product.

Just because it's easy, that doesn't mean it's ideal.

If you have some experience in mobile apps, you know a "web view" doesn't come without tradeoffs.

It doesn't scale.

The “mobile” version will become slower as more code and features are added to the “web.” The “web” version will become slower as more code and features are added to “mobile.”

As time goes by, there will be product changes different for "mobile" and "web." At some point, as complexity start to increase, everyone will realize that the workflow is completely different between "mobile" and "web."

They are fundamentally decoupled and cohesive on their own.

You can adapt the same codebase of your website to a mobile "web view." However, that doesn't scale.

So what's the alternative?

You can build native mobile apps — without HTML — using the same principles that made the web as robust and backward compatible as it is.

Imagine in one side you have a server that returns a different markup language for an HTTP request, let's call it DML — Different Markup Language. That markup language conforms to a specific format optimized for mobile. It allows a program to write code to understand that format, just like browsers write code to interpret HTML.

On the other side, you have the client. It's a native mobile app that is like a "browser." However, it doesn't understand HTML and has no "web view." It's optimized to parse DML and build the whole app from the server.

In this setup, you have the power to change all the UI, including the interactions, without changing a single line of code in your app.

It would be like a "native app over HTTP."

Wouldn't that be great?

A system where you can make changes in the server and update the mobile app would be a game changer.

The good news is that it already exists.

The author calls it "jasonette":

A video from the author of jasonette introducing the core idea behind it. It's possible to write code on the server that can be used to create a mobile app.

Jasonette is a very good example.

You don't have the problem of having to deploy multiple projects in a specific order. You just need to deploy changes in your Back-End and it will always work.

You'll never have to write code specifically for a mobile app, you have a client that can understand a format and a server that can write to it.

Imagine a book.

The book is written by a human brain who uses a written language to communicate a message to another human brain. The brain of a human can be considered a biological Turing Machine. The capability to read has been programmed into the human brain so that it can effectively understand the message somebody else is trying to send.

In this case, the human brain of the writer represents the server. The human brain of the reader represents the browser. The book is the website. The content of the book is the HTML message.

The capability to understand the content of the book is coded inside the human. It would make no sense for a human to be specifically coded to read a single book.

Due to the way evolution has built us, the contents of the book can change but the human doesn't have to. The only thing it needs is the ability to read in a specific language. It just needs to know the communication format.

That's what the browser is for HTML: an artificial brain who can understand a communication format.

The browser can read a website as efficiently as you can read a book, as long as the server and the client conform to a common message format.

Sometimes great ideas are hidden in plain sight.

If you code to the format of a message, not the structure, you can build a great system that won't require multiple ordered deployments.

Just like the text you're reading right now, computers can also understand a common language and pass a message efficiently.

With this fundamental principle, you will be able to create something today that may become the next Space Jam website of tomorrow.

Code that you will write once… and last forever.