[jasim]

Even if we don't use React on the client side, it can act as an excellent server-side view templating language. This is because React inverts the templating model on its head.

A typical template is an HTML file (or some variation of it) within which the dynamic content is inserted using string interpolation.

A React view on the other hand is a piece of Javascript code which can compose small snippets of view as JSX, use programming constructs like loops and conditionals and finally return the assembled result.

Basically, React views are pure functions that return a validated HTML snippet. Normal templates are big blobs of strings with logic mixed in.

[daliwali]

The string building approach is the fastest, and it's the benchmark to beat. Any other abstraction is just piling more work on top and is generally just a more inefficient way to output HTML. The most lightweight pseudo-DOM implementations are still going to be significantly slower than string concatenation, and I have benchmarks to back up that claim [0].

Realistically, a server-side rendered JS app is also going to run most of the code that runs in the client per page load, so you would also have to consider initialization costs as well. I've had to work on one that took 100+ ms to render a static page (without accounting for network latency), which a static file server could render the same page orders of magnitude faster.

Long story short, most of the newer, non-string based JS server-side rendering does not consider performance a factor and consequently, perform pretty terribly. There are band-aid fixes such as putting a reverse proxy in front or running on super fast hardware, but it's like putting a band-aid on a bullet wound.

[0] https://github.com/daliwali/simulacra/blob/master/benchmark/...

[jasim]

I don't know who downvoted you or why, but yes - performance could be a problem as you pointed out. I prefer the React model simply because it is more programmer friendly. I would hope that performance is something that can be fixed, or at least the 80-20 rule will come to help.

[daliwali]

Most JS server-side rendering never approaches anywhere near string concatenation performance, and I've tried. Whatever abstraction you use has to resemble string concatenation without doing much else, and it's really, really hard to not do much else. That's why embedded JS templates (EJS) is so fast, it just concatenates strings with some logic built-in to the template.

[dbbk]

I'd imagine at the Times' scale they're not server-side rendering every page view though. I'm sure they'd be caching the HTML result at the CDN level.

[daliwali]

Yes, they likely have reverse proxies that cache static content. But this won't work well for any sort of dynamic content, i.e. apps that require login, when data changes in real-time, etc.

[TekMol]

But is this nytimes approach?

How does a server side React app look like? Is it basically a node application then?

[eyelidlessness]

> But is this nytimes approach?

It pretty much has to be, there is no way NYT is giving up showing up in search results.

> How does a server side React app look like? Is it basically a node application then?

There is almost certainly Node somewhere in the pipeline. It's possible to build static content with Node/React as well, but NYT has dynamic server functionality as well so it would not surprise me if there's at least a Node layer in production.

[TekMol]

    It's possible to build static content
    with Node/React as well

Without node.js? How? What type of software is the server side React then?