Issue #2: Harder, Better, Faster, Stronger

🎶 Work it harder, make it better, do it faster, makes us stronger. 🎶

I have a very cool selection of developer wisdom for you this week. Everything here fits perfectly into a single common theme: investigating the current state of metaframeworks, diving deeper into the ecosystem, testing specific examples, and considering alternatives.

That’s why I’ve decided to step away from the structure of previous issues (YOLO!) and make this one a bit more custom. You’ll get the idea as we go. All the quotes belong to their respective awesome authors.

Declaring Complexities

Ryan Carniato, one of the metaframework heroes, wrote a piece titled “JavaScript Frameworks - Heading into 2025”. As usual, his opinions are thoughtful and, well, opinionated. An important idea there is that with all the approaches, benchmarking, star-counting, and build-speed optimizations, sometimes the popularity of a framework and its place in the ecosystem depend on something bigger.

Both Vue and Angular are frameworks I’d have my eye on this next year. Not because I expect to be blown away by some innovation here, but because these tools go the extra mile in making developers happy. Sometimes the best tool isn’t the “best” tool.

We developers often forget that our tools are just tools, and in the hands of a motivated person, any framework can shine and bring satisfaction worthy of the first rows of the “State of JS.”

We live in a world full of complexity, and that doesn’t appear to be changing any time soon. So 2025 feels like a good time to hunker down and get stuff done.

Selecting Your Own Complexity

Andrew Webb explores “Shopping for a JavaScript Meta-Framework”. It’s a very decent overview for folks who aren’t well-versed in the world of modern metaframeworks, and the shopping metaphor is particularly fitting, if you ask me. One thing that resonates with me especially is the magnetism of the metaframeworks discourse (one of the actual reasons for this newsletter in the first place) as a kind of equilibrium between innovation and the desire to establish patterns that alleviate the pains of modern full-stack development.

[…] meta-frameworks are like brand-new power tools with all 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.

Looking from the Outside

Tyler Smith offers his invaluable perspective on the modern JS metaframework (Astro, in this case) from the experience of a seasoned full-stack PHP/Go/Ruby developer. As the ecosystems are quite different, the experience of migrating WordPress, Go, Rails, and Hugo websites to Astro sparks curiosity: it highlights what looks better in comparison and what might be confusing.

One concern that resonated with me is the cadence of updates in modern metaframeworks, at least some of them. This raises some worries about production-readiness and stability, as well as the necessity for active, regular maintenance work.

Despite my strong distaste for file-based routing, my biggest concern with adopting Astro is the potential for breaking changes that would force me to rebuild my sites. JavaScript tools are much more aggressive with breaking changes than tools you find in other language ecosystems.

Diving Deeper into One Thing

Another metaframework hero, Lee Robinson, came up with a piece on one of the latest experimental Next.js features—Composable Caching. This is one of the exact examples of my previous point about the excitement related to new innovations brought by the necessity to solve problems created by previous innovations. Caching implementations have a long history of pain for Next.js, and this time we can see a great and consistent improvement for all the framework fans.

If you’re thinking “that feels like the same model of server and client composition”—you’re absolutely right. This is sometimes called the “donut” pattern:

• The outer part of the donut is a server component that handles data fetching or heavy logic.
• The hole in the middle is a child component that might have some interactivity.

Considering Alternative Ways

React guru and big TanStack fan Adam Rackis conducted a great exploration of modern metaframework problems in general, and the new way of dealing with some of them brought by TanStack Start—one of the newest and coolest kids on the metaframeworks block. This is both a detailed theoretical introduction to the pains of modern web technology and a hands-on experience of how TanStack Start uses isomorphic loaders to address the problem of user-facing performance.

The root problem is that these meta-frameworks inevitably have server-only code running on each path, integrating with long-running client-side state. This leads to conflicts and inefficiencies which need to be managed. […] Let’s be clear right away: if this situation is killing the performance of your site, you have bigger problems. If these extra calls are putting undue strain on your services, you have bigger problems. […] But I’m here to show you some new, better tooling that side-steps these issues altogether.

So, it looks like TanStack Start offers another promising alternative to habitual metaframework patterns, which, who knows, might find its honored place in our repositories very soon.

Minding a Wider Perspective

This issue got a bit bigger and more complex in comparison. (Which is pretty on-point, isn’t it?) Metaframeworks have their obvious CONs, and one should keep them in mind. But with that said, for some of us, they’re the best sets of patterns and tools to develop awesome apps in minimal time and with minimal headache. They represent a balance between innovation and practicality, offering a way to navigate the ever-growing complexity of modern web development. While they may not be perfect, they provide a foundation that allows us to focus on what truly matters: building great experiences for users. So, as we move forward, let’s embrace the tools that empower us, while staying mindful of their limitations and the broader context in which we use them.

👋