Pushing next as a default seems pretty reasonable to me.
The ergonomics are comparable to CRA for novices (imo slightly better, but that might be controversial) and it solves some of the problems that are commonly griped about (SSR, broken back buttons) without users really having to think about it. I think the public perception of react would be significantly better if more things were handled by a framework with a reasonably standard approach rather than having everyone trying to stand up their first thing needing to configure eg react-router on their own.
Nextâs SSG output should be equally trivially deployable. Iâve never used it because Iâve never built something complex enough that I felt like I needed react but didnât also need a backend, so the overhead of a long running process or a serverless env is necessary anyway, but the âupload a fistful of static filesâ hosting option is there
What do the costs look like with real node apps on Vercel? I know they use âserverlessâ with it. But, does it get pricey fast if you get decent traffic?
A year or so ago I would have agreed but, as someone who has been building with Nextjs and React for almost as long as they have existed, Nextjs is getting really complicated and in some ways so is react! The new app directory stuff is a step so far away from file system based routing. Itâs hard for me to recommend Nextjs to newcomers as I once did.
Agree and disagree. The part I disagree with is just how complicated these frameworks are, how complex your build becomes, and how difficult it always seems to be to draw outside the lines. But this assumes developers have good knowledge of the existing landscape and know how to make those complexity calls where a framework can make them for you. Making it easy to get a complected build setup for what could be a static site with npm install is a double-edged sword.
Doesnât 80% of the reason for React go away if you do SSR? Arenât all the fancy state stuff, shadow DOM, components etc, pointless if you just render to static HTML? So what weâre left with like JSX, which can be done in many other ways?
Not at all. SSR is basically just an optimisation to make the first page load faster when a user enters the site since the HTML comes back along with the response. After that point the client-side JS takes control again (re-hydration) so your subsequent page navigations happen in js. Itâs not comparable to the old-school SSR of sending back HTML with minimal js.
The expectation is that you will rehydrate on the client so itâs interactive, but yes, React is a poor fit with SSR. Come to think of it, React is a poor fit in general. Itâs the Wordpress of the frontend. :-)
The idea is generally to render to html on the server on a per-request basis. Then when the client gets the initial html the state that was on the server to produce the initial render is reconstituted on the client and it works like a normal react app.
I wouldnât pick up an SPA at this day and age honestly, even when the backend is not Nodejs. Much better to use Gatsby, static Next.js or something (which works at build time) and at least ship a basic skeleton instead of shipping an empty HTML.
If you want to sprinkle React to your MPA, thatâs also documented but since React is a large library I wouldnât recommend it unless you have a lot of those âsprinklesâ and React pulls its weight. Maybe as a way to transition to fully React?
I have been using React (and React-Native, and, later React-native-web) since about 2015. I am still evolving my code base to use more hooks, but I am staying with classes mostly.
My backend is in Java. Deploying NodeJS backend and rewriting things in NodeJS â to get the âfirst page load timeâ better, is something I will not do for many reasons.
One of them is that I would not want to deploy a type-less backend language, while I am happily using Java and sharing a bunch of stuff with my Android client app (even if I would be starting a new project now)
I think there is a clear difference between the âevolutionâ vs âextensionâ of an ecosystem.
I hope that React team focuses on careful, downward-compatible evolution while leaving the âextensionâ to the outside communities.
Maybe this is a bad analogy, but I hope it does not become another âPerl/Rakuâ
Pushing next as a default seems pretty reasonable to me.
The ergonomics are comparable to CRA for novices (imo slightly better, but that might be controversial) and it solves some of the problems that are commonly griped about (SSR, broken back buttons) without users really having to think about it. I think the public perception of react would be significantly better if more things were handled by a framework with a reasonably standard approach rather than having everyone trying to stand up their first thing needing to configure eg react-router on their own.
You can deploy a SPA anywhere more or less for free. Deploying a real Node app is a lot more complicated. Unless you use Vercel. đ¤
Nextâs SSG output should be equally trivially deployable. Iâve never used it because Iâve never built something complex enough that I felt like I needed react but didnât also need a backend, so the overhead of a long running process or a serverless env is necessary anyway, but the âupload a fistful of static filesâ hosting option is there
What do the costs look like with real node apps on Vercel? I know they use âserverlessâ with it. But, does it get pricey fast if you get decent traffic?
A year or so ago I would have agreed but, as someone who has been building with Nextjs and React for almost as long as they have existed, Nextjs is getting really complicated and in some ways so is react! The new app directory stuff is a step so far away from file system based routing. Itâs hard for me to recommend Nextjs to newcomers as I once did.
Agree and disagree. The part I disagree with is just how complicated these frameworks are, how complex your build becomes, and how difficult it always seems to be to draw outside the lines. But this assumes developers have good knowledge of the existing landscape and know how to make those complexity calls where a framework can make them for you. Making it easy to get a complected build setup for what could be a static site with
npm installis a double-edged sword.https://react.dev/learn/start-a-new-react-project#can-i-use-react-without-a-framework
and the content at the link in the screenshot from the article is here: https://react.dev/learn/add-react-to-an-existing-project#using-react-for-a-part-of-your-existing-page.
They document both approaches, and they encourage one and discourage the other. That seems fine to me?
Doesnât 80% of the reason for React go away if you do SSR? Arenât all the fancy state stuff, shadow DOM, components etc, pointless if you just render to static HTML? So what weâre left with like JSX, which can be done in many other ways?
Not at all. SSR is basically just an optimisation to make the first page load faster when a user enters the site since the HTML comes back along with the response. After that point the client-side JS takes control again (re-hydration) so your subsequent page navigations happen in js. Itâs not comparable to the old-school SSR of sending back HTML with minimal js.
The expectation is that you will rehydrate on the client so itâs interactive, but yes, React is a poor fit with SSR. Come to think of it, React is a poor fit in general. Itâs the Wordpress of the frontend. :-)
The idea is generally to render to html on the server on a per-request basis. Then when the client gets the initial html the state that was on the server to produce the initial render is reconstituted on the client and it works like a normal react app.
đż
I wouldnât pick up an SPA at this day and age honestly, even when the backend is not Nodejs. Much better to use Gatsby, static Next.js or something (which works at build time) and at least ship a basic skeleton instead of shipping an empty HTML.
If you want to sprinkle React to your MPA, thatâs also documented but since React is a large library I wouldnât recommend it unless you have a lot of those âsprinklesâ and React pulls its weight. Maybe as a way to transition to fully React?
I have been using React (and React-Native, and, later React-native-web) since about 2015. I am still evolving my code base to use more hooks, but I am staying with classes mostly.
My backend is in Java. Deploying NodeJS backend and rewriting things in NodeJS â to get the âfirst page load timeâ better, is something I will not do for many reasons.
One of them is that I would not want to deploy a type-less backend language, while I am happily using Java and sharing a bunch of stuff with my Android client app (even if I would be starting a new project now)
I think there is a clear difference between the âevolutionâ vs âextensionâ of an ecosystem. I hope that React team focuses on careful, downward-compatible evolution while leaving the âextensionâ to the outside communities.
Maybe this is a bad analogy, but I hope it does not become another âPerl/Rakuâ