Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Building a front end framework – Reactivity, composability with no dependencies

18alan.space

Post reply on HN
Print view View original

71–80 of 80 posts

Re: Building a front end framework – Reactivity, composability with no dependencies

#71

Post by spankalee »

SebastianKra wrote: post #67
spankalee wrote: post #45

Earlier quoted context omitted.

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…

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…

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.

Re: Building a front end framework – Reactivity, composability with no dependencies

#72

Post by rk06 »

ttfkam wrote: post #20

They literally just described Svelte with that headline. Front end framework: check Reactivity: $check Composability: check No dependencies: once compiled, check And pretty sure Svelte (or Qwik or Solid or even React) will perform better than the "dependency-free" custom components. The open secret in the front end world is that custom components as baked into browsers is slower and a major pain in the ass as an API.…

No, it is more Vue than svelte. Vue use proxies while svelte doesn’t. That being said I wonder if tying up with web components is a good idea. Cause if it was, other js framework author would have applied it

Re: Building a front end framework – Reactivity, composability with no dependencies

#73

Post by gloosx »

I think a lot of stuff is taken wrongly in this article. First of all, React.js is a library that just provides a handful of hooks. "magical HTML and JavaScript" code is called JSX, and that is transpiled by Babel into not-so-magical nested function walls. Imperatively applying mutations to an application state inside a proxy object setter is, in fact, proactive and not reactive. Reactive implies that the renderers are pure declarative functions that are derived from data, so changing the data would result in a different renderer output based on a composition of these pure functions. So, in the end, React.js is just a library that brings a pure functional renderer to the web, and you even need a separate library, called react-dom, in order to manipulate the DOM itself with the outputs of React function. If you want to approach something similar to React, try to abstract away from DOM and HTML, and think in terms of a single pure data function, which returns a tree that can be then traversed into a set of UI elements.

Re: Building a front end framework – Reactivity, composability with no dependencies

#74

Post by SebastianKra »

spankalee wrote: post #71
SebastianKra wrote: post #67

Earlier quoted context omitted.

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…

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

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.

Re: Building a front end framework – Reactivity, composability with no dependencies

#75

Post by datadeft »

xboxnolifes wrote: post #64
datadeft wrote: post #40

Earlier quoted context omitted.

* Applications where sensitive data lives in the client Isn't JS the worst kind of solution for security related things?

In what way?

A few:

https://snyk.io/learn/javascript-security/

Re: Building a front end framework – Reactivity, composability with no dependencies

#77

Post by aabbcc1241 »

hbroek wrote: post #60
aabbcc1241 wrote: post #32

Earlier quoted context omitted.

I made a similar library [1] using data-* attributes. It also supports nesting, looping and conditions. For event handling, I use function in object (a.k.a. method) while you support writing them inline. Your way to support inline logic in the text and style is interesting. [1] https://github.com/beenotung/data-template

Very cool, it seems we almost came up with the same approach of components/templates. In your framework, it is referenced with a data-template attribute. In Reken, I use a data-component attribute. One of the design goals for Reken was to not have to context-switch while coding, to not lose my train of thought (Guess my short-term memory is limited). Hence try to add everything inline in the HTML file. Also I'm worki…

Wish you'll keep up and see more adoption over time :)

Re: Building a front end framework – Reactivity, composability with no dependencies

#78

Post by aabbcc1241 »

adparadox wrote: post #57
aabbcc1241 wrote: post #31

Earlier quoted context omitted.

Would you also add these js library to the list? They don't require build step as well. https://github.com/beenotung/html-template-lite https://github.com/beenotung/data-template https://github.com/beenotung/dom-proxy

I added `dom-proxy` because that looked like the closest to a complete solution from a quick skim. Let me know if you want to swap for another one, though.

dom-proxy is the most recent work, I'm glad it stands out to you

Re: Building a front end framework – Reactivity, composability with no dependencies

#80

Post by klysm »

duxup wrote: post #16
klysm wrote: post #14

New front end frameworks that claim leaps in simplicity feel like the violate some kind of no free lunch principle to me. If they’re that simple, then I’m willing to bet they make some use cases very difficult or impossible

I feel like the only things that provide “ leaps in simplicity” as far as web dev goes are basic css frameworks. Generally they really can save a lot of time / needed structure.

Sure but they make certain things very hard or impossible, usually as things get more dynamic. But CSS has gotten a lot more dynamic capability in recent years.
Post reply on HN