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.
tasn 17 days ago [-]
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.
cjs_ac 17 days ago [-]
> 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.
moltar 17 days ago [-]
ClickUp runs on Angular though.
tasn 16 days ago [-]
I explicitly said server side rendering for this reason.
tmcdos 16 days ago [-]
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.
andybak 16 days ago [-]
> 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.
Alifatisk 17 days ago [-]
I miss the old LAMP stack, good times
Carrok 17 days ago [-]
The LAMP stack is still here, waiting for you.
bryanrasmussen 17 days ago [-]
>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.
tasn 16 days ago [-]
I explained why in the rest of the comment. Reusable components, code generation, etc. are a godsend. Copy pasting sections across and within pages, and not being able to generate code is hell.
Simple is better, but bare doesn't necessarily mean simpler.
averageRoyalty 13 days ago [-]
We're talking about "simple website". You can use any number of LLMs to generate you a boilerplate or use something simple and lightweight like Bootstrap. For a simple website, the things you're talking about add time and effort, not remove them - especially for someone who knows how to do neither.
paddw 17 days ago [-]
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
WhyNotHugo 17 days ago [-]
The issue is a bit deeper than this.
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.
joshribakoff 17 days ago [-]
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)
pjs_ 17 days ago [-]
Why is a process that is just serving static HTML regularly dying? NGINX, Apache etc will run for years unattended, they are designed to do this
doctorpangloss 17 days ago [-]
If that were true, why do people keep designing and deploying orchestrators? In your opinion, because they’re stupid?
Alifatisk 17 days ago [-]
Because devops and their service are way more dynamic than a simple static html file
nine_k 17 days ago [-]
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.
echelon 17 days ago [-]
Can someone explain what is so hard about kubernetes?
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.
stackskipton 17 days ago [-]
SRE here. First off, updating control plane/kubelet is nightmare in itself but let's assume you are running managed Kubernetes somewhere so that's taken care of.
Kubernetes out of the box is not ready to go. What Ingress are you going to use? Ingress-Nginx. Cool cool, How is that getting deployed? Helm Chart. How do we keep track of that being kept up to date and who deployed it? ArgoCD. So who is going to teach all CRDs for Argo and how they work with each other? SREs. You understand we dislike the devs and last thing we want to do is hold classes they don't want to learn? JUST BUILD A PLATFORM. And here we go.
So out of box, most people deploy Kubernetes + 8 "plugins" and it's Frankenstein monster that's you have to manage or it will decide to kill all the workloads one day.
EDIT: I'm didn't even discuss certificates for that ingress or all monitoring/logging this cluster will need to make sure it's properly operating.
doctorpangloss 17 days ago [-]
It has a terrible first time user experience. Once you accept that developer experience means user experience for 19/20 programmers, it’s imperfect. For example even though programming is all about reading, the average programmer looks more like the average person than it ever was, and the average person hates reading. So Kubernetes bad. IMO this is why so much success has been found building SaaS on top of Kubernetes.
alerighi 17 days ago [-]
Because you have to have and manage a Kubernetes cluster, that is not something easy. Moreover scaling is not always automatic, you don't tell Kubernetes "scale this application" and it works, if the application is a monolith. You have to write it using a microservices architecture, something much more difficult.
Also, managing a CI pipeline isn't something very easy to start with, there are entire teams in companies that only do that.
In contrast running a simple server is much more simple, you install a Linux OS (probably Ubuntu server, or Debian), install a web stack (for example Apache, PHP, Mysql or Postgres these days), copy the files of your website in the root directory (/var/www), or if you are fancy pull a git repository on the server so you can update it with a simple "git pull", if you need more websites on the same machine configure virtualhosts (or use one of the many software that have a GUI to configure virtualhosts).
The second solution is much more simple, in fact is the most used solution as far as I see. Most websites doesn't need high availability, if the website of the bike repair shop that I have 100 meters down the street goes offline for a couple of minutes or even one day because I'm doing maintenance on the server really nobody notices it.
dartos 17 days ago [-]
It’s not necessarily that it’s hard, but to be effective with kubernetes you need to understand a lot of infrastructure concepts like DNS, load balancing strategies, docker, storage drivers, service discovery, what exactly a pod is, what exactly a container is, etc.
It’s a lot of up front knowledge needed for marginal benefit at small to mid scales.
There’s a lot of steps if the “write your deployment yaml” step.
merb 17 days ago [-]
If you are small or mid scale and you need lots of compute between 8
5 to 8 on Monday till Friday it basically the best thing you can you to schedule your workload.
If you need some things like load balancing and zero downtime deploys etc you probably will build your own k8s which is often worse
dartos 16 days ago [-]
Or you can deploy on app engine, lambda, firebase, etc.
Kubernetes is not the only game in town.
Sometimes shipping asap is more important.
As with just about anything in tech, it’s about tradeoffs.
I may be biased, since I worked in devops before k8s came out, but building a decently scalable system architecture with load balancing and rolling deployments is pretty straightforward with monolithic systems. Especially since service discovery isn’t really a concern. Horizontal scaling works well in many many cases.
Realistically any app simple enough to be deployed by hand with a few docker containers will not be difficult to convert to k8s anyway.
echelon 17 days ago [-]
You're doing the moral equivalent of that when you're setting up on bare metal.
PuppetSoup 16 days ago [-]
> 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..
citizenpaul 17 days ago [-]
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.
Levitz 17 days ago [-]
> 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.
17 days ago [-]
matt-p 17 days ago [-]
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.
dom96 17 days ago [-]
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".
The app router is complete hell and was dog slow when it was launched as "stable/new default".
Use pages and remember that env var patten and you're good.
dom96 17 days ago [-]
Pages is the old thing, why would I use it? Isn't it basically deprecated by now?
vunderba 17 days ago [-]
It might be the old thing but it's still widely supported by Next - in no small part due to the backlash over the IMHO way overengineered App Router.
I still use the pages system and actually find myself increasingly moving back to just using Vite + React if I don't need access to the node-based API.
matt-p 16 days ago [-]
Agree Vite/react is a great choice too.
matt-p 16 days ago [-]
Because it works better?
383toast 17 days ago [-]
Totally agree, Next.js has so much Next-specific stuff (which also changes frequently) that I don't use it anymore.
sibeliuss 17 days ago [-]
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)
tengbretson 17 days ago [-]
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.
YuukiRey 17 days ago [-]
I work on a CMS using NextJS (PayloadCMS) and NextJS is hands down the worst piece of technology I have ever had to use.
christophilus 17 days ago [-]
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.
sexy_seedbox 16 days ago [-]
Worst than Drupal? Magento? Microsoft Teams?
dzonga 17 days ago [-]
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 ?
383toast 17 days ago [-]
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.
revskill 17 days ago [-]
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.
If filesystem routing isn't something you enjoy, Next.js probably isn't the right tool for you.
hu3 17 days ago [-]
> 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.
citizenpaul 15 days ago [-]
Do some people prefer using filesystem routing? I don't think I've used it before but it sounds clunky.
mzronek 17 days ago [-]
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.
Almost all projects I see that use Next.js or React or Vue or any other heavy frontend framework/library would be better off just using a library to template things on the backend (For example Jinja). Sometimes a bit of client side rendering via EJS also makes sense.
Why use a framework at all?
ericyd 17 days ago [-]
Do you feel this way about dashboard apps? The OP is about a dashboard app, and I think they are one example where the benefits of a SPA framework really do make sense. Curious if these fit into the "almost all" criteria you use.
TekMol 17 days ago [-]
What makes a dashboard app particularly suited to not just use simple server side and/or client side rendering but a framework?
ericyd 16 days ago [-]
I think the main thing is that the downsides of SPA frameworks are significantly mitigated in a dashboard app.
Typically dashboards will be accessed on a desktop in an office setting with good internet, so initial load and asset size isn't a huge issue. Then you get benefits like client side routing which feels snappy, and live updating widgets is pretty simple. Of course it's a matter of opinion though.
TekMol 16 days ago [-]
I doubt that "client side routing" makes a site more snappy.
I think what you mean is that elements shared across pages (the header, the navigation bar etc) do not have to be sent again.
But those are very small anyhow. And you could bring the size down to zero by making them web components. Web components are cached along with the JS that defines them.
ericyd 15 days ago [-]
Ah yes, thank you for the thorough corrections, you knew much more about this topic than me and correctly guessed exactly what I meant.
mzronek 17 days ago [-]
Using server-side templating is another layer of complexity on top of your stack, that just glues together your output. These template languages are not easy to learn. Custom code for loops, escaping, template inheritance etc. Sometimes these are also hard to debug. The documentation of Jinja is huge.
Things get worse when you bring Javascript into the mix. You need to create Javascript code with your template engine without any Javascript toolchain.
Hard no to the string concat approach for me.
TekMol 17 days ago [-]
How is React easier to learn and debug?
mzronek 17 days ago [-]
With Full-Stack React you will use JSX to directly render HTML. Logic is done with Javascript, so you don't need to learn an additional language. There is also no mapping to Javascript and you can use the standard toolchain (for debugging).
TekMol 16 days ago [-]
How does JSX "directly" render to HTML? Have you compared the codebase of the React to EJS? EJS is much more direct. And the logic is also Javascript.
What do you mean by "no mapping to Javascript"? It is not as if React is part of the Browser API.
mzronek 16 days ago [-]
How do you get the server-side data to client-side Javascript? For example an array of strings or an object.
jbeard4 17 days ago [-]
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.
joshlemer 17 days ago [-]
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?
arend321 17 days ago [-]
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.
floydnoel 17 days ago [-]
I built a small router that can use Prerender for SEO compatibility on vanilla React projects. So there are some alternatives.
hey thanks for linking to routerino <3, i;ve thought about using something like this for my vanilla react projects and this seems perfect.
do you know what are the actual downsides for the end-user/client when compared to SSR (besides requiring client js)?
floydnoel 16 days ago [-]
the main downside as a developer is it can be a little more work to set up Prerender depending on your hosting setup (although Netlify has just a checkbox to enable) to allow Googlebot to view the page JS-free. I've been playing around with some ideas to eliminate that requirement, however.
as an end user, the only downside would be the typical SPA ones, such as the client needs to render the site with JS like you mentioned (except in cases where we use pre-rendering).
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.
arez 17 days ago [-]
in what way has crawlability anything to do with that?
akritrime 17 days ago [-]
I am more surprised at how the general notion has shifted towards the idea that Next.js is the default starting option now. It just feels like such a drastic change to me, compared to even 2 or 3 years back (last when I paid enough attention to frontend stuff).
chrisweekly 17 days ago [-]
Yeah, NextJS is very opinionated and IME (doing webdev since 1998), using Vite (and optionally React-router / Remix, for SSR etc) makes MUCH more sense.
nickdichev 17 days ago [-]
I’ve been playing around with Vike to replace a NextJS app and I’m having a good time. It gets out of my way and lets me build how I see fit.
There was some incorrect information in that post, which was later followed up on by myself (I work on Next.js) – Kent linked back in his post (https://archive.leerob.io/blog/using-nextjs)
ggregoire 17 days ago [-]
Most users don't need anything else than React with React-Router, a tool like Vite or similar for hot reload in dev and make the build, and a static hosting solution like S3 and CloudFront to host the app for peanuts.
akmittal 17 days ago [-]
Nextjs had become the de facto standard for writing React apps. However, things seem to have gone sideways after RSC. Not just Next, with time, React has become very confusing.
Hopefully, turbopack and RSC fixes some of these issues in future.
joshcsimmons 17 days ago [-]
“We received an unexpected $2,000 bill from Vercel due to high API usage from a single user”
Skill issue.
Testing APIs became a nightmare, because we had a lof of server actions mixed with api routes.
Sounds like you designed the app poorly.
Build times got so slow it felt like watching paint dry.
Heard but is there any situation where you’d a sub 3 minute deploy.
Local dev was brutal - every tiny change triggered a full SSR reload.
I have never noticed this as an issue across any Next app of any size that I’ve worked on.
I agree that next probably doesn’t scale but it’s pretty good for 0-to-1 without having to worry about setting up routing, tailwind, basic API etc
cess11 17 days ago [-]
Liveview addresses some of the things they lost, like crawlability.
Are you really proposing for JS developers to learn another stack? Only half-joking.
mrweasel 17 days ago [-]
It was only recently that I realised that there are developer out there who know only Javascript. That's crazy to me, it's like a language of last resort, for when you absolutely need the browser to do something it wasn't meant to do.
cess11 17 days ago [-]
If they do they won't have to learn more, the BEAM has everything: load balancing, in-memory database, distributed inference models, agent frameworks, video streaming and pattern matching that will make Javascript array destructuring look like child's play!
Though I can sympathise with wanting the simplicity of React, after all it's just a diffing algorithm and markup.
katspaugh 17 days ago [-]
We’re also seeing super slow dev build times with Next.js. It takes around 12 seconds for the initial page and then 2-3 seconds for other pages.
I always thought it was an inherent issue in this app due to the many dependencies (9000+ modules for each page) but I’m going to try what the article suggests.
Does Rsbuild or any other build tool provide an alternative to Static Site Generation with automatic code chunking? Because this part of Next.js is great. The production app is super fast to load.
Edit: looks like Rspress does exactly that.
actualwitch 17 days ago [-]
You don't have to lose backend/frontend logic colocation when you shed next.js, just implement your own ssr which is mostly trivial. You don't have to use server components either, you just have to guarantee that node imports get pruned from browser build, and then you can run node deps on ssr to your heart's content. I went this way in my recent pet project and not gonna lie, updating dependencies and nothing breaks feels wild after years of next/cra churn.
deanc 17 days ago [-]
I hate to be blunt here but if you are complaining about 3min builds and 10s start-up times for a dev environment, you are looking at the wrong areas of optimisation.
codehotter 17 days ago [-]
? These are complete unacceptable, developer feedback loops should be measured in milliseconds not minutes.
12345hn6789 17 days ago [-]
These are for cloud / non local builds no? My company is pushing 10-15 minutes for cloud deployments. I'd love for 3 minutes.
joshribakoff 17 days ago [-]
Is the implication developer experience does not matter and user experience is the only thing that matters?
I can improve the user experience faster and more reliably if i can iterate faster.
While I wouldn’t agree with the sibling comment that says it needs to be measured in milliseconds, I will say that the faster it is, the more motivated I am to work on it as well.
deanc 17 days ago [-]
No, but when you choose NextJS you're choosing a product and should evaluate the reasons for doing it. It's abstracting away a substantial amount of pain points in deploying and optimising react apps. The OP even talks about some of the things he's losing out on by dropping it. We spend so much time as developers moving on to the next thing, instead of shipping and worrying about a few mins of build time when deploying (which is nothing).
tommy_axle 17 days ago [-]
It's not only a few mins when deploying. Often you want to test the production build locally and it feels like waiting forever. Especially since clicking around in an app for the dev build is slow during cold use. I think it has gotten worse as I don't remember build times taking so long in next versions 5 thru 9 or so.
17 days ago [-]
mjAxi0m 17 days ago [-]
I've been using https://perseid.dev for years, for building web apps, never had any performance issues. Only websites like e-commerce really need SSR. For all the other use cases, it's really just a fancy thing, not worth the extra development complexity and hosting costs.
17 days ago [-]
izwasm 17 days ago [-]
I totally agree, but what i hate about react.js is that if you have like a big app, the routes definitions will be a nightmare, i would love to see native file routing system inside react.js
ggregoire 17 days ago [-]
> i hate about react.js is that if you have like a big app, the routes definitions will be a nightmare
I'm curious how you define your routes cause I've got several big apps with lot of routes, nested routes and complex access permissions for each route and it never entered in my mind that there was anything complicated about it.
17 days ago [-]
lovegrenoble 17 days ago [-]
Build time went from a couple of mins to 18 secs
Why it's important for you? How many times in a day do you need to build the app?
383toast 17 days ago [-]
if you have a build on every CI run (every commit pretty much) and a preview link, then it really adds up...
383toast 17 days ago [-]
Yep nextjs doesn't really provide much for regular CRUD/SaaS apps, just use Vite react starter
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.
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.
Simple is better, but bare doesn't necessarily mean simpler.
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.
Kubernetes out of the box is not ready to go. What Ingress are you going to use? Ingress-Nginx. Cool cool, How is that getting deployed? Helm Chart. How do we keep track of that being kept up to date and who deployed it? ArgoCD. So who is going to teach all CRDs for Argo and how they work with each other? SREs. You understand we dislike the devs and last thing we want to do is hold classes they don't want to learn? JUST BUILD A PLATFORM. And here we go.
So out of box, most people deploy Kubernetes + 8 "plugins" and it's Frankenstein monster that's you have to manage or it will decide to kill all the workloads one day.
EDIT: I'm didn't even discuss certificates for that ingress or all monitoring/logging this cluster will need to make sure it's properly operating.
Also, managing a CI pipeline isn't something very easy to start with, there are entire teams in companies that only do that.
In contrast running a simple server is much more simple, you install a Linux OS (probably Ubuntu server, or Debian), install a web stack (for example Apache, PHP, Mysql or Postgres these days), copy the files of your website in the root directory (/var/www), or if you are fancy pull a git repository on the server so you can update it with a simple "git pull", if you need more websites on the same machine configure virtualhosts (or use one of the many software that have a GUI to configure virtualhosts).
The second solution is much more simple, in fact is the most used solution as far as I see. Most websites doesn't need high availability, if the website of the bike repair shop that I have 100 meters down the street goes offline for a couple of minutes or even one day because I'm doing maintenance on the server really nobody notices it.
It’s a lot of up front knowledge needed for marginal benefit at small to mid scales.
There’s a lot of steps if the “write your deployment yaml” step.
If you need some things like load balancing and zero downtime deploys etc you probably will build your own k8s which is often worse
Kubernetes is not the only game in town.
Sometimes shipping asap is more important. As with just about anything in tech, it’s about tradeoffs.
I may be biased, since I worked in devops before k8s came out, but building a decently scalable system architecture with load balancing and rolling deployments is pretty straightforward with monolithic systems. Especially since service discovery isn’t really a concern. Horizontal scaling works well in many many cases.
Realistically any app simple enough to be deployed by hand with a few docker containers will not be difficult to convert to k8s anyway.
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.
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.
I still use the pages system and actually find myself increasingly moving back to just using Vite + React if I don't need access to the node-based API.
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.
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...
Why use a framework at all?
Typically dashboards will be accessed on a desktop in an office setting with good internet, so initial load and asset size isn't a huge issue. Then you get benefits like client side routing which feels snappy, and live updating widgets is pretty simple. Of course it's a matter of opinion though.
I think what you mean is that elements shared across pages (the header, the navigation bar etc) do not have to be sent again.
But those are very small anyhow. And you could bring the size down to zero by making them web components. Web components are cached along with the JS that defines them.
Things get worse when you bring Javascript into the mix. You need to create Javascript code with your template engine without any Javascript toolchain.
Hard no to the string concat approach for me.
What do you mean by "no mapping to Javascript"? It is not as if React is part of the Browser API.
https://www.npmjs.com/package/routerino
as an end user, the only downside would be the typical SPA ones, such as the client needs to render the site with JS like you mentioned (except in cases where we use pre-rendering).
here's an example site built with Routerino if you'd like to experience what it is like in usage: https://virtourlimited.netlify.app/
But page load optimization does typically bring better user engagement so it’s not just an SEO strategy.
Discussion at the time: https://news.ycombinator.com/item?id=38018217
Hopefully, turbopack and RSC fixes some of these issues in future.
Skill issue.
Testing APIs became a nightmare, because we had a lof of server actions mixed with api routes.
Sounds like you designed the app poorly.
Build times got so slow it felt like watching paint dry.
Heard but is there any situation where you’d a sub 3 minute deploy.
Local dev was brutal - every tiny change triggered a full SSR reload.
I have never noticed this as an issue across any Next app of any size that I’ve worked on.
I agree that next probably doesn’t scale but it’s pretty good for 0-to-1 without having to worry about setting up routing, tailwind, basic API etc
https://m.youtube.com/watch?v=Qz0ZnOMaePo
Though I can sympathise with wanting the simplicity of React, after all it's just a diffing algorithm and markup.
I always thought it was an inherent issue in this app due to the many dependencies (9000+ modules for each page) but I’m going to try what the article suggests.
Does Rsbuild or any other build tool provide an alternative to Static Site Generation with automatic code chunking? Because this part of Next.js is great. The production app is super fast to load.
Edit: looks like Rspress does exactly that.
I can improve the user experience faster and more reliably if i can iterate faster.
While I wouldn’t agree with the sibling comment that says it needs to be measured in milliseconds, I will say that the faster it is, the more motivated I am to work on it as well.
I'm curious how you define your routes cause I've got several big apps with lot of routes, nested routes and complex access permissions for each route and it never entered in my mind that there was anything complicated about it.
Why it's important for you? How many times in a day do you need to build the app?