A few years ago Ubuntu was still using Unity.

I wouldn’t say just web developer, but average programmer unfamiliar with Qt’s stack.

qt supports mobile

https://doc.qt.io/qt-5/supported-platforms.html

There is wisdom in this comment. It's important to note, though, that the point about investment applies also to the tools and methodology that the blank slate programmers are being steered towards.

It's both interesting and exasperating that the modern JS ecosystem and its influencers have managed to recreate the experience of downloading SDKs and fiddling with configuration options and dealing with builds that sometimes fail, and that when they don't, build success means producing inscrutable blobs where View Source is rendered useless. On the whole, it's a community that has neglected to maintain the ecosystem's original strengths.

https://www.colbyrussell.com/2019/03/06/how-to-displace-java...

But OP isn't a newbie going to coding school, he/she already knows JavaScript and webdev in general ! Of course if you don't know programming at all it's harder (even then, 3 months seems like an awful lot - this year I teach programming to graphic design students and in ~15 hours they are already able to do neat things on their own with p5.js).

To give my own experience, I'm almost exclusively a C++ coder but had to do two Web projects earlier this year, a React one and a custom one, and even though both times it felt like eating nails, it didn't take more than a day to "get in" ; I'm confident that it's be the same no matter the language except maybe APL and derivatives :)

Yes, I personally am happy that Spotify is an electron app. Considering that the Linux binary is maintained by volunteers at the company I'm pretty sure it just wouldn't exist otherwise.

Yes, the fact this issue is literally a one line CSS change is what attracted me so strongly to using Electron.js. I'm all for software engineers building amazing macOS/Windows apps, but I wouldn't have any idea how to make text non-selectable.

In CSS it's "user-select: none;" and you're done. Playing to your strengths is important when building a business so that's exactly what I did :)

> It was built for UX

It kinda really isn't. "Great UX" is not something I associate with any web app. They're generally slow and unresponsive, have atrocious accessibility, and don't integrate with OS native UX concepts.

I've used a few alternative Discord frontends, both GUI and terminal-based.

To put it frankly: they're all flaming heaps of dog shit.

The ToS explicitly forbid usage of third-party clients and people have been banned over this issue. Some people may be fine with taking this risk, but I also absolutely understand not wanting to deal with it. Personally, I fall in the latter category, so I mostly have the web client open in a pinned tab.

> Personally I'm not, at all, I'm barely comfortable enough with installing Emacs from source.

sure - but to give you an example doing something like that is the kind of project that I'd give to beginning computer science students that know pretty much nothing outside of for-loops and variables, and I know from experience doing that every year that they'd get it done in a few weeks, including learning enough of Qt to achieve it. So if you have existing programming knowledge it should not take more than a week, even without knowing C++.

Perhaps you should try a hello world GTK JS app instead of speculating about how it surely will confirm your biases. It would've taken you less time type "hello world gtk javascript" into a search engine and copy and paste the snippet into a file than writing out that bad faith argument.

> Keep in mind that with Electron/nw.js I download the toolkit binary and then simply declare an arbitrary webpage or js file filled with arbitrary modern HTML5 to be my "main" page/script.

I don't know why you assume that GJS is any different. Well, actually it is different: you don't have to "declare" any file. You can open up a file hello.js, write your code, and... there it is, in a dozen SLOC. (If you really wanted to, you could write an entire app in that one file.)

Not that any of this is even relevant, because you totally misread my comment. It was not about how GJS is better than Electron and the Electron folks just won't admit it. It was about how Electron is better than whatever the JS-hating GTK developers wanted, but they were too shortsighted to see the future we were going to end up in with or without their endorsement. So your kneejerk defense of your tribe is off the mark.

  $ 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);

Oops, had and typo there, meant to say: reusing the frontend skills... what is weird about that?

Here's another example: GNOME shell uses JavaScript and CSS, and it's pretty straightforward to understand. Was looking at the code of a plugin to hide the workspace switcher popup and tried a few things to instead reduce the animation time to something that does not necessarity stick around over my windows too long to bother me when I want to view the content beneath. Took and few hours but I got it configured decently, and "live reloaded" it to get the effect instantly. Here I reused my JavaScript knowledge to solve it; if it wasn't so easy due to my previous unrelated knowledge I probably wouldn't have invested any time in it.

You keep mentioning Wayland as if it is the magic keyword that will strike fear into the heart of native app developers. That's just not a thing, it won't matter at all for your app.

The irony is that if you write a desktop app at one point, you will soon learn about all the things that Chromium doesn't do for you. Want to run some kind of privileged operation (since disk benchmarks came up)? Tough luck, there is no special pass for you on macOS just cause it's Chromium. And with the app sandbox, there are now lots of things that are privileged. This story repeats ten times for every OS you want to support, regardless of using CSS for your UI chrome.

This is a false dichotomy. There are plenty of cross-platform toolkits that are far leaner than electron.

Sciter is missing from that list for some reason.

How about Electron-based chat apps like Slack and Teams? We know it's possible to implement this kind of functionality in <40MB of RAM, rather than the 300MB used by Slack and Teams. [0] If these apps are going to be running constantly, it essentially means you've paid for 260MB of RAM more than you're able to use, on account of Slack putting their developer convenience before your computational resources. This seems especially silly to me as many companies pay good money for the privilege.

For comparison, the Playstation 3 has 256MB of system RAM, and manages to run GTA V.

[0] See the Ripcord application, discussed https://news.ycombinator.com/item?id=23163960

In general, I think you're right - but that mindset can quickly become one of shifting costs to others: E.g., $framework-of-your-choice may increase your velocity and allow you to ship faster.

However, it might also make it harder to find bugs and it will produce bloat with real, noticeable consequences - e.g. increased RAM, CPU and disk usage, more sluggish UI behavior, etc - except, those effects will happen on the user's machine, not the developer's, so a developer might be tempted to ignore them.

> The Slack app is essentially a Chromium browser running the usual web-based Slack. It uses the same amount of resources running in a tab in your browser.

I would expect that a pinned Slack tab in Chrome/Edge would be able to share some resources with the browser that a separate Slack app can't.

Has anybody tested the performance difference between running 100 browser tabs vs. running the same webapps as 100 electron processes?

Honestly though, why would you rather have that 3.4% of ram back?

Is the bottleneck in your system actually ram usage? Because I think implicit in your view is that you have a better usage for that ram. If so, what?

Because I really struggle coming up with more than about 5 electron apps I might ever run at any given time (Slack, VSCode, Discord, maaaybe Etcher..., and I'm basically out of ideas). Even then, two of those apps are both chat apps and I probably shouldn't have Discord open for work, and I don't use slack for any personal reason.

Basically - Electron apps are all applications that are UI heavy. I don't have the mental power to manage more than about 5 open and active UI apps before I'm the bottleneck, not the computer.

So at 5, you're spending 15-18% of your RAM on 5, 5! apps that you want to be interacting with rich GUIs at any given time. I just don't see it.

At least for my use cases, electron apps almost always make up a trivial amount of my total ram usage. Docker/Development Env/Vms DOMINATE in comparison.

So while I get that it could be faster, the reality of the situation is that without electron, none of the apps I listed would work on Linux at all. Instead they all do by default.

So right now on amazon, 16gb of ram is 53 bucks for a decent module. 150/16000 = .009. So basically - I paid 49 cents, and got apps that work by default on my platform of choice. That's pretty fucking amazing compared to old platform specific apps.

I meant that as a nod to the person to whom you're replying, as well as the author of the article. Of course it's possible for indie developers to build native apps — but I don't begrudge them for avoiding that route, especially if their day job doesn't involve it. I am perfectly fine with criticizing giant companies for building chat apps atop Electron.

Nobody’s stopping you from using the web version of Slack or Spotify.

That said I can think of some pretty good reasons.

- Users don’t understand it as well or are less comfortable with it.

- Users’ general preference for logical separation

- Mobile safari doesn’t support browser notifications.

- You won’t get browser notifications if you close the tab by accident

- You lose OS integration, like replying via OS notifications in Slack or using OS Music controls with Spotify

On top of all that a browser tab uses plenty of RAM as well so I don’t really see the upside of using the browser for these apps, either.

I'm guessing you're not going to run Slack unless you're at a company. And I'm guessing if you have 2-4GB of RAM you are not running a company issued computer. And if for some odd-ass reason you are running on a personal computer with 2-4 GB of RAM and NEED slack, why not just run it in a chrome tab?

Of course not. But do we expect companies to stick to the decisions they made as startups forever?