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".
That's fascinating that it already had a term! The YC founder I used to work for was adamant that he came up with the term "idealized path" for this phenomenon.
Pathways is an urban open problem that companies like GoodMaps are trying to solve, although in a convoluted way (more sensors = more accuracy, but walled-garden is meh).
After doing this for more than 20 years I have asked that question hundreds of times and the answer is almost always about aesthetics, about 95%+. Of those aesthetics based conclusions most people cannot find their own way to handle it without waiting for somebody else to write a tool that provides the answer they were looking for. Even then the answer tends to be predicated on social acceptance more than technical evaluation. That is a training or human performance problem more than a technical problem. It says a lot about an industry where the people who are able to ask these kinds of questions realize its a training problem and are willing to raise salaries and assume tech debt as opposed to fixing a human capital problem for far less money.
At any rate there is something to be said for the developer who builds things on their own just for themselves. In many cases the result is faster, lighter, and more capable software than what they are paid to do for their employer. Their personal software isn't locked into conventions or abstractions beyond their control.
The APIs are expensive for storing state (read access on attributes) and expensive to write (so many ways to trigger reflows and paints) without a good way to batch them.
WCs have tons of boilerplate to them, such as extra song and dance to make attributes observable. In fact, a custom element can have an attribute and a property with the same name, and they are managed separately unless you explicitly set them up to sync. It's a terrible design.
Built-in things aren't extensible - there's no way to have a number type input that doesn't suck without doing it yourself, and then you need to opt into extra song and dance for your element to participate in form submission data.
There's a reason popular frameworks are popular. They're good enough, you can hire people who already know them, and you benefit from the maintainers fixing bugs for you.
On the platform, my code is split between HTML, JS and CSS files.
I like modules. They exist in some form or another in most programming languages and they are one of the few definitively good ideas in software engineering. Give me the ability to split off parts of my work with some public API and hidden internals. Works on different levels too, like with a reusable library that consists of modules.
JS has a module story. But HTML and CSS just aren't connected to it, without using something like JSX.
That's why I end up abandoning "using the platform" every time.
I dont know any other environment except the browser where code is split into three in a similar way.
I have worked on my own component libraries for HTML, but I don't like solving the same problems over and over and over again. I'd prefer a well-supported battle-tested library over my ad-hoc attempts.
The argument presented in the article here is that libraries like jQuery and React were useful, but now the browser has better APIs, so we should use them.
The browser indeed has a components API, but it is by the admission of many, fairly low-level as far as component APIs go. It doesn't really solve how to manage data flow or rendering in your components or application, and has many sore spots.
No problem. There is a pretty nice library called LitElement that provides solutions to some of these problems.
But then we're not really living off the land are we? We still need Lit in this case.
So what's wrong with WebComponents? Frankly, I think this is a bad question. A better question is why people think WebComponents competes with React to begin with. WebComponents intentionally fails to solve some of the most annoying problems with writing components because it is intended to be low-level and used by libraries like Polymer. Because of this, it leaves many problems open-ended. Like for example. WebComponents act like HTML elements. Cool? So you can pass data down using HTML attributes. Neat. Problem: HTML attributes are strings. Okay... So you either need to serialize everything to strings, or you have to pass objects through a separate side channel (usually properties that you assign separately.) In fact, generally speaking, writing WebComponents that compose other WebComponents is ass. I'm pretty sure it has been noted before that WebComponents works best for leaf components... So it would certainly not make a good replacement for a library like React, which is meant to be a substrate you can build large scale applications out of.
Most browser things live in a bubble of ignorance about what people are trying to build.
It's not overly ambitious to have rich text input fields or a sortable table. If you can have a half assed xpath implementation you can have a shopping cart and a product.
Someone knowledgable once ran off with a fumble of mine acting like I pulled gold from thin air.
It took the id's from the page, created strings with the same name containing the inner html, made a copy, compared the copy with the string every 50ms, if they were no longer the same the dom node and the copy were updated with the new value. Input fields compared the copy with the input value as well.
The web platform is still garbage. I want something with the simplicity of Classic MacOS, or GTK2, where for e.g. a text editing page like a wiki, I have a toplevel "App" component, and inside a combination of VerticalBox, and HorizontalBox for layout, with a MenuBar on top and a TextBox on the bottom, and some buttons. In total, a tree with a depth of max 4-5, and sane defaults so I never have to think about the "CSS rendering algorithm", divs, CSS selectors, Z-index or other useless details like that, which should be left to those designing a skin for the UI components library.
Web design hasn't caught up with desktop UI frameworks of 30 years ago.
Then, dive down into the concept of polyfills to understand what extra work everyone must go through to normalize the platform.
And then look at the features themselves. Web components is a good example. Theywere developed as a hack to extend toe current platform to catch up with basic features provided by JavaScript web frameworks. Except they are virtually unusable, unless they are made palatable with... JavaScript frameworks.
And lastly, compare that with the experience of just using a mainstream JavaScript framework. Any of them. It's world's of difference. JavaScript frameworks prioritize developer experience to the point they even went through great pains to have a xml-like DSL to make their javascript be seamless. Whereas things like web components go the opposite direction and make their platform's first class feature feel like vanilla javascript.
I've been involved in successful and unsuccessful platform builds. In the successful ones, I either had absolute authority or I built for the desire paths, even if they weren't the "perfect" ones that I desired. I anchored on the non-negotiables, which I kept to a minimum, and then optimized to get people on board, even if that meant deviating from my perfect vision.
One way to keep myself honest in being on the desire path was to go from win to win (win = someone using platform and being a satisifed "customer") iteratively as part of the full build. It also helps avoid platform fatigue, and ensures that should some priorities change, we've gotten some value out of the effort.
There is even a book mentioned here a number of years ago - a particulae favorite of mine - that features this as a plot point: Squares of the City by John Brunner
There was a genre of YouTube shorts about Minecraft desire paths. The videos showed increasingly ridiculous attempts at stopping the desire path from forming. The joke of course being that dedicated Minecraft players will somehow make their way even through the unbreakable bedrock. And the admin/owner has to give up.
Unfortunately, the browser is not a Minecraft server. It's a living standard that has to maintain backwards compatibility. The desire path (React, Svelte,...) will always exist. And so will the ridiculous way they tried to stop that.
> if you don't put sidewalks and pathways in the right places, people invent their own.
To expand on that a bit, you can deliberately avoid putting in paths so that the natural behaviour becomes clear. You'll see paths develop between areas that you might not have thought of. Pedestrians are flattening grass and showing connections that are actually useful rather than following lines that have been set out for them with competing priorities in mind like aesthetics or budgets. Then you take that data and create paths that "users" actually want, based on their behaviour / use of the previous system.
I definitely love this approach IRL. I think the closest you can get is watching what users try when they’re unfamiliar with the application. Sadly, it seems like actual user testing is rarer now than ever.
“UX Designers” seem to worship at the Jony Ive/Alan Dye altar of minimalism and “airiness” and tell anyone who will listen that every type of user, for every type of task, gets “overwhelmed” if you give them ‘too many choices,’ so instead of natural direct paths that people would have chosen, modern software is more like a series of white rooms with exactly three exits each, and the exits are labeled with an icon when they’re labeled at all (many are impossible to label because they’re swipe gestures), and other exits only appear when you step near them (the hover nonsense).
I can relate to this, but React definitely made things more fun for me at least.
Web Components on the other hand seemed to solve a problem that few actually were having, or for those that loathe React & modern frameworks because of bloat or whatever
> 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.
On my university campus there was a well-trod path across the grass where students would traverse in a beeline from their dorms to the cafeteria during mealtime.
Eventually they did put a walkway there. But for a time the only thing paving it was student footfalls.
I don't understand how WebComponents are such a poor idea. I have intentionally reached for them when building frontend code for most of my simple sites and they have been perfectly fine. Not great, but fine.
WebComponents do their job with little-to-no fuss, and they're universally available.
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.
> Your premise that the browser implementation is faster and better is rarely true.
I know that they’ve optimised this as much as they can, but it still seems to catch pretty much everybody by surprise that every single instance of a web component with a shadow DOM needs the site’s CSS reset added to it individually (or just skip it and keep forgetting that things like box-sizing will be inconsistent with your non-shadow-DOM styles). There’s no way to say “here’s my default styles” that will work consistently across the whole page once you start using web components. And then you have the !important fights between the web component and its contents as well.
Even though it’s been standard practice amongst web developers for 15+ years, the people working on the web platform seem to mostly act like CSS resets aren’t a thing.
The tension is between two kinds of CSS users. The ones who want cascading style sheets, and the ones who want scoped style sheets. And sometimes even people who think they want scope find out they also want the cascade, and just wanted to scope a bit "at the end" (something the cascade can do anyway)
I find that developers add a CSS reset without thinking about it as if there is always a need. We never used resets. There was never a need. Typically we would set something according to the design anyway and starting with a reset was like slamming something against one wall only to throw it back to a different wall later.
The history here, as I understand it, was that they imagined you would use custom elements from multiple third parties, so any shared CSS definitions would cause breakages.
fwiw, your comment would almost certainly have positive karma if you had left off the final paragraph. Asking for sources is popular here. Grousing about how you're oppressed by the dumb voters on the site is not.
Native date pickers can’t handle range. So then you need two date pickers with validation logic.
That’s just one example of the native implementation lacking common utility. That’s one thing they could mean when they say the native solution is lacking.
> Your premise that the browser implementation is faster and better is rarely true
Thankfully, this opinion is measurably false just by reviewing source code of any website. What you're referring to, primarily, are categories of elements like form elements like <datalist> and that's fair.
This is why the web community is asked to support improving the platform through submissions to Interop, such as this one for <datalist>
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.
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 haven’t found a front end library I like more than React except maybe Astro.
I didn’t really like Svelte and I am pretty opposed to htmx. It is certainly better than Angular and Vue, though Vue 3 is tolerable. Maybe there are more popular options nowadays but tbh I am not really looking to move from React. I have zero complaints other than maybe the push towards server rendering and partnering with Next.js
React is simple and I like that it feels a bit like FP. I love that I can write just about my entire application in TypeScript with all of the benefits that incurs. It requires some knowledge/discipline e.g. around useEffect.
If you care to use native browser APIs and features you can have lightweight, performant applications that behave well in the browser.
Most devs don’t do this, even with vibe coding. It’s a very easy way to filter for those who care about what they are building.
I have to step in here to say that, at least documentation wise, this is revisionist history.
The original react documentation is fine, but focused almost entirely on class components. What was there on hooks was either outdated or outright harmful.
It's not until 2023, 4 years after react hooks launched, that the new react docs which focused on them were released.
React has an incredible ecosystem, it's almost synonymous with web development. The available render backends alone, namely React Native, are currently unbeaten.
As interested as I may be in the alternatives, they simply don't have this.
> 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 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 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 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.
People are using things like lit and react not because web components suck but because they want something reactive (declarative UI bound to app state).
Web components are lower-level than that -- they can be one building block for this (e.g., lit), but don't accomplish it on their own.
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.
Not to piss on your experience, I use WebComponents for almost everything and they have a lot of issues (mostly they're not really integrated into a coherent model with the remaining things that always exist in their presence, the browser, DOM, lifecycles, requests, etc) but being slow can only be an issue of your implementation to be honest, it's an imperative model for the most part - in fact the reason why I've started using them was because it was much easier to make things fast easily - there's no way updating/replacing dom elements surgically is faster with any other framework.
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.
If you do this you might as well just write JavaScript without using WebComponents. APIs like innerHTML, querySelector, addEventListener have been around for decades.
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.
For starters, that it introduces weird special cases to DOM parsing and structure, thereby breaking .isEqualNode whenever <template> elements are present.
I think the problem is not what I don't like about WebComponents individually. The problem is that to use WebComponents, you have to use JavaScript anyway and if it does not do exactly what you wanted, then you're right there, in JS, ready to DIY the problem away.
If WebComponents were purely declarative, I would try harder to use them.
(preface by saying I use webcomponents regularly, I can show you a game that's currently online where they're used extensively)
I don't really understand why people are complaining that this is unmaintainable on the replies to this snippet but there's plenty of things with webcomponents in general that could be better done on the browser side.
For one the innerHTML (or some new method) should be able to reference a `template` directly. If you want to use templates you need to do:
And if you want to use templates then you need to render the templates in a part of the dom that is parsed before this JS is run - there's no way of specifying dependencies for this kind of things - which is a short-coming of the platform as a whole.
One the same topic there's no way of providing an url for retrieval of a fragment that contains templates and have it parsed directly and available to subsequent JS if you could do:
`<HTML-FRAGMENT href="/my-endpoint/returns-templates.html" required="true" id="MAIN_FRAGMENTS">` or doing `fetch("/my-endpoint/returns-templates.html", {DOCUMENT_ID="MAIN_FRAGMENTS")` would parse the result and make it available to the browser engine then you could have on subsequent JS:
`<script requires="MAIN_FRAGMENTS" wait="GLOBAL_LOADING_INDICATOR`>....</script>` or in a file/module `requires DOCUMENT_ID: MAIN_FRAGMENTS` and the file/script execution would block until that would be available, just that would go a long way. You could specify fragments (the component DOM templates to be used) that are needed for the webpage to work at all, fragments that would only show loading for their own content, etc (you could style the TAG with a pseudo-state indicator, so if it had a wait not resolved yet, CSS could target it with `MY-TAG:state(waiting)`).
Another issue is `attributeChangedCallback` - this doesn't take into account how most of the times one can/will update the attributes of an element, so it fires once for each change, even if you made X changes in one swoop, making it so that you have to have to make a more complex "update_render" function to work around that, or lots of small functions that are composable (ideally, but not practical or wanted in many cases where the whole thing is to be treated as a single update) or create a `batched_attributeChangedCallback` that you implement yourself as part of a class mixin and then extend the HTMLElement class on declaration and use that, because most of the times you want to re-do/update the whole component and when you have multiple properties (equivalent to react props and similar in other frameworks) and multiple components this can result in expensive updates to the page that the user feels as sluggish on their end. Something like:
`batched_attributeChangedCallback(attributes, old_values, new_values, batch_timer_window: 200, batch_timer_fn: true)` where the default for the batch window is 200ms, but can be provided a `fn` that does the evaluation to. So even if the updates are done independently but under the timer window they're batched instead of run 1 by 1 (or immediately if the `fn` returns true, defaulting to true when it's independent 1 by 1 updates).
I usually have a function `_set_handlers(boolean)` that is used on connected and disconnected callback but this is just plain js organisation:
And the connectedCallback just calls `this._set_handlers(true)` and disconnected `this._set_hanlders(false)`.
I use them, you can use them to great effect, but I think the biggest problem is the lack of connection between the different APIs. This includes things like indexDB as well, it's not very complex, but it does look messy on "first-glance". Like your example, but when you actually read it, it's pretty straightforward (ignoring the bad/non-existing functionality/APIs). The same with SSE. This could be a great solution for many things, but you always need to wire up yourself how it works. Would be great if you could declare "receiving beacons", at the page level, or component level, with automatic teardown on removal/navigation. So a component could have `static SSE_BEACONS() { ["https://something.com/path"] }` and would mark the state of the component automatically with `BEACONS: [WAITING | CONNECTED | ERROR]`
The loading indications, still seems strange that after 40 years of web development the transition between webpages are basically "white page", "freeze current view". Just having some way of specifying loading states would make any webpage feel 90% of a webapp between page transitions. Make it be a restricted subset of CSS that can be included as a header at the document top level and cached for subsequent visits `<LOADING_STYLES version=X><MAIN>background-color: white;</MAIN><LOADING_INDICATOR>shape: square; rotation: 1s; main-color: blue; secondary-color: turquoise</LOADING_INDICATOR></LOADING_STYLE>`. This would also allow to evolve it while maintaining strict backwards compatibility by starting from a very basic set of possible values - but just this would make website loading a much more app like experience. It could be used together with webcomponents too:
`<MY-WEBCOMPONENT ...><LOADING_STYLES>...</LOADING_STYLES></MY-WEBCOMPONENT>` that then could be automatically derived from the `states` I mentioned prior.
Anyway... Spent too much time with frameworks and webcomponents by now. It probably would also make writing code for LLMs less error prone.
Just a rant, don't take it too seriously, but sometimes I wonder with all the resources poured into frameworks by the big Gs, that must amount to millions and millions of dollars when you take into account the salaries some of the people working on them take, if it wouldn't have been better spent somewhere else on the "base" implementation.
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.
It’s surprising how bad the API is. Shadow DOM makes just about everything worse. Our frontend org opted out of even using Lit, so we get the raw stupidity of the whole idea.
Style encapsulation? You get that, but not fully, and good luck finding out which parts you don’t get.
State management? Back to query selectors, which btw work worse and need workarounds when reaching into the shadows. We went with DOM-as-state. I don’t want to talk about it.
Slots? After coming from a modern framework, slots are a clear step backwards. In React you can pass a component as a prop but in the shadow DOM world, you have to signify it with HTML. Multiply it by several slots and you get a lot of verbosity just to match the behavior.
Yet to mention using the platform directly means losing so much work around static verifiability. No one has to talk about this anymore, but sticking religiously to the platform by strictly using addEventListener means you can’t require event handlers to exist for any of your elements. People forget this, but the browser’s default way of letting you do anything is an enormous footgun for reliability.
Learn from our frontend org’s mistakes. Run, don’t walk, away from it.
How can you say react isn't bloated it requires a full download on first website visit, web components are browser native, not saying they're better, but to say react is not bloated is an affront , there was a time where people were carefully deciding on whether or not to include jquery.
WebComponents were created out of spite for react and are the composability equivalent of medieval artist drawing horses that look like they had never seen an horse
I don't understand why browser makers don't just steal the API from popular solutions like React honestly. That's "fair use" since Oracle v Google afterall.
As a user of native apps, I can always tell when the developer (or, often, the UI designer) chooses to "fight the platform" and reinvent things themselves, instead of embrace the platform and use what it provides for free. Developers who insist controls should look like their own vision, instead of what the platform provides (and users of that platform expect). Apps built this way always look/feel a bit weird and off. Keyboard shortcuts don't work like you'd expect. Accessibility functions that you normally get for free are missing. Controls behave just so slightly differently for them to be odd to work with. The app "sticks out" among the rest of your native apps, and usually not in a good way.
So you end up with situations like: My time picker looks exactly like I want it to look, but it doesn't handle leap seconds. And: My login form behaves exactly like the vision our PM dreamed up, but autofill doesn't work anymore.
Kinda funny I was trying to log into the network at a Hilton last night with a Steam Deck and I had to lie about my state and zip code because it took about a minute for the state dropdown to get populated with states and once I picked Ohio instead of New York, I couldn’t get the dropdown to open again so I looked up an Ohio zip. It was one of a number of small technical glitches on the trip including USB chargers that had bad connections and worked intermittently.
Accessibility is important to our customers where I work so it is important to us…. And I have spent so much time fighting with third party controls to get them to work right.
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.
GUI development in general is quite complex. You _can_ in principle compose a GUI from even simpler components: keyboard/mouse/touch events and blitting pixels to a screen, but this leaves you to do almost everything yourself. This is not only more work but also means there's a lot less consistency from GUI to GUI.
In the olden days, you would be expected to use the UI toolkit provided by the OS, which was designed to provide a consistent and complete implementation of each GUI element, which not only made things easier to navigate for users but also provided things like customizable theming and accessibility features more or less 'for free'. Nowadays it's much more like a free-for-all, and every application is just a little bit different, sometimes on purpose, sometimes just by accident. Accessibility is a complete crapshoot.
The web is similar. The people pushing for using 'the platform' are trying to capture exactly the same set of advantages as the old-school OS UIs, as well as the additional complication that we have a much more diverse set of devices with UIs nowadays.
> there are only three platforms: Blink/V8; WebKit/JavaScriptCore; and Geko/SpiderMonkey.
You’re misunderstanding the terminology here. The platform being talked about is the World-Wide Web and you are listing three implementations of the client part of the platform.
Probably the decisive difference is that the web needs to be delivered over network, while the OS is installed once and then is just there. If everyone needs to download your very special implementation of an otherwise pretty common type of widget, it becomes a nuisance and a waste of bandwidth.
> 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.
I always wonder if there could ever be a new css variant with less features that nevertheless can do everything that can be done today. Then you could imagine a migration where unnecessary CSS has to be implemented by poly fills and frameworks will be shamed into using the stricter subset
>For a functionality that can be composed out of existing APIs in a performant way, we do not add it in the platform
Why do standard libraries implement sorting and common data structures when they can be made from existing programming language features? The point of a platform isn't to expose the most minimal interface possible. It's to make it as easy as possible for people to use the platform.
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
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.
Not sure why you're being downvoted, this is basically the sole reason the web won as a development platform. You aren't tied to the platform's idea of what components should look like or how they behave, by default. You can take the Figma screens and make them exactly.
I don't see how that's true, you can absolutely do the same thing on the desktop? No one is forcing you to use the OS's default widgets there either, you can use Qt, Flutter, or even paint every single pixel yourself which is a lot less feasible on the web.
The main reason the web won is that you can ship SaaS without the user having to install anything locally, and there's no expectation of it being able to work offline, so you can offload processing to servers resulting in fewer bugs, compatibility issues, and DRM problems.
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.
This comment is at the same depth of analysis of saying that the only reason for python being successful is that universities started teaching it and then people no longer could do C++
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.
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.
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.
I always try to make HTML and CSS do the main work, while using HTML semantically. JS sprinkled on top where HTML/CSS won't perform the desired function (has gotten less over the years). And obviously server-side code where such a thing is needed.
But if I can get away with a static website that uses just HTML and CSS that is the baseline. And it has served me very well and produced very low (=zero) maintenance results.
They want the benefits of a browser with the capabilities of native code. At some point you have to ask yourself would it not just be easier to do this in a normal programming language.
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
This is the answer. I have a strong bias towards using the platform but very often you just can't because the platform has weird edge cases or inconsistent behaviour across browsers.
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.
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)
> 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.
> 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.
This is a crutch that people lean on to not use the right thing and use what they’re familiar with. Start with the browser default and change when it doesn’t work in that case.
When you tried to do that a few dozen times, and the outcome is always to build (and have to rebuild!) off platform, starting out off platform is the logical option.
Why should a developer learn 2 ways to do something when they could just learn 1. You are not improving the developer experience of the web by dictating that people have to learn 2. Either you make the native one capable enough to handle everything or you accept that people should just learn a javascript one that is capable of everything.
Yeah, the dialog thing is extremely annoying... I use them, and I always have to have a work-around for when morphdom replaces the dom nodes of a dialog because it will just make it disappear ... `non-programmatic-open=true` would solve it - yes, it can have edge cases but then it's a matter of me programming correctly, instead of programming work-arounds every time I need it.
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.)
> 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.
As far as I know React hasn't had any such breaking changes. Those were all added on top without removing anything. Class components without hooks still work fine, for example.
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.
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.
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.
One of the failure modes was it running out of GPU RAM because it tried to allocate (multiple!) pixel buffers on a m-pixels-per-n-real-world-meters basis(!), and repeatedly didn't see the problem with this despite it being a vector graph on a normal screen.
I only even noticed this bug due to another bug where it got the bounding box for Portsmouth badly wrong by including the entire length of the ferry routes to France.
If I didn't understand how to use the JS console, it would have been stuck saying "I can't reproduce the problem"; and if I didn't understand the way computer graphics work I wouldn't have been able to recognise that multi-gigabyte pixel buffers are not normal, nor would I have been able to recognise that in this case those particular buffers were totally redundant.
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.
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".
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).
<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.
~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.
The problem is that HTML, Javascript, and CSS are the wrong "low-level" abstractions. They are high-level abstractions that various web development technologies like React work around. The problem is that they try to provide a standard that solves every problem; and the market generally rejects that standard so it tries to work around it.
The right thing would be for the browser to expose much lower-level abstractions. Webassembly is a step in the right direction, but it needs an API other than HTML and calling back to Javascript.
I have been down the rabbit hole. React for a web app used for scheduling. I built my own React/Elm-like framework in Rust/WASM. Use react at work.
All my web sites / web apps now are HTML + CSS + targeted/native JS. No npm or build steps. And I don't hit any limitations. They load and run faster than ~99% of websites.
Because every product manager thinks they know better. I and other engineers have pushed back to "use the platform" for years and years and more often than not we get told to do something custom to please product's fantasies, because "the platform" doesn't implement some inane custom request. So we make something custom and worse at great expense of user experience/expectations, implementation cost, and maintainability.
The login site for my work does everything server side and serves up vanilla html that looks "from the 90s" in the context of present websites. After some slight adjustment, it's heavenly, a miracle of consistency and keyboard shortcuts.
And yeah, the thing is both designers and managers want a misable GUI that looks like a floating cloud. From their point of view, that is better. GUIs with little functionality but pointing the user at what they are supposed to do. Treating the user like a moron, not because the user inherently is one but it's convenient if they are.
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.
I think the question at this point is not why React was adopted, but why it still dominates despite overriding the platform in many ways, with all the downsides that entails.
IMO did not React necessarily originate a style of programming but was undeniably successful in packaging and documenting 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.
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
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
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.
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.
Safari 16 is not a reasonable target for the vast majority of developers.
Apple tends to support older iPhones in newer versions of iOS, and iPhone users upgrade their software a lot. The most common target is the last two major versions because people using older versions are so rare. Every iPhone released in the last nine years can upgrade to iOS 16 to get Safari 16.
If it makes sense for you to spend time supporting 0.25% of users rather than spending that time on the other 99.75% of users, then support Safari 16. Everybody else should avoid incurring that opportunity cost.
Every time I try to use the platform feature I get it working well in one or two browser on either desktop, android or iOS and then later find out it works pretty badly on one of the other platforms
Maybe I'm too old, but remember position sticky is relatively "new" and I was around when browsers didn't support it, yet everybody demanded for "affix" solution [0] (the buzzword you would search to find a jquery plugin). Internet Explorer never had position: sticky, and FF only introduced it in 2014. And I dealt with projects until around at least 2017/2018 where enterprise clients would make any webdev required to run on IE12 too.
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.
> 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".
My guess, based on my own and closely observed experiences, is that you can take a developer’s project history and carve out two pretty distinct categories that have huge significance: (1) projects they are most proud of and (2) projects that have the largest value/impact. I know for myself there is very little overlap in those groups.
The former being dominated by bespoke things that worked better than anything available at that time, but filled a tiny niche: “not using the platform”.
While the latter are the boring things that were built with unexciting bulletproof tools that keep churning and adding business value day after day, year after year: “using the platform”.
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.
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 deeply detest "wacky scrolling schemes where unusual things happen as you scroll down".
But I guess (some) people without much technical exposure might be impressed by them. My and my strong dislike of the UIs is based on aesthetics mostly, I don't even care to consider the technical horrors behind them.
It doesn't matter how often Safari released as long as updates keep on being tied to os updates. A large enough percentage of people do not upgrade their OS fast enough for new features to be broadly usable.
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.
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.
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.
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.
> 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
I think the core issue is that the platform was bad for a long time so tools sprung up to make it more manageable (from jQuery all the way up to React). Now the platform is much better but it’s too late: a meaningful share of web developers don’t really understand the DOM.
I’ve interviewed an incredible number of junior developers that really don’t understand what’s going on beneath the React level at all. I blame a lot of this on code bootcamps that never even tried to explain the fundamentals. Over time they’ve collapsed and AI is going to overwhelm that basic level of understanding. But a lot of it still persists.
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.
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.
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.
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.
Indeed, HTML is like the assembly language of the web: clunky and very limiting to use directly.
That's why we have to resort to all kinds of libs that render and manipulate HTML. And from there comes the need to bundle large amounts of JS with pages, and almost all other web development "sins"
A real pity, elevating HTML to be actually directly useful for rich interactive UIs should have been a primary activity of the relevant working groups.
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.
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.
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.
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).
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.
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".
> "In urban planning they have a concept called "desire paths""
If you're wondering what that looks like, people post pictures of them found in the wild on Reddit:
https://reddit.com/r/DesirePaths/
That's fascinating that it already had a term! The YC founder I used to work for was adamant that he came up with the term "idealized path" for this phenomenon.
Pathways is an urban open problem that companies like GoodMaps are trying to solve, although in a convoluted way (more sensors = more accuracy, but walled-garden is meh).
> The platform APIs were terrible.
In what way?
After doing this for more than 20 years I have asked that question hundreds of times and the answer is almost always about aesthetics, about 95%+. Of those aesthetics based conclusions most people cannot find their own way to handle it without waiting for somebody else to write a tool that provides the answer they were looking for. Even then the answer tends to be predicated on social acceptance more than technical evaluation. That is a training or human performance problem more than a technical problem. It says a lot about an industry where the people who are able to ask these kinds of questions realize its a training problem and are willing to raise salaries and assume tech debt as opposed to fixing a human capital problem for far less money.
At any rate there is something to be said for the developer who builds things on their own just for themselves. In many cases the result is faster, lighter, and more capable software than what they are paid to do for their employer. Their personal software isn't locked into conventions or abstractions beyond their control.
The APIs are expensive for storing state (read access on attributes) and expensive to write (so many ways to trigger reflows and paints) without a good way to batch them.
WCs have tons of boilerplate to them, such as extra song and dance to make attributes observable. In fact, a custom element can have an attribute and a property with the same name, and they are managed separately unless you explicitly set them up to sync. It's a terrible design.
Built-in things aren't extensible - there's no way to have a number type input that doesn't suck without doing it yourself, and then you need to opt into extra song and dance for your element to participate in form submission data.
There's a reason popular frameworks are popular. They're good enough, you can hire people who already know them, and you benefit from the maintainers fixing bugs for you.
On the platform, my code is split between HTML, JS and CSS files.
I like modules. They exist in some form or another in most programming languages and they are one of the few definitively good ideas in software engineering. Give me the ability to split off parts of my work with some public API and hidden internals. Works on different levels too, like with a reusable library that consists of modules.
JS has a module story. But HTML and CSS just aren't connected to it, without using something like JSX.
That's why I end up abandoning "using the platform" every time.
I dont know any other environment except the browser where code is split into three in a similar way.
I have worked on my own component libraries for HTML, but I don't like solving the same problems over and over and over again. I'd prefer a well-supported battle-tested library over my ad-hoc attempts.
The argument presented in the article here is that libraries like jQuery and React were useful, but now the browser has better APIs, so we should use them.
The browser indeed has a components API, but it is by the admission of many, fairly low-level as far as component APIs go. It doesn't really solve how to manage data flow or rendering in your components or application, and has many sore spots.
No problem. There is a pretty nice library called LitElement that provides solutions to some of these problems.
But then we're not really living off the land are we? We still need Lit in this case.
So what's wrong with WebComponents? Frankly, I think this is a bad question. A better question is why people think WebComponents competes with React to begin with. WebComponents intentionally fails to solve some of the most annoying problems with writing components because it is intended to be low-level and used by libraries like Polymer. Because of this, it leaves many problems open-ended. Like for example. WebComponents act like HTML elements. Cool? So you can pass data down using HTML attributes. Neat. Problem: HTML attributes are strings. Okay... So you either need to serialize everything to strings, or you have to pass objects through a separate side channel (usually properties that you assign separately.) In fact, generally speaking, writing WebComponents that compose other WebComponents is ass. I'm pretty sure it has been noted before that WebComponents works best for leaf components... So it would certainly not make a good replacement for a library like React, which is meant to be a substrate you can build large scale applications out of.
2 replies →
Most browser things live in a bubble of ignorance about what people are trying to build.
It's not overly ambitious to have rich text input fields or a sortable table. If you can have a half assed xpath implementation you can have a shopping cart and a product.
Someone knowledgable once ran off with a fumble of mine acting like I pulled gold from thin air.
It took the id's from the page, created strings with the same name containing the inner html, made a copy, compared the copy with the string every 50ms, if they were no longer the same the dom node and the copy were updated with the new value. Input fields compared the copy with the input value as well.
So you could do:<div id="myname">my name <div>
Then do myname += "John";
Or <div id="a">42<div><input id="b" value="123">
Then do a = a * b / 2
1 reply →
> In what way?
State management.
I have to track what items I want to remove, hide, show, alter, etc. in each handler.
That is a cumbersome mental model, which is why React, Angular, Vue, Svelte and every other web framework calculate that automatically for you.
To be clear: I don't necessarily begrudge the mutation APIs; but there's no way I'm going to use them directly for anything except very simple things.
2 replies →
The web platform is still garbage. I want something with the simplicity of Classic MacOS, or GTK2, where for e.g. a text editing page like a wiki, I have a toplevel "App" component, and inside a combination of VerticalBox, and HorizontalBox for layout, with a MenuBar on top and a TextBox on the bottom, and some buttons. In total, a tree with a depth of max 4-5, and sane defaults so I never have to think about the "CSS rendering algorithm", divs, CSS selectors, Z-index or other useless details like that, which should be left to those designing a skin for the UI components library. Web design hasn't caught up with desktop UI frameworks of 30 years ago.
> In what way?
For starters, you can start by checking https://caniuse.com .
Then, dive down into the concept of polyfills to understand what extra work everyone must go through to normalize the platform.
And then look at the features themselves. Web components is a good example. Theywere developed as a hack to extend toe current platform to catch up with basic features provided by JavaScript web frameworks. Except they are virtually unusable, unless they are made palatable with... JavaScript frameworks.
And lastly, compare that with the experience of just using a mainstream JavaScript framework. Any of them. It's world's of difference. JavaScript frameworks prioritize developer experience to the point they even went through great pains to have a xml-like DSL to make their javascript be seamless. Whereas things like web components go the opposite direction and make their platform's first class feature feel like vanilla javascript.
I've been involved in successful and unsuccessful platform builds. In the successful ones, I either had absolute authority or I built for the desire paths, even if they weren't the "perfect" ones that I desired. I anchored on the non-negotiables, which I kept to a minimum, and then optimized to get people on board, even if that meant deviating from my perfect vision.
One way to keep myself honest in being on the desire path was to go from win to win (win = someone using platform and being a satisifed "customer") iteratively as part of the full build. It also helps avoid platform fatigue, and ensures that should some priorities change, we've gotten some value out of the effort.
There is even a book mentioned here a number of years ago - a particulae favorite of mine - that features this as a plot point: Squares of the City by John Brunner
There was a genre of YouTube shorts about Minecraft desire paths. The videos showed increasingly ridiculous attempts at stopping the desire path from forming. The joke of course being that dedicated Minecraft players will somehow make their way even through the unbreakable bedrock. And the admin/owner has to give up.
Unfortunately, the browser is not a Minecraft server. It's a living standard that has to maintain backwards compatibility. The desire path (React, Svelte,...) will always exist. And so will the ridiculous way they tried to stop that.
The "fun" angle slots in perfectly with the other parallel false narrative about the devs who hate AI.
> if you don't put sidewalks and pathways in the right places, people invent their own.
To expand on that a bit, you can deliberately avoid putting in paths so that the natural behaviour becomes clear. You'll see paths develop between areas that you might not have thought of. Pedestrians are flattening grass and showing connections that are actually useful rather than following lines that have been set out for them with competing priorities in mind like aesthetics or budgets. Then you take that data and create paths that "users" actually want, based on their behaviour / use of the previous system.
I definitely love this approach IRL. I think the closest you can get is watching what users try when they’re unfamiliar with the application. Sadly, it seems like actual user testing is rarer now than ever.
“UX Designers” seem to worship at the Jony Ive/Alan Dye altar of minimalism and “airiness” and tell anyone who will listen that every type of user, for every type of task, gets “overwhelmed” if you give them ‘too many choices,’ so instead of natural direct paths that people would have chosen, modern software is more like a series of white rooms with exactly three exits each, and the exits are labeled with an icon when they’re labeled at all (many are impossible to label because they’re swipe gestures), and other exits only appear when you step near them (the hover nonsense).
1 reply →
> building things yourself is just more fun
I can relate to this, but React definitely made things more fun for me at least.
Web Components on the other hand seemed to solve a problem that few actually were having, or for those that loathe React & modern frameworks because of bloat or whatever
> 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.
On my university campus there was a well-trod path across the grass where students would traverse in a beeline from their dorms to the cafeteria during mealtime.
Eventually they did put a walkway there. But for a time the only thing paving it was student footfalls.
I don't understand how WebComponents are such a poor idea. I have intentionally reached for them when building frontend code for most of my simple sites and they have been perfectly fine. Not great, but fine.
WebComponents do their job with little-to-no fuss, and they're universally available.
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.
> Your premise that the browser implementation is faster and better is rarely true.
I know that they’ve optimised this as much as they can, but it still seems to catch pretty much everybody by surprise that every single instance of a web component with a shadow DOM needs the site’s CSS reset added to it individually (or just skip it and keep forgetting that things like box-sizing will be inconsistent with your non-shadow-DOM styles). There’s no way to say “here’s my default styles” that will work consistently across the whole page once you start using web components. And then you have the !important fights between the web component and its contents as well.
Even though it’s been standard practice amongst web developers for 15+ years, the people working on the web platform seem to mostly act like CSS resets aren’t a thing.
The tension is between two kinds of CSS users. The ones who want cascading style sheets, and the ones who want scoped style sheets. And sometimes even people who think they want scope find out they also want the cascade, and just wanted to scope a bit "at the end" (something the cascade can do anyway)
2 replies →
I find that developers add a CSS reset without thinking about it as if there is always a need. We never used resets. There was never a need. Typically we would set something according to the design anyway and starting with a reset was like slamming something against one wall only to throw it back to a different wall later.
3 replies →
The history here, as I understand it, was that they imagined you would use custom elements from multiple third parties, so any shared CSS definitions would cause breakages.
See eg the (now removed) HTML imports standard.
[flagged]
fwiw, your comment would almost certainly have positive karma if you had left off the final paragraph. Asking for sources is popular here. Grousing about how you're oppressed by the dumb voters on the site is not.
5 replies →
Native date pickers can’t handle range. So then you need two date pickers with validation logic.
That’s just one example of the native implementation lacking common utility. That’s one thing they could mean when they say the native solution is lacking.
6 replies →
What would you expect a designer to measure when making an aesthetic judgement?
[dead]
> Your premise that the browser implementation is faster and better is rarely true
Thankfully, this opinion is measurably false just by reviewing source code of any website. What you're referring to, primarily, are categories of elements like form elements like <datalist> and that's fair.
This is why the web community is asked to support improving the platform through submissions to Interop, such as this one for <datalist>
https://github.com/web-platform-tests/interop/issues/1402
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.
> pretending like they invented FP
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.
3 replies →
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).
13 replies →
I haven’t found a front end library I like more than React except maybe Astro.
I didn’t really like Svelte and I am pretty opposed to htmx. It is certainly better than Angular and Vue, though Vue 3 is tolerable. Maybe there are more popular options nowadays but tbh I am not really looking to move from React. I have zero complaints other than maybe the push towards server rendering and partnering with Next.js
React is simple and I like that it feels a bit like FP. I love that I can write just about my entire application in TypeScript with all of the benefits that incurs. It requires some knowledge/discipline e.g. around useEffect.
If you care to use native browser APIs and features you can have lightweight, performant applications that behave well in the browser.
Most devs don’t do this, even with vibe coding. It’s a very easy way to filter for those who care about what they are building.
I have to step in here to say that, at least documentation wise, this is revisionist history.
The original react documentation is fine, but focused almost entirely on class components. What was there on hooks was either outdated or outright harmful.
It's not until 2023, 4 years after react hooks launched, that the new react docs which focused on them were released.
React has an incredible ecosystem, it's almost synonymous with web development. The available render backends alone, namely React Native, are currently unbeaten.
As interested as I may be in the alternatives, they simply don't have this.
3 replies →
> 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.)
1 reply →
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 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").
3 replies →
> They ran react conferences, teaching everyone who would listen about "1 way data flows" and pretending like they invented FP.
When you have to resort to outright lying about something it's usually a good sign your argument is flawed.
> 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.
People are using things like lit and react not because web components suck but because they want something reactive (declarative UI bound to app state).
Web components are lower-level than that -- they can be one building block for this (e.g., lit), but don't accomplish it on their own.
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.
Not to piss on your experience, I use WebComponents for almost everything and they have a lot of issues (mostly they're not really integrated into a coherent model with the remaining things that always exist in their presence, the browser, DOM, lifecycles, requests, etc) but being slow can only be an issue of your implementation to be honest, it's an imperative model for the most part - in fact the reason why I've started using them was because it was much easier to make things fast easily - there's no way updating/replacing dom elements surgically is faster with any other framework.
What do you not like about WebComponents?
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...
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.
1 reply →
This is a very simple component, and its already a mess.
Something with more HTML and javascript is going to be a nightmare.
Then theres the problem of sharing state, the world is far more complicated than something simple in isolation.
If you do this you might as well just write JavaScript without using WebComponents. APIs like innerHTML, querySelector, addEventListener have been around for decades.
Here's equivalent svelve code. I can't format it correctly because I'm on mobile but even without proper indentation it's easy to read.
<script> let count = $state(0); let dialog; </script>
<button onclick={() => { count++; dialog.showModal(); }}> :) </button>
<dialog bind:this={dialog}> <p>Hello, I was clicked {count} times</p> <form method="dialog"><button>Close</button></form> </dialog>
2 replies →
WebComponents are some of the coolest APIs on the web if you ignore all the ways they fall short and make everything else harder
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.
- I still don't like it despite that.
6 replies →
For starters, that it introduces weird special cases to DOM parsing and structure, thereby breaking .isEqualNode whenever <template> elements are present.
> The webcomponent code seens quite sane to me
If that's a joke, it passed over everybody's head here. I can't imagine it's serious, but it still doesn't sound like a joke to me.
If that is what sane web component code looks like, I never want to use it ever.
>What do you not like about WebComponents?
I think the problem is not what I don't like about WebComponents individually. The problem is that to use WebComponents, you have to use JavaScript anyway and if it does not do exactly what you wanted, then you're right there, in JS, ready to DIY the problem away.
If WebComponents were purely declarative, I would try harder to use them.
Why are your component styles global not encapsulated within the component?
(preface by saying I use webcomponents regularly, I can show you a game that's currently online where they're used extensively)
I don't really understand why people are complaining that this is unmaintainable on the replies to this snippet but there's plenty of things with webcomponents in general that could be better done on the browser side.
For one the innerHTML (or some new method) should be able to reference a `template` directly. If you want to use templates you need to do:
``` const template = document.getElementById("templates-materialization-base").content;
this.appendChild(template.cloneNode(true)); ```
And if you want to use templates then you need to render the templates in a part of the dom that is parsed before this JS is run - there's no way of specifying dependencies for this kind of things - which is a short-coming of the platform as a whole.
One the same topic there's no way of providing an url for retrieval of a fragment that contains templates and have it parsed directly and available to subsequent JS if you could do:
`<HTML-FRAGMENT href="/my-endpoint/returns-templates.html" required="true" id="MAIN_FRAGMENTS">` or doing `fetch("/my-endpoint/returns-templates.html", {DOCUMENT_ID="MAIN_FRAGMENTS")` would parse the result and make it available to the browser engine then you could have on subsequent JS:
`<script requires="MAIN_FRAGMENTS" wait="GLOBAL_LOADING_INDICATOR`>....</script>` or in a file/module `requires DOCUMENT_ID: MAIN_FRAGMENTS` and the file/script execution would block until that would be available, just that would go a long way. You could specify fragments (the component DOM templates to be used) that are needed for the webpage to work at all, fragments that would only show loading for their own content, etc (you could style the TAG with a pseudo-state indicator, so if it had a wait not resolved yet, CSS could target it with `MY-TAG:state(waiting)`).
Another issue is `attributeChangedCallback` - this doesn't take into account how most of the times one can/will update the attributes of an element, so it fires once for each change, even if you made X changes in one swoop, making it so that you have to have to make a more complex "update_render" function to work around that, or lots of small functions that are composable (ideally, but not practical or wanted in many cases where the whole thing is to be treated as a single update) or create a `batched_attributeChangedCallback` that you implement yourself as part of a class mixin and then extend the HTMLElement class on declaration and use that, because most of the times you want to re-do/update the whole component and when you have multiple properties (equivalent to react props and similar in other frameworks) and multiple components this can result in expensive updates to the page that the user feels as sluggish on their end. Something like:
`batched_attributeChangedCallback(attributes, old_values, new_values, batch_timer_window: 200, batch_timer_fn: true)` where the default for the batch window is 200ms, but can be provided a `fn` that does the evaluation to. So even if the updates are done independently but under the timer window they're batched instead of run 1 by 1 (or immediately if the `fn` returns true, defaulting to true when it's independent 1 by 1 updates).
I usually have a function `_set_handlers(boolean)` that is used on connected and disconnected callback but this is just plain js organisation:
``` _set_handlers(toggle) { let act = toggle ? "addEventListener" : "removeEventListener";
} ```
And the connectedCallback just calls `this._set_handlers(true)` and disconnected `this._set_hanlders(false)`.
I use them, you can use them to great effect, but I think the biggest problem is the lack of connection between the different APIs. This includes things like indexDB as well, it's not very complex, but it does look messy on "first-glance". Like your example, but when you actually read it, it's pretty straightforward (ignoring the bad/non-existing functionality/APIs). The same with SSE. This could be a great solution for many things, but you always need to wire up yourself how it works. Would be great if you could declare "receiving beacons", at the page level, or component level, with automatic teardown on removal/navigation. So a component could have `static SSE_BEACONS() { ["https://something.com/path"] }` and would mark the state of the component automatically with `BEACONS: [WAITING | CONNECTED | ERROR]`
The loading indications, still seems strange that after 40 years of web development the transition between webpages are basically "white page", "freeze current view". Just having some way of specifying loading states would make any webpage feel 90% of a webapp between page transitions. Make it be a restricted subset of CSS that can be included as a header at the document top level and cached for subsequent visits `<LOADING_STYLES version=X><MAIN>background-color: white;</MAIN><LOADING_INDICATOR>shape: square; rotation: 1s; main-color: blue; secondary-color: turquoise</LOADING_INDICATOR></LOADING_STYLE>`. This would also allow to evolve it while maintaining strict backwards compatibility by starting from a very basic set of possible values - but just this would make website loading a much more app like experience. It could be used together with webcomponents too: `<MY-WEBCOMPONENT ...><LOADING_STYLES>...</LOADING_STYLES></MY-WEBCOMPONENT>` that then could be automatically derived from the `states` I mentioned prior.
Anyway... Spent too much time with frameworks and webcomponents by now. It probably would also make writing code for LLMs less error prone.
Just a rant, don't take it too seriously, but sometimes I wonder with all the resources poured into frameworks by the big Gs, that must amount to millions and millions of dollars when you take into account the salaries some of the people working on them take, if it wouldn't have been better spent somewhere else on the "base" implementation.
[dead]
What about the web components APIs are bad, and how could they be done differently given the reality of the existing platform?
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.
1 reply →
Components without ShadowDOM not having a slot is the biggest known issue.
3 replies →
It’s surprising how bad the API is. Shadow DOM makes just about everything worse. Our frontend org opted out of even using Lit, so we get the raw stupidity of the whole idea.
Style encapsulation? You get that, but not fully, and good luck finding out which parts you don’t get.
State management? Back to query selectors, which btw work worse and need workarounds when reaching into the shadows. We went with DOM-as-state. I don’t want to talk about it.
Slots? After coming from a modern framework, slots are a clear step backwards. In React you can pass a component as a prop but in the shadow DOM world, you have to signify it with HTML. Multiply it by several slots and you get a lot of verbosity just to match the behavior.
Yet to mention using the platform directly means losing so much work around static verifiability. No one has to talk about this anymore, but sticking religiously to the platform by strictly using addEventListener means you can’t require event handlers to exist for any of your elements. People forget this, but the browser’s default way of letting you do anything is an enormous footgun for reliability.
Learn from our frontend org’s mistakes. Run, don’t walk, away from it.
How can you say react isn't bloated it requires a full download on first website visit, web components are browser native, not saying they're better, but to say react is not bloated is an affront , there was a time where people were carefully deciding on whether or not to include jquery.
> web components are browser native
I would say very few people are using bare web component. They'll be using a library like Lit at the very least, so your argument is moot.
> full download
Like 50kb. Roughly the same size as Amazon website's icon sheet.
WebComponents were created out of spite for react and are the composability equivalent of medieval artist drawing horses that look like they had never seen an horse
Stencil or Lit are basically required, yeah.
I don't understand why browser makers don't just steal the API from popular solutions like React honestly. That's "fair use" since Oracle v Google afterall.
Only if you mean React before they went crazy with hooks and "use whatever" magic strings.
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.
As a user of native apps, I can always tell when the developer (or, often, the UI designer) chooses to "fight the platform" and reinvent things themselves, instead of embrace the platform and use what it provides for free. Developers who insist controls should look like their own vision, instead of what the platform provides (and users of that platform expect). Apps built this way always look/feel a bit weird and off. Keyboard shortcuts don't work like you'd expect. Accessibility functions that you normally get for free are missing. Controls behave just so slightly differently for them to be odd to work with. The app "sticks out" among the rest of your native apps, and usually not in a good way.
So you end up with situations like: My time picker looks exactly like I want it to look, but it doesn't handle leap seconds. And: My login form behaves exactly like the vision our PM dreamed up, but autofill doesn't work anymore.
Kinda funny I was trying to log into the network at a Hilton last night with a Steam Deck and I had to lie about my state and zip code because it took about a minute for the state dropdown to get populated with states and once I picked Ohio instead of New York, I couldn’t get the dropdown to open again so I looked up an Ohio zip. It was one of a number of small technical glitches on the trip including USB chargers that had bad connections and worked intermittently.
Accessibility is important to our customers where I work so it is important to us…. And I have spent so much time fighting with third party controls to get them to work right.
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.
GUI development in general is quite complex. You _can_ in principle compose a GUI from even simpler components: keyboard/mouse/touch events and blitting pixels to a screen, but this leaves you to do almost everything yourself. This is not only more work but also means there's a lot less consistency from GUI to GUI.
In the olden days, you would be expected to use the UI toolkit provided by the OS, which was designed to provide a consistent and complete implementation of each GUI element, which not only made things easier to navigate for users but also provided things like customizable theming and accessibility features more or less 'for free'. Nowadays it's much more like a free-for-all, and every application is just a little bit different, sometimes on purpose, sometimes just by accident. Accessibility is a complete crapshoot.
The web is similar. The people pushing for using 'the platform' are trying to capture exactly the same set of advantages as the old-school OS UIs, as well as the additional complication that we have a much more diverse set of devices with UIs nowadays.
> In the olden days, you would be expected to use the UI toolkit provided by the OS
That’s still (IMHO) the best place to start.
This point came home recently in doing a little macro to load a directory of GeoJSON documents into QGIS.
You need to load the Python console to get the proper environment, and you can't just say logger.debug() to get a trace.
This is because QGIS runs in the Qt event loop.
Big cluebat: QGIS (qualitatively, and for the regular pythonista) is like doing everything via asyncio.
Ah, so: no wonder it's such a challenge.
1 reply →
> there are only three platforms: Blink/V8; WebKit/JavaScriptCore; and Geko/SpiderMonkey.
You’re misunderstanding the terminology here. The platform being talked about is the World-Wide Web and you are listing three implementations of the client part of the platform.
You are the one misunderstanding my point.
There ARE ONLY THREE implementations of the client platform.
I would like for there to be a hundred, and there would be if the platform was simpler, but its not, so there won't.
4 replies →
Probably the decisive difference is that the web needs to be delivered over network, while the OS is installed once and then is just there. If everyone needs to download your very special implementation of an otherwise pretty common type of widget, it becomes a nuisance and a waste of bandwidth.
But libraries can be GET'ed from common URLs and cached!
1 reply →
> 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 web has a gazillion libraries...
Yeah exactly. So does native. So what? Why is this a bad thing?
3 replies →
I always wonder if there could ever be a new css variant with less features that nevertheless can do everything that can be done today. Then you could imagine a migration where unnecessary CSS has to be implemented by poly fills and frameworks will be shamed into using the stricter subset
>For a functionality that can be composed out of existing APIs in a performant way, we do not add it in the platform
Why do standard libraries implement sorting and common data structures when they can be made from existing programming language features? The point of a platform isn't to expose the most minimal interface possible. It's to make it as easy as possible for people to use the platform.
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
The vast majority of the patterns in the ARIA APG require bespoke JS plumbing for proper focus management, keyboard controls, and etc.
Isn’t datalist doing that? Last time I had to build a combo search box I was pleasantly surprised to learn about it
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.
Not sure why you're being downvoted, this is basically the sole reason the web won as a development platform. You aren't tied to the platform's idea of what components should look like or how they behave, by default. You can take the Figma screens and make them exactly.
I don't see how that's true, you can absolutely do the same thing on the desktop? No one is forcing you to use the OS's default widgets there either, you can use Qt, Flutter, or even paint every single pixel yourself which is a lot less feasible on the web.
The main reason the web won is that you can ship SaaS without the user having to install anything locally, and there's no expectation of it being able to work offline, so you can offload processing to servers resulting in fewer bugs, compatibility issues, and DRM problems.
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.
This comment is at the same depth of analysis of saying that the only reason for python being successful is that universities started teaching it and then people no longer could do C++
How is tailwind and shadcn worse than platform? It speeds up development by orders of magnitude.
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.
2 replies →
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.
Been there. Jquery broke. Ended up writing basic DOM manipulation in JS. Has worked fine for 15 years!
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.
I always try to make HTML and CSS do the main work, while using HTML semantically. JS sprinkled on top where HTML/CSS won't perform the desired function (has gotten less over the years). And obviously server-side code where such a thing is needed.
But if I can get away with a static website that uses just HTML and CSS that is the baseline. And it has served me very well and produced very low (=zero) maintenance results.
The insane double think of web dev...
They want the benefits of a browser with the capabilities of native code. At some point you have to ask yourself would it not just be easier to do this in a normal programming language.
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
Ever used a time field in pure html? And then you get reports users can enter 99 minutes.
Yes that's why
This is the answer. I have a strong bias towards using the platform but very often you just can't because the platform has weird edge cases or inconsistent behaviour across browsers.
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.
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)
1 reply →
> 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.
> 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.
This is a crutch that people lean on to not use the right thing and use what they’re familiar with. Start with the browser default and change when it doesn’t work in that case.
When you tried to do that a few dozen times, and the outcome is always to build (and have to rebuild!) off platform, starting out off platform is the logical option.
Why should a developer learn 2 ways to do something when they could just learn 1. You are not improving the developer experience of the web by dictating that people have to learn 2. Either you make the native one capable enough to handle everything or you accept that people should just learn a javascript one that is capable of everything.
Yeah, the dialog thing is extremely annoying... I use them, and I always have to have a work-around for when morphdom replaces the dom nodes of a dialog because it will just make it disappear ... `non-programmatic-open=true` would solve it - yes, it can have edge cases but then it's a matter of me programming correctly, instead of programming work-arounds every time I need it.
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.)
> 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.
As far as I know React hasn't had any such breaking changes. Those were all added on top without removing anything. Class components without hooks still work fine, for example.
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.
An aside: This name an logo are incredible. https://bevacqua.github.io/dragula/
An aside: drag and drop doesn’t work on iOS Safari well at all - dragging also pans the viewport.
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.
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.
Do you really need to know the language or is it enough to bother asking about improving the loading time or customizing the look?
You need to know.
Here's an isochrone map renderer I got Claude to make: https://benwheatley.github.io/Isochrone/web/?region=berlin&s...
One of the failure modes was it running out of GPU RAM because it tried to allocate (multiple!) pixel buffers on a m-pixels-per-n-real-world-meters basis(!), and repeatedly didn't see the problem with this despite it being a vector graph on a normal screen.
I only even noticed this bug due to another bug where it got the bounding box for Portsmouth badly wrong by including the entire length of the ferry routes to France.
If I didn't understand how to use the JS console, it would have been stuck saying "I can't reproduce the problem"; and if I didn't understand the way computer graphics work I wouldn't have been able to recognise that multi-gigabyte pixel buffers are not normal, nor would I have been able to recognise that in this case those particular buffers were totally redundant.
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.
What do you mean by “squishy and satisfying”? Otherwise it’s easy.
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".
One can also ask why that is needed and how it will make product better. Is that the highest priority to move a border three pixels to the left?
Well, people caught in the Apple universe seem to be capable of going pretty berserk about a few pixels left or right.
I don't think anyone was ever able to talk reason into them.
Just do what you're paid to do codemonkey and stop arguing
1 reply →
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).
<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.
~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.
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.
The problem is that HTML, Javascript, and CSS are the wrong "low-level" abstractions. They are high-level abstractions that various web development technologies like React work around. The problem is that they try to provide a standard that solves every problem; and the market generally rejects that standard so it tries to work around it.
The right thing would be for the browser to expose much lower-level abstractions. Webassembly is a step in the right direction, but it needs an API other than HTML and calling back to Javascript.
I have been down the rabbit hole. React for a web app used for scheduling. I built my own React/Elm-like framework in Rust/WASM. Use react at work.
All my web sites / web apps now are HTML + CSS + targeted/native JS. No npm or build steps. And I don't hit any limitations. They load and run faster than ~99% of websites.
Because every product manager thinks they know better. I and other engineers have pushed back to "use the platform" for years and years and more often than not we get told to do something custom to please product's fantasies, because "the platform" doesn't implement some inane custom request. So we make something custom and worse at great expense of user experience/expectations, implementation cost, and maintainability.
Not that I'm bitter about it or anything.
The login site for my work does everything server side and serves up vanilla html that looks "from the 90s" in the context of present websites. After some slight adjustment, it's heavenly, a miracle of consistency and keyboard shortcuts.
And yeah, the thing is both designers and managers want a misable GUI that looks like a floating cloud. From their point of view, that is better. GUIs with little functionality but pointing the user at what they are supposed to do. Treating the user like a moron, not because the user inherently is one but it's convenient if they are.
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.
I think the question at this point is not why React was adopted, but why it still dominates despite overriding the platform in many ways, with all the downsides that entails.
IMO did not React necessarily originate a style of programming but was undeniably successful in packaging and documenting 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.
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
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
Often it's that the internal platform isn't very good and not worth the trouble.
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.
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
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.
Safari 16 is not a reasonable target for the vast majority of developers.
Apple tends to support older iPhones in newer versions of iOS, and iPhone users upgrade their software a lot. The most common target is the last two major versions because people using older versions are so rare. Every iPhone released in the last nine years can upgrade to iOS 16 to get Safari 16.
You can download a CSV here to explore the data: https://gs.statcounter.com/browser-version-market-share#week...
Baseline’s support window for “Widely available” is 30 months and Safari 16 is almost twice that age: https://web-platform-dx.github.io/baseline/
If it makes sense for you to spend time supporting 0.25% of users rather than spending that time on the other 99.75% of users, then support Safari 16. Everybody else should avoid incurring that opportunity cost.
This is a very bad take. There is millions and millions of devices on Safari 16.
Thinking of it as 0.25% of users is also very narrow way of thinking, 0.25% of what kind of users? who is your demographic?
1 reply →
Every time I try to use the platform feature I get it working well in one or two browser on either desktop, android or iOS and then later find out it works pretty badly on one of the other platforms
> If you search for “sticky positioning” on npm, there’s no package that says “just use CSS position: sticky, you dolt.”
You could maybe find a component that all it does is apply position:sticky though?
Maybe I'm too old, but remember position sticky is relatively "new" and I was around when browsers didn't support it, yet everybody demanded for "affix" solution [0] (the buzzword you would search to find a jquery plugin). Internet Explorer never had position: sticky, and FF only introduced it in 2014. And I dealt with projects until around at least 2017/2018 where enterprise clients would make any webdev required to run on IE12 too.
[0]: https://www.w3schools.com/bootstrap/bootstrap_affix.asp
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.
> 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".
My guess, based on my own and closely observed experiences, is that you can take a developer’s project history and carve out two pretty distinct categories that have huge significance: (1) projects they are most proud of and (2) projects that have the largest value/impact. I know for myself there is very little overlap in those groups.
The former being dominated by bespoke things that worked better than anything available at that time, but filled a tiny niche: “not using the platform”.
While the latter are the boring things that were built with unexciting bulletproof tools that keep churning and adding business value day after day, year after year: “using the platform”.
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.
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 deeply detest "wacky scrolling schemes where unusual things happen as you scroll down".
But I guess (some) people without much technical exposure might be impressed by them. My and my strong dislike of the UIs is based on aesthetics mostly, I don't even care to consider the technical horrors behind them.
> 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
It doesn't matter how often Safari released as long as updates keep on being tied to os updates. A large enough percentage of people do not upgrade their OS fast enough for new features to be broadly usable.
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.
Extreme apathy towards "learn to do it yourself" is exactly why "AI" is so popular right in programming right now.
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.
3 replies →
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.
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.
People really used to search for “sticky positioning” or things like that on npm?
I always just googled stuff, now I prompt
> 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
> the platform abadoned us(and I also have a thinfoil hat theory about that)
Care to share? Genuinely curious.
Because they learned top down instead of bottom up and are stuck
I think the core issue is that the platform was bad for a long time so tools sprung up to make it more manageable (from jQuery all the way up to React). Now the platform is much better but it’s too late: a meaningful share of web developers don’t really understand the DOM.
I’ve interviewed an incredible number of junior developers that really don’t understand what’s going on beneath the React level at all. I blame a lot of this on code bootcamps that never even tried to explain the fundamentals. Over time they’ve collapsed and AI is going to overwhelm that basic level of understanding. But a lot of it still persists.
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.
Which app?
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.
"use the platform" is a short version of "use the platform, it is good enough, trust me bro".
And the only reasonable answer is: "No."
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.
8 replies →
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.
Indeed, HTML is like the assembly language of the web: clunky and very limiting to use directly.
That's why we have to resort to all kinds of libs that render and manipulate HTML. And from there comes the need to bundle large amounts of JS with pages, and almost all other web development "sins"
A real pity, elevating HTML to be actually directly useful for rich interactive UIs should have been a primary activity of the relevant working groups.
Friends don't let friends use npm
Same reason they don't use any platform. It's not as good as you think.
The platform sucks, still does, it's very simple. If you used native elements for everything, the users would complain that your website sucks ass.
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?
The Platform doesn't provide much tooling to aid development, it remains in isolation
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.
[dead]
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.
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.
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).
[flagged]
[flagged]
[flagged]
[dead]
[flagged]
[flagged]
[flagged]
[flagged]
I don't necessarily disagree with you on some of your points, but your tone seems to me to be unproductive and at odds with the norms of this forum.
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?
I guess static HTML is easy to scrape
This looks like a backend engineers take.
I must say it was worth reading , thanks for sharing your insights !!
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.
I’m not sure why people are talking about web components seeing as they aren’t mentioned in the article a single time.
Anyway, my complaint is about the troglodytes who refuse to learn CSS, and who promote troglodism in the form of tailwind and similar antipatterns.