Hacker News Reader

Comment by izacus | Hacker News Reader

Well, I'm sure Logitech was sensible like most HackerNews developers and saved costs by using Electron for their driver. This gives you a nice 300MB+ base package to drive the UI with a lot of unneeded code (most likely asking for the firewall permissions) and then additional actual driver download.

I'm sure that allowed them to iterate quickly, hire developers who know nothing but JS to build their driver package and ship the MVP with low costs!

Isn't that the type of software that keeps being defended here? ^^

View on HN

> Isn't that the type of software that keeps being defended here? ^^

No? I've basically never seen that and I see endless posts like yours.

> Let’s get these out of the way:

> 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

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?

a reasonable explanation would have been "it was the best choice for our end users", not "it was the best choice for us"

A reasonable explanation can, of course, be either of those things.

Can't ship code that doesn't exist.

From my point of view, if the code being shipped performs badly, then it may as well not exist.

Whoa that’s deep.

> So you found someone who had a perfectly reasonable explanation for his choice of tools.

Really depends on your definition of "reasonable". I could invoke Goodwin's law :)

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

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.

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

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.

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.

These two things are not mutually exclusive.

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 don't get your point. To reiterate, I'm challenging the idea that on HN you're likely to find stronger support for electron vs against.

GP is challenging the idea that "HN" is a single cohort with a consistent monolithic viewpoint on anything.

I see. I explicitly specified that I was referring to comments I see.

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

> No? I've basically never seen that and I see endless posts like yours.

HN is definitely swarming both proponents and opponents for Electron. While I can understand the appeal of Electron, I'm no way in favor of it.

I think it's because the audience here has both creators and consumers.

I'm both - I fucking love electron.

Do I like the 300mb download? No

Do I like the development language? No

Do I like the apps built with it? Depends entirely on the app.

Do I FUCKING LOVE BEYOND BELIEF that it means linux support is native and present at first release? You bet your ass I do.

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.

No one cares one whit about the battery/memory/CPU requirements of software they can't run in the first place.

And at least in my experience, spinning up a VM to run windows only software is a bigger battery/memory/cpu hit than running electron.

---

I would love it if Electron was better on those fronts (not to mention a few others) but it's good enough for most of my current use cases.

And if they do, there's already ChromeOS. Why use an inferior slapped-together distro for that?

> electron

> linux support is native

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.

native is probably an exxageration.

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.

>unwilling to spend much money

Citation needed.

I think for years humble indie bundle kept statistics and linux supporters were always chipping in well above average.

I know, but would doubt, that they are represantive of the common linux user.

> Because this is usually the choice.

Interesting. I don't seem to be lacking software to do everything I want to do in Linux without having to use Wine.

Also, I've spent more money buying Linux software than any other platform.

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

> It's also with chrome super easy to open a page without the normal browser UI that looks like an app

Yeah that's what Electron is.

> add a .desktop file and presto it's an app

So Chrome has turned the .url into a .desktop and ruined what .desktop means. Neat.

> it would actually be superior in many respects

Few, not many. And those respects are garbage because it's a still a web app masquerading as something it's not.

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.

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.

I have zero troubles shipping Windows and Linux user end GUI made in Lazarus. Single tiny exe. Does not gobble up RAM either.

C++ with Qt also seems like a good choice, although it is not free for most types of commercial use.

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.

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.

Maybe try electron with WASM? :D

(Full disclosure - I don't really recommend this, it's not ready yet, imo)

If you think electron is anything at all like Lazarus, you must never have used Lazarus.

I mean, it's an event based form builder. Same as almost all of these tools (going WAAAAY back, 20+ years at least).

I have not used Lazarus for any serious project, so if there's something particularly novel that you enjoy about it, I'd love to learn!

>"I mean, it's an event based form builder. Same as almost all of these tools (going WAAAAY back, 20+ years at least)."

And nothing "better" and more practical came out ever since paradigm wise. Just insane bloat of trying to marry Browser to a native application

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.

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

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

From that list the only valid points I see are -

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.

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

What is package management like with Lazarus? Are there third-party/community-contributed packages?

> Do I FUCKING LOVE BEYOND BELIEF that it means linux support is native and present at first release?

Not me.

From my point of view, if the Linux version is Electron-based, then there is no Linux version.

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.

... does it mean I won't run your software? You bet your ass it does.

I mean... great?

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

no please dont turn this into a "why i like/dislike electron" thread

edit: ah, too late

Isn't this the problem Java was trying to solve? Why did that go out of fashion?

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.

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.

>Do I FUCKING LOVE BEYOND BELIEF that it means linux support is native and present at first release? You bet your ass I do.

Ironically, this thread is exactly about a Logitech app that doesn't have this.

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

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.

> Well, I'm sure Logitech was sensible like most HackerNews developers and saved costs by using Electron

I'm not here to defend Electron, but most of the things Foone is complaining about would be terrible regardless of what base they use for the UI, and I'm not really sure what Electron has to do with this (or if it's even in use in this case).

The really egregious thing here is asking for a Firewall exemption and not including the base driver in the box. A slow driver with a giant list of dependencies is bad, but it's bad for its own reasons. Electron didn't force the devs not to include mouse drivers in the physical box, Electron apps will easily fit on a driver CD.

See also some of the other complaints popping up in the comment section here:

> I recently bought a Logitech G Pro X Superlight to use as my daily driver on an M1 Mac. [...] Runs as root, [...] requires manually setting permissions on a config file in order to save settings[0]

> Windows Update will download and execute RazerInstaller as SYSTEM[1]

> All of Razer's products are like that. I've been boycotting them since their keyboard wanted me to sign in to use my function keys.[2]

Again, not here to argue that Electron is good, but I don't see how any of the above is Electron's fault -- and I think even if you were happy with Electron, all of the above would still be egregious and unacceptable.

Is the idea that if Razer wasn't using Electron, they wouldn't force you to create an online account and to stay continuously logged in for your function keys to work? I don't think I believe that.

----

[0]: https://news.ycombinator.com/item?id=28274711

[1]: https://news.ycombinator.com/item?id=28274594

[2]: https://news.ycombinator.com/item?id=28275254

I think HP home inkjet printers were the first to do this, over 10 years ago. Somehow any way of finding and installing a driver on windows would pull in a 500MB suite of always-running junk before the actual driver. No electron back then. (I'm still a bit of an electron hater though :)

> The really egregious thing here is asking for a Firewall exemption and not including the base driver in the box.

A million times this. The electron thing is a sideshow. The real problem is asking for too much in the way of security exceptions.

Electron comes with a lot of security exceptions and an insanely large security issue surface. You're essentially running an old unpatched version of Chrome for every Electron app you're using.

> Electron comes with a lot of security exceptions

I promise you that the reason Razer is asking for network access isn't because they forgot to turn it off.

They could be writing this driver in Rust and they would still be asking for these exceptions. Nobody accidentally builds a driver whose sole purpose is to download and install another driver from a remote source.

Just to address your Electron mini-rant:

I've been trying to build a desktop application for the entire pandemic. In my professional work I work on infrastructure products (think software engineering, not DevOps or SRE). My skills are not really outfit for frontend development or desktop development. Shocking stuff, my ineptitude, I know (/sarcasm)

I ended up learning some JS and I wrote a desktop app with the help of a package called Wails for Go. It's electron-like in many ways, but lets me code up a "backend" in go while JS is resigned to doing things it's good at, like UI. Eventually, though, I struck the gold mine. I actually made a native desktop app in Go with an immediate mode package. It looked like shit, but it worked. I then went on to design a command line variant as well.

My chief takeaway after doing all of them: even my native code resembled the patterns found in JavaScript based UI developments. This basically implies "ELM is everywhere" to some degree, even in Frontends that don't explicitly say it. QT's QML is JavaScript that's pre-compiled for desktop. Sciter is the same way. You can gripe about electrons size, computational, and memory efficiency, but the opposite (native programming for UI) requires an order of magnitude of very niche programming that will only be useful for this purpose, of which any cool thing (like syntax highlighting) that you might want to do will need to be done for the first time. Just a quick reminder, again, I'm not really a fan of or regular user of JavaScript or TypeScript.

What I'm saying is, there are tradeoffs to be made. I don't blame a bunch of startups investing in a JavaScript desktop app when you can absolutely produce a stable cash cow with minimal skillset change and leave a handful of teams building independent threads and daemons that JavaScript can pass work off to that it can't do.

> My chief takeaway after doing all of them: even my native code resembled the patterns found in JavaScript based UI developments.

> (native programming for UI) requires an order of magnitude of very niche programming that will only be useful for this purpose

that seems contradictory

The broader patterns are repeatable, somewhat, in that you can see them broad as day. The way these different languages handle state and communication is totally different though, so, simultaneously incredibly niche as well.

Did you see Logitech's previous native apps? Did you think they were better?

Because they really weren't. Hardware companies fail at software is a much longer living phenomenon than Electron.

(I could believe Logitech's current apps are an Electron like technology, but timeframe wise they predate it also, so maybe more like nw.js or similar, this article talks about roccat, which is a different company)

Logitech is absolutely as bad, or worse than Roccat here. I have no legitimate way to get mac drivers for my mice, because they aren't on Logitech’s website anymore. And thanks to mac bs, they don't work out of the box.

You should stop buying non-standard compilant hardware then.

The driver is from Roccat, not Logitech.

> with a lot of unneeded code

I've read this as "uuencoded" first :-) Imagined sort of like trojans obfuscate their code with Base64 but using a more weird encoding this time :-)

> and then additional actual driver download.

I bet you can just steal the driver form the temp dir or from the actual system after it installs and save for future usage.

I doubt the driver is actually written in JS (I don't think that's possible on Windows, Linux, or MacOS). As a client to help configure the driver setup and manage its updates in a consistent way across platforms... is it really that bad?

I use Logitech’s software on three macs, and my honest evaluation is that it gets the job done, but just barely.

Key cons: - Yes, it asks for a firewall rule, which I simply deny with no negative consequences. Still, it’s concerning that it even tries.

- In order to save or backup your settings, you must create a Logitech account, and those settings will be saved on their servers. I would really just like a config file I can sync myself.

- The frequency with which the software needs updates is baffling. On one hand it’s nice to get such support years after the purchase. On the other.. what the hell needs updating on a mouse?

- The software UI sucks. And there’s no excuse for that given it’s just JS.

- Somehow, after reboot Logitech’s drivers are one of the last things to load. So you have to wait over a minute, and sometimes much longer, for you mouse to be able to handle your inputs correctly, which is really frustrating.

Key Pros:

- The software does work. You don’t actually open the config UI very often, so it’s not like you’re constantly running an electron app in the background.

- Let’s face it, the hardware is good enough to overcome the bad software.

> The frequency with which the software needs updates is baffling. On one hand it’s nice to get such support years after the purchase. On the other.. what the hell needs updating on a mouse?

I'm pretty sure it requests an update anytime any Logitech product gets an update, even one you don't own or have installed. A recent G-Hub update where the release notes only mention mice I don't own broke the battery detection on my wireless headset. Now it always says I'm at 2% battery. (Why did I even update?)

That's really good point I hadn't considered. I'll bet you're right.

You don't need to install anything from Logitech to use most of their products.

...Logitech?

Logitech software might be bloated, but it's downright lean compared to the Roccat mouse I just got for my son.

Both Roccat and Logitech are horrible in this regard. I skipped a thought mostly because I had to deal with Logitech crap the latest.

Electron is like 80MB, uncompressed. That isn't really the issue here anyway.

I think far more people here prefer native apps than Electron. I know I do.

"like most HackerNews developers"

What are you babbling on about?

Seriously, I would have assumed Rust, Elm, Julia, D, or Zig if that were the case.

> ...by using Electron for their driver.

Except they didn't use Electron for the driver. They used it for the management UI.

> I'm sure that allowed them to iterate quickly, hire developers who know nothing but JS to build their driver package and ship the MVP with low costs!

Pffft. Imagine thinking that people who choose Electron only know JS. Clearly that's incorrect as many companies choose Electron despite employing a multitude of native programmers. I'm one of them.

Personally, I know C, C++, C#, Go, JavaScript, Python, TypeScript, SQL, Swift and Visual Basic...and I'll choose Electron to build GUIs every time. I also use React Native to build mobile apps. Pure native kits all suck compared to Electron or React Native and on top of their pure suckage you'll have to deal with the idiosyncrasies of each platform you deploy to.

I don't just build them either. I run multiple instances of about 4-5 different Electron apps all day long without issue on an i7-4770, a CPU that was released in 2013, inside of an old refurbished machine from like 2014 or 2015. And that's under XFCE most of the day...but when do I go use my Mac or Windows machines I get the same exact experience from those apps thanks to Electron.

But oh no! 300mb!! Unneeded code on my precious hard drive!

Maybe stop whining and get a bigger hard drive if you can't handle 300mb. And I doubt you've actually looked into many of the native desktop apps that you're running to investigate how much of the code is actually necessary. Let's hear some of the great native apps that you run.

What kind of work do you? I really want to hear about the 100% efficient native-only apps.

People like you are ruining the desktop computing experience. just stop

Reply on news.ycombinator.com