[TekMol]

Do you guys think it makes sense for a newspaper to use React for the frontend?

I would think React might make sense for realtime dashboards and similar webapps.

But does it make sense for displaying articles, navigation and ads?

[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?

[jorblumesea]

React is a view library and it does this very well. It doesn't have all the bells and whistles like Angular and it's plethora of helpers ($HTTP etc) or complex dependency injection.

I would argue it's the perfect candidate for this purpose. What does a news site need? Articles? Ads? Basic nav? Angular or Ember would be overkill. And with Redux, it's very easy to think about complex UI state.

My only complaint with React is how large it is given what it actually does. Loading 100kb of JS (not Gzipped) seems very heavy.

[stephenboyd]

You might like Preact: https://github.com/developit/preact

It's a 3kb React alternative with the same API.

[jorblumesea]

Interesting, thank you

[mden]

Why not? Newspapers are fairly complex websites too and React is amazing at reducing code complexity, especially when compared to using vanilla js. There are other libraries that would also work great, but then it's comparing pros and cons and there is little reason React can't win in such a comparison.

[TekMol]

    Why not?

My expectation is that the site does the templating on the client then. And my experience with websites that do that is that they load slow, behave sludgy and suffer from all kinds of display errors.

This might be a worthwile tradeoff to quickly build a highly interactive realtime interface. But for a newspaper? As a user I would be very much turned off to endure all that just to read an article.

[davnicwil]

One of the really powerful features of React is that server rendering of the views is trivial. This makes it very compelling even for content sites, where as you rightly say, time to first meaningful render of said content really matters after you hit the URL in your browser.

You could even write an entirely server-rendered web application, or a static website, in React should you be so inclined. In fact, I do the latter for my (very simple) personal site at https://davnicwil.com!

Nothing about React obliges you to do client rendering, a SPA app, or anything complex at all. It's, at the end of the day, just a view rendering library.

[stephenboyd]

Endure it? Try visiting the NY Times. It doesn't load slow, behave sludgy, or suffer from display errors. And SPAs are a faster experience when you know the user is going to be looking at multiple pages, like how people typically read newspapers.

If the user is on any hardware from the past 7 years, a React developer would have to do some distinctly bad programming to make it behave sludgy. Any poor performance is likely to be from the same things that make a classic static page slow: large media files and tracking scripts.

[TekMol]

You mean www.nytimes.com ? Is that already the new react powered version?

As a sidenode, it does feel sludgy:

- Scroll is not smooth.

- It does not adapt well to different browser sizes

- After a few seconds the page "jumps down"

But the reason might simply be the overkill of JS,animations, overlapping elements (like the static header), ads, dynamically loaded stuff and other crap. When I turn off JS, some of the problems go away.

[scottmf]

They're not using React right now. If you read the article it says they'll be introducing the new version over the next several months.

A lot of this "JS is slow, what happened to good old HTML and CSS, get off my lawn" stuff is simply confirmation bias.

[stephenboyd]

I didn't look close enough in the developer tools to see the limited extent. From what I can see, just the email list sign-up forms on www.nytimes.com are using React, but all of the new front page of mobile.nytimes.com is in React. They are testing the new version of the mobile site in a partial roll-out, so if you open a new browser session there's a good chance the new one will get served to you (It will have a message saying "You’re seeing a test of a new version of the New York Times home page.").

[manigandham]

> But does it make sense for displaying articles, navigation and ads?

No it doesn't. We (as a marketing tech company) deal with major publishers all the time and come across all kinds of ridiculous and complicated tech used to show a basic article when a simple static website would be easier and faster at this point.

It's a lack of good talent, resume-led motivations for choosing technology and overall poor vision in execution by CTOs and management.

[linkmotif]

React (or similar library) makes sense whenever you want to have the ability to reason easily about state in your UI application. So if your UI accumulates any kind of user-introduced state, like text input, some kind of toggle, React provides a very pleasant mental model.

[s_kilk]

But what the hell kind of state is involved in rendering a static page of text with a few images?

[danielharrison]

Initial page load might be marginally slower, although it's not hard to thrown down the bare minimum and lazy load the rest, but every subsequent page load will be faster and much less intrusive.

I'd say react is a perfect fit for this type of thing. A basic news site it might be, but there's a lot more going on under the hood than you'd imagine.

[linkmotif]

My experience has been that this kind of thing is very rare.