Ask HN: If you’ve used both Svelte and React, which is better?
Interest in hearing opinions from people who have used both and why they chose the one they did.
4 comments
I hit my first roadblock in React -- I had a list of objects each had lists in them (list<Post>, Post has list<Replies>). I wanted the UI to update when a reply is updated. This isn't straightforward, https://stackoverflow.com/questions/43040721/how-to-update-n...
I've comments on it, but here goes again. I can't at all say Svelte lacks magic, but that magic is focused on eliminating boilerplate, not hiding where everything is coming from and going to.
It is jarring at first when you look at your code and say, "Wait, what else do I need to do?" And there's nothing left.
Vanilla JS libraries typically work out if the box with it without some bespoke wrapper or adapter for your framework. ("bind:this" is really handy.) Web development with 99% less BS. Lets you focus on your problem, not on your framework's abstraction leaks.
In Svelte, CSS is automatically scoped to your component. No manual shenanigans, weird naming rules, or bespoke CSS generation from JS your dev team have to agree on like what's found in React. No giving up and just using inline styles. No hacks.
Just make a descriptive class name and write your CSS styles. That's it. You're done. For that reason, it reduces any desire I have to work with Tailwind, since we don't have to worry about style leakage. For pre-made styles, Open Props works better with SvelteKit's model.
If you like functional programming (like REALLY like it and consider it the "one true way"), React will likely appeal to you more since it puts programmatic logic above all other concerns and really cares about immutability and one-way data binding.
For the rest of us who care a little less about (in my opinion illusory) absolute purity and more about getting the job done as quickly as possible, with the least amount of code, and more understandable to newcomers, SvelteKit simply can't be beat for developer experience.
Under no circumstances would I recommend using React without a metaframework like NextJS. Similar advice for Svelte/SvelteKit, though I have used Svelte on its own for trivial, truly single-page view apps/pages.
For a beginner, no question: Svelte/SvelteKit is easier to learn, teach, and become productive with.
If you hate HTML and CSS, React is far better at hiding the underlying technologies from view. With Svelte, HTML and CSS are baked in to the developer experience.
It is jarring at first when you look at your code and say, "Wait, what else do I need to do?" And there's nothing left.
const { count, setCount } = useState(0);
let count = 0;
Vanilla JS libraries typically work out if the box with it without some bespoke wrapper or adapter for your framework. ("bind:this" is really handy.) Web development with 99% less BS. Lets you focus on your problem, not on your framework's abstraction leaks.
In Svelte, CSS is automatically scoped to your component. No manual shenanigans, weird naming rules, or bespoke CSS generation from JS your dev team have to agree on like what's found in React. No giving up and just using inline styles. No hacks.
Just make a descriptive class name and write your CSS styles. That's it. You're done. For that reason, it reduces any desire I have to work with Tailwind, since we don't have to worry about style leakage. For pre-made styles, Open Props works better with SvelteKit's model.
If you like functional programming (like REALLY like it and consider it the "one true way"), React will likely appeal to you more since it puts programmatic logic above all other concerns and really cares about immutability and one-way data binding.
For the rest of us who care a little less about (in my opinion illusory) absolute purity and more about getting the job done as quickly as possible, with the least amount of code, and more understandable to newcomers, SvelteKit simply can't be beat for developer experience.
Under no circumstances would I recommend using React without a metaframework like NextJS. Similar advice for Svelte/SvelteKit, though I have used Svelte on its own for trivial, truly single-page view apps/pages.
For a beginner, no question: Svelte/SvelteKit is easier to learn, teach, and become productive with.
If you hate HTML and CSS, React is far better at hiding the underlying technologies from view. With Svelte, HTML and CSS are baked in to the developer experience.
> If you like functional programming (like REALLY like it and consider it the "one true way"), React will likely appeal to you more since it puts programmatic logic above all other concerns
Forgive me for conparing frameworks and languages, but.
IMHO a person like that would love Elm. I use react, especially with Typescript, but it is full of leaky and competing abstractions. It has a "functional style" in the same sense as using map and lambdas, but IMO it is missing the elegance, consistency, and guarantees of a well thought-out system.
Luckily Typescript, nextjs, and the ecosystem make it one of the best options, but the hooks system is, IMO again, a hack.
Forgive me for conparing frameworks and languages, but.
IMHO a person like that would love Elm. I use react, especially with Typescript, but it is full of leaky and competing abstractions. It has a "functional style" in the same sense as using map and lambdas, but IMO it is missing the elegance, consistency, and guarantees of a well thought-out system.
Luckily Typescript, nextjs, and the ecosystem make it one of the best options, but the hooks system is, IMO again, a hack.
In React, you typically manage state changes manually using setState or hooks. While libraries like Redux can help with state management, React doesn't provide automatic two-way data binding out of the box like Svelte. Also no virtual DOM with Svelte. Why did I chose one over the other? I didn't. I just worked on various projects over the years and inherited code where someone else made this choice. Which is better? It's like the line from war games, the correct answer is not to play. Just don't use any JS framwork at all. Keep everything server side rendering and minimal JS code only when absolutely necessary.