The front end community wants to wash its hands of the decade we lost

He doesn’t care about making a point to the world at large. He’s subtweeting some group of people and is hoping they read his long thread.

> It’s not perfect. I think we’ll find a better approach eventually, which is why I’m fine with the churn. The churn is part of the search for something better.

People have been building UIs for quite a while now; from before a large percentage of people reading this were born. It's not exactly a new thing. I have generally found building UIs a bit painful in any language, so sure, let's go find a better solution, I'm all for that.

But ... 2 weeks ago I took over a half-finished Go project that's been left to "bitrot" for almost 3 years after the previous developer took a different job. Updating the Go dependencies was pretty easy; updating from 1.4.3 to 1.8.9 and such; maybe 1 or 2 with major version bumps, which were minor incompatibilities. Even the usage of the now-deprecated github.com/golang/protobuf wasn't a big deal, and updating to use the new conventions was boring and unexciting, but fairly painless.

The frontend part ... yikes... Things need to be updated from 3.0.2 to 6.8.4 and nothing works if I update it. There are what seem like to be 500 releases in the meanwhile and a lot of changes to go through. It seems in those 3 years the entire world changed. I spent a day on this, and eventually resigned to just accepting the 100+ security vulnerabilities that npm install throws at me. Most, if not all, probably aren't a huge deal in a browser context, but still...

Certainly from my perspective, there seem to be some problems here. I just want to solve real-world problems and write code, not babysit my 1000+ dependencies for what is actually not a very complex project at all. Of course, you don't deal with any of this for new projects, but a 3 year jump really isn't that long of a period. Some churn is expected, but "yeah, maybe just throw a lot of it away and start from scratch"-kind of churn? Meh.

> It's the whole "THIS IS THE MOST AWESOME THING OF AWESOMENESS SINCE THE INVENTION OF AWESOMENESS!!!!" that kills me

I joined a project using node, npm and angular. Everybody said things like that; "this is so awesome", "JS is great", "never had so much fun".

I tried installing it and needed help at every step, "Oh right! We need to do this in our env because X and Y", "Oh, you missed a step, trust me, it's easier to nuke everything and start again now." I ended up with a 30+ step guide that nobody had documented before. We had a little less than 100 security vulnerabilities.

Almost every standup was an exercise in figuring out some strange problem with node or angular, sometimes several.

This team was definitely doing things poorly, but the unrelenting toxic positivity mixed with the "Rails and Django and Symfony all suck so bad" was hard to take, especially as we struggled to ship a really basic MVP.

> It's not just the gung ho "everything is awesome". There's also pushback against critique.

And the required "buy in", not only can't you critique, you must ALSO actively assert everything is great or you're not "part of the team".

Any team without a few, "I disagree but support the group" engineers on it, is probably in a bad way.

I'm at a startup that builds an e-comm platform. Currently on Next.js; evaluating Astro.

We're slowly coming to the realization that none of these platforms are either simpler or faster than what we could do with modern vanilla.

Some very basic things like show/hide images and blocks of text based on user selection require an obscene amount of code/complexity in React that in vanilla is just

  element.style.display = condition ? 'none' : 'block'

Bonus is that there's no need to think about component re-render. No need to think about hooks, callbacks, memos, effects, etc. A whole layer of complexity disappears.

From a performance perspective, there's no contest. Not only is the resultant JS more performant, having the content actually in HTML at download results in faster renders and time to interactive. Our stats show 90+% of our users are mobile so being fast and light are key parameters.

I think the author's point is that while HTML, JS, and CSS have been advancing, a generation of developers have been invested in React rather than learning the fully capable and often better underlying capabilities of modern browser platforms. There are many, many developers who have been trained in React + component frameworks with only a very cursory understanding of the underlying HTML, JS, and CSS.

Should any team use component libraries or roll vanilla? It depends on the objectives of each team. Often that tradeoff is time to market and future tech debt versus absolute performance. (I have not worked on a React project that didn't have massive tech debt not because of React itself, but the complexity ramp that arises with additional packages, dependencies, state management, and general lack of deep understanding of React's render model).

We still like Astro because it allows us the flexibility to use React (or Vue, or Svelte) in dollops where it makes sense.