Hacker News Reader

People should stop looking for a silver bullet. If you are using react + relay, you must be building a very complex solution, where the overhead for such abstractions is justified.

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.

I've found that the benefits in terms of developer experience, and being able to build good UI quickly, start accumulating almost immediately, even on tiny projects.

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.

For React you kind of have to use the minified file size, because the dev file size is SHOCK FULL of dev-only validation and error messages and other logic that is made to be minified away. The prod build isn't even close to the same code.

With that said React + ReactDOM is 180kbish unminified.

I can't find Relay's size as a single file. Is it really over 800kb?

React unminified is ~660kb.

You're totally right. I downloaded the latest release earlier and looked at the file size, and did it again right now, and you're correct.

I still can't figure out where the hell I saw the smaller numbers earlier. I must have been drunk.

I'll need to do a webpack report to get the actual numbers out.

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 should add, that if there's a truly blessed CDN for these dependencies (cdnjs is the closest we have to that) that everyone uses, it puts us in a much better place. So we should actively be encouraging people to use them.

I'm very split on using these CDNs. I understand the advantage, but do I really want to make my site import Javascript from a third party source? Their downtime becomes my downtime, their security issues become my security issues, and I've now shared my visitor's usage patterns with a third party...

That's a good point, and they've also been my concerns with using them too, which I overlooked with my comment.

I love cdnjs.com but check out npmcdn.com

I see your point. Indeed this does not sound very good. I don’t know enough about Relay or their plans so I can’t really say much.

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.

I agree it's about picking and choosing the right things, but as I think we've both mentioned elsewhere, an audit and explanation of what contributes to file-size in these libraries would be super useful, for a few reasons:

* It helps us justify to our bosses why a 350kb library is needed instead of a 3kb one.

* It helps us understand the overall picture of JavaScript today, what kind of problems we're having to solve that could eventually be better solved by browsers themselves.

* It just makes me more comfortable in my decision to send a lot of JavaScript over the wire.

Without such an explanation, we're essentially taking it on faith that these libraries are written by people who value good quality lean code.

Relay was built to address concerns that our developers faced with managing data in complex apps. Needing to reimplement solutions to the same complex problems (error handling, request coordination, caching, etc) could take time away from focusing on building products. Relay helps to solve these common cases, and it sounds from your comments above ("my productivity has skyrocketed") that you've seen the benefits too - great to hear!

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

Would it be possible to split those libraries in smaller modules? For example Preact (https://github.com/developit/preact) has the same basic API of React but it's just 3kb because a lot of features are stripped away in optional modules. Also, using preact-compat you could replace it as-is* in your bundle right now.

Depends if I need the features in those optional modules. An app is essentially made up from architectural modules (frameworks, alongside anything else that you use everywhere), and then specific pieces of functionality (with dependencies that are used less frequently).

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.