3 ms·

I often read people complaining about library size, but is there any numbers about the actual impact on the user's perception? i.e. how many milliseconds are w

I often read people complaining about library size, but is there any numbers about the actual impact on the user's perception? i.e. how many milliseconds are we losing in parsing time or download time? I imagine it may matter in a mobile browser but for a desktop app my intuition tells me the difference is not noticeable.

scarlac 10y ago
Every year the mobile market share grows (still) making mobile devices and their experiences even more important. Time lost can vary wildly. 1-10 KB seems like nothing but the collective effect makes a difference if you have enough users. But I think the real reason people are complaining about size is not the potential increase for each version but the trend. Increases will accumulate unless something is actively done. As such, I think the push-back is fine, although I'm personally okay with the size.
- chadscira 10y ago
  We also should remember that most react apps are single page apps, and usually this .js file is aggressively cached on a CDN. Most interactions are close to instant. Server-side rendering fixes the issue of time to first pixel. I think we don't really need to worry about a 10KB bump, especially considering how many websites are serving ads to mobile which are sending over MUCH MORE DATA. I have been traveling around to many 3rd world countries, and when I hit a website thats loading a little slow you know what I do? I wait for it to finish loading, or I refresh. One of the biggest things a site can do to improve speed is picking a good CDN (Cloudflare).
lhorie 10y ago
> is there any numbers about the actual impact on the user's perception ThreadItJS[1] has some tests for this (scroll down to the "Dependency load and execute" section). On my desktop, loading React on a clean cache takes a little over 300ms. Ember is over 600ms. This is just to get to a point where you can start a hello world with the framework on a powerful desktop machine with fast internet. Another anecdote: one project at my day job is using the Auth0 lock library (long story, don't ask). It's basically a login widget, but it bundles all of React and a few other libraries, and it's over 1MB of Javascript (uncompressed). Is the site still usable? Sure, I guess. Could it be faster? Absolutely. Basically it comes down to a trade-off between developer comfort and a commitment to give users the best experience they can get. You just gotta draw a line somewhere. The thing is that many people justify the trade-off of React/Ember/Angular/whatever's code size by saying it provides benefits in maintainability, etc, but the reality is that for a lot of projects, you could compromise less on the user experience side and still have good maintainability with smaller libraries. [1](https://koglerjs.com/verbiage/performance https://koglerjs.com/verbiage/performance)
bsimpson 10y ago
addyo@, samccone@, and slightlyoff@ gave talks at Chrome Dev Summit last week about exactly this topic (and plugged Preact while they were at it). The average load time on mobile right now is 19s. (I think they were citing a DoubleClick study.) The Chrome dev rel team is in the midst of a big educational push around these topics right now, because pages are getting more complex, but median devices and networks are actually getting slower as more low-end devices enter the market. As I recall, one of the other stats they cited is that mobile traffic is outpacing desktop traffic, so unless you're designing an app that really only works on a large screen, your users may be more mobile than you imagine. Facebook is a desktop site (most of their mobile traffic is in native apps), so they don't have the same incentives to optimize React for mobile that other developers might.

scarlac 10y ago

Every year the mobile market share grows (still) making mobile devices and their experiences even more important. Time lost can vary wildly. 1-10 KB seems like nothing but the collective effect makes a difference if you have enough users. But I think the real reason people are complaining about size is not the potential increase for each version but the trend. Increases will accumulate unless something is actively done. As such, I think the push-back is fine, although I'm personally okay with the size.

chadscira 10y ago
We also should remember that most react apps are single page apps, and usually this .js file is aggressively cached on a CDN. Most interactions are close to instant. Server-side rendering fixes the issue of time to first pixel. I think we don't really need to worry about a 10KB bump, especially considering how many websites are serving ads to mobile which are sending over MUCH MORE DATA. I have been traveling around to many 3rd world countries, and when I hit a website thats loading a little slow you know what I do? I wait for it to finish loading, or I refresh. One of the biggest things a site can do to improve speed is picking a good CDN (Cloudflare).

lhorie 10y ago

> is there any numbers about the actual impact on the user's perception ThreadItJS[1] has some tests for this (scroll down to the "Dependency load and execute" section). On my desktop, loading React on a clean cache takes a little over 300ms. Ember is over 600ms. This is just to get to a point where you can start a hello world with the framework on a powerful desktop machine with fast internet. Another anecdote: one project at my day job is using the Auth0 lock library (long story, don't ask). It's basically a login widget, but it bundles all of React and a few other libraries, and it's over 1MB of Javascript (uncompressed). Is the site still usable? Sure, I guess. Could it be faster? Absolutely. Basically it comes down to a trade-off between developer comfort and a commitment to give users the best experience they can get. You just gotta draw a line somewhere. The thing is that many people justify the trade-off of React/Ember/Angular/whatever's code size by saying it provides benefits in maintainability, etc, but the reality is that for a lot of projects, you could compromise less on the user experience side and still have good maintainability with smaller libraries. [1](https://koglerjs.com/verbiage/performance https://koglerjs.com/verbiage/performance)

bsimpson 10y ago

addyo@, samccone@, and slightlyoff@ gave talks at Chrome Dev Summit last week about exactly this topic (and plugged Preact while they were at it). The average load time on mobile right now is 19s. (I think they were citing a DoubleClick study.) The Chrome dev rel team is in the midst of a big educational push around these topics right now, because pages are getting more complex, but median devices and networks are actually getting slower as more low-end devices enter the market. As I recall, one of the other stats they cited is that mobile traffic is outpacing desktop traffic, so unless you're designing an app that really only works on a large screen, your users may be more mobile than you imagine. Facebook is a desktop site (most of their mobile traffic is in native apps), so they don't have the same incentives to optimize React for mobile that other developers might.