I don't really think that React is necessarily the best possible library, but there is certainly more to a UI library than simply compiling out the need for diffing. For one thing, I find JSX to be a relatively unobtrusive addition to the language. It is implemented by a variety of things and is a pretty simple transform as far as things go; basically pure sugar, it's possible to avoid it if you want. It could be better designed than it is, but I think it's at least sufficiently general - it is feasible to say, use an alternate library with JSX, like Preact.

Svelte on the other hand by its nature just simply requires a more complicated compiler step to work and deliver on its promises. That's a trade-off. Whether you think it's worth it is up to you, but presenting it as an objectively technically superior design is disingenuous. Superior how? Runtime costs? Sure, but it does beg the question how much. Will a well-optimized Svelte app feel much better than a well-optimized React app?

> The amount of hype around it made it really feel like the next big thing.

We are a really long way away from the hype of React. I would argue that hype stopped carrying React a long time ago. Momentum? Sure, but if something was truly dramatically better, then I think it would have a fair shake at beating out React.

The problem is that the web isn't microbenchmarks and developer experience does matter to some degree, so the trade-offs that seem so good on paper don't always pan out.

I'm not a hater of Svelte. On paper, it is a very elegant idea. However, when I actually tried to use it, I genuinely came out feeling that it was simply not for me, and the benefits it has are not enticing enough for me to continue experimenting. My React apps are not particularly slow or bad at handling huge amounts of data. (One of my apps has no problem handling a file grid of over 1 million items, and in fact, I run into issues with browsers not being able to handle a large enough scroll area long before performance of my React code is a problem. That is good enough for me.)

Talking about one-way data flows was an excellent way to speak to a lot of tortured souls at the time (who had just found out they were going to be forced to migrate their projects to something else anyway due to Google's absolutely insane "we're deprecating this, we'll have a replacement for it at... some point, good luck").

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.

As interested as I may be in the alternatives, they simply don't have this.

When you have to resort to outright lying about something it's usually a good sign your argument is flawed.

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.

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.

Make it have an initial count via attributes, sync it with the DOM so if the attribute changes the count resets, and make the JS property always match the attribute (and vice-versa) so it behaves sanely. You're in for a world of pain even for something as simple as this.

Plus they're not declarative: you will only make me use innerText-based updates by threatening me and my family.

Plus they only work with JS enabled, while I can use JSX in SSR.

I've worked extensively with Web Components. They suck.

- HTML in a string. No syntax checks. If you interpolate it, you have to escape manually or you could create trivial XSS vulnerabilities. Your editor will probably not syntax highlight it, making it harder to tell when you break it.

- Manually formatted update logic that is redundant with the string. Not so bad here, but try formulating a practical large component.

- Completely ad-hoc state management, no reconciliation. Again, fine for Hello World, not fine after that.

Using raw WebComponents, your application has to care about all of this on its own and more. You can use templates and slots (which you should) but that makes this even messier IMO and brings back the split that React became famous for getting rid of. We left manual DOM reconciliation, ad-hoc data flow and non-reactive components that manually call a render routine at arbitrary points for a reason: it sucked. It made for buggier, harder to maintain code. It can be done, but usually any decent app will wind up encapsulating patterns into utilities that get reused. And... That's precisely why we want a good library. That's what I want, a library that packages up good reusable patterns for constructing UIs effectively.

And that's exactly my point, which is WebComponents or not, the solution is still basically the same, use libraries. Which begs the question: if I have to use Lit, what is the point of "using the platform"? What is WebComponents doing for me here that React wouldn't be? And in my case, I struggle to see it.

Interoperability? The old way of embedding external components works quite fine. Switching APIs where you pass a DOM node for something to mount into and get back an object with an API to one where you instantiate a component and communicate via properties and events feels like a strictly lateral move. I can't think of a condition where this would be particularly more convenient, but I can think of some where it is actually less. Next.

Isolation? Yes, WebComponents does add tools to provide better isolation between components. For some use cases this is a genuinely useful feature, although it also isn't without tradeoffs (I mean, the flexibility of having things be not isolated comes in clutch sometimes, it's hard to argue this.) But I use React primarily to construct components in an application, where I find this property more undesirable than desirable.

The one thing I thought could be cool with WebComponents is if you could build them in pure HTML when you only needed basic templating, but no: the design they went with always requires subclassing in JS AFAIK.

I could go on and get more specific, but I feel like people will pick everything I just said apart quite enough. I hope I'm at least able to make the case that:

- I do in fact, get the general gist of WebComponents.

- I still don't like it despite that.

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.

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";

  window[act]("some-window-event", this._maybe_ready);
  this[act]("some-component-event", this._some_fun.bind(this));

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.

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

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.

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.

For one, they can stop pretending that JS and the DOM are two completely separate entities, and lock the two working groups in a basement until they figure out a sane way to do reactivity, natively, that actually works.

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

Like 50kb. Roughly the same size as Amazon website's icon sheet.

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.

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?

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.

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.

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.

That’s still (IMHO) the best place to start.

I don't think anyone was ever able to talk reason into them.

See eg the (now removed) HTML imports standard.

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.

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