Hacker News new | past | comments | ask | show | jobs | submit login

> 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".




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.


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.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: