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
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.
> 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.
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.
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.