>Just as an aside, something I've found funny for a long time is that I get quite a bit of hate mail about the styling on this page (and a similar volume of appreciation mail) Yes! I've definitely felt like this while using his website. Of course, today I just fixed it with main { max-width: 720px; margin: 0 auto; } but tbh, I don't want to install an extension to customise the css on this one site...
How web bloat impacts users with slow devices
471–480 of 613 posts
Re: How web bloat impacts users with slow devices
#472Earlier quoted context omitted.
As a counterpoint, I have a 2015 MacBook, a 2015 iMac, and a recent Apple Silicon MacBook. Of course I do Photoshop, Lightroom, Generative AI, etc. on the Apple Silicon system. But I basically don't care which system I browse the web with and, in fact, the iMac is my usual for video calls and a great deal of my web document creation and the like. I suspect that people who have somewhat older Macs (obviously there's s…
>I do Generative AI, This makes me call into question literally everything else in your post. You might be able to do CPU based for a few trials for fun, but you arent running LLMs on CPU on a daily basis.
The relatively little LLM use I do is in a browser and it doesn't matter which computer I'm doing it on.
Re: How web bloat impacts users with slow devices
#473Earlier quoted context omitted.
Reddit is another example where they've broken the mobile browser experience, to send you to another app. Arguably broken, but in different ways.
[flagged]
Re: How web bloat impacts users with slow devices
#474Using https://www.mcmaster.com/ makes me wish I were a hardware engineer. Makes every other e-commerce site feel like garbage. If amazon were this fast, I’d be broke within days. Why haven’t other sites figured this out?
Maybe a quality service really does cost that much? But the gap in performances and usability is so great, it seems that something else must be at play sometimes.
Re: How web bloat impacts users with slow devices
#475Earlier quoted context omitted.
Performance is a feature and management often doesn't care to optimize for it. If the market valued performance more then we would probably see competitive services which optimize for performance, but we generally don't. I'm sure there's plenty of developers that could deliver improved performance, it's just a matter of tradeoffs. Maybe the people who care this much about performance should start competing services o…
Performance is not a feature. Decisions about performance are part of every line of code we write. Some developers make good decisions and do their job right, many others half-ass it and we end up with the crap that ships in most places today. This “blame the managers” attitude denies the agency all developers have to do our jobs competently or not. The manager probably doesn’t ultimately care about source control or…
Secure software happens because of a culture of building secure software, or processes and requirements. NASA doesn't depend on individual developers "just doing the right thing", they have strict standards.
Re: How web bloat impacts users with slow devices
#476I have modern I7, 64GB RAM, RTX3090, a 7gbps NVME SSD and a 1Gbps internet connection. Can run pretty much any game maxxed out in 4k with 100 fps. Download 100GB files in few minutes. Can do all sorts of tasks and workloads. Can calculate the 20th billionth number of PI in a microsecond. What I cant do however is use twitter without stutters and hitches, or windows, or any shopping website. Nice work, webdevelopers!
> or any shopping website Could you give an example? I used a shopping website yesterday, both on a laptop and on an android phone, and apart from cookie banner popups (design choice, not hardware limitation), did not have any significant inconveniences.
Re: How web bloat impacts users with slow devices
#477I like how most people blame bosses or scary big companies. No developers appear willing to admit that there is a large cohort of not that great web programmers who don’t know much (and appear to not WANT to know much) about efficiency. They’re just as to blame for the sad world of web software as the big boss or corporate overlord that forced someone to make bad software.
So you have a feature team that works on a feature for 6 months, does a 1 hour "KT Session" with the offshore maintenance team and hands them the code. The offshore team has some information on the feature but not enough to really manage existing tech debt, just to keep the lights on. And on top of this they know they are the lowest totem on the pole and don't want to get fired so they don't go out of their way to try and fix any existing code or optimize it, again just enough to keep the thing working.
Then this cycle repeats 100-1000x within an org and pretty soon you have a scenario where the frontend has 2M lines of code when it really should be 250k max. A new feature team might come on with the brightest engineers and the best of intentions, but now they have to work within the box that was setup for them. Say they have a number of elements that don't line up with their feature mockups. The mockups might be incorrect, there might have been an upgrade to the UI kit, or the existing UI kit might need refactoring. Problem is none of that is budgeted for so the team is told to just copy the components and modify them for their own use. And of course on handoff to maintenance team, the new team does not want to mess with the existing feature work so they leave it as is. Management is non-technical so they don't know the difference, and you end up with 50+ components all called "Button" in your codebase from years and years of teams constantly copy/pasting to accommodate their new feature.
Re: How web bloat impacts users with slow devices
#478I like how most people blame bosses or scary big companies. No developers appear willing to admit that there is a large cohort of not that great web programmers who don’t know much (and appear to not WANT to know much) about efficiency. They’re just as to blame for the sad world of web software as the big boss or corporate overlord that forced someone to make bad software.
Marketing team mandating inclusion of at least one "Tag Manager" (if they are especially bad, there will be multiple).
A "Tag Manager" is a piece of JS that is installed together with an API key in the site... and then it downloads whatever extra JS that was configured for given API key. The actual site developer often has absolutely no control over it (the closest I got once was PoC-of-PoC where we tried to put even inclusion of tag manager behind an actually GDPR-compliant consent screen).
Marketing team gets to add "tags" (read, tracking, chat overlays, subscription naggers, whatever), sometimes with extra rules (that also take time processing!), all without involving the development team behind the site.
Re: How web bloat impacts users with slow devices
#479Earlier quoted context omitted.
How do you do that on mobile?
Who read article like this on mobile? In a pinch, I'd just activate Reader Mode (Safari, iOS), or more likely save it for reading on a bigger screen (tablet, laptop,…)
Only thing that annoyed me is that there are very lengthy appendices. Thus the scroll bar suggests the main article is much longer than it actually is.
Re: How web bloat impacts users with slow devices
#480I like how most people blame bosses or scary big companies. No developers appear willing to admit that there is a large cohort of not that great web programmers who don’t know much (and appear to not WANT to know much) about efficiency. They’re just as to blame for the sad world of web software as the big boss or corporate overlord that forced someone to make bad software.
People who never worked with some of the bloated sites often forgot third party in the bloating. Marketing team mandating inclusion of at least one "Tag Manager" (if they are especially bad, there will be multiple ). A "Tag Manager" is a piece of JS that is installed together with an API key in the site... and then it downloads whatever extra JS that was configured for given API key. The actual site developer often h…