Hacker News Reader

Comment by a13n | Hacker News Reader

This is probably the worst possible takeaway from this article.

> not use javascript for everything

Using JS for frontend + backend has significant advantages. Your developers only need to know one language/codebase. You don't need to hire/maintain separate frontend/backend teams who need to figure out how to coordinate with each other.

> actually generate html

That's what server-side rendering does.

> expecting people to run your code

This is how the web works, for the vast majority of users and markets worth serving.

> having to do it yourself in a convoluted workaround

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

View on HN

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

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

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

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.

> You don't need to hire/maintain separate frontend/backend teams who need to figure out how to coordinate with each other.

In my experience the language is very little of what makes a frontend / backend developer, and you still need separate teams.

Seriously! I find backend work unintuitive and colorless. Others on my “full-stack” team have about as much love for the frontend as I do the backend.

   > Your developers only need to know one language/codebase

As one wise man said: make it easier for the users, harder for a database. The same applies to developers. We tend to forget who we make products for.

This holds true until about a year into the project and everything is complicated beyond the desire of your developers and productivity has tanked.

Reply on news.ycombinator.com