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

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

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

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

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

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.

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>

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

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.

    this.innerHTML = html`Hello ${name}!`

    function html(strings, ...values) {
      let result = strings[0];
      for (let i = 0; i < values.length; i++) {
        result += escapeHtml(values[i]);
        result += strings[i + 1];
      }
      return result;
    }

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.

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

  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.

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?

[dead]

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.

Components without ShadowDOM not having a slot is the biggest known issue.

If you are referring to how SSR pages need to download the serialised page "props" and not just the html+js then good news! Solid 2.0 is about to solve this.

If you are referring to having to download react itself then you have to download the WebComponents code too.

Actually with smart use of forms and links you could make a js free react page (using forms to submit state changes) more easily than for WebComponents

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