Salma Alam-Naylor

Posted on Oct 4, 2022

I changed my mind about writing new JavaScript frameworks

#javascript

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.

There are fewer options than we thought

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.

What type of website are you building?
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:

The code is actively maintained (a release happened in the last year)
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.

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 in order to prevent JavaScript pre-fetching 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.

⭐️ Update: Nuxt is also a valid option!

After sharing this post on Twitter, Daniel Roe let me know that Nuxt 3 provides a hybrid combination of static pages and server-side rendered pages as an MPA. He also submitted a pull request to update the WTF project. Thanks, Daniel!

There are problems to be solved

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?

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 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.

Top comments (14)

DiegoFranco2001 • Oct 6 '22

No matter how many JS framework are out there, the market will ever choose the technology with lowest cost, easy development and with more developers working with. So, why not improve the technology that we already have?. In my opinion, not only from the web dev point, there could be hundreds of framework, 3 or 4 will ever be the mainly used, and, make framework just for fun and for understand some concepts.

Salma Alam-Naylor • Oct 6 '22

why not improve the technology that we already have?

An absolutely valid point!

Some people may argue that the technology we already have can be tricky to navigate. There is likely years of tech debt wrapped up in React, for example. You know how sometimes a feature gets so convoluted in production, with fix on top of fix, that sometimes it's better to rip it out and start again rather than embark upon a gruelling refactor?

I'm speculating here, but fixing what already exists may limit innovation. Then again, working within constraints is also something that can spark innovation.

There will always be pros and cons to any approach. Always two sides to the story. Always more than one approach — and each one as valid as the next.

DiegoFranco2001 • Oct 6 '22

Yeah, you're right, at this point, I think that JS frameworks has become in a matter of subjectivity, maybe due to the nature of JS? 🤔, because, I've not seen other language with this situation (hundreds of frameworks). JavaScript ecosystem is a case study, something should make a thesis about this. :D

Salma Alam-Naylor • Oct 4 '22

How much does a ticket cost?

Damian Cyrus • Oct 5 '22

I hear my senior talking:

If you don't like it: change it!

Works everywhere 😃

Good post!

Siddharth Kumar Mehta • Oct 4 '22

Thanks, Salma for sharing your experience with the dev community.

Sm0ke • Oct 4 '22

nice ...

Ibrahim • Oct 5 '22 • Edited

While that sounds all good. In reality it's not all sunshine and rainbows.

The "platform" does not support all the features that JS frameworks provide such as SSR, partial hydration etc.

The "platform" moves at a snail pace compared to the OSS JS fws that innovate so much more quickly to offer better DX, performance and features.
Using the "platform" is so cumbersome, that the vast majority of the time you need to use other frameworks to even compose WCs and handle state etc...

Ren Hiyama • Oct 5 '22

Further, frameworks makes sure that your code can run on not so old browsers, like shadow Dom is relatively new and you probably have to add polyfills, and another example is import maps, and they're still under consideration+ not supported by every browser...

Muhammad Sifat Hossain • Oct 5 '22

Vanilla! Vanilla! Vanilla! Frameworks And Libraries are mere details. I only use them as plugins. That's what Uncle Bob taught me.

artydev • Oct 4 '22 • Edited

I launch the #noRAV # tag : no React no Angular, no Vue :-)

DiegoFranco2001 • Oct 6 '22

What should we use? XD

artydev • Oct 6 '22 • Edited

All depend of your constraints.

For my personal projects I have gathered some functions I found useful in a little library.

Among those functions :

morphdom
observable, subscribe from Sinuous
some functions from DML

Create your own :-)

Here is an example MVU Sample

const {
  dom,  // ~<=> <div>
  udom, // ~<=> </div> 
  m,    // ~<=> document.createElement
  render, // ~<=> append
  observable, // create e reactive variable
  subscribe // reacts on reactive varible changes
} = MVU;

const h1 = m("h1");
const div = m("div");  

const state = observable({ 
  counter : 0,
  name: "wait 2s...."
})

state.get = function (prop) {
  let _state = state()
  return _state[prop]
}

state.set = function (patch) {
  let _state = state() ;
  state({..._state, ...patch});
}

function App (state) {
  const s = state();
  let view = dom()
    h1(`Name : ${s.name}`)
    h1(`Value :  ${s.counter}`)
  udom()
  return view;
}

function createApp (target, application, state) {
  subscribe(() =>  render(target, application(state)))
}

createApp(app, App, state); 

setInterval (() => state.set({counter : state.get("counter") + 1}), 900);
setTimeout(() => state.set({name: "Bob"}), 2000)