Issue #37: Light My Fire
These days, when we’re lighting up our chimneys waiting for the year’s best family party, a lot of things are happening in the JS tooling world we humbly monitor under this project’s umbrella. The thing is, it always comes up to “the good”, “the bad”, and “the noteworthy” parts in a stable way so it always sounds like some kind of bittersweet cacophony symphony because of that. But with each time there’s something that gives a Hope — the hope that we’ll get there some day, that we’ll learn how to fight back the negative and savor the positive properly. What will light our soul (and keyboard) fires the nearest time? Let’s figure out, choose, and prepare.
The Good
In the article prophetically titled “The Browser Has Everything You Need”, GraphQL and TypeScript guru Jovi De Croock reasons about the eternal web-development war between initial website loads and following website navigation experience, that is between SPA and SSR, that is the thing metaframeworks set as something eventually solved here.
…Here’s the thing, the browser has had solutions for these problems all along.
I think that is something all of us — frameworks and metaframeworks fans, vanilla-JS zealots, or even someone in the middle — need to hear more often. Something that metaframeworks vendors try to juggle skillfully (dropping more and more complexity to this safety-oil-leaking fan), something that many simple old e-commerce website developers could teach everyone big time, and something we often forget about hiding behind thought leadership of loud Twitter/X influencers.
…We keep building increasingly complex frameworks to solve what is fundamentally a resource loading problem, we server-render, then client-render, then partially hydrate, then stream render…
There are some neat tips, tricks, insights, and parallels worth checking out in this writeup, that’s why I love it so much.
Whether you’re using Next.js, Remix, SvelteKit, or rolling your own SSR you can benefit from preload hints.
The Bad
React2Shell has become a big name in the close circles of React and Next.js users lately — similar to the notorious Shai Hulud (whose consequences are still retrospected deeply). It is the name given by security researchers to a critical, maximum-severity (CVSS 10.0) remote code execution (RCE) vulnerability in React Server Components (RSCs) we already discussed in the previous issue. Now its circumstances scale and escalate widely to something even more complex and dangerous (to the extent even Angular developers started to check their package-lock.json files for bad signals, and those who didn’t update from React 18 yet offer thanksgiving sacrifices to all their gods). This vulnerability and threat are still ongoing, and I like how seriously the industry discusses it and responds to it. One of the cool examples is this writeup from the Netlify security team.
React2Shell was a major framework-level vulnerability that deserves the tech media attention given to its coverage, and has many parallels to the massive Log4j / Log4Shell vulnerability disclosed almost exactly four years ago.
The solidarity and common industry response is especially important as not all the “native” safety measures from platforms and providers work like a Swiss clock. The fact that this attack happened almost exactly on the 30th anniversary of JavaScript (whose date is arguable though) which is, basically, considered the unlucky culprit of it all. Interestingly, maybe that is one of the reasons the JS ecosystem gradually starts to gravitate more and more to the side technologies like Rust.
The Noteworthy
If you’re not persuaded by React2Shell consequences, one other reason to update your Next.js app is the new shiny version 16.1.0 which brings not only the safety, but also some awesome DX improvements from Turbopack and other platform developments.
React Router (do not confuse it with the new Remix) was also updated recently, and version 7.11.0 also improves DX for the fans of its framework mode (ex-Remix).
Analog delivered a new version 2.2.0 (happily exhaling from not being a React/RSC framework these days) with lots of improvements for Nx monorepo tools users (historical love story, I guess) and support for the latest and greatest from Vite ecosystem.
Hono released version 4.11.0 with improvements for Hono client and middleware. And even if not using it as a metaframework tool (which is totally possible), people share their love to its simple and straightforward capabilities taking it for a spin to challenge the limits in pretty rough battles.
There are more and more rumors about the coming 6th version of Astro, threatening developers with lots of breaking changes, but I’m pretty sure the team won’t let their users suffer and will provide awesome migration utilities and guides, as usual, so no sweat and looking forward to it.
Last but not least, Cloudflare came up with experimental support for automated deployments for web apps based on almost all existing metaframeworks. Interestingly enough, I haven’t found the most Cloudflare-oriented framework in this list — but maybe it’s because it doesn’t even need this support being all square and good.
With all this fire in our hands, there’s solid hope that innovation won’t stop in 2026 and we’ll see a lot of new cool stuff — arguably, not too complex; hopefully, much more safe; and definitely, fun and motivating to build new cool stuff for the web. I wish you all a Merry Christmas and the Happy New Year, and look forward to seeing you digging through the Metaframeworks Records shelves in 2026.
🎄