The Preamble

Welcome! This is the first blog post of Games, Tech, Gone. I created this blog with the topic of this article - Sveltekit, and a bunch of other technologies. I'll be going over my experience with using Sveltekit, from the parts I found great and intuitive, to the parts that had me scratching my head at times. 

For some context of my overall experience going into this, I have been in the software industry for about a year, and am currently a junior at university. I'm by no means an expert in any tech stack, but I can typically fumble my way around to a solution and product. For web development specifically, I have some experience with Microsoft's Blazor framework, specifically Blazor Server, which does all rendering and logic server-side, and sends HTML/CSS/JS down through a websocket to be displayed onto the user's page. Most of my other experience involves some backend work.

I started this Sveltekit project after hearing about Svelte, a new-ish frontend framework that was performant, intuitive, and relatively easy to use. After doing some of their tutorials, I learned about their full-stack framework Sveltekit before 1.0 had released, and toyed around with it for a bit. After some practice with Python and finding a blog template, I decided a blog would be a great way to not only learn a JS/TS framework, but to also put something out there that allows me to word vomit into the void.

And so, let's start spewin'.

The Tools

• QuillJS - is a WSYWIG editor library that looks and feels very clean. However, the documentation is a bit painful, and implementing with Sveltekit specifically took a decent chunk of research and duct tape.
• PostGreSQL - Good ol' database. Lightweight and easy enough to implement, I typically have very little issues spinning up a DB with this.
• Prisma - Library that makes code-first databases easy to create and implement, as well as acts as the intermediate service between you and your database. It can generate its own types and code completion based on the schema you've provided. Prisma was an absolute joy to work with.
• Cloudinary - Image CDN! For reasons we'll get into with the bad (though it's not exactly bad, just frustrating for somebody lazy like myself), this project required a CDN to serve some of its images from. That's right, I said some. Photos in an actual article body like this one will be *gasp* stored in the database. Why? Laziness, that's why. But also, due to there only being a small handful of photos per article, I figured it's just easier to shove it in with the text as is. Every other photo is either served from a CDN or locally, though. Take solace in that.
• Vercel - Serverless, free, surprisngly simple! Especially when it came to adding the custom domain, my networking skills are admittedly lacking, so setting up the domain was a welcome, painless experience.

The Good

Folder-based routing

The routing system takes very little work to wrap your head around. Each folder under the "routes" folder will be a new route, e.g. /blog. You can continue to stack routes, and add slugs. You can then add a +page.svelte for the Svelte component that will render the page, and a +page.server.ts that will do all of your server-side computing for the route it's under.

This is just a simple example showing how each folder can have subfolders, leading to nested routes, as well as contain their +page.svelte and +page.server.ts.

Clear Separation of Concerns

Ya got your server.ts, ya got your <script> in a component. Simple and surprisingly easy to manage for someone who's really only ever had to deal with server-side computing.

Clean Syntax

Sveltekit feels very slim. This could be due to perhaps some missing features that other, more mature frameworks have. But at the same time, it's not overwhelming for a newbie like me to get into. Not only that, but the framework's syntax is relatively simple as well, similar but maybe slightly more powerful version of Flask's (technically Jinja's) templating syntax. Here's a small example:

This is how I create the list of posts for a given blog. The $page.data prop allows us to access data returned by the server's load function. I believe it can be boiled down simpler to "data" had I exported the variable, but I felt like this was more explicit.

The Bad

Inconsistent Environment Behavior

This could be due to my lack of npm knowledge and general web development, but Sveltekit does NOT behave the same in dev/prod environment. By dev/prod, I mean:

dev - npm run dev

prod - npm run build -> npm run preview

The dev environment let my foolish, naive self believe that I could just write to the /lib or /static folder dynamically from the server and Sveltekit would be able to serve those photos.

That is not the case. And it makes sense, security risks, blah blah blah, but this issue would have been much easier to deal with had I known beforehand it wouldn't work.

JavaScript/TypeScript

I never fully understood what people meant when they said that the JS ecosystem is bloated. It's bloated. There's so many libraries out there, so many dependencies, and a frustrating lack of clarity of what really anything does, and why it does it. TypeScript tries to alleviate this problem by adding typing, which does help! Unfortunately, at least for me, it wasn't always clear what a function would be returning, and so I set variables to 'any' more often than I should have.

The Wrap-up

I was debating on whether I would do a full tutorial series on how I created the app, but I figured that probably wouldn't be the most helpful, as I'm sure there are a ton of tutorials out there already. Instead, I've created a public template GitHub repo of this blog, with a small set of instructions on how to get it up and running. I did my best to allow it to be highly configurable via environment variables, as well as attempt to generalize some of the technology used to make it less restrictive. The link to the repo will be below. Thanks for taking the time to read my first blog post!

https://github.com/Josh-H-555/Sveltekit-Blog-Template