The WWDC by Sundell 2019 retrospective

Shortly after WWDC 2018 ended, I decided that for 2019, I wanted to do something special. While I was really happy with how my 2018 “Daily WWDC” series of articles had turned out, I had this idea of covering the conference in a much more thorough — but still developer-focused — kind of way.

Fast forward to the beginning of 2019, and me being hard at work building the next major version of Swift by Sundell, for which I’m moving away from Squarespace towards static HTML — using my work-in-progress Swift static site generator. However, the prospect of moving Swift by Sundell — which is my main source of income these days — to a brand new tech stack, using a brand new site generator, was (and still is) super scary. So I figured that before I’d make that jump, I’d need to conduct some form of test of this whole new setup.

The combination of the above two ideas is what led to WWDC by Sundell — a brand new, dedicated site for covering WWDC 2019 — as well as a large-scale test of my new web tech stack. In this retrospective — I’ll reveal how that test went, and share some overall thoughts and takeaways from running this site during WWDC and what my plans are for my static site generator.

The tech stack

Let’s start by taking a closer look at the tech stack that I chose to base WWDC by Sundell on, as well as its overall architecture. When making any sort of big architectural decision, I always first like to list what my goals are with what I’m aiming to build — and let those goals inform my tech decisions, rather than the other way around.

These were my core goals for WWDC by Sundell:

What makes the web both exciting and terrifying at the same time is just how many options there are for building anything. For just hosting a statically generated site alone, there are dozens of options — from GitHub’s built-in Pages feature, to dedicated hosting services, to web servers that are fine-tuned for serving static content.

After carefully surveying what kind of options that I had at my disposal, I finally settled on the following tech stack, from top to bottom:

CDN: Cloudflare

I picked Cloudflare as my CDN (Content Delivery Network). I realized quite quickly that if I were to achieve my goal of building a blazingly fast site, then all of its content would need to be heavily cached using a global CDN — and Cloudflare had the exact infrastructure that I was looking for.

I set up Cloudflare to unconditionally cache all of my site’s content — including its HTML — and then I’d invalidate that cache after each deploy. That way the vast majority of the site’s requests would never hit my server, and instead be served directly from Cloudflare’s cache — resulting in fast page loading speeds, since Cloudflare has edge nodes all over the world, and minimal pressure on my own server.

Cloudflare also gave me HTTPS/SSL support for free, and offered me a lightweight but useful set of analytics — such as number of page views and visitors — without requiring me to embed any analytics SDKs, or to compromise user privacy.

Hosting provider: Linode

Since one of my core goals with this site was to achieve a highly flexible setup that I’ll be able to keep using as I continue to grow my work in different directions — I came to the conclusion that I would need to move away from plug-and-play services, and instead run my own server. While I do like services like Squarespace, GitHub pages, and others like it — they always come with a certain “technical ceiling” that it’s really hard to grow past.

When I first started publishing weekly articles back in 2017, I did so using Medium — simply because it was the (by far) easiest way for me to get started. I knew that if I’d have to spend any time on things like configuring services, picking themes, or tweaking HTML/CSS code — then there was no way I’d be able to keep up with writing a new article every single week, so back then I was definitely optimizing for ease-of-use.

These days, I’m instead optimizing for future flexibility. During the past 2,5 years, my content has grown from small Medium posts — into several article series, hundreds of Swift tips, multiple podcasts, and beyond — and with new formats on the horizon, like my upcoming book, I really need that additional flexibility. Having my own server would let me do things like install custom software, run Swift server-side, and setup things like a store for selling my book later this year.

All of this is what led me to Linode. While I’ve heard great things about other services — like DigitalOcean and Heroku — Linode seemed to strike just the right balance between being cost-efficient (which is important when you’re giving almost all of your work away for free), user friendly, and robust. Using Linode enabled me to quickly fire up an Ubuntu Linux instance and easily configure it to both serve HTTP content, and to accept FTP-based deployments, all within an hour — using a server that’s under my control.

Web server: Apache

With Cloudflare set up to handle all incoming requests and to pull content from my Linode server to populate its cache — all that was left in terms of server-side infrastructure was to decide what web server to use. Just like with all of my other decisions up to this point, there were many different options to choose from — but since I knew that this choice wouldn’t really have a big impact on the site itself (as I was opting for such a cache-heavy approach), I decided to go with a web server that I already knew very well — Apache.

If my web server was to be put more in the critical path in terms of handling requests, then I’d probably pick one capable of handling a larger number of parallel requests — such as nginx — and if I wanted to build something more custom I probably would’ve opted for a Swift-based solution, such as Vapor, or even building something myself right on top of SwiftNIO. But since I knew that the vast majority of all my incoming requests would end up being handled by Cloudflare, then I chose the approach that’d be the easiest to set up (for me).

All I needed to do to get Apache running on my Linode server was to simply install it using apt-get — something I’ve done many times in my past career as a full-time web developer — and to configure a few settings, like what 404 page to use.

And with that done, I was ready to start deploying my site!

Swift static site generation

The final piece of the puzzle was my new Swift static site generator, a project that I’ve been working on on-and-off for the past year. This generator is still very much a work in progress, and I’ve changed its design multiple times during its development so far. Just like when I wrote Imagine Engine, or Splash, my goal is not simply to create “yet another solution”, but instead to do things a bit differently — to try to achieve new kinds of results.

Splash was definitely not the first Swift syntax highlighter, but it’s the only one that I’ve seen that is capable of producing such highly accurate results across all recent Swift versions — without requiring the user to embed any JavaScript. My static site generator is designed along those same lines — fast execution and highly accurate results, while also giving the user a ton of power when it comes to customization.

For example, the site generator I’m building will support things like plugins to make it easy to connect it to any hosting service for one-command deployments, and it won’t make any hard assumptions about what kind of templates a site is using, or even how its content is structured. It’s built around the idea that each site will be defined as a Swift package, making it possible to both get started with just a few commands, and also making all sorts of customization possible — by simply writing Swift code.

I’m planning to open source this site generator once the new version of Swift by Sundell is finished. By that point I’ll have two sites built using it, which’ll give me enough confidence to open it up for anyone to use. I’m really looking forward to sharing more details about this project as I continue working on it, and as I get closer to a version that I consider good enough to release.

100% JavaScript free

While this site’s CDN-focused architecture played a big part in making it achieve its speed goal — there’s another major reason why it turned out so fast — it doesn’t contain a single line of JavaScript.

I should point out that I’m not one of those developers that passionately hates JavaScript, but it’s undoubtedly one of the main reasons that the modern web feels so much slower than it ought to. It almost seems like the web development community has gone from “Let’s try to make Doom run in a web browser” to “Let’s make every website the same size as Doom”, by filling even the simplest sites with everything from React to CPU-crunching ad-tech.

I wanted to move as far away from that as possible, and while I realize that not every website contains just articles and audio files — and doesn’t require any form of login or other user-submitted data — I do believe that the modern web relies far too heavily on client-side scripting. By eliminating the need for any sort of JavaScript downloads or evaluation, I was able to make this site render using a minimum number of rendering passes — often resulting in a whole page rendering in less than 100 milliseconds.

In my opinion, that shouldn’t be an exception, it should be the norm.

The results

When launching this site, I honestly didn’t really know what to expect in terms of technical results or how it would be received by the community. On one hand I was quite confident in both the tech stack that I had chosen, and the concept of the site itself — but on the other hand, whenever I launch something, I never assume that it’s going to be even remotely successful.

While I take all of my projects seriously, I kind of treat them as experiments when I first launch them. Some will succeed, others will fail. Regardless — I learn from them, and either evolve them or abandon them — and move on. While I very much launched WWDC by Sundell with that mindset, within just the first 24 hours, it ended up performing much better than I could ever have imagined.

Here are some stats as to how the site performed, both from a technical point of view, as well as its scale and audience size, during the week of WWDC:

I’m incredibly happy with the above results, both as an indication as to how many people enjoyed my WWDC coverage this year, but also as validation that my new tech stack — from Cloudflare at the top, to my static site generator at the bottom — works incredibly well.

The experience of building and launching this site has also given me much more confidence when it comes to building brand new things, instead of just sticking to what I’ve built up over time with Swift by Sundell. It’s all really exciting, and I can’t wait to keep trying new things like this, and to see where it takes me — and anyone who wants to follow along.

Thank you!

As I wrote in my opening article, WWDC by Sundell was very much made to be a way for anyone to closely follow WWDC, from anywhere in the world. So hearing from such a large number of people throughout the week that this site made them feel more connected to the conference than ever before, and that it provided a way to more easily digest all of the new tools, APIs and technologies — was incredible.

Thanks so much to all of you who read this site during WWDC, and who said so many kind things about it on Twitter and through email. I’ll be honest, producing this site was a huge amount of work, but hearing that so many people got joy and value out of it made it feel totally worth it.

I also want to thank the four wonderful sponsors that helped me finance this site and my work on it. If you enjoyed this site, then I’d really appreciate it if you’d check them out using these links — as it directly shows each sponsor that their money was well spent:

I’d also like to extend my special thanks to the amazing group of people who participated in my series of developer interviews, and helped create content for this site — Gui Rambo, Dave Verwer, Antoine van der Lee, Anastasiia Voitova, Meghan Kane, and Paul Hudson.

Last but not least, big thanks to John Gruber for featuring this site on Daring Fireball, which really helped spread the word, as well to all of you who tweeted, blogged, podcasted, and shared the site in other ways — you are all amazing, and I really appreciate your support.

Until next year, see you on Swift by Sundell, and thanks for reading! 🚀