I developed a personal finance app "using the platform". The only JS is for push notifications (service worker registration). IMO the app still feels interactive, because modern CSS (e.g. toggle visibility on radio selection) and modern HTML features like dialog or details allows for some JS-like actions.
For one thing, I just genuinely think WebComponents are a badly designed API that is weird and hard to use (how many people are using WebComponents without at least Lit, if not something much bigger?), and React is a relatively well-designed library that isn't really that bloated. There's not really much of a point in trying to argue since this is inherently subjective and people with different values are going to irreconcilably disagree. But, if you don't respect that some people hold this position, we're not going to make any progress towards a consensus.
On the note of <dialog>, I recently tried to use <dialog> in a (React) application, and it did work pretty well, but I also found that in Firefox it is only practically possible to do a fade-in animation, not a fade-out one. That isn't really a critical issue for me, it is just an animation after all, but I find it unfortunate. I also find <dialog> to be a weirdly shaped API too: I don't really hate it, but I don't love it either. It feels awkward.
I find this implicit view that developers that, for example, prefer React over WebComponents are making a suboptimal choice to be rather condescending and not really in the spirit of trying to see things from the other side. Wouldn't you want to focus on the strongest arguments and not the weakest ones? Maybe you've literally never heard anyone complain about WebComponents or Shadow DOM, but if so, I find that surprising. Certainly here on HN, I've seen a fair bit of WebComponents hate.
I do, FWIW, realize that I've particularly focused on WebComponents, which this article doesn't actually name directly. But, I assume we're not talking about ditching React to implement our own component framework on top of the traditional DOM APIs, because that's what React already does...
> React is a relatively well-designed library that isn't really that bloated.
I am one of the people who irreconcilably disagree. I think svelte and solidjs are - obviously - technically superior. But it leaves the question of why react is still so popular. I think the biggest reason is all the non-technical aspects of react:
- They have excellent documentation. And have, from day 1.
- They produced videos, sample projects, and all sorts of "getting started" documentation.
- They ran react conferences, teaching everyone who would listen about "1 way data flows" and pretending like they invented FP.
The amount of hype around it made it really feel like the next big thing. Between the very well funded react team and the outside developer community, there was real momentum. People learned it in droves. Taught students. Built websites with it. When react's poor design choices caused issues (and there were a lot of issues), then you were blamed for holding it wrong. (Component classes, state, CSS, hooks, webpack and babel taking ages, big bundle sizes, slow re-renders, and so on.)
By the time the next generation of JS frameworks broke onto the scene, there was a collective moan from the community. "Oh no, not again - we just relearned how to make websites." React was the wave, and in its wake we all had Framework fatigue.
Software doesn't get popular without a lot of work by dedicated people. I really admire the work standards bodies do. But they rarely bother to take the time to produce documentation, videos, tutorials, starter projects, blogs and podcasts and all the rest of that work.
More like trying to explain to people who have only done imperative programming (and that also in JS of all languages) why a render function was necessary. The creator of React, Jordan Walke, was big into OCaml and one might even say he got some of the ideas of React through working in OCaml, so much so that he tried to bridge both by making ReasonML which is an alternative syntax for OCaml which has JSX and React bindings.
Yeah, there's a lot of people who have either forgotten or never knew that the context React came into was a world full of JQuery and AngularJS two-way bindings. I started my internet touching career having to work on that stuff, and boy, so much of it was a nightmare that just got endless workarounds heaped on top for basic performance issues, let alone other complications.
There really isn't anything in react that is inherently "bloated", most companies were indeed using it wrong, or at least in a naive way. Over-reliance on useEffects, re-render issues, non-memoized components etc. When used correctly, react 18 provides really fast web apps on whatever scale (small one pager app to massive enterprise apps).
> I am one of the people who irreconcilably disagree. I think svelte and solidjs are - obviously - technically superior.
I don't really think that React is necessarily the best possible library, but there is certainly more to a UI library than simply compiling out the need for diffing. For one thing, I find JSX to be a relatively unobtrusive addition to the language. It is implemented by a variety of things and is a pretty simple transform as far as things go; basically pure sugar, it's possible to avoid it if you want. It could be better designed than it is, but I think it's at least sufficiently general - it is feasible to say, use an alternate library with JSX, like Preact.
Svelte on the other hand by its nature just simply requires a more complicated compiler step to work and deliver on its promises. That's a trade-off. Whether you think it's worth it is up to you, but presenting it as an objectively technically superior design is disingenuous. Superior how? Runtime costs? Sure, but it does beg the question how much. Will a well-optimized Svelte app feel much better than a well-optimized React app?
> The amount of hype around it made it really feel like the next big thing.
We are a really long way away from the hype of React. I would argue that hype stopped carrying React a long time ago. Momentum? Sure, but if something was truly dramatically better, then I think it would have a fair shake at beating out React.
The problem is that the web isn't microbenchmarks and developer experience does matter to some degree, so the trade-offs that seem so good on paper don't always pan out.
I'm not a hater of Svelte. On paper, it is a very elegant idea. However, when I actually tried to use it, I genuinely came out feeling that it was simply not for me, and the benefits it has are not enticing enough for me to continue experimenting. My React apps are not particularly slow or bad at handling huge amounts of data. (One of my apps has no problem handling a file grid of over 1 million items, and in fact, I run into issues with browsers not being able to handle a large enough scroll area long before performance of my React code is a problem. That is good enough for me.)
I mean, prior to React the big Framework at the time was AngularJS 1 - a hellscape of two way data binding.
Talking about one-way data flows was an excellent way to speak to a lot of tortured souls at the time (who had just found out they were going to be forced to migrate their projects to something else anyway due to Google's absolutely insane "we're deprecating this, we'll have a replacement for it at... some point, good luck").
I don't think React pretended like they've invented FP, and I've always heard them be pretty open about FRP work existing in the past and them leaning on it.
> I just genuinely think WebComponents are a badly designed API that is weird and hard to use
This was exactly what sprang to mind as soon as I saw the title. I’ve been writing front-end code for over 25 years now, and exactly two things in that entire time have made me miserable enough to think about stopping: Internet Explorer 6 and web components. Every time I try to just “use the platform” it makes me miserable and I end up demotivated and stop working on whatever side project I chose to try again with. And I otherwise like the web platform! I’ve been building with it since there was nothing but the web platform. But web components kill my enthusiasm for it stone dead.
Even now in the age of agentic development, AI trips over all the same footguns in web components that humans do. It just seems like everybody involved has been adding to the standards with “yes, and…” without ever thinking about how it will be used by web developers in practice.
I don't know if that's idiomatic webcomponent or not but that looks unmaintainable, even for such a minimal component, imagine once it grows. It's not separating presentation from state and logic. querySelector need to match classes and elements in the markdown. Mutating textContent is going to run out of sync as soon as you have more than one event source doing the same. Those are all problems that React solve by separating state and only rendering in one path.
That's the best case scenario and already looks like crap. If that looks sane to you, I don't know what to say.
Make it have an initial count via attributes, sync it with the DOM so if the attribute changes the count resets, and make the JS property always match the attribute (and vice-versa) so it behaves sanely. You're in for a world of pain even for something as simple as this.
Plus they're not declarative: you will only make me use innerText-based updates by threatening me and my family.
Plus they only work with JS enabled, while I can use JSX in SSR.
I've worked extensively with Web Components. They suck.
Well for one thing, I don't find that to be particularly succinct or nice example. There's a lot going on there:
- HTML in a string. No syntax checks. If you interpolate it, you have to escape manually or you could create trivial XSS vulnerabilities. Your editor will probably not syntax highlight it, making it harder to tell when you break it.
- Manually formatted update logic that is redundant with the string. Not so bad here, but try formulating a practical large component.
- Completely ad-hoc state management, no reconciliation. Again, fine for Hello World, not fine after that.
Using raw WebComponents, your application has to care about all of this on its own and more. You can use templates and slots (which you should) but that makes this even messier IMO and brings back the split that React became famous for getting rid of. We left manual DOM reconciliation, ad-hoc data flow and non-reactive components that manually call a render routine at arbitrary points for a reason: it sucked. It made for buggier, harder to maintain code. It can be done, but usually any decent app will wind up encapsulating patterns into utilities that get reused. And... That's precisely why we want a good library. That's what I want, a library that packages up good reusable patterns for constructing UIs effectively.
And that's exactly my point, which is WebComponents or not, the solution is still basically the same, use libraries. Which begs the question: if I have to use Lit, what is the point of "using the platform"? What is WebComponents doing for me here that React wouldn't be? And in my case, I struggle to see it.
Interoperability? The old way of embedding external components works quite fine. Switching APIs where you pass a DOM node for something to mount into and get back an object with an API to one where you instantiate a component and communicate via properties and events feels like a strictly lateral move. I can't think of a condition where this would be particularly more convenient, but I can think of some where it is actually less. Next.
Isolation? Yes, WebComponents does add tools to provide better isolation between components. For some use cases this is a genuinely useful feature, although it also isn't without tradeoffs (I mean, the flexibility of having things be not isolated comes in clutch sometimes, it's hard to argue this.) But I use React primarily to construct components in an application, where I find this property more undesirable than desirable.
The one thing I thought could be cool with WebComponents is if you could build them in pure HTML when you only needed basic templating, but no: the design they went with always requires subclassing in JS AFAIK.
I could go on and get more specific, but I feel like people will pick everything I just said apart quite enough. I hope I'm at least able to make the case that:
- I do in fact, get the general gist of WebComponents.
> If you interpolate it, you have to escape manually
Well, for some definition of "manually".
If you have untrusted variables to interpolate, you can do
this.innerHTML = html`Hello ${name}!`
Where html is a function that escapes the variables.
The arguments brought forward against web components all seem to fall under "But it does not contain every functionality you want to use out of the box". Personally, I don't think browsers should provide more and more functionality, but rather a good base to build upon.
> Isolation? Yes, WebComponents does add tools to provide better isolation between components. For some use cases this is a genuinely useful feature, although it also isn't without tradeoffs
I hate the guts of every site that uses those. Shadow DOM makes the site hard to operate and fix programmatically from user end.
I mean, these days I can just throw an LLM at it so I don't care as much, but sometimes I want to still do things hands-on. Not to mention, Shadow DOM is often a difference between "simple userstyle/userscript that is allowed at work by security extensions" vs "requiring things that are banned on corporate-managed browser".
For starters, that it introduces weird special cases to DOM parsing and structure, thereby breaking .isEqualNode whenever <template> elements are present.
The current state of the platform has even been a blocker to standards folk when they want to add a shiny new thing, thus the absurd bloat of the specs.
For one, they can stop pretending that JS and the DOM are two completely separate entities, and lock the two working groups in a basement until they figure out a sane way to do reactivity, natively, that actually works.
I have stubbornly avoided React. When native WebComponents became a thing, I figured I'd try them out on a small internal site I maintain. It was very slow. In an effort to reduce a bit of duplicate code, my site when from loading instantly to having a noticeable load time. Having to employ tricks to try and optimize and speed up the most basic implementation of a built-in feature seemed like the wrong move, so I ditched them all together and reverted back to my old structure.
As far as I know there are still some things "the platform" actually won't deliver; for instance I'm fairly certain there's no searchable combobox that's fully accessible. One ~must leave the platform to give users the experience the expect.
That means "the platform" itself is actually teaching people to work "off platform" and arguably will always have gaps as functionality and expectations evolve.
Admittedly, the habit really ought to be 'I need to make a combobox -> does the platform have what I need? -> Research, evaluate, test -> Otherwise, make it' but I don't begrudge people for skipping the middle steps.
Especially because the last step is less "make it" and more like "npm add it".
The browser has "ready-made components". React (et al) also has "ready-made components". React's selection is a thousand times larger. React also allows you to make your own. The browser doesn't [1].
Who can blame developers for skipping the inconvenient half-solution and going straight to the all-encompassing ecosystem
[1]: It does, but web components are too unwieldy to compete with React
Things that are harder to do make your website seem more flashy.
Its like when rounded borders were hard to do without using clever tricks, people would try and add them to their website so that they looked different to everyone else. Once they became easy to do they weren't so desirable.
The equivalent today is wacky scrolling schemes where unusual things happen as you scroll down. Whatever is difficult can be used to distinguish your site.
I think this is completely wrong. The reason why nkt a lot of people use the built in elements is because sooner or later you will hit a limitation that you cannot fix.
If it is a javascript element you can do whatever you want if it doesn'fit.
Take dialog as an example. If you have a server side rendered app and you want to show an open dialog without js. You are out of luck, you can't just render it as open because that opens a dialog that does not correctly work.
Or take a multiselect input. Just unusable as a normal browser element.
Also most elements miss something essential like no search function in an input. So also unusable for big lists.
I could make a list of 100 things that are wrong with native browser elements.
It is just easier to use a js framework/library and have a clean view and state.
> It is just easier to use a js framework/library and have a clean view and state.
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 issue remains true even with the JS "wrapper" elements.
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.
I agree. Still better than the native elements.
The biggest downside is 100kb js elements because they try to handle everything.
I used basecoat and that worked ok, even if some essentials are missing.
Currently I am using my own webcomponents created with rocket (from datastar)
When a technology becomes popular enough, it develops a community that solidifies that choice: conferences, books, extensions, a generation of engineers that see things in terms of React.
A technology needs to be a lot better to overcome that aspect.
Sometimes I visit a subreddit for a tech and see them all discussing strategies/techniques that are ultimately workarounds for what an alternative technology has fundamentally solved, but...
the original tech has an army of volunteers able to help newbies workaround it, which is often an easier onboard experience than the alternative tech that just works, but doesn't have any advocating solutions/blog posts because there are no blog posts to be written.
Counterpoint: the problem was solved by an alternative, but was it solved without any tradeoffs? If the solution comes with no real tradeoffs, then that begs the question why React wouldn't simply adopt the solution... And I think this is not a theoretical nitpick, either: Angular actually has, to my knowledge, basically done this more than once. And React certainly doesn't seem afraid to make big or breaking changes, from fibers to suspense to hooks to context, so I don't think it is resistance to change at play here.
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.)
I think we agree, though I can see why it might not have seemed that way, since I didn't draw attention that users might rightly conclude the overall tradeoff is worth it, even if another tech is sounder in some minor aspect.
React can adapt, and though Web Components might still have some claim on X, Y, Z, React still is heavily preferred because all the other things are so much more important to developers.
For what genuine gaps remain, there's lots of React users that can help others through it.
Web components are lighter than frameworks, are they not? That was the biggest benefit I saw: no dependency on an ever changing framework and toolchain.
Decades old apps written in DOM and JS are eminently more maintainable than that written in some no longer maintained backbone / 1.4 django frontend or wherever, with their cacophony of unmaintained tools.
They didn’t seem quite as polished as the latest framework offering but they promised to be around when everyone gets bored of framework x.
I feel like it’s a historical accident. In the past the platform couldn’t do it all, and if you wanted a dialog you had to use a library. Developers were trained to reach for libraries when they needed something like a dialog.
Then react came along and all developed learning web development after react had little to no knowledge of the platform. They were taught that touching the DOM was a bad thing to do.
That’s about it. Even now when I advocate for vanilla css I get the side eye and “tailwind and shadcn should be the default”. I get it, it’s what most people are familiar with, even if it’s worse than the platform.
Depends on the criteria, e.g. if dev speed has highest prio, a full blown component lib like Material UI would be superior to shadcn. CSS can obviously do things that tailwind can't, so it is more powerful.
The point of shadcn is you can pull in a component and modify it any way you want. It's always going to be bare bones at the start. Something like MUI locks you into a layout and style that's coupled with the API, and you need to rewrite big chunks of your app if you want to add your own branding.
For me the best middle ground is Headless UI or Bits for Svelte, unstyled and composable but you don't need to vendor code into your repo like shadcn.
I actually still use Dragula. I can't quite put my finger on it, but it just feels better than Sortable. I may be imagining it, but I also don't care because, you know, it's just a JS library.
<dialog> still has issues to this day that haven't been resolved - https://tane.dev/2021/02/revisiting-dark-patterns-with-the-h... - of course these can be implemented in any framework but this makes is much easier - at the platform level - to make a browser unusable, and as it's platform it's of course never been fixed.
You can have fun with web components (https://tanepiper.github.io/webc-humour/) but from my experience trying to build UIs with them - they end up becoming an additional abstraction that instead of just using a framework to build the entire experience, it creates annoying boundaries of having to deal with DOM attributes instead of just working with properties.
From other comments that are focused on the code part of the subject, I think there are 2 big forgotten points here: time and hype.
Time: since platforms are big machines, their timeline and backlog is huge, and the self-taught geek does not consider (care) that. So when there is an obvious little hiccup somewhere, they create a bug report that asks for details, proof, reproduceability,... and finally get pushed back to eons because there are more pressing concerns to attend to at the platform level.
Meanwhile, it takes about 1h (without AI) to code a workaround and feel like a hero because "I've fixed something that took them 3 years to triage".
Hype: yes documentation and code quality and all matter, but it matters even more when it comes from Google or Meta! We all feel little compared to giants and when they open their internal secret tooling framework (with big marketing budget) then we all feel like there is a secret to grasp and a key success factor to wield.
So it is not so much whether a npm library some nobody created exists, but whether the main contributor works at a big brand name. It does not prevent smaller anonymous projects from emerging but lets face it, it is much more appealing when it is how Cloudflare handles it at 1e20 scale (because we all feel we face the same challenges of course).
There have been countless times where I wanted to use some new fangled platform API, but couldn’t because it was buggy/unsupported in one of the browsers or didn’t quite match my use case.
It does t help that the platform abandoned some of its efforts to introduce better primitives in favor of higher level APIs.
Because the platform sucks. I want a rounded button with a certain radius and a certain font, that feels squishy and satisfying when you press it, especially on mobile.
Counterpoint on Safari. Apple still ties browser updates to OS updates and there are a lot of old iPhones in circulation. Safari 16 is still a reasonable target and it’s missing a lot of modern features and has a lot of bugs to work around.
The answer is UX designers and marketing people. I will yet have to work in a web project where any UX designer will be happy with what the native browser has to offer. Notable examples are date/time pickers. Look at any of the Top100 websites and you will find custom date/time picker designs. And I would also say, with standard browser built-in dialogs you could not rebuild/model those pickers to match what the Top100 websites use.
React to some degree made immediate mode UI possible in the browser, which is part of why it is this successful. If the browser gave the option to do ui = f(state) natively, you wouldn't need React.
Some developers are locked in to using some in house UI solution that is slow to implement any new features from evergreen browsers and even is still shipping hacks for IE11, although it was depreceted company wide years ago.
The last couple of websites I've made have been largely the output of Claude with some instructions to keep to WCAG AAA accessibility standards and to optimize for loading and rendering times, and it's done a pretty decent job. If you're insistent about page weight it will avoid adding JS and React and use to browser-native elements, CSS, and vanilla JS where it can.
I think the problem is that you have to ask, and to know the language to get the result you're after. If you just ask for a pretty website you're getting 800KB of React libraries to render something, and all in AI Beige with Inter as your font choice.
> If you search for “sticky positioning” on npm, there’s no package that says “just use CSS position: sticky, you dolt.”
Sure you use sticky till your component gets embedded inside a relative positioned container that you have no idea of where it is and why, and in complex codebases hardly you would rewrite the code for that container in order to not create regression. You then go with "use the platform" but javascript and you try using that horrible intersection observer api with an hack to make elements sticky, except it breaks immediately after on a corner case. You then reach out for a mature library.
Fuck off the platform i've been suffering for decades at this point fighting half complete apis and non well documented behaviour(no i wont read the humongous spec).
Everytime I used the platform(even recently with dialog) you almost immediately hit all the limitation.
The sooner we understand the platform abadoned us(and I also have a thinfoil hat theory about that) the soon we can have an api for drawing the heck we want(please dont mention canvas 2d) and an api for accesibility
It's because frankly the platform has been historically shit. Web components comes to mind as someone else here has mentioned, as it's just not a good API and needs wrapping to make it usable, same as IndexedDB which the author readily admits as a creator of such tooling. It seems like the ones who determine the platform aren't actually developers day in and day out and thus don't dogfood their own products while the rest of us do, leading us to reinvent the wheel.
Here is a great comment and discussion (scroll down) by Ian Hickson who wrote the HTML5 spec on how the platform has essentially failed on its promises causing everyone to write everything in JS or even other paradigms like Flutter and other WASM or canvas based frameworks that eschew the web entirely: https://news.ycombinator.com/item?id=34612696
It’s funny, the article proceeds to answer the question in great detail: familiarity, level of abstraction, documentation, etc.
I agree with his point that learning to do it yourself can be fun and lead to a flywheel of improvement where the next time you’re faster and the next time faster still.
In the past that was the recipe for success as a developer, nowadays with AI many feel that’s no longer the case.
It's not apathy towards "learn to do it yourself", it's apathy towards dealing with the recursive fractal of bullshit that is modern software. It's not 2000s anymore, we have orders of magnitude more of nonsense to learn (ironically, most of it are attempts at repackaging and hiding nonsense from lower layers), and learning that is just a waste of life. LLMs finally give us the option not to.
This misses the point completely for repeated arguments that make no sense "Its historical ...".
The reality is, you lose programmatic control when you use HTML directly. Its much easier to have Dialog component that reacts to its state, than to use the native dialog tag.
People will just use the best tool for the job, putting aside some time it takes for practices to propagate.
Native date pickers suck, are ugly, and have no customizability, and look inconsistent between user agents. They don’t even really conform to the OS either (other than iOS). Everyone uses JS. Chrome’s native date picker shipped with a monospaced input font, for crying out loud.
Position sticky is amazing and the behavior is better than what JS can give you. A lot of people use it. Not much UI to make consistent between user agents.
Make the platform actually good and consistent and people will use it. Native APIs are always the better choice if they accomplish your need.
Seems from the article that this is more "why don't more REACT developers use the platform"?
I think it is largely because IMHO React is very much an "overlay" on top of (and inspite of) normal web standards and general beat practice (e.g. JSX throwing out decades of separation of concerns etc), leading to whole swathes of people who have basically only ever been "react developers" not generalist frontend engineers. They find the DOM APIs "icky" because it takes them out of the React lifecycle, mindset, and ecosystem etc.
Tldr, React and NPM are a pox on the world of frontend development and especially the JavaScript ecosystem. It's given JavaScript such a bad name, unfairly.
Still with AI basically nothing matters any more - no one sees the code any more.
since the author brought up the native <dialog>, developers chose custom implementations of dialogs because they want better accessibility, better focus management, better mobile and touch screen reader support, and more flexibility. adobe's implementation is far more robust and flexible compared to the native dialog, and it's hard to justify "use the platform" when it results in a strictly worse end result.
When I tried using <dialog> for the first time, there was one major thing that stuck out to me as a bit of a problem with how it is implemented:
It has become a norm to expect that if you click/tap on the backdrop of a modal/dialog, it will dismiss the modal/dialog. That isn't the case with <dialog> by default, and you need to use either use a hacky JS handler that checks the bounding box of the dialog (because the backdrop click events just end up fed to the dialog element), or use an attribute, `closedby`='any' that does not work on iOS and has spotty support at best in desktop Safari
Yeah, that was kind of ignored in the article and it's definitely an issue for some platform features. Date pickers are another one where it's easy to outgrow the native implementation.
I was excited about the native date picker and tried to use it once, only to discover that you couldn't (can't still, I assume) disable dates other than by setting min and max. Every native browser widget I've tried to use doesn't implement the features my clients expect, so I don't use them. People want a better web platform and the only way to get it is JavaScript.
Once upon a time, there was a golden age for devex, when “the platform”, i.e. Windows, was on-prem and Microsoft wanted everyone to be able to develop software for it and have it easy to set up and run. Thus, we got very nice toys like .NET and SQL Server, which is still the easiest, most batteries-included and hands-off database to this day. As much hate as Microsoft deservedly got and still gets, it’s hard to overstate what a miracle this alignment was. A corporation’s real, intrinsic, not just stated in marketing, but legitimate goals were to actually empower customers. When does that ever happen?
Of course, this had its own misaligned incentives: Microsoft didn’t own the web, so they were only interested in improving it strictly on Windows, so they put proprietary shit in their browser. Everybody saw that this was bad and a big long struggle ensued and finally Firefox came out on top.
But with the balance shifting in favor of the web, new incentive perversions arose. To sell cloud bullshit and lock people into their platforms, web companies obviously don’t want you to have a good time developing or hosting competing products, even just for yourself, so complexity exploded and any focus on developer and operations experience went out the window. They also don’t want anyone to be able to turn of Javascript or otherwise have much control via their “user agent”, so not only do they not care about advancing “progressive enhancement”, they’d probably prefer to get rid of it.
As quickly as Firefox saved the day, one of these companies came out with their own browser, and everybody saw that this was going to be a bad idea, but they ran TV ads, so everybody switched regardless.
Actually, developers were the first ones to switch, because they were promised cool new toys, lmao.
We should have rejected clouds and we should have rejected Chrome and with some luck we could this day be living in a paradise of on-prem toys and be the princes of our orgs. Well, probably not, but still.
That lets you bring up the picker, let the user pick any date, and then show an error message if they picked an unavailable one. It doesn’t let you show dates as unavailable in the picker or prevent the user from picking them.
But also custom date pickers are the most broken thing you can find everywhere. Browse with a combination of browser/phone the developer didn't test, and you can't pick even the most basic single date. The most blatant are the fancy range pickers, instead of two date picker boxes: I have been pushed to a desktop browser because the mobile renders half of it off-screen, or don't hold open after tapping the start date, or works by dragging but breaks on single taps...
Yep. I've also seen a datetime picker (in a log viewing tool) where adjusting time from keyboard is nigh impossible: you have "12:30:00", with the cursor right after the "30", and want to make it "35", so you press [Backspace] — nope, deleting a digit would make an invalid time, so the component undoes it. You press "5", but inserting yet another digit would also make an invalid time, so the component undoes it. You have to text-select the zero, and then press "5" to overwrite it... and you have to do it digit-by-digit, because you can't replace two digits at once with a single key press. Amazing.
Developers don't "use the platform" because all the building blocks for any component you can think of are already there. When "the platform" adds yet another set of not particularly pretty and badly configurable components, why would we use them? When there's tons of mature, deeply thought out, battle tested, cleanly abstracted components out there - especially when _those_ components are made of divs and layouting and CSS and are therefore malleable to the pixel instead of being made of magic browser pixie dust?
Because the platform is too hard. The average person does not want to spend time figuring out how to get stuff to work. All the browser documentation is 1000 times nerdier than the average person wants. They want all this low level stuff abstracted away from them.
Even if you want to do it the nerdy way and bust out a text editor and start writing some HTML tags it all looks ugly out of the box. Browsers pushed everything for making websites onto 3rd party devs, so they shouldn't be surprised when they want to use 3rd party dev's stuff over the bad and confusing 1st party ones. The browser developers are in an ivory tower building a product that doesn't really care about web developers and their needs.
Is it just me or does it feel like Anthropic and OpenAI (and probably others) are pumping harness engineering and the like to try and convince engineering organizations, or even entire companies, to "use the platform", and not meddle with software anymore?
There’s only one “the platform” but there were tons of competing libraries to do things like css, components, etc. The competitive landscape just produced better results. For me, Tailwind is nicer to use than regular CSS, and React is nicer to use than web components.
On the note of <dialog>, I recently tried to use <dialog> in a (React) application, and it did work pretty well, but I also found that in Firefox it is only practically possible to do a fade-in animation, not a fade-out one. That isn't really a critical issue for me, it is just an animation after all, but I find it unfortunate. I also find <dialog> to be a weirdly shaped API too: I don't really hate it, but I don't love it either. It feels awkward.
I find this implicit view that developers that, for example, prefer React over WebComponents are making a suboptimal choice to be rather condescending and not really in the spirit of trying to see things from the other side. Wouldn't you want to focus on the strongest arguments and not the weakest ones? Maybe you've literally never heard anyone complain about WebComponents or Shadow DOM, but if so, I find that surprising. Certainly here on HN, I've seen a fair bit of WebComponents hate.
I do, FWIW, realize that I've particularly focused on WebComponents, which this article doesn't actually name directly. But, I assume we're not talking about ditching React to implement our own component framework on top of the traditional DOM APIs, because that's what React already does...
I am one of the people who irreconcilably disagree. I think svelte and solidjs are - obviously - technically superior. But it leaves the question of why react is still so popular. I think the biggest reason is all the non-technical aspects of react:
- They have excellent documentation. And have, from day 1.
- They produced videos, sample projects, and all sorts of "getting started" documentation.
- They ran react conferences, teaching everyone who would listen about "1 way data flows" and pretending like they invented FP.
The amount of hype around it made it really feel like the next big thing. Between the very well funded react team and the outside developer community, there was real momentum. People learned it in droves. Taught students. Built websites with it. When react's poor design choices caused issues (and there were a lot of issues), then you were blamed for holding it wrong. (Component classes, state, CSS, hooks, webpack and babel taking ages, big bundle sizes, slow re-renders, and so on.)
By the time the next generation of JS frameworks broke onto the scene, there was a collective moan from the community. "Oh no, not again - we just relearned how to make websites." React was the wave, and in its wake we all had Framework fatigue.
Software doesn't get popular without a lot of work by dedicated people. I really admire the work standards bodies do. But they rarely bother to take the time to produce documentation, videos, tutorials, starter projects, blogs and podcasts and all the rest of that work.
More like trying to explain to people who have only done imperative programming (and that also in JS of all languages) why a render function was necessary. The creator of React, Jordan Walke, was big into OCaml and one might even say he got some of the ideas of React through working in OCaml, so much so that he tried to bridge both by making ReasonML which is an alternative syntax for OCaml which has JSX and React bindings.
I don't really think that React is necessarily the best possible library, but there is certainly more to a UI library than simply compiling out the need for diffing. For one thing, I find JSX to be a relatively unobtrusive addition to the language. It is implemented by a variety of things and is a pretty simple transform as far as things go; basically pure sugar, it's possible to avoid it if you want. It could be better designed than it is, but I think it's at least sufficiently general - it is feasible to say, use an alternate library with JSX, like Preact.
Svelte on the other hand by its nature just simply requires a more complicated compiler step to work and deliver on its promises. That's a trade-off. Whether you think it's worth it is up to you, but presenting it as an objectively technically superior design is disingenuous. Superior how? Runtime costs? Sure, but it does beg the question how much. Will a well-optimized Svelte app feel much better than a well-optimized React app?
> The amount of hype around it made it really feel like the next big thing.
We are a really long way away from the hype of React. I would argue that hype stopped carrying React a long time ago. Momentum? Sure, but if something was truly dramatically better, then I think it would have a fair shake at beating out React.
The problem is that the web isn't microbenchmarks and developer experience does matter to some degree, so the trade-offs that seem so good on paper don't always pan out.
I'm not a hater of Svelte. On paper, it is a very elegant idea. However, when I actually tried to use it, I genuinely came out feeling that it was simply not for me, and the benefits it has are not enticing enough for me to continue experimenting. My React apps are not particularly slow or bad at handling huge amounts of data. (One of my apps has no problem handling a file grid of over 1 million items, and in fact, I run into issues with browsers not being able to handle a large enough scroll area long before performance of my React code is a problem. That is good enough for me.)
Talking about one-way data flows was an excellent way to speak to a lot of tortured souls at the time (who had just found out they were going to be forced to migrate their projects to something else anyway due to Google's absolutely insane "we're deprecating this, we'll have a replacement for it at... some point, good luck").
This was exactly what sprang to mind as soon as I saw the title. I’ve been writing front-end code for over 25 years now, and exactly two things in that entire time have made me miserable enough to think about stopping: Internet Explorer 6 and web components. Every time I try to just “use the platform” it makes me miserable and I end up demotivated and stop working on whatever side project I chose to try again with. And I otherwise like the web platform! I’ve been building with it since there was nothing but the web platform. But web components kill my enthusiasm for it stone dead.
Even now in the age of agentic development, AI trips over all the same footguns in web components that humans do. It just seems like everybody involved has been adding to the standards with “yes, and…” without ever thinking about how it will be used by web developers in practice.
Say we want to make an icon that when clicked shows how often it was clicked. The webcomponent code seens quite sane to me:
Try it here:https://plnkr.co/edit/0XUOLyM52xfFiIBu?open=index.html&previ...
Make it have an initial count via attributes, sync it with the DOM so if the attribute changes the count resets, and make the JS property always match the attribute (and vice-versa) so it behaves sanely. You're in for a world of pain even for something as simple as this.
Plus they're not declarative: you will only make me use innerText-based updates by threatening me and my family.
Plus they only work with JS enabled, while I can use JSX in SSR.
I've worked extensively with Web Components. They suck.
- HTML in a string. No syntax checks. If you interpolate it, you have to escape manually or you could create trivial XSS vulnerabilities. Your editor will probably not syntax highlight it, making it harder to tell when you break it.
- Manually formatted update logic that is redundant with the string. Not so bad here, but try formulating a practical large component.
- Completely ad-hoc state management, no reconciliation. Again, fine for Hello World, not fine after that.
Using raw WebComponents, your application has to care about all of this on its own and more. You can use templates and slots (which you should) but that makes this even messier IMO and brings back the split that React became famous for getting rid of. We left manual DOM reconciliation, ad-hoc data flow and non-reactive components that manually call a render routine at arbitrary points for a reason: it sucked. It made for buggier, harder to maintain code. It can be done, but usually any decent app will wind up encapsulating patterns into utilities that get reused. And... That's precisely why we want a good library. That's what I want, a library that packages up good reusable patterns for constructing UIs effectively.
And that's exactly my point, which is WebComponents or not, the solution is still basically the same, use libraries. Which begs the question: if I have to use Lit, what is the point of "using the platform"? What is WebComponents doing for me here that React wouldn't be? And in my case, I struggle to see it.
Interoperability? The old way of embedding external components works quite fine. Switching APIs where you pass a DOM node for something to mount into and get back an object with an API to one where you instantiate a component and communicate via properties and events feels like a strictly lateral move. I can't think of a condition where this would be particularly more convenient, but I can think of some where it is actually less. Next.
Isolation? Yes, WebComponents does add tools to provide better isolation between components. For some use cases this is a genuinely useful feature, although it also isn't without tradeoffs (I mean, the flexibility of having things be not isolated comes in clutch sometimes, it's hard to argue this.) But I use React primarily to construct components in an application, where I find this property more undesirable than desirable.
The one thing I thought could be cool with WebComponents is if you could build them in pure HTML when you only needed basic templating, but no: the design they went with always requires subclassing in JS AFAIK.
I could go on and get more specific, but I feel like people will pick everything I just said apart quite enough. I hope I'm at least able to make the case that:
- I do in fact, get the general gist of WebComponents.
- I still don't like it despite that.
Well, for some definition of "manually".
If you have untrusted variables to interpolate, you can do
Where html is a function that escapes the variables.The arguments brought forward against web components all seem to fall under "But it does not contain every functionality you want to use out of the box". Personally, I don't think browsers should provide more and more functionality, but rather a good base to build upon.
I hate the guts of every site that uses those. Shadow DOM makes the site hard to operate and fix programmatically from user end.
I mean, these days I can just throw an LLM at it so I don't care as much, but sometimes I want to still do things hands-on. Not to mention, Shadow DOM is often a difference between "simple userstyle/userscript that is allowed at work by security extensions" vs "requiring things that are banned on corporate-managed browser".
For one, they can stop pretending that JS and the DOM are two completely separate entities, and lock the two working groups in a basement until they figure out a sane way to do reactivity, natively, that actually works.
I put up with it, because plenty SaaS products favour Next.js and React as their only extension SDK.
I would never pick it up freely, all side projects with Web are VanilaJS, coupled with what is available on Java, .NET and PHP.
That means "the platform" itself is actually teaching people to work "off platform" and arguably will always have gaps as functionality and expectations evolve.
Admittedly, the habit really ought to be 'I need to make a combobox -> does the platform have what I need? -> Research, evaluate, test -> Otherwise, make it' but I don't begrudge people for skipping the middle steps.
The browser has "ready-made components". React (et al) also has "ready-made components". React's selection is a thousand times larger. React also allows you to make your own. The browser doesn't [1].
Who can blame developers for skipping the inconvenient half-solution and going straight to the all-encompassing ecosystem
[1]: It does, but web components are too unwieldy to compete with React
Its like when rounded borders were hard to do without using clever tricks, people would try and add them to their website so that they looked different to everyone else. Once they became easy to do they weren't so desirable.
The equivalent today is wacky scrolling schemes where unusual things happen as you scroll down. Whatever is difficult can be used to distinguish your site.
Take dialog as an example. If you have a server side rendered app and you want to show an open dialog without js. You are out of luck, you can't just render it as open because that opens a dialog that does not correctly work. Or take a multiselect input. Just unusable as a normal browser element. Also most elements miss something essential like no search function in an input. So also unusable for big lists. I could make a list of 100 things that are wrong with native browser elements. It is just easier to use a js framework/library and have a clean view and state.
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.
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.
A technology needs to be a lot better to overcome that aspect.
Sometimes I visit a subreddit for a tech and see them all discussing strategies/techniques that are ultimately workarounds for what an alternative technology has fundamentally solved, but... the original tech has an army of volunteers able to help newbies workaround it, which is often an easier onboard experience than the alternative tech that just works, but doesn't have any advocating solutions/blog posts because there are no blog posts to be written.
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.)
React can adapt, and though Web Components might still have some claim on X, Y, Z, React still is heavily preferred because all the other things are so much more important to developers.
For what genuine gaps remain, there's lots of React users that can help others through it.
Decades old apps written in DOM and JS are eminently more maintainable than that written in some no longer maintained backbone / 1.4 django frontend or wherever, with their cacophony of unmaintained tools.
They didn’t seem quite as polished as the latest framework offering but they promised to be around when everyone gets bored of framework x.
Then react came along and all developed learning web development after react had little to no knowledge of the platform. They were taught that touching the DOM was a bad thing to do.
That’s about it. Even now when I advocate for vanilla css I get the side eye and “tailwind and shadcn should be the default”. I get it, it’s what most people are familiar with, even if it’s worse than the platform.
For me the best middle ground is Headless UI or Bits for Svelte, unstyled and composable but you don't need to vendor code into your repo like shadcn.
You can have fun with web components (https://tanepiper.github.io/webc-humour/) but from my experience trying to build UIs with them - they end up becoming an additional abstraction that instead of just using a framework to build the entire experience, it creates annoying boundaries of having to deal with DOM attributes instead of just working with properties.
Time: since platforms are big machines, their timeline and backlog is huge, and the self-taught geek does not consider (care) that. So when there is an obvious little hiccup somewhere, they create a bug report that asks for details, proof, reproduceability,... and finally get pushed back to eons because there are more pressing concerns to attend to at the platform level. Meanwhile, it takes about 1h (without AI) to code a workaround and feel like a hero because "I've fixed something that took them 3 years to triage".
Hype: yes documentation and code quality and all matter, but it matters even more when it comes from Google or Meta! We all feel little compared to giants and when they open their internal secret tooling framework (with big marketing budget) then we all feel like there is a secret to grasp and a key success factor to wield. So it is not so much whether a npm library some nobody created exists, but whether the main contributor works at a big brand name. It does not prevent smaller anonymous projects from emerging but lets face it, it is much more appealing when it is how Cloudflare handles it at 1e20 scale (because we all feel we face the same challenges of course).
I think the problem is that you have to ask, and to know the language to get the result you're after. If you just ask for a pretty website you're getting 800KB of React libraries to render something, and all in AI Beige with Inter as your font choice.
Sure you use sticky till your component gets embedded inside a relative positioned container that you have no idea of where it is and why, and in complex codebases hardly you would rewrite the code for that container in order to not create regression. You then go with "use the platform" but javascript and you try using that horrible intersection observer api with an hack to make elements sticky, except it breaks immediately after on a corner case. You then reach out for a mature library.
Fuck off the platform i've been suffering for decades at this point fighting half complete apis and non well documented behaviour(no i wont read the humongous spec).
Everytime I used the platform(even recently with dialog) you almost immediately hit all the limitation.
The sooner we understand the platform abadoned us(and I also have a thinfoil hat theory about that) the soon we can have an api for drawing the heck we want(please dont mention canvas 2d) and an api for accesibility
Here is a great comment and discussion (scroll down) by Ian Hickson who wrote the HTML5 spec on how the platform has essentially failed on its promises causing everyone to write everything in JS or even other paradigms like Flutter and other WASM or canvas based frameworks that eschew the web entirely: https://news.ycombinator.com/item?id=34612696
And when it becomes real, you've got yourself an argument
I agree with his point that learning to do it yourself can be fun and lead to a flywheel of improvement where the next time you’re faster and the next time faster still.
In the past that was the recipe for success as a developer, nowadays with AI many feel that’s no longer the case.
The reality is, you lose programmatic control when you use HTML directly. Its much easier to have Dialog component that reacts to its state, than to use the native dialog tag.
Native date pickers suck, are ugly, and have no customizability, and look inconsistent between user agents. They don’t even really conform to the OS either (other than iOS). Everyone uses JS. Chrome’s native date picker shipped with a monospaced input font, for crying out loud.
Position sticky is amazing and the behavior is better than what JS can give you. A lot of people use it. Not much UI to make consistent between user agents.
Make the platform actually good and consistent and people will use it. Native APIs are always the better choice if they accomplish your need.
I think it is largely because IMHO React is very much an "overlay" on top of (and inspite of) normal web standards and general beat practice (e.g. JSX throwing out decades of separation of concerns etc), leading to whole swathes of people who have basically only ever been "react developers" not generalist frontend engineers. They find the DOM APIs "icky" because it takes them out of the React lifecycle, mindset, and ecosystem etc.
Tldr, React and NPM are a pox on the world of frontend development and especially the JavaScript ecosystem. It's given JavaScript such a bad name, unfairly.
Still with AI basically nothing matters any more - no one sees the code any more.
It has become a norm to expect that if you click/tap on the backdrop of a modal/dialog, it will dismiss the modal/dialog. That isn't the case with <dialog> by default, and you need to use either use a hacky JS handler that checks the bounding box of the dialog (because the backdrop click events just end up fed to the dialog element), or use an attribute, `closedby`='any' that does not work on iOS and has spotty support at best in desktop Safari
“We need a date picker to schedule a visit.”
“Okay, use `<input type=date>`”
“It needs to be a date in the future.”
“No problem, add a `min="2026-10-05"` attribute.”
“And we’re only available on weekdays.”
“Okay, throw the native date picker away completely and build one yourself from scratch.”
Did nobody involved ever bother to ask what the requirements were for a date picker? Excluding dates is one of the most common requirements there is!
Of course, this had its own misaligned incentives: Microsoft didn’t own the web, so they were only interested in improving it strictly on Windows, so they put proprietary shit in their browser. Everybody saw that this was bad and a big long struggle ensued and finally Firefox came out on top.
But with the balance shifting in favor of the web, new incentive perversions arose. To sell cloud bullshit and lock people into their platforms, web companies obviously don’t want you to have a good time developing or hosting competing products, even just for yourself, so complexity exploded and any focus on developer and operations experience went out the window. They also don’t want anyone to be able to turn of Javascript or otherwise have much control via their “user agent”, so not only do they not care about advancing “progressive enhancement”, they’d probably prefer to get rid of it.
As quickly as Firefox saved the day, one of these companies came out with their own browser, and everybody saw that this was going to be a bad idea, but they ran TV ads, so everybody switched regardless.
Actually, developers were the first ones to switch, because they were promised cool new toys, lmao.
We should have rejected clouds and we should have rejected Chrome and with some luck we could this day be living in a paradise of on-prem toys and be the princes of our orgs. Well, probably not, but still.
It's a lose-lose situation, honestly.
Developers don't "use the platform" because all the building blocks for any component you can think of are already there. When "the platform" adds yet another set of not particularly pretty and badly configurable components, why would we use them? When there's tons of mature, deeply thought out, battle tested, cleanly abstracted components out there - especially when _those_ components are made of divs and layouting and CSS and are therefore malleable to the pixel instead of being made of magic browser pixie dust?
Even if you want to do it the nerdy way and bust out a text editor and start writing some HTML tags it all looks ugly out of the box. Browsers pushed everything for making websites onto 3rd party devs, so they shouldn't be surprised when they want to use 3rd party dev's stuff over the bad and confusing 1st party ones. The browser developers are in an ivory tower building a product that doesn't really care about web developers and their needs.