21–30 of 104 posts
> From my perspective, the post-React frameworks have all converged on the same foundational ideas... Using reactivity (e.g. signals) for DOM updates. For an intro from the OG, consider this 6 minute video from Solid [0] or this blog post [1] by Solid's author. 0: https://www.youtube.com/watch?v=cELFZQAMdhQ 1: https://dev.to/ryansolid/building-a-reactive-library-from-sc...
I really love Svelte. The compiler is great and very extensible. For example, you can easily add functions to the processing pipeline to process Svelte templates (or the script elements or style sections) in your own special way. It's a fantastic way to build JavaScript frameworks. Svelte people always note Svelte isn't a framework, so this isn't a framework on top of another framework! I used this to build Svekyll,…
I'm 50% convinced there's a Chesterton's fence I'm mising but where?
> To grossly oversimplify things: React assumes that your entire virtual DOM tree needs to be rebuilt from scratch, and the only way to prevent these updates is to implement useMemo
Not quite, on a state update, it rebuilds the component that was updated and all of its children. Not the entire virtual DOM; old versions of Angular did this, but it was wasteful.
useMemo doesn't prevent that, but React.memo can (useMemo has a different role; it lets you choose when to recompute or recreate a normal JavaScript object. But on its own it won't stop rerendering of child components!) [0]
This invalidates some of their assumptions. The reason why React isn't "push-only" isn't because it does that, it's because it sometimes buffers updates instead of always pushing them immediately. In fact, other frameworks like ~~Svelte also aren't "push-only" and hence not strictly reactive~~! [edit: this is no longer true after Svelte v5, see discussion below] (Funnily enough, OP uses an article as a source that explains this correctly [1], but it seems they took the wrong lesson from it).
The reason why signals are so cool is because the framework knows for any given state change which exact attributes in the DOM need to be re-rendered, even more specifically than "the element and all its children". But this neither implies reactivity nor the other way around. The two concepts are orthogonal.
Anyways, kudos to the author for diving into this so deeply!
[0] useMemo is useful in combination with React.memo sometimes, as the latter compares objects shallowly/by reference instead of their contents, so useMemo can be used to only recreate shallow references if its contents changed. You could probably also reimplement React.memo with useMemo, but you probably shouldn't. [1] https://dev.to/this-is-learning/how-react-isn-t-reactive-and...
I'm always surprised when articles mention a bunch of JS frameworks and leave out RiotJS. I can't be the only person using it?
Never heard of it. Looks sveltish.
I suppose, if which ever choice is doing the trick - keep it while practicable
Please, do not build more JS frameworks (see-no-evil emoji).
Is there a framework/library that supports the usage of an effect-system when it comes to rendering actions?
For instance, in react, a component (or rather it's render-function) has to return the element(s) directly. Is there a framework where the render-function accepts something effect-like or promise-like instead, even if that means that the rendering might potentially be delayed?
Question to the folks with a lot of frontend framework experience: Is there a framework/library that supports the usage of an effect-system when it comes to rendering actions? For instance, in react, a component (or rather it's render-function) has to return the element(s) directly. Is there a framework where the render-function accepts something effect-like or promise-like instead, even if that means that the render…
function MyComponent() {
const promise = ...;
const result = use(promise); // use is like await
// do something
}
function Wrapper() {
return (
}>
);
}
I like the article, but it gets some things subtly wrong. > To grossly oversimplify things: React assumes that your entire virtual DOM tree needs to be rebuilt from scratch, and the only way to prevent these updates is to implement useMemo Not quite, on a state update, it rebuilds the component that was updated and all of its children. Not the entire virtual DOM; old versions of Angular did this, but it was wasteful.…
I did indeed mix up `useMemo` and `React.memo` – fixed it in the post.
You're right, I am skipping a lot of details (hence "to grossly oversimplify"). I know that React doesn't invalidate the whole tree, but it does in the worst case. Maybe I should add a note about that.
Svelte not being truly reactive makes perfect sense, but in Svelte v5 my understanding is that "runes mode" does exactly that. This is what I mean by "moving in that direction."
Question to the folks with a lot of frontend framework experience: Is there a framework/library that supports the usage of an effect-system when it comes to rendering actions? For instance, in react, a component (or rather it's render-function) has to return the element(s) directly. Is there a framework where the render-function accepts something effect-like or promise-like instead, even if that means that the render…
I've made my own though: https://github.com/marcellerusu/capable-js.
Its not for use but it was an interesting experience that enables a lot of new patterns by using generators.
I don't claim that it is better than other frameworks though, there's a lot of times where this pattern is significantly more cumbersome than just using react.