Jack Franklin

Comparing Svelte and React

Last year I created Pomodone, a small time tracking application based on the Pomodoro technique of working in 25 minute intervals. It's a pretty basic app; it has a 25 minute timer (that runs in a Web Worker) and saves a history of your "poms" to a small Firebase database. I initially built it using React (well, Preact actually) but I then started to play around with Svelte, and decided rebuilding the app in Svelte might be a nice way to blog about the similarities and differences between the libraries.

This is not a post declaring Svelte to be better than React, or vice-versa. This is a post where I'll tell you about my preferences, and what I find easier or harder with either framework. I'm not here to pick a fight! Plus, Pomodone is hardily a vastly complex application that could be used to fully put React or Svelte through its paces. Think of this post as a commentary based on my experience throwing a side project together, focusing on the developer experience putting these components together.

Authentication

The app uses Firebase Authentication to log a user in via either their GitHub or Google account. I love Firebase Authentication, it's such an easy way to add auth to side projects.

React's hooks are a great way to package this up; I create a useCurrentUser hook which listens out to authentication changes and sets some state accordingly. I can then trust React to re-render as required when an authentication change is noted.

export const useCurrentUser = () => {
  const [currentUser, setCurrentUser] = useState(undefined)

  useEffect(() => {
    return firebase.auth().onAuthStateChanged((details) => {
      setCurrentUser(
        details
          ? {
              displayName: details.displayName,
              provider: {
                'google.com': 'Google',
                'github.com': 'GitHub',
              }[details.providerData[0].providerId],
              uid: details.uid,
            }
          : null
      )
    })
  }, [])
  return [currentUser]
}

Within any component, I can write:

const [currentUser] = useCurrentUser()

This is nice; it's low effort and lets any component quickly access the current user. The only downside of this is that you potentially have many onAuthStateChanged listeners; I could mitigate this by only binding one listener, or by putting the current user in a context instead.

Talking of context, that's much closer to the approach I take with Svelte and use a writable store.

export const currentUser = writable()

export const listenForAuthChanges = () => {
  return firebase.auth().onAuthStateChanged((details) => {
    if (details) {
      currentUser.set({
        displayName: details.displayName,
        provider: {
          'google.com': 'Google',
          'github.com': 'GitHub',
        }[details.providerData[0].providerId],
        uid: details.uid,
      })
    } else {
      currentUser.set(null)
    }
  })
}

Within the top level Svelte component, I can call this within onMount, which will run once when the component is mounted (the function is returned so we unsubscribe when the component is removed, much like how useEffect lets you return a function).

onMount(() => {
  return listenForAuthChanges()
})

Now anywhere in my Svelte codebase, a component can import the currentUser writable store, and act accordingly. What I like is that currentUser isn't a value, it's a store, and therefore you have full control over how you deal with it. You can either subscribe to it and manually control with state changes:

currentUser.subscribe(newValue => {
  ...
})

Or, if you want to just read the latest value, you can prefix it with a $:

console.log($currentUser)

This is where some of Svelte's syntax trickery begins to shine; this dollar prefix trick automatically subscribes you to the store's latest value. I both like and dislike this; it's a nice syntax once you know it, but it's a bit odd as a beginner to get used to. However I like that Svelte doesn't make me use the subscribe API every time I need to read the value.

As far as basic authentication goes, both libraries seem to take similar approaches here. Whilst the terminology and exact syntax differs slightly, both allow you to subscribe to a Firebase listener and get updated when the authentication state changes. React's contexts and Svelte's stores play almost identical roles for their library.

Using a worker

Pomodone has to keep a 25 minute timer going and try to be as accurate as possible. If a browser tab is backgrounded (e.g., not the focused tab), most browsers will lower the priority of its setTimeout calls and not run them strictly to time. Most of the time on the web this isn't a massive deal, but when a user is tracking 25 minutes of work via your app, it is! Plus, over the course of 25 minutes, any slight time drift will cause the final time to be quite far off. However, if these timeouts are moved into a web worker, they should run to time and not get de-prioritised by the browser.

Therefore, in my Tracker component, I need to instantiate a web worker, send it messages and receive data (such as time remaining) back. This is one area where I found React more "admin heavy" than Svelte; because React components are re-executed every time the component re-renders, you can easily end up with thousands of workers being created! It's essential to use useRef to avoid this problem by maintaining a reference to the worker that you've created.

Firstly I set up the initial state I need for the component:

const [currentPom, setCurrentPom] = useState(null)
const [currentUser] = useCurrentUser()
const worker = useRef(null)

And then create a useEffect hook that will instantiate the worker, if required, and bind an event listener to listen for messages:

useEffect(() => {
  if (!worker.current) {
    worker.current = new Worker(workerURL)
    window.worker = worker.current
  }

  const onMessage = (event) => {
    if (event.data.name === 'tick') {
      setCurrentPom((currentPom) => ({
        ...currentPom,
        secondsRemaining: event.data.counter,
      }))
    } else if (event.data.name === 'start') {
      // More branches removed here to save space...
    }
  }
  worker.current.addEventListener('message', onMessage)

  return () => {
    worker.current.removeEventListener('message', onMessage)
  }
}, [currentUser])

And then, when the user hits the "Start" button, I have to send the worker a message:

const onStartPom = () => {
  if (!worker.current) return
  worker.current.postMessage('startTimer')
}

Svelte looks pretty similar, but has two small changes that personally make the Svelte code easier to read, in my opinion:

  1. We don't have to keep the worker in useRef, and can just assign it to a variable.
  2. We can pull the event listener code out into a function more easily, as that function won't then become a dependency to a useEffect - at which point we will have to wrap it in useCallback.

Instantiating the worker is now:

let worker
onMount(() => {
  worker = new Worker(workerURL)
  worker.addEventListener('message', onWorkerMessage)
  return () => {
    worker.removeEventListener('message', onWorkerMessage)
  }
})

We also don't have to set state by using React's setX(oldX => newX) convention, and can just mutate the local variable:

function onWorkerMessage(event) {
  if (event.data.name === 'tick') {
    currentPom = {
      ...currentPom,
      secondsRemaining: event.data.counter,
    }
  } else if (event.data.name === 'start') {
    // More branches here removed to save space...
  }
}

Here's where I start to have a preference for Svelte; the two are very similar but once I got used to Svelte I found that React felt like jumping through hoops. You can't create a worker instance, it has to go in a useRef, and then you can't easily pull code out into a function without then requiring useCallback so it can be a safe dependency on useEffect. With Svelte I write code that's closer to "plain" JavaScript, whereas in React more of my code is wrapped in a React primitive.

Conditional rendering

One part of React that I've always championed is how it's just JavaScript. I like that in React you don't use a distinct template syntax and instead embed JavaScript, compared to Svelte's templating language:

<ul>
  {pomsForCurrentDay.map(entryData, index) => {
    const finishedAt = format(new Date(entryData.timeFinished), 'H:mm:ss')
    return <li title={`Finished at ${finishedAt}`}>{index + 1}</li>
  })}
</ul>
<ul class="poms-list">
  {#each currentDayPoms as value, index}
    <li
      title={`Finished at ${format(
        new Date(value.timeFinished),
        'H:mm:ss'
      )}`}
    >
      {index + 1}
    </li>
  {/each}
</ul>

I was pleasantly surprised by Svelte's templating; in the past I've found templating languages overwhelming and inflexible, but Svelte offers just the right amount of templating whilst enabling you to use JavaScript too. That said, I will always find React's approach easier - at least in my head - and I think more friendly to people familiar with JavaScript who are learning a library.

However, Svelte does have some nice touches to its syntax when it comes to rendering components (which feels very JSX-like). My favourite is the ability to collapse props:

<History pomodoros={pomodoros} />
<History {pomodoros}/>

This is something I've longed for with React!

Reactivity in Svelte with $

React requires us to use useEffect and other hooks because it fully controls how all your code is run and re-runs your code whenever a component is re-rendered. Svelte is different in that by default most of your code is only going to run once; a console.log('foo') line in a component will only run when that component is first rendered. In React, it will run many times.

React's re-rendering approach has its upsides: let's say you are taking in a big list of data and running some function to convert it into data that you can render. In React, within your component, you can write:

const input = props.inputData
const transformed = input.map((item) => transformItem(item))

return <div>{JSON.stringify(transformed, null, 2)}</div>

And this will always be up to date - should the user provide new props.inputData, the component will re-render and the output will be updated.

The same is not true in Svelte:

<script>
export let input;
const transformed = input.map((item) => transformItem(item))
</script>

<div>{JSON.stringify(transformed, null, 2)}</div>

Here the output will be rendered the first time the component is rendered, but then not updated at all. We can solve this in two ways, either by using the $: label syntax, which marks the code as reactive, or by moving our transform logic into the template:

<script>
export let input;
$: transformed = input.map((item) => transformItem(item))
</script>

<div>{JSON.stringify(transformed, null, 2)}</div>
<script>
export let input;
</script>

<div>{JSON.stringify(input.map((item => transformItem(item))), null, 2)}</div>

This is another example of Svelte taking JavaScript syntax and using it for a slightly different meaning; it tells Svelte that the statement is reactive and should be recalculate should any imports change. You might also call it a "computed property". The second solution simply moves the logic into the template, thus ensuring that when the component re-renders the logic is executed again. In my time with Svelte this is the approach I've gone with most of the time, often pulling out the logic into a function:

<div>{calculateOutputForItems(input)}</div>

Coming from React to Svelte this did catch me out numerous times but for me I now prefer Svelte's approach, particularly because it removes some of the boilerplate around useEffect.

Component composition

Component composition is a huge part of what makes working with a component based framework enjoyable or not and it's something that both React and Svelte solve well. React's children prop makes it very easy to render any provided content:

function Box(props) {
  return <div>{props.children}</div>
}

function App() {
  return (
    <Box>
      <p>hello world!</p>
    </Box>
  )
}

(If you've not read it, the React guide on Composition is well worth a read).

Svelte does similar, using slots:

<!-- Box component -->
<div class="box">
  <slot></slot>
</div>

<!-- App component -->
<Box>
  <p>hello world!</p>
</Box>

They take different approaches when it comes to multiple children, and this is where I find myself preferring Svelte's approach more. React suggest passing through multiple props:

function Box(props) {
  return (
    <div>
      <div class="left">{props.left}</div>
      <div class="right">{props.right}</div>
    </div>
  )
}

function App() {
  return <Box left={<p>hello</p>} right={<p>world!</P>} />
}

One gripe I've had with this approach is that you lose the visual cues that you're passing children into the Box component; they now aren't nested within the Box when you render them like we're used to in HTML; it's now up to you to read the props and spot which ones are being used to provide children. It's easily done on this dummy example, but harder in "real world" applications - or at least, I find it harder!

Svelte's approach is to define multiple slots with explicit names to let the user provide the elements that should fill those slots:

<!-- Box component -->
<div class="box">
  <slot name="left"></slot>
  <slot name="right"></slot>
</div>

<!-- App component -->
<Box>
  <p slot="left">hello</p>
  <p slot="right">world!</p>
</Box>

I like this approach more because I can scan the code that renders the Box component and easily spot that it takes two children. If the Box took any props, they'd be within the opening <Box> tag, and they would be distinct from any children props.

My preference here is biased by the fact that I spend everyday at work building web components, so Svelte's approach feels very familiar to slots in web components.

Styling

I enjoy that Svelte has an opinion about styling; especially in the context of small side projects like Pomodone, it's great to have that decision made for me. The fact that Svelte can also detect unused CSS is great, and this is one of the reasons why I suspect I'll reach more for Svelte in future projects.

This isn't really a downside to React; one of React's strengths is that it lets you control so much and slot React into your environment, but I like that Svelte comes with a good CSS story out the box.

Conditional classes

One small feature I love about Svelte is how I can apply classes conditionally to an element:

<div class:is-active={isActive}>

This will apply the class is-active to the element, but only if the value isActive is truthy. This reads well, is clear and is great that it comes out of the box.

I have used classnames to achieve similar functionality in React, and it's a good solution, but I enjoy that Svelte provides this out the box.

Binding event listeners

Similarly to conditional classes, Svelte packs in some extra utilities for binding event listeners in the form of modifiers. These let you modify event listeners to ask Svelte to include common functionality, such as calling event.preventDefault(), for you.

<script>
function click(event) {
  event.preventDefault()
  // logic here
}
</script>

<button on:click={click}>
  Click me!
</button>
<script>
function click() {
  // No need to preventDefault ourselves
  // logic here
}
</script>

<button on:click|preventDefault={click}>
  Click me!
</button>

Conclusion

I like both React and Svelte. Put me in a codebase with either of them and I'll enjoy it, be productive and happy putting new features together or fixing bugs. I have side projects in React, and others in Svelte, and I'm in no rush to convert any from one to the other. React and Svelte are very similar in many ways, but what I've found is that in all the little ways that they are different, I prefer Svelte. The codebase for Pomodone makes more sense to me in Svelte, not React. I find it easier to navigate and work with.

If I were to sum up why in one sentence, it's because I don't miss useEffect. I understand why it exists, I understand the approach React takes, and there are benefits of its approach. But writing complex React components feels more like admin; a constant worry that I'll miss a dependency in my useEffect call and end up crashing my browser session. With Svelte I don't have that lingering feeling, and that's what I've come to enjoy. Svelte is there when I need it with useful APIs, but fades into the background as I put my app together.

If you enjoyed this post, you might like to follow me on Bluesky.

All blog posts