Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

React, Relay and GraphQL: Under the Hood of the Times Website Redesign

open.nytimes.com

Post reply on HN
Print view View original

31–40 of 113 posts

Re: React, Relay and GraphQL: Under the Hood of the Times Website Redesign

#31

Post by jasim »

TekMol wrote: post #20

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?

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.

Re: React, Relay and GraphQL: Under the Hood of the Times Website Redesign

#32

Post by jorblumesea »

TekMol wrote: post #20

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?

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.

Re: React, Relay and GraphQL: Under the Hood of the Times Website Redesign

#33

Post by sAbakumoff »

djmashko2 wrote: post #23
lioeters wrote: post #21

Earlier quoted context omitted.

I appreciate your perspective, as I've been considering whether to invest time into learning GraphQL. It's informative to know that it's not suitable for some use cases. Probably could have done without the inflammatory adjectives.. ;) As far as the criticism, would you be kind enough to explain what you mean by "relay concepts", and how GraphQL failed to satisfy those needs?

I think the parent is saying something different: They were happy with GraphQL for their API, but weren't happy with the requirements the Relay client library imposed. My interpretation is that they are now using a GraphQL API but fetching from it with regular HTTP fetches and managing data with Redux on the frontend.

Yes exactly, thanks for your help.

Re: React, Relay and GraphQL: Under the Hood of the Times Website Redesign

#34

Post by TekMol »

stephenboyd wrote: post #27
TekMol wrote: post #25

Earlier quoted context omitted.

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.

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 li…

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.

Re: React, Relay and GraphQL: Under the Hood of the Times Website Redesign

#35

Post by TekMol »

jasim wrote: post #31
TekMol wrote: post #20

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?

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,…

But is this nytimes approach?

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

Re: React, Relay and GraphQL: Under the Hood of the Times Website Redesign

#36

Post by notadoc »

Putting aside all of the technical fun, from a pure reader perspective of any website sometimes I miss just simple boring HTML with a bit of CSS to make it more pleasant and readable. I don't know about anyone else, but particularly from a consumption standpoint I miss the days of 100k webpages.

I'm always stunned, but at the same time never surprised, when you discover a single webpage is 35+ MB, consuming 2GB of RAM, and consuming CPU as if it were a midrange video game.

Re: React, Relay and GraphQL: Under the Hood of the Times Website Redesign

#37

Post by fishnchips »

thomasfoster96 wrote: post #10
colemorrison wrote: post #2

I've looked at GraphQL a number of times. Does anyone have any practical examples of integrating it with backend(s), APIs, and/or specific databases? So instead of "we use GraphQL, much love" + basic example and how it looks on React - a "here's how we take that structure and resolve it and return it." Because that structure looks amazingly sweet - but if in the background it's requiring circles of work, work and rew…

I strongly suggest that you look at Apollo's GraphQL offerings. My 'aha' moment with GraphQL came while reading the docs for their GraphQL server[0]. IMHO Relay doesn't make a lot of sense. Apollo Client [1] has a much better feature set for most use cases, doesn't need React and is better documented. [0] http://dev.apollodata.com/tools/graphql-tools/resolvers.html [1] http://dev.apollodata.com/core/

+1 to that. I'm working on a (mostly) GraphQL application with a Rails backend and a React frontend with a touch of Redux. I really wanted to like Relay but the documentation was lacking (I suspect that a major API change is to blame) and the amount of boilerplate is prohibitive. On the other hand Apollo Client is straightforward, framework agnostic with great React bindings. As a web development veteran I feel that I've never been as productive as with this particular stack.

Re: React, Relay and GraphQL: Under the Hood of the Times Website Redesign

#38

Post by bobwaycott »

notadoc wrote: post #36

Putting aside all of the technical fun, from a pure reader perspective of any website sometimes I miss just simple boring HTML with a bit of CSS to make it more pleasant and readable. I don't know about anyone else, but particularly from a consumption standpoint I miss the days of 100k webpages. I'm always stunned, but at the same time never surprised, when you discover a single webpage is 35+ MB, consuming 2GB of RA…

If anywhere is the place to find others who miss the days of small HTML pages with CSS, especially for reading, HN is that place. :)

Re: React, Relay and GraphQL: Under the Hood of the Times Website Redesign

#39

Post by daliwali »

jasim wrote: post #31
TekMol wrote: post #20

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?

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,…

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

Post reply on HN