[_odey]

No matter how much I hate the bloat, and no matter how much I don't like JavaScript as and language due to it's behaviour around type coercion, I can't help it but to agree with everything in this article. Reusing the frontend skills I learned throughout the years to build desktop apps when needed, instead of having to learn an OS toolkit (and in the case of linux, multiple desktop environments, neve mind Wayland vs X) is the difference between shipping something and not shipping at all.

Learning takes time and effort, and the more general the tool I use the better.

If I had to implement a desktop app tomorrow, I would default Electron, no contest.

A bit of an aside, but I was thinking lately, it would be great for linux to have an SSD benchmarking app, just like CrystalDiskMark, I would never attempt to implement something like this in Qt or GTK, there's just too much to learn beforehand compared to simply going with CSS, wrapping the fio command in a JavaScript shell call then publishing everything as an appimage. This way I know it will work everywhere and it will have a consistent look and feel everywhere. I might actually set this up as a weekend project sometime next month. Without Electron it would take me months of intense dedicated time, which I would rather spend on something else.

[jsdavid]

The tweet mentioned in the article, saying:

Electron app memory usage: 150MB

Native app memory usage: 0 MB (because you never ship it)

really hit home for me.

[_odey]

I used to disagree with this view, since I was "raised" in school to think that raw performance is the only worthy attribute of a computer program, regardless of purpose. Then, when I started working on real products instead of homework I learned how wrong that way of thinking was.

Of course it does not apply to everything, some apps do need every last clock cycle of speed, but so far none of mine had.

[MaxBarraclough]

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

[Falling3]

Yea, completely agree. I think context is very important here. We should not be making the same arguments for a one-person side business and a company with 400MM in revenue. Slack really can't stand on the arguments presented in the article.

[dangus]

Slack didn't exactly start with 400MM of revenue.

[Falling3]

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

[dangus]

Ripcord itself demonstrates why Slack is written in Electron.

Is there a mobile app? Nope! Dead on arrival. In 2020, Slack or Teams or anything similar is literally useless without a mobile app.

Feature matrix says animated emojis will arrive "never." lol!

I remember the days of native chat clients like Skype and AIM. I remember how Linux and Mac platforms were basically half-clients compared to Windows. It sucked.

Electron applications like Slack and Spotify work everywhere, exactly the same. And if you think about it, that's why something like chat and music apps would prioritize ease of cross-platform deployment over perfect efficiency. They're not particularly demanding, and they are most valuable to people when they're ubiquitous. If Spotify isn't in every device I own it loses a great amount of value.

Nobody's sitting at their Activity Monitor staring at the RAM usage of Slack or Teams. In reality, performance is fine. It's just chat.

(Interestingly enough, I've never found a music application that skips tracks more quickly than Spotify, even for locally-stored music. It's just instant with no gaps.)

[xg15]

> Electron applications like Slack and Spotify work everywhere, exactly the same.

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

[dangus]

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.

[coding123]

The PS5 has 16GB of RAM.

So does the Mac I'm using.

Slack is taking less than 1% of my Ram.

PS3 was released 13 YEARS ago.

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

[MaxBarraclough]

> PS3 was released 13 YEARS ago.

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.

[horsawlarway]

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.

[hansvm]

Plenty of people only have 2-4GB of RAM, and Slack eating up 360MB along with a couple other bloated apps and some God-foresaken autoplaying video ad can easily start requiring swapping and slow a computer to a crawl.

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.

[coding123]

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?

[jakelazaroff]

I think we can hold multi-billion dollar venture-backed companies to a different standard than we do indie developers working on side projects.

[MaxBarraclough]

Not sure if you meant that as a nod to Ripcord.

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.

[jakelazaroff]

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.

[_odey]

I don't use the Slack app, there is no need to do that when I can have it running in a browser tab instead. Not sure what Teams is either...

[MaxBarraclough]

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

[piaste]

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

[kyriakos]

You'll be lucky if you get Teams to work in a 300mb. I regularly see it hitting 1GB. The fact is though that even if it was implemented as a native up it relies so much on web views for its addons which would probably not give much benefit cause it would need to run tens of webviews as a native up to have the same functionality.

[xg15]

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.

[GirkovArpa]

Sciter.JS is going to change that: https://github.com/c-smile/sciter-js-sdk

I cloned a 165mb Electron app in Sciter, and it was only 6mb:

https://github.com/GirkovArpa/clipper-sciter

[pwdisswordfish4]

> I would never attempt to implement something like this in Qt or GTK

In fact, you can write GTK apps in JS. A year or two before Electron came along, the Gnome folks had the foresight to declare that JS would be the language of choice for promoting GTK and Gnome app development, with the option to drop back to C otherwise. This caused a minor controversy, where the community decided to rage against this effort and essentially rejected it. Here we are then, instead.

Rather than the "default" toolkit of choice in 2020 being GTK, which is cross-platform, provides an opportunity to get closer to "native", and has the roots and traditions of pre-GitHub FOSS, an vacuum was left wide open—unfilled due to the internal revolt/denial of the Linux desktop crowd. So the NodeJS and web developer community swooped in and filled it, with their dubious sui generis practices pushed to the forefront instead, and the world is shipping apps in browser runtime containers.

[jancsika]

> In fact, you can write GTK apps in JS.

I'll eat my hat if it's as easy to write a hello world in GTK as it is in Electron/nw.js.

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. That means any frontend dev can immediately get a "hello world" running with no extra tooling and immediately access the full dev environment they are used to. Aside from the json file they don't even have to learn any of the non-HTML5 APIs (which, btw, are typically where the most nefarious bugs live in these toolkits).

What is more, the dev can immediately bring in any of the zillion frameworks they depend on to pad strings or whatever.

I'm guessing GTK has a way to hook into its own API through javascript. But if it's anything more than a single call to create a window and fill its webview with a page (or execute a js in its context), it's already more complicated and electron/nw.js wins.

Edit: typo

[pwdisswordfish4]

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.

[jancsika]

> there it is, in a dozen SLOC

https://developer.gnome.org/gnome-devel-demos/stable/hello-w...

The actual file is 42 lines there, which includes a shebang and a bunch of calls to GTK stuff.

And that is my point-- it's 42 lines too long to matter whether or not we travel back in time to beat back the "JS-hating GTK developers." Because as it turns out, most devs are not looking for a way to use GTK from their favorite language Javascript. They just want to continue their frontend development in a box as if they are simply developing for the web, and then have the results show up as the GUI for a cross-platform desktop application.

[pwdisswordfish4]

It's clear what your point is. There was no need to explain. You want to put your thumb on the scale and confirm your biases.

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

> includes a shebang

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.

[nvrspyx]

GTK is barely cross-platform. It's an utter pain to get anything usable in either Windows or macOS. It also doesn't look native on either platform, especially Windows though, because of the default Aidwata theme.

[fulafel]

People like to complain about JS but the fact is that it's been completely optional on the frontend to write in it for 8-10 years, certainly the whole time Electron has been around. JS is a fine compile target though.

[zaro]

You should check Gnome Disks, it alrady has bencmarking builtin and is installed by default on Gnome environments.

[_odey]

Thanks for pointing this out to me, I did not know about it, is it new? I remember a few years ago when I would start "Disks" in Ubuntu it would open the "baobab" tool. Might be just an unfortunate naming colision...

[RMPR]

A few years ago Ubuntu was still using Unity.

[_ea1k]

I just tried it and got some crazy high numbers for a VM image mounted on an external USB drive. Something seems off about how it is assessing caching.

[AnIdiotOnTheNet]

Werid. You hate the language and the bloat, but you still would choose Electron over something like Lazarus?

[cogman10]

In a heartbeat.

The fact of the matter is, ecosystem trumps everything else. For UX development, nothing comes close to javascript. The language may suck, npm is somewhat of a trainwreck, and yet, if you want any sort of esoteric component, you'll find it in JS.

It's got so many tools that it simply isn't uncommon for newer desktop apps to have embedded browser in them as an option.

Want proof?

    - Show me a Lazarus native flamegraph.
    - Show me a Lazarus graph library that comes close to D3
    - Show me a Lazarus date picker :D

Sure, if you are doing something like game design or whatever, then JS is probably a poor fit. However, for pretty much any cooperate application, it is really hard to beat the JS ecosystem. Further, the hard part of distributing those sorts of applications have already been solved. Electron works great if you need a dedicated app. However, you can also just make things a webapp and be done with it.

Yeah, I hate the language. I even hate parts of the ecosystem (is-even... WTF?!?!?!). However, you just have to admit that nothing comes close to the tools and widgets you get for free by adopting js. It was built for UX.

[AnIdiotOnTheNet]

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

[cogman10]

For super simple apps, sure, you might be able to get away with OS native (or frameworks like GTK). And the look and feel will be better.

That's not really the point I was making. The point I was making is that if you want to do anything more complicated then "push this button", you'll quickly find out how limited pretty much every other UX environment is.

Javascript isn't "Great UX" it is "Great UX ecosystem".

[_odey]

Lazarus meaning the Delphi / Pascal IDE? I haven't touched any Pascal code since the first year of highschool over a dousen years ago :). Forgot it even existed.

Yes I hate bloat but I'm starting to hate it less and less each day due to understanding more and more the effort required to build things (in general, not just desktop apps).

I think, unless you have the resources to dedicate yourself to just one OS/toolkit, for which your app performance is an absolute must, it's better to prioritize delivery speed and adoption, using generic tools, with plenty of resources and skills that can be transfered from other areas, like web frontend is in this case. One thing is for sure, I don't have time and resources but I have a pretty fast laptop, so the choice is easy in my case.

[dave84]

> Reusing to the frontend skills I learned throughout the years

Not weird at all.

[_odey]

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.

[AnIdiotOnTheNet]

I don't think they were commenting about the typo, they were simply pointing out that it isn't weird to prefer using things you know.

Personally I can't agree, since in this case using what you know involves shoe-horning a hacked together and mutated beast into a role it wasn't designed for.

[_odey]

Oh, sorry for misunderstanding that.

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.

[jcelerier]

> Without Electron it would take me months of intense dedicated time, which I would rather spend on something else.

c'mon, getting the very basics of it in Qt took the better part of 15 minutes and less than 100loc - then it's mostly a menial "where to show which data"

https://github.com/jcelerier/fio-ui

[joshmanders]

> c'mon, getting the very basics of it in Qt took the better part of 15 minutes and less than 100loc

I used to think this same way about things because I had so much time in the tools that I never looked at stuff from a perspective of people who have no clue.

Now that I have a friend going through coding schools and everything with zero understanding, everything I think is "just a 15 minutes of tinkering and you'll know all the bits you need" is actually 3 months of banging your head against the fucking wall.

Don't let your existing experience cloud your judgement.

[cxr]

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

[jcelerier]

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

[_odey]

From your GH profile I see you're quite familiar with C++ development. Personally I'm not, at all, I'm barely comfortable enough with installing Emacs from source. Considering the time I need to dedicate to my dayjob and the limited amount I have on the weekends I'm not exagerating when saying it would take me months to reach and level where I would be comfortable developing something in Qt. Not impossible, of course, just time consuming.

[jcelerier]

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

[_huayra_]

I have not taught webdev folks C++, but I have taught brand-new C++ programmers just basic things for an intro course. I think it's easy to forget how hard it is to pick up for beginners except for the handful of people who have the ability to "think like the abstract machine".

I think folks who are steeped in the webdev stuff and UI don't always grok languages like C++ or its many footguns as easily as one may suspect. fwiw I feel the same way when I have to do any web stuff (i.e. out of my element). C++ may seem easy, especially when using a framework like Qt, but students tend to get really overwhelmed by all of the rules to avoid the language's pitfalls (e.g. the GSL rules, abseil's tips, Scott Meyer's books and so many other authors, etc).

Perhaps if one is a great teacher, the pedagogy can introduce these things in a tolerable progression. I found as long as students stuck to value semantics only they got it, but as soon as they used a framework that dealt in references / pointers it was a real step function in difficulty. Thinking about the lifetime pitfalls and related UB really ratcheted up the mental load, and I was not really trained how to teach effectively (like most grad students).

[cxr]

> I think folks who are steeped in the webdev stuff and UI don't always grok languages like C++ or its many footguns

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.

[serial_dev]

It might be 15 minutes for you, because you already know and used Qt.

I can almost guarantee you that an average frontend developer (web) would not be able to do that.

[tylerhou]

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

[maxk42]

This code genuinely looks simple. Can you recommend a good resource for getting started with Qt? Also, is this just for desktop development or is there a relatively straightforward to make it cross-platform compatible? If I can build one Qt app and export it to iOS and Android then I'd much rather do that than Electron.

[asddubs]

qt supports mobile

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

[adzm]

It's not only that, it is also leveraging the very rich ecosystem built on html and js

[stefan_]

    Learning takes time and effort, and the more general the tool I use the better.

I mean, you could have just written this. It's fine you don't want to learn anything new, but it makes your judgement suspect - hence the "Wayland vs X" confusion.

[_odey]

No, I do want to learn things, but the choice is simple, you either:

1. Learn Electron and implement an app, publish to all platforms.

2. Choose your target OS, learn the native toolkit, implement the app, switch to other OS, implement again, rinse and repeat for all, and in the case of linux you have to deal with multiple toolkits and you have to know the quirks around Wayland support (with electron you don't necessarily as chromium handles most of that).

One of them simply takes way more time and effort than the other.

[stefan_]

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.

[_odey]

I mention it because that's basically what I keep reading related to it, the fact that it's incompletely implemented right now and some apps that used to work with X no longer do. Isn't it natural to consider it a potential risk for app development as well?

For the OS specific stuff that chromium doesen't handle, that's fair, hopefully I'll have to deal with as little of that as possible.

[cjaybo]

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

[_odey]

Can you please give me a list of examples I can evaluate myslef and decide if it's worth spending my time learning instead of going the Electron route?

[thesuperbigfrog]

Not the previous poster, but here is a list of cross-platform GUI libraries / toolkits:

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

[GirkovArpa]

Sciter is missing from that list for some reason.