The Post-HTML Browser

Clay Allsopp
2 min readMay 17, 2015


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, 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"
(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.



Clay Allsopp