Recently i read the VUE-documentation about client side rendering, which is considered to be slower than server side renedering:

...because the browser will receive a largely empty HTML page, and has to wait until the JavaScript is loaded before rendering anything.

This is commonly agreed, but is it really true?

When you read this page, what do you see? Is this HTML? No! What you see is the graphical representation of what we call the "DOM tree", the internal database that resides in your browser. HTML is just one way to tell the browser, how to create the DOM tree.

But wait, is it really HTML that defines the composition?

No, not really. When Tim Berners-Lee invented HTML, the computers at the CERN this days could not display colors at all. They had this handy "green on black" screens, you all know from the film "the matrix", so they did not use colors. That is the reason you can set a text to "BOLD" or ITALIC, but not to "RED" with HTML. It is a child of the late 80th and hasn't changed much since then. The capabilities of HTML to represent more than just plain text are fairly limited.

Setting up the DOM

What sets up a page content is HTML and CSS, and the process those two work together is fairly complex. As CSS changes the behavoir of the machine that "renders" HTML elements, a browser first has to load the CSS definitions before he can start to do anything. And as the processs to determine, which CSS definition is applicable to a single element is fairly a complex and painfull work, it is just a wonder that this still is recognized as "fast". Modern browsers are absolute great pieces of software to keet track of the process and deliver a smooth user experience anyway.

The common belive of the "fast HTML pages" completely turns out to be a fairy tale, if you create multi page applications with "Hyperlinks". This was initially the core concept of the WWW, but also a reason to use Javascript: if the page needs a complete page reload to jump from one content to another, it is nothing users would accept today.

HTML is still the standard

But anyway, static HTML+CSS is a common way to deliver web content, and from a security perspective, server side rendering has big advantages. But that is not our focus here, we are talking about speed and user experience. And most pages will have some Javascript anyway, at least to perform some page updates.

Sure, the user experience will be bad if a page stops rendering to wait for a some content or Javascript to be loaded, but this is the disadvantage of using two different rendering engines, not a general constrain. If a page was purely built with Javascript, the user does not see any delay at all.

Talking about Rendering engines: Would it be possible to create your own "Rendering engine"? It is not only possible, is is fairly simple, as the HTML-DOM-Api exposes all the possiblilities of HTML+CSS to Javascript. And after the "Browser war", the Api of all modern browsers is mostly identical. From that perspective, using HTML files is just a detour. Most markdown parsers do exactly this, they get some "content" and call the appropriate api functions to "render" the content.

Using stateless programming on a stateful DOM

One reason for slow page loads is the size of the downloaded files, mainly caused by external libraries to be loaded. Some file types like images can be loaded delayed, but the main scripts used to render the page have to be loaded before. So it is very important to have this modules as small as possible.

So, let´s see, what is "state of the art" today? There are many approaches out today to help you to build better web pages. The most common frameworks like React and Vue rely on an external state logic. It is common sense, that it is necessary to have some logic to control "state changes" on a web page to reduce the number of unnecessary transactions of the page.

This was true, if the DOM was completely statles, but in fact it is not: the DOM is a state machine. Each element on screen is represented by a DOM element, that know precisely what state the element has. And browsers are extremely good at maintaining state changes. Even complex interactions on the DOM are hidden from the user to provide a smooth experience.

So, if the browser does all this, why do we need a second machine that does the same? Truth is, that functional programming used to control a state machine is not the best Idea you can have. Im not talking about possible advantages of functional vs object oriented vs procedural programming, which is another topic. Functional programming has - at least for complex applications - big advantages. But to control the DOM smoothly, you may need things like a "virtual DOM" to use it. And many tasks of websites like reacting on a button press are not very complex. This is easily done with event functions like "onClick". So, you get a big overhead to do things, that otherwise would be easy. Or, to say with other words: some frameworks solve problems that you would not have without them.

New approaches to web programming

There are many libraries and frameworks that try to change the roles like Svelte, that creates precompiled JS code from a source, which is made of a melange of HTML and JS. Finally you have the choice to run your code on server- oder client side.

About two years ago I tried to find out, if you can create web pages without HTML at all, and the results where pretty amazing. There is a free library on github called the Document Makeup Library DML that is mainly a wrapper to the HTML-DOM-API. This little piece of code allows to create full featured web applications relatively fast, the introduction page is a good example of what is possible. There are some more examples on dev.to.

If you don´t want to dig deep and like just a quick intro, you can check out a demo, that implements the core routines in only some lines of code. I total you get a complete responsive calculator application in just 61 lines of javascript without any html and no external library. Direct Dom Programming can be extremely compact.

Using the DOM as a state buffer

Creating HTML elements directly with the DOM-api gives you full access to the DOM tree without id´s or lengthy "getElementBy..." calls. An element created from withing Javascript gives you a direct reference to the DOM tree:

let el = document.createElement(typ)

So, if you store the reference in a variable, you can directly access the complete state of an element, including screen position, content etc.

el.style.color = "red"

You can even store own properties in the element for later access.

el.myProperty1 = "remember me";
el.myProperty2 = 200;

The only thing that might be a bit tricky is to find out, which CSS rules are actually used for the element.

Creating elements from within Javascript gives you another big advantage: If you create an object inside a function or a class object, the element reference is only know to the creating parent and is not exposed globally. You gain the power or "encapsulation". If you create elements within a javascript Class, the DOM-elements are bound to the Class Objects, which have their own local namespace. So you will avoid any namespace conflicts.

Long story short

There are many cases where delivering HTML will be the solution of choice, and the security advatages of severside rendering are undisputed. But not using HTML may give you some unexpected new options to create web applications.

There are simple and fast solutions to handle state changes in all modern programming languanges. They have been used and tested for a long time and that are perfectly applicable to web programming. Using getters and setters is the most simple solution to let a state change show up in a DOM element, that was created by and is bound to a Javascipt objcet.

The DML-Library has already proven, that you also can use complex arrangements of elements in a way very similar to the use of web components, but without the overhead. I found that web development generally speeds up very much. So, it´s really worth a try to build a web without HTML.