DEV Community

Cover image for Svelte from a React developer's perspective: The Basics
José Del Valle
José Del Valle

Posted on • Originally published at on


Svelte from a React developer's perspective: The Basics

So I don’t know a thing about Svelte. I mean, yes. I know it’s a new framework for building web apps and that it’s generating a lot of buzz but that’s pretty much it. Instead of reading articles by other fellow developers I’ve decided to introduce myself into the thing and give it a go from a React developer’s perspective.

I’ve been a React developer for about 5 years now so I’m pretty excited about learning a new and - I hope - refreshing technology.

So, I went to the Svelte site and started doing their tutorial. Here are my thoughts as I go through it. What I want to do is to write about the similarities and differences I find between Svelte and React that I consider worth mentioning.

Compilation vs Interpretation

Right on the first page of the tutorial you can read the definition of what Svelte is and the main reason it is different than other frameworks:

Svelte converts your app into ideal JavaScript at build time, rather than interpreting your application code at runtime.

When you compile a Svelte app, you end up with plain Javascript code and the browser doesn't have to run nor download anything specific to Svelte to do any of the UI operations. With React, on the other hand, the browser needs to download the React library to do all the stuff we are used to, more specifically the Virtual DOM diffing.

Not having to download any code to do UI operations means your apps are smaller and load faster on the browser.

I still wonder how much of a benefit there is when introducing third-party libraries but I'll leave that for future posts.

No Virtual DOM

Unlike React, Svelte doesn't do Virtual DOM diffing to update the DOM. When you compile Svelte apps, you end up with the Javascript code that is responsible for updating the DOM when the state of your app changes. This way your apps are not subject to any overhead related to Virtual DOM operations.


So, at a glance, it seems that Svelte’s markup shares some similarities with React’s JSX. I’ve also spotted some cool differences. Let’s take a look:

Svelte also uses curly brackets to pass data to elements.

The code below is actually valid Svelte and JSX from a syntactical standpoint:

<h1>Hello {name}!</h1> 

Of course, we’re not yet looking at the surrounding Javascript where the variable name lives but so far we are presented with a similar approach for dealing with this.

Svelte has a very cool ‘attribute shorthand’ feature

This does not exist in React and I love it. See the code below:

<img src={src} alt="A man dances.">

With Svelte, we can just do the following

<img {src} alt="A man dances.">

We’ve dropped the src={src} in preference of just {src}. Very cool!

Working with Svelte files feels more like working with HTML

So, to develop Svelte components you have to write your code in .svelte files, which just feel like modular HTML with Javascript and CSS specific to the component you are working on.

My current approach with React files is to have the component-specific styles in the same file using styled-components so this feels similar to me. It just looks a little bit more sectioned.

Here's a quick example of a very simple .svelte file:

    p {
        color: blue;

    let name = 'José'

<p>Hello {name}!</p>

Importing and using external components looks like React

So, putting the Svelte structure aside, importing and using external components feels the same.

Here's a small example of that:

    import Nested from './Nested.svelte';

<p>This is a paragraph.</p>

Svelte has a dangerouslySetInnerHTML but without the spooky name

So, everyone has used React's dangerouslySetInnerHTML at some point. Svelte has exactly the same without putting the word dangerous in it. You just have to use a @html prefix before the variable that contains the HTML string.

Still, this is dangerous. Both React and Svelte advice that injecting HTML could be a vulnerability for cross-site scripting (XSS).

    let string = `this string contains some <strong>HTML!!!</strong>`;

<p>{@html string}</p>


Finally, the part where we take a look at DOM updates given state changes.Here things look a bit different from React but it's still Javascript and it's kinda cool!

Let's take a look at the following code snippet:

    let count = 0;

    function handleClick() {
        count += 1;

<button on:click={handleClick}>
    Clicked {count} {count === 1 ? 'time' : 'times'}

Unlike React where we declare a state object in a class component or use Hooks in functional components, we just declare the variable we want to change and the event handler function that will update that variable. So far that sounds like plain Javascript. The key here is in the button element and the syntax on the event handler attribute.

Instead of using onClick we use Svelte's on:click. This will tell Svelte to generate the necessary code that will update the DOM when the value of the variable count changes. Remember, all the browser will get is plain Javascript and no DOM diffing is involved here. Just like they mention on their homepage:

Svelte generates code that surgically updates the DOM.

This is all for now but there's still a lot to cover. I'll work on a second part during the following days and hopefully create some app in the following weeks.

Thanks for reading!

Follow me on twitter: @jdelvx

Top comments (1)

seemcat profile image
Maricris Bonzo

I've read many intros to Svelte, and this by far is my favorite...I think it's because of your React angle. Thanks!

Timeless DEV post...

Git Concepts I Wish I Knew Years Ago

The most used technology by developers is not Javascript.

It's not Python or HTML.

It hardly even gets mentioned in interviews or listed as a pre-requisite for jobs.

I'm talking about Git and version control of course.

One does not simply learn git