React was frontend's introduction to Big Lies. The React team themselves were talking a book they didn't fully understand (else Pete Hunt would never have been able to get on stage and say "it works like game engine!" with a straight face), and were serially unwilling to tell the full story as they knew it.

So the implausible proposition that a system that *obviously* doubled up work and didn't defend against layout thrashing would somehow be "faster" was projected and uncritically accepted.

WHY was it so uncritically accepted? JSX + weekend projects.

The promise of not having to think about how data and UI interact over time, wrapped in nice-looking forks of HTML and JS syntax, meant that the 1-10 hour project got "simpler" (assuming you ignore the hundreds of MB of NPM crap lugged in tow). Nevermind that serious teams were reliably finding themselves neck-deep in perf remediation quicksand almost as soon React got popular.

So the lie curdled: you weren't holding it right.

It was accelerated by people who sold all of this on the back of "better UX". And that's still the right yardstick: does this technology, in general, lead to better user experiences?

Obviously not. The less React (and Angular, etc.) there is in your stack, the better the UX is for *most* types of products, *most* of the time. Not a hard and fast rule, but a useful proposition to work through to understand a specific case.

The (narrowly defined) success of React spawned many imitators that rolled out the same playbook: active denial and suppression of critical engineering discussion, heavy marketing, and bloated, slow products in their wake (looking at you, Apollo). That this axis of untruth has condensed into Next.js and marketing by Vercel about speed should teach us a lot of lessons; one that I take now is that lies spread without active opposition, and that I was too quiet. I knew better; and yet.
Anyway, you might look back on Frontend's Lost Decade and ask _"who were the influencers that seemed willing to go along with this?"_. Your regular Wes's and Addys and Maltes and Theos and Kent Cs. They all had their reasons, and each undoubtedly expressed mild reservations at various points, but none of them told the truth reliably enough to counter the overwhelming marketing behind the lie. And that's why you should never trust them now.
@slightlyoff anyone who pushed CSS-in-JS should immediately be disqualified. One smaller lie hidden in the swamp of other ones.
@sangster Fundamentally disqualifying without some sort of public apology letter (and I haven't seen any yet).
@sangster @slightlyoff I like the idea of web components but the implementation?
@GuillaumeRossolini @sangster @slightlyoff What about the implementation do you not like?
@hasanhaja @sangster @slightlyoff bundling CSS, JS and HTML in the same file doesn’t feel great, but maybe I just don’t know enough

@GuillaumeRossolini @sangster @slightlyoff You don't have to and what you put in there largely depends on what you want your component to be exactly. It can range from super simple ones that progressively enhances some existing markup to fully self-contained elements with its own markup, state and styles. The "range" part is the most interesting thing to me, because that means you can use as much or as little as you need.

What kind of things have you wanted to build with web components?

@hasanhaja small stuff admittedly, to get the hang of them

For example a checkbox that reuses its third state to cycle a new behavior while clicking: checked yes, checked no, undefined

@hasanhaja @GuillaumeRossolini @slightlyoff Etsy is working toward having the next version of its design toolkit built with Web Components, in large part to ensure that we can use it more easily in Mustache rendered by the server and also with our Preact apps.

Definitely proving to be more complex than we had originally expected as we sort through the nitty-gritty implementation details of really making this work for more complex components.

@slightlyoff I think part of the issue is that it’s a very compelling abstraction. Unfortunately, it’s a faulty abstraction. It presents a model that’s too divergent from how the web actually works.

@slightlyoff

"...lies spread without active opposition, and that I was too quiet. I knew better; and yet."

This is hitting me hard right now.

@slightlyoff the ‘time to first demo’ (TTFD) culture that emerged with hackathons and accelerators in the early teens is part of all this
@johnallsopp @slightlyoff we keep repeating the pattern: the mvp is easy, the long term maintenance is not. But by the time people realise that, they are beyond the point of no return in the investment cycle. Logically they should eject, but it turns out budget cycles aren't logical.
@slightlyoff I resisted initially. I wanted a better Knockout JS back then. But when popularity takes over job market, it felt like fighting upstream. OTOH Solid js took some of those ideas and improved it which now I feel my gut instinct back then was right - KO observables (rebranded as Signals) was a good idea.
@slightlyoff And when DOM parts and Signals land into tbe browser, then we can remove more JS view libraries for a lot of cases.
@slightlyoff I feel vindicated. React has never sat well with me, even though I use it all the time for work. Trying to cram an innately stateful system into an immutable, functional paradigm felt very much like the wrong tool for the job. Rebuilding and reconciling state changes seemed like a roundabout and poorly-scaling way of doing updates. And don't get me started on hooks. But hey, the entire industry was going mad for React so surely I was just being contrarian, right?