Live data from Hacker News

Fucking Color Picker

tonymccoy.me

121–130 of 140 posts

Re: Fucking Color Picker

#121
post #81

Earlier quoted context omitted.

> What´s the problem with 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.

Just download more RAM! 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!

Because there are few people on earth more entitled than the modern web developer?

Re: Fucking Color Picker

#122

Earlier quoted context omitted.

There is no problem. It is just like flying with a helicopter to the supermarket. You just need a supermarket with a large enough parking lot.

but better than using 5 different cars for 5 different supermarkets.

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

Re: Fucking Color Picker

#123
post #55

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…

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?

Re: Fucking Color Picker

#124
post #2

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. [1]: https://medium.com/commitlog/electron-is-cancer-b066108e6c32

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

Re: Fucking Color Picker

#125
post #97

Earlier quoted context omitted.

Sorry, is this a comment on elixer or Nim?

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

Can't argue with you there, I tend to use tcl/tk for something this small.

Re: Fucking Color Picker

#126
post #100

Earlier quoted context omitted.

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

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…

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.

Re: Fucking Color Picker

#127
post #55

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…

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). -- [0] - https://githu…

Totally agreed.

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.

Re: Fucking Color Picker

#128
post #112

Earlier quoted context omitted.

Qt

One of the advantages of Electron is that apps can be written in JavaScript and other web technologies, making it accessible to many more developers.

You can use QML and QtQuick and use Javascript plus a markup langauge.

Re: Fucking Color Picker

#130
post #55

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…

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?

This seems like a very Windows-specific complaint, not a general desktop OS one.
Post reply on HN