5 ms·

It is actually. Software development can either focus on new features made possible by complex inefficient abstractions or can be focused on efficiency in limi

It is actually. Software development can either focus on new features made possible by complex inefficient abstractions or can be focused on efficiency in limited hardware. Focusing on efficiency will always come at cost of reduced features. As long as hardware is not limiting developers are going to focus on new features giving them the edge, when hardware growth slows , performance will become a factor for competition. Customers are today paying for features, when they for performance industry will also shift. Electron has enabled a whole host of apps to become possible despite it's obvious performance limitations. I would rather have those poor performing apps rather than just few perfomant native apps.

Seirdy 5y ago
Rhetorical question: how much e-waste do you think Wirth's Law is responsible for? I personally don't think that people should ever have to buy a new computer until their use-case changes. At most, they might need a battery replacement after a few years. The idea that people need to replace a machine every six years to keep doing the same tasks is backwards. Hardware is, and should be, limiting.
- pjmlp 5y ago
  100% this. All my private computers are getting around 10 years by now. VS, Windows 10, Netbeans, Eclipse all work just fine. Naturally I am not using Docker to start a Python web server.
vladvasiliu 5y ago
The issue with this approach, is whether those "features" are real, actual features improving people's lives or just bs. Slack is a usual target of derision around these parts, for example. I don't use Slack, but my client has me use Teams which seems just as bad, maybe worse. I really wonder what those great features of Teams are that have a chat application lag on an 8th gen desktop i5? And I mean lag for basic UI things, like move the mouse around the list of contacts. When nothing else happens on the computer. I remember when I was younger, at the beginning of the 2000s, I used to chat with friends on whatever IM clients we had at the time. On computers ridiculously slow by today's standards. I used to have a 1.4 GHz Athlon until the late 2000s. Single core. 256 MB RAM. The chat client would never ever lag. I guess we didn't have emojis at the time, but smileys were good enough. I'm not really sure that wasting all these resources on that is such a good investment. There is a noticeable delay between my key press and the character showing up in Teams. Sometimes the characters don't show up in the right order (how's that even possible?! and yes, it only happens in Teams). That's just text. No 4K screen sharing of an AAA game. No live UHD camera with 32 people multiplexed in ultra quality on a 8k screen or whatever. Text. We used to have this down. What happened? What features do we have now that justify this terrible regression in UX?
- seanp2k2 5y ago
  There’s also the latency issue: https://danluu.com/input-lag/ https://danluu.com/input-lag/ My normal desktop has a 240hz monitor and going between that and 60hz is an immediately noticeable downgrade in performance. Why did we accept 60hz as good enough for so long? Even CRTs commonly ran at faster refresh rates. IIRC 1600x1200@90 was what I ran back in the Pentium 3 days on a 21” Sony CRT. We still don’t have useable 4:4:4 4k@120hz on something like a 32-42” screen available. Anyway, I agree that web tech is easy to develop (not that I thought Visual Basic was terribly difficult comparatively) but there are too many layers of abstraction these days. Can we not make sufficiently advanced compilers to make these really efficient? If not, do we need to go back to tinge drawing board with libuv and event loops? Maybe interrupts and manual memory management really were better. Java for GUI apps certainly hasn’t done much to show that it’s a better solution. It’s funny but sad how these days, apt upgrade runs so fast, and compiling kernel modules happens extremely quickly, but it takes 10x as long as it did 20 years ago to schedule a calendar appointment with someone because GCal in a browser is so slow. Slack compared to curses-based IRC clients…woof.
  - vladvasiliu 5y ago
    Well, yes, there's the display latency issue, but I think that given the state of some programs, the display lag is really way, way down the list of problems. I have a 60 Hz display, and an IPS one at that, which doesn't even try to pretend it's fast. Still, my terminal window doesn't lag behind when I type. Teams does, every time. > Java for GUI apps certainly hasn’t done much to show that it’s a better solution. Meh, I use a Jetbrains IDE almost everyday, sometimes even with Rust and pretty much everything turned on. Even on my almost eight-year-old MBP input never, ever lags like Teams does on a 6 core i7 with a "gaming" GPU. It's not as smooth as a Linux terminal, but it's never irritating. > It’s funny but sad how these days, apt upgrade runs so fast, and compiling kernel modules happens extremely quickly, but it takes 10x as long as it did 20 years ago to schedule a calendar appointment with someone because GCal in a browser is so slow. Slack compared to curses-based IRC clients…woof. Exactly. And what drives me up a wall is seeing people being resigned. Some act like they don't even notice this. I guess we may moan until we're blue in the face on HN &c, but if "regular people" don't care, no one's going to do anything about this.
staticassertion 5y ago
> Focusing on efficiency will always come at cost of reduced features. This is probably sort of true, but it's way worse than it has to be. I feel like with just a little more effort, a little bit of a higher standard, we could get massive improvements. Electron is great for the problem that it solved. But what if they'd started from day 1 thinking about performance? Maybe they would have taken a year longer, or whatever, but I'd imagine it could be 10x-100x faster/lighter. Perhaps not, but there's plenty of software where that is the case. The problem then is that someone would release a garbage slow version sooner, and we'd all be using that - and imo this is the more serious issue. When something like electron comes out we need to push back wayyyy harder, the industry needs actual standards. Things like maximum viable latency for UX - it is insane to me that software deployed on extremely powerful systems can have 10s of milliseconds spent on something like typing a character, or even longer! But we have no quality standards in this industry, so it's I guess hard for everyone to say "this is below our standard".
- tompazourek 5y ago
  I like your comment, but I think Electron is only part of the problem. IMHO, the bigger part is that all these apps are built using JavaScript and all the SPA style frontend frameworks. Heavy Javascript-based UIs aren't slow because of Chromium or V8... I wouldn't blame it on them. It's the frontend frameworks and libraries, their design and abstractions, and then as a consequence, how they are used by developers.
  - staticassertion 5y ago
    Yeah, I agree fwiw. I think that most engineers have a very weak idea of "fast" vs "slow". I've met people who think JS is really fast, or that Go is like C++ level speed. And we wonder why software is so slow.
HeadsUpHigh 5y ago
I am yet to see an Electron app do something that wasn't already done by some older app before it with less lag. All I've seen so far are various flavors of the same basic chat/conference features in slightly different pricing models. Or apps that exist just for the sake of claiming something has a native app( while being just a wrap around the website).

Seirdy 5y ago

Rhetorical question: how much e-waste do you think Wirth's Law is responsible for? I personally don't think that people should ever have to buy a new computer until their use-case changes. At most, they might need a battery replacement after a few years. The idea that people need to replace a machine every six years to keep doing the same tasks is backwards. Hardware is, and should be, limiting.

pjmlp 5y ago
100% this. All my private computers are getting around 10 years by now. VS, Windows 10, Netbeans, Eclipse all work just fine. Naturally I am not using Docker to start a Python web server.

vladvasiliu 5y ago

The issue with this approach, is whether those "features" are real, actual features improving people's lives or just bs. Slack is a usual target of derision around these parts, for example. I don't use Slack, but my client has me use Teams which seems just as bad, maybe worse. I really wonder what those great features of Teams are that have a chat application lag on an 8th gen desktop i5? And I mean lag for basic UI things, like move the mouse around the list of contacts. When nothing else happens on the computer. I remember when I was younger, at the beginning of the 2000s, I used to chat with friends on whatever IM clients we had at the time. On computers ridiculously slow by today's standards. I used to have a 1.4 GHz Athlon until the late 2000s. Single core. 256 MB RAM. The chat client would never ever lag. I guess we didn't have emojis at the time, but smileys were good enough. I'm not really sure that wasting all these resources on that is such a good investment. There is a noticeable delay between my key press and the character showing up in Teams. Sometimes the characters don't show up in the right order (how's that even possible?! and yes, it only happens in Teams). That's just text. No 4K screen sharing of an AAA game. No live UHD camera with 32 people multiplexed in ultra quality on a 8k screen or whatever. Text. We used to have this down. What happened? What features do we have now that justify this terrible regression in UX?

seanp2k2 5y ago
There’s also the latency issue: https://danluu.com/input-lag/ https://danluu.com/input-lag/ My normal desktop has a 240hz monitor and going between that and 60hz is an immediately noticeable downgrade in performance. Why did we accept 60hz as good enough for so long? Even CRTs commonly ran at faster refresh rates. IIRC 1600x1200@90 was what I ran back in the Pentium 3 days on a 21” Sony CRT. We still don’t have useable 4:4:4 4k@120hz on something like a 32-42” screen available. Anyway, I agree that web tech is easy to develop (not that I thought Visual Basic was terribly difficult comparatively) but there are too many layers of abstraction these days. Can we not make sufficiently advanced compilers to make these really efficient? If not, do we need to go back to tinge drawing board with libuv and event loops? Maybe interrupts and manual memory management really were better. Java for GUI apps certainly hasn’t done much to show that it’s a better solution. It’s funny but sad how these days, apt upgrade runs so fast, and compiling kernel modules happens extremely quickly, but it takes 10x as long as it did 20 years ago to schedule a calendar appointment with someone because GCal in a browser is so slow. Slack compared to curses-based IRC clients…woof.
- vladvasiliu 5y ago
  Well, yes, there's the display latency issue, but I think that given the state of some programs, the display lag is really way, way down the list of problems. I have a 60 Hz display, and an IPS one at that, which doesn't even try to pretend it's fast. Still, my terminal window doesn't lag behind when I type. Teams does, every time. > Java for GUI apps certainly hasn’t done much to show that it’s a better solution. Meh, I use a Jetbrains IDE almost everyday, sometimes even with Rust and pretty much everything turned on. Even on my almost eight-year-old MBP input never, ever lags like Teams does on a 6 core i7 with a "gaming" GPU. It's not as smooth as a Linux terminal, but it's never irritating. > It’s funny but sad how these days, apt upgrade runs so fast, and compiling kernel modules happens extremely quickly, but it takes 10x as long as it did 20 years ago to schedule a calendar appointment with someone because GCal in a browser is so slow. Slack compared to curses-based IRC clients…woof. Exactly. And what drives me up a wall is seeing people being resigned. Some act like they don't even notice this. I guess we may moan until we're blue in the face on HN &c, but if "regular people" don't care, no one's going to do anything about this.

staticassertion 5y ago

> Focusing on efficiency will always come at cost of reduced features. This is probably sort of true, but it's way worse than it has to be. I feel like with just a little more effort, a little bit of a higher standard, we could get massive improvements. Electron is great for the problem that it solved. But what if they'd started from day 1 thinking about performance? Maybe they would have taken a year longer, or whatever, but I'd imagine it could be 10x-100x faster/lighter. Perhaps not, but there's plenty of software where that is the case. The problem then is that someone would release a garbage slow version sooner, and we'd all be using that - and imo this is the more serious issue. When something like electron comes out we need to push back wayyyy harder, the industry needs actual standards. Things like maximum viable latency for UX - it is insane to me that software deployed on extremely powerful systems can have 10s of milliseconds spent on something like typing a character, or even longer! But we have no quality standards in this industry, so it's I guess hard for everyone to say "this is below our standard".

tompazourek 5y ago
I like your comment, but I think Electron is only part of the problem. IMHO, the bigger part is that all these apps are built using JavaScript and all the SPA style frontend frameworks. Heavy Javascript-based UIs aren't slow because of Chromium or V8... I wouldn't blame it on them. It's the frontend frameworks and libraries, their design and abstractions, and then as a consequence, how they are used by developers.
- staticassertion 5y ago
  Yeah, I agree fwiw. I think that most engineers have a very weak idea of "fast" vs "slow". I've met people who think JS is really fast, or that Go is like C++ level speed. And we wonder why software is so slow.

HeadsUpHigh 5y ago

I am yet to see an Electron app do something that wasn't already done by some older app before it with less lag. All I've seen so far are various flavors of the same basic chat/conference features in slightly different pricing models. Or apps that exist just for the sake of claiming something has a native app( while being just a wrap around the website).