The Post-HTML Browser
This is a crazy, possibly bad, idea — but I thought it would be fun to explore. Give it five minutes.
The post-HTML browser is a web browser, or a special mode of a browser, optimized for JavaScript-powered web pages. It embraces a world where DOM elements are constructed at runtime using scripts instead of at response-time by the server.
The most striking change of the post-HTML browser is that it assumes when you request a URL, like http://medium.com, that the response can be JavaScript.
Maybe the browser would do some kind of OPTIONS request dance, or the server responds with a special Content-Type, but somehow the server would know to optionally respond with only JavaScript.
To be perfectly clear on what this means, here’s an example:
$ curl -H "Accept-Type: application/javascript-page" https://medium.com
(function() { /* do application stuff */ })();A few (but not all) consequences of ditching HTML as a first-class response type:
- The DOM is ready immediately — to the JavaScript code, the world looks like an empty <html /> tag.
- The page’s JavaScript is the only manager of network resources. If you want to load more code, or images, or whatever, the JavaScript explicitly handles it.
- There is no more CSS. There’s already a movement in the React community to keep style-related code in JavaScript, and the post-HTML browser would optimize for “inline” styles created at runtime.
- The application JavaScript now has to deal with setting <head> tag information like <title> and <meta>.
My intuition is that this would provide at least the same, if not better, performance for JavaScript-heavy webpages, and strictly reduce the complexity of how the developer deals with server responses, assets loading, and styling.
Another evolution of the post-HTML browser is to disable the DOM completely and delegate rendering to an empty WebGL canvas. Maybe we can call this the “post-DOM” browser. This would have more drastic effects on search engine discoverability and screen readers, but may be the right choice for some games and very advanced web apps.
I started thinking about this because we often jump through hoops to build JavaScript-based web applications. If you choose to think of the hoops as legacy artifacts, you wonder what a world without the hoops looks like. So here’s to that.
