[dvt]

> Running your frontend code on the backend to generate HTML is an elegant solution and extremely easy to implement. These days it works out of the box. Not sure where you got the idea it was a "convoluted workaround".

Oh boy, this must be the overstatement of the decade. I've done SSR with a few frameworks now, including Meteor, Nest, and Next. Saying that "it works out of the box" is so disingenuous, it borders on fake news. Even ignoring the trillion edge cases involving authentication, cookies, localstorage, dynamic components, promises/futures, async components, and so on, it will take dozens of man-hours to get properly-rendered server output that works with server-side routing, hydration and looks good on Google's SEO crawlers.

[loh]

From my experience, this is not the case, not for a long time now, at least.

With proper architecture, all you need is plain React (no frameworks) with `styled-components` for everything - i.e., server rendering, client rendering, and hydration.

The architecture I'm describing is a fully top down approach, with concerns separated into API, UI, and App components, where the route dictates the data to be fetched, which is passed as a `store` to the layout to be rendered, with each layout being a composition of the UI components, App components, and occasional API components. I've had a lot of success with this approach and it is, in my opinion, the simplest way, incredibly easy to follow and maintain, and extremely minimal for what is actually being achieved.

With this architecture, switching between server-only rendering and client-only rendering and/or some combination of both becomes a matter of minutes, or even just seconds if you have some env var switches in place.

[a13n]

This hasn't been my experience. How does SSR not work out of the box with NextJS?

[dvt]

Simple example: I worked on an app where I wanted to use the @elastic/eui UI framework[1]. That framework (a fairly popular/vetted one) used some DOM manipulations somewhere deep for some thing or other and Next broke with some bizarre error. Had to find this snippet in someone's reported (Gatsby) issue and stick it in my next.config.js file:

      /**
       * We have to force the bundling of @elastic/eui and react-ace
       * as Gatsby, then all loaders below will match and avoid HTMLElement issues
       */
      config.externals = config.externals.map(fn => {
        return (context, request, callback) => {
          if (request.indexOf('@elastic/eui') > -1 || request.indexOf('react-ace') > -1) {
            return callback();
          }

          return fn(context, request, callback);
        };
      });

      config.module.rules.push(
        {
          test: /react-ace/,
          use: 'null-loader',
        },
      );

And this was just my first SSR issue. Definitely not "out of the box."

[1] https://github.com/elastic/eui