Earlier quoted context omitted.
Voice, video, realtime interaction, a devoted user base, an incredible amount of money…
Discourse, not Discord.
whoopsie. thanks.
How web bloat impacts users with slow devices
431–440 of 613 posts
Re: How web bloat impacts users with slow devices
#432Earlier quoted context omitted.
> Are these Androids actually less powerful than an 11 year-old, base-spec MacBook? Yes. Definitely. a Macbook Pro from 2013 has between 4-16GB of memory for one thing. The lowest spec phone in the article (Itel P32) has 1GB. A 2013 Macbook Pro has a 4th gen i5 processor. This phone has a MediaTek MT6580. It's not even in the same ballpark. This is a bit of an extreme example, but the fact is that a very large number…
Additionally, weak Android devices are not necessarily old Android devices. New underpowered Android stuff is sold every day. Cheap tablets are particularly bad about this — I have a Lenovo tablet that I bought maybe a year ago which uses a SoC that benches a bit above a 2015 Apple A9.
$50 android phones are still sold in developing countries and they usually have an MT6580 or UMS312 with 720p screen.
Re: How web bloat impacts users with slow devices
#433I feel like there's a good point made by the Discourse CEO about Qualcomm (and competitors) - the product decision to segment their CPU line by drastic differences in single-threaded CPU perf is a highly anti-consumer one.
In contrast AMD and Intel use the same (or sameish) CPU arch in all of their lineup in a given generation, the absolute cheapest laptop I could find used a Pentium 6805, which still has a GB6 score of well over 1000, sold in a laptop that's cheaper than most budget smartphones.
In contrast, Qualcomm and Mediatek will sell you SoCs that don't even have half of that performance as a latest-gen 'midrange' part.
Re: How web bloat impacts users with slow devices
#434Earlier quoted context omitted.
Did no one call bullshit on the test before running it? Personally I'd just flat out refuse to run the test, likely designing the proper test comparing while third party scripts where enabled. Management and product owners should understand how these things work, and shouldn't ask for bogus data when they do. But teams implementing the changes should just flat out refuse when they know the request isn't reasonable.
Sir, in most companies if you suggest something technical without having equivalent political power, at best, no one will listen to you. At worst you will create political enemies. Probably there was an SDE-2 or SDE-3 who called bullshit on it and got ignored.
You call bullshit on it by either refusing to run the test, or better and more helpfully by running a test that answers the performance question.
I've seen these kinds of requests plenty of ways. Sometimes those asking include a design or specs because they honestly thought that was the right way to do it, other times they are knowingly asking for (in this case) a useless test to check a box. In either case, IMO the right response is to ask questions to clarify the goals and build to that, changing the provided design or specs if necessary.
I've had to play this out dozens of times over the years and never earned enemies from if, at one point I won over the PM leader that everyone on the dev team warned me about. Its all about tact and approach, assume everyone is on the up and up and just ask good questions to clarify the goals. Its hard to get mad at that unless its done in a condescending or argumentative way.
Re: How web bloat impacts users with slow devices
#435Some might be interested in pre-compressing their sites:
https://gitlab.com/edneville/gzip-disk
Re: How web bloat impacts users with slow devices
#436Dan's point about being aware of the different levels of inequality in the world is something I strongly agree with, but that should also include the middle-income countries, especially in Latin America and Southeast Asia. For example, a user with a data plan with a monthly limit in the single-digit GBs, and a RAM/CPU profile resembling a decade-old US flagship. That's good enough to use Discourse at all, but the exp…
> For example, a user with a data plan with a monthly limit in the single-digit GBs
I live in a poor Southeast Asian country.
People with small data plans don't use data from efficient websites, they use wifi which is omnipresent.
30GB of data on a monthly plan is $3.64. Which is about 4-6 hours of minimum wage (minimum wage is lower in agricultural areas).
But more to the point, people don't use data profligately like in the West. Every single cafe, restaurant, supermarket, and mall has free wifi. Most people ask for the wifi password before they ask for the menu.
I've never seen or heard anyone talk about a website using up their data too fast.
It honestly sounds like a made up concern from people who've never actually lived in a developing country.
People here run out of data from watching videos on TikTok, Instagram, and Facebook. Not from website bloat.
Re: How web bloat impacts users with slow devices
#437I'm normally a fan of Dan Luu's posts but I felt this one missed the mark. The LCP/CPU table is a good one, but from there the article turns into a bit on armchair psychology. From some random comments coming from Discourse's founder, readers are asked to build up an idea of what attitudes software engineers supposedly have. Even Knuth gets dragged into the mud based on comments he made about single vs multi-core per…
Knuth is kinda right imo - parallelism as we have it now is unused by 90% of software outside of specialist use cases and running the same single-threaded program on multiple data items.
Programming languages and hardware both offer poor support for fine-grained parallelism and it's very hard to speed up classical software using parallel approaches.
Re: How web bloat impacts users with slow devices
#438>Many pages actually remove the parts of the page you scrolled past as you scroll There is a special place in hell for every web developer who does that.
It’s a performance optimization for rendering a large amount of html. If the DOM had all the items in memory it would perform much worse. Thankfully browsers are working on a feature where you can keep the markup in the DOM for things like CTRL-F without hurting performance. Granted the main reason such a technique is needed is designs that avoid pagination.
What is the feature called?
Re: How web bloat impacts users with slow devices
#439I 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.
I have worked with such people. When I asked them specifics about the "result" (HTML, CSS, JS) they looked at me as if I was talking another language. They came from javascript framework world, and there they didn't really think all that much about that.
My philosophy is nearly completely different, I ask myself what the minimum maintainable code is that would produce the equivalent of a well hand coded HTML+CSS+JS website. Usually the result is magnitudes smaller.
One of those people asked me how I did realtime list filtering on 1000 table rows and still have it load fast ans perform well on mobile. While that isn't really a feat, all I sid was deliver the whole data on the first request and then hide non-filtered data dynamically. That means the webserver didn't have to do anything wild, orher than deliver the same cached data to everybody who filters that list and because this was the only javascript going on on that site it was (to them) unusually performant. If you look at a comparable table row from their solution (some framework, didn't have much insight into it) the resulting html was 80% boilerplate that they didn't even use.
Web development is too entrenched and many wandered too far from the essentials of web technology.
Re: How web bloat impacts users with slow devices
#440This 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.
I'm 53 and I'm at least five years behind getting my specs sorted out - they are currently perched right on the end of my nose now and I have to get the angle right sometimes (astigmatism). That page is nearly fine for me but I just hit CRTL + to scale up. That works for me. That page is pure text with no or at least minimal fiddling. You have your solution for your use case and I have mine. A blind reader will also…
> That page is nearly fine for me but I just hit CRTL + to scale up. That works for me.
How do you do CTRL++ on a mobile phone?