[nailer]

Less code as everyone else mentioned, single file components (CSS is inside your .svelte files too, and isolated automatically), and a general feeling of on railsness that React for me lacked.

State in Svelte goes in stores. State in react seems to go in one of eighteen different mechanisms, which all begin with a 45 minute video of the author’s opinions about the true nature of reactive programming, when all I want to do is store a string.

[faefox]

> State in Svelte goes in stores. State in react seems to go in one of eighteen different mechanisms, which all begin with a 45 minute video of the author’s opinions about the true nature of reactive programming, when all I want to do is store a string.

So... useState? :)

Of course then I got to thinking about how I'd answer the question "How can I put make that useState value accessible at different points in the component tree?" and the answer was "Make a new context with createContext and wrap the context provider in a component which provides the state and write a hook to easily consume the context within a child component" and, yeah, that's not exactly a frictionless dev experience.

FWIW for simple state management in React I've heard lots of good things about zustand: https://github.com/pmndrs/zustand

[nightski]

I work on several large react apps that are very data heavy and what I would consider complex. Honestly we just use useState and prop drilling. Most state is stored at optimal position within the hierarchy, so there really aren't that many props being passed down. The only place context is used is for session information.

It's really quite simple and elegant. Svelte's model would likely be more complex tbh.

[nailer]

> It's really quite simple and elegant. Svelte's model would likely be more complex tbh.

Prop drilling in Svelte is exactly the same complexity.

useState() wouldn’t exist because Svelte doesn’t need a virtual DOM and the compiler takes care of reactivity (per the famous React vs Svelte meme).

Stores are way, way simpler than redux reflux whatever else.

[nightski]

I prefer an explicit function call over compiler voodoo magic, especially when it comes to reactivity (of which can have performance implications). Any solution where a compiler is changing the semantics of my code on the fly is just a hard pass.

[nailer]

Shrug. You’re comparing compiler voodoo with vdom voodoo.

[faefox]

Yeah, I think it's something you just have to get a feel for over time. Sometimes prop drilling is the lesser of two evils, other times it makes more sense to break related state up into a shared context.

At least the React ecosystem as a whole seems to have broken free from the delusion that Redux is the be-all-end-all of state management. Those were dark days.

[nailer]

I audibly laughed at your second paragraph. Yes you understand this perfectly :).