I changed my mind about writing new JavaScript frameworks

⚠️ This post is over two years old and may contain some outdated technical information. Please proceed with caution!

A few months ago, whilst deep in a dark cloud of personal overwhelm caused by the unrelenting exponential growth of the web ecosystem, I wrote about how you probably shouldn’t write a new JavaScript framework. But I’ve changed my mind. Maybe you should write a new JavaScript framework. And here’s why.

I’m currently building WTF: What the Framework? — a new tool to help developers choose their next JavaScript framework based on the features they need for their new project. The idea for WTF came out of the most frequently asked question in the Jamstack community: “What JavaScript framework should I use?” Whilst the answer is always “it depends,” I wanted to empower developers to drill into those dependencies and make a decision based on the type of project they’re building.

WTF asks just two questions about your project, and shows you a list of JavaScript frameworks that are suited to building your project.

1. What type of website are you building?

2. Do you need your website to maintain state across multiple pages?

The TL;DR is that the first question determines if you’re building a static site, a site that needs server-side rendering, or if you need a combination of the two; and the second question determines if you need a Single-Page Application (SPA) — a JavaScript application that builds HTML for different routes locally in the browser, or a Multi-Page Application (MPA) where every route has its own HTML file that’s delivered from the server and doesn’t rely on client-side JavaScript.

The criteria for including a JavaScript framework on the WTF list were as follows:

1. The code is actively maintained (a release happened in the last year)

2. The project has published a stable release (at least version 1)

And here’s where my ridiculous 300-new-JavaScript-frameworks-a-week-exaggeration falls a little flat. Say my project needs to serve both static content and server-side rendered pages, and I don’t need to manage state across multiple routes. There are currently only four options to choose from on WTF: Eleventy, RedwoodJS, Next.js and Gatsby. WTF?

And here’s where it gets even more frustrating.

Next.js or Gatsby aren’t entirely appropriate for my use case, because they’re actually SPAs by default. However, you can generate a static HTML export with Next.js or render a static site with Gatsby, but you’d need to remember to use native anchor tags instead of the <Link /> component to prevent JavaScript pre-fetching and to preserve the concept of an MPA. What’s more, static site builds in both Next.js and Gatsby can’t make use of server-side rendering functionality. So with these two frameworks, your project is either a hybrid SPA, or a static MPA with workarounds.

Eleventy is a good option, but the server-side rendering on the edge functionality is currently an experimental feature that only works on Netlify.

And so we’re left with RedwoodJS, a full-stack framework which could be a great option in theory, but appears to come with a lot of overheads and integrations that I’m not sure I need just yet!

There simply aren’t enough options.

I’ve presented only one problem here — and there are many. As Zach Leatherman (creator of Eleventy) points out, 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 SSR my new project needs, or if it even needs SSR at all? And what’s more, as the web continues to evolve, developers are hypothesising that servers and serverless can actually cut down build times and match your static site's speed. So I should definitely be using servers, then? Should we even be building static sites anymore? 🌶

And the SPA vs MPA debate rages on. Ben Holmes, core maintainer of Astro, argues that modern browser APIs could make Multi-Page Applications feel like Single-Page Apps — rendering SPA frameworks much less necessary in the future.

And this is only touching the surface. Whilst React has been the go-to SPA framework for almost a decade, younger frameworks such as SolidJS are making moves to tackle the performance constraints and overheads that come with reactive DOM updates. There are certainly 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.” He goes on to describe how he’s committed to bringing framework authors together to work on building a better web ecosystem — together. “Qwik, Astro, Solid, Marko, 11ty, and Angular now share a friendly space to share ideas [and to] bridge the gap between these technologies and the people that would use them.” I’m really grateful to Ryan for sharing his insights on being a framework author. It’s actually what helped challenge my views on this part of the web ecosystem and inspired me to write this post.

So if there’s a problem you want to solve, and if it could be solved through building a new JavaScript framework — build that new JavaScript framework. I’m with you. And I’d love to try it out one day.