It's certainly my experience that using React over a mess of jQuery and its plugins leads to smaller file-sizes when enhancing functionality on a single page, but when you're using React (with Relay, React Router etc) to build the entire site, you end up with enormous payloads.
Let's ignore the gzip size for now, since there's more to file-size than just data over the wire. A production build of a simple React + Relay project (i.e. one that does practically nothing) is around 1mb in size. We can't reliably do server-side rendering with Relay yet, so this is 1mb that must be downloaded and executed before you can see and do anything at all.
This is a bad place to be.
If you are at a point where your task doesn't justify these abstractions - don't use them.
Find the right tool for your job.
My initial reservations about the amount of boilerplate in setting up Relay, were in large part due to the server-side half of the equation. Since switching to building my backend in a different language (now using Elixir with absinthe, rather than node and graphql-js) I've found my productivity has skyrocketed.
At this point the overhead in terms of file-size (and the still pending support for server-rendering) are the only things giving me pause for thought.
With that said React + ReactDOM is 180kbish unminified.
I can't find Relay's size as a single file. Is it really over 800kb?
However, my dev build is 9mb, my production build is 1mb. So when i'm talking about baseline filesize for a React + Relay project, I am talking about production builds. Not all of this 1mb comes from those two libs, but they contribute very heavily towards it.
I still can't figure out where the hell I saw the smaller numbers earlier. I must have been drunk.
Nevertheless it is an ecosystem precisely because you get to pick the pieces you need. For comparison, Redux + Redux Thunk is about 3kb. Immutable is not required either. Of course your app code would have to include data fetching logic which would make it much larger. But those are all tradeoffs you have the power to make.
* It helps us justify to our bosses why a 350kb library is needed instead of a 3kb one.
Without such an explanation, we're essentially taking it on faith that these libraries are written by people who value good quality lean code.
> Without such an explanation, we're essentially taking it on faith that these libraries are written by people who value good quality lean code.
We built something that works for us, balancing feature set, runtime performance, maintainability, code size, etc. We're continually focusing on performance - see https://github.com/facebook/relay/blob/master/meta/meeting-n... for more about what we're focusing on - but so far file size has not been the most impactful thing to work on.
As far as understanding Relay's functionality, we've covered the more obvious aspects in talks (http://facebook.github.io/relay/docs/videos.html) and in a conceptual overview (http://facebook.github.io/relay/docs/thinking-in-graphql.htm...). But an analogy to React is probably simplest. React converts declarative UI descriptions into imperative updates on the DOM. Relay is superficially similar - it converts declarative data descriptions into imperative calls - except that there is no DOM for data, so Relay also implements the query representation, object graph for cached data, networking, mutation queuing & rollback, etc.
We're also giving a tech talk about Relay internals (https://relaytechtalk.splashthat.com/) which may be of interest.
If the bulk of your bundle size comes from page-specific functionality, then you can easily benefit from code-splitting and tree-shaking techniques. But those techniques won't help you at all when it's your core architecture that are enormous, because every single page on your site depends on it.