4 ms·

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

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.

en_js 11y ago
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-notes/2016-03-14-team-sync.md#h1-plans 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 http://facebook.github.io/relay/docs/videos.html) and in a conceptual overview (http://facebook.github.io/relay/docs/thinking-in-graphql.html 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/ https://relaytechtalk.splashthat.com/) which may be of interest.

en_js 11y ago

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-notes/2016-03-14-team-sync.md#h1-plans 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 http://facebook.github.io/relay/docs/videos.html) and in a conceptual overview (http://facebook.github.io/relay/docs/thinking-in-graphql.html 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/ https://relaytechtalk.splashthat.com/) which may be of interest.