5 ms·

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 webapp

by TekMol 9y ago

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?

mden 9y ago
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 9y ago
  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.
  - stephenboyd 9y ago
    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 9y ago
      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 9y ago
        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 9y ago
        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.").
  - davnicwil 9y ago
    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 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.
linkmotif 9y ago
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 9y ago
  But what the hell kind of state is involved in rendering a static page of text with a few images?
  - linkmotif 9y ago
    My experience has been that this kind of thing is very rare.
  - danielharrison 9y ago
    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.
jasim 9y ago
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.
- TekMol 9y ago
  But is this nytimes approach? How does a server side React app look like? Is it basically a node application then?
  - eyelidlessness 9y ago
    > 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 9y ago
      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?
- daliwali 9y ago
  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/render.js https://github.com/daliwali/simulacra/blob/master/benchmark/...
jorblumesea 9y ago
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 9y ago
  You might like Preact: https://github.com/developit/preact https://github.com/developit/preact It's a 3kb React alternative with the same API.
  - jorblumesea 9y ago
    Interesting, thank you
manigandham 9y ago
> 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.

by TekMol 9y ago

mden 9y ago

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 9y ago
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.
- stephenboyd 9y ago
  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 9y ago
    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 9y ago
      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 9y ago
        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.").
- davnicwil 9y ago
  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 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.

linkmotif 9y ago

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 9y ago
But what the hell kind of state is involved in rendering a static page of text with a few images?
- linkmotif 9y ago
  My experience has been that this kind of thing is very rare.
- danielharrison 9y ago
  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.

jasim 9y ago

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.

TekMol 9y ago
But is this nytimes approach? How does a server side React app look like? Is it basically a node application then?
- eyelidlessness 9y ago
  > 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 9y ago
    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?
daliwali 9y ago
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/render.js https://github.com/daliwali/simulacra/blob/master/benchmark/...

jorblumesea 9y ago

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 9y ago
You might like Preact: https://github.com/developit/preact https://github.com/developit/preact It's a 3kb React alternative with the same API.
- jorblumesea 9y ago
  Interesting, thank you

manigandham 9y ago

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