Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Engineering for Slow Internet

brr.fyi

Post reply on HN
Print view View original

131–140 of 406 posts

Re: Engineering for Slow Internet

#131

Post by SpaceNugget »

mwcampbell wrote: post #122
bayindirh wrote: post #118

Earlier quoted context omitted.

However, getting 6.4KB of data (just tested on my blog) or 60KB of data (a git.sr.ht repository with a README.md and a PNG) is way better than getting 20MB of frameworks in the first place.

False dichotomy, with what is likely extreme hyperbole on the JS side. Are there actual sites that ship 20 MB, or even 5 MB or more, of frameworks? One can fit a lot of useful functionality in 100 KB or less of JS< especially minified and gzipped.

Well, in TFA, if you re-read the section labeled "Detailed, Real-world Example" yes, that is exactly what the person was encountering. So no hyperbole at all actually.

Re: Engineering for Slow Internet

#132

Post by bayindirh »

mwcampbell wrote: post #122
bayindirh wrote: post #118

Earlier quoted context omitted.

However, getting 6.4KB of data (just tested on my blog) or 60KB of data (a git.sr.ht repository with a README.md and a PNG) is way better than getting 20MB of frameworks in the first place.

False dichotomy, with what is likely extreme hyperbole on the JS side. Are there actual sites that ship 20 MB, or even 5 MB or more, of frameworks? One can fit a lot of useful functionality in 100 KB or less of JS< especially minified and gzipped.

I just tried some websites:

    - https://web.whatsapp.com 11.12MB compressed / 26.17MB real.
    - https://www.arstechnica.com 8.82MB compressed / 16.92MB real.
    - httsp://www.reddit.com 2.33MB compressed / 5.22 MB real.
    - https://www.trello.com (logged in) 2.50MB compressed / 10.40MB real.
    - https://www.notion.so (logged out) 5.20MB compressed / 11.65MB real.
    - https://www.notion.so (logged in) 19.21MB compressed / 34.97MB real.

Re: Engineering for Slow Internet

#133

Post by izacus »

toast0 wrote: post #52
chipdart wrote: post #36

Earlier quoted context omitted.

> In Australia you're just 200ms from everything most of the time. (...) > The only app that I am always impressed with is WhatsApp. It's always the first app to start working after a reconnect, the last to get any traffic through before a disconnect, and even with the latency, calls feel pretty fast. The 200ms is telling. I bet that WhatsApp is one of the rare services you use which actually deployed servers to Aust…

> I bet that WhatsApp is one of the rare services you use which actually deployed servers to Australia. To me, 200ms is a telltale sign of intercontinental traffic. So, I used to work at WhatsApp. And we got this kind of praise when we only had servers in Reston, Virginia (not at aws us-east1, but in the same neighborhood). Nowadays, Facebook is most likely terminating connections in Australia, but messaging most lik…

Yeah, it's very very noticeable that WhatsApp is architected in a way that makes experience great for all kind of poor connectivity scenarios that most other software just... isn't.

Re: Engineering for Slow Internet

#134

Post by tecleandor »

mwcampbell wrote: post #122
bayindirh wrote: post #118

Earlier quoted context omitted.

However, getting 6.4KB of data (just tested on my blog) or 60KB of data (a git.sr.ht repository with a README.md and a PNG) is way better than getting 20MB of frameworks in the first place.

False dichotomy, with what is likely extreme hyperbole on the JS side. Are there actual sites that ship 20 MB, or even 5 MB or more, of frameworks? One can fit a lot of useful functionality in 100 KB or less of JS< especially minified and gzipped.

Well, I'm working right now so let me check our daily "productivity" sites (with an adblocker installed):

  - Google Mail: Inbox is ~18MB (~6MB Compressed). Of that, 2.5MB is CSS (!) and the rest is mostly JS
  - Google Calendar: 30% lower, but more or less the same proportions
  - Confluence: Home is ~32MB (~5MB Comp.). There's easily 20MB of Javascript and at least 5MB of JSON. 
  - Jira: Home is ~35MB (~7MB compressed). I see more than 25MB of Javascript
  - Google Cloud Console: 30MB (~7MB Comp.). I see at least 16MB of JS
  - AWS Console: 18MB (~4MB Comp.). I think it's at least 12MB of JS
  - New Relic: 14MB (~3MB Comp.). 11MB of JS.
    This is funny because even being way more data heavy than the rest, its weight is way lower.
  - Wiz: 23MB (~6MB Comp.) 10MB of JS and 10MB of CSS
  - Slack: 60MB (~13MB Compressed). Of that, 48MB of JS. No joke.

Re: Engineering for Slow Internet

#135

Post by AllegedAlec »

I currently develop applications which are used on machines with very spotty connections and speeds which are still calculated in Baud. We have to hand-write compression protocols to optimize for our use. Any updates/installs over network are out of the question.

It's a great lesson in the importance of edge computing, but it also provides some harsh trusth about the current way we produce software. We cannot afford to deliver a spotty product. To get new updates out to all parties takes a prohibitively long time. This is hard for new people or outsiders giving courses to grok, and makes most modern devops practices useless to us.

Re: Engineering for Slow Internet

#136

Post by christophilus »

RedShift1 wrote: post #51
parentheses wrote: post #39

I recall using a device called the "Mini Maxwell" by this company: https://www.iwl.com/ It enabled you to simulate network slow-downs, packet-loss, packet corruption, packet reordering and more. It was so critical in testing our highly network sensitive software.

For browser apps, a network connection simulator is included in the Chrome developer tools' Network tab.

It doesn’t do a great job, though. A good simulator will have random drops, jitter, bursts, etc.

Re: Engineering for Slow Internet

#137

Post by lukan »

padolsey wrote: post #43

A lot of this resonates. I'm not in Antartica, I'm in Beijing, but still struggle with the internet. Being behind the great firewall means using creative approaches. VPNs only sometimes work, and each leaves a signature that the firewall's hueristics and ML can eventually catch onto. Even state-mandated ones are 'gently' limited at times of political sensitivity. It all ends up meaning that, even if I get a connectio…

"I feel like some devs need to time-travel back to 2005 or something and develop for that era in order to learn how to build things nimbly."

No need to invent time travel, just let them have a working retreat somewhere with only bad mobile connection for a few days.

Re: Engineering for Slow Internet

#138

Post by b3orn »

mwcampbell wrote: post #122
bayindirh wrote: post #118

Earlier quoted context omitted.

However, getting 6.4KB of data (just tested on my blog) or 60KB of data (a git.sr.ht repository with a README.md and a PNG) is way better than getting 20MB of frameworks in the first place.

False dichotomy, with what is likely extreme hyperbole on the JS side. Are there actual sites that ship 20 MB, or even 5 MB or more, of frameworks? One can fit a lot of useful functionality in 100 KB or less of JS< especially minified and gzipped.

I'm getting almost 2MB (5MB uncompressed) just for a google search.

Re: Engineering for Slow Internet

#139

Post by RGamma »

bayindirh wrote: post #118
mike_hearn wrote: post #116

Earlier quoted context omitted.

If you're behind an overloaded geosynchronous satellite then no JS at all just moves the pain around. At least once it's loaded a JS-heavy app will respond to most mouse clicks and scrolls quickly. If there's no JS then every single click will go back to the server and reload the entire page, even if all that's needed is to open a small popup or reload a single word of text.

However, getting 6.4KB of data (just tested on my blog) or 60KB of data (a git.sr.ht repository with a README.md and a PNG) is way better than getting 20MB of frameworks in the first place.

Also wonder how many savings are still possible with a more efficient HTML/CSS/JS binary representation. Text is low tech and all but it still hurts to waste so many octets for such a relatively low amount of possible symbols.

Applies to all formal languages actually. 2^(8x20x10^6) ~= 2x10^48164799 is such a ridiculously large space...

Re: Engineering for Slow Internet

#140

Post by rcxdude »

mike_hearn wrote: post #116
jiggawatts wrote: post #113

Earlier quoted context omitted.

By far the lightest weight JS framework isn't React, it's no javascript at all . I regularly talk to developers who aren't even aware that this is an option.

If you're behind an overloaded geosynchronous satellite then no JS at all just moves the pain around. At least once it's loaded a JS-heavy app will respond to most mouse clicks and scrolls quickly. If there's no JS then every single click will go back to the server and reload the entire page, even if all that's needed is to open a small popup or reload a single word of text.

This makes perfect sense in theory and yet it's the opposite of my experience in practice. I don't know how, but SPA websites are pretty much always much more laggy than just plain HTML, even if there are a lot of page loads.
Post reply on HN