Posted by sangeeth96 12/11/2025
***
Seems that server functions are all the rage. We are unlikely to have them.
The main reason is that it ties the frontend and the backend together in undesirable ways.
It forces a js backend upon people (what if I want to use Go for instance).
The api is not client agnostic anymore. How to specify middleware is not clear.
Requires a bundler, so destroys isomorphism (isomorphic code requires no difference between the client and the server/ environment agnostic).
Even if it requires a bundler because it separates client and server implementation files, it blurs the data scoping (especially worrying for sensitive data) Do one thing and do it well: separate frontend and backend.
It might be something that is useful for people who only plan on having a javascript web frontend server separate from the API server that links to the backend service.
Besides, it is really not obvious to me how it becomes architecturally clearer. It would double the work in terms of security wrt authorization etc. This is at least not a generic pattern.
So I'd tend to go opposite to the trend and say no. Who knows, we might revisit it if anything changes in the future.
***
And boy, look at the future 3 weeks later...
To be fair, the one good thing is that they are hardening their implementation thanks to these discoveries. But still seems to me that this is wholly unnecessary and possibly will never be safe enough.
Anyway, not to toot my own horn, I know for a fact these things are difficult. Just found the timing funny. :)
It happened with Next.js as well https://github.com/vercel/next.js/discussions/11106
> Say Python ran in the browser natively, and you reimplented React on browser and server in Python. Same problem, not Javascript.
Yes.
And since Python does not natively run in the browser, that mistake never happens. With JavaScript, the desire to have "backend and frontend in a single codebase" requires active resistance.
It's the same vulnerabilities because Next uses the vulnerable parts of React.
Your rational is quite poor as I can write an isomorphic web app in C or Rust or Go and run parts in the browser, what then? Look, many of us also strongly dislike JavaScript but generally that distaste is based on its actual shortcomings and failures, you don't have to invent new ones plenty already exist.
If you have a single codebase for Go-based code running in an untrusted browser (the "toilet") and a trusted backend (the "kitchen"), then the same contamination is highly likely.
Did you even bother to read my comment? Try again, please. Next time don't skip over parts.
Indeed, but unlike Go/Python (backend) and TS/JS (frontend), the separation is surmountable, and the push to "reuse" is high.
Other than types and stuff like zod validators there's not a lot of overlap between server and client code.
I agree with your point that iso code can be confusing. But beyond that I think you're just pushing an irrational anti JS narrative.
Programming languages do lead to certain software architectures. These are independent but not orthogonal issues.
How about either just return html (maybe with htmx), or have a "now classic" SPA.
The frontend must be the most over engineered shitshow we as devs have ever created. Its where hype meets the metal.
I’m not interested in flame wars per se, but I can tell you there are better alternatives, and that the closer you stay towards targeting the browser itself the better, because browser APIs are at least an order of magnitude more secure and performant than equivalent JS operations.
It’s common for critical CVEs to uncover follow‑up vulnerabilities because researchers scrutinize adjacent code paths looking for variant exploit techniques to test whether the initial mitigation can be bypassed.