undefined | Better HN

0 pointsSebastianKra2y ago0 comments

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/

0 comments

spankalee2y ago

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.

SebastianKraOP2y ago

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.

j / k navigate · click thread line to collapse