My first career language for writing software was JavaScript. Sure, I had used barebones HTML/CSS to start, then jumped into WordPress CMS with PHP. But what really did it for me was the world of possibilities for creating rich web applications with JS.

However, the industry was in a nascent state; it was possible to build these things, but was it practical? After all, dealing directly with event listeners and DOM manipulation was tedious. Not impossible, but an exercise in patience.

jQuery came along and sped up the developer workflow. It also introduced a lot of footguns if used improperly. But, it was a solution for its time, an abstraction to allow for more time and effort to be devoted to the application logic itself.

Fast-forward several years to the ascent of JS frameworks and libraries, also with their own new footguns. Angular was supposed to be the "V" in MVC. Then MVVM came along. Suddenly in addition to DOM reactivity there were tools for managing state, optimizing nearly every aspect of a build (which would've blown minds for anyone using JavaScript more than 10+ years ago), and rewiring your React application for extensive integrations without ejecting.

Now, with over a decade of hindsight, it's time to ask: is this all really necessary?

By now, many people have seen this presentation from David Guillot at DjangoCon 2022. To summarize, by moving from a React frontend to HTMX, they were able to decrease lines of code and complexity in a highly-reactive application. Normally the rule of thumb has been if you need a lot of snappy reactive behavior on a page, you need a lot of JavaScript loaded at once (and to be creative with loading/styling for the user experience). I've seen and worked on large apps that accept this tradeoff and implement this with varying degrees of success.

Other approaches are stacks such as Flavio Copes' idea of the AHA Stack, or the incredibly named GoTH Stack, and many other permutations. These feel closer to the mix-and-match approach and freedom in the spirit of early development depending on the type of application or site you're working on. Though you have more choices, you can select each tool to reduce complexity. And, as shown in the DjangoCon video, it's possible to use existing principles in an efficient, modern way.

Maybe it's a pattern in web development where we tend to over-complicate everything, without even realizing it. We lead with a conclusion when we haven't carefully considered the use case. The more logic in JavaScript I've added to the frontend, the less I like the outcome. It's almost Zen-like. What's the expression? The best code is no code at all? Same with JS. My perspective should be to deliver the least amount of JavaScript necessary to do the job and do it well. This is a hard concept to grasp when you've been adding on and npm installing everything under the sun into a kitchen-sink web app.

With years of exploration and experimentation, the industry has gained a better understanding of what these technologies can do, and what they maybe shouldn't try to do. And specifically in web development, there's been valuable lessons learned from both content sites and applications. Combined with the power of other lightweight tools, I'm finally seeing a case for using slim libraries like Alpine.js when you can re-evaluate what is really needed in your project.

One misconception outside the world of software is that complexity is better; somehow more "big-brained." Even on the developer experience side, I often hear "don't care about the developer experience, it's the user experience above all else." Ok, that may be well and good, but when you want to ship a new feature quickly, or maintain and evolve a rapidly growing product at scale? An ergonomic developer experience will allow those other things to flourish, and probably for a lot longer in the lifespan of a project.

Main thing is: you can start with complex ideas, but the real genius is stripping out the unnecessary complexity for the developer and the end user. The day we can start simplifying, the better off we'll be.