The Frontend Treadmill

I hear from the b/e people about containers, serverless, lambdas, ORMs, queues, schedulers, caches, pipelines (ok, I use these too), databases, API gateways. Oh, but it's podman now, not Docker. And they're moving everything off AWS to Azure. And there's three versions of the API my f/e needs to talk to still in production. And every micro-service depends on a different version of Node. Apart from the one that's in Ruby and the stuff from that department who only use .NET.

I don't believe this promised land of clarity, comfort and purity exists. It's just mess on both sides of the internet connection trying to solve different parts of the problem of turning user needs into money.

This leads to a loop of unrealistic optimism.

1. Library X promises to abstract everything away in an easy-to-use way

2. Devs adopt X and it makes work fast and fun.

3. The human element forces in tons of edge cases.

4. Devs hit the abstraction limit and start needing elaborate workarounds to do simple things.

5. Devs start looking for an abstraction that works and goes back to the first stage.

I'd note that a decent portion of this loop is powered by the explosion of FE devs. There were probably just a couple hundred thousand frontend people when Chrome launched in 2008 (and most of them were design guys rather than programmers). Today, there are millions and most of them have been programming for just a couple of years.

Devs (especially senior devs who make architecture/library decisions) and their managers need to realize that there is no panacea. Fast time to market followed by slowing development speed is expected. It seems like every blog brags how "we rewrote 80% of our app in 3 months" but seldom mentions that they are still at just 95% done 3 years later.

If you started with React in 2013, you'll still be using it 12 years later (11 years if you were using Vue). If you stuck with Redux, you'll still be using it 10 years later. If you used basically any of the abstractions layered on top of these basic libraries, you have probably been through several rewrites none much better than the previous.

The key is not abstracting too much. Repeat yourself just a little more and you'll find the edge cases easier to deal with and changing something basic in 5 files is easier and faster than trying to wade into a single very complex component and change something. You'll find that lots of those abstraction libraries you were using aren't actually buying you much at all.

I should also mention Typescript. Basic types are a great resource. When you are spending hours wrangling your complex type soup to fix something you know can be solved with just one simple change, this is an indicator your types are hurting your project. These types are almost always a reflection of your abstraction and indicate that you are abstracting too much. These types also indicate your code is highly polymorphic and will have terrible performance on modern JITs.

DRY is a means to an end rather than an end in itself.

Also been doing webdev for 20+ years now and I'm still very happy with the CHAMP stack.

CHAMP of course standing for: CSS, HTML, Apache, MySQL and PHP. As you can see, there's no J in CHAMP.

I have been doubting my choice in the past, because everybody was using (frontend) frameworks and the like and I'm just a social animal like everybody else. I'm happy I stuck with the stuff I already knew from around 2004, but I feel for all kinds of younger developers who got dragged into the trap.

- they're much harder to learn and understand than the callback hooks from class components

- The built in ones hide all the ways React is managing state for you behind obscure names that don't reflect how or when to use any of them

- The new-ish `use` built-in doesn't follow the same usage rules as the rest of them (you can use it in places you can't use the others)

- the stateful ones create side effects (unless you pretend that state is an argument), so they don't even follow an easy-to-grasp version of the functional paradigm

- they have strange quirks (like you basically have to write your component function to use its hooks before you render anything... so you can't early return)

- the mental model for how to put them together when you're writing custom ones is a little bit funky too.

- the early "advert" for them was that we could put all our domain knowledge together in one place, rather than spread about over multiple callbacks. Given that we usually need to interact with a couple of domains at a time, in time with component lifecycles, I think this makes the code harder to work with rather than easier

I know you mentioned a company-backed example, but bear in mind most open source libs are given away and maintained for free. After a certain point people move on, so basically what do you expect to happen.

I created and maintained a couple libraries for 5+ years and it didn't really help my career or life in any way - no job offers, didn't matter to interviewers, so why would I bother?