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 questions. Silly. [00:02:00] 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 are building a static site, which is a website that’s packaged up and served as static HTML files and. 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 are refer to this mode as hybrid mode. Question two was originally, do you want to maintain state across multiple pages, but you can [00:03:00] achieve that in more than one way.
But say my project needs to serve both static content and server ended pages, so hybrid mode, and I want to build a multi-page application. Here we have five options, Eleventy, Redwood.js, Next.js, Nuxt, and Gatsby. Plenty of options, right? Not really. When we look at what the frameworks. Next, JS or Gatsby aren’t entirely appropriate from our use case because they are spars by default.
They use. Now there are ways to generate static sites with nex 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, [00:05:00] 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, NEDT or Redwood js. Now, Ned three specifically provides a hybrid combination of static and server side rendered pages as a multi-page application, but I don’t know view right now, and I’m not sure I want to learn a new framework, in a new project.
Redwood JS 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 nuance.
Zach Leatherman, the creator of Eleventy, points [00:06:00] 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.
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 speed. This means you can do less pre-building of static pages and do more server side rendering and still have a fast sight. So service can give me better performance.
There are different types of service 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? [00:07:00] As Ryan Carniato, creator of Solid JS says, we need new frameworks.
We need innovation. 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. But I talked to him in depth about all of these issues when I released that blog post and stupid website. So I recently researched into the history of the tech that powers Twitter, and it’s an interesting story.
This was in 2013, 10 years ago. In 2017, Twitter released Twitter lite. 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.
I will encourage you to ask meaningful questions. When you’re choosing your tech, who is your audience? How fast is their internet connection? What devices do they use? Do they use more than one device frequently? How do they actually use the product? And because of all this and more what the framework is a pretty much entirely useless tool.