← Back to context

Comment by 323

3 years ago

In theory React websites should transfer less data since you just send a JSON model instead of one annotated in full HTML markup. The React runtime would be cached after the first visit.

The problem isn't the amount of data but the number of round trips required to get it.

Imagine you need to do the following calls to get the page rendered with the various information different parts of the page has:

1. Get user information

2. Get projects for user

3. Get the selected project

Now, if this was all server side rendered, it might take 1ms to go to the database and get the various bits of info, or 3ms for 3 sequential requests.

With a react app and say 250ms of latency to the database, you're looking at 750ms of overhead - 200x slower.

Of course you can architect all your APIs to always return everything the user needs so they don't have to do multiple requests, but that has its own drawbacks and honestly is very difficult to do and plan ahead for, especially at scale with multiple consumers of various APIs.

  • What you describe is solved with GraphQL, which is a very mature technology by now.

    • Now we are in the world of graphql, react (and all the other stuff that comes to react), plus the backend server and language. It's a complicated world and I'm not sure we really need that much complexity. There are times when it is needed but I think we've over done it in some cases where we can just have a golang or ruby backend server that renders the page server side. I recently did this and it's a very good feeling just sticking to my server side language that I use daily + html.

      3 replies →

That’s the theory, but every time I measure it the combined data and JS needed to render it wind up being more than plain HTML both in bytes transferred and milliseconds to render.

There will be exceptions of course, but I haven’t found them.