Re:Engineering for Slow Internet
by chiefalchemist on Friday May 31, 2024 @06:23AM
(#40533283)
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.
[ Parent
| on HN ]
Re:Engineering for Slow Internet
by FridgeSeal on Friday May 31, 2024 @06:32AM
(#40533321)
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.
Re:Engineering for Slow Internet
by chiefalchemist on Friday May 31, 2024 @08:49AM
(#40534469)
Yup. There's definitely too much unnecessary complexity in tech and too much over-design in presentation. Applications, I understand. Interactions and experience can get complicated and nuanced. But serving plain ol' content? To a small screen? Why has that been made into rocket science?
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
Re:Engineering for Slow Internet
by chiefalchemist on Friday May 31, 2024 @12:58PM
(#40537506)
I've not so much good vs not so bad vs bad. It's more necessary vs unnecessary. There's also "just because you can, doesn't mean you should."