Decoupling Web Application Eventing from the DOM

Jerng — Wed, 04 Sep 2019 17:56:18 +0000

Sometimes I think, I write things which make no sense at all. Then I frame them up for farther consideration.

TL;DR: Can you guys tell me about programs which:

implement "events" and "event listeners" ...

... on web clients... (not servers)

... outside of the the DOM (events are not attached to DOM elements)

I just found a bug in common web applications. This has been bugging me for some time, and I'm relieved to have nailed it finally (I think). Caveat emptor: this is an architectural bug that is expansive throughout the web application ecosystem, so it may not be easily viewed as a bug.

The DOM is supposed to be a document, not a business processor. But for quite a few years now, people have been using DOM events & event-handlers as business processors, instead of as mere documents. This has royally fucked up the separation of concerns between the DOM tree, Web Application APIs (Javascript), and Rendering (CSS, etc.).

It just so happens that usually, the only place to plant event listeners, and the only place to trigger events, is on DOM elements. So what happened is that in pursuit of writing event-driven business processes into code, people have been writing event-driven business processes into the DOM.

The data structure of a web application is NOT supposed to depend on a DOM tree. Therefore close-coupling between {data models in a web application} (read in 2019 as "stores"), and {specific node trees in a DOM} is an anti-pattern.

But isn't the DOM supposed to mediate such user-interface actions as receiving input from the user, and sending feedback to the user, you might ask? Yes, of course, these can be modelled as events, and the DOM provides us data structures pertaining to those events, as well as ways to operate on those structures (listeners).

But that does NOT mean that the DOM is also supposed to handle traffic control for events throughout an entire web application. A web application should have an eventable control centre which lies OUTSIDE the DOM. (That is, outside any light, shadow, or virtual DOM, in case it wasn't clear). We generally know how to do this on the server, since NodeJS lit the rage on this. But web applications are not always supposed to run on the server - often times we want a web application to run robustly on the client side, and to depend on servers only for federated data stores. So how do we go about writing web application CLIENTS that have EVENT-driven traffic control OUTSIDE the DOM?

With that in mind, I searched for implementations of event listeners outside the DOM, and was pointed to the Reactor pattern by this thread.

I look forward to examining it more closely, perhaps with your input.

My Limited Experiences in Machine Computation / FFWD: Web Dev in 2019

Jerng — Tue, 03 Sep 2019 19:39:45 +0000

Past

In the 1990s, I used to play games on a monochrome XT. It also ran QBasic, but I never learnt how to use that properly. I first got involved in website development in secondary school, on voluntary projects.

In the summer of 2004, if memory serves me right, I developed websites industrially at an internship. This was a mix of design and development work, involving HTML, CSS, and Flash/ActionScript. We used Windows machines.

In 2006, I learnt how to use spreadsheets at a management consulting firm. In 2007, I learnt how to write scripts in Excel.

In early 2009 I found myself helping an entrepreneur to assemble, from untrained talent, a small web development product, in CakePHP on LAMP, and jQuery. Here I also learnt how to use Vim, VirtualBox, and SSH.

In 2012, I took some time off to study Git, MongoDB, Erlang, and Haskell, among other things. I developed a superficial understanding of these things, and their related fields of technology.

In 2014, I worked in a few software development operations, none of which could be called robust. I practiced quite a bit of responsive web design, and learnt how to work very superficially on cloud infrastructure.

In 2015, I got around to starting work on AWS.

It is now 2019. Web standards were a mess ten years ago, and they appear to remain a mess now, albeit somewhat cleaner.

Present

In preparation for web development at work, I've been reading to catch up on lost time.

In terms of separation of concerns, the dichotomy of HTML for content and CSS for presentation... seems to be continually abused.

Fortunately, with the advent of Custom Elements v1, we can now officially rant at people who redefine vanilla HTML elements to do absurdly irrelevant things - not that this is going to stop everyone from trying to distort the semantics of the given tags.

There remains no standard [data storage model] for [web applications].

There remains no standard [application architecture] for [web applications].

In the debates on UX, web developers seem obsessed with web rendering performance, and little else.

In the debates on DX, web developers seem obsessed with workflow ergonomics, to the detriment of considerations on what the standards should be.

In short, little has changed. I look forward to reviewing this all tomorrow when I get back to work on it.

A Legalistic View

I accept that many people will not agree with me on the following point, and I think that's perfectly reasonable for them.

First and foremost, I think a web developer needs to forget about commercial concerns when embarking upon the selection of tools for developing a web site or a web application. The domain of web development is politically governed by commercial implementations of renderers, i.e. browser implementations - and the only thing holding that Mexican standoff in place is the good old W3C. When the limitations of browser implementations become the primary concern of web developers, it is then that web developers lose sight of the end-game... which is an eventual redundancy of such war and the eventual emergence of a boringly staid technology stack. However, given the way technology works, that's probably only going to happen when the stack has been tooled down to the molecules. So for the time being, I guess we're stuck in this decades long race to be first to grasp at infinitely durable design patterns.

That being said, I think that at this time I want to approach web development with a modular lens. A web development framework should bridge... the standard semantics of the media, with the availability of innovative programs that enable the standard media to do various things. I think an explicit plumbing skeleton which lets users plug in their preferred data store, state management rules, router, node differ, renderer, etc. is in order. (Poor old Project Ara comes to mind.) All of this should explicitly warn users of the framework, where and when standards endorsed architectural patterns are being either encouraged or denied.

DEV Community: Jerng

Decoupling Web Application Eventing from the DOM

My Limited Experiences in Machine Computation / FFWD: Web Dev in 2019

Past

Present

A Legalistic View