> 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.
Ultimately, I don't think that's great for Linux on the desktop. Nobody wants to use a platform where everything is giant battery, memory, and CPU hog.
Lazarus is pretty good, I've used it a few times myself to make quick one-off static executables with GUIs. I don't use it for anything serious though because, well, Pascal just isn't a language I want to spend a lot of time working in.
I wish there was something like Lazarus, but somehow more language agnostic.
>"Pascal just isn't a language I want to spend a lot of time working in."
I do not dwell on "liking/disliking" languages. I use what I use (few languages) for pure practical reasons. To me the goal is to design and deliver end product. Language to me is like a screwdriver. It just has to be good enough to do the job without bending backwards. For making native multiplatform GUI applications Lazarus/Freepascal combo totally ticks the box.
That's fair and also generally how I look at things, but it does mean having to become familiar with yet-another-language that has its own quirks and models and whatnot and, in FPC's case, a complete lack of inline variable declaration.
> And nothing "better" and more practical came out ever since paradigm wise.
I think this is a pretty poor take on the problem. If that were really the case we'd all be using winforms 3.1 (or whatever the original version number was...).
Here's the "Better" that a browser does
- It's got standards and open documentation describing most behavior
- It's got incredibly robust networking code.
- It's got an insanely flexible markup language for describing both what form elements are present, but also how they're visually displayed. (Show me how to do animations in Lazarus... last I looked it was all manual) NOTE: Not only is it insanely flexible, it also is well documented and described by standards.
- It avoided the trap of being GUI first at development time, encouraging an eco-system of tools that generate and modify the text based definition of the GUI you're going to present to users
- It has good separation of concerns. My form elements can be styled completely differently by just swapping out a style sheet.
- It has good (although often underused) A11y support. For most disabilities that you can think of.
- It has first class debugging tools available, supporting a wide variety of environments.
----
That's what the browser brings. Is it heavy? Sure. Is it bloat? Not really.... depends a lot on your use case.
a) animations. yes you have to do it manually in Lazarus. or you can spend few days and write a component which would animate any published property of any component on a form. Will take a few days to write it in a flexible way and not to be ashamed to submit in public repo. I suspect such component maybe written by someone already but since I did not need it I did not research the area.
b) Debugger is a sore point. It is adequate but falls way of behind what you have in browser or in Delphi (commercial IDE Lazarus is trying to imitate). But they're not standing still and it is getting better.
c) A11y - Highly unfamiliar with the subject so you are most likely correct here.
I think the reality is that it's insane bloat trying to give browsers access to native libs. If I could just download and install apps in the browser that weren't sandboxed (don't @ me about PWA's they're not even close) then I think we might actually achieve Java's dream.
Keep waiting for a miracle. Meanwhile native applications solve problem with ease. Sure some applications are totally make sense as browser based but you can't just color everything the same. This dream will never materialize for way too many reasons, including political ones.
After reading their license I would not touch it with the wooden pole. Too bad as it seem to be a good tool. I made couple of demo projects to get familiar but did not proceed any further as I did not want to end up paying one of the most exorbitant license fees for a general development tool.
I'm not really sure what point you're trying to make here.
If the linux version is Electron-based, ALL versions will be electron based. That's the whole point.
If you'd rather not use electron based software, more power to ya - that's your choice. But lets admit that's a luxury that some of us don't have - I'm a hell of a lot happier spinning up slack as an electron app rather than having to run it in a vm, I promise you that much.
I won't knock you for that opinion but I can use VS Code, Spotify, Bitwarden, Discord, Teams, Notion, GH Desktop where not 10 years ago I would have been stuck with either the crippled web versions, running them in a Windows VM, or booting into my Windows partition.
It's fine to hate the tech and wish that someone would come along and make something better but the tools that everyone big and small is using to build apps is cross-platform by default and that's a huge huge huge win for users.
Java applets were one of the first and most visible ways that this was attempted. The user experience of applets was atrocious. Starting up the applet runtime browser plugin at the time would cause the whole system to stutter and stall for several seconds. I'm not sure if it was the single core architecture of the time, but I recall that the entire system would lock up while this was happening. I think that this single fact caused a lot of damage to the reputation of java in the general public.
It did go out of fashion and I'm not sure why that is. I do have some ideas and opinions...
AFAIK, JetBrains builds all of their excellent IDEs with Java + Swing. Old school for sure, but it works great. If I were building something new today, I would definitely consider Java on both the client and server sides.
If the determining factor for whether my product was useful to you is what rendering engine it uses, you were not and will not ever be the target user anyways.
I don't make "social" apps, I'm not in the business of collecting users for the hell of it. Either I provide business value or I don't, and Electron has very little to do with the business value my customers get (although it certainly does accelerate new feature releases, and most of my customers like that).
Whoever told you that Electron means native Linux is lying to you. It's as native to Linux as a web app is native to Windows or Mac; that is: it's just run in a glorified browser.
It's native as in supported directly by the company making the software.
It's not some random 3rd party that's trying to implement a buggy client or wrapper. At risk of being shut down at any moment, and probably violating the company's terms of use. (which is a whole different conversation around the sad reality of interoperable software today)
---
It's native in the sense that I, as a developer employed by a company using it, can easily drop in a linux release without having to have a long drawn out cost/benefits analysis trying to convince PMs that we should do it, because it's not months or years of additional work - it's some manifest file tweaks to get icons in, and possibly some additional signing scripts to be run during the final packaging.
---
It's not native in the sense that it directly uses OS specific APIs, but who gives a flying fuck? Seriously.
I spend 95% of my time in a browser or a text editor already - "Browser with better system access" is just fine to me.
It turns out RAM and disk space are really, REALLY, REALLY fucking cheap. as in - I can get 32gbs of ram for less than the cost of a windows license. So I'll take my linux support, thank you very much. (shocker - I also like mobile web apps, and strongly favor mobile moving that direction as well - For exactly the same reasons).
> It's native as in supported directly by the company making the software.
Except for the times when that isn't true. Elsewhere in this thread people are complaining about how the Logitech software is Electron based but doesn't work on Linux.
> It turns out RAM and disk space are really, REALLY, REALLY fucking cheap.
RAM and disk may be cheap and plentiful, but battery power and bandwidth are not. It's why web apps don't make much sense for mobile today.
Web apps are the default access mechanism for basically everything I do on my phone. And by that, I mean - I open chrome/firefox and navigate to the site I'd like to use.
I have less than 5 installed apps that I use on my phone directly, and those are almost all exclusively apps that need direct hardware access
- Camera
- Phone
- Maps
I also happen to use a few apps to work around sites that are genuinely awful to their mobile users (reddit, for example, is a black whole of dark ux patterns if you open it in a browser without faking your user agent - So I run bacon reader which [ironically] is just another webview running on the device anyways)
Just because web apps are fitting to your current workflows and apps you use, it won't fit everybody else.
I'm just the opposite of you. Just using web to reach HN, and Google, nothing else. Everything I use is native, and I'm happy with all the native apps I have.
Hardware is cheap, network is reliable notion is just an illusion. No resource is cheap and nothing is reliable. I'm in a remote location with 4G network access and, while it's not slow, it's unreliable and choppy as hell (with full bar / excellent reception). Even well-baked and battle tested algorithms and applications (e.g. Zoom, Skype and other similar covid-19 critical, realtime software) choke, shudder and fail with smallest network congestion.
Also, while RAM is relatively cheap, processing power is not. Just because you have fast flash and plentiful RAM on the device, it doesn't mean all is yours. You can't just assume to use all of that.
If that software is running on a resource contained system, It'd be probably confined in a cgroup, and it'd be killed or crashed with OOM exceptions constantly because of this assumption.
At the end of the day, Electron is useful for some stuff, however it's not native in any means. If it was literally native, Evernote for Linux would've been released by now. Tiddly Desktop wouldn't have some silly fullscreen bugs. Spotify Linux wouldn't be a volunteer project inside Spotify. A simple application wouldn't consume as much memory as a full blown IDE with gazillion plugins enabled and written in Java. Visual Studio Code wouldn't need plugin subsets or "Hey, group the plugins you use by language, otherwise memory usage becomes unwieldy" warning. I can go on and on and on.
We have alternatives. We have Qt, GTK, Python compiled with Cython (if you need binary code), heck even Lazarus and WX widgets, and Java. It's unbelievable that JVM is lighter than Electron with all bells, whistles and Hotspot and whatnot. Some of these technologies can adapt themselves to the hardware resource limits of the system they're running on, transparently, with negligible performance impact most of the time.
So, you can tell that Electron is a better RAD tool than Java, but it's nowhere the only feasible tool to enable native cross-platform applications. Electron is lazy. It's the perfect manifestation of MVP meets mock-ups with enough features baked in to allow rapid-fire releases.
I agree that 640K is not enough for everybody, but no resource is as abundant as hydrogen in the universe.
But it means (in theory) the same experience on all plattforms.
And in my opinion, a working linux electron app beats a buggy wine ported version by far.
Because this is usually the choice. The linux market is way too small and unwilling to spend much money, than to justify a common software developer to spend the effort of porting.
> But it means (in theory) the same experience on all plattforms.
That's quite the opposite of native since each platform has a host of unique features and capabilities. Guaranteeing the same experience on all platforms is guaranteeing that you're not using the platforms natively.
Same experience on all platforms. Sure. Nowhere does that imply "a good experience on any one of those platforms"...I am reminded of early (1.4) Java, just an order of magnitude worse.
A tab on a browser the user is already running would cost less memory and CPU.
It's also with chrome super easy to open a page without the normal browser UI that looks like an app add a .desktop file and presto it's an app it would actually be superior in many respects.
Electron is like its own possibly out of data copy of chromium packaged with other resources.
This means that it shares little with the installed browser and will consume 300MB-1GB of ram itself.
I do not suggest a web app is an adequate replacement for a native application but rather that a website may be a superior alternative to electron as it uses fewer resources while providing a similar UI for some applications.
I see both, all the time (where relevant). I understand the hate, so I tend to forget it. Justifying the horrible user experience for cost or "without electron the app wouldn't exits" is something I don't agree with and as such it sticks out more. You might be in the other camp and just have different perception.
The people I see complaining about Electron sound like they never did commercial frontend, and usually bring up stuff like Visual Basic making me think they haven't done frontend in 20 years or done anything non-trivial with GUI (if you actually used VB to build serious apps you'd know where the codebehind and using threads to avoid blocking the UI leads you).
Just a very loud minority. I don't particularly like Electron but compared to the alternatives it's the best choice for a lot of apps (as demonstrated by the success of many apps using it, despite "performance is the most important feature" crowd).
No? I've basically never seen that and I see endless posts like yours.