Server Side Rendering(ish) with zero HTML

application/nd-javascript

application/nd-javascript

text/html

 application/binary

application/wasm

application/nd-javascript

• For many applications, we build executables whose core function is an interplay of generating DOM, responding to the user, and updating the DOM. Obeserve the distinct lack of HTML mentioned in the prior statement. Consider web application runtimes, such as

  react

  ,

  svelte

  ,

  solid

  , etc. These toolkits are for building applications--and ultimately, DOM nodes. Indeed, they can generate HTML, but that is an important secondary feature. HTML is side-effect of these frameworks' DOM CRUD. Their primary objective is to make application development easier by applying tools that result in a predictable & DX-friendly DOM tree. Thus, if we have established that our primary application toolkits excel at

  DOM-ops

  and handling user events, why is it then that we commonly burden ourselves with also generating HTML? Most senior web-devs have all heard of

  VirtualDOM

  by this point. Why is there no

  VirtualHTML

  (/s)? For server side rendering, why do we use DOM-first libraries, convert to HTML, then post-hydration, go right back to DOM? The answer is that we have to, not that we want to. Can we cut out the HTML middleman and operate with DOM from start to finish? HTML is wonderful DSL for documents, but for applications it is pure overhead. For applications, our community would likely operate on DOM directly if the browser would allow us. Imagine if all of the power backing browser's HTML engines were actually APIs that we could tap into at boot time!
• Efficiency. Thousands to millions of servers exist in the wild with the nearly sole purpose of generating HTML. If applications could actually be compiled to static artifacts, they could be served by CDNs only, with optional runtime enhancement at edge computing layers, which often already exists. Large layers of compute could be erased in web infrastructure.