> 1. Yes, we’re building on Electron. Yes, we are aware of the performance tradeoffs, but have decided this is the best choice for us. We’re shipping Windows, Mac and Linux clients along with browsers with a four-person team — it’s the only good way right now to do that without features taking six months. We’ve modified the screen sharing pipeline in Chromium to reduce latency as much as possible, because with interactive screen sharing, milliseconds matter.
Literally a massively popular post from this week, and all of their comments within are "Well yes, but theoretically VS Code got it to slightly over a hundred megabytes when idle so naturally Electron's perfect."
So you found someone who had a perfectly reasonable explanation for his choice of tools. We started with drivers and now you come with a desktop app example?
Now find not just one (anecdote) but a trend in HN comments that this tool is recommended to be used when it is clearly the wrong tool for the job?
They literally put "why we use electron" as their first point clearly in defense of the expected onslaught of HNers who were going to attack them for it.
> and all of their comments within
A majority of the following posts (with regards to Electron) are negative...
> ust promise yourself you'll eventually quit Electron. Electron is nothing more than a deal you make with the devil,
> Don’t just tinker... make it a grand North Star goal to lose Electron, and make performance your moat.
> It being Electron especially explains why it's so much more resource intensive than the other solutions.
> I hope you'll reconsider as your team grows.
> For me personally, memory usage has been a big concern with the growing number of Electron apps
> Indeed - a key competitor, Tuple, does not use Electron, and as a result I won’t even be taking a second look at Pop.
It's interesting that people on HN seem to be in such an obvious echo chamber but also see themselves as outsiders.
There are thousands and thousands of people on HackerNews and only a tiny fraction of people comment on any given post. Further, the group that does comment on a particular post isn’t a random sample.
Under such conditions, expecting a consistent, well thought out, position from post to post is unrealistic. And not really even all that surprising.
I think it’s fair to say that when people say something like “HN says” or “HN thinks”, they are asserting that a large majority of the comments take a particular side of an issue. Sure, there are many readers who don’t comment, but if they think very differently from the commenters, then they should speak up, because otherwise they don’t really count as part of the conversation.
I can just as well point at that thread and go "Isn't that the type of software HN keeps criticizing for being Electron?". Somehow people see discussions about A vs B and go "HN is totally always for A", despite the only reason you even see A so much is that it's hotly discussed every single time, with plenty people arguing B. And of course that shitty generalization is now top of the thread, instead of something discussing any substance specific to the submission.
The perception is that the pro-Electron group is made up of all the people writing the software being discussed and therefore getting most of the benefits of their choice, while the anti-Electron group is made up of all the people criticizing it for having to put up with all the drawbacks for the end-user (and setting aside the fact that the software may not exist at all if not for those pro-Electron benefits).
However, since lots of software is still being written in Electron and... essentially none of the criticisms and drawbacks of doing so have been addressed, the anti-Electron group feels like they're being ignored. Because they are. So when they make posts about feeling ignored or complaining about having to repeat the same criticisms over and over without any improvement, that's because that's what's happening.
The anti-Electron people are not saying that nobody agrees with them. They're complaining that their arguments are clearly falling on deaf ears.
I suspect there is hope from the electron developers that somehow the platform will start getting less resource intensive.
App developers want their user to have a good experience (I'm guessing). But it isn't great with electron. But its fund one team or fund 3 ui teams (Windows, Mac, Linux) and hope testing gets them all in sync.
Unfortunately there isn't a great cross-platform solution (qt?) that makes everyone happy (or at least not furious).
You also see non-devs saying Electron is fine, and if the complaints were considered is not something you can really tell. Few people deciding against Electron are going to loudly broadcast that "we were thinking about Electron", and if you consider it and decide it's worth it for you despite downsides, well, you are the "bad guy"(TM) anyways.
Can you find pro-Electron comments? Sure, but if you browse any post about Electron you’ll see a lot of “Electron is a disrespect to your users!” comments, whose top reply is “Yes, and also…(more complaints)”, whose top reply is “Electron is the worst in a long line of…”
This kind of “reply-to-agree-and-pile-on” chain happens on HN a lot, but there are certain topics that really set it off, and Electron is definitely one. The commenters are commenting, the readers are upvoting, and what we end up with is an atmosphere where one side of the conversation is clearly getting more engagement.
A driver and a screen sharing/video calling application have vastly different constraints, and what makes sense for one doesn't make sense for the other...
I have to agree with a sibling commenter, you've weakened your case by jumping from a driver to a desktop application. If we follow what I think your implicit reasoning here is, then we need to just throw Electron in the dumpster because there can be no good time to use it/no sufficient defense.
> 1. Yes, we’re building on Electron. Yes, we are aware of the performance tradeoffs, but have decided this is the best choice for us. We’re shipping Windows, Mac and Linux clients along with browsers with a four-person team — it’s the only good way right now to do that without features taking six months. We’ve modified the screen sharing pipeline in Chromium to reduce latency as much as possible, because with interactive screen sharing, milliseconds matter.
Literally a massively popular post from this week, and all of their comments within are "Well yes, but theoretically VS Code got it to slightly over a hundred megabytes when idle so naturally Electron's perfect."
https://news.ycombinator.com/item?id=28223515