This talk premiered at TheJam.dev 2023.
Click the video above to play
My name is Salma Alam-Naylor and I write code for your entertainment, and I am going to take you on a journey and show you why I changed my mind.
Now the answer of course is always, it depends, but I wanted to encourage developers to drill into those dependencies and make a decision about a framework to use based on the type of site they wanted to build. No hype, no bias. And I tried to achieve this by asking just two question. Silly, I know, it's far more complicated than that, but let's take a look.
Question one, what type of website are you building? Now without biasing the answer with too much technical terminology, this tries to determine if you're building a static site, which is a website that's packaged up and served as static HTML files and assets from a content delivery network. These sites are good for content-based sites that don't change often. Or are you building a site that needs to be server-side rendered, where each HTML page is built freshly on the server at request time. These are good for dynamic sites where each page needs to provide a custom experience for each user. Or are you building a combination of the two, some static pages, some dynamic pages, and I'll refer to this mode as hybrid mode later.
But, say my project needs to serve both static content and server-rendered pages, so hybrid mode, and I want to build a multi-page application. Here we have five options. Eleventy, RedwoodJS, Next.js, Nuxt, and Gatsby. Plenty of options, right? Not really when we look at what the frameworks do.
Next.js or Gatsby aren't entirely appropriate for my use case because they are SPAs by default. They use React. Now, there are ways to generate static sites with Next.js or Gatsby to turn the site into a multi-page application. But you'd need to do a few workarounds and also static builds using these frameworks actually can't make use of server-side rendering functionality, at least at the time I wrote this talk, so it's a no-go for my requirements.
Eleventy is a good option, but the server-side rendering on the edge functionality is currently experimental and it only works on Netlify and I don't like vendor lock-in.
So we're left with two options, Nuxt or RedwoodJS. Now, Nuxt 3 specifically provides a hybrid combination of static and server-side rendered pages as a multi-page application, but I don't know Vue right now, and I'm not sure I want to learn a new framework in a new project.
RedwoodJS is a full-stack framework, which could be a great option in theory, but it comes with loads of overheads and integrations that I'm not sure I need just yet. Given what the web is capable of in 2023, there are simply not enough options. I've presented only one problem here, my hybrid MPA, but there are many more nuances.
Zach Leatherman, the creator of Eleventy points out that there are also many ways to define server-side rendering. So how do I decide which framework to use if I don't know which type of server-side rendering I need, or if I even need server-side rendering at all. And as the web continues to evolve, the choices we have to optimize for performance are growing.
Ben Holmes, core maintainer of Astro, ran some experiments using caching and server-side rendering, and he discovered that server-side rendering can still match your static site's speed. This means you can do less pre-building of static pages and do more server-side rendering and still have a fast site.
So servers could give me better performance, but there are different types of server-side rendering. I don't know what I need, but should we even be considering static sites anymore? There are certainly real world problems that could be solved with new frameworks. And we're developers we build to solve problems, right?
As Ryan Carniato, creator of SolidJS says, "We need new frameworks. We need innovation right now." Ryan is committed to bringing framework authors together to work on building a better web ecosystem together, avoiding the framework wars and building a better web. And I talked to him in depth about all of these issues when I released that blog post on stupid website.
So I recently researched into the history of the tech that powers Twitter, and it's an interesting story.
In 2017, Twitter released Twitter Light, aimed at improving the mobile Twitter experience by minimizing data usage, loading quicker on slow connections, and taking up less than one megabyte of device space. You can still install that now. It's a Progressive Web App, aiming to replicate the native app-like experience of a single-page application.
The story goes on. You can read more about it in depth on my blog, but the bottom line is the tech that powers Twitter and so many projects and products go on a journey, much like I did last year.