My experience with svelte-kit

· erock's devlog

My thoughts on building with svelte-kit
#front-end #svelte is a hobby project I built recently that is a directory search for all neovim-specific plugins. My idea was pretty simple: scrape github data to populate a list of neovim specific plugins and allow users to search them. Instead of building the project using react which is what I'm the most familiar with, I decided to try svelte-kit.

I figured now that was launched and I had a chance to work with svelte and svelte-kit I would talk about my experiences with both of them.

# The good

svelte-kit was very easy to setup. There was a cli command to bootstrap a project and have everything configured properly. In a matter of minutes I had a project setup with a webpage up and running. Nice. Even the production build was setup automatically for me, all I had to do was add an adapter to complete the process.

I was delighted to find that it was using esbuild for the compilation step which was really nice to see since that is how I would set up a modern project (probably via vite).

And for a simple project like neovimcraft it was nice to see file-based routing.

Building a corresponding backend endpoint to fetch or send data to the front-end page was also pretty easy. It was a single function load that lived on the page and was easy to setup and use. It fits my needs perfectly and appears to resemble next.js. The primary exception is that the load function will run on both the front-end as well as the back-end.

On the svelte side of things I found it pretty enjoyable. The most difficult aspect of learning svelte coming from react was the reactive model. I didn't know when to use $ versus when things were automatically reactive. The syntax was obscure and didn't really feel like javascript. That was the only learning curve I had to overcome before I was productive using svelte.

I really liked that each component had different sections (e.g. script and style) and it felt like I was writing plain html and css because of it.

I also felt like I was writing less javascript in svelte. A comparable react implementation would have involved useEffect hooks and a lot more manual manipulation of the url state.

# The bad

svelte-kit has this concept of an adapter where you specify how you want your app to be built and deployed. Want to deploy to netlify? Great, there's an adapter for that. Want to deploy it to your own vm? The node adapter has you covered. In my particular case, I wanted to build a completely static application and host it on google cloud. I decided to use adapter-static to pre-render all my pages and upload it to GCP. Perfect!

One important aspect of my app is when you search for a plugin, the state of what you searched for resides in the URL:

Using the dev server, everything worked perfectly. I decided to use the svelte-kit preview command to make sure everything worked correctly with a pseudo-production build. Excellent, no issues there. After I deployed the app and played around with it in GCP, I noticed an issue: on initial load, whatever search parameter was in the URL was not applied correctly in the app. Hmm. This is a critical aspect of how my webpage works: when people share a search query I want the app to filter the plugins based on that search. I managed to track the issue down in github here.

Darn, it looks like the resolution to this problem is "you can't do what you want." Basically if I want query parameters to work correctly in my application then I cannot prerender my search page. For me this is quite a big limitation and really makes me regret my choice to go with svelte-kit. On top of this was the fact that I spent a bunch of hours searching for this issue and trying to come up with a hack. I even ended up trying to grok the svelte-kit codebase to see what was going wrong.

Maybe for my particular use-case this is not a great fit for svelte-kit? In the end there was another comment that discussed a work-around that I ended up implementing.

It appears to be working fine but I'm not entirely sure why the maintainers of svelte-kit don't want to implement this change upstream, I'm sure there's a good reason.

# My thoughts

There was a lot to like about svelte and svelte-kit. I should add a big disclaimer here that svelte-kit is not 1.0 yet and is considered beta so I probably got into this framework a little early.

Having said that, would I opt to use svelte-kit again? Probably not. I gave up way too much control for the sake of shaving some time off the initial project setup. The only added benefit I got from svelte-kit was file-based routing and the load function. They were convenient to use but not show-stopper features for me.

I find this is a huge aspect of software development. How much control do you want to relinquish to a third-party library or framework? For my particular tastes, I tend to gravitate towards having more control. I don't want to spend hours reading documentation and github issues tracking down an obscure issue only to find out the framework can't do what I want. I'd rather spend that time scaffolding the app to do exactly what I want it to do. This is exactly why I don't recommend next.js at work. It works great until it doesn't and then you are stuck hoping you can convince external maintainers that your use-case is important.

I have no idea what I'm doing. Subscribe to my rss feed to read more of my articles.