Sometime in the year 2020 time collapsed on itself and lost all meaning. Children ran rampant through zoom meetings and we all generally forgot how to wear pants.  Yes, the darkened days.

What did we do in 2020?  We all became home chefs.  We dove head first into various food blogs complete with small book sized, search engine optimized essays about each recipe and ingredient.  Recipe sites were and are brutally inefficient advertising machines. Sure, you could print the recipe to PDF and pull up the PDF on a phone.  Sure, you could ‘jump to recipe’ and skip the ten page stories.  But that didn’t scratch my quarantined itch for an easy to use recipe that would fit onto my phone screen while I was making Claire Saffitz’ amazing cookies.  Nor did it scratch my itch to build something.

To scratch the itch, I decided to leverage my engineering skills to make online recipes easy to use and organize.  The next question was how would I build it.  Part of the fun of hobby projects is building them in some new framework or language.  For my project I decided that I really wanted something lean, mean, and newish.  In the past I have used React, Angular, and Vue.  I decided to try out Svelte and see how it stands up to the popular enterprise javascript frameworks.

Decisions & Process

I’m no Svelte expert, so I went with a more opinionated approach — and the Sveltekit project. Setting up the project was seriously easy.

Running the command…

npm create svelte@latest my-app

…and a few CLI options will generate a skeleton project, and viola, you have a todo app.  Figuring out the routing within SvelteKit was just as simple.  I was able to copy the todo route to a new directory, modify the provided code and I had recipes loading and displaying in no time.

Svelte’s opinions about the app structure and functionality left me free to focus on the page display and end user functionality.  I never felt like I was wrestling with the framework to create nested forms or to build out event reactions.  Another result of these well structured opinions is that Svelte pages are smaller than with other frameworks.  I had originally built a page in React and rebuilt the same page in Svelte.  The Svelte page had half as much code.  As they say, the best code is no code, so I would consider this a substantial win.

But, after my initial quick wins I ran head first into a steeper learning curve.  The first big issue I ran into was authentication.  The first time setting up authentication in any framework is frustrating, but SvelteKit made that more frustrating due to the lack of any common request interceptor.  This made adding authentication tokens to each API request an exercise in ignoring the adage of “don’t repeat yourself”.

The second issue had to do with session expiration and refresh.  My natural tendency was to catch an authentication exception from an API call, try to refresh the token, and retry the original request.  Svelte apparently finds this unacceptable.  I ended up putting some logic on a response handler to handle this retry.  Emphasis: response handler.  There’s an interceptor for responses, but not requests.

I fought through the above issues and the other usual issues of ‘new framework learning curve’. I went through two iterations of the project, one major upgrade of Svelte, and the kids school reopened following Covid restrictions.  Overall I probably spent about 5 months on the project; which in hobby time is probably about 2 weeks of full time work.  Today I can make pancakes by following a recipe which fits neatly on my Pixel 3.  The big takeaway was the experience with Svelte.

Here’s what I learned:

The Good

1. Basic CRUD operations are super easy ( list, get, put, post, delete )

• If you’re building out a site with a backend responses matched to each page, Svelte is the easiest javascript framework I’ve used

2. Routing is super easy

• Each folder is a route, end of story. In the end it creates a project structure similar to a site map.  It’s easy to find the code you’re looking for and easy to visualize navigation.

3. Pages have very little code

• I built the same recipe page in React and Svelte and the same functionality in Svelte took 50 lines vs 100 lines in React.

4. Svelte is fun

• The project mentions this on their site, and if you enjoy coding more than pulling in libraries, I’d say it’s true.  Svelte really does cut down on the boiler plate and lets you focus on clear javascript and clean templates.

5. Deployments are easy

• The newer version of Svelte uses Vite for packaging and running locally.  The integration worked excellently.  For deploying to GCP my front end deployment was 3 lines of code.  Test, Build, Push.

The Bad

1. Authentication and route guards are a pain

• In particular there were no easy ways to leverage request interceptors like if you are using Axios and React.  This makes it challenging to add auth headers to outgoing requests
• There are no centralized ways to capture navigation events making it difficult to check authentication when pages are loaded or as tokens expire

2. Non-CRUD API integration is wonky

• Each page in SvelteKit has a corresponding API route.  That route can have one of each verb.  So if a page needs more than one GET operation to load data, you’re going to get into the weeds creating a separate API route. It’s not the worst thing in the world, but it can be tricky to follow.

3. The project structure is at once opinionated and tricky for newcomers to follow

• For basic pages and their associated backend calls, the structure is super simple.  As I said, each folder is a route, end of story.  But I got tripped up with how to structure the components, stores, and library code.  Honestly this was probably a newbie type issue, but I didn’t love the structure of my completed app.

4. Not as many pre-built pieces or integrations as there are with React or Vue.

• For some, this may be a feature.  Integrating with google auth for instance required building my own, whereas I can grab a React library.

5. Opinionated error handling

• I didn’t feel comfortable not catching errors from API calls.  Svelte wants to do this error handling itself and every path to customizing the behavior seemed like an incomplete solution.

Should You Use Svelte?

Svelte’s implementation of staple enterprise features, notably authentication and route guards, makes it difficult to recommend at the moment.  The current implementation will spread this code throughout the application creating too many opportunities for mistakes.  On the other hand, there are upsides to using Svelte. SvelteKit is opinionated about how the app will be structured and how it will function.  But its opinions make the page templating and javascript straight forward and flexible.  This makes SvelteKit easy to use, creates clean components ( except auth duplication ) and pages, and it’s fast to render.

Overall Svelte feels like a framework which may eventually make a production grade application, but not yet.  Svelte has been gathering popularity and maturing quickly.  By the time you read this, the issues above may have well trod solutions.  So, consider using Svelte but with due diligence.  I recommend you make a test project to exercise Svelte’s weak points.  Start with authentication and route guards.  Build and leverage an endpoint that’s not part of the basic CRUD/REST.  If the functionality and code meets your organization’s standards, you’ll love Svelte.

If you are looking for help modernizing your user experience or evaluating technologies for your next enterprise project, Simple Thread can help.  We would love to hear from you.