On December 17th, 2020, I created the website knox.codes for a UCSD GenEd class project. I used the open source static site generator Gatsby and an existing site template called Lumen to get the site stood up with my content in the 24 hours remaining that my procrastination had left me. All the underlying styling and actual programming was done for me; all I had to do is write articles (one of which I filled entirely with Lorem Ipsum. Yes, I got the credits).
One of the articles that actually had content was Modern DevOps and the 24-Hour Blog. This article basically just discusses how far the development and DevOps worlds have come to deploy a technically sophisticated website like a blog in under 24 hours of work. By the way, this article is now unlisted, a feature that didn’t exist when knox.codes was built with Gatsby.
You see, while I was stuck at home with Covid-19 during Christmas, I thought, “what better way to burn off frustration then to do some web development”? I had already been looking for a good excuse to try out Svelte, the sexy new web framework to simp over these days.
I had also been looking to replace Gatsby, since the amount of memory it uses during the compilation process scales with the size of your content. With only about 8 articles, Netlify was no longer capable of compiling it consistently, leading me to run the build repeatedly trying to hit the lucky 10% chance of it actually working whenever I wanted to post a new article. Believe it or not, this made me less likely to write articles!
So, this article is in a way a tribute to that first one: I want to summarize my approach, the results, and give just a couple words on my experience using Svelte.
Firstly, you can learn everything you want to know by checking out the published source code and documentation on GitHub. The key difference between this new version and the old one is that this time, I wrote the blog “from scratch”, without the use of an existing template, primarily using Svelte.
Here are the technologies I used to manage the frontend, types, styling, and other compilation-level goodies that Svelte supports:
The way posts are supported are similar to how they worked in the original Gatsby blog:
just add a markdown blog article into
the src/lib/posts
folder. They will automatically be precompiled to Svelte components and rendered on the site.
Metadata supplied in the so-called “frontmatter” of the markdown will be used to categorize and tag the articles, which can then be used to filter articles on the site.
Does all this mean it took me even longer this time? Shockingly, no, despite needing to rewrite all the logic and styling myself, the final time to implement was only 14 hours, 45 minutes of work start-to-finish.
Here’s the features that we pulled off:
meta tags and automatically generating /sitemap.xml./rss.xml.Now, how exactly were we able to cram in this much functionality while also finishing in less time than the original template? Yes, a very small part of it is probably me getting legitimately better at web development in two years, but there are some bigger forces at play here.
This was the core theme of my original article, but yes, DevOps has continued to mature further even in the past two years. I’m still using a ”jamstack” deployment platform, but I’ve switched to Vercel from Netlify, mainly because Vercel is a bit simpler and more robust in my specific experience, and the team that built Vercel also wrote Vite and SvelteKit, so the deployment integration between them is intimate and efficient.
Yes, I could have deployed my blog on Kubernetes, but perhaps it’s for the best I don’t.
The most important decision I made when rewriting my blog with Svelte was to not change anything about the site itself. This changed my goal from “develop a blog” to “create a website that looks and behaves exactly like this other one”.
This is a common approach I use for learning new technology. Trying to build a new thing with new technology is more cognitive load than just trying to build an old thing with new technology. You also get the additional advantage of being able to directly compare the old technology you already know with the new.
As it turns out, design is most of the work of web development. And I’m not just talking about UI or upfront design. There’s a huge difference between having a completed design for a website and having a working version to work off of. After all, software development is not simply a process of writing code, it is largely an adventure of discovering the problem you are trying to solve as you work on it.
Having the working version of knox.codes on standby made it extremely simply to see what I had successfully done and what was left. Just because I didn’t copy any code doesn’t mean it wasn’t 1000 times easier than it would have been otherwise.
Here is a quote from my original 2020 article:
After all, building a website from scratch (without the use of WordPress and the likes) is a deeply complicated, convoluted process.
In some ways its easy to learn, but almost impossible to master everything that goes into making a website that not only works, but works well, look nice, and doesn’t break. Paradoxically, the farther the frontend and backend development worlds accelerate, the more technology they invent to make websites better, the harder it is to start learning about how to actually do any of it.
Svelte, at first glance, appears to exacerbate this issue by being fully incompatible with existing component-based frameworks like React and Angular (yet another technology to learn). Looking closer however, it’s also fighting against this trend in its own small way.
One of its main gimmicks features is that it presents a syntax familiar
to the budding web developer:
<script>
export let name = 'KNOXDEV';
</script>
<style>
h1 {
font-size: 4rem;
}
</style>
<h1>
This is a component belonging to { name }!
</h1>By mimicking the feeling of the framework-less web development experience, Svelte maintains a slightly more gentle learning curve for the new developer while also reinforcing basic concepts.
Svelte also fights against the trend of web frameworks getting bigger and slower runtimes. It does this by compiling your app to imperative code that surgically mutates your webpage in a minimal and runtime-free fashion.
In reality, the above example component gets all the features you would want in a reusable component framework such as hybrid server-sided rendering and client-sided rendering, local styles, Typescript and PostCSS preprocessor support, and more all at compile time.
Unfortunately, the user promise of being seemingly low-code / simple and powerful / featureful are competing, which creates what is known in software design as a cursed problem. Cursed problems do not have solutions, since they arise from a conflict in core promises made to the user. They can only be weaseled around, and the outcome of Svelte’s cursed problem is typical: there is a lot of “magic” in Svelte, and anybody in software development knows that is not a compliment.
Using Svelte is a lot like writing code in some kind of frequency encoding: common tasks and functionality are as simple to perform as possible, while more infrequent tasks are usually more verbose and require hacky workarounds.
This may all sound like criticism, and while this approach comes with its own learning curve, it also has a lot of benefits. And in my case, rewriting this blog is the ultimate example of an app that fits almost perfectly along Svelte’s “happy path”. It is directly due to Svelte that development was much faster.
Using cloc, we can quantify this:
| Language | files | blank | comment | code |
|---|---|---|---|---|
| TypeScript | 12 | 41 | 7 | 244 |
| Svelte | 13 | 54 | 1 | 212 |
| CSS | 1 | 9 | 1 | 30 |
| HTML | 1 | 0 | 0 | 12 |
| SUM | 27 | 104 | 9 | 498 |
Compared to the old Gatsby codebase that I admittedly didn’t write:
| Language | files | blank | comment | code |
|---|---|---|---|---|
| JavaScript | 73 | 183 | 73 | 1665 |
| SCSS | 24 | 175 | 22 | 702 |
| SUM | 97 | 358 | 95 | 2367 |
Ignoring that I am worse at commenting my code, a ~79% reduction in lines of code is honestly comical. I can complain about Svelte’s “magic” or lack of comprehensive documentation all day, but there is something to be said about its performance in its own problem space. If nothing else, Svelte was definitely the correct tool for this kind of job.
If this was an article about Svelte, I would go deep on my specific criticisms. Svelte is but one tool of a
swirling, unknowable vortex of web development frameworks and paradigms. To constantly stay on top of every
www.*.io that hits HackerNews would be a full time job.
That said, I think it’s important for us as engineers to always be learning something. It doesn’t have to be the hot new thing, but honestly, that is not the worst metric you could use. The secret to learning and sticking with a new tool regularly is to be selfish: only learn what you can put into immediate, self-benefiting application. Only enrich your resume if it will also enrich your life.
Published December 17th, 2022
The ramblings of a software engineer, with an emphasis on security.
© Aaron James 2022