Hacker News new | ask | show | jobs
by vmfunction 704 days ago
> In summary: our modern computer's sheer power are camouflaging poor software performance. The difference between using native and Electron apps, is a huge reduction in the upper limit of how many things you can do at the same time in your machine, or having a lower ceiling on how many heavy-load work tasks your system can be doing before it breaks.

Same can be said about a lightweight web page and 'React' with tons routers all in SPA and vdom. Maybe the page is fine when it is the only page open, but when there are other SPA also open, then even typing becomes sluggish. Please don't use modern computer's sheer power to camouflaging poor software performance. Always make sure the code uses as little resource as possible.

3 comments

That brings a Python "performance" talk to mind that I was recently listening to on YouTube. The first point the presenter brought up was that he thinks the laptops of developers need to be more modern for Python to not be so slow. I had to stop the video right there, because this attitude isn't going anywhere.
You know what? I actually believe in having developers work (or maybe just test) with slower computers (when writing native apps) or with crippled networking (when doing web) in order to force them consider the real-world cases of not being in a confy office with top-notch computers and ultra high-bandwidth connections for testing.
I agree with this approach. I used to always have hardware no more than 2 years old and were med-high to high spec. When I helped troubleshoot on my families and extended families devices and internet connection I saw how normal people suffered on slow systems and networks. I since operate on older devices and do not have gig internet at home every web and app designer should have to build or test with constraints.
I think dev containers can help here. You have a laptop that can run your editor, and a browser. The actual build is done on a remote machine so that we're not kneecapping you by subjecting you to compiling kotlin on a mid range machine, but your laptop still needs to be able to run the site.
I totally agree. However, I feel like this is an ageism :-) Are you 40+ perhaps :-)
Heheh no. I'm in my 30s. My opinion comes from experience. I like to travel a lot, and have been several times on trips that brought me to places where the norm is a subpar connection. Taking 30 seconds to load the simplest bloatware-infested blog that doesn't even display text without JavaScript enabled, teaches you a thing or two about being judicious with technology choices.
This is giving me flashbacks to editors of yore; EMACS, Eight MB And Continually Swapping. I remember reading almost the exact same comments on Usenet from the 80s and 90s.
Flashbacks? It’s 2024 and Emacs is still single threaded
It’s also 2024 and you still can’t share JavaScript objects between threads. Do not underestimate the horror that is tracing garbage collection with multiple mutator threads. (Here[1] is Guile maintainer Andy Wingo singing praises to the new, simpler way to do it... in 2023, referring to a research paper from 2008 that he came across a year before that post.)

[1] https://wingolog.org/archives/2023/02/07/whippet-towards-a-n...

And it still performs better than vscode.
That’s not entirely surprising. Emacs’s UI is a character-cell matrix with some toolkit-provided fluff around it; VSCode’s is an arbitrary piece of graphics. One of these is harder than the other. (Not as harder as VSCode is slower, but still a hell of a lot.)
I use Emacs in textmode. It's super fast! But I've also never found VS Code slow, and that's with viewing multiple large log files at the same time
Sure. Just allocate 10x the engineering resources and I can make it as fast and bug free as you like.
Getting the same amount of current engineers or possibly less that actually care and know about performance can work. There’s a reason applications are so much relatively slower than they were in the 80s. It’s crazy.
Anyone that believes this can prove it by taking down an existing popular product with a better engineered and better performing competitor built for the same cost.

I was using computers in the 80s. They did a very small fraction of what we ask them to do now and they didn't do it fast.