Hacker News Reader

Comment by bwd1992 | Hacker News Reader

bwd1992

Would have liked to have seen some figures or graphs visualising the React performance boost.

Also I thought one of the advantages of using a js framework is that rendering can be done on the client? It sounds from this article that server rendering is more advantageous?

Also SEO was mentioned, but I thought javascript was taken into consideration by web crawlers?

View on HN

>It sounds from this article that server rendering is more advantageous?

Rendering on the server feels faster to the user. With client side rendering, you will often get a skeleton of the site that loads, and then the content that fills that skeleton 100ms or so apart from one another. This sounds like nothing, but it is perceptible to the user.

There are absolutely ways around this, but even the Big Guys get it wrong sometimes (for instance: facebook).

Initial page load feels faster when rendered on the server. The very moment you navigate to another part of the site, client-side rendering is a huge win for apparent load times. Not only can you give the user feedback that something's loading, but you only need to retrieve the delta from the server between the page you're on now and the one you're going to. Within a few clicks, the amortized cost of the SPA in terms of both latency and over-the-wire size is already lower.

> Also I thought one of the advantages of using a js framework is that rendering can be done on the client? It sounds from this article that server rendering is more advantageous?

Server rendering has advantages when first loading the SPA from the server: better user experience - faster loading because you don't need to wait for AJAX calls to do their round trips between browser and server to get data to populate the page - and better SEO - you don't need to rely on the search engine to correctly render the whole page.

With state changes after the initial load, though, client rendering is much better for UX (responsiveness). The whole point of "universal javascript" is that you can get both (initial server rendering and subsequent client rendering) with the same code base.

Can't one populate the initial state from the server to skip the extra round trip of the ajax call? Eg. dump a json somewhere on the page and have react load it from there, like a global JS variable.

There's that, or use something like python-react[0]. No js on the server required ;)

[0] https://github.com/markfinger/python-react

Yes, that's what's done but also you want the page to be server side rendered for SEO and may be for those who have js disabled.

I suspect that in most cases time spent loading the initial data is dwarfed by the initial app payload and turning the data into html.

Server-side rendering solves this by sending you a full 'screenshot' of the initial app, even before the app is downloaded and 'fresh' data is requested.

The clever thing React does in this use-case is that even though the initial load is 'finished' html, React won't have to re-render the entire thing once your app is loaded and requests new data. Instead, it will be able to seamlessly take over and update only what's new, and do its usual thing from there.

One issue you could run into is that users start trying to interact with your app before React has taken over. I'm not sure if that's a problem in practice though, perhaps others can chime in.

You can achieve that with almost any framework.

I never claimed otherwise, but yeah, it's not something unique to React.

Could you elaborate on how this works with other frameworks? Does it work out of the box in most cases, or require some plugin/module?

Crawlers/indexers take JS into account to varying degrees. In my experience they will execute client side code, but AJAX calls are ignored. So at the very least you want to send down data for the initial load.

I've definitely seen Googlebot hitting the API endpoints of a site via AJAX calls. I can't say definitively how they treat that data, but they definitely call it.

Real world experience with clientside rendering for SEO has tons of downsides. Inconsistency in indexing, delayed indexing (yes Google), some (many) bots not doing it... etc.

It isn't solely server side rendering - the power of React and Node is that you can render on both server and client side, and get the best of both worlds.

Creating a universal JS app on the web has some extra cons too - not only is the code run on the server, but also a not insignificant JS payload is downloaded & executed on the client, as well as increased app complexity in order to maintain client/server separation at extension points.

One should be cognizant that one doesn't get benefits for free with the choice to go with universal JS.

The data is transmitted yes. In practice, after gzip, this is negligible compared to say... any average image loaded on that page.

>as well as increased app complexity in order to maintain client/server separation at extension points.

Can you explain what you mean by this?

And are you comparing client-only vs universal, or client-only vs server-only?

Large JS can be solved with code-splitting. The necessary code is downloaded in chunks when needed.

Not OP but think about the window object in the browser. In a client-side only JS application, you can assume that window will always exist. In a server-side PHP application, you never have to worry about interacting with window. In a SSR React application, you have to manage that complexity of window existing sometimes and it not existing other times if you want to share components between the client and the server.

So then there's:

- code-splitting needed for larger codebases

- taking the window object into account

Other stuff I can think of:

- more limited options for routing/etc. because you want to avoid having to maintain two codebases. This means you might have to use Redux+redux-router+whatever instead of express/hapi/etc. because you can't (?) run those frameworks client-side.

- less freedom to modularize state in your app, because last I checked it was still rather messy to ensure that all the separate data-loading events are taken care of server-side before everything is sent to the client. If you're a fan of the Redux approach this shouldn't be a problem though.

- Possible 'issues' with using ESNext features server-side without going through Babel.

All in all I think it's worthwhile and, nowadays, pretty doable to create a 'universal app'. But it has its own complexities and at least last time I tried, I could find very few examples of how to best do this, and we're probably still far away from a 'canonical' solution.

Furthermore, in practice I've found that in many cases it's not really worth the extra effort. If your app is large/complex enough to have a noticeable load-time, it's probably fine for the user to load the entire app first (it might even still be cached), and it's often the case that SEO is not really important.

In my experience, the few cases where a big-ish app needed to load stuff quickly involved going straight to some subpage in the app. In that situation I often found it easier to either just render that bit server-side the old-fashioned way, with its own logic (in which case React is still a good option).

> but I thought javascript was taken into consideration by web crawlers?

It's still kind of crappy. So people end up building more complex solutions like this or using stuff like prerender.io to work around this issue. Just adds another layer of complexity to the already way to complicated stack of modern SPAs (in my opinion)

javascript taken into consideration by crawlers is still likely to be less efficient and sure than just giving the crawlers html they can understand, thus with universal javascript the same code on client and server can render both places and give crawlers a server rendering of what a non-crawler will see with client rendering (it's what I do, I find the benefit minimal but there is a benefit)

Reply on news.ycombinator.com