Today I somehow ended up on Google's web.dev platform, which I'm assuming it's rather new. There is of course the possibility that I have been–or still am–living under a rock, when it comes to new web technologies. Something caught my attention–an article about using Service Workers and streams to deliver partial updates to a website:
"The key element of this solution is the usage of streams, which enables incremental creations and updates of data sources."
It's actually using the DEV.to website as a use-case, based on Ben Halpern's article here on DEV, from last year. In his piece, Ben is enthusiastically praising the "magic" of service workers to deliver on saving “terabytes of data” in network transfers. According to him, this approach enables the team at DEV to “ship many fewer bytes while also controlling the user experience with more precision.” To see the results–which are indeed very impressive–you only have to reload the page to his article, or this very article for that matter.
This architecture is known as the App Shell Model and it seems to be growing in popularity lately. It might in fact be the most innovative development in frontend web space since the dawn of AJAX and JSON. The basic idea is to deliver only a very minimal page structure in the initial request and then gradually deliver the rest via fragments or partials, while leveraging caching. So is this the most paradigm shifting web architecture since a decade ago? It does certainly have the potential. I'm a little skeptical regarding the use of the term "magic” though, as is the case in Ben Halpern’s article.
On Magic
Magic is not innovation, it's the opposite of it. Without getting too much into the metaphysics or the occult, I think we can agree that traditional magic works by creating illusions. And just in case we do want to get into metaphysics, even if for a little bit, there's a great 2003 Ted talk by philosopher and cognitive scientist Dan Dennett, called "The illusion of consciousness", which he starts by humorously explaining the difference between magic and real magic (spoiler: there isn't one):
"Real magic, in other words, refers to the magic that is not real, while the magic that it is real, that can actually be done, is not real magic."
Confused? I know I am. But don't worry, it's only because consciousness itself, or the mind, the self, however you want to call it, "is a bag of tricks", according to Dennett. In other words, it's an illusion. When something is truthful it's only because it appears to be so to our consciousness, and however truthful something appears to us depends on how convinced we feel about it.
But enough about magic. Let's not ruin it, shall we? Let's keep the magic alive. Back to service workers. My main concern is that saying it's "magic" will make it difficult for this technology to be properly understood. A certain technological breakthrough can be an actual innovation only if it's widely adopted. And for service workers to become widely adopted, they have to be properly understood by everybody, not just the most advanced and experienced engineers.
Slickness is Tedious
I remember being first introduced to AJAX (Asynchronous JavaScript And XML) in 2006 and even as I was a junior developer (by experience) I recall having clearly understood what it does–updating the page by doing HTTP calls in the background, without reloading the page. We call this a single-page application nowadays (or SPA–not an acronym which I'm very fond of, personally). And thinking at the past decade, I can't say that I'm convinced of anything being a major innovation in how websites and web applications are built and how they work.
There are of course several high profile Javascript frameworks, the language itself has been tremendously improved in terms of readability and maintenance, and several new html5 apis have been added, but to me it seems that the actual web UI looks pretty much the same as it did in the jQuery days, by which I mean about a decade ago. And if there are any actual innovations, those are mainly the domain of aesthetics, i.e. graphical design, such as SVG or WebFonts, and not performance or interaction.
While the aesthetics may or may not be important, as the visual impact can vary from one person to another, the performance impact is certainly the most important one to consider. When measuring the visual impact, there's a certain threshold above which the user interface becomes stable and subsequent updates are more or less redundant. There's a certain point where the application is slick enough and any amount of additional slickness is irrelevant, and it might even be tedious.
On the other hand, a performance update that can "magically" make the app load much master can have a dramatic effect for everyone who's using it. Improvements in performance can have near universal benefits, because it saves us time–we spend less time while waiting for an event to happen in the application (such as a page or an image to load). A performance benefit is like time regained, because the way time is perceived by our consciousness is shared across all of us, presumably.
Not Another Bag of Tricks
The “App Shell Model” architecture, as Ben Halpern has shown, sure seems to be the innovation which delivers on the performance gain. But the technology to implement it has been existing for a good while. As Ben also points out, streams have been around as long as the web itself, and also a server-push mechanism has been available in all major browsers for longer than a decade ago, namely the EventSource API, or server sent events. I have myself done a presentation about it just seven years ago.
In fact, the initial content-type of the events being sent through this API was application/x-dom-event-stream and have been later changed into the more generic text/event-stream type, according to this, so presumably the EventSource API has been designed for this purpose, as a mechanism which would accommodate streaming updates to the DOM from the server. Bearing in mind also that document fragments have also been existing since the dawn of time, you got yourself a complete server-push-to-dom-fragment architecture.
These days however, what counts as innovation is mostly determined by the big tech “innovators” in Silicon Valley and the innovation itself is usually permitted to happen only if it furthers an agenda of economic growth and corporate prosperity. Even if it does happen on the outside of the big tech corporations–and remember that the world needs massive corporations just as it needs small businesses, as Zuckerberg recently pointed out–the innovation is absorbed and marketed properly to maximise the potential of value delivery. But what does it matter, innovation is innovation regardless of where it comes from, when it does make it. Whether this particular innovation–the “App Shell Model” architecture (we might want to do something about this naming)–is the next AJAX remains to be determined, of course. Personally, I am quite enthusiastic at the prospect of yet again having an actual innovation in website and application building and not just another bag of tricks.
Top comments (6)
Nice post! I really appreciate the analysis building on my post.
Not strictly related to what you wrote, but to speak a bit to what comes to mind when I read this:
EV or DEV?
EV stands for Electric Vehicles
But DEV too was built on the shoulders of giants, that's true for everything :D
Thanks, I just read the full sentence again and I realized it had nothing to do with DEV 🤦🏿♂️ .
Once again, thanks.
I still believe UI/UX Research is innovation, though. Not the technology itself, but the body of knowledge.
Without doubt, we need to stand on the shoulder of giants, which have R&D teams.
I read everything. Nice!.
In addition, is that a typo on paragraph 10?