Why does Swift by Sundell not use any client-side JavaScript?

Over the past few decades, the web has evolved in truly magnificent ways — from a limited network of computers exchanging plain text, into a fundamental part of modern life. A major step in that evolution process was, without a doubt, the popularization of dynamic, scriptable websites in the early 2000s — so major that it’s often referred to as the birth of “Web 2.0”.

However, while much of that dynamism is used to enable rich user experiences and powerful web applications, it does often come with a cost. As websites went from simple collections of hypertext files and stylesheets into increasingly sophisticated pieces of software — they also, in general, became much heavier and slower to load.

Engineering is all about tradeoffs, and when building web experiences that need to be truly dynamic — the tradeoff of having a website be slower to load in order to enable powerful features might be completely worth making. However, even websites that simply display text and images can sometimes take seconds to load and render — even if they don’t (seemingly) include any form of dynamism whatsoever.

If dynamism is the good, slowness is the bad, then the modern web’s relentless user tracking is definitely the ugly. From user profiling, to invasive analytics libraries, to data harvesting — big data gathering is everywhere, and the same dynamic code execution that’s used to enable those great user experiences is, sadly, often used for the exact opposite — to track visitors, to display disruptive, animated banner ads and autoplaying videos, to interrupt users with growth hacking popups, and much more.

I’m not saying that all ads are bad. In fact, this website is kept free and available to everyone thanks to responsible advertising, with referral links as the only means of tracking clicks.

When I set out to build this latest version of Swift by Sundell, I knew that I wanted to stay as far away from those ugly parts of the modern web as possible. So I started to ask myself: What could my website look like if I went the complete opposite direction — if it didn’t include any form of dynamism, but still looked and felt like a modern web experience?

Basically, could I build a modern website more or less the same way as websites were built in the late 90s — as static collections of HTML, CSS and image files?

Back to basics

I love a good engineering challenge. In fact, I think that one of the quickest ways to grow as an engineer is to constantly set up small little challenges while doing your daily work. Not only does that encourage you to learn new skills, and to “think outside of the box” — it also often improves the end result as well.

Would it be possible to make this algorithm more efficient, how could I simplify this view hierarchy, or what would this API look like if I refined it down to its simplest possible form? Those are all examples of the types of questions that I love to ask myself while writing code on a daily basis, and — perhaps even more importantly — when starting a new project.

So, when I set out to build Swift by Sundell 2.0, I expanded that idea of building a website using a basic set of technologies into somewhat of a personal engineering challenge.

I had initially planned to use client-side JavaScript to implement all of my site’s interactive features — things like theming, search, signing up for my newsletter, podcast audio playback, and more. To me, someone who hadn’t really done any serious web development for the past five or six years, it seemed like running JavaScript code client-side would be the only way to realistically implement those types of features.

However, as I kicked off pre-production — with prototyping and research as my two main areas of focus — I eventually realized that it might be possible to build everything that I wanted my site to include, without using any client-side JavaScript at all. That got me incredibly excited, as not only would that let me make my website blazingly fast (as each web browser could simply download HTML and CSS files from my server and render them directly), it would also let me show (both myself and others) that building a modern-looking, nice website doesn’t necessarily require any form of dynamic client-side code execution.

Just like the web itself, both HTML and CSS have evolved so much during the past decade. CSS can now do things like animations, light/dark mode theming, dynamically showing and hiding elements, and much more. HTML also features more built-in components and widgets than ever — enabling websites to leverage functionality that’s built into every modern web browser, rather than having to ship their own JavaScript code that does more or less the exact same thing.

While using client-side JavaScript to render a website is still a completely valid option, the fact of the matter is, for some use cases — it’s simply not strictly required anymore. Sure, you still might embed external web clips (for example YouTube videos) that execute JavaScript within their own iframe, or use JavaScript server-side, but it turns out that it’s perfectly possible to render a modern web UI without relying on any sort of client-side code execution.

I don’t hate JavaScript

So the reason Swift by Sundell doesn’t use any client-side JavaScript is not because I hate the language. In fact, making such technical decisions out of some form of spite would, in my opinion, be incredibly short-sighted. This site doesn’t use client-side code execution simply because I wanted to make it as fast as it possibly could be, because I wanted to get as far away from the slowness and creepiness of the modern web as I could, and because I wanted to set myself an engineering challenge.

I still use JavaScript for certain tools that are run offline, and for some of my server-side code (such as the backend logic that drives my search feature). I also occasionally embed external web pages (like YouTube and Vimeo videos) that use JavaScript. But I wanted to see if I could realize my vision for this website without using it myself on the client side.

At the end of the day, this whole thing is not about JavaScript as a language — it’s about the concept of dynamic code execution on websites. Honestly, even if Swift somehow ends up becoming the new scripting language for the web, I’d still feel the exact same way. I don’t think every website needs to be a complex “web app”. In fact, I think many websites would become better if they weren’t.

So there you have it. That’s why this website is 100% JavaScript-free, and I felt that it was important to include that fact on the site itself — not just because I’m honestly quite proud of what I’ve built, but also to provide a (in the grand scheme of things, tiny) counterweight to the modern trend of websites relying more and more on client-side JavaScript.

I don’t have any delusions of grandeur that my little footer text will change the web as we know it, nor do I claim that I invented this approach in any way — but I thought that if I could provide an example of a somewhat complex website that isn’t rendered using JavaScript, then that could be an interesting point of discussion.

Now, does this mean that I’m encouraging other developers to take the same approach as me? Just like anything that’s remotely interesting to discuss within technology — it depends.

Here’s what I suggest: If you’re starting a new website project today, think about what its goals are, and what type of user experience that you’re looking to provide. Will you exclusively be serving static content, with user interactions that could happen through browser navigation and page reloads? If so, perhaps building things using just HTML and CSS might be a way to go. But if that’s not the case, then there’s no shame in using JavaScript either. Use the tools needed to build the products you want to build, and the tools that you and your team prefer. That’s, at the end of the day, what matters the most.

Just because building a JavaScript-free website was my challenge to myself, doesn’t mean that it has to be yours. And if you prefer building websites using JavaScript, or any other language, then that’s of course fine too. All that matters is that we, collectively as an industry, constantly try to make our software the best, fastest, and most respectful of our users as it possibly can be.

Thanks for reading! 🚀

All of the core tools used to build this website are open source. Check out the Publish static site generator if you wish to learn more, and you’re of course more than welcome to contact me with your questions, comments and feedback — either via Twitter or email.