But if I can get away with a static website that uses just HTML and CSS that is the baseline. And it has served me very well and produced very low (=zero) maintenance results.

They want the benefits of a browser with the capabilities of native code. At some point you have to ask yourself would it not just be easier to do this in a normal programming language.

The number of times I have senen frontend people pull in some frontend component from a library (say, for fancy select widgets) and then have to spend a bunch of time trying to fight the existing bugs in that... and then struggle to swap it out later on for another library with a distinct set of bugs...

UI is hard, so it's hard to have a general thing fit _your_ specific purposes nicely. This is why I think it's super valuable to wrap things you can't control easily. That way you both document what you _do_ use, can fix issues at a bit of a higher level, and can swap out the internals way more easily.

People fight back on me on this on so many projects (the most recent thing: "the LLM won't know about our special UI component" IT WILL! IT CAN READ THE CODE!), but then hit those moments of regrets and end up wrapping stuff anyways.

Especially annoying coming from people who talk about design systems. A base vocabulary is a real good way of enforcing a design system!

I mean this relatively lightly, I understand the qualms at a high level, and coming up with the right abstraction is a skill. I've just felt the burn too many times and have very little issue coming up with very limited abstractractions and relying on tech debt to get my wrapper components out into the world.

To note, it's "easier" if you don't really care outside of your specific and limited case.

Multi select is a perfect example: if you only ever need that component to work in your language on your specific list for the browser you personally use for the screen sizes you care about, it will be pretty easy.

Hell starts when you try to think beyond that: how does the JS component work in responsive for super small screens and super big screens ? do you handle touch and mouse and stuff in-between ? what about CJK ? Right to Left ? do you care if there is any very long entries in the list ? How do you handle previous selections ?

The more you start to care about the details or expand the range of what you're doing, the more you'll be pulling hairs if you try to handle them.

The native components won't be perfect either. Native devs will also be dwelling in that same hell as you, whether or not the native state is better will depend on how much they cared on their side.

This is a crutch that people lean on to not use the right thing and use what they’re familiar with. Start with the browser default and change when it doesn’t work in that case.

I think when you consider that the solutions sometimes may come with tradeoffs that cause problems that people like less than simply working around the first problem, it makes a lot more sense.

I don't think conferences, hype, corporate backing explain the continued success of React; they help but it's just not the full story. I don't think they explain the continued success of anything else, either; I find this to be a shallow and lazy dismissal in most cases. It's easy enough to find counter examples where none of these things, not conferences, hype, corporate backing, or whatever else you could think of, were enough to make something work. While these things definitely help keep something relevant, they can't do it alone.

In fact, in attempting to rationalize the success of React without acknowledging its strengths, I believe people have fundamentally reversed cause and effect. I think a lot of the continued success of React comes from people continuing to choose its set of tradeoffs over others even when they could tolerate risk. I think that conferences continue to be organized and books continue to be written because of its continued success.

The tech community on the Internet has largely matured enough to acknowledge why PHP was and is successful; yes, there are many objective issues with it even today, but it also has many strengths beyond just having existed for a long time, too. Do I think you should choose PHP for new projects, the way I might say for React? Well, no, not really, if I'm being honest. But, I think it was nice to see people grow up and acknowledge that actually, there were and are a lot of redeeming qualities to PHP, and what it did for a lot of people was pretty cool, fractals of bad design be damned. It'd be a shame to see this repeated again more for stuff like React and say, Go, just because it's not the dog in the race we wanted to see win. (And I would understand that position, because I fully understand why people like Svelte, or Rust. I just don't think there is a conspiracy, it's just that there isn't a free lunch here.)