Another blog post about Svelte vs. React

Simplicity is a feature.

Svelte is way easier to use than React (I said “use” and not “learn”, because there’s a huge difference). It does not mean it’s less sophisticated.

On the contrary, it abstracts complexity away from developers and provides simple tools to go beyond the reconciliation.

React vs. Svelte

As you may already know, Svelte does not create any virtual DOM like React. You may also know that Svelte has no runtime, so it does not do the head part of its work in the browser, like React.

Svelte runs all its optimizations during the compilation phase.

React has a diffing algorithm that allows modifying only DOM nodes that need to update instead of re-rendering the whole application.

The reconciliation algorithm has been a game-changer, but it’s limited by nature, and it does not fully work out of the box.

Don’t get me wrong, it works great, but as developers using React, we get extra work comparing to Svelte. Some developers call that “abstraction leaks”.

Of course, Svelte is younger than React, so it’s fortunate it’s better, but it claims a true reactive framework should handle more points. That’s why it goes further with additional tools.

This repository is a pretty cool visual that compares React hooks and Svelte:

In Svelte, all reactive statements are memoized.

Notice that with Svelte, you don’t need to declare the dependencies. The compiler infers them for you.

Size matters

Smaller size means fewer bytes to parse for the browser, and Svelte is on the top of the world in this category.

Build any hello world with any other framework, and you’ll probably get heavier bundles than for a complete application built with Svelte.

It’s possible because Svelte has no dependency by default, only dev dependencies for the compilation.

Source: Svelte GitHub

There is no need for external libraries such as CSS in Js as Svelte provides easy ways to modify classes and styles programmatically.

Less hassle

Write less, do more

Svelte follows that pattern, so ten lines of React code for a very basic component, including state management with hooks, often become two lines with Svelte.

It’s possible thanks to an efficient data-binding. The abstraction combines declaration and change listening because Svelte, as a reactive framework, rightly assumes you’ll need it.

The greatness is that optimization has zero cost, as everything happens during the compilation and not in the browser.

React is not dead yet

The React ecosystem is gigantic.

I doubt Svelte is the best solution to build complex web apps. It does not provide some of the advanced features of React 16++.

As I ever wrote, I don’t think React is the best tool for personal websites such as blogs in 2021, as it’s a lot of bytes to load by default for so few interactions, but it’s still excellent to build large scale UIs.

The performance issue is questionable

I think it’s a good practice not to read things at face value. Svelte is the new kid on the block, so it claims to be revolutionary, and it truly is, but what’s the problem with the diffing algorithm?

We are humans, so we are limited. The perceived performance would be a more pertinent metric. Almost all tests I’ve seen involve thousands of clicks per second, which is, let’s be honest, not the average project.

I don’t have UX (user experience) issues with the virtual DOM…

Don’t get me wrong. It does not mean it’s the ultimate approach. If it was, then why would Svelte even exist?

Besides, Svelte can be cheaper to dev, host, and maintain, but I doubt companies will switch from React to Svelte, at least not yet:

  • High-skilled developers love React
  • Typescript support is still young in Svelte
  • React handles many libraries and specific plugins

Svelte’s approach is probably better, but I think it’s essential to put things into perspective.

Wrap up

I’m still wondering if React and Svelte’s comparison makes total sense.

With its radically new approach, Svelte goes beyond other propositions that are, more or less, forks of React.

However, are we talking about the same business here?

As usual, there’s always going to be some give and take because there are no ultimate answers.

See Also