Hacker News Reader

Comment by bahador | Hacker News Reader

What does "performance orientated" mean?

I use FontFaceObserver (lazy web font loading), minify everything, keep the HTTP requests to a minimum (I'll have to look at that though, now that HTTP/2 is up and coming...), use AppCache and ServiceWorker to make repeat visits almost instant,...

If you have any other ideas how to make this boilerplate even more performance orientated, hmu!

Isomorphic/universal Javascript will insure to have an app SEO friendly and fast rendering times on first visits.

Is it really fast to handle rendering on server side? Why would it be faster than client side?

Because it loads before the JS.

Like any webpage, it is indeed loaded before the JS on client-side. But don't you need to interpret JS on server-side? Why would it be faster than interpreting the React code on client-side?

Client-side: HTML starts loading, browser makes more http requests at various times (JS, CSS, images, etc.), React library loads, data loads, components are initialized, components are rendered.

Server-side: HTML starts loading with component markup already initialized, (other stuff continues.)

I think the GP actually meant that the JavaScript has to be parsed anyway so on the server side you get a delay because the server does it while on the client side you get a delay when the browser does it, so how does this save time in total?

The main problem with client-side rendering is not the parsing time, the problem is the HTTP requests that have to complete before you can start parsing. Whereas parsing on the server side is done in milliseconds by any dynamic document, including this HN page.

While parsing time may not be an issue on client-side, on server-side the situation is a bit different, "server side is done in milliseconds" does not mean it is faster than client side, cf. this presentation [1]. Moreover, I thought that Flux was the solution to the latency introduced by the multiple HTTP requests.

[1] http://www.slideshare.net/nickdreckshage/react-meetup

When this thread started off with the comment saying apps being isomorphic/universal leads to them being "SEO friendly and fast rendering times on first visits" it wasn't about React rendering speed, it was about page load times. First-time visits mean when there the browser hasn't cached various page elements.

I think performance is referring to apps that load fast (server side rendering + AppCache + hot module loading) and using service workers for keeping the main thread running fast.

Service workers or web workers?

simple10 said service works and the repo that we're all discussing mention only service workers. I think it'd be safe to assume we're all talking about service workers.

Actually, there's no server side rendering in this boilerplate yet. It wouldn't be hard to integrate, I didn't want to alienate the front-end devs who are front-end only and don't want to take care of server stuff.

Might have to revisit that again though...

Reply on news.ycombinator.com