111–120 of 140 posts
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
In total, the app is 122 MiB large. 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 (…
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 -…
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.
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…
Nope, you cannot colorpick with MS Paint from the whole visible screen (i.e. all windows and the desktop)
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.
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…
Nope, you cannot colorpick with MS Paint from the whole visible screen (i.e. all windows and the desktop)
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.
Earlier quoted context omitted.
> 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. I…
> 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…
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.
Earlier quoted context omitted.
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.
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.
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
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
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.
See Qml.Net (https://github.com/qmlnet/qmlnet), or PyQt.
Earlier quoted context omitted.
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.
> 260MB 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.
Earlier quoted context omitted.
> 260MB 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
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. [1] https://github.com/electron/electron/issues/2003
But yeah, 85MB for a complete UI runtime seems entirely acceptable to me.