Cheating Entropy with Native Web Technologies

August 15, 2025

I have a number of old side projects which I occasionally have to revisit. The structure of these projects broadly falls under two categories:

  1. Ones I built with a mindset of having my starting point be the most basic, native web technology available. From that foundation, I enhanced functionality through layering on more sophisticated and experimental techniques, APIs, etc., where supported. All code was authored in vanilla HTML, CSS, and JavaScript.
  2. Ones I built with a mindset of having my starting point be abstractions of native web technology (frameworks, tooling, language sub/supersets).

When I open an old project like number two (described above), I find entropy staring me back in the face: library updates, breaking API changes, refactored mental models, and possible downright obsolescence. An incredible amount of effort will be required to make a simple change, test it, and get it live.

Conversely when I open an old project like number one (described above), I find myself relieved. A project authored in native web technologies, enhanced with an eye towards the future, with little or no tooling, leaves me facing few obstacles. Remove a couple shims that are no longer needed and that’s about it. Imagine that: you can remove code to update a project?

Source: Cheating Entropy with Native Web Technologies – Jim Nielsen’s Blog

Over the last 15 years or so, as web developers, we’ve made a significant investment in a particular approach to developing for the web. The reasons behind this trend toward framework-forward development paradigms often make sense.

But they come at a cost that sometimes we only recognise in hindsight. One of those costs is an impact on performance. But ironically, given one of the primary motivations for adopting this paradigm being developer experience, there are alsoserious negative impacts on developer experience through the need to maintain dependencies and continuously update the technology stack we rely on.

Here Jim Nelson reflects on some of those costs.