'useSyncExternalStore()' -- Gack! Now...that "little" it's-not-a-framework-it's-a-library whose scope is supposed to be confined to just the "view" part of MVC (by which I mean: "React") is inserting it's tentacles (along with a quirky architecture and proven to be error-prone coding patterns, cough, hooks) into the _model_. And it's already corrupted (at least partially) the "controller" part of MVC through React's…
RFC: Intent to Ship React 18
41–50 of 75 posts
Re: RFC: Intent to Ship React 18
#42'useSyncExternalStore()' -- Gack! Now...that "little" it's-not-a-framework-it's-a-library whose scope is supposed to be confined to just the "view" part of MVC (by which I mean: "React") is inserting it's tentacles (along with a quirky architecture and proven to be error-prone coding patterns, cough, hooks) into the _model_. And it's already corrupted (at least partially) the "controller" part of MVC through React's…
> Now...that "little" it's-not-a-framework-it's-a-library whose scope is supposed to be confined to just the "view" part of MVC (by which I mean: "React") is inserting it's tentacles [...] into the _model_.
useSyncExternalStore doesn't care about what you do in your model. it's for connecting your view to your model in a way that doesn't give you inconsistent states when concurrent-rendering-funkiness happens.
you could even say that useSyncExternalStore exists because React maintainers want people to be able to use whatever state-manager they want (instead of useState/useReducer/whatever) -- uSES was necessary to enable that in 18.
Re: RFC: Intent to Ship React 18
#43Earlier quoted context omitted.
You can implement a hooks like interface in an afternoon. I don’t think I could do the same for Svelte’s compiler-oriented approach. Using a compiler means that Svelte is essentially a dialect of EcmaScript, which appears to be mutually intelligible but isn’t always. React used a compiler for JSX which also introduced a dialect, but JSX is optional and very straightforward sugar for a simple function call. The Svelte…
> Using a compiler means that Svelte is essentially a dialect of EcmaScript 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.
Re: RFC: Intent to Ship React 18
#44React still rocks, as it keeps "magic" to the minimal (Hook introduces a little magic for a tradeoff). Simplicity is key here.
Hooks are not simple at all, are very error prone, and definitely do not put the user in the "pit of success". JSX is terrific, but React has only gone backwards since classes IMO.
Re: RFC: Intent to Ship React 18
#45Earlier quoted context omitted.
I just don't know, svelte feels way too similar to the "magic" of knockout and angular 1.0 when looking at the output... Something I got burnt by with weird edge cases of update loops or desync. 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.
If you think Svelte is magic, wait until you see how hooks work.
- 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".
Honestly they are weird, but I can reason about them with a "good enough" mental model to get paid.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?
Re: RFC: Intent to Ship React 18
#46Earlier quoted context omitted.
You can implement a hooks like interface in an afternoon. I don’t think I could do the same for Svelte’s compiler-oriented approach. Using a compiler means that Svelte is essentially a dialect of EcmaScript, which appears to be mutually intelligible but isn’t always. React used a compiler for JSX which also introduced a dialect, but JSX is optional and very straightforward sugar for a simple function call. The Svelte…
> Using a compiler means that Svelte is essentially a dialect of EcmaScript 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.
Re: RFC: Intent to Ship React 18
#47Earlier quoted context omitted.
You can implement a hooks like interface in an afternoon. I don’t think I could do the same for Svelte’s compiler-oriented approach. Using a compiler means that Svelte is essentially a dialect of EcmaScript, which appears to be mutually intelligible but isn’t always. React used a compiler for JSX which also introduced a dialect, but JSX is optional and very straightforward sugar for a simple function call. The Svelte…
> Using a compiler means that Svelte is essentially a dialect of EcmaScript 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.
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.
Re: RFC: Intent to Ship React 18
#48Earlier quoted context omitted.
> Using a compiler means that Svelte is essentially a dialect of EcmaScript 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.
Exactly, I don't get the React is just Javascript. It's not. You're tied to React just as much as Svelte or anything else. The Facebook propaganda machine is clever I will say.
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.
Re: RFC: Intent to Ship React 18
#49React still rocks, as it keeps "magic" to the minimal (Hook introduces a little magic for a tradeoff). Simplicity is key here.
Hooks are not simple at all, are very error prone, and definitely do not put the user in the "pit of success". JSX is terrific, but React has only gone backwards since classes IMO.
Re: RFC: Intent to Ship React 18
#50The fact that it's been well over 3 years since the introduction of hooks in React and people still don't understand how to use them makes me very worried for frontend development. Really looking forward to server components.
What give you the impression that people don't get hooks? In our company I see zero questions about how hooks work on slack. 90% of the time useEffect is enough.