Issue #17: Wherever I May Roam
🎵 …I’ll take my time anywhere, free to speak my mind anywhere, never find anywhere… 🎵
There are multiple ways one can build web applications delivered to client browsers. Basically, this newsletter is dedicated to the ongoing research on options around that. Some approaches are new and some old; some more performant with the tradeoff of growing complexity and some, on contrary, sacrifice performance in favour of simplicity of development; some take good from both previous ways, and some just spoil everything spectacularly by poor performance and sophisticated code practices. There’s always a reason for this or that approach, and in modern web development with React as a UI library we see mentions of React Server Components (RSC) as the way to go more on more. Today we’ll try to figure out, if there’s any sense in that, what are the possible routes, worrying tradeoffs, and even what can we do as an alternative.
The Good
Starting with the latter, Eleventy team published the long-anticipated release v3.1.0.
11% faster and 22% smaller!
In addition to significant performance improvements and multiple bug fixes for Eleventy itself and its ecosystem, there are some new features (like the fancy import attributes) and improvements (like dev server empowerment with better Fetch support and easier proxy configuration) which may get you interested in trying it out (if you didn’t do it yet).
Possible exactly that was one of the reasons encouraged Jien Weng to switch from Astro to Eleventy. I mean, that says a lot, taking into account the Astro’s famous cool DX, lots of innovations around, and support for versatile set of accompanying tools.
Don’t get me wrong — Astro is fantastic. It’s sleek, modern, and its component-based approach makes building dynamic, beautiful sites a breeze. But for me, it started to feel like too much. I wanted something leaner, something that didn’t make me think too hard about build processes or framework intricacies.
To be honest, I can totally relate to that, as even with Astro’s simplicity, the amount of moving parts and necessity to update them constantly may get overwhelming at some point, especially for a simple thing like a personal website, but even more — maintaining a complex enterprise Astro code base is a big deal too.
But if you’re not ready for any departure away from Astro, Dan Abramov may get you interested in his in-depth comparison of Astro’s components and client islands with RSC, where the matching abstractions are called server components and client components.
The mental model behind these two are remarkably similar! If you know Astro, you already have 80% of the mental model for React Server Components.
This article is a very thoughtful overview of pros and cons of the both ways, as well as a very good and relevant RSC introduction for Astro developers.
You noticed how slick this segue to RSC was here? I bet Ryan Florence also realized that the recent updates to Remix (and thus React Router) were a good segue for following React Router empowerment with RSC. This feature has got to its public preview stage.
This is very exciting for us: both React’s and React Router’s full feature sets will soon be usable with very little effort with any bundler, any JavaScript runtime, and any server!
I like how dots get connected with this update and how many references there, both for React and its future specifically, and Vite (and wider) ecosystem in general, in addition to the multiple capabilities for using RSC (with or without frameworks) Dan emphasized in the article mentioned above.
Waku team, one of the RSC pioneers, proceed improving its way of RSC enablement with Waku’s adjacent features, like the fine-grained router components making its routing story almost as powerful as Next.js or TanStack Router with much lower complexity friction.
The Bad
In the context of this general RSC excitement, Nir Tamir calls us to slow down and think about some RSC cons and tradeoffs in his piece called “The Limits of RSC: A Practitioner’s Journey”.
[…] Real-world implementation exposes fundamental gaps in the model.
There are both some general thoughts on the technology and a bunch of example edge cases highlighting possible pitfalls of using RSC for everything without proper context considerations.
RSC represents an important advance in React development, but it works best as part of a hybrid approach rather than an all-encompassing solution. Use it where it shines, but be prepared to supplement it with client-side data management when complexity demands it.
The Noteworthy
If you get confused with all of that and start looking for a breath of fresh air away from React’s innovative but comparatively complex and contradictory abstractions, the Deno team got you covered with some news on their Fresh metaframework development state.
The Fresh v2.0 is nearing to see the light and the guys describe what you may expect with this release.
Fresh 2 is already powering deno.com and Deno Deploy in production, but we’re still putting the final touches on the plugin system, bundler integration, and overall developer experience.
The most valuable anticipated update is probably the Express/Hono-like APIs and custom middlewares making DX for developers acquainted with these ubiquitous tools convenient, predictable, and consistent. That, along with multiple underlying platform improvements, promise a good boost in Fresh adoption.
Fresh 2 makes the framework much more extensible, faster and easier to work with.
And if it’s gladly adopted by such clever guys like Adam Argyle, who mentioned recently that his awesome blog is powered by Deno and Fresh, you don’t have any reason stopping you from trying Fresh today.
But wherever you may roam, don’t forget that there’s no single correct way of doing web development so you won’t be blamed (by any adequate person) for using Astro, or PHP, or even Rust for your personal weblog about gardening or your next unicorn OpenAI-powered chat platform for tackling ball bearing problems for mechanical coffee makers.
👋