We're working on it :)

My job involves keeping a finger on the pulse of frontend web frameworks. I wrote a post about all I tracked in 2025.

Themes I saw: 1. So. Many. CVEs. 2. The Next.js team delivered! 3. Frameworks made changes for coding agents 4. RSCs entered a new phase 5. Signals won... almost 6. Rustification continues

Hey, I built something somewhat similar a couple months ago: https://triple-buzzer.netlify.app/.

TanStack Start has its own implementation of Server Functions: https://tanstack.com/start/latest/docs/framework/solid/guide.... It doesn't use React Server Functions, in part because it intends to be agnostic of the rendering framework (it currently supports React and Solid).

To be fair, they also haven't released (even experimental) RSC support yet, so maybe they lucked out on timing here.

Same for Netlify: https://www.netlify.com/changelog/2025-12-03-react-security-...

and Deno Deploy/Subhosting: https://deno.com/blog/react-server-functions-rce

> I really, really liked how Cargo did things (e.g. optional dependencies and rigid library structure) and it'd be incredible to have that for the JavaScript ecosystem.

FYI: https://thenewstack.io/vites-creator-on-a-unified-javascript...

I'm keeping my eye on Void0, yeah! If anyone can live up to such promises, it'll be them.

They'll have a tough job getting sticky ecosystems like React Native to adopt, but hope to see them make a compelling case for their stack.

You can use the Tailwind Prettier plugin to automate this: https://github.com/tailwindlabs/prettier-plugin-tailwindcss. I'm not sure if it would support the precise grouping and sorting you prefer, but it may be worth it anyway!

The ability to self-host on serverless compute is just a subset of the challenges. Even with your own VPS or ECS setup, I think it's legitimate to say a serious project requires server redundancy, and as soon as you have more than one running server it opens up requirements to synchronize cache state, which is a significant challenge. This has nothing to do with serverless architecture.

Ooh, interesting. We didn't know about this. Is this it? https://github.com/caching-tools/next-shared-cache/tree/cana...

yes, there is even the official example here https://github.com/vercel/next.js/tree/canary/examples/cache...

but it does not work because of NextJS 15.

I changed the example to point to latest NextJs 14 and fixed some cache-handler bugs it works fine, and I deploy it successfully with DollarDeploy to DO VPS https://github.com/huksley/next-cache-handler

This is a great point and definitely something we're mindful of. That sentence actually ended with "and share these with the community" in the draft, but we can't make promises on behalf of the Next.js team.

Our hope is that the OpenNext initiative's growth and connections with the Next.js team is just a first step toward shifting some Next.js governance out to the open. The article calls out that the OpenNext members are hoping to contribute to public RFCs in the future, with Next.js core team collaboration.