6 ms·

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

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.

zaro 6y ago
You should check Gnome Disks, it alrady has bencmarking builtin and is installed by default on Gnome environments.
- sdwolfz 6y ago
  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 6y ago
    A few years ago Ubuntu was still using Unity.
- jsight 6y ago
  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.
stefan_ 6y ago
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.
- sdwolfz 6y ago
  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.
  - cjaybo 6y ago
    This is a false dichotomy. There are plenty of cross-platform toolkits that are far leaner than electron.
    - sdwolfz 6y ago
      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 6y ago
        Not the previous poster, but here is a list of cross-platform GUI libraries / toolkits: https://en.wikipedia.org/wiki/List_of_platform-independent_GUI_libraries https://en.wikipedia.org/wiki/List_of_platform-independent_G...
        GirkovArpa 6y ago
        Sciter is missing from that list for some reason.
AnIdiotOnTheNet 6y ago
Werid. You hate the language and the bloat, but you still would choose Electron over something like Lazarus?
- dave84 6y ago
  > Reusing to the frontend skills I learned throughout the years Not weird at all.
  - sdwolfz 6y ago
    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 6y ago
      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.
      - sdwolfz 6y ago
        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.
jsdavid 6y ago
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.
- sdwolfz 6y ago
  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 6y ago
    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 https://news.ycombinator.com/item?id=23163960
    - jakelazaroff 6y ago
      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 6y ago
        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.
jcelerier 6y ago
> 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 https://github.com/jcelerier/fio-ui
- sdwolfz 6y ago
  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 6y ago
    > 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_ 6y ago
      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).
pwdisswordfish4 6y ago
> 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 6y ago
  > 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 6y ago
    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.
fulafel 6y ago
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 6y ago

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

sdwolfz 6y ago
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 6y ago
  A few years ago Ubuntu was still using Unity.
jsight 6y ago
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.

stefan_ 6y ago

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.

sdwolfz 6y ago
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.
- cjaybo 6y ago
  This is a false dichotomy. There are plenty of cross-platform toolkits that are far leaner than electron.
  - sdwolfz 6y ago
    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 6y ago
      Not the previous poster, but here is a list of cross-platform GUI libraries / toolkits: https://en.wikipedia.org/wiki/List_of_platform-independent_GUI_libraries https://en.wikipedia.org/wiki/List_of_platform-independent_G...
      - GirkovArpa 6y ago
        Sciter is missing from that list for some reason.

AnIdiotOnTheNet 6y ago

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

dave84 6y ago
> Reusing to the frontend skills I learned throughout the years Not weird at all.
- sdwolfz 6y ago
  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 6y ago
    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.
    - sdwolfz 6y ago
      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.

jsdavid 6y ago

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.

sdwolfz 6y ago
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 6y ago
  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 https://news.ycombinator.com/item?id=23163960
  - jakelazaroff 6y ago
    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 6y ago
      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.

jcelerier 6y ago

> 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 https://github.com/jcelerier/fio-ui

sdwolfz 6y ago
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 6y ago
  > 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_ 6y ago
    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).

pwdisswordfish4 6y ago

> 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 6y ago
> 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 6y ago
  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.

fulafel 6y ago

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.