Comment by mysterydip
4 months ago
The computing power available today is such a double-edged sword. We can do so much more so much faster, but then we (including myself in this) waste so many cycles on abstractions and frameworks and layers of libraries to make our development jobs easier.
If the absurd memory prices might have some positive outcome, it will be consumers demanding that all their basic pack of apps are able to run on 16 and even 8 GB of RAM, by means of avoiding those that hog their machines. And consequently (hopefully), developers and their managers being incentivized by market forces to have a modicum of care for performance and not wasting bytes. Dreaming is free...
All Electron devs, let's go back to native-er toolkits! Qt and Slint are already here for proper FOSS apps, while a new generation of research and development on the field of efficient GUI toolkits would benefit us all so much.
>> it will be consumers demanding
But how do I get to express that demand? Asking as a frustrated regular user of excel - excel is amazing software but if your laptop is not in airplane mode, the number of little delays that creep in is wild. It's all seemingly network delays, connecting to onedrive servers when i'm editing a field (why?!), 10s of connections to random microsoft domains as i flick between tabs in the UI (why?!) - each flick incurring a subtle but observable delay.
>> Dreaming is free... All Electron devs
I like your sentiment for sure but i reckon you might be barking up the wrong tree. I'll give the clearest counter example i know of:
When i scroll a buffer in Zed (it's a 120fps editor written in rust that i really want to like) i perceive micro stutters.
When i scroll a buffer in VSCode (an electron app) it's buttery smooth.
I've tried this many times over 1.5+ years of releases. It's a reliable finding on an m1 macbook pro and an m1 imac.
If the slow stack can be fast and the fast stack can be slow, then there's more to this than just tech stack.
I'm so glad it's not just me. M1 MacBook Pro, here, and I quickly gave up on Zed because it felt so laggy to me. Thought it was something wrong with my MacBook (or maybe me).
Most people can't perceive "micro stutters" and many who can don't care. It's a fairly niche feature requirement.
10 replies →
That's because VS Code is hiding everything behind a bunch of non-real-time tricks of perception. Zed is giving you actual real-time feedback.
"Whom the gods wish to destroy, they give real-time data."
The overwhelming majority of the population cannot perceive anything over 90 Hz. Those that can are overwhelmingly skewed towards under 30 years old. Fighter pilots have a floor of something like 200hz for an idea of how rare it is. Just fun info.
7 replies →
This is very optimistic. I see a future where high hardware prices push more and more stuff to the cloud and consumer hardware becomes largely a thin client. Soon doing anything with a computer will require an internet connection because the "local" portion of software will be an electron UI that makes API calls to a server somewhere to do any "serious" work.
I have a T430 that came out 14 years ago that does "serious" work for me. For almost everyone the computers they use are wildly over speced for what they use it for.
1 reply →
Don’t worry - the cycle will reverse again at some point and we’ll go back to more powerful local machines.
3 replies →
Yup. We're going back to time sharing for the majority of people. The terminal will be their dumb phone.
No not going back to a mainframe computing…
I don't think your average consumer has any idea how memory works, which apps are using it, or what a "reasonable" consumption is for a given task.
If things don't work, they will blame the computer. Developers will check and see that their electron app is only using 5GB of memory. They will test on 32GB memory M5 MBPs. Complaints to support will lead to recommendations to kill other apps.
What would make change is if MacOS killed processes above a certain limit, which obviously it would never (and should never) do.
There are a lot of things our devices could do to give users insight into basic things like which apps use a lot of resources, but they don't and it's a colossal failure for everyone (users, people who make efficient apps, pressure on people who make inefficient apps).
iPhone's battery usage screen is a microstep in the right direction, but it doesn't go far enough since the user has to know it exists, then visit it regularly and mentally calculate if the app's energy consumption is proportional to the amount they use it.
Just consider how an app can get stuck in a 100% CPU loop on macOS (Discord/Spotify used to do this to me if they had any animations on screen) and there's literally zero indication to the user that it's happening and which app is responsible. Best they get is that the computer's fans turn on, if it has them.
One improvement would be for the app-switcher view on iOS/macOS to show you the app's battery impact and average memory consumption. Anything would be an improvement.
2 replies →
> I don't think your average consumer has any idea how memory works, which apps are using it, or what a "reasonable" consumption is for a given task.
I had a brand new experience today. I emailed someone explaining to "right-click, then…" and got a reply saying that they are left-handed, so my instructions were not applicable for them.
Average consumers, for the most part, have a magic box. Only when someone is motivated to learn, like wanting to have a better gaming experience or having an interest in media production (or code), is there incentive to learn.
Oh but I have seen totally tech uneducated people saying that they are tired of so many apps in their phones that slow things down. People do notice, and as soon as you start asking around groups who use mid- to lower tier level of Android devices, they do develop a diffuse intuition of what is and what isn't a "heavy" app. It is unavoidable, the cruft and bloat can be observed very visually in some apps that don't care about performance.
> If things don't work, they will blame the computer
Or the single app that slows it down.
To be fair to Apple, their best selling laptop runs on the same chip as their best selling phone, so they are rather surprisingly on the forefront of this efficiency in consumer-facing devices.
Not looked at Slint, thanks for the tip. Qt is OK-ish; things seem to improve on the Mac a lot beyond 6.8.
> To be fair to Apple, their best selling laptop runs on the same chip as their best selling phone
Technically, their best selling laptop has been the MacBook Air for some number of years. Maybe that changes with the Neo, which genuinely runs on a former phone chip, but a slightly older version than what's in their newest phones. Macs are running on silicon that builds on the phone architecture specifically intended to run in larger devices with larger batteries and (in most models, though not the Air) active cooling.
But they do all share a lot of design philosophy around performance per watt, and they're quite good at the moment.
1 reply →
This pressure works for pure software companies that don’t depend on hardware sales and that have competition. Unfortunately not all software vendors will respond to inflated RAM and SSD prices, since there are many important software vendors who have a vested interest in having users upgrade their hardware frequently. Microsoft still makes a good deal of money on OEM Windows licenses, Apple’s App Store and services revenue is built on regular sales of Apple hardware, and Google benefits from the sale of Android devices. The software needs to perform well enough on new hardware to not cause bad reviews, but sluggish enough (or with enough missing features) to motivate users to upgrade their hardware.
Additionally, software is often chosen based on market effects and not necessarily based on quality. If my colleagues use Zoom, then I need to use Zoom to avoid being difficult. If they use Microsoft Office and take advantage of features that LibreOffice and other competitors can’t support well, then I’m pressured to also use Microsoft Office for compatibility reasons.
The only silver lining I see is that these price hikes will effectively freeze current software requirements in the near future, since purchasing power has been diminished. The MacBook Neo has set 8GB of RAM as the standard for casual users. I’ve found that I don’t have a good time on Windows 11 with 8GB of RAM, but 16GB provides more breathing room and 32GB is great. I don’t expect software companies to revert to the days where they needed to squeeze every kilobyte of RAM like back in the 80s and 90s, but I do expect them to be more mindful of the fact that a lot of people will be using 8GB and 16GB configurations through at least the end of the decade.
> All Electron devs, let's go back to native-er toolkits!
They can't. They have no clue how. Electron is all they know and I doubt they can learn anything else.
Also AI clearly hasn't replaced developers since the AI companies are also using electron and generating very buggy software.
In many contexts, compute and memory can be traded. Some apps prefer higher memory usage over higher CPU usage, because it requires less power and depending on the configuration, is overall less slow when many apps are contending for the CPU.
It's a good thing Apple's newest computers are so power efficient, because an industry-wide decrease in RAM bloat could theoretically lead to higher CPU usage and power consumption on average.
RAM prices won’t stay like this forever. If demand keeps up, suppliers will just start producing more.
Yes. Several new memory fabs are expected to come online in 2028, one in late 2027:
https://manufacturing.economictimes.indiatimes.com/news/hi-t...
So I guess the price should come down substantially in about two years.
(Except if the data center demand keeps growing to eat up that increased supply. But at that point the bottleneck might shift somewhere else, e.g. to TSMC and processor manufacturing.)
They're already producing as much as possible.
Building a modern chip fab takes many years, and no one seems ready to take the plunge yet. The existing suppliers are happy to just keep raising prices instead.
Suppliers have ceased to exist in the past decades for building up fabs to satisfy demand and by the time they went online prices cratered. I’d assume is even riskier and more expensive now.
https://en.wikipedia.org/wiki/David_May_(computer_scientist)...
https://en.wikipedia.org/wiki/Andy_and_Bill%27s_law
> but then we (including myself in this) waste so many cycles on abstractions and frameworks
"what Andy [Grove of Intel] giveth, Bill [Gates] taketh away."
* https://en.wikipedia.org/wiki/Andy_and_Bill%27s_law
As a steam deck user I've become very bothered how some games run like a dream while others are unplayable, seeing beautiful games running perfect on the hardware proves it's more than possible, but studios aren't allocating the resources to make things run efficiently.
If anything good comes out of these insane prices I think it will be more effort allocated to efficiency rather than relying on consumers buying x% faster hardware every year.
I did my first ESP32 project recently and was amazed you can get a system that starts up Micropython, then a Wifi AP, DNS, and Web Server in a second or two total and uses less than 512kB RAM. And thats with a high level programming language.
Shouldn't that all fit into less than 64k?
Something I love about this AI era is how we are going to see companies actually focus on performance optimization again.
There’s a reason WWDC was all about apps launching faster on iOS. Apple doesn’t want to stuff more RAM in iPhones when it’s not even a spec sheet their users see or care about.
Apple has historically tried to avoid “spec” unless its a comparative for illustration purposes.
Apple always markets from a “what is the value to a consumer” angle.
So, they don’t usually lead woth “128Gigabytes of storage”, they’ll say “12million photos of your most cherished memories or 800 hours of video in high fidelity”.
Us techy people know what 128G will give us, so the marketing doesn’t land.
This subject gives me sudden nostalgia for the times when Steve Jobs was talking about the front side bus during Apple keynotes.
I bet he hated that he had to talk about it.
> 12million photos of your most cherished memories or 800 hours of video in high fidelity
Or 3 modern Electron apps.
It's been nice that they don't have to play the specs game. Back when pixels were scarcer, it was like iPhone 4 720p video recording vs Nexus or whatever 1080p video, yet the iPhone's video was clearly better quality. Or the Apple Silicon chips have faster RAM and disk access that don't really get noticed in spec sheets or benchmarks.
Do you really think we'll have optimization in an era of metrics encouraging developers to approach shipping a million lines of code a month?
The tradeoff isn’t dev job easy vs better performance. The abstractions allow devs to build faster or work on things users care about instead of unobservably better performance.
Oh, you mean those shitty Web UI frameworks with worse performance on modern hardware than native GUI programs from 1995?
Back then devs were not taking shortcuts, it was the C API or bust, and it very much shows how far we have regressed.
Oh no, the devs back then were for sure taking all the shortcuts they could, there just weren't as many ways to leave problems for the users compute to solve.
C API was a shortcut. Extensive use of C was a sign of a lazy programmer who wouldn't send the time to write in assembly, which was much more efficient and performant.
I'd love if everyone that made noise about this would put their money where their mouth is and just do it. Make better alternatives to the slow bloated shitty software you decry, and reap the inevitable benefits since it's what users actually care about.
> instead of unobservably better performance
That's... quite the choice of words there
The problem Is when the performance problems becomes observable. Only after a specific scenario like low power mode for example
> The abstractions allow devs to build faster or work on things users care about
I care about native macOS look and feel. Sadly the entire industry has pretty much decided that this is no longer worth the effort. I miss the days when Mac users demanded more from their apps, even if it meant that some apps were not available for the platform.
> instead of unobservably better performance.
It's imperceptible because the hardware has gotten so much faster. This would be like a top fuel dragster the size of a freight train.
The engine is incredibly powerful but the overall performance is hindered by the size of the overall vehicle not being optimized around it.
> work on things users care about
Apparently what users care about is having more whitespace around everything.
[dead]
Which is such a capitalist lens to look at things through. Optimizing for a very small window of reality.
It's the same sort of optimization that drives behaviors where corporations feel no need to contribute to open-source projects. The same projects that enabled those very corporations to exist.
Also it's no longer a toy for hobbyist but a necessary tool to participate in society
Yeah, I recently went to the DMV, the only way to even get a place in line in person was on a phone. Also needed some kind of web browsing device to get basic online-only services.
The problem isn't the necessity of a computer to participate in society, as those are everywhere in public for free(My library and unemployment office has PCs free to use), it's the mandatory need for smartphones, as the library has no public smartphone to borrow you.
Sometimes abstractions make performance better too. We can’t all be experts of everything so using a well-optimized library is a boon.
Even beyond the library scope. I suspect most complaints in this regard are around electron/web tech, but a well developed modern C#/dotnet application is plenty fast for most use cases and you get the productivity of a high level GC language with it. Go has even a smaller footprint.
There's plenty of value in the abstractions. It didn't all start to break down until we collectively decided that javascript + chromium is the only way forward for literally everything.
not even that. you spend most cycles on thing you 1. don't want, 2. don't benefit from, 3. don't even know about.
your phone doesn't even need mention (whatsapp request the full contact list from the OS every minute. nobody knows that. google play service usea your phone as a WiFi scanner etc)
your browser churn proof of work every site you visit. cloudflare now probably waste more power than btc (and they don't save your site from bota, only set the bar at bots-willing-to-pay-to-run-canvas-fingerprints or something)
Yes, when you're used to using the modern web with all its bloat it can be a huge surprise when you build something in C or Rust - everyday computers are actually incredibly powerful.
I'd say some of those extra abstractions and frameworks are actually making many jobs harder.
Would love to elaborate, but need to get back to work migrating a jekyll site to astro
"Hey Opus, migrate this site from jekyll to astro" doesn't work?
On one of my machines I run Trisquel Linux (one of the FSF approved distros). In part is because in order to running fully FSF approved hardware, a Lenovo T400 is the top end. It is a Core 2 Duo with 4GB of RAM. With that, it is still a very functional unit as a lot of the bloat hasn't crept in outside of the browser.
Fully agree with you. I am a frontend developer. On my work machine spotify uses maybe 300mb of memory, but on my home pc with opensuse? Image what it uses... 1.1GB.. The same as my brave browser with 4 tabs open. What is going on.
I imagine your work machine, just like mine and everyone I've ever had, has application level limits to how much resources it can consume, spotify picks up on the limits, and adjusts accordingly?
As to what its doing with all those extra resources on your linux box... shrug maybe using your laptop to train its models or mine crypto?
Because so much modern software is a web browser. The application bundles in its own version of Chromium.
Built natively, the same app could use an order of magnitude less memory, while being functionally identical.
That doesn't explain the discrepancy
I mean, why even use spotify?
I like music, and i have a diverse taste.
a single leetcode tab is taking up up to 700mb of memory...
It's interesting to contrast this with the attitude taken by the FFmpeg open source developers. They still hand write assembly code because performance and power efficiency is so critical that every clock cycle counts.
https://lexfridman.com/ffmpeg-transcript#chapter14_assembly_...
Something being easier is not a waste, it’s literally the purpose of every technology.
"What Andy Giveth, Bill Taketh Away"
It’s not Bill any more, it’s developers choosing to use Electron as an app development platform. It all seemed fine when 64 GB of RAM was cheap.
[flagged]
> This is such a reddit take
You might consider that your comment would have been just as strong without the opening put-down.
I was going to upvote the parent in agreement, but decided the put-down was uncalled for. "Reddit take" itself sounds like some jargon from Reddit, wouldn't know though.
I found it interesting commentary… must’ve been because I wasn’t its target!
Maybe “common myth I’ve noticed spread on reddit” would work.
4 replies →
I'm fine with Electron, not so fine with basic websites being so bloated now that even a modern computer lags on them. Those were achievable in the past.