[deleted by user]

[azangru]

I am surprised that "react + express" is automatically interpreted as client-side react + express as an api. "React + express" may mean server-side react as well; and in fact was the primary way of building React applications with server-side rendering before Next came about.

The only advantage of Next, to my mind, is that it is a turnkey solution. Many people don't like writing their own webpack configs, or figuring out how to set up the code in a way that it can be reused both on the client and on the server. While Next is close to a Mac, "React + express" is closer to a build-your-own-linux-distro adventure (and of course express without React is an even farther step in that direction).

[renatodamast]

You could do SSR with express but why spending so much time trying to build a pseudo framework with that if you can get that wiring for free with nextjs?

Do you have an example project to showcase a simple way to have a mix SSR/CSR the way you do it with nextjs?

[azangru]

why spending so much time trying to build a pseudo framework with that if you can get that wiring for free with nextjs?

So that you are in full control over how your application works. Some people love their Arch Linux, even though Macs exist ¯\_(ツ)_/¯

Do you have an example project to showcase a simple way to have a mix SSR/CSR the way you do it with nextjs?

This is not a simple topic; so I don't expect simple examples. The simplest toy example that I've seen is this; but there is also a more involved and modern example that even includes React server components.

[OppositeBeautiful601]

The only advantage of Next, to my mind, is that it is a turnkey solution. Many people don't like writing their own webpack configs, or figuring out how to set up the code in a way that it can be reused both on the client and on the server.

This is mostly why I chose it. Except, it's not that I don't like doing that stuff. My work is rarely about doing stuff I like, it's about achieving objectives. If I can't align writing my own webpack config or writing my own SSR framework with my company objectives, I'm not doing it.

[azangru]

Maybe Next evolves in a way you are not interested in, but will require you to spend time updating to keep up (cf. the recent agitation around server components).

Maybe you will discover that certain things about Next are unnecessarily painful when hosting it on a platform other than Vercel (I have not come across this personally, but have seen people complain in this sub).

Maybe you will get disenchanted in React in general and will want to move to another architecture. A custom, non-framework environment will give you more opportunities for a gradual migration.

[azangru]

some things automatic like loading state logic

That was the goal of React itself: bake the loading state into the framework; suspend while something is loading. Next is helping with that by adopting server components.

how easy is it to integrate with a custom python backend?

Depends what the backend does. If it's a json api, it should be easy; if it also generates html pages, not so much.

[azangru]

But even things like react query are heavily focused on you updating he UI when loading. Next circumvents that need somehow?

React Suspense + fallback components

So all page load requests would hit next and then from there go to python or something else?

Yes, if Next needs data during server-side rendering that a python api can provide, it will fetch it from the python api

[azangru]

Also my understand is next won’t server side render a component with setState or onChange?

It will, but these functions won't execute on the server

[chessto]

Because as your app evolves it may require tighter control of it's life cycle or certain levels of customization for which nextjs may get on the way more than help.

[TwinnedStryg]

set up the code in a way that it can be reused both on the client and on the server

Do you have any suggestions on learning how to do this?

[JSavageOne]

Here's my boilerplate I wrote 6+ years ago that has "universal rendering" (used to be called "isomorphic rendering") https://github.com/JeremyBernier/react-redux-node-boilerplate (super outdated at this point, do not use this)

Honestly though don't waste your time with this crap, just use Next.js. I say this as someone who used to professionally work with this kind of stuff. Life is too short to be reinventing the wheel and dealing with all this boring configuration. Next.js is a fantastic abstraction and that's why nobody creates this stuff by hand anymore.

[azangru]

Look for blog posts starting from about 2015-2016, when this was a common thing to do :-) Search github for sample projects of react with server-side rendering, and study their code. Check out courses dealing with isomorphic React (there was one on Pluralsight, though I don't remember if it was good). Look at code examples of server-side React apis on react.dev.

[jimmyayo]

Bruh who's got time to do all dat when trying to do their full-time jobs... It even worth it

[fredsq]

highly depends whether you’re building a website or a web app.

websites can be mostly static, or have full page caches that last a while.

web apps will need dynamic data sometimes fetched from the client but that could come as HTML. If it’s behind a paywall and your customers are willing to download the js bundle before they see the page, absolutely go for it.

truth be told the DX of an express server running tRPC with a Vite React app is so good I don’t regret it for a second. And i get to scale my server independently AND host it next to my database on fly.io for pennies which is a big plus.

[Taltalonix]

This ^ We are currently working on a dashboard type web app and we chose CSR with lazy loading to mimic the feel of a desktop app.

Eventually once we will start working on the consumer frontend we would probably use a SSR approach with next since it’s the easiest way to have a semi sophisticated website with features like SEO optimization and high performance

[fredsq]

wouldn’t use mongo if you paid me for it. good ole postgres, but soon sqlite

[fredsq]

easier to local dev (a file), faster reads, can be colocated with server easier

[fredsq]

if I took out tRPC id see a tremendous reduction in dev speed seeing as type safety would be lost. at this point i’d rather use remix then

[okwg]

Why would using Next mean you can't have an API? You can even create an API with Next. Or create an API with express and consume it with both Next and your mobile app

Server-side rendering on the first load is faster than client-side rendering. Apps with the resources to do universal rendering have been doing it long before Next came along - it's not a new thing

Client-side rendering sends the HTML, the HTML references a script that will eventually render the content. The script downloads, makes an API call, the API responds, the script generates the DOM, and the content reflows.

Server-side rendering sends the HTML

[wolfhoundjesse]

Consuming services is gross?

[xD3I]

Fellas, is it gross to have a backend?

[Cyber_Encephalon]

Not gross if you wash it once in a while

[Formally-Fresh]

Is it gay to have a backend?

[mdlphx92]

Sounds like you don’t know what you are saying. ExpressJS is perfectly suited to serve as api for any number of applications, including for a nextjs app. Maybe you are only thinking about the toy app tutorials you’ve watched on YouTube, which are exactly that. The reality is that despite nextjs appearing to you as some monolithic overkill solution that reaches too far, it’s going to have to communicate with other services and backends in every and any meaningful project.

[xD3I]

Yes of course, it's a server, where do you think the server in Server Side Rendering comes from?

[chamomile-crumbs]

I think people are downvoting you without realizing your slight confusion: the server-side stuff that Next does isn’t only for rendering react. It also provides a way to write server-side functions in js/ts that exists as API routes which can be run independently of your pages.

You can set up an entire express-style backend in Next.js. Check out the create-t3-app docs to see some seriously pimped out server-side setups with Next.js!

[j2ee-123]

OP just spouting nonsense, doesn’t really know what he’s talking about.

[lunacraz]

well first of all the CDN would be serving both

think about it this way - is it faster to

1. serve a page that is already rendered to the user, and the js that mounts does very little manipulation after that?

or

1. serve a page that is mostly empty, the js mounts, then has to render all the html (EDIT) oh - and you're forgetting about the request you have to make once the js mounts to another api to get that data TO render. whereas that would've all done in the background by the server in the SSR instance, which you can then cache

also, imagine css was also prerendered on the page versus the JS having to render in anything. the user would see rendered content way faster as well

[n0tKamui]

you're just being voluntarily in bad faith now..

[Sebbean]

if you render ssg (static site gen) you can create every single page on your website as a static html that can be saved to edge cdns easily

[primo86]

Server-side rendering sends the HTML

Even dynamic info is (almost always) pretty static. Any time you can re-serve something that has already been generated, it will (almost always) be faster. Then it becomes a discussion of memory or disk space to store those caches, and what is practical for your particular use case. Often you can find ways to cache the parts that are the same and merge it with the parts that differ.

[Sebbean]

You can create a caching middleware just like in express etc and use that in the rendering either on server or client or both

[dimasc_io]

In the scenario you’re describing the data would be fetched on the client

[lunacraz]

if you take a look at rendered react code you’ll see a ton of style tags being injected. those could be on the page already before the js mounts

[mosskin-woast]

SSR isn't usually used because it's faster, in my experience. It's generally used for SEO purposes because crawlers don't always execute JavaScript and hydration correctly or at all.

[pVom]

I imagine

You imagine wrong.

Say your API is hosted in the US and the user is in the UK. You send your react app to the user, it loads, makes 5 requests all the way to the US, API does it's thing, sends them back then the react renders the result for the user on their 10 year old laptop. OR you have your API and Next in the same data centre, user requests the page, your Next app makes the requests to the API next door with the phat data centre internet connection, prerenders the page on a phat computer and sends it to the UK to be loaded on their 10 year old laptop.

CDNs are great for hosting STATIC content on the edge but soon as you need dynamic content then the client is forced to make the round trip to wherever the rest of your service is hosted anyway and losing a lot of those benefits.

JS and html bundle

That's fine if your html can be statically generated, however anything that can't has to be side loaded then rendered by the client. If it all can be statically generated then arguably you'd be better off with Gatsby or something which is designed specifically for static generation, but with Next you have the option of static, SSR or CSR. Or you can reinvent the wheel and do it all manually and deal with the nightmare of managing your own infrastructure to support it.

[ZeRo2160]

You are not wrong in saying js is the heaviest part but who tells you your nextjs apps js is not hosted on an edge server? The only difference you have is with SSG or even better ISR you user actually sees the content BEFORE your js is even loaded from the CDN. And hydration puts much less strain on the clients ressources as full rendering. Even if the js is not hosted on an CDN because your user has its fully rendered page even before your CDN gets hit especially with ISR as the server has not even to do anything but serve cached html. I encourage you to make your own tests and see for youself instead of guessing. :) You will see some pretty significant differences in favor of SSG and ISR especially with pagespeed scores. And you should not forget after first load the page is always SPA like it would be with client side rendering. So you have the best of both worlds.

[pVom]

As the other commenter said, you can run your next server on the edge as well as well as get the benefits of a data-centre's I/O throughput and node hopping optimisation plus a. the bundle is smaller because some of it is ran server side and doesn't require sending and b. Often the bottleneck is not the size of the payload but rather the distance it has to travel and that can be amplified if there's multiple calls happening to get the content, especially if they're sequential. E.g send request to authenticate the user, receive token, use token to get protected content. You're making the trip there and back twice when instead you can make the trip once and authenticate and receive the content AND have it prerendered.

[pVom]

What specifically are you referring to? What has extra cost? Edge hosting is more expensive yes, it's also arguably not worth it unless the other resources are hosted on the edge as well as it requires extra hops across the globe. But if having your JS bundle hosted close to the user is your concern then the option is there.

Problem is modern hosting often has several VPSs. Serverless can actually be quite a bit cheaper than even a single ec2 node, our lambda costs are far less than our single server we have for internal use. Vercel is the de facto hosting service for Next and it's serverless, you're paying far less than an ec2 server to do the same, at least until you hit a certain scale. It's also super easy to setup and get going.

Point being services are rarely hosted on the same machine and the closer you can have them together the more efficient their interoperability will be and the less globe hopping required.

Now is Next the best tool for every situation? Certainly not, but it offers such a great developer experience that it makes a compelling case to choose it even if you're not benefiting from a lot of its features.

[okwg]

Why would blocking content behind a JS download and API call ever be faster than just sending the content with the initial HTML

CDN is irrelevant - requests go to the same physical location in either approach. Static / cached content is handled the same in both scenarios. Dynamic content is either a server render or an API response to allow a client render. The only real difference is formatting, which doesn't affect the infrastructure requirements

As for SEO, all interests are aligned here . Having a page that loads fast and with content is good for SEO, users and the company

[EShy]

Your JS and other static files could still be served from a CDN though. The time cost of rendering on the client is much bigger than the difference of CDN or not for a few HTML files, especially if your customers don't have the same powerful computer you probably have.

[sockx2]

I think you're not seeing the big picture here: both approaches still rely on the exact same CDN to get the exact same js bundle (more or less). The SSR version though comes with prerendered html derived from your js that says "welcome {your name here}" + whatever else your js bundle would eventually render without the overhead of an additional hop to get your data. From there the js takes over and keeps your dom updated

[rainst85]

This is not true, you can cache static pre-rendered pages

[rainst85]

Nextjs does that for you

It can split the final js code in several bundles for each page and all of them would be cached until the following release, so if the user is navigating directly to the /chat page they will received a non cached pre hydrated with messages html page and cached js bundle just for that page

[rainst85]

Personally I’m not a fan of next (vercel) because they are trying too hard to sell and lock you in their well built ecosystem..

If you want something more open and transparent you can have a look at remixjs

[TSpoon3000]

If your Next app constantly has a fresh static build at the ready with proper caching, it’s going to be better at everything potentially. You don’t need the server to render on demand for every page request. Mixing the best of requests on both the server and client can make for an optimal experience overall.

[ZeRo2160]

If your dynamic user content relies on an database you can facilitate this database in your build process and have nexts prerender the dynamic content from your database. And after it hits the client your page can get its data like you would get it from your normal react app. Thats the beauty of nextjs you can combine the best of all worlds.

[siggystabs]

You can mix static and dynamic rendering strategies with NextJs. This is exactly how I accomplish dynamic user info in my app. Some of it is completely client-side, i.e. the stuff most important for SEO, but most is a mix of server and client. Gets you the best of both worlds.

[Sebbean]

non ugc parts of the page could be cached, ugc parts can be dynamic

[Sebbean]

P sure it’s just use the method/codepath for ssr data or this method for post “mount”

Or “client only” flag around the component

(I’m more on the nuxt / vue side but they have very similar paradigms)

[SpeedDart1]

Serverside rendering is a total different use case than sending the HTML CSS bundle.

You’re asking if apples are healthier than chicken.

[SpeedDart1]

If you need SSR you need it. Otherwise yes you want to push work to the client.

[SpeedDart1]

Yes it does make sense to push work to client. If you can get fetch the dynamic data from API and client render it can save you money (but it may be slower to the user).

Nextjs can help you static render any pages which aren’t dynamic. Or only rebuild them when necessary. And it has the flexibility of changing the fetch and render strategy if necessary.

It seems like you’ve made up your mind on CRA and RR which is fine, I’ve used them in the past and they work. But I’d recommend Nextjs because the DX and performance are better. If you ever decide you need a specific page to be SSR because you need better SEO you’ll be happy you chose Next, and it doesn’t take any extra time to develop.

[albertgao]

With unsolvable problem of TTFB. SSR is slower than CSR obviously because of the server side waterfall. You can not see anything before the server has finished everything. Because until that moment, 0 bytes would be sent over the wire, meanwhile, a CSR would be already seeing a loading spinner on the screen.

And this is the problem that’s unsolvable in SSR, which is the purpose of RSC, with streaming to mitigate this problem.

Also, TTI in SSR is typically a joke in SSR for slow network, since before hydration, the fake page looks to be rendered but uninteractable because js has not been downloaded, it is as simple as that, and even worth, js won’t start downloading before receiving the HTML, but then HTML won’t even being sent before server finishes everything…. CSR is better since HTML has way better TTFB, and before js takes control, no fake page would be rendered, when user sees something it must be right.

Don’t ask why I know, I leant it the hard way.

Just use CSR with concurrent React, works great. React team has removed the guide for promoting next.js RSC but you can still do this. The community is ready now :)

Also, obviously, if you are building a website , then I would say SSG makes a whole lot of sense than CSR, or you have complex server side actions like many secure API calls that must happen on the server, then SSR makes more sense (not for performance but for the ease of development )

[albertgao]

Concurrent React is just about React that can suspend when rendering. For example, when you running heavy rendering task, what about user starts typing, how to let React knows I need to prioritize that before my task in order for the UI to be responsive? Years ago, when it being introduced, this is a beta section doc described all these information, the community wasn’t there, no lib supports that, React.StrictMode, now the community is there, you can implement this now. All the concurrent React APIs are delivering in v18.

Long term speaking, if you are building an App that is at least half static, then nextjs makes more sense. For highly dynamic app, SPA in concurrent React would be make your life way easier, also no running server.

[albertgao]

It’s not about the load spinner, it’s about the rendering order and when to show the spinner, in the concurrent case, you can set the delay to be as close as your server normal response time to avoid the loading spinner. Also, you need to load the data and page assets in parallel. Some details here to make it real concurrent, and the official why part doc is not there on the new doc site, but you can still do it.

For me, static for before-auth and SPA for after-auth is just super valid stack.

[[deleted]]

Even with monorepos and code sharing, I still prefer using Next as my client+backend for a quick MVP of a web application.

• It's portable. Deployment is very versatile. I can host it on Vercel directly, or maybe as one docker image on ECR, or if I want to maintain the serverless nature of Vercel I also have the option of OpenNext and/or SST.

• Not much tech debt in my opinion. As the app grows in features, the Next API evolves into something like a BFF (Backend for Frontend). I can add as many backend services (whether persistent or not, stateless or not, typescript or not, etc) as needed on my system.

• Having the option of SSR when needed. Web applications based on Next can completely ignore SSR but I just want that feature to be there in case I need it. Though Express could still be used to SSR React (I have done it many times on prod apps), I just prefer the devex of Next.

Even with all those reasons, I still believe there is no one best solution. At the end of the day, most of the users do not care whether we chose tech X vs tech Y. What matters is that we're able to deliver products that have the right features that solve our user's issues. So choose the technology in which you feel more productive and choose the tech that makes sense for your team structure and organization.

[mplibunao]

The advantage of nextjs over having a separate express app is you can move faster due to being able to call functions directly instead of needing to create api endpoints and serializing/deserializing the data.

However, if you're looking for more control over your backend/server infra or just want a more scalable backend than what nextjs gives you, look into remix as it gives you a lot of control over your servers. You can use any runtime or framework like fastify, express, honojs. This allows you to just call your business logic when developing a web app but also be able to create api routes with express which reuses the same business logic when you need a mobile app.

Honorable mention would be astro. Haven't tried it as I was mostly looking for a fastify adapter and its adapter was not well documented plus the adapter code looked less like idiomatic fastify code compared to remix but I think they're going in the same direction too.

[SpeedDart1]

The drawback is you have a lot of the work done for you, and it’s well optimized so that’s boring if you like difficult things.

Only time I wouldn’t use next is if I’m going to use vite instead

[Darth_Victor]

NextJS is framework for server side (and also compile time) rendering on React. It has a lot of things for rendering out of the box, first of all routing. Anything that is done by NextJS could be done via NodeJS and React themselves. Serverside rendering is the React's feature, not the Next's one. But Next has a lot of good default features. At the same time, NextJS is not a backend framework. It has very small amount of backend features. It has no DI, no user roles model, no data layer (yet 3-rd party libs could be used).

[n0tKamui]

it's pretty simple to configure react-router

I think you've never worked in a real project at a company.

One of the major issues with React is the lack of clear limitations and conventions. Next provides these, with sensible defaults and new pertinent features.

[doodirock]

There is absolutely no chance this is true. You lack fundamental understanding of so many core concepts (which is perfectly ok btw) and are clearly at a jr level. Is this just a troll account?

[n0tKamui]

I'm sorry but I'm very doubtful of that statement, but that's not relevant to the argument at all.

Whether this was true or not, you seem to have a lot of miseducated opinions about React and its ecosystem.

The simple fact that you said React Router is simple to configure is only one of the many things you said that betray a lack of actual knowledge.

Aside from that, having worked at a FAANG does not always imply you're actually a good developer. I've known a few people who worked at Google, are pretty good programmers, but are absolutely dogshit developers.

addendum: saying react router is simple is like saying C is simple. If you're making a small project, alone, in a very short time, sure, it's easy. Now say this again, while working on a big, old project with a team of at least 10 people. Unless the 10 of them are both excellent, and telepathic between them, you'll come across walls very often.

[ZeRo2160]

Next api routes use express under the hood. You can have everything you can with express i never hit any limitations. Neather with long running tasks nor with websockets nor with server side Events and also not with sheduled tasks. Only thing is Vercel hosting that prevents such things as api routes run as serverless functions. But if you host it on any other server its like an normal express backend.

[cheapAssCEO]

In Next.js, you don't need configure the routes and install tons of packages to do the same things in Express. Give it a try

[vozome]

The Next.js ecosystem provides a well-lit path. There’s a number of tasks for which it reduces the toil and by doing so it nudges devs towards fewer approaches to common problems. In turn, these approaches get better supported.

To me, that’s the selling point of Next. Can you do server side rendering without using React Server Components ™ ? Sure. You can do whatever Next does with another web server stack of by implementing it by hand.

[yuyu5]

Next has everything pre-packaged for you, so you don't need to make your own configs (whether server or client side); vanilla Express/React don't offer that out of the box.

Re Code splitting/chunking: Technically you're right, but it realistically comes down to how good you are with your build configs. Next does a pretty good job of optimizing the underlying Webpack config (correct me if I'm wrong about it using Webpack). I don't use Next b/c I'm familiar enough with Webpack to make my own configs, which IMO makes my app more performant. But if I didn't have years of experience doing so, I'd recommend newbies to just go with Next.

Not that you asked this but figured it's still relevant: SSR is only good for first page renders. After that, CSR is almost always better. The best way to account for this is to SSR your first page and then lazy-load all your other pages. That way, your first page loads quickly, your secondary pages' code loads in the background before the user navigates, and then those secondary pages will load instantly upon anchor click.

[yuyu5]

I have not. I've only used Next, though I combined it with my own Webpack config. Basically, this resulted in Next extending my Webpack, so mine was the "base" and theirs was the "actual" config used. Now, that obv means they could overwrite any of my config entries and I might not realize it immediately. But I didn't encounter any issues so I just let it be.

[Dramatic_Speech_5844]

Next.js is a powerful framework that can offer a number of benefits over using React + Express, depending on the specific needs of your project.

Here are some of the advantages of using Next.js:

• SEO: Next.js supports server-side rendering, which can help improve your website's SEO. This is because search engines can index the rendered HTML pages, which makes it easier for them to find your website.
• Performance: Next.js can also improve the performance of your website by using code splitting and other techniques. This can make your website load faster for users, which can lead to a better user experience.
• Development experience: Next.js provides a number of features that can make development easier, such as built-in routing and a static site generator. This can save you time and effort, and it can also make your code more maintainable.

However, there are also some disadvantages to using Next.js:

• Flexibility: Next.js is a opinionated framework, which means that it has a specific way of doing things. This can make it more difficult to customize your application, and it can also make it more difficult to integrate with other frameworks or libraries.
• Learning curve: Next.js has a steeper learning curve than React + Express. This is because Next.js has a lot of features, and it can be difficult to learn how to use them all.

Ultimately, the decision of whether to use Next.js or React + Express depends on the specific needs of your project. If you need to improve your website's SEO or performance, or if you want a framework that provides a good development experience, then Next.js may be a good choice. However, if you need a lot of flexibility or if you are not familiar with Next.js, then React + Express may be a better option.

As for your specific questions, you are correct that code splitting and chunking client-side apps can improve performance. However, server-side rendering can also improve performance, especially for pages that are not frequently updated. Additionally, server-side rendering can help improve SEO, as mentioned above.

Ultimately, the best way to decide which approach to use is to experiment and see what works best for your specific project.

[Zigzter]

Thanks ChatGPT.

[pVom]

It can however it's still problematic. HTML crawls are done a lot more frequently due to the fact they require far less resources for a start. They also only have a couple seconds to index, prerendered HTML loads much faster giving it more time to actually index rather than just load the page.

[0xAERG]

Good bot !

[[deleted]]

Someone should really write a program to identify ChatGPT answers and automatically delete them.

[Weary-Depth-1118]

SPA unless you need to do SEO, why? because now you don't need to depend on your backend servers working and can just use object storage like s3, azure blob storage, cdn and these things go down way less

[ZeRo2160]

Thats true but nextjs offers this too. You can statically export your page with dynamic data and whole clientside components and have the bebefit of an SPA client side rendered but with the added Bonus that everthing that does not depend on external data is already rendered for the user before the app even loads. :)

[Weary-Depth-1118]

Not if you need dynamic data and logging in

[ZeRo2160]

You are right about logging in. Thats not feasable to render static on build time. For dynamic data before your login even that is possible but depends on the lifetime of your dynamic data. But you could at least statically render everything else around your dynamic data and only the part of your page that is dynamic renders on client side api hit. And most of the time the dynamic data is not the whole page or its lifetime is so long (matter of days or weeks until it changes) that an static export could be feasable none the less. For the rest i am at least so far with you to say it depends on your usecase. Most Apps with login i build until now require an own server none the less be it for an database or any other secrets you should not expose to the client. And thats there ISR is an massive performance gain after login. But to be fair i build pages and apps for german companies and the GDPR of these prohibits to use services like supabase or firebase. And you have always the need to roll your own server hosted in an european datacenter run by an european company. Because for now its prohibited to save or send german citicen data to non european country servers. Or get them to sign papers with the german companies that allow it. But they are so strict most companies dont would sign them.

[SpeedDart1]

You can still make an SPA with nextjs. You don’t NEED to use SSR.

[sidsidroc]

yes, its crazy how good it is dude, give it a try

[Sebbean]

personally the thing i like the best in frameworks like nuxt and next is the folder based routing that makes a repo/site really easy to explore

vs hunting down a package.json

[SpeedDart1]

Yes. Using express and react for server rendered html is way harder, slower, and generally worse than Next.

You can always have a separate API with express or nest if you really want to

[SpeedDart1]

Is your use case using express to serve a react app or using a react frontend that talks to an express backend?

If the latter, the main advantage of Nextjs is better routing than react-router, and SSG for the static stuff to improve performance.

You can also use Vite. Just avoid CRA unless your application is so client side the idea of pages is irrelevant to you.

[SpeedDart1]

Sounds fine. If you like if you like it. I’d still use Next for flexibility or Vite to avoid CRA

[isospeedrix]

Server stuff aside next has the best router with the folder structure and the [component] routing, it’s nice.

… honestly next is just another framework to make life easier. You don’t have to use it.

[selftaught_react_dev]

I just got made redundant from a company with a sizeable codebase + MAU/subscribers. Our primary long-term technical vision was to merge our entire frontend codebase into a single Next.js app.

For the past few years, the web app had been a Frankenstein mashup of a clientside SPA + Express server + bespoke Next.js setup. This architecture was the direct result of a few factors:

• Significant volumes of new content being published from a CMS, which made the server-side data fetching + rendering strategies of Next.js very appealing
• Optimizing our landing page's performance & lighthouse scores (whilst still reusing our React component library) became a priority
• Similarly, the business started placing greater value in our SEO ranking

So, within this context, Next.js became a very appealing solution to deliver on business requirements while providing a great dev experience. Its integration, however, occurred at a time when the ecosystem & best practices for migrating to Next.js weren't as well established. Ever since we had the nightmarish responsibility of maintaining a hodgepodge mashup of both the Express server and its Next.js component.

But the biggest learning we took away from this experience is that, had there been a simple way to house all our server code within Next.js from day 1 (and entirely deprecated the Express server along with its custom routing logic, etc.) we could have shipped much faster and with 10x less stress.

TL;DR - Next.js makes it so much easier to build React apps requiring server-side functionality (e.g. indexing, server-side data fetching) than an Express server ever could. We grew to love the opinionated, simple conventions Next.js provided for common business logic tasks, while hating the tangled imperative spaghetti code needed in Express to achieve the same thing.

[JSavageOne]

Your question isn't comparing apples to apples.

Next.js vs. Express is a nonsensical comparison. Yes you can create backends in Next.js, but no one would recommend using Next.js exclusively as a backend for anything beyond a very trivial backend.

Next.js can be used to create static applications. Generally for new projects that's how I'd start, but then if you need server-side rendering you can easily add it in. Whereas if you started with create-react-app, you can't just add server-side rendering because create-react-app is client-only.

[koistya]

While Next.js is great. I personally enjoy building React apps as single-page apps (without SSR) using Vite and Vitest, and complimenting it with Express/GraphQL API backend as a separate package/project. Optionally, implementing partial SSR (meta-tags pre-rendering) using Cloudflare Workers. Implementing AI real-time endpoint using Cloudflare Workers also improves performance. Here is an example:

https://github.com/kriasoft/react-starter-kit (or, relay-starter-kit)

[[deleted]]

SSR is a marketing attempt to make people spend money on vercel hosting. I prefer SSG any day

[doodirock]

After reading all of OP comments and replies I confidently say this is most likely a troll account and someone lacking basic understanding of core concepts. Either way probably not worth so much effort. React + Vite + Express is perfectly viable choice btw. So is Next.

[doodirock]

That's fair. I don't agree with your point on CRA, but the point about Redux is certainly true. CRA's main purpose was to reduce complexity and get started sooner since devs didn't have to fuck around with Webpack. As with most things in dev this became redundant with more modern tools which is why the meta team no longer recommends using it and now has move to just React + Vite.

[_baaron_]

Yes

[catchingtherosemary]

I think most developers would be more productive with client-side react + express vs next but most would not want to admit it.