The purpose of this series was to explore the idea maze of what the web might look like if it were rebuilt from first principles given the internet infrastructure we have today. The goal was to force clarity to a mess of unrefined ideas by putting them into words as a new essay each month of 2024. Afterward came implementation and not every idea survived first contact with reality. Even the names themselves changed: XUI became Web4, HTTP/X became Keyholes, and ZeroScript became XTML (ironic considering the "zero theme" of the series). This work eventually led to the formation of The Web4 Foundation.

Shiny new things

Learning new things and exploring new ideas is something I’ve always enjoyed. Ten years ago my old friend Scott – brilliant engineer – would go to lunch with me every day and we’d geek out together. If we weren’t discussing the latest tech news, I’d bounce crazy ideas off him to see what he thought. He’d always poke thoughtful holes in the corners I hadn’t yet considered. I enjoyed the exercise. He seemed to as well.

Then one day he had a response that set me back on my heels. I thought he was joking at first. We had just spent twenty minutes hammering out some clever solutions to whatever was the problem du jour and I thoughtlessly blurted out, “Well cool. That seems like a very elegant solution. So is that something you'd use on a personal project too?”

He said, “Oh gosh no. Absolutely not.”

I paused waiting for the punchline but soon realized he was being serious. I said, “Wait, why not? This is better right?” His response echoes in my head to this day.

“It's not that I won't learn new things. I’d just rather not waste time on things that won’t last.”

On framework fatigue

Let's talk about web frameworks.

The winds are shifting in the web community. The burden of playing guinea pig has reached a tipping point. While it is known that the price of innovation comes with the burden of frequent change, the ground beneath has become sand – too unstable to build anything upon anymore. Meanwhile the one narrative that served as a flame of hope seems to be all but abandoned – that webapps will inevitably catch up to native apps and humanity can finally remove the training wheels that is the walled garden app store just like the venerable URL did to AOL and their silly “AOL Keywords” back in the 90s.

Now let’s talk numbers. There’s a term in physics called half-life that loosely correlates to death-rate:

Half-life is the time required for a quantity (of substance) to reduce to half of its initial value. The term is commonly used in nuclear physics to describe how quickly unstable atoms undergo radioactive decay or how long stable atoms survive.

This dataset uses Google Trends as an indication of popularity. A few notes:

• Each framework has been normalized by its own “peak popularity” on a scale of 0-100 and thus cannot be used to compare how much more popular one framework was compared to another.
• Half-life is calculated by counting the months between its peak popularity of 100 and the next nearest 50.
• It’s also worth pointing out that search trends more closely correlate to popularity than usage – as we painfully know, the usage of any technology often has a mighty long tail of support, long after its popularity is lost.
• React is missing because its popularity hasn’t dipped below 50 yet.
• AngularJS is tricky because of Angular (sans the JS) which replaced it. Measuring search trends on the latter was hard to separate by keyword from the former. Below includes only the predecessor AngularJS since the successor Angular, like React, hasn’t dipped below 50 yet.

This suggests that the half-life of a modern web framework is about 2.5 years. If you went to college, expect whatever was king when you entered to be in hospice care before you exit. If you attended a bootcamp, don’t be surprised to emerge 3 months later discovering that you’re no longer versed in the “top” framework.

If you can't beat them, join them

“The busy man is never wise and the wise man is never busy.” ― Lin Yutang

Thus Scott became my litmus test. If I ever were to put any of those ideas to paper, it’d have to be something he’d be willing to use. It needed to somehow be written in stone. It needed to be the web’s “final form.”

This got me thinking about how powerful HTML has proven to be over the past 30 years. It's powerful because it's declarative. This allows the ground beneath it to shift around while it itself remains evergreen and durable by default. There exist websites that were built in the 90s, untouched since, and they still run today. Amazing. This makes HTML like hydrogen – its half-life is effectively infinity.

So what would a declarative-only web framework look like? Mostly like vanilla HTML with some minor embellishments thrown in.

• Components? Just use smaller .html files.
• Properties? Just use HTML attributes.
• Routing? Just use a file-based approach.
• Control flow? Introduce <if> and <for> tags.
• State? Try a <state> tag.
• DOM updates? No imperative code like getElementById or innerHTML. HTML just updates itself when <state> changes.

This covers the overlapping features across all web frameworks. Both event handlers and dynamic expressions can be handled with any escape sequence such as {{ }}. All the business logic can remain in separate files as intended.

Artifacts

Here’s an artifact to explore the concept concretely. It’s called ZeroScript since the goal is to flesh out a complete UI layer using, hopefully, zero JavaScript. (One delicious side effect is that it opens the door to use imperative languages other than JavaScript. But that’s an essay for another month.)

• Learn ZeroScript in 180 seconds at ZeroScript.org
• Spec: github.com/schmylan/zeroscript