1. 15

  2. 12

    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.

    1. 3

      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. 🤔

      1. 2

        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

      2. 1

        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.

        1. 1

          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.

        2. 6

          you have to go through a wall of text convincing you why not using a framework is a bad idea


          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?

          1. 5

            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?

            1. 6

              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.

              1. 3

                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. :-)

                1. 3

                  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.

                2. 2


                  1. 1

                    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?

                    1. 1

                      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’