Well on second thought I guess qbrt is more or less trying to solve the same problem as Electron, without being compatible as it is "simplifying the process of developing and packaging a desktop app using web technologies."
Electron apps display misleading RAM statistics in Task Manager, at least on Windows. There are multiple content processes that you have to compare paths to find.
not open source, for one. looks interesting, and it might be a pragmatic choice if you're a company developing a desktop app, but for a hobbyist programmer i see no real appeal in a closed source framework.
https://sciter.com/prices/. It has a free binary-only tier. Not entirely sure what the restrictions are. I also don't quite get their renewal pricing - it's not cheap at all.
There's a little known Microsoft framework that allows html and JavaScript to be compiled into an exe using ie, but its so obscure I couldn't find it after five minutes of googling. And obviously it's not cross platform.
I actually liked active Desktop. You could have animated wallpapers and system information embedded on your Desktop back in windows 98, it was a shame it got removed. Nowadays you have to use rain meter if you want to do any of that stuff
I'm a web dev but I don't have a MacBook. Does that make me better or worse?
Also tell me more about your Amiga
Edit: I realise that probably looked like I was having a go, but I was actually trying to diffuse the argument. I'm genuinely interested in the Amiga, if you have one. Do you use it for work?
> "Is Gecko better than Chromium in certain cases?"
Yes, in certain cases. However, I don't think it's worth another flame war about this. Even if I posted some benchmarks all you'd have is a stream of people sharing their anecdata trying to confirm or deny the accuracy of the benchmarks. Can we nip this in the bud before it begins and just be glad that Electron has some competition to help push it forward?
Agreed. I'm not a fan of web apps/wrappers in general, but they're here and they're clearly not going away any time soon, so it's important that they don't become steeped in a Blink-based monoculture. Competition is healthy.
my thoughts exactly. mozilla arguably set the ball rolling on this stuff with the Prism project, which allowed turning web-pages into chromeless browser window apps, with their own desktop icons and everything
One difference (Don't know if its a benefit) is that it uses a common runtime. Two qbrt apps would use the same installed version of Firefox Nightly, so app download sizes would be smaller. If you read these electron threads this is something that comes up a lot.
Firefox's latest build made significant RAM usage improvements [1], leapfrogging Chrome when it came to multiple tabs.
the same way that the JVM works, at least in theory.
You have the base virtual machine installed, and then the app just needs to ship the code itself.
You could even ship with an "install script header", like "if this isn't installed, offer to download and install it". I imagine a lot of us have seen these kinds of installers before.
I don't understand how that would be different than Electron or nw.js.
For example, if there were a Debian package for either of those, all apps leveraging them would just declare that same package a dependency and you'd have a single system-wide install for the large binary everyone keeps complaining about. (AFAICT there is no such deb package for any of the above.)
Electron is designed to be bundled into your app, I'm not aware of any distros/package tools that allow Electron apps to share a runtime.
The JVM (and apparently qbrt) is designed to be shared, apps are expected to use the installed system version of the VM, though if the packager wants they can include a specific version to use.
I wish it were easy/possible to get Electron apps to share things, it bothers me that Chrome, Discord, and Slack almost certainly could share most of their hundreds of megabytes.
You can install electron globally but if you package your app to target electron prebuilt you'd have to require the use to have installed both it and nodejs already.
It's not completely bonkers. It could be possible to make a web installer that checks for node and electron and downloads them if necessary. Nobody seems to do that though. Every electron app bundles electron. At least every one I've seen
Part of the problem here is that the entire JS ecosystem is built around local copies of things, so there might not be a lot of institutional knowledge in that corner of OSS to pull off the "shared env" thing quite well.
That plus scarring from browser differences over N years.
Of course it's still totally possible, but there are probably gotchas that aren't obvious if you're mainly a web developer.
You may bundle the Electron runtime in an app or not. An app is started by "electron main.js", so once Electron is installed you have just to download an app and create an icon. Example with https://github.com/Scriptol/Advanced-Editor
In theory the app could actually be cross platform for every platform that supports nodejs and gecko instead of being only cross platform for the platforms that the developer wants to support. You'd have a generic build where native libraries are compiled with webassembly and then specialised builds for each supported platform for more performance.
No offence, but please write your desktop "apps" as native programs or don't write them at all, we have enough of this slow and bloated web shit on desktop already. Sorry.
Don't forget better UX. The whole practice of UX is utter hogwash. Comparisons between 3 or 4 (or 100) solutions that are shitty at baseline is not honest at all.
If they are of higher quality, yes. In fact, there are plenty of useful and native applications which many just haven't discovered --- you could argue they spent far more effort on the product than marketing it. Related: https://news.ycombinator.com/item?id=14748924
What incentive does any developer have to do as you say?
I'm not the one you're replying to, but as developer myself I don't want to have to put up with "this slow and bloated web shit on desktop" either. IMHO increasing the combined computing resource consumption of all your users significantly just so you can make your product a little more easily is the complete opposite of being a good developer.
The argument about it being "easier" might be questionable too --- I've been programming native GUI apps for over a decade and for the type of functionality that a lot of these web-app-packaged-with-browser monstrosities are doing, it'd probably take me far less time to write something in pure Win32 and X than download and figure out how to use Electron. Some may argue that the initial learning curve is steeper, but then after that you're a "real native coder" instead of a "web apper" and will be making far more efficient applications for everyone.
Yes, precisely like Facebook "Internet" is worse than nothing. Things like these will bite us in the ass in the future, better to stop it as soon as possible.
Personally, I'd rather have fewer webapps (which is what these really are) bundled into bloated browsers and called "desktop" or "native".
If you're going to put in the effort to write a proper desktop application with native components through Qt, .NET, Java or OpenGL or something, go ahead but please don't bother with webapps with a browser wrapper, just leave them on the web where they belong. If you need a little more integration, do it with a browser extension.
I'm yet to see a single necessary Electron port.
> What incentive does any developer have to do as you say?
The top comment on any news article or discussion forum being something other than "great, another unnecessary Electron app that'll waste my CPU, RAM and battery".
I use Linux as my desktop and the rising popularity of electron means that most "cross platform desktop app" links which used to mean "we do windows AND mac!" are actually cross-platform, are usable on Linux and are feature-complete and behave the same as on other platforms.
Electron has been a godsend to Linux users and it can definitely be highly performant. I've even switched from vim to vscode because the latter is actually the slickest IDE I've ever used.
You're yet to see a single necessary electron port? Well, I use 4 all the time, probably none of which would even be Linux-compatible were it not for electron. YMMV.
> means that most "cross platform desktop app" links which used to mean "we do windows AND mac!" are actually cross-platform
The "cross platform desktop apps" I'm objecting to are really just webapps that could run just as well in a browser without the wrapper. If they weren't released in a wrapper at all, they'd still be cross platform.
> I've even switched from vim to vscode because the latter is actually the slickest IDE I've ever used.
VSCode and Atom make a little more sense in Electron because they actually have requirements that can't be met when run purely in a browser (like running a build system). I still prefer a native IDE like Sublime Text but I can see also see the benefit of using Electron here. The apps I have problems with are the webapp ports like Slack, Discord and Spotify.
> You're yet to see a single necessary electron port? Well, I use 4 all the time
What are they? What makes them necessary (other than VSCode, which I understand as explained above)?
Unless you can put the [little used] HTML5 FileSystem API into full-effect, by creating a full-blown Unix-like operating system (complete with a desktop environment) that runs inside of a browser tab (ie, is "just" a web page)... so that whatever music files are kept in this browser-sandboxed filesystem become your local music library.
(Yes, this idea is slowly but surely becoming a reality... I'm the creator of a little thing called "Linux on the Web", at https://linuxontheweb.org)
"I use Linux as my desktop and the rising popularity of electron means that most "cross platform desktop app" links which used to mean "we do windows AND mac!" are actually cross-platform, are usable on Linux and are feature-complete and behave the same as on other platforms."
This. Electron makes it economically and technically feasible for companies to deliver the same features and support to Linux users as their other customers.
The thing is often not explicitly stated is that many companies using Electron are not desktop software vendors, but SaaS providers. They aren't going to do native desktop applications, because they just want to provide nice clients to users for their particular service.
I've considered using Qt in the past as it seems like a good GUI framework, but there seems to be one technical factor that holds it back from even greater market share, which is language bindings.
If you program in C++ or Python, no problem, both have good support for Qt. However, outside those two languages it seems that the available bindings tend to be small projects rather than something robustly tested. That's appeared to be the case a few years ago at least, would be happy to be proved wrong.
I'm not suggesting this is a JavaScript-specific issue, there are plenty of other languages without solid Qt bindings, and the suggestion that someone should learn a whole new language just to use one library is a little absurd.
> "If they want to ship a product with good UI/UX quality, then they should learn the supported languages."
The time sunk in learning a new programming language is not inconsequential. You can get to a basic level of proficiency relatively quickly, but being productive in a language takes time and effort.
If I took your approach I'd constantly need to switch languages and rely on glue logic to piece them together. Just because a language is 'the best' at one thing doesn't mean it's always the right choice for a project that has multiple requirements. Should all regular expressions be written in Perl? Should all mathematical operations be written in Fortran? Should all macros be written in Common Lisp? Should all data structures be described in Idris?
That's not what we're talking about though. What we're talking about is developing outside the bounds of battle-tested stacks.
To use another example, let's say I was writing an app in C#. Should I use a JVM GUI library just because I liked it better than the .NET ones? Even if it's technically possible, it's far from optimal.
The strategy behind JavaScript is to write your application as close to one time(s) as possible. Adding Python or c++ defeats this goal. For most startups looking to build their MVP, the cost of c++ dev (in addition to writing your codebase a second time) would be dangerously unpredictable in cost and stability if they're not already using c++. Python is missing strong alternatives to both writing UI code in the browser and alternatives to react-native. It's also not reliably faster or better than nodejs in any metric outside of a few unrelated top libraries like numpy and ML. The JavaScript community is also interested in an electron alternative and proper QT bindings to nodejs would be a valuable first step to solving the electron problem, if another solution isn't established via react-native/native-script.
> If you're going to put in the effort to write a proper desktop application with native components through Qt, .NET, Java or OpenGL or something, go ahead but please don't bother with webapps with a browser wrapper, just leave them on the web where they belong. If you need a little more integration, do it with a browser extension.
Yeah... no. I'm not that fond of using Electron apps (Atom, Slack...) myself, but I absolutely don't want them in a browser window. Writing a "native" application simply isn't an option in many cases.
> The top comment on any news article or discussion forum being something other than "great, another unnecessary Electron app that'll waste my CPU, RAM and battery".
So what? There's the same handful of curmudgeons posting that comment everywhere. That doesn't mean they're valuable as a demographic. It depends on the market of course, but if your application solves a problem that nothing else solves as well (as it should), then running on Electron is not a dealbreaker. Most ordinary users can't tell and don't know to care.
> but I absolutely don't want them in a browser window.
But that's exactly what you're getting when they're run as Electron apps. The main difference being that they consume more system resources than an actual browser window because they can't share any resources with your actual browser.
> So what?
> Most ordinary users can't tell and don't know to care.
The problem is that the complaints of CPU, RAM and battery degradation are valid complaints. I think you'll find that many users can tell that their machine has become slower or has a faster draining battery but they won't know to blame the browser wrapper for it. Take Spotify (which uses Chromium Embedded Framework) for example:
> But that's exactly what you're getting when they're run as Electron apps.
Well, no it isn't. If you can't even make that distinction, then having any further conversation with you is going to be pointless.
I suppose you would welcome the use of progressive web apps, but those haven't yet "arrived". If they did, I might argue for using them over things like Electron.
> The problem is that the complaints of CPU, RAM and battery degradation are valid complaints.
Many complaints about web technology are valid, that doesn't mean they invalidate its use. The reality is that even a company like Spotify would rather drain its users batteries than develop native apps. It's a tradeoff.
If Spotify followed through with your advice, those users should not be offered a desktop app at all, they should be forced to only use the website and have their browser drain the battery instead. You're effectively arguing for less choice when a native app is not an option. That doesn't make sense to me.
> Well, no it isn't. If you can't even make that distinction, then having any further conversation with you is going to be pointless.
What is the distinction you want me to make? That it has a different icon in your OS task bar?
> If Spotify followed through with your advice, those users should not be offered a desktop app at all, they should be forced to only use the website and have their browser drain the battery instead.
My argument is that by sharing resources with the browser they're running anyway, that the battery/CPU/RAM drain will be reduced. A browser is a lot of overhead and using less browsers at once is always good.
> You're effectively arguing for less choice when a native app is not an option. That doesn't make sense to me.
The reason is that these browser wrappers are marketed deceptively, so users aren't equipped to make an informed decision about whether to use them.
Users generally expect that when they download a desktop application, that it's native, has minimal overhead and performs well. Browser-wrappers don't meet these expectations. Users don't realise they're downloading an extra browser and all the overhead it entails.
If users realised that these were just another browser that can only open one website, I'm sure their feelings would be substantially different.
They think that when they download Spotify, it's going to perform like VLC or Winamp and it absolutely doesn't.
> What is the distinction you want me to make? That it has a different icon in your OS task bar?
That's one! So, it's already not exactly the same. Figuring out the rest shall be left as an exercise to the reader.
> My argument is that by sharing resources with the browser they're running anyway, that the battery/CPU/RAM drain will be reduced. A browser is a lot of overhead and using less browsers at once is always good.
You are describing one trade-off. Your argument is valid, but if you follow the links you yourself posted, it's not actually the browser engine that does all the draining, it's the content it is running (i.e. you can disable some functionality and the problem is mitigated). The base RAM overhead of running Electron compared to something like Qt isn't that big either.
> Users generally expect that when they download a desktop application, that it's native, has minimal overhead and performs well.
I don't think that's true, but even if it was, so what? Users need to lower their expectations.
I find that complaining about something without providing suggestions to be unproductive. It's very easy to complain and say things are bad. Anyone can do that.
There are reasons why people are doing things this way. Just like the discussion of why people have 1000+ tabs. You could try to understand the underlying reasons vs just criticize.
What would you rather people do? Code it in Qt? Code it in Java? Code it for each platform specifically? If so, why aren't people doing that?
I value cross-platform support greatly because I run Linux on desktop, Windows on laptop, and I have a Mac Mini as well.
I use Moneydance [1] as my personal finance tracking software. It's written in Java for cross-platform support. I use it on Linux and on Windows. If it was written in Electron, I'd still use it. Why? Cross-platform support is important to me.
That's an interesting example, because I really want a Quicken alternative, but I didn't go with Moneydance in part because of the Java requirement. I don't want to be constantly patching yet another insecure runtime. Bundling Java with the app is better from a usability perspective, but then I can't be sure if they're keeping it patched, and it's still a non-native & bloated experience.
I value cross-platform too, and there are lots of native apps that manage that without Electron or Java. From my toolkit I can see Sublime Edit (of course), also Photoshop, Affinity Photo, Renoise, Melodyne, iZotope RX, Tower, Beyond Compare, Postbox, VLC. Also tons of audio VST effects plugins.
When I make native cross-platform desktop apps, I usually lean towards Xojo (aka REALbasic), which also has Linux support. And for my cross-platform Photoshop plug-in effects, the Windows versions are in C / Win32 while the Mac version is a C++/Obj-C framework I made to let me use the same code on both Windows & Mac without changes.
No offense, but what makes you think (potential) customers like you are so valuable that serving their pet peeves becomes a sane business decision?
Everyone is moving to web technology because it cuts down on cost on many fronts, not because it's the better technology. Finding web developers is easy and using Electron (etc) gives free cross-platform support, which is very valuable. It's all about economics, not quality.
> Also, qbrt doesn’t yet support runtime version management (i.e. being able to specify which version of Gecko to use, and to switch between them). At the time you install it, it downloads the latest nightly build of Firefox.
This doesn't sound so good, and is the opposite of what I think people have come to expect. It's seems like the most straightforward solution is to hardcode a specific version of the runtime into the package, so that installing qbrt XX.0.0 gets you the runtime that corresponds to Firefox version XX.
It's not that big a deal, but it all adds up eventually. I wouldn't want every .net or java app to install their own versions of .net and java. Sure, my laptop hd probably has enough space for that, but its unnecessary
And every qbrt app is the same way. If there are two apps 'one' and 'two' written as node modules, and both have qbrt x.x.x in their dependencies, then installing both will leave you with two identical but independent runtimes. There's no sharing going on.
A runtime that can't run the app it's supposed to (because of breaking changes across runtime versions) is also not a very useful runtime, shared or not.
There were a few popular non-Mozilla apps that were built using XULRunner back in the day, but considering Mozilla has made it clear that XUL development will soon stop, I don't think it's likely to be a technology that grows in popularity.
Yes, they plan to switch away from XUL. I'm not sure about the situation with Thunderbird, but I believe Firefox will be dropping XUL this year or early next year.
There are two sides to this migration. The main Firefox UI is being rewritten (how much of XUL remains after this rewrite is unclear), and extensions developed in XUL are being dropped.
The new UI for Firefox 57 is still written in XUL. It's just the XUL extension API that is being deprecated in favor of WebExtensions with Firefox 57.
This deprecation of XUL extensions could prove problematic for Thunderbird, as it means that Mozilla can now move a lot faster and make breaking changes without having to worry about mass-breakages in extensions, therefore making it more likely that they'll leave Thunderbird behind at some point, but XUL itself isn't yet being deprecated.
There are some long-long-term plans to maybe eventually replace XUL with HTML/CSS/JS, but they need much better performance still before that becomes viable. There are some efforts into that direction already[0], building a framework for it as well, and those mostly focus around Servo, as that will have the necessary performance, so I'd guess at least a couple of years still.
Like 3 years ago I proposed a Nodejs implementation based on Gecko instead of V8. Two Mozilla devs mentioned they don't care and see no need. In the meantime even MS is trying with their Chakra.
Instead of using the system API you should start a nodejs process and have the web app communicate with it using websockets, and use the system api in the nodejs app. That way it will be easy to port your "native" app to different systems and you can use the same code on both web and native! You don't even need the runtime, just launch Firefox with the "-chrome" argument, or "--app=" in Chrome or "-k" in IE.
98 comments
[ 745 ms ] story [ 2506 ms ] threadEdit: Electron really needs a competitor/alternative
Myk wrote about taht as well: https://mykzilla.org/2017/03/08/positron-discontinued/
https://nwjs.io/
I used it to port a frontend for an application that requires multiple toplevel windows and found its API way easier for that particular problem.
Edit: also a rather informative statement by the author on the relationship between nw.js (which used to be node-webkit) and Electron:
https://groups.google.com/forum/#!topic/nwjs-general/LIrC7zH...
http://sciter.com - single dll/so of 5mb - embeddable HTML/CSS engine designed specifically for running desktop UIs.
https://en.m.wikipedia.org/wiki/HTML_Application
You cannot find much about it, because it was an IE 6.0 based technology, when "Electron apps" were the IE ActiveX engine bundled as .exe.
I'm a web dev but I don't have a MacBook. Does that make me better or worse?
Also tell me more about your Amiga
Edit: I realise that probably looked like I was having a go, but I was actually trying to diffuse the argument. I'm genuinely interested in the Amiga, if you have one. Do you use it for work?
Is Gecko better than Chromium in certain cases?
Yes, in certain cases. However, I don't think it's worth another flame war about this. Even if I posted some benchmarks all you'd have is a stream of people sharing their anecdata trying to confirm or deny the accuracy of the benchmarks. Can we nip this in the bud before it begins and just be glad that Electron has some competition to help push it forward?
Firefox's latest build made significant RAM usage improvements [1], leapfrogging Chrome when it came to multiple tabs.
[1][http://www.techradar.com/news/firefoxs-blazing-speed-with-hu...]
You have the base virtual machine installed, and then the app just needs to ship the code itself.
You could even ship with an "install script header", like "if this isn't installed, offer to download and install it". I imagine a lot of us have seen these kinds of installers before.
For example, if there were a Debian package for either of those, all apps leveraging them would just declare that same package a dependency and you'd have a single system-wide install for the large binary everyone keeps complaining about. (AFAICT there is no such deb package for any of the above.)
The JVM (and apparently qbrt) is designed to be shared, apps are expected to use the installed system version of the VM, though if the packager wants they can include a specific version to use.
I wish it were easy/possible to get Electron apps to share things, it bothers me that Chrome, Discord, and Slack almost certainly could share most of their hundreds of megabytes.
https://www.npmjs.com/package/nwjs
and electron:
https://github.com/electron-userland/electron-prebuilt
It's not completely bonkers. It could be possible to make a web installer that checks for node and electron and downloads them if necessary. Nobody seems to do that though. Every electron app bundles electron. At least every one I've seen
That plus scarring from browser differences over N years.
Of course it's still totally possible, but there are probably gotchas that aren't obvious if you're mainly a web developer.
You keep saying this. It's not mentioned in the post, and it doesn't match how qbrt is actually doing things. Where are you seeing it?
If they are of higher quality, yes. In fact, there are plenty of useful and native applications which many just haven't discovered --- you could argue they spent far more effort on the product than marketing it. Related: https://news.ycombinator.com/item?id=14748924
What incentive does any developer have to do as you say?
I'm not the one you're replying to, but as developer myself I don't want to have to put up with "this slow and bloated web shit on desktop" either. IMHO increasing the combined computing resource consumption of all your users significantly just so you can make your product a little more easily is the complete opposite of being a good developer.
The argument about it being "easier" might be questionable too --- I've been programming native GUI apps for over a decade and for the type of functionality that a lot of these web-app-packaged-with-browser monstrosities are doing, it'd probably take me far less time to write something in pure Win32 and X than download and figure out how to use Electron. Some may argue that the initial learning curve is steeper, but then after that you're a "real native coder" instead of a "web apper" and will be making far more efficient applications for everyone.
Personally, I'd rather have fewer webapps (which is what these really are) bundled into bloated browsers and called "desktop" or "native".
If you're going to put in the effort to write a proper desktop application with native components through Qt, .NET, Java or OpenGL or something, go ahead but please don't bother with webapps with a browser wrapper, just leave them on the web where they belong. If you need a little more integration, do it with a browser extension.
I'm yet to see a single necessary Electron port.
> What incentive does any developer have to do as you say?
The top comment on any news article or discussion forum being something other than "great, another unnecessary Electron app that'll waste my CPU, RAM and battery".
And producing a better performing application.
Electron has been a godsend to Linux users and it can definitely be highly performant. I've even switched from vim to vscode because the latter is actually the slickest IDE I've ever used.
You're yet to see a single necessary electron port? Well, I use 4 all the time, probably none of which would even be Linux-compatible were it not for electron. YMMV.
The "cross platform desktop apps" I'm objecting to are really just webapps that could run just as well in a browser without the wrapper. If they weren't released in a wrapper at all, they'd still be cross platform.
> I've even switched from vim to vscode because the latter is actually the slickest IDE I've ever used.
VSCode and Atom make a little more sense in Electron because they actually have requirements that can't be met when run purely in a browser (like running a build system). I still prefer a native IDE like Sublime Text but I can see also see the benefit of using Electron here. The apps I have problems with are the webapp ports like Slack, Discord and Spotify.
> You're yet to see a single necessary electron port? Well, I use 4 all the time
What are they? What makes them necessary (other than VSCode, which I understand as explained above)?
(Yes, this idea is slowly but surely becoming a reality... I'm the creator of a little thing called "Linux on the Web", at https://linuxontheweb.org)
This. Electron makes it economically and technically feasible for companies to deliver the same features and support to Linux users as their other customers.
The thing is often not explicitly stated is that many companies using Electron are not desktop software vendors, but SaaS providers. They aren't going to do native desktop applications, because they just want to provide nice clients to users for their particular service.
If you program in C++ or Python, no problem, both have good support for Qt. However, outside those two languages it seems that the available bindings tend to be small projects rather than something robustly tested. That's appeared to be the case a few years ago at least, would be happy to be proved wrong.
Not the lack of alternatives.
If they want to ship a product with good UI/UX quality, then they should learn the supported languages.
It is all about placing customers above personal preferences.
I bash C a lot, yet I will use it without thinking twice about it, if is the best solution for solving out our customer's project requirements.
Then again, I never bought into Developer Technology X mentality.
The time sunk in learning a new programming language is not inconsequential. You can get to a basic level of proficiency relatively quickly, but being productive in a language takes time and effort.
If I took your approach I'd constantly need to switch languages and rely on glue logic to piece them together. Just because a language is 'the best' at one thing doesn't mean it's always the right choice for a project that has multiple requirements. Should all regular expressions be written in Perl? Should all mathematical operations be written in Fortran? Should all macros be written in Common Lisp? Should all data structures be described in Idris?
We deliver projects in Java (Swing, JavaFX, Android, JEE, Spring), .NET (Forms, WPF, ASP.NET, UWP), C++ (NDK, .NET, Java native methods), Objective-C/Swift (iOS), PL/SQL(Oracle), Transact-SQL(MS SQL Server), pg/SQL (PostgreSQL), JavaScript(Web).
Every 6 months or so, we tend to switch customer and respective project stack, being able to proficiently jump between technology stacks is expected.
To use another example, let's say I was writing an app in C#. Should I use a JVM GUI library just because I liked it better than the .NET ones? Even if it's technically possible, it's far from optimal.
We also have projects with application servers written in JEE, using native desktop GUIs in WPF, talking via REST to those servers.
Yeah... no. I'm not that fond of using Electron apps (Atom, Slack...) myself, but I absolutely don't want them in a browser window. Writing a "native" application simply isn't an option in many cases.
> The top comment on any news article or discussion forum being something other than "great, another unnecessary Electron app that'll waste my CPU, RAM and battery".
So what? There's the same handful of curmudgeons posting that comment everywhere. That doesn't mean they're valuable as a demographic. It depends on the market of course, but if your application solves a problem that nothing else solves as well (as it should), then running on Electron is not a dealbreaker. Most ordinary users can't tell and don't know to care.
But that's exactly what you're getting when they're run as Electron apps. The main difference being that they consume more system resources than an actual browser window because they can't share any resources with your actual browser.
> So what?
> Most ordinary users can't tell and don't know to care.
The problem is that the complaints of CPU, RAM and battery degradation are valid complaints. I think you'll find that many users can tell that their machine has become slower or has a faster draining battery but they won't know to blame the browser wrapper for it. Take Spotify (which uses Chromium Embedded Framework) for example:
- https://community.spotify.com/t5/Desktop-Mac/Battery-Drain/t...
- https://community.spotify.com/t5/Desktop-Linux-Windows-Web-P...
- https://community.spotify.com/t5/Desktop-Mac/Again-When-will...
Well, no it isn't. If you can't even make that distinction, then having any further conversation with you is going to be pointless.
I suppose you would welcome the use of progressive web apps, but those haven't yet "arrived". If they did, I might argue for using them over things like Electron.
> The problem is that the complaints of CPU, RAM and battery degradation are valid complaints.
Many complaints about web technology are valid, that doesn't mean they invalidate its use. The reality is that even a company like Spotify would rather drain its users batteries than develop native apps. It's a tradeoff.
If Spotify followed through with your advice, those users should not be offered a desktop app at all, they should be forced to only use the website and have their browser drain the battery instead. You're effectively arguing for less choice when a native app is not an option. That doesn't make sense to me.
What is the distinction you want me to make? That it has a different icon in your OS task bar?
> If Spotify followed through with your advice, those users should not be offered a desktop app at all, they should be forced to only use the website and have their browser drain the battery instead.
My argument is that by sharing resources with the browser they're running anyway, that the battery/CPU/RAM drain will be reduced. A browser is a lot of overhead and using less browsers at once is always good.
> You're effectively arguing for less choice when a native app is not an option. That doesn't make sense to me.
The reason is that these browser wrappers are marketed deceptively, so users aren't equipped to make an informed decision about whether to use them.
Users generally expect that when they download a desktop application, that it's native, has minimal overhead and performs well. Browser-wrappers don't meet these expectations. Users don't realise they're downloading an extra browser and all the overhead it entails.
If users realised that these were just another browser that can only open one website, I'm sure their feelings would be substantially different.
They think that when they download Spotify, it's going to perform like VLC or Winamp and it absolutely doesn't.
That's one! So, it's already not exactly the same. Figuring out the rest shall be left as an exercise to the reader.
> My argument is that by sharing resources with the browser they're running anyway, that the battery/CPU/RAM drain will be reduced. A browser is a lot of overhead and using less browsers at once is always good.
You are describing one trade-off. Your argument is valid, but if you follow the links you yourself posted, it's not actually the browser engine that does all the draining, it's the content it is running (i.e. you can disable some functionality and the problem is mitigated). The base RAM overhead of running Electron compared to something like Qt isn't that big either.
> Users generally expect that when they download a desktop application, that it's native, has minimal overhead and performs well.
I don't think that's true, but even if it was, so what? Users need to lower their expectations.
There are reasons why people are doing things this way. Just like the discussion of why people have 1000+ tabs. You could try to understand the underlying reasons vs just criticize.
What would you rather people do? Code it in Qt? Code it in Java? Code it for each platform specifically? If so, why aren't people doing that?
I value cross-platform support greatly because I run Linux on desktop, Windows on laptop, and I have a Mac Mini as well.
I use Moneydance [1] as my personal finance tracking software. It's written in Java for cross-platform support. I use it on Linux and on Windows. If it was written in Electron, I'd still use it. Why? Cross-platform support is important to me.
I value cross-platform too, and there are lots of native apps that manage that without Electron or Java. From my toolkit I can see Sublime Edit (of course), also Photoshop, Affinity Photo, Renoise, Melodyne, iZotope RX, Tower, Beyond Compare, Postbox, VLC. Also tons of audio VST effects plugins.
When I make native cross-platform desktop apps, I usually lean towards Xojo (aka REALbasic), which also has Linux support. And for my cross-platform Photoshop plug-in effects, the Windows versions are in C / Win32 while the Mac version is a C++/Obj-C framework I made to let me use the same code on both Windows & Mac without changes.
Everyone is moving to web technology because it cuts down on cost on many fronts, not because it's the better technology. Finding web developers is easy and using Electron (etc) gives free cross-platform support, which is very valuable. It's all about economics, not quality.
This doesn't sound so good, and is the opposite of what I think people have come to expect. It's seems like the most straightforward solution is to hardcode a specific version of the runtime into the package, so that installing qbrt XX.0.0 gets you the runtime that corresponds to Firefox version XX.
A runtime that can't run the app it's supposed to (because of breaking changes across runtime versions) is also not a very useful runtime, shared or not.
There are two sides to this migration. The main Firefox UI is being rewritten (how much of XUL remains after this rewrite is unclear), and extensions developed in XUL are being dropped.
https://www.neowin.net/news/mozilla-is-working-on-a-new-ui-f...
https://blog.mozilla.org/addons/2017/02/16/the-road-to-firef...
This deprecation of XUL extensions could prove problematic for Thunderbird, as it means that Mozilla can now move a lot faster and make breaking changes without having to worry about mass-breakages in extensions, therefore making it more likely that they'll leave Thunderbird behind at some point, but XUL itself isn't yet being deprecated.
There are some long-long-term plans to maybe eventually replace XUL with HTML/CSS/JS, but they need much better performance still before that becomes viable. There are some efforts into that direction already[0], building a framework for it as well, and those mostly focus around Servo, as that will have the necessary performance, so I'd guess at least a couple of years still.
[0]https://github.com/browserhtml/browserhtml
https://news.ycombinator.com/item?id=14156251
https://en.wikipedia.org/wiki/Q*bert
https://vimeo.com/21062117