Compare with one of my projects, [1]
It is a minimal, though modern-looking web chat. The HTML, CSS and JS together is 5024 bytes. The Rust backend source is 2801 bytes. It does not pull in anything from anywhere.
How web bloat impacts users with slow devices
301–310 of 613 posts
Re: How web bloat impacts users with slow devices
#302Earlier quoted context omitted.
In these situations what’s eating up your resources usually isn’t the data being represented but instead the representation. This is why native apps use recycler views for not just infinite scroll, but anything that can display more rows/columns/items/etc than can fit on screen at once. Recycler views only create just enough cells to fill the screen even if you have tens of thousands of items to represent, and when y…
I find this idea interesting ‘These are possible in JavaScript in browsers, but implementation quality varies a lot and many web devs just never bother.’ Do you have any examples that you consider good implementations? I ask because tables seem to be the biggest offenders of slow components in say Angular / PrimeNG. I am going to a legacy app soon that is being updated (Angular but not PrimeNG). Would like to see if…
We do this at Fastmail and, if I say so myself, our implementation is pretty damn good. We’ve had this for over a decade, so it was originally built for much lower powered devices.
Re: How web bloat impacts users with slow devices
#303Earlier quoted context omitted.
> ...which is a long standing point of academic contention. What contention? If anything, Luu is being rather generous–Knuth was just whining that the decades-long free lunch program was being cancelled.
VLIW (Itanium is a VLIW arch) is what's contentious, not multiprocessing.
[deleted]
Re: How web bloat impacts users with slow devices
#304This article is basically unreadable for me 48 y/o on desktop). In the dev tools I added the following to the body to make it readable: font-size: 18px; line-height: 1.5em; max-width: 38rem; Now look how readable (and beautiful) it is. I read a lot of Dan Luu's posts, and each time I have to do this sort of thing to make it readable. Seriously, techies, it's an extra 64 Bytes to make your page more readable.
If you can't read font-size: 14px, you got your resolution/scaling/screen size wrong. The default text size is similar to the standard text size of OS UI controls. If you can't read them, I'd suggest to reconfigure your setup: change resolution, change scaling, or configure the default zoom level.
Re: How web bloat impacts users with slow devices
#305Earlier quoted context omitted.
> ...which is a long standing point of academic contention. What contention? If anything, Luu is being rather generous–Knuth was just whining that the decades-long free lunch program was being cancelled.
VLIW (Itanium is a VLIW arch) is what's contentious, not multiprocessing.
OK I missed that. Thanks. But it looks like Itanium was only tangential to this discussion, in that Knuth thinks multicore programming may be an even worse mistake than Itanium.
Re: How web bloat impacts users with slow devices
#306It impacts me, and I have a fast device!
Re: How web bloat impacts users with slow devices
#307> As sites have optimized for LCP, it's not uncommon to have a large paint (update) that's completely useless to the user, with the actual content of the page appearing well after the LCP
Aahh yes, the “I’ve loaded in my 38 different loading-shimmer-boxes, now kindly wait another 30 seconds while each of them loads more”
Can we go back to “your page is loaded when _everything _ finishes loading” and not these unhelpful micro-metrics web devs are using to lie to themselves and users about the performance of their site?
Re: How web bloat impacts users with slow devices
#308Browsers should only display documents, not apps.
That's what operating systems are for.
Just give native apps what made the web popular in the first place:
• Ability to instantly launch any app just by typing its "name"
• No need to download or install anything
• Ability to revisit any part of an app just by copy/pasting some text and sharing it with anyone.
All that is what appears and matters to users in the end.
--
But I suppose people who would disagree with this really want:
• The ability to snoop and track people across apps (via shit like third-party cookies etc)
Re: How web bloat impacts users with slow devices
#309Using 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?
[flagged]
If you are upset that I posted obv GPT output, then here is a reason why you're failing at your disgruntlement:
I am able to post my prompt in whatever crazy alarmist fashion I would like and massage it into producing an output that I agree with, represents my arguments and doesnt inflame or trigger...
aside from the 12 monkeys anti GPT reponse, because they couldnt imagine that it not a generic GPT-barf, as opposed to the machinations of the OP to get a more salient point without crossing lines....
oops..
Re: How web bloat impacts users with slow devices
#310Compare with one of my projects, [1] It is a minimal, though modern-looking web chat. The HTML, CSS and JS together is 5024 bytes. The Rust backend source is 2801 bytes. It does not pull in anything from anywhere. [1] https://github.com/coolcoder613eb/minchat
Is there a demo site or screenshots somewhere? Add them to README :-)