Related: Too much of technology today doesn't pay attention or even care to the less technologically adept, either. Smartphones in my opinion are a major example of this. I can't tell you the number of people I've meet who barely even or don't even know how to use their devices. It's all black magic to them. The largest problem is the over-dependence on the use of "Gesture Navigation" which is invisible and thus non-…
> The largest problem is the over-dependence on the use of "Gesture Navigation" which is invisible and thus non-existent to them.
This is uniquely an iPhone problem, not a smartphone problem. It’s been one of my biggest gripes after switching from android. Where the heck is my back button? Home button? Any buttons? I really despise Apple’s obsession with minimalism and will be switching back to android when this phone dies.
I'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.
This felt more true a decade ago but there’s been a lot of improvement in both languages (e.g. Rust) and libraries - I routinely see most of the cores on my Macs fully loaded for things like working with media files which used to be single-threaded.
>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.
Pagination is part of it but most of it is simply using inefficient JavaScript frameworks and not learning how the DOM or CSS really work. The maximum number of elements you could have on a phone a decade ago was measured in hundreds of thousands (median) or millions (iPhone), and the hardware & browsers have gotten faster. The problem is that you have had a lot of very turnaround focused developers shoveling out code which uses deeply nested elements, poorly-scoped event handlers, etc. which mean that too many DOM elements are created, unnecessarily touched during updates, and the overall complexity means that on the off chance someone opens their browser’s profiler they won’t see a single obvious problem and will likely proclaim it unfixable and say something like “the DOM is slow”.
I had to upgrade my 12" Macbook because Youtube Music brought it to a crawl. I could play music or work, but not both.
I used a 12" Macbook as my main development machine. It ran IntelliJ with Python/Django applications, Postgres & Redis running in parallel (along with Safari, Mail, etc) around 2018-2020 just fine. Tried it somewhat recently around Ventura and the machine clearly appeared to be struggling with the OS alone. So we had a machine that used to be capable of actual, productive work , and is now seemingly struggling at idl…
I got mine in 2022-2023, so I couldn't tell how it changed. However I wouldn't be surprised. Operating systems used to be much snappier.
I have noticed with two 7 year old Snapdragon 835 devices that RAM and running a recent Android version makes a huge difference. I daily drive a OnePlus 5 running Android 14 through LineageOS and the user experience for non-gaming tasks is perfectly adequate. This phone has 6GB of ram, so it's still on par with most mid-range phones nowadays. My only gripe is that I had to replace the battery and disassembling phones…
I want to research this route more but the camera is an important component to me. I suspect their is a model of phone from 5-10 years ago that has a an under-the-radar stellar camera and I would find "perfectly adequate". ("perfectly adequate" is my favored state for most tech solutions.)
Yeah the camera is the only feature that would really make me want to switch phones. In my case it's more about being a broke CS student without a job lol.
But the low-end device thing still stands. At least here in Argentina where I live most people can't buy a $1000+ phone without going into debt or saving money for a stupid amount of time to get it. Some people that really can't afford to do so still buy them though. Maybe it is reasonable for some but I never saw any appeal in spending so much money (comparatively to a monthly salary) on a non necessity. I happily spent that kind of money on a PC to use for work/study, but a phone? Nah.
Dan'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…
These phones aren't just in the Developing World, though. This is a USA problem too.
I work with parolees and they get the free "Lifeline" phones the federal govt pays for. You can get one for free on any street corner in the poor 'hoods of the USA. They are the cheapest lowest spec Android phones with 15GB data/month. That data is burned up by day 3 due to huge Web payloads and then the user can't fill out forms he needs for jobs/welfare and can't navigate anywhere as he can't load Maps.
The entire "Premature optimization is the root of all evil" notion should be considered harmful. That one idea has completely destroyed the end user experience.
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.
This felt more true a decade ago but there’s been a lot of improvement in both languages (e.g. Rust) and libraries - I routinely see most of the cores on my Macs fully loaded for things like working with media files which used to be single-threaded.
Languages are getting there but based on how much heartburn Rust's async causes, I still find it to be a very hard problem to give programmers a real multicore abstraction. And it starts from the ground up with operating systems designed around single core ideas.
When I first read about the multi core vs single core debate in college, I thought it was silly and that multi core would be just fine. But over the years I've developed a more nuanced view. The average user is mostly doing things that involve IO, so that makes multi core useful in that you can use multiple cores to wait for IO, but for actual computation single core performance continues to be the bottleneck.