Why don't more developers “use the platform”?

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...

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

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.

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.

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.

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.

This looks like a backend engineers take.

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.

<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.

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.

An aside: This name an logo are incredible. https://bevacqua.github.io/dragula/

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).

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.

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.

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.

> 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

can the title be changed to "Why don't more developers use browser native features?"

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.

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

> The argument is simple: why build something yourself, in JavaScript, when the browser can do it for you?

And when it becomes real, you've got yourself an argument

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.

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.

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.

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.

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.

This article misses the most crucial point.

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?

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.

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.

I must say it was worth reading , thanks for sharing your insights !!

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?

[flagged]

[dead]

[flagged]

[flagged]

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.