At the same time there's a huge amount of React code at this point. It would be an interesting experiment to try to compile React code to really reactive code that doesn't need virtual DOM.
Svelte might have that all reasoned out though, in which case the harder separation of logic and view is the only stickler for me, and transpiling JSX into svelte would be interesting to see.
With hooks at least I am able to have a mental model around what happens when I call a change function since it flows top down (instead of bottom up).
So do hooks. Suddenly regular function calls can't be put in if statements or require "dependency lists" to make them work properly.
Also you're just just passing a callback function to React and then giving it some pointers to data used as part of the conditional on when it should run.
Like it's janky and reaches through layers but it's not up and rewriting your code.
In Javascript, "just iterables" can be put in conditional statements, and they don't cause the outer function to be called again.
> Also you're just just
Ah yes. That "just" again
Edit:
> just passing a callback function to React and then giving it some pointers to data
Thing is, in plain JavaScript if it was a callback function, it could be called anything and live anywhere. However, these functions have to be named with a `use` prefix and have limitations on how they can be called.
it = ["hello", "world", "foo", "bar"]
shouldbehello = next(it)
shouldbeworld = next(it)
if sometimes_true_sometimes_false:
shouldbefoo = next(it)
# if the conditional is false this will be foo, oops.
shouldbebar = next(it)
def react_to_stuff(func, var):
orig = var.copy()
def monitor():
while True:
sleep 2
if var != orig:
orig = var.copy()
func(var)
t = Thread(target=monitor)
t.start()
stuff = "Hello"
react_to_stuff(lambda x: print(x), stuff)On "it's iterators actually", I have a response to a sibling comment here: https://news.ycombinator.com/item?id=30799543
- These are "just function calls"
- Except they are "iterators"
- Except if you have them in a conditional, you must provide an `else` branch so that `next` is called the same number of times
None of this is in the semantics of the language where I don't have to provide an else branch to an iterator, and function calls are not iterators ;)
* React stores the state for your hooks in a list which is iterable.
* useBlah is just a normal function that internally calls next() on that list to get the next hook state which is why order matters.
* React checks that the iteratior on the list is at the end to see if you’ve consumed all the hooks and throws an error if not because it’s indicative of a bug in your code.
Like at this point the only thing I can recommend is try writing a toy implementation of hooks and see that they’re not magic, they’re just normal JS, and that the restrictions flow naturally from the implementation.
Like why do you want so bad for hooks to be weird?
you keep showing isn't a normal function :)
> Like why do you want so bad for hooks to be weird?
I don't want them to be weird. They are weird already. https://news.ycombinator.com/item?id=30801466
So are hooks. The fact that you can't put regular function calls (which hooks look like) in an if statement, or have to provide custom "dependency lists" to some of them, or that data returned from them suddenly re-renders (aka calls again) the function they are in tells you that this is no longer regular Javascript.
I’ve helped teams pilot out of own-the-world frameworks like Backbone and Rails before (both of which substantially distort the runtime they’re embedded in); but it was much harder to deal with Backbone + Coffeescript together. For Backbone w/ vanilla JS or Rails, we could use standard static analysis tools, Coffeescript added a big extra wrinkle to our migration.
There's a fundamental difference between a framework that takes your code and does weird things with it, vs a framework that rewrites the semantics of your code out from under you.
- They're tied to the lifecycle of the component, so they must reach "up" into whatever just called our component function.
- They do not like being moved about/conditionally executed, so hook's likely use an array for metadata storage and position rather than needing explicit "hook keys".
I've no clue what svelte does behind the scenes, much the same way as I can't reckon what WASM or assembly do. So I guess I just have to blindly trust the compiler?
I think they are actually _more_ explicit than classes about how the state is stored. IMO `this` in class based components isn't as straightforward (e.g. https://overreacted.io/why-do-we-write-super-props/)
I haven’t built anything big with it yet but I like what I see so far!
There’s some real overhead of React’s virtual DOM.
The VDOM definitely carried overhead in my case, but it was easy to profile and optimize (with the React tools). In many cases, reflowing the sheer size of the DOM we were generating was a bigger bottleneck than the time it took React to render it in the first place
I'm really curious what was going on in your app
Can a better design help to mitigate those issues? Sure. But I don't like having to wonder whether it was my own design, or if it's something internal to the library.
This is the part I thought I was bizarre:
> The React profiler wasn’t able to show any latency in my render functions and using the browser profiler I saw that all time was spent somewhere inside React’s internal
Svelte avoids this by magically not doing the unnecessary work. That doesn't mean it's faster, it just means your design needs to make different kinds of considerations.
React also gives you great tools to avoid and remediate this (memoization wrappers, the dev tools highlight elements that rerender, linters that check you're using hooks correctly), so it's really hard to say that this is a slowness that's endemic to the vdom.
I thought React and React-DOM were separate?
Still the best choice for huge, corporate frontend projects.