7 ms·

> You know what I love as a user? When I have to wait for a network trip before the Button I clicked on does anything. There is always so much cognitive disson

> You know what I love as a user? When I have to wait for a network trip before the Button I clicked on does anything. There is always so much cognitive dissonance for me when I read performance complaints like this from React/JS folks. They will complain that the user might have to wait 60-100ms extra for an interaction (not ideal at all granted), but totally ignore the 20 seconds spent waiting for megs of JS to download and execute for a new visitor or cache eviction (which happens all too often).

Dylan16807 4y ago
Looking up react plus react-dom version 18 when minified and gzipped is... less than 50KB total? Do I have the wrong number?
- Nextgrid 4y ago
  That doesn't include the overhead of parsing & executing all that, not to mention the runtime overheads of every interaction having to go through megabytes of crap JS instead of native, battle-tested browser code refined over 2 decades.
  - Dylan16807 4y ago
    > That doesn't include the overhead of parsing & executing all that I would say "50KB of zipped javascript framework" includes parsing and execution. > not to mention the runtime overheads of every interaction having to go through megabytes of crap JS ...do I have the wrong number? Even when you decompress those 50KB, it's less than 150KB of javascript. > instead of native, battle-tested browser code refined over 2 decades. Browsers don't have native code for dynamically updating the page. Without javascript the solution is reloading, which adds a lot more overhead than the equivalent react.
nawgz 4y ago
That seems like a strawman. Google Docs spins up a brand new doc - including back-end creation time, mind you - in 7 seconds to full interactivity. Code Sandbox for collaborative coding and hot-reloading in the browser might take 20 seconds. My own apps are usually <512kB because they're built with about 5 libraries outside the build tools, so they take in the region of 1s to interactivity. And then they're snappy :)
- infamia 4y ago
  First, I commend you for writing efficient and snappy apps. People who care about quality and user experience are rare in any field! However, Google Calendar (which I use a lot) takes 20-25 seconds to load on my relatively recent i7 laptop whenever its cache is evicted. I haven't timed Gmail, but it is also very slow (many seconds) when it needs to reload everything. Google's apps are some of the worst offenders, but Proton Mail's apps are similarly slow. This is all consistent across several devices, so I wouldn't call it a straw man at all. Honestly, who doesn't encounter sites with loading screens that last in the high single digit seconds? This is very common, and is completely unacceptable to my mind.
  - nawgz 4y ago
    Counting "opening" as time to interacting: - Opening Google Calendar on my personal phone with my personal calendar took about 6s to interactivity - Opening Google Calendar on my MacBook (2017, dual core) took about 5s - Opening Google Calendar on my MacBook with an "Empty Cache and Hard Reload" took about 10s I'm not sure what your expectations are but it looks to me like web was faster than native for this use case, and even in the worst case under a factor of 2 slower. Pray tell, how long does your phone take to open your calendar?
    - infamia 4y ago
      > Opening Google Calendar on my personal phone with my personal calendar took about 6s to interactivity Are you using the personal version of Workspaces, or just the free version? I use the enterprise version of Google Workspaces, which has a lot more going on than the free version of Google's apps. Maybe that's a big part of the difference. To be clear, I get a 20-25 sec. cold start time on both my i7 Windows work laptop, my new AMD Linux machine, and a personal Windows machine with both OSes using different browsers (i.e., Chrome and Firefox). > I'm not sure what your expectations are... Your acceptance of a 10-second start time, while sneering at the possibility of maybe waiting 50-100ms for an interaction, is precisely the cognitive dissonance I mentioned originally. Possibly waiting 100ms for an interaction to complete is not good... but waiting 10 secs. (and more) to even begin working is very solidly in the "also not good category". Both approaches clearly have compromises. Knowing when to use each approach and resisting latching on to one approach due to personal affinity, is where our trade craft hopefully shines through. I know I don't always live up to that ideal, but we all (hopefully) try to move in that direction every day.

Dylan16807 4y ago

Looking up react plus react-dom version 18 when minified and gzipped is... less than 50KB total? Do I have the wrong number?

Nextgrid 4y ago
That doesn't include the overhead of parsing & executing all that, not to mention the runtime overheads of every interaction having to go through megabytes of crap JS instead of native, battle-tested browser code refined over 2 decades.
- Dylan16807 4y ago
  > That doesn't include the overhead of parsing & executing all that I would say "50KB of zipped javascript framework" includes parsing and execution. > not to mention the runtime overheads of every interaction having to go through megabytes of crap JS ...do I have the wrong number? Even when you decompress those 50KB, it's less than 150KB of javascript. > instead of native, battle-tested browser code refined over 2 decades. Browsers don't have native code for dynamically updating the page. Without javascript the solution is reloading, which adds a lot more overhead than the equivalent react.

nawgz 4y ago

That seems like a strawman. Google Docs spins up a brand new doc - including back-end creation time, mind you - in 7 seconds to full interactivity. Code Sandbox for collaborative coding and hot-reloading in the browser might take 20 seconds. My own apps are usually <512kB because they're built with about 5 libraries outside the build tools, so they take in the region of 1s to interactivity. And then they're snappy :)

infamia 4y ago
First, I commend you for writing efficient and snappy apps. People who care about quality and user experience are rare in any field! However, Google Calendar (which I use a lot) takes 20-25 seconds to load on my relatively recent i7 laptop whenever its cache is evicted. I haven't timed Gmail, but it is also very slow (many seconds) when it needs to reload everything. Google's apps are some of the worst offenders, but Proton Mail's apps are similarly slow. This is all consistent across several devices, so I wouldn't call it a straw man at all. Honestly, who doesn't encounter sites with loading screens that last in the high single digit seconds? This is very common, and is completely unacceptable to my mind.
- nawgz 4y ago
  Counting "opening" as time to interacting: - Opening Google Calendar on my personal phone with my personal calendar took about 6s to interactivity - Opening Google Calendar on my MacBook (2017, dual core) took about 5s - Opening Google Calendar on my MacBook with an "Empty Cache and Hard Reload" took about 10s I'm not sure what your expectations are but it looks to me like web was faster than native for this use case, and even in the worst case under a factor of 2 slower. Pray tell, how long does your phone take to open your calendar?
  - infamia 4y ago
    > Opening Google Calendar on my personal phone with my personal calendar took about 6s to interactivity Are you using the personal version of Workspaces, or just the free version? I use the enterprise version of Google Workspaces, which has a lot more going on than the free version of Google's apps. Maybe that's a big part of the difference. To be clear, I get a 20-25 sec. cold start time on both my i7 Windows work laptop, my new AMD Linux machine, and a personal Windows machine with both OSes using different browsers (i.e., Chrome and Firefox). > I'm not sure what your expectations are... Your acceptance of a 10-second start time, while sneering at the possibility of maybe waiting 50-100ms for an interaction, is precisely the cognitive dissonance I mentioned originally. Possibly waiting 100ms for an interaction to complete is not good... but waiting 10 secs. (and more) to even begin working is very solidly in the "also not good category". Both approaches clearly have compromises. Knowing when to use each approach and resisting latching on to one approach due to personal affinity, is where our trade craft hopefully shines through. I know I don't always live up to that ideal, but we all (hopefully) try to move in that direction every day.