Why SvelteKit Will Be My Goto Moving Forward

Why SvelteKit Will Be My Goto Moving Forward

Read 467 times

#svelte

#sveltekit

#complexity

#simplicity

Allow me to tell you a tale, take you on a journey of how I switched how I work completely and I am probably not going back…

History

Anyone who knows me and has been following my journey is aware that my development focuses consist of:

What this has allowed me to do is be more efficient at picking the correct tool for the things I’ll be trying to accomplish.

The Then

It’s no secret that I have been an advocate of Next.js for some time. I even have a short series I did investigating how to integrate it with different Headless CMS. I have done explorations on the features I believed people should know in regards to Next. As such me and Next have been on very good terms for a while.

Breaking Up With Next

Put simply two words - App Router. I am not sure what the team at Vercel was in a hurry to get to, but they rushed this like I’ve never seen before. With me, if anything is pushed on me that hard, I form a natural aversion towards it; see one of my previous articles.

The Lie of Stable

While they may have made it stable now, when a lot of the features of the router were introduced they weren’t ready; despite what they liked you to believe.

I could go on and on about the things that were reportedly stable, but that’s not the point of the article. What I will do is tell you my main pain points.

Clear boundaries or lack thereof:

Having to add pieces of text to change how your file/component works:

I will not even get started on the actions, sorry server actions.

Yes, I know I can still use Next.js the way I prefer, but the mob makes so much noise I would just rather maintain the project I have the way they are and just not deal with this new way.

The Now

After all the noise with Next.js I went on a journey to find something else that would meet my needs and not lie to me. My journey led me to several options; ones that did things better than Next.js, others not so much. Here is a very brief rundown:

Laravel

Considering I already use PHP in the form of TYPO3. I didn’t go that way because I already got a sufficient dose of PHP. Also, I wouldn’t randomly whip out TYPO3 for any ‘ol project.

Vue/Nuxt

What put me off of Vue/Nuxt was mainly their templating engine. It just didn’t sit well with me; the particular way the files in it are written. Also, something about its routing felt iffy.

Solid

This would have been going back to a version of React/Nextjs type framework. I wouldn’t learn as much as I would like. Also things would still be abstracted from me, I was trying to avoid that.

Enter Svelte

Long ago, I tried to dabble in Svelte, but that was in my naive and hard-headed days and never took the time to understand what it required of me. Additionally, I tried to do it alongside another person and that did not go well. This time instead, I chose to knuckle down and get into what made Svelte Svelte; the changes in mindset I would need to undertake for this part of my journey.

Finding Synergy

I am not going to lie, the move to SvelteKit was not seamless. A lot of shift in mindset was required

To start the directory-based routing and wrapping my head around the +page.svelte naming convention was a bit confusing to get comfortable with. Afterwards; understanding how working with data was accomplished and what the +page.js and +page.server.js files did, and where I used each.

Understanding those things would aid me greatly in grasping how SvelteKit works and how I should approach my journey with it. With determination in my heart and a vantage point I was aimed at, I went to work.

And then, it clicked!

During the struggling, the change in mindset and embracing the power of native HTML and how SvelteKit leverages that, it clicked. Sticking to it paid off and my new home had been found and solidified.

What I Like About SvelteKit

  1. Native HTML: It strips away the abstraction; no virtual DOM or anything of the kind. It’s all just native HTML. Because of that your elements work the way they were intended.

  2. Things are defined clearly:

    1. +page.svelte: is your frontend stuff what you see when a page loads. Basically the crux of what a user sees when they visit your site/app.
    2. +page.js / +page.server.js: this is where you load data to be displayed on your pages, and where your form actions run.
    3. +layout.svelte: this applies styling and/or data to set of routes under the same directory.
    4. +layout.js / +layout.server.js: allows you to specify data you want applied to an entire set of routes. In essence, the higher level of your page.server.js

  3. Form actions: With it leveraging the native HTML means it takes advantage of all the functionality already present with forms. This means that nothing is hidden from you; what you can do in a form on a basic page, you can do with Sveltekit.

    1. progressive enhancement: since we leverage the default functionality of forms, they will reload the page on a submit. Progressive enhancement gives us the ability to utilise the submit action without making the entire page reload.

Yes sure, Next.js might have now implemented some of this in their new version, but with SvelteKit it feels a lot more thought out and not rushed.

Wrapping Up

All in all, I actually thank Vercel for taking the approach they did. I would not have rediscovered Sveltekit otherwise. In addition, it helps in my goal of stripping away complexity that I talked about in these articles:

And that’s the journey; How an advocate of Next.js was not impressed by the direction it took and moved to SvelteKit. Thereby finding a better way, a more honest way, a streamlined way of doing things. A way he is much happier with.

Thank you for reading, let’s connect!

Thank you for visiting this little corner of mine. Let’s connect on Twitter, Discord and LinkedIn

Back to articles