HTML First is a fool’s dream
It’s “Make HTML Great Again”… all over again
Many of you know, or now you know, that most snappy apps around the Internet are built on top of mature JavaScript frameworks, like React, Angular, Vue, Ember, Lit, you name it.
Some are deeper, like those running JavaScript on the server (backend) like Svelte, SolidJS, ExpressJS, Koa, Backbone, and many more. These like leveraging one single language, or even codebase, for a single project, which in returns removes a lot of headaches. You may thank “running JavaScript on server” to PHP own lack of innovation and advancements circa 2010.
That is precisely what argues HTML First: we don’t need all of that.
Honestly, it has a point, a web page will work fine with only HTML, but mostly it won’t because you will need more functionality. In other words, you can commute by bicycle, but most people will drive a car because it’s more convenient.
Even if anyone sane consider JavaScript as a mistake, it wouldn’t be such predominant around the web if it wasn’t by HTML and backend languages shortcomings that, after 30 years, haven’t resolved in any way: reactivity.
It’s JavaScript what enables reactivity on modern web pages. Adobe Flash tried to be the next big thing, but Apple killed it before it was too late. The closest you will have to a webpage that can react to changes made somewhere else by just using some HTML attributes inside a tag are HTML-X, followed by HyperScript.
// HTMLX
<button classes="toggle red">Click Me</button>
// HyperScript
<button _="on click toggle .red on me">Click Me</button>If you go the rabbit hole of making your website reactive, without needing to make a request to the server each time a value changes and wait for the result, you’re bound to use a JavaScript framework sooner or later. Vue it’s my personally choice, but it’s okay whatever you prefer to do the job.
That’s the whole point of JavaScript, mind you. Vanilla HTML is the start, but we’re so past the turning point of having reactivity embedded in HTML that we’re left with learning a JavaScript framework and hoping it stays alive, consistent and maintained for free, in the same vein your browsers is also maintained for free.
“And I know that, they know I know that, but other developers had no idea.”
Let me put it another way. When you go deep into the route of reactivity, it becomes a logic decision to check a JavaScript framework to see if you can streamline your development. Don’t get me wrong™, Vanilla JavaScript can make sense on a page or two, and more than often it just works and will keep working for years to come. It’s when you start to deal with dozens of pages and multiple data sources and displays when you get things done faster.
HTML First is something you think last
Today development problems don’t come from trying to wrap around your head around HTML tags, but reacting to values, manipulating variables, and firing events. HTML is the least of your problems.
Frameworks are built on top of HTML but, thanks to JavaScript and componentization, is recommended to use each frameworks element rather than vanilla HTML tags. Not only is faster to develop using the tools the frameworks wrap around HTML shortcomings, but also more consistent and reliable.
Up to this day, HTML is the base diagram for web programming and accessibility, but nothing more. It will keep being that for, probably, many years to come. May be W3C decides to create HTML 6 to bring new ideas and features that only JavaScript and backend servers made possible.
Maybe they do by the point everyone has moved into something else. Maybe they replace JavaScript with “WebScript” that fixes all problems the language has until now. Who knows.
The time to make “HTML First” was around mid-2000. That time was the moment to fight for the Web 2.0, not now.
As the W3C didn’t, time passed, and we have now to deal with the many frameworks going around on the Internet. Plus, require JavaScript on all webpages to work.
At least we have democratized the many alternatives of JavaScript solutions for creating rich web experiences, interpreter engines aside.
