Choosing Svelte.js for production
Why Svelte.js is a good choice for bootstrapping a startup
When I stumbled upon the Svelte 3’s introduction talk by Rich Harris a year ago, I was taken aback. Being the greatest fan of React since its beginning, and having been mind-blown as well by the talk introducing React Asynchronous Rendering a couple years before that, I was instantly convinced. Yet, being busy on React projects, I had never used Svelte passed the tutorial and couldn’t wait to try it for real.
What impressed me with Svelte was the incredible promise of performance (and lightness, at the same time) as well as easier transitions and animations. For a year after seeing that talk, I kept looking for opportunities to try it for myself.
When I quit my job to co-found a startup, the inevitable finally happened: my decision had been made a long time ago, so I started out with Sapper and Svelte.
Our need
As a fan of the Lean Startup approach, our goal was not to spend several months developing a product before the first release. We wanted to “be out there” as quickly as possible in order to validate the traction of our idea. As technology wouldn’t be a differentiator for our business, there was no time to spend on “trying fancy things”. On the other hand, we also needed a robust and fail-proof system, that ran with very little maintenance. Ah, and also SEO optimisation (which I knew nothing about).
To summarize, our needs were:
- Development efficiency
- No maintenance
- SEO performance
Why Svelte.js was a good candidate
For a simple presentational SPA, I didn’t think that there would be a much differences between modern frameworks. In terms of SEO, I just knew a couple of things that were important on the technical side: a huge chunk of users will land on your website via mobile, so Google decided to weigh sites by their mobile performance.
I therefore decided to compare the performance of documentation websites between frameworks. Aren’t the documentation websites supposed to be the example of how to best implement a static website using their technology?
Using the mobile evaluation from Lighthouse, Sapper always scored better than Next.js, and the difference in payload was 305KB against 918KB (for an equivalent HTML page content size). I didn’t want to spend too much time benchmarking, but it seemed to me as if Sapper and Svelte would give me an edge compared to the other frameworks, that would be hard to catch up on, or searching for optimisations that I anyway didn’t have the time for.
Lastly, I am not a pro at css transitions and animations. Having been disappointed with my experience in the past using react libraries for that, I decided to trust Rich Harris that Svelte had a far better developer experience on that topic. We wouldn’t have a design and development team before a long time, so any small animation that I could easily code would be a “delight” to our users. As it is said in the Svelte tutorial,
“In the real world, […] instead of disappearing and reappearing in another place, [objects] move through a series of intermediate positions. Using motion can go a long way towards helping users understand what's happening in your app.”
Amen. If Svelte can help us achieve that, it's a big plus.
The challenges
With all this being said, we started our journey with Sapper and Svelte. Sapper, Rollup, Svelte were all new to me, but happened to be very simple to learn and use. Even though new, they were familiar to my experience with Webpack and React. The community is smaller than of the React ecosystem, yet the documentations are great and the examples are plenty. Here were the few challenges I faced:
Learning a new language
Like with everything new, there is a learning curve. I found Svelte’s one to be very easy. Basically, write the html and css you want to see on the page, and then start scripting it. I had to go to the tutorial quite often, but it is very well made. In my mind, it encourages you to focus on the looks.
CSS-in-JS
Being used to styling my components according to props, I had some hard times with the separation between script and styles at the beginning. But I quickly got used to doing things in a different manner, for example adding classes according to boolean variables, or using css custom properties when some maths were needed. In the end, isn’t it better to do these maths off the main thread ? I found the css experience delightful with Svelte (and I’m not using any pre-processors).
Even though simpler, animations are still IMO not for beginners
After the tutorial, I was convinced that animations could go from my imagination to the website in a couple of minutes. I found that this is usually false. Transitions are incredibly easy to use (to make elements appear and disappear), and the crossfade function is amazing to automatically make elements move even though they are in different components !! But you will have to make sure to master your css, because the elements surrounding the transitioning one will be visible until the transition is over (issue).
Yet, here is the type of page transition I managed to implement with a couple of lines of code, and a few css headaches. I still wonder how I could have implemented those with React!
Here are some of the resources that were useful for transitions and animations:
- https://svelte.dev/examples#deferred-transitions
- https://dev.to/buhrmi/svelte-component-transitions-5ie
- https://stackoverflow.com/questions/59882179/svelte-transition-between-two-elements-jumps
The app state
Our application currently does not have a heavy frontend logic. For that reason, Svelte stores have been more than enough. I am wondering though whether it is a solution that can scale (in terms of code organization). I have seen tweets about people just using stores, and I have also seen a Svelte connector for redux. Because I like simplicity as long as it works, I think that we will use stores for the time being. But this question was for me a challenge, because as often there is no consensus.
The enigmatic rule about external components
In the Sapper template (that you will most likely use when starting a project), there is a rule about using external components. I had read it before, but am not yet comfortable with the practice. It just seems non-standard to me, and caused therefore a waste of time when I started to use Sveltefire! So do not disregard it.
Takeaways
Using Svelte to build a site for production was really delightful. I love the performance it provides out of the box, the simplicity it encourages you to strive for. You don’t even need to remember all the tutorial to start using it. Just go back to it when you’re stuck. With Svelte, everything feels native and natural. It feels like you can truly dedicate all your energy making your site look good for the user. I never loved learning CSS as much as through this experience as well. I just feel that the simplicity of this library changed my way of seeing the web: why not embrace the native standards rather than coding for a virtual DOM that will in the end manage everything for you?
A bright future
It is always difficult to choose a technology that will be at the base of your company’s tech stack. Unlike with React, it will be harder to hire engineers with knowledge of Svelte or the motivation to learn.
Nevertheless, Svelte passed my “production test”: it already has everything needed to thrive in my opinion. It is also light and compatible with other frontend technologies if needed.
Svelte allowed us to quickly build our prototype and was such a good experience that we decided to continue with it for the development of the web responsive application.
Thank you so much to all the Svelte community working hard out there !
