I changed my mind about writing new JavaScript frameworks

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 shouldnt write a new JavaScript framework. But Ive changed my mind. Maybe you should write a new JavaScript framework. And heres why.

There are fewer options than we thought

Im 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 theyre 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 youre 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 thats delivered from the server and doesnt 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 heres 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 dont need to manage state across multiple routes. There are currently only four options to choose from on WTF: Eleventy, RedwoodJS, Next.js and Gatsby.

And heres where it gets even more frustrating.

Next.js or Gatsby arent entirely appropriate for my use case, because theyre actually SPAs by default. However, you can generate a static HTML export with Next.js or render a static site with Gatsby, but youd need to remember to use native anchor tags instead of the <Link /> component in order to prevent JavaScript pre-fetching to preserve the concept of an MPA. Whats more, static site builds in both Next.js and Gatsby cant 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 were 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 Im not sure I need just yet!

There simply arent enough options.

There are problems to be solved

Ive 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 dont know which type of SSR my new project needs, or if it even needs SSR at all? And whats 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 were developers; we build to solve problems, right?

Frameworks can help solve problems

As Ryan Carniato, creator of SolidJS says: We need new frameworks. We need innovation right now. He goes on to describe how hes 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. Im really grateful to Ryan for sharing his insights on being a framework author. Its actually what helped challenge my views on this part of the web ecosystem and inspired me to write this post.

So if theres a problem you want to solve, and if it could be solved through building a new JavaScript framework build that new JavaScript framework. Im with you. And Id love to try it out one day.