31–40 of 220 posts
I hate how productive with this framework I am. I try to move on and can’t. I’ll take a security hit to use it lover leptos.
Is it the rest of the deploy infra? The vanilla app you can push to Heroku or any of its clones.
I hope Next's downfall sends a signal to the quality lib maintainers and changes direction (e.g. Remix and a f'd up router, TanStack w/ Start).
SSR frameworks make me vomit.
We opted for self-hosted next.js as the architecture for the web app we are building because we believed a lot of the hype. The more comments I read about it in HN, the less comfortable I feel about this decision.
HN has a very weird mind-set when it comes to JS frameworks. Next.JS is more than fine for 99% of web apps, and the fit only gets better the bigger your web app/platform. In general it's probably the framework that will give you the most bang for your buck.
I found a different article that goes into more detail: https://zeropath.com/blog/nextjs-middleware-cve-2025-29927-a... This looks trivially easy to bypass. More generally, the entire concept of using middleware which communicates using the same mechanism that is also used for untrusted user input seems pretty wild to me. It divorces the place you need to write code for user request validation (as soon as the user re…
That's basically the same way phone phreaking worked back in the day. Time is a flat circle.
We opted for self-hosted next.js as the architecture for the web app we are building because we believed a lot of the hype. The more comments I read about it in HN, the less comfortable I feel about this decision.
We opted for self-hosted next.js as the architecture for the web app we are building because we believed a lot of the hype. The more comments I read about it in HN, the less comfortable I feel about this decision.
HN has a very weird mind-set when it comes to JS frameworks. Next.JS is more than fine for 99% of web apps, and the fit only gets better the bigger your web app/platform. In general it's probably the framework that will give you the most bang for your buck.
Next.js is a bad choice for a lot of apps, javascript is slow at a lot of things.
Next.js would be a terrible choice for any app that has any non-trivial compute, for example.
VC influence in the web space has been a fascinating thing. I hope Next's downfall sends a signal to the quality lib maintainers and changes direction (e.g. Remix and a f'd up router, TanStack w/ Start). SSR frameworks make me vomit.
VC influence in the web space has been a fascinating thing. I hope Next's downfall sends a signal to the quality lib maintainers and changes direction (e.g. Remix and a f'd up router, TanStack w/ Start). SSR frameworks make me vomit.
SSR is fine. We used to call it "PHP" or "Ruby" or "Java." People need to stop reinventing things, but feature development outweighs maturity when you have funding.
Why?
The security posture for the code running in the browser is very different from the code running on a trusted backend.
A separation of concerns allows one to have two codebases, one frontend (untrustworthy but limited access) and one backend (trustworthy but a lot of access).
Earlier quoted context omitted.
HN has a very weird mind-set when it comes to JS frameworks. Next.JS is more than fine for 99% of web apps, and the fit only gets better the bigger your web app/platform. In general it's probably the framework that will give you the most bang for your buck.
That's a bold claim, that's easy to refute. Next.js is a bad choice for a lot of apps, javascript is slow at a lot of things. Next.js would be a terrible choice for any app that has any non-trivial compute, for example.
If you're going to try to be pedantic, do it right?
>Next.js would be a terrible choice for any app that has any non-trivial compute
Most web apps only need trivial compute. If you're including back-office, source systems in the word "web app" well that's your sticking point, not mine.