A future without JavaScript

A while ago I came across an article indicating that Google was planning to switch to using the Canvas API for Google Docs. This let to some contemplation as to why Google is doing this and what this could mean for the future of the web.

A short re-cap of the current state of the web. Webpages are writing in HTML, JavaScript, and CSS. HTML is parsed into the Document Object Model or DOM, which is modified by JavaScript, and rendered by the browser using Cascading Style Sheets or CSS to instruct to renderer how to display the end result to the user. For a long time programming on the web meant you had no other choice then to use HTML, JS, and CSS¹. The Canvas API Google Docs is switching to has been around since 2007². It allows for directly drawing graphics, including text, without going through the DOM, in a manner which is very much like programming desktop or mobile applications.

So why have we been using the DOM? The DOM was originally intended to display documents. It wasn’t really intended to allow for complex applications like WYSIWYG editors. For one updating the DOM is rather slow, although frameworks like Angular, React, and Vue.js are able to significantly optimize (effectively minimize changes to) the DOM. Another problem is that web standards don’t specify, to the pixel level, how the DOM should be rendered. This results in (usually small) rendering differences between different browsers. Not a problem for a blog post, but not ideal if you want the on-screen representation match exactly the on-paper result.

Why switch to Canvas? I am not sure what Google’s motives are exactly. But I guess there are two reasons. First, Canvas has been maturing over the past 14 years, to a point, I assume, that it is now very stable, supported in all browsers, and close to as fast as it can get. Second is the introduction of WebAssembly in 2019. WebAssembly allows programs to be written in any programming language and the compiled to a bytecode format, very similar to the one underpinning Java or .NET, to then be converted to native code by the browser. How does WebAssemly help the adoption of Canvas? Because, although the DOM is slow, rending complex layouts using JavaScript and Canvas is probably even slower. If Google would combine WebAssembly and Canvas, not sure they will, but if they would, that would provide the performance necessary for Google Docs.

But why now? Well, the only major browser not supporting WebAssembly is Internet Explorer³. Now that Microsoft is sunsetting IE⁴ the time is right to start using WebAssembly.

This brings me to the title of this post, with the combination of WebAssembly and Canvas it is now possible to write web applications without HTML, CSS, or JavaScript. Well, not entirely without JavaScript, because WebAssembly cannot interact with Canvas, or any other API for that matter, directly. For now, JavaScript code is necessary to load the WebAssembly and to provide the glue to interface with other APIs. But that can be achieved using a standard library. Allowing developers to write the application proper entirely in C# or Kotlin⁵!

Will the future be a web without HTML, JavaScript, and CSS, instead running on WebAssembly and Canvas? It definitely possible. WebAssembly is not without its problems⁶, but given some time to mature, and for compilers, libraries, and frameworks to grow, it definitely an interesting tool in the kit of a web developer.