[spankalee]

I would argue rather that the amount of complexity that frontend web devs put up with is more of a Stockholm Syndrome situation. You can be much simpler than most mainstream frameworks, using only standard JS, CSS, and HTML, and acheive better results.

Using custom elements and shadow DOM like this post is a big part of that. Custom elements give you a built-in component module, shadow DOM gives you compositions and style scoping.

I think using proxies like this post is a challenging because proxies are very hard to get correct when dealing with methods, collections, object identity, privacy, etc. but it turns out that many applications do just fine with a simple Redux-like store / action / subscribe system for data.

I personally think the project I work on (https://lit.dev) hits a sweet-spot of simplicity vs complexity because it also gives component reactivity, declarative templates, embedded CSS, with standard syntax and no build tools required. In more than 400 LoC, but only by ~3x.

[SebastianKra]

Rather I feel like there's a now fairly well known set of requirements, and every so often, a new framework comes around and says: "It's simple, we just don't consider this."

For instance, the controllers introduced in Lit 2.0 feel like an admission that you forgot to consider the reasons why React moved away from classes in the first place. The example [1] could be written in less than half the amount of lines with hooks, and isn't any easier to understand. Also, I can't find a solution for skipping expensive computations when re-rendering the component.

Admittedly, I only skimmed Lit's documentation. But with the frameworks that I have tried, I came across cases where I had to either implement my own workaround, or the framework began introducing more and more concepts to fix their fundamentally broken approach (cough Aurelia).

[1]: https://lit.dev/docs/composition/controllers/

[spankalee]

Controllers are a much simpler way to hook a component's lifecycle than hooks, and I'm referring to the implementation and conceptual load.

A hook system takes some doing to build, controllers work like:

    connectedCallback() {
      this.controllers.forEach((c) => c.hostConnected());
    }

References from host to controller and controller to host are simple JS references that you can directly see in the debugger.

The React custom hook is a bit shorter, but it's only 13 lines vs 17, and I think hooks are harder to understand because of how much is happening under the hood and the fact that for some reason you need two separate useEffect() calls.

[SebastianKra]

In terms of implementation, I can believe you that they're simpler.

In terms of conceptual load I disagree. In React I'd have to know two concepts: `useEffect` and `useState`. In Lit I have to know the API of LitElement; that it implements a host; the four methods of the controller; the boilerplate for registering my controller and triggering updates; plus all the conceptual baggage of classes.

Further, the hooks implementation considers when an effect should replace itself. For example, if you wanted to have the timeout change dynamically based on the component input, you'd get this for free in react by including `[timeout]` in the dependency array of `useEffect`, whereas with the controller you'd have to do the diffing and replacement yourself.

Then there's propagation of errors from controllers through the tree, where Lit just gives up [1].

Granted, you may not need these features for whatever project you're building, so a simpler framework may be perfectly fine. But don't call it Stockholm-syndrome when other projects _do_ need solutions to these problems.

I want to make clear that I'm not just picking these concepts because they're in React. I've used frameworks before React and I found myself naturally wishing for similar solutions. And React is by no means the only framework with such solutions.

---

[1]: https://lit.dev/docs/components/lifecycle/#errors-in-the-upd...

PS: I was counting 10 Lines in React vs 23 in Lit on the ClockController. Although I would of course be fine with both, if I thought it improved on readability.

[Freedom2]

Do you have an example of a complex widget being implemented in a simpler way with better results? I see this sentiment often here, but most examples are toy examples or frivolous.