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

221–230 of 406 posts

Re: Engineering for Slow Internet

#221

Post by Arthur_ODC »

padolsey wrote: post #49
auggierose wrote: post #47

Earlier quoted context omitted.

Or maybe, just get rid of the firewall. I am all for nimble tech, but enabling the Chinese government is not very high on my to-do list.

Whether you like it or not, over 15% of the world's population lives in China.

Are you a citizen of China, or move there for work/education/research?

Anyway, this is very unrelated, but I'm in the USA and have been trying to sign up for the official learning center for CAXA 3D Solid Modeling (I believe it's the same program as IronCAD, but CAXA 3D in China seems to have 1000x more educational videos and Training on the software) and I can't for the life of me figure out how to get the WeChat/SMS login system they use to work to be able to access the training videos. Is it just impossible for a USA phone number to receive direct SMS website messages from a mainland China website to establish accounts? Seems like every website uses SMS message verification instead of letting me sign up with an email.

Re: Engineering for Slow Internet

#222

Post by the__alchemist »

Thank you! I am in the East coast US, and consistently find web sites and internet-connected applications are too slow. If I am at home, they are probably fine, but on mobile internet? Coffee shops etc? Traveling? No!

No excuses! It is easier than ever to build fast, interactive websites, now that modern, native Javascript includes so many niceties.

Using JS dependencies is a minefield. At work, where I give less of a fuck, a dev recently brought in Material UI and Plotly. My god.

Re: Engineering for Slow Internet

#223

Post by jabroni_salad »

HL33tibCe7 wrote: post #83

Why do writers like this feel so entitled to engineering effort from companies? Maybe companies don’t want to plow millions into microoptimising their sites so a handful of people in Antarctica can access them, when the vast majority of their clients can use their sites just fine.

If you do not want to write software that works well in the antarctic mission, just don't sell to them. Government contracts are pretty lucrative though.

Re: Engineering for Slow Internet

#224

Post by LtWorf »

RGamma wrote: post #139
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.

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

Surely you're aware of gzip encoding on the wire for http right?

Re: Engineering for Slow Internet

#225

Post by chefandy »

nicoburns wrote: post #197
rcxdude wrote: post #140

Earlier quoted context omitted.

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.

It often is that way, but it's not for technical reasons. They're just poorly written. A lot of apps are written by inexperienced teams under time pressure and that's what you're seeing. Such teams are unlikely to choose plain server-side rendering because it's not the trendy thing to do. But SPAs absolutely can be done well. For simple apps (HN is a good example) you won't get too much benefit, but for more highly i…

Yep. In SPAs with good architecture, you only need to load the page once, which is obviously weighed down by the libraries, but largely is as heavy or light as you make it. Everything else should be super minimal API calls. It's especially useful in data-focused apps that require a lot of small interactions. Imagine implementing something like spreadsheet functionality using forms and requests and no JavaScript, as others are suggesting all sites should be: productivity would be terrible not only because you'd need to reload the page for trivial actions that should trade a but of json back and forth, but also because users would throw their devices out the window before they got any work done. You can also queue and batch changes in a situation like that so the requests are not only comparatively tiny, you can use fewer requests. That said, most sites definitely should not be SPAs. Use the right tool for the job

Re: Engineering for Slow Internet

#226

Post by LtWorf »

andrepd wrote: post #124
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.

Yes. It's inexcusable that text and images and video pulls in megabytes of dependencies from dozens of domains. It's wasteful on every front: network, battery, and it's also SLOW .

The crap is that even themes for static site generators like mkdocs link resources from cloudflare rather than including them in the theme.

For typedload I've had to use wget+sed to get rid of that crap after recompiling the website.

https://codeberg.org/ltworf/typedload/src/branch/master/Make...

Re: Engineering for Slow Internet

#227

Post by salawat »

zerkten wrote: post #188
rpastuszak wrote: post #171

Earlier quoted context omitted.

I lived in Shoreditch for 7 years and most of my flats had almost 3G internet speeds. The last one had windows that incidentally acted like a faraday cage. I always test my projects with throttled bandwidth, largely because (just like with a11y) following good practices results in better UX for all users, not just those with poor connectivity. Edit: Another often missed opportunity is building SPAs as offline-first.

>> Another often missed opportunity is building SPAs as offline-first. You are going to get so many blank stares at many shops building web apps when suggesting things like this. This kind of consideration doesn't even enter into the minds of many developers in 2024. Few of the available resources in 2024 address it that well for developers coming up in the industry. Back in the early-2000s, I recall these kinds of t…

>Should developer experience ever weigh higher than user experience?

Developer experience is user experience. However, in a normative sense, I operate such that Developer suffering is preferable to user suffering to get any arbitrary task done.

Re: Engineering for Slow Internet

#228

Post by mkroman »

lukan wrote: post #137
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.

Just put them on a train during work hours! We have really good coverage here but there's congestion and frequent random dropouts, and a lot of apps just don't plan for that at all.

Re: Engineering for Slow Internet

#229

Post by LtWorf »

jerf wrote: post #194
tecleandor wrote: post #134

Earlier quoted context omitted.

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…

I sometimes wish I could spare the time just to tear into something like that Slack number and figure out what it is all doing in there. Javascript should even generally be fairly efficient in terms of bytes/capability. Run a basic minimizer on it and compress it and you should be looking at something approaching optimal for what is being done. For instance, a variable reference can amortize down to less than one byt…

js developers had this idea of "1 function = 1 library" for a really long time, and "NEVER REIMPLEMENT ANYTHING". So they will go and import a library instead of writing a 5 line function, because that's somehow more maintainable in their mind.

Then of course every library is allowed to pin its own dependencies. So you can have 15 different versions of the same thing, so they can change API at will.

I poked around some electron applications.

I've found .h files from openssl, executables for other operating systems, megabytes of large image files that were for some example webpage, in the documentation of one project. They literally have no idea what's in there at all.

Re: Engineering for Slow Internet

#230

Post by LtWorf »

FridgeSeal wrote: post #143
chiefalchemist wrote: post #142

Earlier quoted context omitted.

It's not always the application itself per se. It's the various / numerour marketing, analytics or (sometimes) ad-serving scripts. These third party vendors aren't often performance minded. They could be. They should be.

And the insistence on pushing everything into JS instead of just serving the content. So you’ve got to wait for the skeleton to dl, then the JS, which’ll take its sweet time, just to then(usually blindly) make half a dozen _more_requests back out, to grab JSON, which it’ll then convert into html and eventually show you. Eventually.

Well grabbing json isn't that bad.

I made a CLI for ultimateguitar (https://packages.debian.org/sid/ultimateultimateguitar) that works by grabbing the json :D

Post reply on HN