I know some people think Electron is cancer[1], but it is the fastest way to write cross-platform applications. I've been trying to learn to make apps for macOS, and it feels like even Apple doesn't want me write apps for the Mac.
Been using GColor2 forever on Linux. And I believe there are others.
Don't really see how this improves it. I use Mac OS as well but I don't miss the color picker from Mac OS when I'm using Linux, not sure what his problem is. Or the attitude in general, I wouldn't want to be running something showing at all times such a cute name on screen. No thanks.
I'd like for people to drop the whole 'x is cancer' thing since aside from the actual fuckery of cancer most things aren't that bad. A little too flippant imo :)
Is it actually faster to develop in Electron than with QT and C++?
It has been over a decade, but I remember it being both straight-forward and pleasant to support Linux, Windows, and MacOS. I vaguely recall supporting Solaris too.
As a C++ developer who had to learn Javascript and Vue to write an Electron app, it was still faster than writing the same app in QT (which I used before).
I just realized this morning that JavaScript is the new Java.
js targets the browser (angular, React...), the back-end (node), the desktop (Electron) and mobile (React native). Just like the Java of old with applets, javax, JME, and of course weblogic and friends, js today allows you to code anything, as long as you don’t mind doing it badly, insecurely and/or wastefully.
Due to this ubiquity, a large majority of job openings list js in one form or another as a prerequisite (remember when entreprise code was synonymous with Java?)
Once you know enough js to be dangerous, there’s little incentive to pick up another programming language.
That's a good comparison, and I think I should qualify my statement. It's the fastest way to develop cross-platform apps when you already know web development. I've only done some trivial apps with QT and Python, and it was pretty straight forward. The UI didn't look as nice as it does with Electron. I'd be interested to hear someone's opinion who has real experience with both.
To be fair to Electron, Qt is an enormous dependency as well. Not as memory hungry at runtime, but Qt 5.12.1 frameworks for macOS are over 260MB. Granted, Qt is at least modular so you don't necessarily need them all.
However, given macOS apps don't really support shared libraries (at least in the typical sense), it adds up pretty quickly if you've got a few Qt apps.
Those are compressed figures (.tar.gz). Decompressing the OSX 64-bit runtime frameworks from there yields 85 MB. Which is less than the figure I had, but I believe is roughly in the same ballpark as the Electron runtime[1].
My original figure was probably debug frameworks (it's whatever Homebrew installs by default). However, I'd already excluded the tooling.
As someone who wrote GUI apps in most of the frameworks, starting with raw Win32 and MFC, yes, doing a GUI in Electron is massively faster, especially if you use modern frameworks like Vue or React.
> it is the fastest way to write cross-platform applications.
I disagree. Maybe that's true if you're a webdev unwilling to learn anything else, but Lazarus is the fastest way I've found to write cross-platform GUI software, and as a bonus it compiles to native code in a single executable.
Also, xmag, you already have it installed if you use the X Window System. It's 41kb, extremely lightweight (always starts instantly) and also magnifies a screen portion which is helpful for picking colours.
> you already have it installed if you use the X Window System
Maybe.
It looks like it's been spun out into `x11-apps` on debian based distros in the last year or two, and for some reason I don't have that package installed despite using X
It's a HTML + Javascript desktop application that weighs 2 K. And it even uses native widgets and looks and feels like a real application. Isn't that something... ;)
Yes, this 450 line program could have been written in whatever native language you want with probably 3x the code and time spent, but why would you? Developer time has been more expensive than hardware for a decade now.
Everyone here loves to virtue signal about how horrible programs that take 0.01% of the space of a normal SSD and 1% of the RAM are, but the fact is that it does not matter at all, and you wouldn't even have noticed if you hadn't intentionally looked at the size of it.
> Everybody who works on a cross-platform version of a generic utility has potentially many millions of users.
Not the same thing. And other threads have established there are already popular color pickers this would be competing with if rewritten in a native lean style, that this would first need to take mindshare away from as well.
I'm going to assume the answer is "no, this does not currently have a million users".
> Nobody knows.
We can make reasonable guesses. For one, I bet the author can get hired to work on a codebase that actually has a million users, not any of this "potentially maybe in the future" stuff. For another, I know for a fact that many of those codebases - even the native ones - have bigger perf problems, and a lot more room to optimize towards the ideal.
I'm going to assume the answer is "yes, that developer time can be more efficiently used."
> But it's obvious that wasting resources like this is going to scale with every user.
This we can agree on. But there's an opportunity cost[1] to fixing that. Going to the root of the hosting site, it clearly states the author is a webdev, so "fixing" that in the "let's not use electron" sense might involve learning Rust or some other native language first. That's not insignificant. And then you're competing with other already existing perfectly functional native color pickers... so are you actually saving significant hardware costs?
> I'm going to assume the answer is "no, this does not currently have a million users".
You can spend all day asking irrelevant questions and answering them yourself, it won't get us anywhere.
The point is that "developer time is more expensive than hardware" is not a valid argument from the user's perspective. As you can see from the complaints here, people already find the color picker less attractive because it uses wasteful Electron. It's not a good product, regardless of how cheap it was for the developer to produce and will be less successful as a result.
You don't need justification for developing something that isn't good because of wrong or selfish priorities, but you'd better accept that success of your product and its environmental footprint depends on these priorities too.
> You can spend all day asking irrelevant questions
We're discussing how dev time is best spent in service to the end user (and environment.) It's absolutely relevant.
> The point is that "developer time is more expensive than hardware" is not a valid argument from the user's perspective. As you can see from the complaints here, people already find the color picker less attractive because it uses wasteful Electron. It's not a good product, regardless of how cheap it was for the developer to produce and will be less successful as a result.
Things the end user does care about include features, price, and the actual existence of the end product, all things I see frequently sacrificed by the "maximum efficiency at any cost" crowd, because they're misallocating dev time. They aren't even optimizing the actual efficiency bottlenecks half the time, just micro-optimizing some unimportant edge case.
You're right that the discussion doesn't matter to the end user, but that doesn't mean it's the wrong decision. As you can also see from the posts here, not everyone is convinced it's a big deal either. People are constructing strawman arguments "these devs and their 4k monitors and 32GB+ machines", but I'm using electron apps from an underpowered 8GB laptop just fine.
Yes, if you're traveling and downloading it over a mobile connection, it'll take a hit. Yes, I'm sure you can find a worse laptop than mine, and if you search hard enough you'll even find one where the fact that it's an electron app will be a problem. Yes, you can spend more resources to make a better app - that's always true, the question is where diminishing returns make that no longer cost effective. Yes, if there's no outlets nearby, it won't stretch battery life as far.
But no, I'm not convinced that calling it "not a good product" as a result of being an electron app is quite right either. Not the best product it possibly could be, but no product is.
> You don't need justification for developing something that isn't good because of wrong or selfish priorities,
Nor am I convinced there are wrong or selfish priorities in using electron. What, exactly, is wrong or selfish with saving dev time to work on something more important to the end user? Even if that's another product entirely?
> What, exactly, is wrong or selfish with saving dev time to work on something more important to the end user? Even if that's another product entirely?
It's simply completely irrelevant what the developer might or might not be working on also in your imagination, when we are judging the product based on its technical merits.
Inventing some extremely important better use of the developer's time to justify inflicting a wasteful 55MB download on the world, is a strawman argument of the same quality you complained about.
I deal with programs that crash OOM on 32GB+ machines. I deal with products that actually have a million users, with gigabytes of download. I don't need to invent anything that the developer could be working on, existing problems to work on are abundant. And I don't even work on anything important! But more important than this color picker? I'm pretty sure you could think of concrete examples of that too, without resorting to imagining anything.
And if we're limiting the discussion to just the technical merits of a product, I'm not sure why you started discussing developer time and expense at all. You're the one who brought up "dev time vs millions of users hardware", and I'm just pointing out that it's perhaps more realistic to view this as "dev time" vs "thousands of users hardware" in this particular case, and that there's a lot of mildly important things the developer could work on instead.
Ah yes, the good ol' "Efficiency doesn't matter on my hardware in my situation" argument. Brought to you by the same culture that ends up with devs being surprised most of their users in fact don't have 8-core 32G machines with 4k screens, unlike all of their colleagues and immediate peers.
For that matter, I did notice the size, as I'm browsing on a mobile connection (travelling) and the 55M color picker utility would take a bit over 2 minutes to download.
I would in fact argue that until we are at a point of diminishing return of improving hardware that it is good that software is becoming more and more "bloated", because that's the only incentive to keep researching more efficient hardware.
Phones for example have basically been unchanged for 5 years regarding performance, because while hardware has drastically improved the apps have become heavier in proportion for superficial new features. Same goes for internet connections.
As another example I'd say that the recent resurgence of deep learning has mostly come from (or at least was catalysed by) cheap, affordable GPUs, which only exist because gamers wanted better and better graphics.
> we are at a point of diminishing return of improving hardware
We're already at the point where hardware is marginally increasing in efficiency year-over-year for most purposes. We've been there for like, 4-5 years now. Chips created on high-end processes are already expensive to the point there's no immediate cost-savings to be had from them, only power savings. Twice as dense, twice as expensive, marginal performance improvements. Years of development.
That's due to physical laws of nature, not because we suddenly started writing way, way better software and therefore hardware engineers decided to slack off for the past 8-5 years or whatever, after year-over-year doubling in the prior decades. Your lunch was never actually free, it's just that Bill down the hall has finally stopped paying for you every day, because he's starting to go broke and has to tighten his belt.
> that it is good that software is becoming more and more "bloated"
No it isn't, you only think that (and justify it with a speculative argument) because it lets you justify externalizing the costs of bloat onto someone else, ignoring any other concerns -- your users, your cloud provider, your hardware vendors, etc who all pay for the energy and time you wasted on their behalf.
> that's the only incentive to keep researching more efficient hardware.
No it isn't, this is just more baseless speculation to support your point.
> Phones for example have basically been unchanged for 5 years regarding performance, because while hardware has drastically improved the apps have become heavier in proportion for superficial new features.
I don't see it. The latest version of iOS is (apparently) such a big performance improvement that its performance got top billing as a "Feature" from Apple [1]. They brag about how it's ~50% faster at several common tasks.
Why is everybody always so concerned with developer time, but never with user time? The author of this tool even complains about the startup time of photoshop, but somehow has no problem with building a tiny tool on Electron. The irony is quite strong here.
I had become so used to just grabbing color values from any old pixel on the screen..., but on Windows the best way I came up with was to take a screenshot, wait for Photoshop to open, then get the color value through the PS eyedropper tool. That took probably 30 seconds to get a single color, since Adobe software is somehow still dog slow on brand new hardware.
You can do the same thing in MS Paint and save yourself 15 seconds.
I think this is more down to Apple style workflow than actual requirements.
With Apple you have to do things the special Apple way because Steve Jobs said so.
On Linux I am not thinking 'oh, where is my system wide colour picker and getting irate because there isn't one'. The colour picker works fine in the image editor program, with the browser add on I am covered for practically every use case.
Sure I had to add the browser extension and would be stuck without it, but my thinking was to get the browser extension rather than even think to install an OS widget.
I can't say that I have had a genuine need for a OS level colour picker ever. It is just not something needed. And no, just because I am not on an Apple machine does not mean I don't do anything 'creative'.
With Linux there are plenty of colour pickers already out there, 'pick' is very neat as it gives you a little screenshot of the context of where you got your colour from with a sensible colour name given too (albeit not a standard X-Windows style one, so you get 'Hot Cinnamon' instead of 'chocolate').
> A dev missed some feature of their usual OS and so wrote a cross platform version open source in their spare time.
So what matters is the "why" and the "what", and we can just forget about the "how"? Engineering is all about the how we do things, and HN tends to have more engineers than your typical online community. What's wrong with that?
That isn't the problem. The problem is the community, and the effect Electron is having on it.
Cross platform application development is considered a "solved problem" with Electron, and it's developed a cult that leads people to disparage native applications and native development as inferior in all cases, as if Electron were already the best possible solution rather than a hack around webdev that blew up because of the SV hype machine.
Because of this commoditization around a single language and a single framework (mostly by corporate interests, mind you,) curiosity and innovation are halted in favor of developer time efficiency and resume visibility. No one is even going to bother trying to create the next cross-platform application solution after Electron, because they would only be able to do so in Electron.
If anyone is put off by it being an Electron app and are running Windows, here's an AHK[0] script to get the hex code of the pixel color under your cursor and copy it to your clipboard:
---
#h::
MouseGetPos, MouseX, MouseY
PixelGetColor, color, %MouseX%, %MouseY%
StringLower, color, color
clipboard := SubStr(color, 3)
---
It's bound to Win+h (hex color) by default.
It's not fancy, but it works. You just run it in the background and hit the hot key to copy the color whenever you want to. There is no UI.
AutoHotkey is amazing. It's a little gem of a Windows app. I only wish I discovered it earlier, when I was still using Windows as my main OS.
AHK can be used to trivially fix many usability warts you have with random software, and is powerful enough that someone implemented a clone of dwm tiling window manager in it (bug.n, [0], I used it for more than a year and can attest it works very well).
I'd go as far as saying AHK is one of the few tools on Windows that I really miss when on a Linux system. It's that good and I don't even know it too well, I just hack things together as needed. Bash is great and all but AHK does so many useful GUI things.
Thanks for the link on bug.n. I use i3 on my Linux laptop and for day to day usage I do prefer a tiled window manager of some sort. My Windows box is my main workstation so having some type of proper tiled wm would be really nice. Currently I use dexpot (virtual workspaces), AHK (global hotkeys), keypirinha (fuzzy find app launcher) and the built in Win 10 window split shortcuts to get as close as I can to an i3 set up.
AutoHotKey is great and the kind of thing that should just be built in to desktop OSs. Why shouldn't I just be able to assign any key combo to anything, contextually? Why do we have to rely on applications supporting hotkeys at all?
Oh? What is the Linux equivalent? I'm aware of KDE having a hotkey system but from what I recall it didn't allow you to bind keys to scripts or contextually. Maybe there's some X component I'm not aware of? That's nice, probably doesn't work in Wayland. Of course in Wayland such things would be left up to the compositor.
"Linux" isn't the only other OS either (and here doesn't quite make sense, seeing as it's a userland detail that doesn't really have anything to do with the kernel the distros share). Apart from the ability to change the keybinding dictionary for basic stuff like copying and pasting and such, Automator on macOS lets you pretty much bind anything to anything.
It was something I whipped up in 5 minutes about a month ago when I really wanted a quick and dirty color picker. I do use it in practice.
One shortcoming is it doesn't visually show the color after you copy it, but that could also be done with AHK. You could totally have it show a small 16x16 window with the color which would disappear after 2 seconds and would get refreshed after you pick a new color if it were still visible.
You could even go 1 step further and change it to zoom around your cursor on key press, and then copy the color on mouse click while showing a 16x16 window color preview on hover. That would be the ideal solution, but something like that might be 3-4 hours of hacking around with no real AHK knowledge instead of 5 minutes and that wasn't worth it to me at the time.
Of which the runtime is about 120.3 MiB. There is even a copy of ffmpeg (2 MB) for the rare occasion when you want to play back an mp4 video in your color picker.
The actual app itself is in the resources directory which is 1.8 MiB large.
This directory contains files electron.asar (214 KiB), app.js (1.7 KiB), package.json (727B), and directories static (152 KiB) and node_modules (1.4 MiB).
The actual content created by the author is in app.js, package.json and static, which together take 160 KiB, of which 52 KiB is the logo (would have been much smaller as SVG) and 68.8 KiB a bundled font.
In the node_modules directory major contributors for size that I see are:
* node_modules/tinycolor2/demo (288 KiB; largest contributor here is a jquery copy)
All of the stuff I listed above is quite redundant for the users who just want to run the app. If you remove them, the 1.8 MiB become 764 KiB for the entire app and I'm pretty sure that minifiers, bundlers etc. could make it even smaller.
The runtime could be provided by the OS. I think it's definitely possible to create apps < 500 KiB with web technology, it's just the deployment patterns that turn this into a major download of 122 MiB. As for the RAM usage, idk about that. I guess if the runtime is provided by the OS, it would be the same electron binary so the OS could share that one at least.
What´s the problem with this? I have enough space on my drive. Sure the app is bigger but it´s platform independent and works flawlessly. Native apps crash often, use big os dependent frameworks (you have to install sometimes) and only to have a smaller bundle? I don't get it.
The problem? When you start to have 5-6 apps running with Electron in the backend and start to take 10% of your CPU time and 2 Gigs of RAM, you will start to feel how it impacts your working environment, battery life and all.
On a serious note: I never understood why people tell me to buy better hardware to compensate for the shitty performance of their software. No, fix your software!
Nah dude this line of thinking got us here. We need to reach back to what the OG's in computing thought about. Small size, fast performance. Limit ourselves.
I read about this dude who purposely writes software on a shitheap laptop just so that "if it's fast here, it's fast on modern mobile phones."
Even my app written in Elixir and uses 160MB of RAM after letting it run for a week; I've been thinking: "Maybe I could bring it lower to what nzbget uses (around 59MB)". I've been exploring Nim for that.
It is about having a color picker (probably just a few lines of code) bundled with quite a set of dependencies and complex chromium runtime environment which does not get updated regularly. Therefore they keep their vulnerabilities even after they are known and fixed in later versions of the dependencies.
With small footprint applications, you are less likely to have such problems.
My app does very little and is meant to be self-hosted for your own use. Or are you talking about Elixir or Nim as a language?
Edit: Oh I get it you actually meant:
"Hehe, kinda funny when your application written for Electron comes with more security vulnerabilities than it has lines of code for its own logic ;-)"
Every native app I've used works everywhere I've used it, every time as well.
That native apps were wildly unstable, or that it was impossible to find native apps that ran on different platforms before Electron is a myth. Electron didn't solve those problems, because they weren't problems.
Electron solved the problem of "how can I, a web developer, run a website on the desktop but make it seem like a native app and call myself an application developer?"
First, this is a false dichotomy. There are alternatives to Electron that don't require a 120 MiB runtime and don't involve using the OS APIs directly.
Second, this is not a criticism on application writers, but on Electron itself. It could use a runtime available on computers (virtually every computer has a browser) or, at least, a shared runtime that would download itself.
Bundling a browser with EVERY different app is not only a waste of space and of RAM, but also a security issue: now you have to wait for each app developer to update the app in case there's a security problem with Electron, Chromium or any of its 2000 dependencies, and that's "if" they upgrade. And that update takes at least another 120 MiB to download, for each Electron app you have.
Instead of downloading 120 MiB for each app, each app could come in a small package and only download the runtime if it's not available in the computer yet. Java got it right in the 90s, .NET got it right in the 2000s, although downloading the runtime had terrible UX for stupid marketing reasons (you had to provide e-mail to download from the Sun or the MS website).
Nice breakdown of wasted resources.. It's frustrated me for a long time how people are carelessly bundling unused code, which is unfortunately common in JavaScript-land.
Including only the bundled/minified app is possible, leaving no node_modules folder at all - or, at least, just the native binaries needed.
As for bundling the whole Electron runtime on every app: technically it's possible to have a shared runtime - as this 3-year old issue shows, many people have attempted various approaches: https://github.com/electron/electron/issues/673
However, sadly no one has stepped up to come up with a general solution. While there are disadvantages and some reasonable arguments for bundling the exact version of the runtime required by an app, it seems efficent use of resources isn't enough of a priority..
I'm not sure what it is about the node development environment but you are right. I haven't seen such wildly complicated dependency trees in any other language. Literally hundreds of modules can come together to make even simple applications.
Is there an idiom or ethos in node land that aims for tiny re-usable packages? I am not criticising if there is, just genuinely curious.
I have been writing JS applications for years and it's only since node and npm hit the scene that this has occured.
It might be the Unix philosophy taken to its logical extreme. Everything should do one thing and do it well. So now we have libraries that are literally a single function.
Here's the thing though: You could build this in pure Node and call Windows APIs, Qt, etc and it'd be much, much smaller.
But everyone just goes ahead and pulls in Chrome.
It's shameful, and the worst part is that I get it - at this point I'm suggesting we go to Electron for a new application at work because it seems like the best maintained UI frameworks with readily available 3rd party components are all web based.
I find it darkly funny that Electron is the new size/waste-of-resources whipping boy. Java applications generally suffer the same issues with the exception that the runtime isn't usually distributed with every application. But the goal of write once, run anywhere is basically the same.
Now that Java is being developed at such a speedy clip at the cost of breaking changes, we may see Java runtimes being shipped with apps. (I'm personally still on Java 8 because that was the last release before drastic breaking changes started happening.)
Just kidding. Java has been abandoned in favor of web apps anyway.
139 comments
[ 2.5 ms ] story [ 185 ms ] thread[1]:https://medium.com/commitlog/electron-is-cancer-b066108e6c32
Don't really see how this improves it. I use Mac OS as well but I don't miss the color picker from Mac OS when I'm using Linux, not sure what his problem is. Or the attitude in general, I wouldn't want to be running something showing at all times such a cute name on screen. No thanks.
It has been over a decade, but I remember it being both straight-forward and pleasant to support Linux, Windows, and MacOS. I vaguely recall supporting Solaris too.
js targets the browser (angular, React...), the back-end (node), the desktop (Electron) and mobile (React native). Just like the Java of old with applets, javax, JME, and of course weblogic and friends, js today allows you to code anything, as long as you don’t mind doing it badly, insecurely and/or wastefully.
Due to this ubiquity, a large majority of job openings list js in one form or another as a prerequisite (remember when entreprise code was synonymous with Java?)
Once you know enough js to be dangerous, there’s little incentive to pick up another programming language.
edit: u/781 has some experience with both and says Electron was faster to develop, his comment is below: https://news.ycombinator.com/item?id=19652691
However, given macOS apps don't really support shared libraries (at least in the typical sense), it adds up pretty quickly if you've got a few Qt apps.
That includes all the tooling/headers/.a/etc.
See this for the accurate size for the Qt runtime: https://github.com/qmlnet/qt-runtimes/releases
Windows - 43MB
OSX - 32.2MB
Linux - 57.6MB
My original figure was probably debug frameworks (it's whatever Homebrew installs by default). However, I'd already excluded the tooling.
[1] https://github.com/electron/electron/issues/2003
But yeah, 85MB for a complete UI runtime seems entirely acceptable to me.
See Qml.Net (https://github.com/qmlnet/qmlnet), or PyQt.
It isn't replacing app dev. It's adding more app developers.
I disagree. Maybe that's true if you're a webdev unwilling to learn anything else, but Lazarus is the fastest way I've found to write cross-platform GUI software, and as a bonus it compiles to native code in a single executable.
And for size fetishists: it weights 42KB.
And the EXE is only 32 KB when UPX is applied on it. And uses only 1 MB of RAM when running.
Maybe.
It looks like it's been spun out into `x11-apps` on debian based distros in the last year or two, and for some reason I don't have that package installed despite using X
[1] http://www.nattyware.com/pixie.php
There are a couple of other cool tools on the page too that I weren't aware of, like this:
http://www.nattyware.com/fontster.php
It's a HTML + Javascript desktop application that weighs 2 K. And it even uses native widgets and looks and feels like a real application. Isn't that something... ;)
http://colorcop.net/
http://www.iconico.com/download.aspx?app=ColorPic&type=free
http://www.youngsmarts.com/download.htm
... and so on.
Also, opening up Photoshop for the color picker? Paint opens faster than I can blink and has a color picker.
[1] https://electronjs.org/apps/colorpicker
I'm absolutely sure it is possible to write the same cross-platform app for less than 500KBytes and no dependencies.
Everyone here loves to virtue signal about how horrible programs that take 0.01% of the space of a normal SSD and 1% of the RAM are, but the fact is that it does not matter at all, and you wouldn't even have noticed if you hadn't intentionally looked at the size of it.
How about developer time of 1 person vs. hardware (and electricity, CO2 emissions...) of 1 million users?
Do you actually have a million users? Can that developer time be spent saving even more hardware or human costs elsewhere?
Everybody who works on a cross-platform version of a generic utility has potentially many millions of users.
> Can that developer time be spent saving even more hardware or human costs elsewhere?
Nobody knows. But it's obvious that wasting resources like this is going to scale with every user - even non-users who just download out of curiosity.
Not the same thing. And other threads have established there are already popular color pickers this would be competing with if rewritten in a native lean style, that this would first need to take mindshare away from as well.
I'm going to assume the answer is "no, this does not currently have a million users".
> Nobody knows.
We can make reasonable guesses. For one, I bet the author can get hired to work on a codebase that actually has a million users, not any of this "potentially maybe in the future" stuff. For another, I know for a fact that many of those codebases - even the native ones - have bigger perf problems, and a lot more room to optimize towards the ideal.
I'm going to assume the answer is "yes, that developer time can be more efficiently used."
> But it's obvious that wasting resources like this is going to scale with every user.
This we can agree on. But there's an opportunity cost[1] to fixing that. Going to the root of the hosting site, it clearly states the author is a webdev, so "fixing" that in the "let's not use electron" sense might involve learning Rust or some other native language first. That's not insignificant. And then you're competing with other already existing perfectly functional native color pickers... so are you actually saving significant hardware costs?
[1] https://en.wikipedia.org/wiki/Opportunity_cost
You can spend all day asking irrelevant questions and answering them yourself, it won't get us anywhere.
The point is that "developer time is more expensive than hardware" is not a valid argument from the user's perspective. As you can see from the complaints here, people already find the color picker less attractive because it uses wasteful Electron. It's not a good product, regardless of how cheap it was for the developer to produce and will be less successful as a result.
You don't need justification for developing something that isn't good because of wrong or selfish priorities, but you'd better accept that success of your product and its environmental footprint depends on these priorities too.
We're discussing how dev time is best spent in service to the end user (and environment.) It's absolutely relevant.
> The point is that "developer time is more expensive than hardware" is not a valid argument from the user's perspective. As you can see from the complaints here, people already find the color picker less attractive because it uses wasteful Electron. It's not a good product, regardless of how cheap it was for the developer to produce and will be less successful as a result.
Things the end user does care about include features, price, and the actual existence of the end product, all things I see frequently sacrificed by the "maximum efficiency at any cost" crowd, because they're misallocating dev time. They aren't even optimizing the actual efficiency bottlenecks half the time, just micro-optimizing some unimportant edge case.
You're right that the discussion doesn't matter to the end user, but that doesn't mean it's the wrong decision. As you can also see from the posts here, not everyone is convinced it's a big deal either. People are constructing strawman arguments "these devs and their 4k monitors and 32GB+ machines", but I'm using electron apps from an underpowered 8GB laptop just fine.
Yes, if you're traveling and downloading it over a mobile connection, it'll take a hit. Yes, I'm sure you can find a worse laptop than mine, and if you search hard enough you'll even find one where the fact that it's an electron app will be a problem. Yes, you can spend more resources to make a better app - that's always true, the question is where diminishing returns make that no longer cost effective. Yes, if there's no outlets nearby, it won't stretch battery life as far.
But no, I'm not convinced that calling it "not a good product" as a result of being an electron app is quite right either. Not the best product it possibly could be, but no product is.
> You don't need justification for developing something that isn't good because of wrong or selfish priorities,
Nor am I convinced there are wrong or selfish priorities in using electron. What, exactly, is wrong or selfish with saving dev time to work on something more important to the end user? Even if that's another product entirely?
It's simply completely irrelevant what the developer might or might not be working on also in your imagination, when we are judging the product based on its technical merits.
Inventing some extremely important better use of the developer's time to justify inflicting a wasteful 55MB download on the world, is a strawman argument of the same quality you complained about.
And if we're limiting the discussion to just the technical merits of a product, I'm not sure why you started discussing developer time and expense at all. You're the one who brought up "dev time vs millions of users hardware", and I'm just pointing out that it's perhaps more realistic to view this as "dev time" vs "thousands of users hardware" in this particular case, and that there's a lot of mildly important things the developer could work on instead.
For that matter, I did notice the size, as I'm browsing on a mobile connection (travelling) and the 55M color picker utility would take a bit over 2 minutes to download.
Phones for example have basically been unchanged for 5 years regarding performance, because while hardware has drastically improved the apps have become heavier in proportion for superficial new features. Same goes for internet connections.
As another example I'd say that the recent resurgence of deep learning has mostly come from (or at least was catalysed by) cheap, affordable GPUs, which only exist because gamers wanted better and better graphics.
We're already at the point where hardware is marginally increasing in efficiency year-over-year for most purposes. We've been there for like, 4-5 years now. Chips created on high-end processes are already expensive to the point there's no immediate cost-savings to be had from them, only power savings. Twice as dense, twice as expensive, marginal performance improvements. Years of development.
That's due to physical laws of nature, not because we suddenly started writing way, way better software and therefore hardware engineers decided to slack off for the past 8-5 years or whatever, after year-over-year doubling in the prior decades. Your lunch was never actually free, it's just that Bill down the hall has finally stopped paying for you every day, because he's starting to go broke and has to tighten his belt.
> that it is good that software is becoming more and more "bloated"
No it isn't, you only think that (and justify it with a speculative argument) because it lets you justify externalizing the costs of bloat onto someone else, ignoring any other concerns -- your users, your cloud provider, your hardware vendors, etc who all pay for the energy and time you wasted on their behalf.
> that's the only incentive to keep researching more efficient hardware.
No it isn't, this is just more baseless speculation to support your point.
I don't see it. The latest version of iOS is (apparently) such a big performance improvement that its performance got top billing as a "Feature" from Apple [1]. They brag about how it's ~50% faster at several common tasks.
[1]: https://www.apple.com/ios/ios-12/features/
Short thread on the matter: https://twitter.com/Wunkolo/status/1091572380315439104
This is an answer without a real problem, for Mac users anyway.
https://kde.org/announcements/plasma-5.5/plasma-5.5-colorpic...
https://userbase.kde.org/Plasma/ColorPicker
You can do the same thing in MS Paint and save yourself 15 seconds.
1) Take a screenshot.
2) Paste it into Paint.
3) Use the eye dropper to select the pixel that has the color you want.
This is the equivalent of editing a file with Notepad++ instead of opening it in Visual Studio.
The only problem I have with MS Paint is that it doesn't give me the hex value of the color I picked, only the individual RGB values.
With Apple you have to do things the special Apple way because Steve Jobs said so.
On Linux I am not thinking 'oh, where is my system wide colour picker and getting irate because there isn't one'. The colour picker works fine in the image editor program, with the browser add on I am covered for practically every use case.
Sure I had to add the browser extension and would be stuck without it, but my thinking was to get the browser extension rather than even think to install an OS widget.
I can't say that I have had a genuine need for a OS level colour picker ever. It is just not something needed. And no, just because I am not on an Apple machine does not mean I don't do anything 'creative'.
With Linux there are plenty of colour pickers already out there, 'pick' is very neat as it gives you a little screenshot of the context of where you got your colour from with a sensible colour name given too (albeit not a standard X-Windows style one, so you get 'Hot Cinnamon' instead of 'chocolate').
Color Picker for Windows (500KB) (1.6MB unzipped): http://instant-eyedropper.com
Significantly smaller than the Electron app and works across Windows XP to 10.
http://www.mirekw.com/winfreeware/mwsnap.html
but I also overrode the tooltip text on the screenshot cursor to display the RGB hex, as a ctrl+c will copy whatever is in this box
And I also think the slow "new document" screen is also javascript
Also let's not forget all those stupid creative cloud background updater jobs / services... that use node.js
Who cares that they used the “wrong” language or framework, or could have solved it another way or “who need this functionality anyway”.
Isn’t this supposed to be what the dev spirit is about?
Someone spent their free time to give the world something free, shame on them it's not perfect.
So what matters is the "why" and the "what", and we can just forget about the "how"? Engineering is all about the how we do things, and HN tends to have more engineers than your typical online community. What's wrong with that?
Cross platform application development is considered a "solved problem" with Electron, and it's developed a cult that leads people to disparage native applications and native development as inferior in all cases, as if Electron were already the best possible solution rather than a hack around webdev that blew up because of the SV hype machine.
Because of this commoditization around a single language and a single framework (mostly by corporate interests, mind you,) curiosity and innovation are halted in favor of developer time efficiency and resume visibility. No one is even going to bother trying to create the next cross-platform application solution after Electron, because they would only be able to do so in Electron.
It's getting kind of ridiculous.
---
#h::
MouseGetPos, MouseX, MouseY
PixelGetColor, color, %MouseX%, %MouseY%
StringLower, color, color
clipboard := SubStr(color, 3)
---
It's bound to Win+h (hex color) by default.
It's not fancy, but it works. You just run it in the background and hit the hot key to copy the color whenever you want to. There is no UI.
What's neat about it is the entire source code fits in a tweet: https://twitter.com/nickjanetakis/status/1108825825116332032
And it uses 0.6MB of RAM when running.
[0]: https://www.autohotkey.com/
AHK can be used to trivially fix many usability warts you have with random software, and is powerful enough that someone implemented a clone of dwm tiling window manager in it (bug.n, [0], I used it for more than a year and can attest it works very well).
--
[0] - https://github.com/fuhsjr00/bug.n
I'd go as far as saying AHK is one of the few tools on Windows that I really miss when on a Linux system. It's that good and I don't even know it too well, I just hack things together as needed. Bash is great and all but AHK does so many useful GUI things.
Thanks for the link on bug.n. I use i3 on my Linux laptop and for day to day usage I do prefer a tiled window manager of some sort. My Windows box is my main workstation so having some type of proper tiled wm would be really nice. Currently I use dexpot (virtual workspaces), AHK (global hotkeys), keypirinha (fuzzy find app launcher) and the built in Win 10 window split shortcuts to get as close as I can to an i3 set up.
Excuse me, this is one of the tiniest and most useful things i've seen in my life as a budding designer.
It was something I whipped up in 5 minutes about a month ago when I really wanted a quick and dirty color picker. I do use it in practice.
One shortcoming is it doesn't visually show the color after you copy it, but that could also be done with AHK. You could totally have it show a small 16x16 window with the color which would disappear after 2 seconds and would get refreshed after you pick a new color if it were still visible.
You could even go 1 step further and change it to zoom around your cursor on key press, and then copy the color on mouse click while showing a 16x16 window color preview on hover. That would be the ideal solution, but something like that might be 3-4 hours of hacking around with no real AHK knowledge instead of 5 minutes and that wasn't worth it to me at the time.
Of which the runtime is about 120.3 MiB. There is even a copy of ffmpeg (2 MB) for the rare occasion when you want to play back an mp4 video in your color picker.
The actual app itself is in the resources directory which is 1.8 MiB large.
This directory contains files electron.asar (214 KiB), app.js (1.7 KiB), package.json (727B), and directories static (152 KiB) and node_modules (1.4 MiB).
The actual content created by the author is in app.js, package.json and static, which together take 160 KiB, of which 52 KiB is the logo (would have been much smaller as SVG) and 68.8 KiB a bundled font.
In the node_modules directory major contributors for size that I see are:
* node_modules/tinycolor2/demo (288 KiB; largest contributor here is a jquery copy)
* node_modules/tinycolor2/docs (228 KiB)
* node_modules/tinycolor2/test (116 KiB)
* node_modules/electron-settings/node_modules/fs-extra/docs (96 KiB)
* node_modules/electron-settings/node_modules/fs-extra/CHANGELOG.md (56 KiB)
* node_modules/user-media-screenshot/.idea/ (44 KiB)
All of the stuff I listed above is quite redundant for the users who just want to run the app. If you remove them, the 1.8 MiB become 764 KiB for the entire app and I'm pretty sure that minifiers, bundlers etc. could make it even smaller.
The runtime could be provided by the OS. I think it's definitely possible to create apps < 500 KiB with web technology, it's just the deployment patterns that turn this into a major download of 122 MiB. As for the RAM usage, idk about that. I guess if the runtime is provided by the OS, it would be the same electron binary so the OS could share that one at least.
I don't hate web technology, I just hate electron's distribution model. There are so many frameworks to get around this.
The problem? When you start to have 5-6 apps running with Electron in the backend and start to take 10% of your CPU time and 2 Gigs of RAM, you will start to feel how it impacts your working environment, battery life and all.
On a serious note: I never understood why people tell me to buy better hardware to compensate for the shitty performance of their software. No, fix your software!
I read about this dude who purposely writes software on a shitheap laptop just so that "if it's fast here, it's fast on modern mobile phones."
Even my app written in Elixir and uses 160MB of RAM after letting it run for a week; I've been thinking: "Maybe I could bring it lower to what nzbget uses (around 59MB)". I've been exploring Nim for that.
We need a return to small-footprint as a feature.
EDIT: edited to make it less ambiguous
It is about having a color picker (probably just a few lines of code) bundled with quite a set of dependencies and complex chromium runtime environment which does not get updated regularly. Therefore they keep their vulnerabilities even after they are known and fixed in later versions of the dependencies.
With small footprint applications, you are less likely to have such problems.
Edit: Oh I get it you actually meant:
"Hehe, kinda funny when your application written for Electron comes with more security vulnerabilities than it has lines of code for its own logic ;-)"
It's 120 MB for literally a fucking color picker.
That native apps were wildly unstable, or that it was impossible to find native apps that ran on different platforms before Electron is a myth. Electron didn't solve those problems, because they weren't problems.
Electron solved the problem of "how can I, a web developer, run a website on the desktop but make it seem like a native app and call myself an application developer?"
Second, this is not a criticism on application writers, but on Electron itself. It could use a runtime available on computers (virtually every computer has a browser) or, at least, a shared runtime that would download itself.
Bundling a browser with EVERY different app is not only a waste of space and of RAM, but also a security issue: now you have to wait for each app developer to update the app in case there's a security problem with Electron, Chromium or any of its 2000 dependencies, and that's "if" they upgrade. And that update takes at least another 120 MiB to download, for each Electron app you have.
Instead of downloading 120 MiB for each app, each app could come in a small package and only download the runtime if it's not available in the computer yet. Java got it right in the 90s, .NET got it right in the 2000s, although downloading the runtime had terrible UX for stupid marketing reasons (you had to provide e-mail to download from the Sun or the MS website).
Including only the bundled/minified app is possible, leaving no node_modules folder at all - or, at least, just the native binaries needed.
As for bundling the whole Electron runtime on every app: technically it's possible to have a shared runtime - as this 3-year old issue shows, many people have attempted various approaches: https://github.com/electron/electron/issues/673
However, sadly no one has stepped up to come up with a general solution. While there are disadvantages and some reasonable arguments for bundling the exact version of the runtime required by an app, it seems efficent use of resources isn't enough of a priority..
Is there an idiom or ethos in node land that aims for tiny re-usable packages? I am not criticising if there is, just genuinely curious.
I have been writing JS applications for years and it's only since node and npm hit the scene that this has occured.
But everyone just goes ahead and pulls in Chrome.
It's shameful, and the worst part is that I get it - at this point I'm suggesting we go to Electron for a new application at work because it seems like the best maintained UI frameworks with readily available 3rd party components are all web based.
Now that Java is being developed at such a speedy clip at the cost of breaking changes, we may see Java runtimes being shipped with apps. (I'm personally still on Java 8 because that was the last release before drastic breaking changes started happening.)
Just kidding. Java has been abandoned in favor of web apps anyway.