In the other corner, we have Svelte. Svelte is an up-and-comer with nowhere near React’s market share, but it’s just getting started. Created by Rich Harris, a New York Times employee, it offers something different: a simplified structure and an emphasis on run-time performance, including things like fast load times.
They can both manage state, and the app used to compare them basically has one webpage which changes state to the next webpage when you click on it, and changes the style state from fullscreen to letterboxed when you click a button, on the desktop.
The app doesn’t have a router, because I thought that would’ve obscured the differences overly much. The routing is usually done by libraries, and I wanted to stick to ‘vanilla’ React and Svelte.
This is the Svelte version, after being deployed to AWS S3.
This is the React version, after being deployed to AWS S3.
The pitch deck is for a fictional stock photography company called Eye Captain. I created 9 pages, or cards, enough to get the general idea across.
While you should feel free to copy this to make your own pitch deck, this is not a real pitch deck, which should only be attempted by professionals (kidding).
From there user’s perspective, there’s 2 things you can do with the UI.
In addition to clicking through the cards sequentially, you can also click on a button to change their formatting.
In desktop mode, it can either be letterboxed — really, surrounded by blank black space — or fullscreen — meaning the card, and its blue background, stretches to the corners of the screen.
In mobile mode, there’s less space, so you can only view the cards there in fullscreen mode.
When you click on a card, it advances the card index plus one, and that index is used to find the next card (unless you’re at the last card, in which case it loops back to the first one). The card index and the styles affecting the cards are all stored within the framework’s state.
One of the more instructive parts is seeing how React and Svelte separately manage this state.
See the code for details.
I tried to lay out the two apps to be as identical as possible.
Both of them have a main app component where the text is defined, and passed as an argument to the component that actually implements the page, called Deck in both apps. In React, it’s Deck.js, and in Svelte, it’s Deck.svelte. When I talk about the ‘app’ here I mostly mean the Deck.js and Deck.svelte files.
I’ll start with Svelte.
In Svelte, at the top, as I’ve written it, you have some script definitions.
Below that, you have the CSS.
In the case of the React app, it’s a standard React implementation, using hooks.
Even though the React one has a short code section, it gives you a good sense of the idiosyncrasies you get accustomed to in React, the React way of doing things with camel-cased CSS properties and setState, for example.
State is important in both versions. To quote the React docs: State is reserved only for interactivity, that is, data that changes over time.
I think of state as the program’s ‘memory’ (note: that’s my personal mental shortcut, don’t say this in a job interview). Just like you use your memory to remember when something has changed locations so you can act on the difference, your program does that too.
One state variable is for the index.
It’s purpose is obvious: to show the card associated with that index number, and increment the number on a mouse click. In both programs, a function with the same name, advanceClick, moves the index forward by one, when you click on the screen (onClick in React, on:click in Svelte).
Another state variable is for, basically, ‘fullscreen’ or ‘not fullscreen’ — which is to say, desktop or mobile.
The variable is called display. When it’s true, on the desktop, you see the fullscreen version of the site. When it’s false, you see the mobile version. You flip between those versions by clicking on a button which toggles the value of display, with every click.
A media query checks to see if your screen is desktop or mobile sized. If it’s desktop, you can switch between fullscreen and letterboxed. If it’s mobile, you can only see the fullscreen version. Or, in other words: if you’re viewing the live app on a mobile phone, you’ll only see a plain click-scrolling app.
When looking at the two side by side, I find the Svelte version to be ‘cleaner’ and simpler to understand. I use React all the time and so find it natural to think in React, so for me to find Svelte more intuitive after one use is a pretty strong vote for the framework.
I sometimes see tutorials that say something like, ‘Use the framework that’s best for your situation.’ I find this frustrating, because the question is only asked when that answer is unknown.
As an analogy, here’s a guide for getting into the medical school, university, or job of your dreams: whenever you are asked a question or face a choice about it, choose the best appropriate answer. Correctly applied, you’ll ace every test, interview, and academic honor, by always choosing the correct answer in context.
But how is this useful? It’s just stating a kind of tautology: the right answer is by definition the right answer to the right question.
So, here is stronger, more useful advice.
Whenever you can use Svelte, use Svelte. When you can’t, use React.
You know what’s a common use case for Svelte — meaning a situation where you should use Svelte over React?
This hits the nail on the head. And is 100% matching our long term thinking. Client-side-only is not sustainable. We need to move more stuff to the server, but without sacrificing seamless composition of interactive pieces. https://t.co/O4LX8JacRo— Dan Abramov (@dan_abramov ) May 10, 2020
The relevant part of the essay is this excerpt:
There is a sweet spot of React: in moderately interactive interfaces. Complex forms that require immediate feedback, UIs that need to move around and react instantly. That’s where it excels… The less interactive parts don’t benefit much from React.
There is a swath of use cases which would be hard without React and which aren’t complicated enough to push beyond React’s limits. But there are also a lot of problems for which I can’t see any concrete benefit to using React. Those are things like blogs, shopping-cart-websites, mostly-CRUD-and-forms-websites. For these things, all of the fancy optimizations are trying to get you closer to the performance you would’ve gotten if you just hadn’t used so much technology.
I can, for example, guarantee that this blog is faster than any Gatsby blog (and much love to the Gatsby team) because there is nothing that a React static site can do that will make it faster than a non-React static site.
For blogs, I think the average developer underestimates the advantage of speed. That’s your main priority! I personally have clicked on developer portfolio sites on my iPhone, only for it to essentially time out while waiting to load. You’re a developer, and the quality of your blog reflects on you. Don’t be that person with the slow site.
After I finished the React and Svelte versions, I deployed them both to S3. I decided to test them using the Audit feature in Chrome’s Developer Tools.
The Svelte result:
The React result:
Spoiler: the Svelte results are about twice as good.
In particular, look at that difference in time to interactive. It’s huge! The React one is more than twice as large — 3.7 seconds vs. 1.7 seconds.
If you can sidestep that - you should. This comparison app is dirt simple, but as it gets more complicated (like a real app), I’d expect that to creep up.
So, if you’re doing a blog from scratch, it’s easy: use Svelte.
If you have more interactivity than we would expect from your average blog, or have some special use case that is React specific, use React — but think carefully, if you don’t really need it.
Be willing to learn and use Svelte, because the speed difference is worth it.
For more content like this, follow me on Twitter.