Why Sveltekit
Published: 2022-06-27 10:50:38

---
title: Why Sveltekit
published: true
description: 
tags: 
cover_image: https://dev-to-uploads.s3.amazonaws.com/uploads/articles/mryqyc669es6qxlr6oo9.png
---

<!--
![sveltekit image](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/cktvff1tfcx8jfqdd7aj.png)
-->

**Introduction**

I have just concluded on a project built with Sveltekit (locked at version 170) and in this article I will brush over my experience with the framework.

Sveltekit is a Javascript framework for svelte; much like we have Next.JS for react. As of the writing of this article, Sveltekit is still in beta with development at 70% as per the [milestone tracker] (https://github.com/sveltejs/kit/milestones). This notwithstanding, it's still a solid framework that one can pick up and incorporate in their production-level projects (like I did 😌); I would recommend Sveltekit for production for most use cases as noted in this [reddit thread](https://www.reddit.com/r/sveltejs/comments/r4prys/sveltekit_ready_for_production/), but use with caution since the api is still in flux.

**Why Sveltekit**
Sveltekit is the official meta-framework for the svelte library ([click here](https://dev.to/ben/whats-the-difference-between-a-library-and-a-framework-1eaj) on the differences between a framework and library). 
Svelte itself offers a few advantages over its contemporaries:

- Back to the Basics - In the story of JS, svelte conforms to canon by building, enhancing and advancing on familiar technology. Other frameworks are adopting this strategy, more prominently [Remix](https://remix.run/)
- Sane Store management - svelte library bundles a default implementation for store management which is simple and striaght-forward. The nearest example I have seen of a similar simplified implementation is [jotai](https://jotai.org/) with its atomic model
- Simplified Reactivity API - The svelte includes two-way binding that enables a terser syntax in setting and getting of variables. On this Svelte's implementation is [safe from a technical perspective](https://imfeld.dev/writing/how_svelte_makes_two_way_binding_safe), and also one can opt out of two-way binding by ensuring only one-way binding at the code level
- Wide integration with (most) JS libraries, no mods and wrappers/ing required. Svelte was built for [visual journalism](https://www.youtube.com/watch?v=kMlkCYL9qo0&list=WL&index=16&t=1620s) hence needed to work comfortably with existing viz libraries like [D3.js](https://d3js.org/).
- CSS - Straightforward and familiar CSS semantics in the component layer. 

In essense, if you know html, css and javascript there's basically very little learning curve in picking up svelte.

**Sapper**

I started working on this app in mid-2020, after picking up svelte after it had just turned to version 3 a year earlier - and yes I am a convert from the  [Rethinking Reactivity](https://svelte.dev/blog/svelte-3-rethinking-reactivity) talk by the framework's author.

I was [working with React (pre-hooks)](https://keymannerdawid.medium.com/why-reactjs-b601e1a131a0) and was wondering how to simplifying the DX, and [comparing with some alternatives](https://keymannerdawid.medium.com/react-hooks-svelte-knockoutjs-angular1-in-2021-cd7c647d47a9) at the time, svelte was a good balance between modern concepts (components etc) and reduced complexity via simplified apis.

After getting familiar with svelte, I started my project on Sapper, the predecessor of Sveltekit. Sapper was an easier take for me compared to the alternatives, and I enjoyed exploring js-land using a "non-express" node based framework. I also ventured into [tailwind](https://tailwindcss.com/) for the front-end UI, and [Objection JS](https://vincit.github.io/objection.js/) (a superset of Knex) for backend database access. I was in nirvana!

**Sveltekit Beta**

After sometime I abandoned the Sapper-based project to concentrate on bread-making activities; then Sveltekit crossed the corner of my eye. 

Was it time to go back to the side-project?...hmm... sneaky temptation

![Vader](https://awskimana.s3.ap-south-1.amazonaws.com/articles/Darth+Vader+1.gif)

The compelling answer was a resounding YES!. So I started porting the app from Sapper to Sveltekit! This was a mostly painless process since both frameworks are very similar. 

The challenge was Sveltekit was and is in beta. Apis were updated every so often, breaking builds when adding some libraries - a good example being adding certain adapters, which would break on cue. 

This is expected for a framework in beta, therefore I decided to lock into version 170 'till version 1 is officially released.

**New Changes**

Since I had locked the api at v170, I was able to happily finish the side-project. Some new changes have since been introduced to the api which I don't have at the current version.
One major change is _Request can now handle blobs_ - at v170, the custom request object in sveltekit could not handle blobs, therefore one could not upload an image to the backend. This was remedied by either intercepting the upload url call via adding your own server in the backend, or calling an external api for this. I chose the latter. 

All changes are documented in the [changelog](https://github.com/sveltejs/kit/blob/master/packages/kit/CHANGELOG.md)

**Looking into the future**

We await the launch of v1 of Sveltekit! I'm personally very excited for the meta-framework, and the general trajectory of JS frameworks to compiler-based technologies (e.g. Angular Ivy, [React forget](https://www.youtube.com/watch?v=lGEMwh32soc)). IMO I view Svelte and the kit as the next iteration/advancement in JS framework landscape, and I believe more developers should give it a chance. 

For more inspiration watch the "FKIT Stack" 🤣
<figure>
 [![FKIT](http://i3.ytimg.com/vi/rFP7rUYtOOg/hqdefault.jpg)]
 (https://www.youtube.com/watch?v=rFP7rUYtOOg)
 <figcaption>Fireship IO - My Bleeding Edge Tech Stack for 2025</figcaption>
</figure>