DEV Community

Cover image for Why SvelteKit Will Be My Goto Moving Forward
James 'Dante' Midzi
James 'Dante' Midzi

Posted on • Edited on • Originally published at dantedecodes.vercel.app

Why SvelteKit Will Be My Goto Moving Forward

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:

  • Python
  • PHP (TYPO#3)
  • React/Next.js

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:

  • One of the things I liked about Next.js was that there were clear boundaries; your pages go here, your assets go here, API routes go here. That is all but gone, with the brunt of the things happening in the app folder.

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

  • This sort of relates to my first point; the adding of 'use client' or 'use server' within a file does not sit well with me. There is something elegant about getStaticProps and getServerSideProps; you knew exactly where your data was coming from and how it would be rendered.

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

Top comments (4)

Collapse
 
0x_brucey profile image
Budi πŸ‡ΊπŸ‡¦πŸ‡΅πŸ‡Έ

Great post. As a beginning developer I've found Sveltekit intuitive and easily compatible with Vercel and Supabase.

Collapse
 
fyodorio profile image
Fyodor

Why pit Svelte against Vercel, it’s not correct actually as Rich Harris literally works for Vercel πŸ˜… Next.js β€” yes, that’d be legit. Vercel is too many things, especially now. And Svelte is really a gem in their armory indeed.

Collapse
 
psypher1 profile image
James 'Dante' Midzi

I am not pitting anything against anything πŸ˜…. This article is simply about my experiences, things that annoyed and in the end lead me to finding a simpler way of accomplishing things.

Side Note: I am not particular about svlete 5 and runes at the moment

Collapse
 
psypher1 profile image
James 'Dante' Midzi

Thank you!

I completely agree; things work with little to no explanation - and that for me is a major bonus.

I'm a bit annoyed at myself for not using Sveltekit sooner πŸ˜…πŸ˜…πŸ˜