Why I chose Electron.js for my side business

https://en.wikipedia.org/wiki/List_of_platform-independent_G...

It's true what you're saying, JavaScript wasn't designed for this, and chromium is being repurposed for something out of it's scope too. But hopefully it will evolve with time in the right direction, my honest opinion is that it has the potential, mainly due to it's popularity, there's and huge amount of resources and hours people are willing to invest it it.

Slack has, to put it mildly, plenty of money, and gave us a 300MB bloated client. Ripcord is a payware alternative client made by a single developer.

Things seem to be precisely backward.

That's why I used it for my example. Past systems are a useful benchmark for what it's practical to do with a certain level of computational horsepower.

> Slack is taking less than 1% of my Ram.

My system has 8GB, so 3.7%. I'd rather have 3.4% of my memory back.

More broadly, we should consider that we may run many bloated apps. Even if Slack doesn't do too much harm on its own, if all your desktop apps are using 10x the resources they could be using, it adds up to you spending more on hardware than you should have to.

You paid for that 16GB of RAM. That should let you do a lot more than old computers can, rather than doing the same things we did 15 years ago with bloated software.

> At the time AIM was the dominant chat client, and it probably took more like 5% of RAM available.

Right, like Ripcord, it did roughly the same thing Slack/Teams do, using far fewer resources.

Sure, people could spend more money to mostly sidestep the issue (supposing they didn't have any workloads which actually benefited from all available RAM), but that doesn't make it a non-issue.

I think there are some UI niceties to the 'app' version but it's essentially the same.

Teams refers to Microsoft's competing product. Like Slack, its desktop app is really just the web version.

Yes, because they're just web pages. Then why not just use the browser to display them?

It's not specific to web developers. "Grok" has a meaning (and C++ a beastliness) that precludes most C++ programmers from being able to be described as "grokking" C++. Most C programmers don't even grok C, and as far as feats go, it's one that's many times smaller than the one discussed here.

> The actual file is 42 lines there

Okay? If you encounter an argument "There exists an X", proving it wrong is not as trivial as pointing out "I can show there (also) exists a Y".

I wrote what I wrote for a reason. Write such a hello world program in a mainstream idiomatic style that most closely resembles the way a JS programmer would write, and a GTK hello world app is (shocker!)... 12 SLOC, as mentioned:

  $ ls -l ./scratch/hello.js # written yesterday
  -rwxrwxr-x 1 asmithee asmithee 402 Nov 20 13:54 ./scratch/hello.js

  $ cloc ./scratch/hello.js | \
  >   grep -ie javascript | \
  >   sed "s/ \( \+[0-9]\+\)\{3,3\}/ /g"
  Javascript              12

  $ cat ./scratch/hello.js
  const Gtk = imports.gi.Gtk;

  let mainWindow = null;
  let app = new Gtk.Application();

  app.connect("startup", function buildUI() {
    const text = "Hello, World";
    mainWindow = new Gtk.ApplicationWindow({
      application: app, title: text
    });
    mainWindow.add(new Gtk.Label({ label: text }));
  });

  app.connect("activate", () => { mainWindow.show_all() });
  app.run(ARGV);

Your thumb is on the scale. No shebang is necessary, and as you pointed out yourself, the equivalent in the Electron world is to 'simply declare an arbitrary webpage or js file filled with arbitrary modern HTML5 to be my "main" page/script'. And speaking of package.json...

> a bunch of calls to GTK stuff

Your thumb is on the scale. Electron developers learn how to deal with "Electron stuff". And, hello? JSX? React? These are things that are used extensively in this space and come with their own complexities and have to be learned. (And neither are even inherently Web things. They're inventions of "framework" people and live entirely in that layer.)

> And that is my point-- it's 42 lines too long

Your thumb is on the scale. There is no equivalent Electron app that is 0 lines long. And let's talk about the untold number of projects whose package.json require many more lines, even for small, trivial, or incomplete programs. That's package.json alone, i.e., before we even get to writing code that actually does anything. Besides that, the community around NodeJS is renowned for bloat and esoteric tooling. As a concrete exercise, take a look at any random repo on GitHub, and you're likely to find the root of the source tree filled a dozen or more auxiliary files. Simplicity is a strength, but it's not one valued very highly by the people who've ended up writing Electron apps and participating in the larger NodeJS community.

In any case, regardless of this stupid (stupid!) attempt at a takedown, you can't ignore that (a) you're responding, as mentioned before, to an argument you're imagining rather than the one anyone is actually making, (b) even if your response were on-target, the argument in it is anachronistic. To be able to "continue" the tendencies they've settled into now in 2020 is an impossible constraint when the entire context of this subthread is how Gnome folks' actions in 2011 could have led to a drastically outcome for how mainstream, cross-platform apps written in JS are developed. To insist that Electron is the best fit for a bunch of developers who are used to and comfortable with writing Electron apps is not insightful, it's just begging the question.