It’s fascinating to note the turns HTML/CSS and JS #frameworks took

All abstractions becoming popular at around the same time

But while #HTML / #CSS frameworks peaked after the market had been flooded and the specs accommodated everyone’s wishes

#JS frameworks, fewer in number, ballooned into ecosystems, and sustain themselves by partially self-inflicted complexity

“The burden of proof is on you, frontend framework stans, not the vanilla Web!”—thank you, @jaredwhite

https://www.spicyweb.dev/the-great-gaslighting-of-the-js-age/

The Great Gaslighting of the JavaScript Era

The age of frontend JavaScript frameworks eating the web world didn’t happen simply because some well-meaning developers found great DX. It happened because we were fed a line.

The Spicy Web

@j9t @jaredwhite

You have given me an opportunity to again bemoan the death of tables. HTML 2 tables were so powerful. I’d like to blame CSS but probably coded sites (vs static HTML documents) were at least as important.

@j9t @jaredwhite

Many have written similar articles when mature working languages become unfashionable. (I remember when creaky, dull, geriatric Java was unbearably cool.)

Those “darn-Rust” articles also are significantly correct. There is a lot of fashion in everything.

@jgordon @j9t @jaredwhite The CSS folks finally stopped making excuses and specified "grid layout", which lets you say "render this as if it was a table tag"; this is now supported pretty much everywhere. But it's been a long slog to get there (in part because everyone's worst enemy, Internet Explorer, implemented only an incomplete, early draft version of the spec for years).
@rst @j9t @jaredwhite thanks Robert, I understand better now.
@j9t thankyou!.gif I have a too much of an impostor syndrome to say this. I have worked on a web application with full state machine and event driven UI and whatnot when a simple <form> should have done the trick.

@jonr @j9t Not only would it have done the trick. The <form> is vastly superior because the <form> is semantic. A human, machine, or any combination of them working together can *interpret* it to interact with it how they need to.

All they can do with the React application garbage is execute it.

@j9t @jaredwhite I have also started to think that there is a baked in sense of disposability in these conversations. It doesn’t matter if React isn’t going to last forever because of course everything on the web gets totally rewritten every 2 years, and maybe, more insidiously, that they will have moved on, making it someone else’s problem. This is easily disproven by talking to anyone who’s been doing it for 10+ years, but those aren’t the React stans
@j9t @jaredwhite I think the fact that heavy JS frontends discriminate against and exclude users of less powered devices, is a very important point to make that is not talked about enough.

Tech doesn't exist in a vaccum and the implications of development trends aren't just technical in nature.

@jec @jaredwhite @j9t Not just less-powered devices but users who cannot use what most of us consider to be a standard device.

I'm thinking of people using screen readers, where the big JS frameworks just fail.

@j9t I appreciate the share!

"self-inflicted complexity"

Oh my, yes… 😄 This is a problem which often creeps up in various arenas of computing, not just frontend web of course. As the years go by, you start to develop a keen sense for when a solution being presented to you isn't really a "solution" on the whole, it's simply another layer of complexity to patch issues with the previous layer of complexity. 🤪

@j9t @jaredwhite One factor in the spread of these trends: large companies spending $tens of millions to promote them -- FB/Meta for React, Google for Angular, etc. Which is an example of a pattern that goes back much farther (Sun and IBM pushing EJB2, for example -- another framework bad enough that it was deliberately killed by incompatible rewrite).

Which is why some of us aren't rushing pell-mell to adopt Kubernetes. (Maybe you need a container orchestrator, but do you need *this* one?)

@j9t @jaredwhite I feel like "partially self-inflicted complexity" is a good way to describe deployment pipelines and infrastructure-as-code, too.