21 ms·

I'm bullish on Electron. I think it's just a couple of technical advancements away from being the ultimate desktop toolkit. For context, I love and have worked

I'm bullish on Electron. I think it's just a couple of technical advancements away from being the ultimate desktop toolkit. For context, I love and have worked a ton with Qt, and I much prefer Qt UIs as a user. But Electron has brought true cross-platform development to all platforms (Including Linux!). If it weren't for Electron, I wouldn't even have a bunch of the apps I use today. Hell, I wouldn't have a good IDE, and I don't think I'd be as good in Typescript had I not been a day-1 VS Code user. I think the main thing preventing it from "feeling" good to most users is the most common complaint on HN about how each individual app is its own version of Chrome. This sucks; it's heavy, it's laggy, and users feel it even instinctively. OSes and frameworks have tried to solve this a bazillion ways. Edge WebView, Android WebView, Qt WebView, QtWebkit, whatever the iexplore stuff was in XP, …. Electron might have the opportunity to actually solve this. If it does, honestly, to hell with anything else. I'm sure over time the web world will gravitate towards a fairly common set of widgets that will, at one point or another be standardized. We'll reinvent UI frameworks under a different name, except this time they'll be running under the ultimate cross-platform framework.

_bxg1 7y ago
Agreed. We need a cross-OS definition of "web views" and a standard way to say, "use my default browser for all web views, including Electron".
- skybrian 7y ago
  It seems like that's not really going to work for the developers of these apps due to browser variation and version skew? (If it were okay, why aren't they supporting web browsers already?) But maybe apps on the same version of Electron could share a runtime?
  - _bxg1 7y ago
    Web developers are already accustomed to supporting much more widely-varying browser versions, and web standards are expressly designed to be backwards-compatible basically forever. I don't think it would be a major problem.
  - Filligree 7y ago
    Discord, to take an example, does support running in a browser. It's how I usually run it. It also comes as an Electron app, because it wants more system privileges than browser tabs are ever allowed to get -- to tell people what game you're playing.
- _bxg1 7y ago
  Really, given that the primary consumer of this API would be Electron and that it would take a huge coordination between OS and browser vendors to create a standard, it seems like it would be possible for Electron to just circumvent it and come up with their own way of sharing Chromiums between their own apps. When building you could specify whether you want your build to be fully portable, portable with the option of sharing, or fully reliant on a system-wide Chromium copy. On startup, an Electron app could check for an existing shared copy and automatically install its dependencies. The same could be done for Node.
- hechang1997 7y ago
  this library seems promising: https://github.com/zserge/webview https://github.com/zserge/webview
Razengan 7y ago
I'd rather see SwiftUI or something like it ported to other systems with a "driver" that translates it to each platform's 100% native UI. It's already amazing in how it abstracts common elements for such distinct environments like desktop, phone, TV and watch while still exposing OS-specific features. Why not other operating systems?
- scrollaway 7y ago
  Insert any framework in place of SwiftUI. You're describing Qt, essentially. The approach has been tried, and succeeded to some degree. But the web is the only app where cross-platform is the default, and it's truly hard to avoid it. Even if the widgets all look different. Even if nothing looks native (people got used to it anyway). And to be clear I want the status quo to improve in this regard, especially in terms of accessibility (nobody should have to reimplement eg their own dropdown especially if it breaks eg. keyboard shortcuts, mobile UIs and so on). But I can't see anything from today that isn't either a web technology, or web-compatible (and web-accessible, not the Qt webgl hack that's on the frontpage right now) making it in the long term.
  - blueprint 7y ago
    > But the web is the only app where cross-platform is the default That's just because it describes its own embedded rendering system.
  - Razengan 7y ago
    > Insert any framework in place of SwiftUI. You're describing Qt, essentially. SwiftUI's syntax feels closer to a markup language than code, though, so it might be more appealing to web frontend devs.
    - bryanlarsen 7y ago
      QT Quick also uses a markup language.
      - 7y ago
fetbaffe 7y ago
Free Pascal & Lazarus has already solved this problem, but no one cares because Pascal is outdated & therefore we need to reinvent the wheel over & over but doing it worse for every iteration.
- badsectoracula 7y ago
  Kinda. Lazarus is great and all (though even Delphi 2 felt more coherent, which is a side effect of Lazarus not really being a single project nor the result of a single vision), but the only LCL backend where everything works as expected is the Win32 one with the Gtk2 one being just a bit behind. Other backends are of a much more "alpha" quality, especially the Cocoa backend (for many years the Carbon backend was what was developed since it was easier to interface from C - AFAIK the Cocoa backend really got focus when Free Pascal got its "Objective Pascal" compiler mode that extends their OBJFPC dialect with Objective-C compatible features and the ability to directly use Objective-C objects) and the overall Mac support is lacking in manpower compared to the others (some people prefer to use the Qt backend - which isn't as good as the Win32/Gtk2 - just so they get a bit better Mac support, but that adds a lot of extra unnecessary bloat since in addition to LCL's own overhead, you also get the Qt4Pas overhead and Qt's own overhead, not to mention you do not get "real" native widgets).
blux 7y ago
Is the comparison with Qt relevant? My understanding is that Electron is for JavaScript what Qt is for C++. Is there not a better fit for C++ development in the web UI ecosystem?
- scrollaway 7y ago
  > My understanding is that Electron is for JavaScript what Qt is for C++. This is a weird comparison. Electron isn't really a UI framework, it's more of a customized web browser and JS runner, with some platform APIs to bridge the gap. But no, I don't know of anything serious that lets you write web UIs in C++. The closest you'll get are things like Google's Closure Compiler which compile Java to JS. There's very likely something for C++, but nobody's seriously using that, probably because nobody actually wants this. "All of C++'s hare-brained syntax and slow iteration speed, with none of the performance benefits!" is not a good selling point.
  - emiliobool 7y ago
    not exactly the most performant but there is https://ultralig.ht/ https://ultralig.ht/
  - Scarbutt 7y ago
    Closure compiles JS to JS, you must be thinking fo GWT.
    - scrollaway 7y ago
      Right.
- TimTheTinker 7y ago
  > Is the comparison with Qt relevant? Absolutely, when considering cross-platform UI frameworks in general. In that sense, Qt competes not only with Electron, but also with toolkits like wxWidgets, GTK+, JavaFX, Flash, and some older ones like Java/Swing, Lazarus and Adobe/Macromedia Director.
tambourine_man 7y ago
Besides memory consumption, the killer feature for me would be true native text boxes. Skype on the Mac won't expand my abbreviations, use my dictionaries, etc. Drives me nuts. Maybe that's Skype's fault, it wouldn't surprise me, but I think I've seen this behavior elsewhere. Skype is, thankfully, the only Electron app I have to interact frequently.
- iaml 7y ago
  Skype is not an electron app though: https://microsoft.github.io/reactxp/blog/2017/04/27/building-skype-on-reactxp.html https://microsoft.github.io/reactxp/blog/2017/04/27/building...
flowerlad 7y ago
>> OSes and frameworks have tried to solve this a bazillion ways. What is different today is that Windows 10 and other popular platforms adopted Flat UI. Users no longer expect apps to have “native look & feel” because Flat UI has no recognizable or desirable look & feel. This is a big mistake by Microsoft because there is no longer any reason for independent developers to write native Windows apps. This works to the benefit of Electron and also users of non-Windows platforms.
- karmicthreat 7y ago
  I don't think that is even a worry for microsoft. Its looking like MS is going to make blazor on electron and eventually blazor on native their cross platform UI.
- AnIdiotOnTheNet 7y ago
  Microsoft has made it pretty clear since about Windows 10 that they don't actually care about the Desktop anymore. It certainly isn't anywhere near their biggest money-maker.
  - pjmlp 7y ago
    Indeed, that is why Microsoft has created teams to support React Native for macOS and Windows, on Windows case it makes use of UWP, which new roadmap (WinUI 3.0) was announced at BUILD 2019, with more details to come up on Ignite. Yeah, Microsoft bashing never grows old.
    - AnIdiotOnTheNet 7y ago
      Yeah ok, fair point. Someone at Microsoft cares a bit about Windows, just not anybody working on the UX bits.
      - pjmlp 7y ago
        Given the market size of laptops, 2-1 hybrids and graphical workstations running Windows, the UI/UX toolings that are available, I fail to see what you mean.
thrower123 7y ago
I cannot love Electron. It's almost always an inappropriate choice for a desktop application, yet I see more and more of what should be power-user desktop applications moving towards using it, and it is horrible. My largest gripe with it, besides the others that are discussed ad nauseum already, is that it is impossible, seemingly, for Electron apps to spawn multiple windows without creating entire new instances. I have several Electron-based chat applications that are a trainwreck to use, compared to their predecessors, because there is no effective way to handle more than one chat at a time; they can't just pop out a small dedicated window for a chat conversation, they have to live inside their one window, and this results in a terrible tabbed UI where one is constantly flipping back and forth between conversation threads. Or the bevy of Electron text editors that you cannot tear a file tab off and put on another screen.
- lukevp 7y ago
  This isn't really true. Electron itself has a renderer process and a background process. It's completely possible to make multiple renderers with independent windows that can coordinate with IPC through the background process. We have an electron app that does this and has undockable tabs, it's not even very hard to implement if you're using something like Redux for a window level state store, you just pass it thru IPC to the new session.
- hechang1997 7y ago
  the most important reason that leads to electron's adoption, I believe, is the flexibility and customizability of HTML UI compared to traditional widget-based ones.
  - thrower123 7y ago
    This is a weak argument, unless people have just never used desktop widget libraries and are arguing against an imagined strawman. There is not a farthings real difference between the two.
rolleiflex 7y ago
I release two apps, across 3 OSes, in somewhat of a bimonthly cadence with a low defect rate. That’s 6 different binaries. I’m a solo founder. I know people like to rag on Electron, but without it, I wouldn’t be using something else, my apps just wouldn’t exist. It allows more people to try building more thing and that is a net positive. The speed problems and bloat issues of Electron is just shoddy programming on the maker’s part - Electron itself isn’t slow. I use it largely as a shell talking to a Go binary that ships within the app package, which makes it only tasked with UI. If you’re having issues with speed, it’s a good approach. A real world example of this approach is the thing I work on at https://aether.app https://aether.app. (An async collaboration tool for engineers)
- vtail 7y ago
  Good rationale from a maker, not a purist, and good luck with your projects! I liked the site, it's clean and to the point. Just a small nitpick: right under the Demo download button, you say "(Demo does not have Pro features such as team management, access control and others)". I wouldn't say that - that essentially gives the user a (subconscious) rationale on why she shouldn't download the demo. I would suggest to focus on the positives instead - what the Demo can do. If you can somehow remove limitations, even for 14 days - even better!
  - rolleiflex 7y ago
    Thank you! That’s good feedback. It’s there because the demo implies that it’s the demo of the same app, while in reality it’s a similar app targeting a different user base (a superficially Reddit-like peer to peer network). That’s why I say I have two apps, Aether and Aether Pro. The demo on the Aether Pro website is actually just regular Aether P2P. I’ll try to find a way of making it less of a showstopper though - might be a better way to tell this.
- dewey 7y ago
  For me, and probably others, the main issue with Electron isn't the speed or even resource usage. It's that it ignores common UX/UI conventions you expect from a native app which still makes me prefer native macOS apps.
alkonaut 7y ago
If only each OS would ship an abstraction layer that guaranteed "at least modern browser X" that one could ship into. I want to ship an electron app but I want it to be 100kb and start in 0.1s and take almost no memory because the libs are shared. I don't want each little chat app or music player to gobble up half a gig of ram and take 3 seconds to start.
- AnIdiotOnTheNet 7y ago
  I give it 15 minutes before decisions, well reasoned or otherwise, by the individual platforms cause incompatibility issues that make you wish you'd just shipped your own copy of Chrome in the first place. This is part of the reason Electron even exists.
- sircastor 7y ago
  I think OS makers explicitly don't want to do this. In the case of Apple, they prefer you to use all their tools and technologies. It allows them more management of the experience.
  - MisterTea 7y ago
    Using the word experience is why we're in this mess. These are tools we're talking about. Not an African safari.
- chocolatkey 7y ago
  Microsoft is working on an API that will use the chromium that's part of their new version of edge. It's already available for use (of course right now you have to have the edge beta downloaded): https://docs.microsoft.com/en-us/microsoft-edge/hosting/webview2/gettingstarted https://docs.microsoft.com/en-us/microsoft-edge/hosting/webv...
  - saagarjha 7y ago
    Is this anything other than just a webview?
  - 7y ago
AnIdiotOnTheNet 7y ago
Electron is so heavy you could include a copy of Windows 95 with every application and use its GUI. This is how ludicrous the state of modern computing is. Java accomplished the same thing with fewer limitations and vastly more efficiency. Best case scenario of the continuing "evolution" of electron is the elimination of the OS entirely. Why do you need it? Just put drivers in Chrome and be done with it. It's already the rest of the damn OS to a lot of people (notably not people like me).
- sroussey 7y ago
  In a later version of Electron (for Windows 10), it could use the Windows supplied Chromium WebView and shrink the size by 80%+.
- yodsanklai 7y ago
  > Electron is so heavy Does it matter? I think heaviness should be defined relatively to the computer resources. Currently VSCode memory usage is 75MB on my computer. It could be 10 times less, it wouldn't make any difference.
  - big_chungus 7y ago
    Which OS are you using for that kind of memory usage? I've tried it, and seen double that out-of-the-box.
    - yodsanklai 7y ago
      Macbook Pro 2018, Catalina
    - cocochanel 7y ago
      50.6MB for me on a 2018 MacBook Pro running macOS Mojave.
  - AnIdiotOnTheNet 7y ago
    > Does it matter? Not really I guess, I mean who cares about the user's computing resources? Certainly not developers.
mshroyer 7y ago
> But Electron has brought true cross-platform development to all platforms (Including Linux!). Only if we restrict "all platforms" to mean Windows, macOS, and Linux. Building and porting Electron appears to be a horrific experience [1], which limits its cross-platform utility. It's only recently that someone pulled the heroics of getting Electron 4 (!) into FreeBSD ports; I still can't run VS Code on OpenBSD. Meanwhile I've yet to encounter an OS with an X11 display where I can't run a Qt app. So I certainly wouldn't hold Electron up as a paragon of cross-platform support. [1] https://deftly.net/posts/2017-06-01-measuring-the-weight-of-an-electron.html https://deftly.net/posts/2017-06-01-measuring-the-weight-of-...
- bitwize 7y ago
  > Only if we restrict "all platforms" to mean Windows, macOS, and Linux. "It's cross-platform! It works on Windows 95 and Windows NT!"
  - nercht12 7y ago
    Come on, guys. Don't downvote him. He was being funny. X) Along those lines, we can say anything made for ChristOS is definitely cross-platform. XD (There's a double pun in that one if you know Greek.)
    - bitwize 7y ago
      I actually saw statements to that effect in popular computer media in the 90s. So I wasn't just being funny.
- hollerith 7y ago
  You might already know of this option, but if your interest in Electron is limited to running vscode on OpenBSD, there are many offerings, both proprietary and open-source, that offer "hosted" vscode where "hosted" means accessible over the net via an ordinary browser. (One offering whose name escapes me has the restriction that it is impossible to develop a vscode extension using the offering.)
all_blue_chucks 7y ago
> Electron has brought true cross-platform development to all platforms (Including Linux!). Last I checked, electron did not work on OpenBSD.
didibus 7y ago
I thought QT worked across all platforms? Also, I think JVM UI frameworks still offer more than people believe. JavaFx and even the good old Swing work cross platform. Compared to Electron apps, they even hold in terms of performance and memory use.
Rapzid 7y ago
Something unfortunate is that last I checked React didn't really have a good UI lib to give an "app" feel. So something like VSCode or what not would not really be feasible in the most popular libs.. Would be great if there were some UI libs on par with Qt and the like. EDIT: I fail-skimmed your comment and missed the Qt mention! Glad there are more folks out there seeing the same.
tedajax 7y ago
I mean only if you like working in web front-end land and I'd rather never use a computer again than do that.
killface 7y ago
glad to see someone else who thinks like this. the way people seem to react to electron apps is very close to "they killed my pappy!" kind of anger.
DonHopkins 7y ago
>OSes and frameworks have tried to solve this a bazillion ways. Edge WebView, Android WebView, Qt WebView, QtWebkit, whatever the iexplore stuff was in XP, …. Electron might have the opportunity to actually solve this. That list goes on and on. Don't forget xulrunner. Or heck, even Visix Galaxy! (Ask Jeff Barr about that one some time. ;) ) http://www.ambiencia.com/overviewgalaxytd.php http://www.ambiencia.com/overviewgalaxytd.php
langitbiru 7y ago
I am quite bullish on PySide2 (Qt Python framework). I don't hate Electron. It's just I am more Python guy rather than JavaScript guy. PySide2 is free for commercial purpose (with some caveats: LGPL). https://doc.qt.io/qtforpython/ https://doc.qt.io/qtforpython/
jagannathtech 7y ago
What is you opinion on flutter? esp performance wise?
- pjmlp 7y ago
  A last attempt to try to rescue Dart from oblivion.
jstimpfle 7y ago
If you are willing to code your own GUI widgets, it's also pretty easy to do cross-platform. You can opt for OpenGL or similar and a little glue for the various platforms. If you slowly grow a collection of just your favorite widtes, that's totally doable. Will grow to maybe 10-15K lines of C code. That's a lot of explicit code, but on the upside the code will be more maintainable compared to all the boilerplate the would be required to bend a super-general library to fit your requirements. I've done a few OpenGL toy apps in the last months, and one commercial project that includes text widgets, editing, table views, buttons, scrollbars and so on. It also scales freely. It's not that hard, and the next time will be even easier.
petemill 7y ago
Except it isn't all platforms - it doesn't include iOS and Android. But the web, especially an installable web app (PWA) is exactly all platforms. As well as solving the issue of a shared chromium engine, or engine of your choice.
pjmlp 7y ago
Laziness always wins apparently.
75dvtwin 7y ago
Well, I think the market is waiting for Qt. What I would very much appreciate is: QT-free (so that everything in that package is clearly LGPL) with React-native built on top of QT-free widgets. That would make my day (and a year...)
- jcelerier 7y ago
  > QT-free (so that everything in that package is clearly LGPL) The immense majority of Qt is LGPL ; only these modules are GPL / commercial : https://doc.qt.io/qt-5/qtmodules.html#gpl-licensed-addons https://doc.qt.io/qt-5/qtmodules.html#gpl-licensed-addons > with React-native built on top of QT-free widgets. https://blog.atulr.com/nodegui-intro/ https://blog.atulr.com/nodegui-intro/ though I still think that QtQuick (or even QtWidgets with https://www.kdab.com/declarative-widgets/ https://www.kdab.com/declarative-widgets/) are much more readable and fast to market.
tluyben2 7y ago
> will gravitate towards a fairly common set of widgets that will Is there anything like that? There is for mobile (Framework7 I like the most) but is there anything for desktop that allows me to create applications with electron in a more desktop like way? I am one of those people that doesn't really html/css. In WPF/QT/Winforms/Gtks/Xamarin/Avalonia/iOS/Android/Lazarus/Livecode I can create complex applications very fast (and a few of these are cross platform too); they don't look great (albeit consistent and not horrible), but something is working and working well in a very short time (hours). I have not found anything for Electron that works as fast as that, including bindings and logic etc. I do a lot of HTML/css, but for web; simple things like getting a few decent looking panes with buttons and text etc that scales automatically still feels like a from scratch exercise and when using standard stuff like Bootstrap, everything looks and feels like web, not desktop. I have friends who created native looking Electron apps and it took forever to make it work well and look good (lot of quirks they had to deal with, but this is a while ago); with Qt or Avalonia (I use mostly C#) it would maybe (?) not look 'as good' (which is taste) but it would be done much faster. There are things like [0] but then all look like Mac OS X. Are there any good ones cross platform or at least a little more 'neutral' than photon? [0] http://photonkit.com/ http://photonkit.com/

_bxg1 7y ago

Agreed. We need a cross-OS definition of "web views" and a standard way to say, "use my default browser for all web views, including Electron".

skybrian 7y ago
It seems like that's not really going to work for the developers of these apps due to browser variation and version skew? (If it were okay, why aren't they supporting web browsers already?) But maybe apps on the same version of Electron could share a runtime?
- _bxg1 7y ago
  Web developers are already accustomed to supporting much more widely-varying browser versions, and web standards are expressly designed to be backwards-compatible basically forever. I don't think it would be a major problem.
- Filligree 7y ago
  Discord, to take an example, does support running in a browser. It's how I usually run it. It also comes as an Electron app, because it wants more system privileges than browser tabs are ever allowed to get -- to tell people what game you're playing.
_bxg1 7y ago
Really, given that the primary consumer of this API would be Electron and that it would take a huge coordination between OS and browser vendors to create a standard, it seems like it would be possible for Electron to just circumvent it and come up with their own way of sharing Chromiums between their own apps. When building you could specify whether you want your build to be fully portable, portable with the option of sharing, or fully reliant on a system-wide Chromium copy. On startup, an Electron app could check for an existing shared copy and automatically install its dependencies. The same could be done for Node.
hechang1997 7y ago
this library seems promising: https://github.com/zserge/webview https://github.com/zserge/webview

Razengan 7y ago

I'd rather see SwiftUI or something like it ported to other systems with a "driver" that translates it to each platform's 100% native UI. It's already amazing in how it abstracts common elements for such distinct environments like desktop, phone, TV and watch while still exposing OS-specific features. Why not other operating systems?

scrollaway 7y ago
Insert any framework in place of SwiftUI. You're describing Qt, essentially. The approach has been tried, and succeeded to some degree. But the web is the only app where cross-platform is the default, and it's truly hard to avoid it. Even if the widgets all look different. Even if nothing looks native (people got used to it anyway). And to be clear I want the status quo to improve in this regard, especially in terms of accessibility (nobody should have to reimplement eg their own dropdown especially if it breaks eg. keyboard shortcuts, mobile UIs and so on). But I can't see anything from today that isn't either a web technology, or web-compatible (and web-accessible, not the Qt webgl hack that's on the frontpage right now) making it in the long term.
- blueprint 7y ago
  > But the web is the only app where cross-platform is the default That's just because it describes its own embedded rendering system.
- Razengan 7y ago
  > Insert any framework in place of SwiftUI. You're describing Qt, essentially. SwiftUI's syntax feels closer to a markup language than code, though, so it might be more appealing to web frontend devs.
  - bryanlarsen 7y ago
    QT Quick also uses a markup language.
    - 7y ago

fetbaffe 7y ago

Free Pascal & Lazarus has already solved this problem, but no one cares because Pascal is outdated & therefore we need to reinvent the wheel over & over but doing it worse for every iteration.

badsectoracula 7y ago
Kinda. Lazarus is great and all (though even Delphi 2 felt more coherent, which is a side effect of Lazarus not really being a single project nor the result of a single vision), but the only LCL backend where everything works as expected is the Win32 one with the Gtk2 one being just a bit behind. Other backends are of a much more "alpha" quality, especially the Cocoa backend (for many years the Carbon backend was what was developed since it was easier to interface from C - AFAIK the Cocoa backend really got focus when Free Pascal got its "Objective Pascal" compiler mode that extends their OBJFPC dialect with Objective-C compatible features and the ability to directly use Objective-C objects) and the overall Mac support is lacking in manpower compared to the others (some people prefer to use the Qt backend - which isn't as good as the Win32/Gtk2 - just so they get a bit better Mac support, but that adds a lot of extra unnecessary bloat since in addition to LCL's own overhead, you also get the Qt4Pas overhead and Qt's own overhead, not to mention you do not get "real" native widgets).

blux 7y ago

Is the comparison with Qt relevant? My understanding is that Electron is for JavaScript what Qt is for C++. Is there not a better fit for C++ development in the web UI ecosystem?

scrollaway 7y ago
> My understanding is that Electron is for JavaScript what Qt is for C++. This is a weird comparison. Electron isn't really a UI framework, it's more of a customized web browser and JS runner, with some platform APIs to bridge the gap. But no, I don't know of anything serious that lets you write web UIs in C++. The closest you'll get are things like Google's Closure Compiler which compile Java to JS. There's very likely something for C++, but nobody's seriously using that, probably because nobody actually wants this. "All of C++'s hare-brained syntax and slow iteration speed, with none of the performance benefits!" is not a good selling point.
- emiliobool 7y ago
  not exactly the most performant but there is https://ultralig.ht/ https://ultralig.ht/
- Scarbutt 7y ago
  Closure compiles JS to JS, you must be thinking fo GWT.
  - scrollaway 7y ago
    Right.
TimTheTinker 7y ago
> Is the comparison with Qt relevant? Absolutely, when considering cross-platform UI frameworks in general. In that sense, Qt competes not only with Electron, but also with toolkits like wxWidgets, GTK+, JavaFX, Flash, and some older ones like Java/Swing, Lazarus and Adobe/Macromedia Director.

tambourine_man 7y ago

Besides memory consumption, the killer feature for me would be true native text boxes. Skype on the Mac won't expand my abbreviations, use my dictionaries, etc. Drives me nuts. Maybe that's Skype's fault, it wouldn't surprise me, but I think I've seen this behavior elsewhere. Skype is, thankfully, the only Electron app I have to interact frequently.

iaml 7y ago
Skype is not an electron app though: https://microsoft.github.io/reactxp/blog/2017/04/27/building-skype-on-reactxp.html https://microsoft.github.io/reactxp/blog/2017/04/27/building...

flowerlad 7y ago

>> OSes and frameworks have tried to solve this a bazillion ways. What is different today is that Windows 10 and other popular platforms adopted Flat UI. Users no longer expect apps to have “native look & feel” because Flat UI has no recognizable or desirable look & feel. This is a big mistake by Microsoft because there is no longer any reason for independent developers to write native Windows apps. This works to the benefit of Electron and also users of non-Windows platforms.

karmicthreat 7y ago
I don't think that is even a worry for microsoft. Its looking like MS is going to make blazor on electron and eventually blazor on native their cross platform UI.
AnIdiotOnTheNet 7y ago
Microsoft has made it pretty clear since about Windows 10 that they don't actually care about the Desktop anymore. It certainly isn't anywhere near their biggest money-maker.
- pjmlp 7y ago
  Indeed, that is why Microsoft has created teams to support React Native for macOS and Windows, on Windows case it makes use of UWP, which new roadmap (WinUI 3.0) was announced at BUILD 2019, with more details to come up on Ignite. Yeah, Microsoft bashing never grows old.
  - AnIdiotOnTheNet 7y ago
    Yeah ok, fair point. Someone at Microsoft cares a bit about Windows, just not anybody working on the UX bits.
    - pjmlp 7y ago
      Given the market size of laptops, 2-1 hybrids and graphical workstations running Windows, the UI/UX toolings that are available, I fail to see what you mean.

thrower123 7y ago

I cannot love Electron. It's almost always an inappropriate choice for a desktop application, yet I see more and more of what should be power-user desktop applications moving towards using it, and it is horrible. My largest gripe with it, besides the others that are discussed ad nauseum already, is that it is impossible, seemingly, for Electron apps to spawn multiple windows without creating entire new instances. I have several Electron-based chat applications that are a trainwreck to use, compared to their predecessors, because there is no effective way to handle more than one chat at a time; they can't just pop out a small dedicated window for a chat conversation, they have to live inside their one window, and this results in a terrible tabbed UI where one is constantly flipping back and forth between conversation threads. Or the bevy of Electron text editors that you cannot tear a file tab off and put on another screen.

lukevp 7y ago
This isn't really true. Electron itself has a renderer process and a background process. It's completely possible to make multiple renderers with independent windows that can coordinate with IPC through the background process. We have an electron app that does this and has undockable tabs, it's not even very hard to implement if you're using something like Redux for a window level state store, you just pass it thru IPC to the new session.
hechang1997 7y ago
the most important reason that leads to electron's adoption, I believe, is the flexibility and customizability of HTML UI compared to traditional widget-based ones.
- thrower123 7y ago
  This is a weak argument, unless people have just never used desktop widget libraries and are arguing against an imagined strawman. There is not a farthings real difference between the two.

rolleiflex 7y ago

I release two apps, across 3 OSes, in somewhat of a bimonthly cadence with a low defect rate. That’s 6 different binaries. I’m a solo founder. I know people like to rag on Electron, but without it, I wouldn’t be using something else, my apps just wouldn’t exist. It allows more people to try building more thing and that is a net positive. The speed problems and bloat issues of Electron is just shoddy programming on the maker’s part - Electron itself isn’t slow. I use it largely as a shell talking to a Go binary that ships within the app package, which makes it only tasked with UI. If you’re having issues with speed, it’s a good approach. A real world example of this approach is the thing I work on at https://aether.app https://aether.app. (An async collaboration tool for engineers)

vtail 7y ago
Good rationale from a maker, not a purist, and good luck with your projects! I liked the site, it's clean and to the point. Just a small nitpick: right under the Demo download button, you say "(Demo does not have Pro features such as team management, access control and others)". I wouldn't say that - that essentially gives the user a (subconscious) rationale on why she shouldn't download the demo. I would suggest to focus on the positives instead - what the Demo can do. If you can somehow remove limitations, even for 14 days - even better!
- rolleiflex 7y ago
  Thank you! That’s good feedback. It’s there because the demo implies that it’s the demo of the same app, while in reality it’s a similar app targeting a different user base (a superficially Reddit-like peer to peer network). That’s why I say I have two apps, Aether and Aether Pro. The demo on the Aether Pro website is actually just regular Aether P2P. I’ll try to find a way of making it less of a showstopper though - might be a better way to tell this.
dewey 7y ago
For me, and probably others, the main issue with Electron isn't the speed or even resource usage. It's that it ignores common UX/UI conventions you expect from a native app which still makes me prefer native macOS apps.

alkonaut 7y ago

If only each OS would ship an abstraction layer that guaranteed "at least modern browser X" that one could ship into. I want to ship an electron app but I want it to be 100kb and start in 0.1s and take almost no memory because the libs are shared. I don't want each little chat app or music player to gobble up half a gig of ram and take 3 seconds to start.

AnIdiotOnTheNet 7y ago
I give it 15 minutes before decisions, well reasoned or otherwise, by the individual platforms cause incompatibility issues that make you wish you'd just shipped your own copy of Chrome in the first place. This is part of the reason Electron even exists.
sircastor 7y ago
I think OS makers explicitly don't want to do this. In the case of Apple, they prefer you to use all their tools and technologies. It allows them more management of the experience.
- MisterTea 7y ago
  Using the word experience is why we're in this mess. These are tools we're talking about. Not an African safari.
chocolatkey 7y ago
Microsoft is working on an API that will use the chromium that's part of their new version of edge. It's already available for use (of course right now you have to have the edge beta downloaded): https://docs.microsoft.com/en-us/microsoft-edge/hosting/webview2/gettingstarted https://docs.microsoft.com/en-us/microsoft-edge/hosting/webv...
- saagarjha 7y ago
  Is this anything other than just a webview?
- 7y ago

AnIdiotOnTheNet 7y ago

Electron is so heavy you could include a copy of Windows 95 with every application and use its GUI. This is how ludicrous the state of modern computing is. Java accomplished the same thing with fewer limitations and vastly more efficiency. Best case scenario of the continuing "evolution" of electron is the elimination of the OS entirely. Why do you need it? Just put drivers in Chrome and be done with it. It's already the rest of the damn OS to a lot of people (notably not people like me).

sroussey 7y ago
In a later version of Electron (for Windows 10), it could use the Windows supplied Chromium WebView and shrink the size by 80%+.
yodsanklai 7y ago
> Electron is so heavy Does it matter? I think heaviness should be defined relatively to the computer resources. Currently VSCode memory usage is 75MB on my computer. It could be 10 times less, it wouldn't make any difference.
- big_chungus 7y ago
  Which OS are you using for that kind of memory usage? I've tried it, and seen double that out-of-the-box.
  - yodsanklai 7y ago
    Macbook Pro 2018, Catalina
  - cocochanel 7y ago
    50.6MB for me on a 2018 MacBook Pro running macOS Mojave.
- AnIdiotOnTheNet 7y ago
  > Does it matter? Not really I guess, I mean who cares about the user's computing resources? Certainly not developers.

mshroyer 7y ago

> But Electron has brought true cross-platform development to all platforms (Including Linux!). Only if we restrict "all platforms" to mean Windows, macOS, and Linux. Building and porting Electron appears to be a horrific experience [1], which limits its cross-platform utility. It's only recently that someone pulled the heroics of getting Electron 4 (!) into FreeBSD ports; I still can't run VS Code on OpenBSD. Meanwhile I've yet to encounter an OS with an X11 display where I can't run a Qt app. So I certainly wouldn't hold Electron up as a paragon of cross-platform support. [1] https://deftly.net/posts/2017-06-01-measuring-the-weight-of-an-electron.html https://deftly.net/posts/2017-06-01-measuring-the-weight-of-...

bitwize 7y ago
> Only if we restrict "all platforms" to mean Windows, macOS, and Linux. "It's cross-platform! It works on Windows 95 and Windows NT!"
- nercht12 7y ago
  Come on, guys. Don't downvote him. He was being funny. X) Along those lines, we can say anything made for ChristOS is definitely cross-platform. XD (There's a double pun in that one if you know Greek.)
  - bitwize 7y ago
    I actually saw statements to that effect in popular computer media in the 90s. So I wasn't just being funny.
hollerith 7y ago
You might already know of this option, but if your interest in Electron is limited to running vscode on OpenBSD, there are many offerings, both proprietary and open-source, that offer "hosted" vscode where "hosted" means accessible over the net via an ordinary browser. (One offering whose name escapes me has the restriction that it is impossible to develop a vscode extension using the offering.)

all_blue_chucks 7y ago

> Electron has brought true cross-platform development to all platforms (Including Linux!). Last I checked, electron did not work on OpenBSD.

didibus 7y ago

I thought QT worked across all platforms? Also, I think JVM UI frameworks still offer more than people believe. JavaFx and even the good old Swing work cross platform. Compared to Electron apps, they even hold in terms of performance and memory use.

Rapzid 7y ago

Something unfortunate is that last I checked React didn't really have a good UI lib to give an "app" feel. So something like VSCode or what not would not really be feasible in the most popular libs.. Would be great if there were some UI libs on par with Qt and the like. EDIT: I fail-skimmed your comment and missed the Qt mention! Glad there are more folks out there seeing the same.

tedajax 7y ago

I mean only if you like working in web front-end land and I'd rather never use a computer again than do that.

killface 7y ago

glad to see someone else who thinks like this. the way people seem to react to electron apps is very close to "they killed my pappy!" kind of anger.

DonHopkins 7y ago

>OSes and frameworks have tried to solve this a bazillion ways. Edge WebView, Android WebView, Qt WebView, QtWebkit, whatever the iexplore stuff was in XP, …. Electron might have the opportunity to actually solve this. That list goes on and on. Don't forget xulrunner. Or heck, even Visix Galaxy! (Ask Jeff Barr about that one some time. ;) ) http://www.ambiencia.com/overviewgalaxytd.php http://www.ambiencia.com/overviewgalaxytd.php

langitbiru 7y ago

I am quite bullish on PySide2 (Qt Python framework). I don't hate Electron. It's just I am more Python guy rather than JavaScript guy. PySide2 is free for commercial purpose (with some caveats: LGPL). https://doc.qt.io/qtforpython/ https://doc.qt.io/qtforpython/

jagannathtech 7y ago

What is you opinion on flutter? esp performance wise?

pjmlp 7y ago
A last attempt to try to rescue Dart from oblivion.

jstimpfle 7y ago

If you are willing to code your own GUI widgets, it's also pretty easy to do cross-platform. You can opt for OpenGL or similar and a little glue for the various platforms. If you slowly grow a collection of just your favorite widtes, that's totally doable. Will grow to maybe 10-15K lines of C code. That's a lot of explicit code, but on the upside the code will be more maintainable compared to all the boilerplate the would be required to bend a super-general library to fit your requirements. I've done a few OpenGL toy apps in the last months, and one commercial project that includes text widgets, editing, table views, buttons, scrollbars and so on. It also scales freely. It's not that hard, and the next time will be even easier.

petemill 7y ago

Except it isn't all platforms - it doesn't include iOS and Android. But the web, especially an installable web app (PWA) is exactly all platforms. As well as solving the issue of a shared chromium engine, or engine of your choice.

pjmlp 7y ago

Laziness always wins apparently.

75dvtwin 7y ago

Well, I think the market is waiting for Qt. What I would very much appreciate is: QT-free (so that everything in that package is clearly LGPL) with React-native built on top of QT-free widgets. That would make my day (and a year...)

jcelerier 7y ago
> QT-free (so that everything in that package is clearly LGPL) The immense majority of Qt is LGPL ; only these modules are GPL / commercial : https://doc.qt.io/qt-5/qtmodules.html#gpl-licensed-addons https://doc.qt.io/qt-5/qtmodules.html#gpl-licensed-addons > with React-native built on top of QT-free widgets. https://blog.atulr.com/nodegui-intro/ https://blog.atulr.com/nodegui-intro/ though I still think that QtQuick (or even QtWidgets with https://www.kdab.com/declarative-widgets/ https://www.kdab.com/declarative-widgets/) are much more readable and fast to market.

tluyben2 7y ago

> will gravitate towards a fairly common set of widgets that will Is there anything like that? There is for mobile (Framework7 I like the most) but is there anything for desktop that allows me to create applications with electron in a more desktop like way? I am one of those people that doesn't really html/css. In WPF/QT/Winforms/Gtks/Xamarin/Avalonia/iOS/Android/Lazarus/Livecode I can create complex applications very fast (and a few of these are cross platform too); they don't look great (albeit consistent and not horrible), but something is working and working well in a very short time (hours). I have not found anything for Electron that works as fast as that, including bindings and logic etc. I do a lot of HTML/css, but for web; simple things like getting a few decent looking panes with buttons and text etc that scales automatically still feels like a from scratch exercise and when using standard stuff like Bootstrap, everything looks and feels like web, not desktop. I have friends who created native looking Electron apps and it took forever to make it work well and look good (lot of quirks they had to deal with, but this is a while ago); with Qt or Avalonia (I use mostly C#) it would maybe (?) not look 'as good' (which is taste) but it would be done much faster. There are things like [0] but then all look like Mac OS X. Are there any good ones cross platform or at least a little more 'neutral' than photon? [0] http://photonkit.com/ http://photonkit.com/