7 ms·

There are two different kinds of web development: a) Apps where the user is expected to stay a while b) Sites where the user is there, maybe once ever (most l

There are two different kinds of web development: a) Apps where the user is expected to stay a while b) Sites where the user is there, maybe once ever (most likely also scared off by the ads) For Apps, I would always prefer a pre-load of JS that was built with React and downloads about 2-4 MB. If there is an update I will be forced to download it again. On the UPSHOT, almost everything I do in that app is now a 3-8KB request. This means transitioning pages, changing states of things, all happen in about 50ms including whatever visual changes are required on the screen. Compare that to full-screen refresh apps and I am usually waiting 200-400ms. It just feels too damn slow. Why am I even typing this? This is the freaking whole point of an SPA. Are we not all caught up on this yet?

deleted 8y ago
[deleted]
andrewmcwatters 8y ago
These definitions are a bit too narrow for me. I think there's a place for sites where the user is expected to stay a while, and where functionality doesn't warrant several megabytes of resources. Thinking that there's anything but can lead to a wasteful landscape for the web.
- mercer 8y ago
  In those situations I'd generally recommend a conservative server-side approach...
timr 8y ago
Unless your user is sitting in the same datacenter as the app, there is almost no chance that you're getting a 50ms latency on any action that requires a round-trip. Pinging google.com from my current connection (NYC) results in an average 26ms latency. Facebook is 25ms. That's just baseline connection latency for a user in a place with a solid connection, and you're unlikely to do better. Realistically, most apps that aren't Google scale are lucky to get 300ms average latency. The way you improve responsiveness is by eliminating round-trips, not assuming that client-side frameworks will save you.
- k__ 8y ago
  I get a <50ms ping to AWS datacenters in my country.
- delinka 8y ago
  "...there is almost no chance that you're getting a 50ms latency on any action that requires a round-trip." Which is why the comment is advocating for locally-cached resources. "The way you improve responsiveness is by eliminating round-trips..." Hence "preload" above.
  - timr 8y ago
    Frameworks don't make your code smart. Writing a webapp that aggressively preloads without causing problems is hard, and while frameworks give you some tools to make that easier, they don't do the hard work for you.
- jlg23 8y ago
  > Realistically, most apps that aren't Google scale are lucky to get 300ms average latency. I am hosting a quite popular site built with perl and php over 20+ years and with at least 2 round-trips to the DB per request. 150ms latency triggers a warning in monitoring, 200 is considered "critical". The site sits on the west coast, the monitor in Chicago. The site serves at least 10 concurrent clients at any time (read: 5am) up to a few thousand. And I am painfully aware that the bottleneck is the code, not the network.
  - timr 8y ago
    Honestly, it sounds like you're set up better than 95% of the webapps I've encountered (and I'm including some big, famous names in that list). Big, well-resourced dev teams make the mistake of assuming that "works on my box" is the definitive measurement of site speed. But also, let's be real for a moment: define "latency". Is 150ms your (client-measured) connection time? Your render time? Your usable-page time? Again, most webapps are lucky to get HTML back to the user in under 300ms, and if your 150ms metric is "time to server-side render", then you very likely aren't.
sam0x17 8y ago
And the third type -- apps where the user is expected to be a developer ;)
zelon88 8y ago
Your math sounds wrong, so I did it on paper and proved that it's wrong. The average bandwidth for a mobile device in the USA is about 3.25 mb/s (26mbps). So to load your "2-4mb" Javascript library you're looking at 400ms to connect + 1000ms to download resources. That's 1400ms. Now for the rest of the math I benchmarked my own website. My homepage is ~300kb and loaded in 461ms. The fastest you're going to get ANYTHING back from my server is about ~170ms. Lets start with your App. 1,400ms and the app is loaded. Load another page and it takes 200ms to load another 5kb of content. Load one more page and it's another 200ms for 5kb of content. I've been waiting on your website for a total 1,800ms and viewed three "pages" of content. Lets move on to my website. ~450ms and the site is loaded. Load another page and it takes another ~450ms to load another 300kb. Load another page and that's another ~450ms to load another 300kb. I've been waiting on my website for a total of 1,350ms and viewed three actual pages of content, but the user only had to download 900kb instead of 4mb. So I think you proved the OP's point.
- fovc 8y ago
  User expectations are very different for when they are starting work vs when they are in the middle of something. If it's really a SPA you can also disguise the load times with optimistic updates and such
  - chooseaname 8y ago
    Don't people still have data caps?
  - extrapickles 8y ago
    You can also stream in most of the assets while the user is trying to remember their username/password.
- Izkata 8y ago
  Shouldn't your static assets be cached in the browser for pages 2 and 3, making your subsequent pages load a bit faster than the first?
- mercer 8y ago
trolleyhacker 8y ago
As long as web designers and developers continue to target imaginary users or themselves, they'll also leave real users wanting more. Great, you've shaved off 150-350ms of refresh load time. So why does your website take 10-15 seconds to load on my phone when I'm walking about the supermarket? Get out of the lab. Start testing with real users in real contexts. You'll quickly learn that many of your assumptions about what users want disappear.
CM30 8y ago
The issue of course is that about 80% of websites don't need to be 'apps' or SPAs or what not. If you're building a news site for instance, it's basically a blog at the end of the day, not something akin to Gmail or Discord or what not. Same goes with a lot of sites that seem to be built as web apps despite not needing to be apps in any shape or form.
- sam0x17 8y ago
  It reminds me of when I was in 8th grade and I discovered Visual Studio and made tons of "apps" that were glorified iframes with a menu and an about box for no reason other than I could. It's a clear case of a solution in search of a problem syndrome (not that there aren't proper use cases for complex web/desktop apps, obviously).
combatentropy 8y ago
Map and chat apps are the ones I can think of right now that is better as a single-pager. I have been writing web apps for over 10 years. They aren't single-pagers, yet everything is a "3-8 KB request" and happens in "about 50 ms." There is never a time at any point where "2-4 MB" is needed. Now perhaps you are thinking these are ugly, and it means little to you if I claim that they aren't. All I can say is before I was a programmer I was a graphic designer, and I still like studying and thinking about user interface design. Oh, and my customers have complimented the look and feel of my apps, without solicitation, many times through the years.

deleted 8y ago

[deleted]

andrewmcwatters 8y ago

These definitions are a bit too narrow for me. I think there's a place for sites where the user is expected to stay a while, and where functionality doesn't warrant several megabytes of resources. Thinking that there's anything but can lead to a wasteful landscape for the web.

mercer 8y ago
In those situations I'd generally recommend a conservative server-side approach...

timr 8y ago

Unless your user is sitting in the same datacenter as the app, there is almost no chance that you're getting a 50ms latency on any action that requires a round-trip. Pinging google.com from my current connection (NYC) results in an average 26ms latency. Facebook is 25ms. That's just baseline connection latency for a user in a place with a solid connection, and you're unlikely to do better. Realistically, most apps that aren't Google scale are lucky to get 300ms average latency. The way you improve responsiveness is by eliminating round-trips, not assuming that client-side frameworks will save you.

k__ 8y ago
I get a <50ms ping to AWS datacenters in my country.
delinka 8y ago
"...there is almost no chance that you're getting a 50ms latency on any action that requires a round-trip." Which is why the comment is advocating for locally-cached resources. "The way you improve responsiveness is by eliminating round-trips..." Hence "preload" above.
- timr 8y ago
  Frameworks don't make your code smart. Writing a webapp that aggressively preloads without causing problems is hard, and while frameworks give you some tools to make that easier, they don't do the hard work for you.
jlg23 8y ago
> Realistically, most apps that aren't Google scale are lucky to get 300ms average latency. I am hosting a quite popular site built with perl and php over 20+ years and with at least 2 round-trips to the DB per request. 150ms latency triggers a warning in monitoring, 200 is considered "critical". The site sits on the west coast, the monitor in Chicago. The site serves at least 10 concurrent clients at any time (read: 5am) up to a few thousand. And I am painfully aware that the bottleneck is the code, not the network.
- timr 8y ago
  Honestly, it sounds like you're set up better than 95% of the webapps I've encountered (and I'm including some big, famous names in that list). Big, well-resourced dev teams make the mistake of assuming that "works on my box" is the definitive measurement of site speed. But also, let's be real for a moment: define "latency". Is 150ms your (client-measured) connection time? Your render time? Your usable-page time? Again, most webapps are lucky to get HTML back to the user in under 300ms, and if your 150ms metric is "time to server-side render", then you very likely aren't.

sam0x17 8y ago

And the third type -- apps where the user is expected to be a developer ;)

zelon88 8y ago

Your math sounds wrong, so I did it on paper and proved that it's wrong. The average bandwidth for a mobile device in the USA is about 3.25 mb/s (26mbps). So to load your "2-4mb" Javascript library you're looking at 400ms to connect + 1000ms to download resources. That's 1400ms. Now for the rest of the math I benchmarked my own website. My homepage is ~300kb and loaded in 461ms. The fastest you're going to get ANYTHING back from my server is about ~170ms. Lets start with your App. 1,400ms and the app is loaded. Load another page and it takes 200ms to load another 5kb of content. Load one more page and it's another 200ms for 5kb of content. I've been waiting on your website for a total 1,800ms and viewed three "pages" of content. Lets move on to my website. ~450ms and the site is loaded. Load another page and it takes another ~450ms to load another 300kb. Load another page and that's another ~450ms to load another 300kb. I've been waiting on my website for a total of 1,350ms and viewed three actual pages of content, but the user only had to download 900kb instead of 4mb. So I think you proved the OP's point.

fovc 8y ago
User expectations are very different for when they are starting work vs when they are in the middle of something. If it's really a SPA you can also disguise the load times with optimistic updates and such
- chooseaname 8y ago
  Don't people still have data caps?
- extrapickles 8y ago
  You can also stream in most of the assets while the user is trying to remember their username/password.
Izkata 8y ago
Shouldn't your static assets be cached in the browser for pages 2 and 3, making your subsequent pages load a bit faster than the first?
mercer 8y ago

trolleyhacker 8y ago

As long as web designers and developers continue to target imaginary users or themselves, they'll also leave real users wanting more. Great, you've shaved off 150-350ms of refresh load time. So why does your website take 10-15 seconds to load on my phone when I'm walking about the supermarket? Get out of the lab. Start testing with real users in real contexts. You'll quickly learn that many of your assumptions about what users want disappear.

CM30 8y ago

The issue of course is that about 80% of websites don't need to be 'apps' or SPAs or what not. If you're building a news site for instance, it's basically a blog at the end of the day, not something akin to Gmail or Discord or what not. Same goes with a lot of sites that seem to be built as web apps despite not needing to be apps in any shape or form.

sam0x17 8y ago
It reminds me of when I was in 8th grade and I discovered Visual Studio and made tons of "apps" that were glorified iframes with a menu and an about box for no reason other than I could. It's a clear case of a solution in search of a problem syndrome (not that there aren't proper use cases for complex web/desktop apps, obviously).

combatentropy 8y ago

Map and chat apps are the ones I can think of right now that is better as a single-pager. I have been writing web apps for over 10 years. They aren't single-pagers, yet everything is a "3-8 KB request" and happens in "about 50 ms." There is never a time at any point where "2-4 MB" is needed. Now perhaps you are thinking these are ugly, and it means little to you if I claim that they aren't. All I can say is before I was a programmer I was a graphic designer, and I still like studying and thinking about user interface design. Oh, and my customers have complimented the look and feel of my apps, without solicitation, many times through the years.