Wed Oct 19 2016

There are two reasons JavaScript gets a lot of hate. The first is that Brendan Eich was famously given just 10 days to design the language, and then was denied any opportunity to make backwards-incompatible improvements. He pled with Netscape to let him release fixes, to no avail, for their fear of breaking existing websites. Poor guy - imagine if one of your most hurried high school essays became the Bible, and you were never allowed to publish a second edition - only to add chapters.

Secondly, the Document Object Model is wonky, unusual, and inconsistent. Much of what JavaScript has historically been used for is simply interacting with DOM APIs, so there is a widespread and understandable confusion as to which terrible developer experiences are the fault of JavaScript, and which of the DOM.

However, there is good news. As MVC-influenced rendering replaced the old imperative logic of jQuery apps, I noticed that we were interacting with the DOM less and less. By interpolating templates rather than reading and writing DOM elements, we can limit our usage of DOM APIs drastically, meaning that most of our application code is pure unadulterated JavaScript. It's becoming clearer what's JS and what's DOM.

A related trend is server-side JavaScript. As we explore ways to run our browser applications on the server, it has become not only convenient but absolutely necessary to limit our use of the DOM. I predict that the current trend of implementing a virtual DOM to accomplish this will not last. Rather, I envision that the winning solutions will simply generate a string of HTML code, inserting it into a mounting point via the DOM in the browser, and via simple string manipulation on the server. By limiting the use of DOM APIs to event handlers, I find that universal rendering comes practically for free. You never need to run event handlers on the server, because your state is predetermined, and you never need to talk to the DOM outside of event handlers in the browser.

These advancements, in my opinion, are what have caused a surge of interest in functional JS. When you don't need to (or can't) interact with the DOM, you can write pure functions, and focus on exploring the power (and the pitfalls) of the language. And if I haven't made this clear already: JavaScript, written well, is a much nicer tool than the DOM.

The point is, my relationship with the DOM as a front end developer has never been more distant, and I couldn't be happier about it. But there is still much work to be done. View frameworks that depend on virtual DOM implementations, like Vue and React, are overkill, and the development toolkits are intimidating to newcomers and frustrating to old timers. The key is not to reimplement the DOM, it's to stop using it except when absolutely necessary. I have confidence that one day soon a tiny framework - just 2 or 3 kilobytes - will present a solution that offers an approach to client side rendering so simplified and functional that server side rendering will come practically for free.

Update 11/21/16

I've published the tiny framework I hinted at above. It's called Oat, and definitely feels more React flavored, whereas my previous attempts were more angularish. Have a look: npmjs.com/package/oat.