11 ms·

The problem I see with Electron (and probably one of the reasons HN hates it) is that it leverages the advances in chip making to work as well as an app from 20

by yoz-y 9y ago

The problem I see with Electron (and probably one of the reasons HN hates it) is that it leverages the advances in chip making to work as well as an app from 20 years ago, but is multi platform. It is a huge productivity boost for programmers at the expense of making computers slow. On my work computer I am used to run many apps, and with each Electron app added I feel it slowing down. (latest one to switch was Skype for me). What is the point of having such powerful computers when they feel like slugs crawling through a bog?

beojan 9y ago
> It is a huge productivity boost for programmers at the expense of making computers slow. It's a productivity boost for web developers, who don't have to learn a new language, and for companies that can hire cheap web developers instead of more expensive desktop developers. It's not a productivity boost for someone who knows (or is willing to learn) .NET or Qt.
- laurent123456 9y ago
  Users benefit from it too since the alternative to Electron often is not .NET or Qt but no app at all, especially on Linux.
  - beojan 9y ago
    As far as I'm concerned, I'd rather have no app at all (and use an alternative) than have an Electron app suck users away from the potential native alternative.
    - thiht 9y ago
      So don't use it and use the web version. A potential native app is of no interest to me compared to an actual full featured Electron app.
      - beojan 9y ago
        If the Electron app exists, there's a lot less incentive to write the native one.
        mateuszf 9y ago
        If the Electron app exists, often the alternative is no app at all.
        OberstKrueger 9y ago
        See Slack. If Slack were still some plucky startup, I can understand it using Electron. But it's been around for a while now, and a more performant native application doesn't seem to be coming anytime soon.
        Aelius 9y ago
        Luckily Slack has the IRC and XMPP bridges. can't imagine any other protocols with a wealth of highly performant clients to choose from. Unlucky for me, my admins refuse to enable the bridges and also won't grant me an API key for use with the weechat slack plugin. I hate Slack so much. Slow and miserable and unconfigurable and just crashes at least once a month.
        detaro 9y ago
        Sadly, Slack also happily breaks the protocols in their bridges, e.g. producing invalid IRC usernames. So even though our Slack has the bridge enabled, I can't login to it since it wants me to put a dot in my nick.
        laurent123456 9y ago
        Skype for a long time only had an outdated application on Linux. Now that MS converted it to Electron, it's available and regularly updated. The truth is, even for huge companies like Microsoft, the cost of doing a Linux-specific app is not worth it given the small user base, but with Electron they get this for free so they do it. This is even more true for resource-limited open source projects, as cross-platform gui-based ones are difficult to get right, but Electron makes that easier.
  - swiley 9y ago
    I would rather run something in wine or run nothing at all than have to run an electron app. It's that bad.
    - h1d 9y ago
      How bad is it to run Electron apps on Linux?
      - pizzapill 9y ago
        Slack uses ~ 2 GB of Ram and ~ 10% CPU when idle. I used it for a short while but now I'm just leaving a Slack tab open in my browser. Its exactly the same functionality-wise. Basically I'm fine with Electron apps but I have yet to find one that I need and can't be replaced by a browser tab.
        danielbarla 9y ago
        Comments like this make me wonder what's going on exactly. Surely your browser tab should now be using ~2GB of Ram and ~10% CPU, since it's the browser, HTML and JS part of Electron that's causing all that? To be honest though, since my VS Code instance is sitting at ~500 MB (all processes together) and 0%, I'd wager it's not actually Electron itself that's at fault. It probably is incredibly inefficient compared to pure native code, and probably makes it easy to write inefficient code, but still, that's quite heavy usage you're referring to.
        pizzapill 9y ago
        My guess is that a lot of memory in the browser is shared. Another commentor in this thread wrote that VS Code is incredible efficient for a Electron app.
        danielbarla 9y ago
        That could certainly account for some of the memory usage. I'm still confused about why there would be a 10% cpu usage on one, and not on the browser version (especially if they are equivalent, or even share underlying code). VS Code certainly is efficient for an Electron app, and I'm sure it's really hard to achieve that level of efficiency. To be honest though, I use it side by side with Visual Studio itself, and on many metrics, it eats its big brother for breakfast (e.g. [1])... and that is a native app. One can argue that it's apples and oranges, and that the two are not equivalent, but we have an interesting counterpoint. While I'm sure performance is heavily weighted in favour of native, it seems like it's certainly surmountable. [1] https://twitter.com/id_aa_carmack/status/695013979807047680?lang=en https://twitter.com/id_aa_carmack/status/695013979807047680?...
  - megaman22 9y ago
    If it's a .NET app on Linux, you just run Wine, and you're all set.
- jampekka 9y ago
  This is the weird elitist argument again. I've done my share of native UI development, and it's total pain compared to HTML/CSS/JS. The tools are crap, the compile cycles too long, the languages to restrictive, the APIs too ad-hoc, the layout engines too crappy, the technology support (eg. multimedia) lagging too many years etc etc. The native libraries had decades to fix this mess, yet they're still by and large the same as decades ago. Will not miss them.
- alexbanks 9y ago
  > It's not a productivity boost for someone who knows (or is willing to learn) .NET or Qt. You do not understand what a productivity boost is if you think learning a totally new language and framework is a better choice than using the tools already available. But also if your logic were correct, we'd all still be writing C.
- JPKab 9y ago
  .net or qt don't offer all of the beautiful ui experiences available for the web. The latest and greatest in ui tech is now on the web in the form of JS/React/css.
  - beojan 9y ago
    Yes they do, with XAML and Qt Quick respectively. On the desktop, I'd rather have the normal menu + toolbars layout though.
digi_owl 9y ago
I fear the long term problem is that "programmers" gets further and further mentally removed from the hardware that their code will ultimately run on. There was already the problem of them using massively more powerful hardware than their customers, in particular in the consumer segment, but now more and more they seem to not even understand what a "computer" by the looks of it. With "cloud services" they do not need to think about the servers sitting in racks doing the computing. And with Electron, this kind of mental distance is making its way onto the desktop.
- lunfardo 9y ago
  Pretty sure your fear is the same that assembler programmers had when C programmers appear.
  - PopsiclePete 9y ago
    Pretty sure you don’t know what you’re talking about. Assembler programmers in the 50’s didn’t “fear” anything, much less C, which wasn’t even a spark in DMR’s eye, they just didn’t believe that a high-level language would be as efficient. Fortran with its 57 (?) optimization passes during compilation proved everyone wrong. But there was never “fear”. There is fear today though, and it’s very justified.
    - lunfardo 9y ago
      No, there is not fear in the industry. It is just people that refuse to learn js/html/css ecosystem that get outraged when see a electron app. Will you seriously think that a company like Skype didnt think and weight every option before doing their electron app? Sure enough they are not as efficient as native apps, and sure enough there are a lot of apps that thinks everyone have an i7 and 16 gb of ram, but the same problems had Java 20 years ago, pretty much with the same promises than Electron (Write Once, Run Anywhere), and it did pretty good.
      - blackoil 9y ago
        Java's run as desktop/web application platform, is nowhere good. It thrived on server, where WORA had limited appeal.
always_good 9y ago
Well, you have a choice, so I don't understand the hate. Okay, maybe you have to use Slack or Discord at work. Life and engineering are about trade-offs. That people use Electron apps despite the downsides just shows that these apps are delivering value to the world. Value that might not have existed had Electron not made it that much easier for people to get into desktop software. The complaining on HN reminds me of how my users get mad at me for not spending more of my free time developing the forum software. Like I'm trying to spite them. As if I just need to pull some knobs and levels. What's happening is that software is getting more and more accessible to people. Beginners are making games in Unity and iOS. Cultural channels into tech like Twitch and cryptocurrencies have been opening up. I watch my cousins' children open up the browser's console to delete annoying DOM nodes. What I suspect is that more and more people are getting into tech, so there are more and more people for you to disagree with about trade-offs.
- yoz-y 9y ago
  You can criticize something even if it does not directly affect you though. For example, I can live with Slack & Skype eating half of my ram but I really wish I would not have to. I really like Git Kraken, in theory, but if I imagine it as a native app it would be so much better. I see the appeal of Electron, and to be fair we also use it at work. However our application is destined to be running on a dedicated hardware which runs it and nothing else. Ultimately I'd like to see products like Slack starting with an Electron app and when the means permit it migrate to a native application. Not the other way around.
  - gldalmaso 9y ago
    If you consider that the browser is where most Electron app users actually begin using the app, you can only expect Electron to be replaced by some native app that runs the same code as the browser. This is the killer feature of Electron. Having a web app + native app means a huge leap in cost. Having no web app + native app means a huge loss in user reach. The only viable replacement would be something like Electron but with a stripped down browser fit to purpose instead of the huge surface-area of Chrome.
cosin 9y ago
Noob question. What makes electron apps slow? The electron framework or the web apps that it wraps?
- yoz-y 9y ago
  Electron apps are basically a Chrome window with a webpage loaded. This means that, for example, they use HTML to display the UI. HTML/CSS is complex and very dynamic, this makes it resource intensive to parse and load. Then, the whole application is written in JavaScript which is a language that is "far from the metal" (although this is getting better due to a massive investment of web browser developers). There is also a more hidden problem, which is that Electron app developers often come from a web background, which is a field with little concern for proper resource management and performance. If a webpage has a memory leak, just refresh it. If it takes too much memory, some other inactive tabs will get killed and be refreshed. VS Code is a good example of an Electron application made by people who are concerned by performance. However, developing a performant application using Electron seems to be harder than actually doing it in another language/framework.
rtpg 9y ago
Yep, I totally get this. There's a world in which Electron (or rather, "web views as apps") don't exist and Slack is native. Though perhaps it wouldn't have ever happened. I feel like _many_ of the big apps simply wouldn't have existed in the old model. Native app development has become extremely niche, and each OS has its own quirks. And on the other side of the fence, stuff like Salesforce exist in the browser pretty well. It's hard to get the causal arrows right on this. But I bet if React Native-style solutions can work well, people would be willing to put in the effort to use it. But so long as the web stack is easier for developers, that'll be where the MVPs get made IMO.
- beojan 9y ago
  > But so long as the web stack is easier for developers, that'll be where the MVPs get made IMO. Is it really easier for developers, or do people learn web development first, so it's easier to use the same skills on the desktop than learn new ones? If find it hard to believe React etc. are easier than .Net, for instance.
  - yoz-y 9y ago
    Reactive UI is easier to reason about I'd say. One thing I'd like to see is a native reactive UI framework that would be thought as such from the ground up. So far react on web is a whole bunch of hacks and react native also wraps classic UI elements.
  - rtpg 9y ago
    UI debugging tools in the web are amazing. I can inspect the entire DOM, add code to test some new concepts, edit layout and get instant results. To my knowledge, almost no native UI libraries have good support for CSS-style selectors. Being able to write out selection rules like "odd elements in this kind of list of elements" is extremely useful. This is going to sound silly, but almost no native UI toolkit has a good "screenshots" section on its website. Meanwhile you go over to Bootstrap and you see stuff you actually recognize. This is important! It proves that you can actually make nice looking things. Stuff like interface designers shipped by MSFT are pretty great though.
nkkollaw 9y ago
As a Linux user, it's a huge productivity boost because I wouldn't be able to use 90% of the app I us since they wouldn't be available on Linux. I also don't notice my machine slowing down with Electron apps.
- jnbiche 9y ago
  > As a Linux user, it's a huge productivity boost because I wouldn't be able to use 90% of the app I us since they wouldn't be available on Linux. That's not true. There are native cross-platform GUI toolkits, such as Qt. There's just as much reason for a Qt app to run on Linux as an Electron app.
  - 9point6 9y ago
    I think the guy you're replying to's point is that Qt versions of the apps he uses don't exist - the Electron ones do. The alternative to many Electron apps isn't a native app in another framework, it would simply be no app (on linux).
    - imtringued 9y ago
      Usually the alternative to many electron apps is the web version which lacks 5% of the features but is 10 times more efficient.
      - yoz-y 9y ago
        Native and Electron apps have two advantages over web though. Fist one is, that they do have access to the file system. This makes a whole range of applications (like Git Kraken) possible. The other is that an application has an icon in the taskbar/dock. When somebody pings me on slack I know where to go to read it. When somebody calls me in hangouts, I have to go fishing for the tab or window with the site open.
      - nkkollaw 9y ago
        Not true. One example of a service that probably _could_ have a web version is Spotify, but they only offer their service via their Electron app. Apps I care about are VSCode, Atom, Spotify, Slack.
jochung 9y ago
If you want to make Electron obsolete, make a cross platform UI toolkit that mixes UI and document-style content as good as HTML/CSS does. End user expectations are for complex layouts, flexible typography, rich media embedding, animated interactions, and so on. I've yet to see a QT app come close to what e.g. Slack has managed to shoehorn in. It'd be great if we could get desktop level robustness out of it too, instead of being limited to scrolling three or four screens up before it has to start paging out content. Web UI is bad in many ways, but many desktop adherents seem willfully oblivious about why there is such a desire for this. The only native OS that has evolved to compete is MacOS, with its multi touch driven interactions genuinely making most web stuff feel like the janky lowest common denominator that it is.
- mixedCase 9y ago
  What you want is all available in Qt via QtQuick, where you can use QML to define you interface declaratively (in a better way than html+css) and JS for logic with the option of dropping down to C++ or another language with bindings.
  - jochung 9y ago
    If you think that, you don't understand the nature of what is being done with HTML nowadays. It's not about declarative markup, it's about efficient updating of a UI whose shape is completely decoupled from the shape of the state it is representing.
    - mixedCase 9y ago
      I'm a professional web developer, I'd like to think I know what I'm doing. And I believe you contradicted yourself, leveraging a Virtual DOM to update the DOM (which has an imperative API) from the changes that exist in two sets of data —both products of (an ideally) pure transformation from high-level data— is very much declarative programming. Meanwhile QML provides you with the same kind of programming paradigm except that you do not have a DOM, you have the QtQuick Scene Graph which calculates how to render your new state in the most efficient way; and, worth mentioning, in a much more efficient way than a standard browser stack would be able to under regular circumstances.
psyc 9y ago
Is there not one engineer on this whole planet with the skill and motivation to make a cross-platform typescript+GUI thing that is efficient from the ground up? I'm often baffled by the seemingly obvious gaps that exist in this profession.

by yoz-y 9y ago

beojan 9y ago

> It is a huge productivity boost for programmers at the expense of making computers slow. It's a productivity boost for web developers, who don't have to learn a new language, and for companies that can hire cheap web developers instead of more expensive desktop developers. It's not a productivity boost for someone who knows (or is willing to learn) .NET or Qt.

laurent123456 9y ago
Users benefit from it too since the alternative to Electron often is not .NET or Qt but no app at all, especially on Linux.
- beojan 9y ago
  As far as I'm concerned, I'd rather have no app at all (and use an alternative) than have an Electron app suck users away from the potential native alternative.
  - thiht 9y ago
    So don't use it and use the web version. A potential native app is of no interest to me compared to an actual full featured Electron app.
    - beojan 9y ago
      If the Electron app exists, there's a lot less incentive to write the native one.
      - mateuszf 9y ago
        If the Electron app exists, often the alternative is no app at all.
      - OberstKrueger 9y ago
        See Slack. If Slack were still some plucky startup, I can understand it using Electron. But it's been around for a while now, and a more performant native application doesn't seem to be coming anytime soon.
        Aelius 9y ago
        Luckily Slack has the IRC and XMPP bridges. can't imagine any other protocols with a wealth of highly performant clients to choose from. Unlucky for me, my admins refuse to enable the bridges and also won't grant me an API key for use with the weechat slack plugin. I hate Slack so much. Slow and miserable and unconfigurable and just crashes at least once a month.
        detaro 9y ago
        Sadly, Slack also happily breaks the protocols in their bridges, e.g. producing invalid IRC usernames. So even though our Slack has the bridge enabled, I can't login to it since it wants me to put a dot in my nick.
        laurent123456 9y ago
        Skype for a long time only had an outdated application on Linux. Now that MS converted it to Electron, it's available and regularly updated. The truth is, even for huge companies like Microsoft, the cost of doing a Linux-specific app is not worth it given the small user base, but with Electron they get this for free so they do it. This is even more true for resource-limited open source projects, as cross-platform gui-based ones are difficult to get right, but Electron makes that easier.
- swiley 9y ago
  I would rather run something in wine or run nothing at all than have to run an electron app. It's that bad.
  - h1d 9y ago
    How bad is it to run Electron apps on Linux?
    - pizzapill 9y ago
      Slack uses ~ 2 GB of Ram and ~ 10% CPU when idle. I used it for a short while but now I'm just leaving a Slack tab open in my browser. Its exactly the same functionality-wise. Basically I'm fine with Electron apps but I have yet to find one that I need and can't be replaced by a browser tab.
      - danielbarla 9y ago
        Comments like this make me wonder what's going on exactly. Surely your browser tab should now be using ~2GB of Ram and ~10% CPU, since it's the browser, HTML and JS part of Electron that's causing all that? To be honest though, since my VS Code instance is sitting at ~500 MB (all processes together) and 0%, I'd wager it's not actually Electron itself that's at fault. It probably is incredibly inefficient compared to pure native code, and probably makes it easy to write inefficient code, but still, that's quite heavy usage you're referring to.
        pizzapill 9y ago
        My guess is that a lot of memory in the browser is shared. Another commentor in this thread wrote that VS Code is incredible efficient for a Electron app.
        danielbarla 9y ago
        That could certainly account for some of the memory usage. I'm still confused about why there would be a 10% cpu usage on one, and not on the browser version (especially if they are equivalent, or even share underlying code). VS Code certainly is efficient for an Electron app, and I'm sure it's really hard to achieve that level of efficiency. To be honest though, I use it side by side with Visual Studio itself, and on many metrics, it eats its big brother for breakfast (e.g. [1])... and that is a native app. One can argue that it's apples and oranges, and that the two are not equivalent, but we have an interesting counterpoint. While I'm sure performance is heavily weighted in favour of native, it seems like it's certainly surmountable. [1] https://twitter.com/id_aa_carmack/status/695013979807047680?lang=en https://twitter.com/id_aa_carmack/status/695013979807047680?...
- megaman22 9y ago
  If it's a .NET app on Linux, you just run Wine, and you're all set.
jampekka 9y ago
This is the weird elitist argument again. I've done my share of native UI development, and it's total pain compared to HTML/CSS/JS. The tools are crap, the compile cycles too long, the languages to restrictive, the APIs too ad-hoc, the layout engines too crappy, the technology support (eg. multimedia) lagging too many years etc etc. The native libraries had decades to fix this mess, yet they're still by and large the same as decades ago. Will not miss them.
alexbanks 9y ago
> It's not a productivity boost for someone who knows (or is willing to learn) .NET or Qt. You do not understand what a productivity boost is if you think learning a totally new language and framework is a better choice than using the tools already available. But also if your logic were correct, we'd all still be writing C.
JPKab 9y ago
.net or qt don't offer all of the beautiful ui experiences available for the web. The latest and greatest in ui tech is now on the web in the form of JS/React/css.
- beojan 9y ago
  Yes they do, with XAML and Qt Quick respectively. On the desktop, I'd rather have the normal menu + toolbars layout though.

digi_owl 9y ago

I fear the long term problem is that "programmers" gets further and further mentally removed from the hardware that their code will ultimately run on. There was already the problem of them using massively more powerful hardware than their customers, in particular in the consumer segment, but now more and more they seem to not even understand what a "computer" by the looks of it. With "cloud services" they do not need to think about the servers sitting in racks doing the computing. And with Electron, this kind of mental distance is making its way onto the desktop.

lunfardo 9y ago
Pretty sure your fear is the same that assembler programmers had when C programmers appear.
- PopsiclePete 9y ago
  Pretty sure you don’t know what you’re talking about. Assembler programmers in the 50’s didn’t “fear” anything, much less C, which wasn’t even a spark in DMR’s eye, they just didn’t believe that a high-level language would be as efficient. Fortran with its 57 (?) optimization passes during compilation proved everyone wrong. But there was never “fear”. There is fear today though, and it’s very justified.
  - lunfardo 9y ago
    No, there is not fear in the industry. It is just people that refuse to learn js/html/css ecosystem that get outraged when see a electron app. Will you seriously think that a company like Skype didnt think and weight every option before doing their electron app? Sure enough they are not as efficient as native apps, and sure enough there are a lot of apps that thinks everyone have an i7 and 16 gb of ram, but the same problems had Java 20 years ago, pretty much with the same promises than Electron (Write Once, Run Anywhere), and it did pretty good.
    - blackoil 9y ago
      Java's run as desktop/web application platform, is nowhere good. It thrived on server, where WORA had limited appeal.

always_good 9y ago

Well, you have a choice, so I don't understand the hate. Okay, maybe you have to use Slack or Discord at work. Life and engineering are about trade-offs. That people use Electron apps despite the downsides just shows that these apps are delivering value to the world. Value that might not have existed had Electron not made it that much easier for people to get into desktop software. The complaining on HN reminds me of how my users get mad at me for not spending more of my free time developing the forum software. Like I'm trying to spite them. As if I just need to pull some knobs and levels. What's happening is that software is getting more and more accessible to people. Beginners are making games in Unity and iOS. Cultural channels into tech like Twitch and cryptocurrencies have been opening up. I watch my cousins' children open up the browser's console to delete annoying DOM nodes. What I suspect is that more and more people are getting into tech, so there are more and more people for you to disagree with about trade-offs.

yoz-y 9y ago
You can criticize something even if it does not directly affect you though. For example, I can live with Slack & Skype eating half of my ram but I really wish I would not have to. I really like Git Kraken, in theory, but if I imagine it as a native app it would be so much better. I see the appeal of Electron, and to be fair we also use it at work. However our application is destined to be running on a dedicated hardware which runs it and nothing else. Ultimately I'd like to see products like Slack starting with an Electron app and when the means permit it migrate to a native application. Not the other way around.
- gldalmaso 9y ago
  If you consider that the browser is where most Electron app users actually begin using the app, you can only expect Electron to be replaced by some native app that runs the same code as the browser. This is the killer feature of Electron. Having a web app + native app means a huge leap in cost. Having no web app + native app means a huge loss in user reach. The only viable replacement would be something like Electron but with a stripped down browser fit to purpose instead of the huge surface-area of Chrome.

cosin 9y ago

Noob question. What makes electron apps slow? The electron framework or the web apps that it wraps?

yoz-y 9y ago
Electron apps are basically a Chrome window with a webpage loaded. This means that, for example, they use HTML to display the UI. HTML/CSS is complex and very dynamic, this makes it resource intensive to parse and load. Then, the whole application is written in JavaScript which is a language that is "far from the metal" (although this is getting better due to a massive investment of web browser developers). There is also a more hidden problem, which is that Electron app developers often come from a web background, which is a field with little concern for proper resource management and performance. If a webpage has a memory leak, just refresh it. If it takes too much memory, some other inactive tabs will get killed and be refreshed. VS Code is a good example of an Electron application made by people who are concerned by performance. However, developing a performant application using Electron seems to be harder than actually doing it in another language/framework.

rtpg 9y ago

Yep, I totally get this. There's a world in which Electron (or rather, "web views as apps") don't exist and Slack is native. Though perhaps it wouldn't have ever happened. I feel like _many_ of the big apps simply wouldn't have existed in the old model. Native app development has become extremely niche, and each OS has its own quirks. And on the other side of the fence, stuff like Salesforce exist in the browser pretty well. It's hard to get the causal arrows right on this. But I bet if React Native-style solutions can work well, people would be willing to put in the effort to use it. But so long as the web stack is easier for developers, that'll be where the MVPs get made IMO.

beojan 9y ago
> But so long as the web stack is easier for developers, that'll be where the MVPs get made IMO. Is it really easier for developers, or do people learn web development first, so it's easier to use the same skills on the desktop than learn new ones? If find it hard to believe React etc. are easier than .Net, for instance.
- yoz-y 9y ago
  Reactive UI is easier to reason about I'd say. One thing I'd like to see is a native reactive UI framework that would be thought as such from the ground up. So far react on web is a whole bunch of hacks and react native also wraps classic UI elements.
- rtpg 9y ago
  UI debugging tools in the web are amazing. I can inspect the entire DOM, add code to test some new concepts, edit layout and get instant results. To my knowledge, almost no native UI libraries have good support for CSS-style selectors. Being able to write out selection rules like "odd elements in this kind of list of elements" is extremely useful. This is going to sound silly, but almost no native UI toolkit has a good "screenshots" section on its website. Meanwhile you go over to Bootstrap and you see stuff you actually recognize. This is important! It proves that you can actually make nice looking things. Stuff like interface designers shipped by MSFT are pretty great though.

nkkollaw 9y ago

As a Linux user, it's a huge productivity boost because I wouldn't be able to use 90% of the app I us since they wouldn't be available on Linux. I also don't notice my machine slowing down with Electron apps.

jnbiche 9y ago
> As a Linux user, it's a huge productivity boost because I wouldn't be able to use 90% of the app I us since they wouldn't be available on Linux. That's not true. There are native cross-platform GUI toolkits, such as Qt. There's just as much reason for a Qt app to run on Linux as an Electron app.
- 9point6 9y ago
  I think the guy you're replying to's point is that Qt versions of the apps he uses don't exist - the Electron ones do. The alternative to many Electron apps isn't a native app in another framework, it would simply be no app (on linux).
  - imtringued 9y ago
    Usually the alternative to many electron apps is the web version which lacks 5% of the features but is 10 times more efficient.
    - yoz-y 9y ago
      Native and Electron apps have two advantages over web though. Fist one is, that they do have access to the file system. This makes a whole range of applications (like Git Kraken) possible. The other is that an application has an icon in the taskbar/dock. When somebody pings me on slack I know where to go to read it. When somebody calls me in hangouts, I have to go fishing for the tab or window with the site open.
    - nkkollaw 9y ago
      Not true. One example of a service that probably _could_ have a web version is Spotify, but they only offer their service via their Electron app. Apps I care about are VSCode, Atom, Spotify, Slack.

jochung 9y ago

If you want to make Electron obsolete, make a cross platform UI toolkit that mixes UI and document-style content as good as HTML/CSS does. End user expectations are for complex layouts, flexible typography, rich media embedding, animated interactions, and so on. I've yet to see a QT app come close to what e.g. Slack has managed to shoehorn in. It'd be great if we could get desktop level robustness out of it too, instead of being limited to scrolling three or four screens up before it has to start paging out content. Web UI is bad in many ways, but many desktop adherents seem willfully oblivious about why there is such a desire for this. The only native OS that has evolved to compete is MacOS, with its multi touch driven interactions genuinely making most web stuff feel like the janky lowest common denominator that it is.

mixedCase 9y ago
What you want is all available in Qt via QtQuick, where you can use QML to define you interface declaratively (in a better way than html+css) and JS for logic with the option of dropping down to C++ or another language with bindings.
- jochung 9y ago
  If you think that, you don't understand the nature of what is being done with HTML nowadays. It's not about declarative markup, it's about efficient updating of a UI whose shape is completely decoupled from the shape of the state it is representing.
  - mixedCase 9y ago
    I'm a professional web developer, I'd like to think I know what I'm doing. And I believe you contradicted yourself, leveraging a Virtual DOM to update the DOM (which has an imperative API) from the changes that exist in two sets of data —both products of (an ideally) pure transformation from high-level data— is very much declarative programming. Meanwhile QML provides you with the same kind of programming paradigm except that you do not have a DOM, you have the QtQuick Scene Graph which calculates how to render your new state in the most efficient way; and, worth mentioning, in a much more efficient way than a standard browser stack would be able to under regular circumstances.

psyc 9y ago

Is there not one engineer on this whole planet with the skill and motivation to make a cross-platform typescript+GUI thing that is efficient from the ground up? I'm often baffled by the seemingly obvious gaps that exist in this profession.