I’ve effing had it with shoddy SPA Frontends and Projects that don’t get it!

Where ever I look, I run into developers who don’t seem to be able to handle the Web in its entirety. Either with the old-school ultra-fanatic „CSS Nazi“ camp that instantly leap into a hissy-fit whenever someone dares to use a frontend toolkit or – god forbid – a generic universal CSS API or the other side when some Java-klutz stuck in the mid-90ies starts building an SPA frontend but insists on handwiring everything and avoids the actual benefits of a VDOM SPA toolkit like some clueless 1980ies teenager doing his first steps in BASIC.

It’s frustrating and the resulting code can get really bad.

State is what it’s all about

Folks, please understand this fundamental fact: SPA/VDOM toolkits were invented for one reason, and just about one reason only: To offer a remedy to the lack of state in the Web! And yes, feasible reactivity to state is self-understood as a consequence. That’s the whole point.

STATE MANAGEMENT! LOOK IT UP!

Here’s the deal: State Management exists for a reason! And if you already have the rare and glorious benefit of building an entirely self-contained SPA product with a single catch-all toolkit and stack entirely under your control, why for heavens sake don’t you actually use the benefits provided with the Jamstack and the kit you’re using?!??

Here’s an example of how not to do things:

WTF is this? I mean, clearly the man – it is a man, I deleted his name from the versioning notations in the screenshot – is writing an SPA for the first time, in this case with Angular 11, and I’ve written enough borky n00by-code myself – like we all have – but if I’d be writing this it would be after the fifth line the latest that it would dawn on me that there must be a better way to do this. Especially if I’m building an SPA with well north of 70 components and all that comes with it and my imperative event-bus-wiring has long since turned into a completely unmanageable mess. Obviously. No?

Angular does not have state-management built in – which does surprise me but that’s what you get when you have enterprise people stuck in the 90ies building for the Web, I guess – but there are enough decent to good solutions out there that are installed in 10 seconds or less. And if you’re building an SPA that has more than 3 views, use one of them! Even if they have confusing and difficult to memorize names, like these ones for Angular:

shitty names or crappy CI design, but very useful

I’m sure some enterprise guys got a hard-on when they named „NGRX“, „NGxS“ and „RSM“. That’s probably part of the reason no one uses these. I’m not joking. We had to name Java objects „Pojo“ („Plain Old Java Object“) before people stopped using bloated EJBs. The Vue hippsters have Pinia, btw. Way cooler, in name at least. … 90ies Java package names *suck*, don’t they? But that’s a different story.

So, bottom line: Building a non-trivial SPA Frontend? Use state management!

Now excuse me while I tack exactly that on to an existing Angular SPA I’ve been tasked with cleaning up and getting under control.