Live data from Hacker News

RFC: Intent to Ship React 18

github.com

41–50 of 75 posts

Re: RFC: Intent to Ship React 18

#41

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

React 15 came out 6 years ago. You make it sound as if there’s a new major version every month.

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…

> '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 [...] 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

#43
post #18

Earlier 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.

[deleted]

Re: RFC: Intent to Ship React 18

#44

React 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.

Not a react fan, here, but hooks are so much better than pre-hooks react. Not sure why anyone would want to go back.

Re: RFC: Intent to Ship React 18

#45
post #6
post #5

Earlier 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.

A fair point, and I haven't dove into react's inner workings to see how the sausage (I was more discussing the compiled code of the app), but one can reason "how" hooks work after observing them.

    - 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

#46
post #18

Earlier 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.

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.

Re: RFC: Intent to Ship React 18

#47
post #18

Earlier 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.

Yes and no. They definitely push the boundaries, and the framework imposes certain extra restrictions on how it wants you to use them, and they warp your normal intuitions a bit. But at the end of the day they are just function calls. They don't compile down to some other sort of construct with totally different language semantics.

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

#48
post #46

Earlier 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.

There’s a wide difference between learning the semantics of an API and learning the semantics of a custom language with a compiler. There are alternate implementations of the React API, like Preact. The semantics of the React API might be complex, but you could implement them in essentially any programming language with function pointers and variable length arrays. You can’t say the same thing for Svelte; which we know is impossible to implement in pure JavaScript, which is why it needs a compiler. This is all anyone in this thread is arguing - it’s an argument about semantics but for some kinds of environments semantics are very important.

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

#49

React 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.

Highly highly disagree. Hooks and Functional components are so much easier to work with nowdays then class based components that came before.

Re: RFC: Intent to Ship React 18

#50

The 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.

Yeah I was going to say.. where’s the confusion? Once you learn the 3 or 4 most used hooks you can pretty much achieve everything you would ever need in a web app. It’s not like they aren’t documented well, and there are tons of videos on them.
Post reply on HN