This got to me: > For a certain type of developer, building things yourself is just more fun

The platform APIs were terrible. React wasn't "more fun"... it just made it possible to do things with the platform that were extremely difficult and cumbersome to get working reliably with platform APIs alone.

To me, web components were an incredible idea poorly implemented. Most of the minimal adoption happened on top of frameworks like Lit that wrapped WCs to try to make the dev experience tolerable.

In urban planning they have a concept called "desire paths" where if you don't put sidewalks and pathways in the right places, people invent their own. I feel like the web community has spent a lot of time and effort patching the platform.

Now credit where credit is due: it has very much improved. And modern standards means it really is time to re-evaluate where and when you need these patches. But don't write off all that annoying and painful effort people put in to trying to making the platform deliver it's promised potential just to "building it yourself is more fun".

Your premise that the browser implementation is faster and better is rarely true. And when it is true, it's only true in a very narrow lane.

Take for instance something like suggestions on form fields: you start typing something and it presents some options from a hardcoded list that matches the prefix. This is natively achieved through the HTML element <datalist>. However, <datalist> implementations on most browsers suck to the point of being unusable.

The drive to roll your own is not so much that "it would be fun to learn this" as much as it's "rolling my own would let me express my vision exactly". What draws a lot of people to software engineering is that it lets you make anything you imagine. This is also what makes a lot of devs turn their nose at no-code and vibe-coding.

If you can't build things exactly how you want them to be, then it's hard/impossible to build something that's truly genius.

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

Coming from a more general programming view, I find web development extremely odd. In general programming we tend to find a small set of abstractions which we can use in a composable way to cover our problem space.

For example, to interact with the VFS, we have read()/write(). When we add more APIs, it can be to enable a new paradigm, like epoll(), or for performance, like readv()/writev(). For a functionality that can be composed out of existing APIs in a performant way, we do not add it in the platform, but leave it instead to the domain of libraries. This separation has immense values, as it makes platforms easy to implement. A Linux filesystem, for example, needs to implement only 10 or so functions.

The web seems to be perfectly composable too, out of <div>, <span>, <p> and a small subset of CSS, but doing this is considered an anti-pattern, and you're supposed to reach for the platform to find the closest thing to what you need, whereas reaching for a library or composing yourself is frowned upon.

The result is that there are only three platforms: Blink/V8; WebKit/JavaScriptCore; and Geko/SpiderMonkey. With many things only working or working well on Blink/V8.

And implementing a new platform is a titanic task.

The "platform"? that never really existed? I have a better question...why would I trust a goddamned browser? Im paid to make my apps look and feel and run beautifully. Im NOT paid to pay homage to someones "well it looks good or works this way on this browser and this version"'s HORSESHIT.

The browser is hands down the worst and I mean the WORST development platform to rise to prominence in the history of software development since computers were invented and its because of the people, the inexperienced, pie in the sky, academic LOSERS who have run "platform development" since the dawn of the web.

Every SINGLE, and I mean EVERY SINGLE other development "platform" back to QBasic was better in EVERY SINGLE WAY.

FUCK YOU!

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.

Because using a platform requires reading and thinking carefully and occupying the mind of someone else. It means telling business people and designers no. It requires maturity and experience to understand the true cost of custom work.

For a lot of us it's lived experience - "the platform" can hide bugs that don't emerge until a certain rare set of conditions is present and we get glared at by the business folks who don't understand why we can't just "fix it" when it's buried in someone else's Jenga tower.

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.

I was early adopter of WebComponents and honestly they are terrible. If only they would have at least CSS layer which would be passed and I can reset styles and shadow root would be accessible ass private property and every element with id world be accessible through private property so I don't need to store them in weird way of query them.

Then I would consider them acceptable

In current state they are unusable beyond simple components

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.

The original sin of JavaScript was such a small standard library.

React, Vue, etc are all just working around it. I’ve never been good at web programming, but the rare times I need to, I want it to be easy. Thus Vue.

Infact I’ve been building my recent web projects with Flutter and Godot. Flutter Web is such a better experience if your use case allows it.

Ever used a time field in pure html? And then you get reports users can enter 99 minutes.

Yes that's why

~a year ago i passed a major inflection point regarding web UIs.

i built an in-browser STT app UI with dear imgui, and everything just _worked_. i’m rendering to a canvas, running the model in a service worker and heavily using web audio, among other platform APIs. but.

at this point, i’d even struggle to comprehend the concept of going back to using the DOM for anything but a static reading experience. perhaps peppered with _fancy_ web components for an interactive animation. some would argue that’s what it’s for.

well, browsers/JS engines can both be powerful and terrible at the same time. despite using imgui via typescript bindings and rendering to a canvas via webgpu/webgl2, there is almost no limit to what i can do. more importantly, how easily i can express _whatever i want to see_ without paying with terrible frame rates, gc or layout jank or some other fun webism.

i’ve built SPAs since dojo was a thing, built iAds (lol), really, i’ve bikeshedded myself to oblivion.

low key expecting some kind of communal inflection point where we stop wasting our time arguing about bronze age tools and start having fun again.

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.

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.

Many native web browser capabilities exist because adventurous developers came up with the patterns themselves. There is no way we’d have CSS scroll-driven animations available to us if front end developers hadn’t already established the requirement and pattern. Browser standards, CSS specs etc follow what _we_ hack together and make ubiquitous (sort of like desire paths), not the other way around. That is why we shouldn’t blindly “use the platform”; vendors should adjust to our demands, not the other way around. Of course, if a native element or capability matches exactly your requirements in some scenario, using it would be sensible.

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

Mostly because UX has some needs they want to fulfilled. At least that has been why we used custom pickers / dropdowns / inputs, you name it

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 did. At some point Claude figured out I didn't even check the code and it "minified" the code. Now only Claude can change it. It's a small side project I wanted to do for a long time and now it's Done.

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.

With AI you dont need React and pals. The best "stack" is just web components, with (if really required) some state manager (zustand, mobx etc) and optionally jsx if you want. Esbuild as a compiler. This is all browser native, very performant and will never get old (deprecated).

The main reason is flexibility.

One day your boss stands next to you and asks: "can you move this border three pixels to the left", and the only correct answer is "but that requires a complete rewrite".

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.

> But for many developers, this sounds like fun! Think of how much you learn as you start building this thing.

I got a good chuckle when my brain finished this sentence with "and promptly forget so that you can learn it all over again years later the next time you need to touch that topic".

Mostly this is true for “internal” platforms as well. Most enterprises have some “way to do things” - and once you get beyond a few developers someone is always rolling some of their own - rarely is it obtuseness, often it’s lack of training and even awareness of the equivalent of “dialog” even exists

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.

Personally, and this is more of a general coding thing than specific to web development, I find a number of imported items are easy to code and write myself, and thus I have control over debugging rather than submitting myself to the process of reporting a bug then hoping it will be fixed in a timely manner. I also have feature control and can avoid feature bloat, and I have full knowledge of the code I am running.

This allows me to speed up development and have a streamlined custom implementation of that feature for my code. For example, I was unhappy recently with performance and feature set in RRDTool. Seeing that updates from the dev for that are quite glacial I wrote my own implementation, which took about 20 minutes, and now I have one less import, and in the process speeded up data retrieval, so I can have 60fps graph generation, discarded unused features, and added a couple of custom ones for my application.

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

People really used to search for “sticky positioning” or things like that on npm?

I always just googled stuff, now I prompt

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

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.

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

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.

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.

Same reason they don't use any platform. It's not as good as you think.

Friends don't let friends use npm

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.

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.

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.

I mean a lot of it is just that many features that would have been nice to use decades ago have only just been implemented. For example, now we have some great modal options built into the browser in the form of the dialog element and popover attribute.

But for years, those didn't exist, and people got used to that. The former was added to certain browsers in 2022, and the latter was added in 2023-2025. If you've building modals with divs and JavaScript for years, it can take a bit to realise you don't need to do that anymore.

Eventually I suspect we'll be in a place where self-made solutions for common UI issues aren't needed anymore, but that's still sadly a way off, especially given how slow browsers have been to add fully customisable select elements and other form fields.

> 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

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.

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.

> 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

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.

The Platform doesn't provide much tooling to aid development, it remains in isolation

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.

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.

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

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?

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?

This looks like a backend engineers take.

JavaScript is an obvious skills gap.

Most people claim to be able to write JavaScript but what they really mean is that they can write only a few lines only if someone else provides them a template and if someone has made all the design decisions for them. It’s color by number. Then you can’t point any of this out because people become immediately defensive crying about how hard life is and how impossible writing original software is and on and on.

I got tired of working with all the liars and pretenders. The greatest challenge doing that work is the people, not the technology.

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.