Shopping for a Javascript Meta-Framework

I am nearly – and only – a five year old software engineer. And I’m still enlightened and entertained by all of the new frameworks, libraries, packages, ideas that surface every week in the Javascript community. One of the largest trends in recent years is a shift from frameworks to meta-frameworks..

What even is a JavaScript Meta-Framework?

A Framework, duh

These projects provide a larger architectural foundation. The metas take on more difficult problems and big decisions that prevent projects from getting a solid start. They do this by defining the way to build a your-brand-of-meta-framework app.

They provide convention. There are a few things the meta-framework brands have agreed upon. One convention is file-based routing – for example, using a project directory `/routes` and special filenames `/routes/thing/[id].js` to determine application routes. Another convention is utilizing a project directory for api endpoints or serverless functions. In simple terms, that is just a lot more problems that an application developer no longer has to manage.

The meta-ness of these frameworks comes from their ambition to solve problems beyond what single-page application (SPA) or rendering frameworks have been solving. And each are, in fact, built atop these frameworks – soo meta.

Full. Stack. Magic.

Meta-frameworks are also considered to be full-stack frameworks. In a variety of flavors, they each allow components to be rendered or streamed from a server (SSR), statically generated (SSG) at build time, completely client side (SPA), or any combination of the above (and probably other ways).

Because of the different rendering approaches, each framework has layers of abstraction for fetching data and managing state. This allows authors to follow familiar patterns of making declarative UI while the framework handles the lifecycle on both the server and client seamlessly.

One of the first advantages of these frameworks that I became aware of is SEO, a sore spot for traditional SPA applications. Because most of the application is rendered on the server and can include dynamic meta tags, it is much more likely to index on search engines. Hear that? All the traditional full stack app framework developers just giggled in unison.

And all that giggling – it’s allowed. Look, I didn’t live through it. But a lot of folks are saying these types of problems were created by SPA frameworks and that meta-frameworks are taking us back to a time before these problems existed. There have been full stack frameworks for longer than there have been frontend frameworks, young man. But the promise of this new wave is that they address the full stack from the front end rather than from the back end. You are able to build a highly interactive application that feels like a SPA while leveraging server-side capabilities. Offering flexibility, from simply utilizing advanced hybrid rendering techniques to building the entire backend within the same application, including API, cloud functions, database schemas, type systems, and shared application logic – all written in the same language and context.

A few outstanding examples

Next.js

Perhaps the first of the breed. Next popularized the idea of the meta framework. It just provides so much that React intentionally avoids as a library vs a framework. Many former React core members now work on Next. And it is often the first to adopt new features from React itself ( like server side components ).

•  Backed by: Vercel
•  Built on: React
•  Differentiator: Cutting edge React

Remix

When Remix came on the scene, its major contribution was (and is) its focus on web standards. With super novel ideas like using a `<form/>` to submit a form. Its founding authorship also includes folks from React Router. So there’s a deep knowledge of the inner workings of React and what applications need to thrive.

• Backed by: Shopify
• Built on: React
• Differentiator: Web standards

Nuxt

Originally inspired by Next.js. Nuxt changed a letter and uses Vue for rendering. Over time though, Nuxt has become entirely its own thing. Since Nuxt version 3, there has been a huge push to separate all of the components that make up the project. As such there’s also a push for modularity. Giving contributors the opportunity to hook into the framework and author Nuxt modules to extend its abilities.

• Backed by: Open Source
• Built on: Vue, Vite, Nitro/UnJS etc.
• Differentiator: Highly Modular

SvelteKit

Svelte and its founder Rich Harris have one main goal: to make web application development better and fun. SvelteKit is an extension of that goal that brings Svelte to the full stack. One of primary differentiators is that it is compiled; meaning the framework has complete control over the output of the application and its performance.

• Backed by: Vercel
• Built on: Svelte
• Differentiator: Compiled

Astro

“The web framework for content-driven websites” says it all. Static generation is the primary target, though it does allow for other rendering depending on project needs. Which makes it a great choice for a website vs web app. Astro has its own component syntax that is designed with content in mind. One of its coolest features is that it allows you to bring in components written in any of the most popular frameworks. So, you can write your main content in Astro and some super highly interactive pieces in the framework of your choice (or the choice of the npm package you’re stealing).

• Backed by: Open Source
• Built on: Astro…or whatever
• Differentiator: Content-driven

SolidStart

SolidStart isn’t even in 1.0. It was almost there…but made some heavy changes inspired by the Nuxt project’s move to a more modular architecture for the underlying framework. The same architecture in fact. Solid’s claim to fame is signals… which nearly every other UI framework has since adopted (even Angular!) and has even led to a proposal to add signals to JS. The component syntax is heavily inspired by React; but it famously does not use a VDOM and has the finest fine-grained control of any of the frameworks I’m aware of.

• Backed by: Open Source
• Built on: Solid (React inspired)
• Differentiator: Speed & fewer opinions

QuikCity

Built by former members of the Angular team; Qwik and QwikCity aim to be…quick. Speed is its main goal; especially quick at all of the metrics Chrome uses in its lighthouse score. It does this by sending completely interactive HTML and lazy loading all of the JS using a variety of tactics. It then “resumes” loading the page in the background. And theoretically reduces the amount of javascript that ever has to be loaded in order to use the app.

• Backed by: Open Source
• Built on: Qwik (React inspired)
• Differentiator: Resumability

Fresh

The folks at Deno have their own framework. Like some others on the list, Fresh tries to minimize client-side JS for speed and progressive enhancement. It uses a technique called Islands to isolate client side code from the rest of the application. Its relationship to Deno means it is focused on things important to Deno. The “edge”. JIT rendering, and Typescript.

• Backed by: Deno
• Built on: Preact (React inspired)
• Differentiator: Islands of Interactivity

Things to consider

Underlying Rendering Framework

Potentially and probably the most important factors in choosing a meta-framework is the underlying rendering framework. While the meta-frameworks all have particular niche focuses that their next versions are chasing after; their underlying feature sets are very similar. And they frequently adopt each other’s good ideas in future versions.

That being said, the community and framework beneath the meta-framework are much more established, though they are also looking more similar than they were just a few years ago (or maybe it’s just my eyes).

Maturity

At the time of writing, the projects mentioned in this article are all at varying stages. Again, their underlying frameworks also vary greatly in maturity. For example, React’s age and project numbers are huge, so there is a lot of support and ready-made solutions out there. Vue is known for having an incredible community around the world and has great international support. Svelte has been dubbed “most loved” for its simplicity and small learning curve and for its ability to work seamlessly with vanilla JS libraries.  It’s also worth considering if the flavor you’re most interested in is getting long term support from and for the team maintaining it.

You

Most importantly, which option fits you? What about your co-developers, and the project you’re creating? Like with everything in software, there are tradeoffs. The choices in meta-frameworks are mostly about developer experience and are somewhat philosophical; but choosing something you will love to work with can make all the difference.

And hey, the time and opportunity for choosing tools like these only comes up every so often. To me, meta-frameworks are like brand new power tools with all of the potential to make better products more quickly. And reading about them is like walking down the power tool aisle in a hardware store letting my imagination run wild about what I could build with this thing. Listening to their brilliant contributors talk through the why of their decisions is inspiring, making me want to build something brilliant too. about  you can be satisfied just to know about all the interesting and different ideas these super brilliant framework authors come up with every couple of days or so. You and your project may be much more suited to an entirely different approach. But I think if you’re starting to build a web application with Javascript in 2024, then these meta-frameworks are the best place to start.

I’d love to hear your thoughts! Please feel free to share any comments you have about the ever-expanding world of Javascript frameworks.