Fucking Color Picker
tonymccoy.me
tonymccoy.me
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.
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.
---
#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.
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.
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.
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.
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
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.
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?
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.
Short thread on the matter: https://twitter.com/Wunkolo/status/1091572380315439104
This is an answer without a real problem, for Mac users anyway.
[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.
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.
https://kde.org/announcements/plasma-5.5/plasma-5.5-colorpic...
On Linux it seems confused with a muti-monitor setup, the orbit button does nothing.
On Windows, in a VM, the orbit button opens a web browser to https://www.tonymccoy.me/orbit/#ffffff and gets a 404 Not Found
https://doc.qt.io/qt-5/qcolordialog.html
KDE's KColorChooser is simply a wrapper around this and is less than 100 lines of code, mostly setting up the about box.
https://kde.org/applications/graphics/kcolorchooser/
This could have trivially been made into a cross-platform color chooser that uses significantly less resources.
On my Linux box Fucking Color Chooser spawns 4 fucking processes uses 128 MB of RAM and 4% CPU.
KColorChooser uses 15 MB in one process and near zero CPU.
Please stop making everything a web application.
A color picker is a tantamount example of an application that does not belong on the Electron platform.
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
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://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.
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').
It obviously doesn't have a fancy preview, different representations or the other stuff you would get in a proper color picker, but it's fast and easy if you already have pyautogui installed and works on both linux and windows.
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
Got me thinking about the meaning of c-word and I realized electron is a contagious form of cancer. It spreads from devs to user sure, but it is also spreading from devs to devs and more and more devs are using it. Fucking Microsoft has an enterprise product built in electron now. Who would have thought?