4 ms·

good for you, you are doing your job very well. part of the reason why modern software is so crappy, is because developers often have thee most powerful machin

by slt2021 2y ago

good for you, you are doing your job very well. part of the reason why modern software is so crappy, is because developers often have thee most powerful machines (MacBook pro like) and don't even realize how resource hungry and crrappy their software at lower end devices

Escapado 2y ago
Another part of the reason is that in every company I have ever worked for some SEO dude insists we need to add literally 10 different tracking scripts and insists they need to load first and consume megabytes of data. At my last gig the landing page was 190kb of HTML, CSS and JS from us, 800kb of images and literally 8mb in vendor scripts we were mandated to load as early as possible. Of course we fought it, of course nobody cared.
- justmarc 2y ago
  Try an e-banking website which literally loads over 25MB of crap just to show the login page. This is by far the worst offender I've seen. Madness.
huijzer 2y ago
Yes MacBook pro with a glass fibre connection with a ping below 10 ms to the server. I’m usually on an old copper line (16 ms ping to Amsterdam) in the Netherlands (130 ms to San Francisco). Some sites are just consistently slow. Especially GitHub or cloud dashboards. My theory is that the round trip to the database slows things down.
- FridgeSeal 2y ago
  GitHub and everything Atlassian deserve to be thrown in the pit-of-shame and laughed at for perpetuity. Jira is so agonisingly slow it’s a wonder anyone actually pays for it. Are the devs who work on it held against their will or something? It’s ludicrous. GitHub gets worse every day, with the worst sin being their cutesy little homegrown loading bar, which is literally never faster than simple reloading the page.
- oefrha 2y ago
  These days people on HN love to advocate sockety frontend solutions like Phoenix LiveView, where every stateful interaction causes a roundtrip, including ones that don’t require any new data (or all required data can be sent in a batch at the beginning / milestones). It’s like they forgot the network exists and is uneven and think everything’s happening in-process. To ward off potential criticism: I know you can mix client-side updates with server-side updates in LiveView and co. I’ve tried. Maintaining client-side changes on a managed DOM, sort of like maintaining a long-lived topic branch that diverges from master, sucks.

Escapado 2y ago

Another part of the reason is that in every company I have ever worked for some SEO dude insists we need to add literally 10 different tracking scripts and insists they need to load first and consume megabytes of data. At my last gig the landing page was 190kb of HTML, CSS and JS from us, 800kb of images and literally 8mb in vendor scripts we were mandated to load as early as possible. Of course we fought it, of course nobody cared.

justmarc 2y ago
Try an e-banking website which literally loads over 25MB of crap just to show the login page. This is by far the worst offender I've seen. Madness.

huijzer 2y ago

Yes MacBook pro with a glass fibre connection with a ping below 10 ms to the server. I’m usually on an old copper line (16 ms ping to Amsterdam) in the Netherlands (130 ms to San Francisco). Some sites are just consistently slow. Especially GitHub or cloud dashboards. My theory is that the round trip to the database slows things down.

FridgeSeal 2y ago
GitHub and everything Atlassian deserve to be thrown in the pit-of-shame and laughed at for perpetuity. Jira is so agonisingly slow it’s a wonder anyone actually pays for it. Are the devs who work on it held against their will or something? It’s ludicrous. GitHub gets worse every day, with the worst sin being their cutesy little homegrown loading bar, which is literally never faster than simple reloading the page.
oefrha 2y ago
These days people on HN love to advocate sockety frontend solutions like Phoenix LiveView, where every stateful interaction causes a roundtrip, including ones that don’t require any new data (or all required data can be sent in a batch at the beginning / milestones). It’s like they forgot the network exists and is uneven and think everything’s happening in-process. To ward off potential criticism: I know you can mix client-side updates with server-side updates in LiveView and co. I’ve tried. Maintaining client-side changes on a managed DOM, sort of like maintaining a long-lived topic branch that diverges from master, sucks.