JavaScript Frameworks

Right, I am not about to say anything that has not already been said better by someone else, but I still feel like I need to sum up my thoughts on this, so here goes.

Javascript Frameworks bug me!

I haven't ever worked on super duper fancy SPA projects. Just good ol' fashioned web apps where full page reloads start to become too inflexible, so we need some partial page reloading instead.

Back when I started out as a fresh young webdev, we used JQuery for AJAX and maybe JQueryUI for some snazzy looking components like fancier multi-selects and modal dialogs. Great! All I needed.

At one point, we started needing something that held a bit more state, and managing that with random JavaScript and sprinkles of JQuery became a hassle.

Enter: React! Alright, uni-directional dataflow, component keeps and manages own state, packaged into a component that we can strap into HTML and then it lives its own life. Cool.

Or so we thought. Suddenly, we were in the npm soup, where every time you sneeze, you need to install a new third party library, and then come the inconsistencies.

Shit, okay, so we start using TypeScript, because then at least the compiler can help find inconsistencies when we update libraries.

But then we need special handling for .tsx files, because of course, React isn't just JavaScript, no, it mixes HTML markup into the language.

What a mess, so we get babel, and we get webpack, and we cry about it, and finally it works. Well, it takes about a full minute to build our shitty TypeScript into some garbage, huge JS bundle that the browser can understand.

6 months in, and we're starting to wonder. There must be a better way. And sure enough, when we started, webpack was "the future of build tools", and since then, 600 new ones have come along, and noone knows which one to use now.

Volatile!

The JS ecosystem is out of control. Even the established tools/frameworks/libraries update with breaking changes multiple times a year. There is no stability.

The React we wrote back then essentially needs to be rewritten! Turns out class-based components were a bad idea. But that was all we had back then. Rewrite. Turns out the "Flux/Redux/fluxxybuxxy" whatever nonsense also turned out to be a cult religion, rather than a reasonable design pattern.

How is anyone supposed to keep track? JS used to be something you springled on top of your web pages. Now it is a whole new system that needs to be learned and maybe you even need to split your team into two, so you don't have to manage the mental load of all that.

Okay, okay, calm down

I've tried a handful of these frameworks. React, BackboneJS, Ember, etc. All come with complexities and are very opinionated. They all want to do their own thing. None of them care about web standards. Seems to be the goal to try to replace what is already there. Ignore markup, HTTP, and browser functionality, and instead do everything in JS. Everything, you say? Yeah, we now have NodeJS, so you can run the server side code in JS as well 🤮

And sure, some say that it is worth it, because then you only need to master one language and use it anywhere, and I can kinda see that. But JavaScript just doesn't have answers to everything. Once you start down the road of having a thick JavaScript client as your front end, you suddenly end up fighting the browser instead of leaning on it. Having to manually push URL state for instance. And then suddenly the front end is too slow, so you want to add the oh so fancy SSR... SSR, which is short for Server-Side Rendering, which is - drumroll please - exactly what you were doing with plain markup before you started with the JavaScript nonsense. So we've come full circle, and we have this crazy JavaScript beast, which noone can control.

I am no expert in either JS framework. I simply didn't have the time or inclination to study them in detail. So take my words with a grain of salt. I may not know what I'm talking about. But seriously: There must be a simpler solution!

Then HTMX came along

So based on my moaning above, you might imagine, that I was pretty excited to hear about HTMX. HTMX is basically a small JS lib that you plug in to your browser, and then you can do partial page reload using just attributes on your HTML markup. No need for all of the JavaScript. It works surprisingly well.

HTMX is not the answer to all of the questions you would want to answer with JavaScript, but it certainly solves all of the JQuery AJAX spaghetti we used to write back in the day. And as a cherry on top, since it lets you avoid writing JavaScript, you also do not need weird and time consuming build commands and a million depencies. This blog is hosted on netlify, and to setup automatic deployments with github actions, I needed to install the Netlify CLI, which is a simple npm install netlify-cli which then installs 1000+ different libraries 😳

HTMX is just a single self-contained script. Plug it in and forget about it. Update it if there are bugs. You're done.

As I said, it doesn't answer all questions, but that is okay. Use it for what it is good at, and if you need something more, you can add something else as and when you need it.

Components though?

Right. Partial page reloads are one thing, but another thing that the fancy JS Frameworks provide are reusable components. Back when I first heard of React, I was already looking around to find what options were available for building reusable components for the web, so I could keep my code organized when building stuff like web-apps ands SPAs (Single-Page Applications). I read about Web Components, which sounded like just the right thing, although the spec wasn't at all ready, and so React had room to move in and become the defacto standard for component-based web work.

Since then, the Web Components spec has become production ready. It is not as sexy or succinct as React has become, which is a shame, but the fact that I can write components without having to react for NPM, build toolchains, thousands of random libraries, etc. is very appealing. I have yet to try actually writing any components though. I found that many places where we used React on projects, we were much better of just using plan HTML and maybe HTMX when necessary. So components have taken a back seat for now. But once the need arises, I will reach for the web standards instead.

Also, since I am finding myself using Dotnet and Razor more and more, I am spoiled with other choices. Razor has component systems as well, so I can write my components in type-safe Razor files, and Dotnet will compile than into HTML when needed. So I guess we'll see when I'll actually need web components.

All this is to say that all of this JavaScript explosion just seems completely unnecessary and disruptive to me.

The industry and the community

Apart from my own distaste for JavaScript is the fact that these tools from tech giants have too much power of the community and the industry!

I see junior developers struggling with React and becoming utterly despaired, because they thing this is what Web Development is about.

It isn't though. And all of this JavaScript nonsense shouldn't be their first steps into Web Development. Junior developers ought to focus on leaning HTML, HTTP, and CSS well. Then they will find that much of Web Development is elegant and simple, and that JavaScript should be used sparingly. No sense making things harder than they need to be.

To wrap up, I want to add that a big part of me realizing these things have been due to listening to smart people in the community. Tech companies, Job listings, Courses, Conferences, etc. all push these JS Hype trains, because there seems to be money in it, but the people who actually have hands on and work with the tools will often share similar experiences to what I've been sharing here. They're not hard to find on social networks like Mastodon. The Hachyderm server in particular seems to have a lot of these great people. Go find them and consider what they have to share.

And please apply critical thinking before buying into JavaScript Frameworks ❤️