Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Fucking Color Picker

tonymccoy.me

Post reply on HN
Print view View original

81–90 of 140 posts

Re: Fucking Color Picker

#81

Post by ekianjo »

Polarity wrote: post #76
est31 wrote: post #64

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

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.

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

Re: Fucking Color Picker

#82

Post by kakarot »

I was really excited until I saw Electron at the bottom.

A color picker is a tantamount example of an application that does not belong on the Electron platform.

Re: Fucking Color Picker

#83

Post by ekianjo »

misnome wrote: post #50

A dev missed some feature of their usual OS and so wrote a cross platform version open source in their spare 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?

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

Re: Fucking Color Picker

#85

Post by krapp »

misnome wrote: post #50

A dev missed some feature of their usual OS and so wrote a cross platform version open source in their spare 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?

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.

It's getting kind of ridiculous.

Re: Fucking Color Picker

#86

Post by sergiotapia »

Polarity wrote: post #76
est31 wrote: post #64

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

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.

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.

We need a return to small-footprint as a feature.

Re: Fucking Color Picker

#87

Post by dna_polymerase »

Polarity wrote: post #76
est31 wrote: post #64

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

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.

> What´s the problem with this?

It's 120 MB for literally a fucking color picker.

Re: Fucking Color Picker

#88

Post by lohszvu »

drivingmenuts wrote: post #67
stephc_int13 wrote: post #10

Wow, this is waaaay too big for my taste. I'm absolutely sure it is possible to write the same cross-platform app for less than 500KBytes and no dependencies.

Well, for one, you could skip writing it for Mac OS because it already has a fucking color picker. This is an answer without a real problem, for Mac users anyway.

Windows and Linux already have color pickers too.

Re: Fucking Color Picker

#89

Post by arendtio »

Polarity wrote: post #76
est31 wrote: post #64

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

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.

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.

Re: Fucking Color Picker

#90

Post by arendtio »

sergiotapia wrote: post #86
Polarity wrote: post #76

Earlier quoted context omitted.

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.

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…

Hehe, kinda funny when an application comes with more security vulnerabilities than it has lines of code for its own logic ;-)

EDIT: edited to make it less ambiguous

Post reply on HN