Issue #5: Run This Town
🎶 Life’s a game, but it’s not fair. I break the rules, so I don’t care. 🎶
In this issue, we’ll explore some important topics related to JavaScript runtimes and ways to handle server-side code in metaframeworks. With not much bad news this week, we’ll also take a look at how different tools and libraries are breaking speed barriers with their streamlined developments. And as usual, we’ll check out some interesting and useful experiments and findings the web has brought to metaframework application developers.
The Good
Marvin Hagemeister wrote a piece dedicated to the modern way to write JavaScript servers. This is very important for metaframework enthusiasts, as the topic of the Fetch API and Request/Response API specifically, being the standard for the web, is often overlooked and hidden compared to popular JS server implementations. However, as we can see from this article, it’s one of the most performant ways, and many metaframeworks use it for their server parts. I’ve updated my metaframeworks comparison with a new specific option for the Fetch API, and you can see why it’s such a big deal now.
Server functions, often using this API, became the topic of research by Brenley Dueck. In the article titled “Why Server Functions Matter In A Server Component World” and its continuation “Server Function Benefits”, the author dives into how different metaframeworks approach them. The TanStack Start approach differs with its client-first approach, which I’ve mentioned before. The author considers the pros and cons of different approaches in great detail, providing a very interesting and important perspective when choosing your tools.
Bun and Deno, being popular platforms for running all these server-side stories lately, have become real production-ready contenders to Node with each release. They made giant leaps last year, and their teams wrote about it almost on the same day. Bun’s blog post is dedicated to their latest release, version 1.2, bringing significant improvements for us metaframework folks, such as Postgres and SQLite support, using bun as a package manager (even for Node!), as a test runner, and as a bundler. It looks like very soon you won’t need much to build your own metaframework except for bun, the aforementioned Fetch API, and some free time. And that’s what the guys from Brisa, for instance, have already started to do.
The Deno team, in turn, wrote about their 2024: improvements for Node and CommonJS compatibility (I know some of you can feel the pain), deno’s standard library, the introduction of JSR, enhancements to binary compilation (threatening to support compiling full-stack frameworks in the future!), and much more, including progress on deno’s own metaframework, Fresh, which is gradually evolving to its v2. I mentioned on Bluesky the nostalgic look back to 2020 and the impressive distance Deno has covered in these years, even though it’s just a single major version step forward. And for those who need more meaningful deliverables to be persuaded, check out this extremely deep and serious video guide—you won’t regret it.
Breaking Bad
With such a vast landscape of innovations, tooling providers couldn’t stand idle and not contribute something of their own.
Vitest, which is no longer just the unit testing framework it was quite some time ago but already a kind of platform for other tools to build upon, has crossed the line of its 3rd major version. Being built on Vite, the technology powering most metaframeworks these days, Vitest is a go-to solution for full-stack application testing. I’d bet on anything Anthony Fu builds, and he’s got a lot of cool ideas, like the recent Epoch Semantic Versioning concept, which sparked some curious discussions. Even if it’s a bit complicated compared to the classic SemVer approach, it would probably be a good way for some library authors to find common ground to prevent destructive effects of breaking changes for consuming projects.
Another initiative aimed at finding common ground and providing a solid standard for web development tooling is the new effort from the creators of Zod, Valibot, and ArkType, popular TypeScript validation libraries, to create a widely shared interface for this kind of tool. Schema validation libraries are an important building block of all full-stack JavaScript/TypeScript applications, allowing for the safe sharing of business logic between frontends and backends. A whole lot of libraries already support the new spec, and it’s an important step in providing convenient interoperability for the corresponding part of the ecosystem. Now we just need the same for runtimes and everything else, but as we’ve seen, many of them are already moving in the same direction.
And speaking of moving, probably no other project runs as fast as Astro. Sometimes when I read their monthly achievements lists, I feel so miserable and minuscule. But then I check the new release (like the latest 5.2) and feel empowered to follow the lead and build great things too. Some people claim this pace is crazy, but it works and brings innovations and fresh air to the ecosystem. And since migration is as easy as running a single CLI command each time, it costs nothing. That’s why Metaframeworks Weekly is on Astro 5.2 already, and you probably should do the same for your next big Astro project. Or update your app’s SvelteKit version… Or Next.js… You name it!
The Noteworthy
And while you’re trying to choose and find the best one for you, I’ve got another helpful resource: the overview of JavaScript frameworks news in 2024 from Netlify’s own Philippe Serhal. Not surprisingly, as 2024 was largely the year of metaframeworks, this retrospective is mostly dedicated to them too. It covers a lot of ground, including some stuff we just discussed here, like server functions and Astro’s dominance in innovation. It’s a spot-on research piece on recent trends, another addition to the awesome collection.
But you know what yearly-curated collection is even more awesome? Of course, it’s the collection of pens from the Codepen community. It’s such a cool compilation of artistic coding experiments for your UIs that each year it draws me away from everything I do for at least a day. From funny ideas to new patterns and POCs by the best authors and HTML/CSS/JS wizards in the industry. So while your slow npm runs the update command for Astro 5.2, you can choose a new shiny component for the corresponding landing page, and the only thing left will be to validate its data exchange with your server function following the new standard… You know the drill now.
All in all, this crazy pace of innovation in everything around, from controlling UI scrolling behavior to deploying your server in the most performant way, leaves me with a very positive attitude. And the hope that the exchange of ideas and mutual innovation proliferation will benefit us, developers, the most in the end.
👋