erock's bloghttps://erock.prose.sh2022-06-29T00:10:06ZTechnical writings by Eric BowererockMy experience with svelte-kit2022-07-05T13:45:06Zhttps://erock.prose.sh/my-experience-with-svelte-kit<p><a href="https://neovimcraft.com" rel="nofollow">neovimcraft.com</a> 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 <code>react</code> which
is what I'm the most familiar with, I decided to try
<a href="https://kit.svelte.dev" rel="nofollow">svelte-kit</a>.</p>
<p>I figured now that <a href="https://neovimcraft.com" rel="nofollow">neovimcraft.com</a> was launched and I
had a chance to work with <code>svelte</code> and <code>svelte-kit</code> I would talk about my
experiences with both of them.</p>
<h2 id="the-good"><a class="anchor" href="#the-good" rel="nofollow">#</a> The good</h2>
<p><code>svelte-kit</code> 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 <code>adapter</code> to complete the
process.</p>
<p>I was delighted to find that it was using <code>esbuild</code> for the compilation step
which was really nice to see since that is how I would set up a modern project
(probably via <code>vite</code>).</p>
<p>And for a simple project like <code>neovimcraft</code> it was nice to see file-based
routing.</p>
<p>Building a corresponding backend endpoint to fetch or send data to the front-end
page was also pretty easy. It was a single function <code>load</code> that lived on the
page and was easy to setup and use. It fits my needs perfectly and appears to
resemble <code>next.js</code>. The primary exception is that the <code>load</code> function will run
on both the front-end as well as the back-end.</p>
<p>On the <code>svelte</code> side of things I found it pretty enjoyable. The most difficult
aspect of learning <code>svelte</code> coming from <code>react</code> was the reactive model. I didn't
know when to use <code>$</code> 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 <code>svelte</code>.</p>
<p>I really liked that each component had different sections (e.g. <code>script</code> and
<code>style</code>) and it felt like I was writing plain html and css because of it.</p>
<p>I also felt like I was writing less javascript in <code>svelte</code>. A comparable <code>react</code>
implementation would have involved <code>useEffect</code> hooks and a lot more manual
manipulation of the url state.</p>
<h2 id="the-bad"><a class="anchor" href="#the-bad" rel="nofollow">#</a> The bad</h2>
<p><code>svelte-kit</code> has this concept of an
<a href="https://kit.svelte.dev/docs#adapters" rel="nofollow">adapter</a> where you specify how you want
your app to be built and deployed. Want to deploy to <code>netlify</code>? Great, there's
an adapter for that. Want to deploy it to your own vm? The <code>node</code> 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
<a href="https://github.com/sveltejs/kit/tree/master/packages/adapter-static" rel="nofollow">adapter-static</a>
to pre-render all my pages and upload it to GCP. Perfect!</p>
<p>One important aspect of my app is when you search for a plugin, the state of
what you searched for resides in the URL:
<a href="https://neovimcraft.com/?search=git" rel="nofollow">https://neovimcraft.com/?search=git</a></p>
<p>Using the dev server, everything worked perfectly. I decided to use the
<code>svelte-kit preview</code> 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
<code>search</code> 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
<a href="https://github.com/sveltejs/kit/issues/669" rel="nofollow">here</a>.</p>
<p>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 <code>svelte-kit</code>. 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 <code>svelte-kit</code> codebase to
see what was going wrong.</p>
<p>Maybe for my particular use-case this is not a great fit for <code>svelte-kit</code>? In
the end there was another comment that discussed a
<a href="https://github.com/neurosnap/neovimcraft/commit/780e2a66be478ee44a77d299caee631937c43c92" rel="nofollow">work-around that I ended up implementing</a>.</p>
<p>It appears to be working fine but I'm not entirely sure why the maintainers of
<code>svelte-kit</code> don't want to implement this change upstream, I'm sure there's a
good reason.</p>
<h2 id="my-thoughts"><a class="anchor" href="#my-thoughts" rel="nofollow">#</a> My thoughts</h2>
<p>There was a lot to like about <code>svelte</code> and <code>svelte-kit</code>. I should add a big
disclaimer here that <code>svelte-kit</code> is <em>not</em> 1.0 yet and is considered beta so I
probably got into this framework a little early.</p>
<p>Having said that, would I opt to use <code>svelte-kit</code> 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 <code>load</code> function. They were convenient to use but not show-stopper features
for me.</p>
<p>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 <code>next.js</code> 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.</p>
<p>Have a comment? Start a discussion by sending an email to
<a href="mailto:~erock/public-inbox@lists.sr.ht" rel="nofollow">my public inbox</a>.</p>
My thoughts on building neovimcraft.com with svelte-kit