neovimcraft.com 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 neovimcraft.com 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: https://neovimcraft.com/?search=git
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.