You know what the issue is? People are so focused on being able to scale their idea to billions of users before they even start building it. So someone today would start using Kubernetes for their website with 5 visitors. I've seen many students use Nextjs for websites that could easily be written with plain html + css, and some chart library.
The experience of developing a simple website using React is orders of magnitude better than using html and CSS. Reusable components, loops, and separating data from presentation go a long way even in the simplest of pages. Sure, you don't need React, you could use Jinja or any other templating library, but React is pretty good at what it does. As for Next.js, it makes it super easy to develop using React.
The biggest problem with React is the JS bloat that's sent to the browser. Though as long as you do server side rendering and don't even ship the JS to the FE, Next.js is a pretty good static site generator.
> The biggest problem with React is the JS bloat that's sent to the browser.
There's a web app I use (ClickUp) where I have to watch UI elements load one-by-one, like I'm back on dial-up or something. I'm convinced they end up with more CPU load just doing all the TLS handshakes than they would if they just sent me all the HTML in one go.
> The experience of developing a simple website using React is orders of magnitude better than using html and CSS.
Isn't this rather circular? It's only this way if you already know React well enough to be fluent. Learning React and all it's conceptual baggage is a huge jump from understanding html/css/basic js plus the HTTP request/response cycle (all things which you'll need to understand even if you do use React)
Honestly - this sounds a little like Stockholm Syndrome. I've spent a long time actively avoiding React and nothing I've read or seen has led me to think that was a poor decision. Quite the opposite - I feel progressively more vindicated with every passing year.
There is CAPRI (https://capri.build/docs/why/) which allows using both interactive (they call them "islands") and non-interactive Vue/React/Svelte components to build your static website. So I can still split the website into reusable Vue components and if the components are not interactive - I can end up with no JavaScript at all. CAPRI also supports getting your content from several headless CMS (Storyblok, TinaCMS, Sanity, Contentlayer) so once you build the layout content can be easily added or changed.
>The experience of developing a simple website using React is orders of magnitude better than using html and CSS.
OK well I've done both and I have to say no it's not, but probably my definition of simple is simpler than yours. It also seems to me that the original comment used a simpler than yours model of simplicity.
>Next.js is a pretty good static site generator.
my experience is that Next.js is a lousy static site generator, but reasonable if you want to use React.
This. It is way faster to build a decent looking prototype using JavaScript Framework Bloat than shipping something leaner. Performance and maintainability are luxuries that make sense to focus on later. This is in no way analogous to using k8s from the get go, which is a technology focused on being flexible and generic enough to maximize choice, rather than speed or developer experience.
Yes, yes, I you want to make a plain HTML form its fast enough, but for a startup 99% of customers want to feel assured by it having a look and feel which simply takes too much time if you are building things up without a framework
A couple of years ago, somebody tweeted something along the lines of "did you know you can POST an html form without using javascript?". The replies were incredible, because they revealed how many folks could write a full blown React app to post a form, but didn't know how to do it with just <form>.
I agree: it's terrible that kids would go straight to React without trying plain html + js first, but they do this because they often don't know any other way of doing it.
It doesn’t matter if you have five visitors or 5 million you presumably want your website to stay online so you need something that restarts the processes when they die, etc. Honestly building and publishing a docker image is super simple. There are numerous hosted kubernetes solutions to deploy it to as well. I don’t think that using next JS or using Kubernetes means you are inherently over complicating anything, and this is coming from someone who prefers minimal technology (I personally don’t use next JS, but I see the value in it for others)
Publishing a Docker image is simple. Managing a Kubernetes cluster, even hosted, may be much more complex, for no added benefit.
Throw your container on a VM, make systemd or even runit keep it running. It scales fine to half dozen boxes if needed. Same for your Postgres DB. For extra fancy points, keep a hot standby / read replica, and pick up any of the manual switch-over scripts.
Should keep you running until dozen million DAU, with half-day spent on the initial setup.
> I've seen many students use Nextjs for websites that could easily be written with plain html + css, and some chart library.
Maybe the students want to learn a popular framework in order to have job? That is exactly the reason I learned Nextjs and lo and behold, it proved to be useful for me and my employer..
I used to think that but I've changed my option in the last couple of years. I think be bar for a bare bones app is starting to get so high you can no longer afford not to think of it as an entire platform from day one. I think AI will make this bar even higher.
The other thing is apps mostly work now. Even 10 years ago people (including devs) would tolerate a flaky application. Now days everyone expects five-nine uptime and zero data loss and seamless cross platform functionality.
If you start off with some "toy" version you fool yourself into thing this idea is not as hard as it sounds. Then once you hit the wall of production reality you start to realize just how hard something is going to be in production and that's why the market is still open for your idea. Its why there are so many profiles on github with tens or hundreds of abandoned projects.
There's probably a lot of greybeards out there that will say all you need on a computer is a terminal and emacs. They might be right but you cannot scale/sell it and everything in-between is just a compromise.
> I've seen many students use Nextjs for websites that could easily be written with plain html + css, and some chart library.
Students are the one case in which I'd say this is good.
The vast majority of the stuff students do is not going to be successful. The purpose here is not to build stuff, it's to learn how to build stuff, and in that case exploring technologies is a net win.
The chart library is presumably JavaScript.. so what's the fundamental difference? Next can just spit out html/CSS/js that you can host on GitHub pages or S3. But they get familiar with a popular full stack framework I honestly don't see what's that controversial with the scenario.
I've built my latest project[1] with Next.js and it's often felt pretty hectic to use.
App vs. pages router, accessing cookies requiring different APIs between the client-side and the server side, env vars being accessed via `process.env.NEXT_PUBLIC_*` which gets rewritten into literal value of the env var (so if you access `process.env` directly you're very confused).
I guess I was hoping that I'd be able to write code which would work on either the client-side or the server-side with minimal changes. But that's not what I experienced. For what Next.js does provide, it doesn't feel worth the overhead and the learning required to do it "the Next.js way".
This is so true! Our codebase got radically simpler when we did the exact same thing. And faster too, in terms of page rendering. It is very unfortunate that the whole community is being pushed onto frameworks like this unnecessarily.
(And I love that the post authors are using rspack! I read the post after posting this comment. This was our exact same process. No more overhead of next -- just used rspack/rsbuilld and a simple router and beautiful simplicity everywhere, including 10ms hot reloads)
Am I the only one having a great time here? I've been using Next.js since the v14 launched and it's been great! Using RSCs, I have large portions of my app that just work even with client-side js turned off.
It's like having all the simple power of a PHP app except with a nice type system and the ability to seamlessly include interactive, stateful client components at the "leaf level" of my view tree.
I had one project that used Next. It was one of the most painful things I’ve used in my 25 year career. And if you’re on Linux, it’s dog slow when developing. Never again.
I'm grateful for rails and hotwire. completely enabled me to escape the madness that is the react ecosystem.
if it's not a state management library, it's a meta framework, if it's not a metaframework, it's a data fetching library. so many choices to do one simple thing put data coming from the server on a page.
then why do people need it to make complicated as if you're hatching dragon eggs with alchemy ?
React for me has several large advantages (no specific order):
1. declarative dom updates is way easier than imperative
2. frontend components
Additionally typescript needs a compile step anyways so it's not super complicated to just add react to it.
I think many people bounced off React 5 years ago when in 2025 React apps are easy to get started with (basically no config), have negligible hot reload + build times, and largely have become a joy to use.
The Next.js team keeps hiding the usefulness of React Server Component for the ease of development and Vercel deployment. It's a gatekeeper at its best.
Why not exposing an API for RSC so that i can imperatively fetch a RSC page with normal fetch call ? Why hiding such a killer feature so that you don't need HTMX anymore.
Also, why conventionally forcing the "RSC page" can't access the Request object in lue of caching. Instead of flexibility of a framework, you force things which users don't prioritize.
Ah, one last point, file system routing without anyway to opt-out is a red flag of the architecture as well.
> You intentionally cannot access the raw request object. However, you can access headers and cookies through server-only functions. You can also set cookies.
> Layouts do not rerender. They can be cached and reused to avoid unnecessary computation when navigating between pages. By restricting layouts from accessing the raw request, Next.js can prevent the execution of potentially slow or expensive user code within the layout, which could negatively impact performance.
I don't like this limiting "I know best what's good for you" attitude in my tooling.
Yes limits are desirable to avoid footguns but this seems like too dumbed down of a restriction for little gain.
You can opt out by using a single (optional) catchall route and handle the path all by yourself. This is sometimes necessary to handle CMS pages for example.
We use nextjs because we want to optimize the page for SEO and crawlability. If you don’t need your page to be crawlable (eg a dashboard behind a login), then there’s a good chance you don’t need nextjs, and pure React will indeed be simpler.
Given how much front end has evolved over the last 15 years, is it really the case still these days that you should do SSR for SEO? That would be a strong indictment of Google and other search engines if they still so many years later are not properly crawling JS based websites wouldn't it?
Google does crawl client side generated content but at a low priority and with mixed results. It's expensive and slow to render js pages so I see where they are coming from.
Unfortunately, yes. While Google and many other search engines/crawlers can render JS it’s much faster to give them the rendered page - especially for very large sites.
But page load optimization does typically bring better user engagement so it’s not just an SEO strategy.
Readit News
The biggest problem with React is the JS bloat that's sent to the browser. Though as long as you do server side rendering and don't even ship the JS to the FE, Next.js is a pretty good static site generator.
There's a web app I use (ClickUp) where I have to watch UI elements load one-by-one, like I'm back on dial-up or something. I'm convinced they end up with more CPU load just doing all the TLS handshakes than they would if they just sent me all the HTML in one go.
Isn't this rather circular? It's only this way if you already know React well enough to be fluent. Learning React and all it's conceptual baggage is a huge jump from understanding html/css/basic js plus the HTTP request/response cycle (all things which you'll need to understand even if you do use React)
Honestly - this sounds a little like Stockholm Syndrome. I've spent a long time actively avoiding React and nothing I've read or seen has led me to think that was a poor decision. Quite the opposite - I feel progressively more vindicated with every passing year.
> The biggest problem with React is the JS bloat that's sent to the browser
What does React bring then? It is slow, overengineered and bloated. It is also the only thing many developers know. Just like PHP 20 years ago.
OK well I've done both and I have to say no it's not, but probably my definition of simple is simpler than yours. It also seems to me that the original comment used a simpler than yours model of simplicity.
>Next.js is a pretty good static site generator.
my experience is that Next.js is a lousy static site generator, but reasonable if you want to use React.
Yes, yes, I you want to make a plain HTML form its fast enough, but for a startup 99% of customers want to feel assured by it having a look and feel which simply takes too much time if you are building things up without a framework
A couple of years ago, somebody tweeted something along the lines of "did you know you can POST an html form without using javascript?". The replies were incredible, because they revealed how many folks could write a full blown React app to post a form, but didn't know how to do it with just <form>.
I agree: it's terrible that kids would go straight to React without trying plain html + js first, but they do this because they often don't know any other way of doing it.
Throw your container on a VM, make systemd or even runit keep it running. It scales fine to half dozen boxes if needed. Same for your Postgres DB. For extra fancy points, keep a hot standby / read replica, and pick up any of the manual switch-over scripts.
Should keep you running until dozen million DAU, with half-day spent on the initial setup.
You build an artifact in CI, you spend a few minutes writing your deployment yaml, and then you deploy it. There's no more work after that.
What is so freaking hard about kubernetes? Why is everyone losing their minds over it? It isn't rocket science and it doesn't take a lot of time.
The nightmare is maintaining flaky snowflake bare metal machines.
Maybe the students want to learn a popular framework in order to have job? That is exactly the reason I learned Nextjs and lo and behold, it proved to be useful for me and my employer..
The other thing is apps mostly work now. Even 10 years ago people (including devs) would tolerate a flaky application. Now days everyone expects five-nine uptime and zero data loss and seamless cross platform functionality.
If you start off with some "toy" version you fool yourself into thing this idea is not as hard as it sounds. Then once you hit the wall of production reality you start to realize just how hard something is going to be in production and that's why the market is still open for your idea. Its why there are so many profiles on github with tens or hundreds of abandoned projects.
There's probably a lot of greybeards out there that will say all you need on a computer is a terminal and emacs. They might be right but you cannot scale/sell it and everything in-between is just a compromise.
Students are the one case in which I'd say this is good.
The vast majority of the stuff students do is not going to be successful. The purpose here is not to build stuff, it's to learn how to build stuff, and in that case exploring technologies is a net win.
Deleted Comment
App vs. pages router, accessing cookies requiring different APIs between the client-side and the server side, env vars being accessed via `process.env.NEXT_PUBLIC_*` which gets rewritten into literal value of the env var (so if you access `process.env` directly you're very confused).
I guess I was hoping that I'd be able to write code which would work on either the client-side or the server-side with minimal changes. But that's not what I experienced. For what Next.js does provide, it doesn't feel worth the overhead and the learning required to do it "the Next.js way".
1 - https://onlyhumanhub.com
Use pages and remember that env var patten and you're good.
All most folks need is `npx rsbuild init`:
https://rsbuild.dev/
(And I love that the post authors are using rspack! I read the post after posting this comment. This was our exact same process. No more overhead of next -- just used rspack/rsbuilld and a simple router and beautiful simplicity everywhere, including 10ms hot reloads)
It's like having all the simple power of a PHP app except with a nice type system and the ability to seamlessly include interactive, stateful client components at the "leaf level" of my view tree.
if it's not a state management library, it's a meta framework, if it's not a metaframework, it's a data fetching library. so many choices to do one simple thing put data coming from the server on a page.
then why do people need it to make complicated as if you're hatching dragon eggs with alchemy ?
Additionally typescript needs a compile step anyways so it's not super complicated to just add react to it.
I think many people bounced off React 5 years ago when in 2025 React apps are easy to get started with (basically no config), have negligible hot reload + build times, and largely have become a joy to use.
I (and the post and many comments here) think many people are bouncing off React now, because of NextJS and Vercel.
Why not exposing an API for RSC so that i can imperatively fetch a RSC page with normal fetch call ? Why hiding such a killer feature so that you don't need HTMX anymore.
Also, why conventionally forcing the "RSC page" can't access the Request object in lue of caching. Instead of flexibility of a framework, you force things which users don't prioritize.
Ah, one last point, file system routing without anyway to opt-out is a red flag of the architecture as well.
If filesystem routing isn't something you enjoy, Next.js probably isn't the right tool for you.
> Layouts do not rerender. They can be cached and reused to avoid unnecessary computation when navigating between pages. By restricting layouts from accessing the raw request, Next.js can prevent the execution of potentially slow or expensive user code within the layout, which could negatively impact performance.
I don't like this limiting "I know best what's good for you" attitude in my tooling.
Yes limits are desirable to avoid footguns but this seems like too dumbed down of a restriction for little gain.
Docs: https://nextjs.org/docs/app/building-your-application/routin...
https://www.npmjs.com/package/routerino
But page load optimization does typically bring better user engagement so it’s not just an SEO strategy.