17 ms·

Electron 6.0

190 points by fnordsensei 7y ago

mosselman 7y ago
It is totally me, seeing as how many electron projects there are, but I have never been able to make anything with it. Not even a POC, I have found it very complex.
- justanegg 7y ago
  It's a cargo cult
- mirekrusin 7y ago
  Complex compared to what exactly?
- z3t4 7y ago
  Also check out nw.js which is like Electron, but you start in browser context instead of node.js context. Also consider running a node.js server and launching existing chrome with chrome --app=http://localhost http://localhost or iexplore -k http://localhost http://localhost
  - dynamite-ready 7y ago
    Agreed. I think NW.js is great (https://github.com/nwjs/nw.js https://github.com/nwjs/nw.js). Especially the binary blob feature which can be used to compile JavaScript to V8 bytecode, and obfuscate portions of your source for security purposes.
  - reeeeee 7y ago
    I've read a tutorial that creates a small desktop application using nw.js and vue, and the package size was 233 mb. This made me decide to use Electron after all. here it is: https://dev.to/n_tepluhina/building-a-desktop-app-with-vue-nwjs-1f9e https://dev.to/n_tepluhina/building-a-desktop-app-with-vue-n...
- aeonflux 7y ago
  If you have a working website it takes like 5 lines of code and random electron guide to actually do a POC. If you want to have a standalone APP, you need to have locally working SPA app. That requires rather deeper familiarity with current JS build stack.
- cvrajeesh 7y ago
  there are few popular ones Slack, VSCode, Atom editor, etc...
  - nullandvoid 7y ago
    The OP mentioned closed source electron products where the source code can be safely protected
  - pjmlp 7y ago
    Given the React Native for Windows talk at BUILD 2019, and their comparisation how it beats Electron, how Office and other teams are now adopting it, I still hope VSCode will eventually join the party. They even did a nice graphic. With UWP C++ being the reference point of 100%, UWP C# gets also 100% (thanks .NET Native), React Native 180% and Electron goes sky high above 700%! https://youtu.be/TZnajQqqKV8?t=2919 https://youtu.be/TZnajQqqKV8?t=2919 This is how much everyone doing Electron apps is contributing to global warming, including VSCode team.
    - calferreira 7y ago
      I'm surprised microsoft isn't pushing xamarin instead of React Native for cross platform.
      - pjmlp 7y ago
        They address that during BUILD. Xamarin for .NET devs, React Native for C++ devs (think Qt/QML).
    - yboris 7y ago
      Seems like React Native is for Android, iOS and UWP (Windows), so no Mac or Linux, right? Doesn't seem like a direct competitor with Electron then. Right?
      - pjmlp 7y ago
        There is ongoing support for React Native for Mac. http://www.reactnative.com/build-os-x-desktop-apps-using-react-native/ http://www.reactnative.com/build-os-x-desktop-apps-using-rea... You got me there on GNU/Linux support, which doesn't mean it will not come later. They just need to decide which flavour of Linux desktop one is supposed to support in React Native.
- _pmf_ 7y ago
  That's my impression too. It seems like a lot of the "native development is hard, so I use Electron" have never once used native C# with Visual Studio.
  - Arbalest 7y ago
    When all you have is Javascript, everything looks like a nail
  - mceachen 7y ago
    Or they might not have the bandwidth to deal with n different builds. I've written UIs in native motif, x, mfc, Android, and iOS, but with modern HTML & CSS (especially in the last couple years with flexbox, grid, canvas, svg support) and TypeScript it seems like there's new goodness daily. That said, I'd love a divorce from Electron if something else would give me a system tray, node runtime, and seamless upgrades, supported cross-platform.
  - megous 7y ago
    Visual Studio. That's a deal breaker right there. With Electron runtime you can just write a text file on any of the supported platforms and you have a working, running desktop app. No compilation needed. No need to install SDKs, deal with builds, project files, etc.
- luismedel 7y ago
  I don't think it's very complex. Only look at the target users! :-) Jokes aside, lack of basic code protection (aside of script minimization and/or obfuscation) it's that prevents me from using Electron/Atom/whatever. I know anyone could decompile a C# application easily, but I find the javascript case worst. Do you know any commercial applications using any of these solutions? (I'm speaking of shareware / paid software, not "Whatsapp desktop" type)
  - pluto9 7y ago
    GitKraken uses Electron and has both free and paid features.
    - luismedel 7y ago
      Please, correct me if I'm wrong, as I don't know GitKraken enough. It appears to be a free client for a paid service. Not the type of commercial software I was thinking of.
      - pluto9 7y ago
        It's a desktop GUI for Git, along the same lines as Sourcetree. They've added stuff over time like various paid integrations and apparently a Kanban board, but it's always primarily been a Git GUI. Mailspring is another one I can think of. It's a free email client that offers extra features for pay.
  - code_Whisperer 7y ago
    Visual Studio Code?
    - dragonwriter 7y ago
      VSC isn't commercial, though it's probably narrowing the market for commercial IDEs.
  - mceachen 7y ago
    PhotoStructure for Desktop runs on macOS, Windows 10, and Ubuntu Desktop, is packaged with Electron (I'm alpha testing 6.0.0 today), and will be commercially licensed when the closed beta ends. I'm also preparing a PhotoStructure for Servers build that is electron-less, and uses either docker or snap (it's how I run it on my NAS). I'm looking for more beta testers for this headless build, if you're interested. https://blog.photostructure.com/introducing-photostructure/ https://blog.photostructure.com/introducing-photostructure/ has more background and signup information. Disclaimer: I'm the author.
- yboris 7y ago
  If you happen to know Angular, it takes 1 minute to have something working: https://github.com/maximegris/angular-electron https://github.com/maximegris/angular-electron The thing I built has enough code you can learn from to get you farther: https://github.com/whyboris/Video-Hub-App https://github.com/whyboris/Video-Hub-App
- CmdrKrool 7y ago
  I have a hobby project in Electron but agree, the forced separation of "main" and "renderer" processes with multiple methods of influencing each other (ipcMain/ipcRenderer, remote, webContents.executeJavascript/send), and the further splitting of the renderer process into multiple similarly-named substructures (webFrame, webview, BrowserWindow, webContents) is a lot to get one's head around right off the bat and make stick, especially if you're the sort who wants to survey and disambiguate all the facilities of the platform beneath you before starting to code, rather than just trusting tutorials and tweaking code snippets towards some degree of satisfaction if and when they 'just work'. On the Rich Hickey "simple vs easy" scale, Electron is very much leaning to the "easy" side.
- 52-6F-62 7y ago
  Here's a very simple and terrible example. Nothing happens except the time is updated every second in the render process. This runs at 90.3 MB RAM usage on my machine and builds to 165.7 MB. It's about as bare of a reference as you might find. Have at it. (Also there's no Readme, just consult the package file. I only threw this together when I was finding my way around it this spring) https://github.com/Robert-Fairley/electron-typescript-starter https://github.com/Robert-Fairley/electron-typescript-starte...
rado 7y ago
Appreciating the contrast with the 512-byte OS posted today.
- mothsonasloth 7y ago
  Its a valid point, the average computer in the Western world is at least 4GB. However when I was in South Africa a few years back they were still running with XP and < 2GB RAM with HDDs that I saw in a school and hotel. Ok, hardware components are cheaper and easier to come by but we shouldn't stop caring about system resource usage.
  - iamnotacrook 7y ago
    If they're using old PCs running deprecated versions of Windows then they long ago stopped caring about resource usage and efficiency (energy usage and operator time) and are instead optimising for hardware cost. It's no reason to favour this or that platform for development.
    - clappski 7y ago
      > instead optimising for hardware cost I imagine a big reason that they're on old hardware is cost - just because it's relatively cheap for someone in the West to get a decent modern machine at a reasonable cost doesn't mean that it's the same everywhere, especially when there's big disparities in the purchasing power of the native currency vs. the sellers/manufactures currency. It's not so much an optimization, I imagine most users on legacy hardware don't choose to be, it's more likely that they can't afford more modern hardware or it isn't available for them to purchase. Another huge reason for users to stay with older operating systems (especially in business and government) is dependencies on legacy software - if an organization relies on software that has never been updated after Windows 95/XP and doesn't function on later versions then they're going to be stuck using legacy machine configurations until the process can be changed to something else. > stopped caring about resource usage and efficiency (energy usage and operator time) How do you know that they don't care about how efficiently they can use a machine for whatever they're doing? It's a baseless assumption. Even if your user percent that's stuck using older hardware/operating systems is in the single digits, that isn't an excuse to ignore their requirements IMO. Doing so is a sign of sloppy engineering, akin to designing a new mode of public transport, for example, that doesn't cater for disabled people.
Robin_f 7y ago
Great, another release not supported by Spectron so you can't actually write tests for it.
daliusd 7y ago
Almost two years ago I have created app (using Electron) that takes xlxs template and data files and generates bunch of xlsx files [1]. It was Electron 1.7.8 and now it is 6.0.0. I guess I need to check it out again. [1] For curious: https://github.com/daliusd/xlsx-generator https://github.com/daliusd/xlsx-generator
- simlevesque 7y ago
  You should add a screenshot in the readme.
  - daliusd 7y ago
    Thank you. Done.
polote 7y ago
Every time I hear about Electron, I have mixed feeling about it, is it : * one the best thing that happened to desktop software as it enable web developers to build desktop portable app * one of the worst thing that happened, because it makes the desktop world rely on Google and decrease even more the expectations on how much resources an app should consume What are your opinions ?
- kgraves 7y ago
  The latter, I have a 3GB laptop. Almost any application I use that is electron makes my laptop scream for help (fan spinning furiously) and freezes it up. I have to kill the application before it consumes everything. Electron applications like VS Code are an exception and slightly gives me hope.
  - stevewodil 7y ago
    Does anyone know what makes VS Code an exception to this? Going to be working on an Electron app, so I'm curious about what optimizations have been made there.
    - 52-6F-62 7y ago
      I can't speak to VSCode, but I've been probably a hard use case for Electron development as I work in an industry without a ton of resources to throw at development, limited time, and less supportive environment for development (in spite of a pressing need to keep up). I've found keeping as precious little of the work in the render process as possible has helped a great deal. Send everything to the main process and use the event/messaging system to update the state. Then things that you're used to doing to maintain application performance in a web browser apply. Keep the compute in the back as much as possible. And depending on the task, offload compute to a native module [if you're capable and] if the expense between NodeJS <> native module is worth it (more intense compute tasks). There's probably more and more experienced advice out there, but this is my experience so far.
    - jayjader 7y ago
interfixus 7y ago
I once drove a huge refrigeration truck across Australia. The full cooling system was running all the way, although storage was howlingly empty, save for twenty liters of drinking water, kept there because the fridge in the driver's cabin had broken down. Electron always reminds me of that trip.
- ktpsns 7y ago
  I love that analogy. The fridge in the driver's cabin is a web widget in a traditional toolkit, for instance https://doc.qt.io/qt-5/qtwebengine-webenginewidgets-markdowneditor-example.html https://doc.qt.io/qt-5/qtwebengine-webenginewidgets-markdown... The large cooling system which requires a substantial amount of fuel is Electron.
gingabriska 7y ago
Can anyone suggest a software niche where Electron has not be used so far? Here is one I think: 3D printer slicer, to my knowledge there is no slicer which uses electron I think it limits the contributers who can quickly deploy plugins in JavaScript
- nickexyz 7y ago
  For slicers there is https://pathio.xyz https://pathio.xyz. Not fully Electron though, which is probably a good thing.. Edit: https://pathio.xyz/hello-world https://pathio.xyz/hello-world "Pathio is built on a mixture of modern web-technology (Electron) and a powerful native slicing engine (written in C++17)"
rvz 7y ago
It's kind of interesting to see this release and previous ones mention 'performance fixes' (V8 and Blink does all the work) that it brings, yet the job postings for desktop software engineer requiring Electron experience also put data structure and algorithms and what I see here is a runtime that is very expensive in both space + time complexity. It makes no difference in using a different language with a faster runtime to combat this. Imagine if I were to write a 'next-gen' CAD program or an alternative 3D modeling program in Electron. I'm not so sure if the manufacturing or the games industry would take a second look at that. But in our industry, it is seen as normal for our text editors, ide's, git clients and video editing software and our messaging clients to be expensive in memory and cpu time. Can't we do better than this? Or do we have to accept and depend on Google to create our desktop software?
- ComodoHacker 7y ago
  There are better alternatives, in almost every possible way. The problem is they aren't that popular. And you can't reuse code (and coders) with web version of your app.
  - dgellow 7y ago
    Alternatives that are supported cross platform? That’s the only reason I would potentially consider Electron.
    - davojta 7y ago
      https://en.wikipedia.org/wiki/Chromium_Embedded_Framework https://en.wikipedia.org/wiki/Chromium_Embedded_Framework is support linux, windows and macos
      - wongarsu 7y ago
        With CEF you can write your business logic in a better language, but the UI suffers from the same problems as Electron since it's basically the same thing.
    - 7y ago
mothsonasloth 7y ago
It seems like you have three choices at the moment for desktop development (for non .NET) that I am aware of. * C++ and GTK or other UI framework : hard but excellent performance. * Java and Swing UI framework : easier but less performant. * Javascript and Electron : easy but terrible performance. Which one will prevail?
- shifto 7y ago
  Python and TkInter : always better than electron
  - royal_ts 7y ago
    can you style anything taht comes with TkInter? It looks ugly af if not
    - shifto 7y ago
      Yes, you can definitely make it way more ugly than default. :)
- kgraves 7y ago
  Qt & PyQt?
  - adem 7y ago
    > [...] GTK or other UI framework [...]
    - roryrjb 7y ago
      Yeah but the list specifically mentions C++, which I think is part of the reason why this category is hard. Python on the other hand is definitely more entry level friendly but it's still Qt. This should be emphasised.
      - 7y ago
Epskampie 7y ago
Can anybody explain why electron includes all off * chromium * node.js * v8 ? To my understanding chromium includes V8, and node.js is built on top of it.
- truth_seeker 7y ago
  ElectronJS Application Architecture - https://electronjs.org/docs/tutorial/application-architecture https://electronjs.org/docs/tutorial/application-architectur...
wongarsu 7y ago
> Per our support policy, 3.x.y has reached end of life. 3.0.0 was released 10 months ago. If the current frequency of releases stays constant any version reaches end of life after about 9 months.
- NullPrefix 7y ago
  Electron does not have a LTS branch ?
  - giancarlostoro 7y ago
    They have "Stable" releases: https://electronjs.org/releases/stable https://electronjs.org/releases/stable I'm guessing their LTS is whatever Google's released to an extent. Google Chrome is the basis for Electron, it would be a bad move to be over a year behind Chrome, which would lend to poor support from Google Chrome's dev team. At least that's my take on it, I'm not involved with either project. Maybe someone else here has better input over the matter.
  - wongarsu 7y ago
    They support the last three major releases, and that's it. So right now that's 6.x.y, 5.x.y and 4.x.y. A new major release is released about every 3 months. To quote the official stance: "If an application has exceptional circumstances and needs to stay on an unsupported series of Electron, developers can silence the end-of-support warning by omitting the final release from the app's package.json" [0] [0] https://electronjs.org/docs/tutorial/support#supported-versions https://electronjs.org/docs/tutorial/support#supported-versi...
    - imtringued 7y ago
      Considering how electron applications are deployed "exceptional circumstances" covers every single electron app in existence.
- JCSato 7y ago
  Oof. I thought it was surprising to see 6 out already. . .
aorth 7y ago
No mention of Wayland support, which means that desktop applications like Skype and Signal will continue to have a poor user experience on GNU/Linux unless you use Xorg. Using these applications with fractional scaling in Wayland is a bit rough—I guess we are waiting for Google to land patches upstream of Electron in Chromium?
- TingPing 7y ago
  It depends on Chromium but as I understand it is being worked on.
- snazz 7y ago
  Have you noticed any issues with XWayland aside from the DPI scaling? I find it pretty seamless on a standard-DPI (or a little higher) monitor.
rhabarba 7y ago
Security Risk 6.0.0.
ksec 7y ago
Hopefully with Apple's Catalyst, there wouldn't be a single Electron Apps ( Ok apart from VSCode ) on my MBP. If you want iOS or iPadOS, you need to be Native. And you can now port it to Mac with ease. The days company ship crappy Desktop software with Electron needs to come to an End.
ausjke 7y ago
Electron is the true and only available cross-platform desktop build environment these days, it actually makes business sense for many. All alternatives(Qt, whatever) come out short in my opinion. The major complain of course is its memory/disk space. I don't see how that's going to be resolved soon even though RAM/Disk is cheap these days, maybe a smaller js engine, or maybe replacing nodejs with something lighter(e.g. golang backend). Another approach is to run a local daemon(e.g. one go binary) that does all the backend operations(filesystem, network,etc), while use browser as your UI.
- localhost 7y ago
  I have no idea why you're being downvoted for this. I like your idea about a golang backend. In fact, the entire application can be packaged within a single golang binary which provides simple distribution and only requires the user have a modern browser installed on their computer. .NET Core recently added self-contained executable support so there are more options available today than just golang.
- ausjke 7y ago
  I'm more and more confused these days by the downvotes at HN, I found I need be "100% politically correct" for technical discussions here(i.e. nothing negative at all, even for critical thoughts or neutral comments, neither is enough though, the comments actually has to be perfect positive), people are so sensitive these days, including me who actually cares about downvotes, which is a bad sign.
- megous 7y ago
  That will not help much. V8/node is not that big. The big part is chromium.
  - ausjke 7y ago
    slack desktop is 60MB zipped. after unzip it's 205MB while slack binary itself takes 115MB, indeed node_modules only took 8MB, https://github.com/electron/electron/issues/2003 https://github.com/electron/electron/issues/2003
wlesieutre 7y ago
Not mentioned in the release notes, but if I'm not mistaken this update adds support for Touch ID. I thought that was coming in 5 but it looks like it didn't. https://github.com/electron/electron/pull/16707#issuecomment-506392471 https://github.com/electron/electron/pull/16707#issuecomment... Welcome to 2016, electron apps! This should help BitWarden be a more competitive alternative to 1Password for Mac users.
rafaelvasco 7y ago
It seems to me that the short term solution for the runtime overhead is to have the core runtime running in the background and the applications running decoupled from it on top. Is there any reasonable mature project going this way ?
waldsonpatricio 7y ago
One library that is trying to be the mid-term between native performance and ease of use is Revery[1]. [1] https://www.outrunlabs.com/revery/ https://www.outrunlabs.com/revery/
fohara 7y ago
I'm surprised Kivy [0] doesn't get more attention for desktop app development. Apps are developed in Python, it's cross-platform and MIT licensed. Running the hello world example uses just ~2.5% cpu and ~57mb memory on a 2015 mbp. [0] https://github.com/kivy/kivy https://github.com/kivy/kivy
deleted 7y ago
[deleted]
gpsx 7y ago
I feel embarrassed to ask such an obvious question, but what would it take to _not_ download electron with every app? I assume the main drawback to doing this is having the correct version. This isn't a big problem for web browsers.
- edflsafoiewq 7y ago
  Arch packages the Electron runtime separately from apps. https://wiki.archlinux.org/index.php/Electron_package_guidelines https://wiki.archlinux.org/index.php/Electron_package_guidel...
dirkg 7y ago
Its always the same complaints about Electron's size/runtime. Try to build a desktop app using a native language/UI framework of your choice (C#/Java/C++ with whatever fancy UI libs you want) which will even come close to the power or HTML+CSS - hint, you can't. Just trying to implement the layout/cascading behaviors, never mind all the stuff on top, would take forever. Next add the fact that you can get true cross platform apps with a single code base in reality, not the pseudo lies promised by ReactNative or the even more ridiculous RN on Web, or new pretenders like Flutter. Electron isn't being used for tiny utilities - its used for apps like Slack/VSCode which really do need to run on multiple platforms and have the exact same UI/UX, which is simply impossible even if you dedicate 3 dedicated teams at 3-5x the cost. Why don't people complain about how bloated browsers are? Electron is simply V8+Node bundled for desktop use.
- z3t4 7y ago
  If you statically link the ui lib - the binary can become quite large too. Another option is to make a web app and use "add to desktop".

190 points by fnordsensei 7y ago

It is totally me, seeing as how many electron projects there are, but I have never been able to make anything with it. Not even a POC, I have found it very complex.

justanegg 7y ago
It's a cargo cult
mirekrusin 7y ago
Complex compared to what exactly?
z3t4 7y ago
Also check out nw.js which is like Electron, but you start in browser context instead of node.js context. Also consider running a node.js server and launching existing chrome with chrome --app=http://localhost http://localhost or iexplore -k http://localhost http://localhost
- dynamite-ready 7y ago
  Agreed. I think NW.js is great (https://github.com/nwjs/nw.js https://github.com/nwjs/nw.js). Especially the binary blob feature which can be used to compile JavaScript to V8 bytecode, and obfuscate portions of your source for security purposes.
- reeeeee 7y ago
  I've read a tutorial that creates a small desktop application using nw.js and vue, and the package size was 233 mb. This made me decide to use Electron after all. here it is: https://dev.to/n_tepluhina/building-a-desktop-app-with-vue-nwjs-1f9e https://dev.to/n_tepluhina/building-a-desktop-app-with-vue-n...
aeonflux 7y ago
If you have a working website it takes like 5 lines of code and random electron guide to actually do a POC. If you want to have a standalone APP, you need to have locally working SPA app. That requires rather deeper familiarity with current JS build stack.
cvrajeesh 7y ago
there are few popular ones Slack, VSCode, Atom editor, etc...
- nullandvoid 7y ago
  The OP mentioned closed source electron products where the source code can be safely protected
- pjmlp 7y ago
  Given the React Native for Windows talk at BUILD 2019, and their comparisation how it beats Electron, how Office and other teams are now adopting it, I still hope VSCode will eventually join the party. They even did a nice graphic. With UWP C++ being the reference point of 100%, UWP C# gets also 100% (thanks .NET Native), React Native 180% and Electron goes sky high above 700%! https://youtu.be/TZnajQqqKV8?t=2919 https://youtu.be/TZnajQqqKV8?t=2919 This is how much everyone doing Electron apps is contributing to global warming, including VSCode team.
  - calferreira 7y ago
    I'm surprised microsoft isn't pushing xamarin instead of React Native for cross platform.
    - pjmlp 7y ago
      They address that during BUILD. Xamarin for .NET devs, React Native for C++ devs (think Qt/QML).
  - yboris 7y ago
    Seems like React Native is for Android, iOS and UWP (Windows), so no Mac or Linux, right? Doesn't seem like a direct competitor with Electron then. Right?
    - pjmlp 7y ago
      There is ongoing support for React Native for Mac. http://www.reactnative.com/build-os-x-desktop-apps-using-react-native/ http://www.reactnative.com/build-os-x-desktop-apps-using-rea... You got me there on GNU/Linux support, which doesn't mean it will not come later. They just need to decide which flavour of Linux desktop one is supposed to support in React Native.
_pmf_ 7y ago
That's my impression too. It seems like a lot of the "native development is hard, so I use Electron" have never once used native C# with Visual Studio.
- Arbalest 7y ago
  When all you have is Javascript, everything looks like a nail
- mceachen 7y ago
  Or they might not have the bandwidth to deal with n different builds. I've written UIs in native motif, x, mfc, Android, and iOS, but with modern HTML & CSS (especially in the last couple years with flexbox, grid, canvas, svg support) and TypeScript it seems like there's new goodness daily. That said, I'd love a divorce from Electron if something else would give me a system tray, node runtime, and seamless upgrades, supported cross-platform.
- megous 7y ago
  Visual Studio. That's a deal breaker right there. With Electron runtime you can just write a text file on any of the supported platforms and you have a working, running desktop app. No compilation needed. No need to install SDKs, deal with builds, project files, etc.
luismedel 7y ago
I don't think it's very complex. Only look at the target users! :-) Jokes aside, lack of basic code protection (aside of script minimization and/or obfuscation) it's that prevents me from using Electron/Atom/whatever. I know anyone could decompile a C# application easily, but I find the javascript case worst. Do you know any commercial applications using any of these solutions? (I'm speaking of shareware / paid software, not "Whatsapp desktop" type)
- pluto9 7y ago
  GitKraken uses Electron and has both free and paid features.
  - luismedel 7y ago
    Please, correct me if I'm wrong, as I don't know GitKraken enough. It appears to be a free client for a paid service. Not the type of commercial software I was thinking of.
    - pluto9 7y ago
      It's a desktop GUI for Git, along the same lines as Sourcetree. They've added stuff over time like various paid integrations and apparently a Kanban board, but it's always primarily been a Git GUI. Mailspring is another one I can think of. It's a free email client that offers extra features for pay.
- code_Whisperer 7y ago
  Visual Studio Code?
  - dragonwriter 7y ago
    VSC isn't commercial, though it's probably narrowing the market for commercial IDEs.
- mceachen 7y ago
  PhotoStructure for Desktop runs on macOS, Windows 10, and Ubuntu Desktop, is packaged with Electron (I'm alpha testing 6.0.0 today), and will be commercially licensed when the closed beta ends. I'm also preparing a PhotoStructure for Servers build that is electron-less, and uses either docker or snap (it's how I run it on my NAS). I'm looking for more beta testers for this headless build, if you're interested. https://blog.photostructure.com/introducing-photostructure/ https://blog.photostructure.com/introducing-photostructure/ has more background and signup information. Disclaimer: I'm the author.
yboris 7y ago
If you happen to know Angular, it takes 1 minute to have something working: https://github.com/maximegris/angular-electron https://github.com/maximegris/angular-electron The thing I built has enough code you can learn from to get you farther: https://github.com/whyboris/Video-Hub-App https://github.com/whyboris/Video-Hub-App
CmdrKrool 7y ago
I have a hobby project in Electron but agree, the forced separation of "main" and "renderer" processes with multiple methods of influencing each other (ipcMain/ipcRenderer, remote, webContents.executeJavascript/send), and the further splitting of the renderer process into multiple similarly-named substructures (webFrame, webview, BrowserWindow, webContents) is a lot to get one's head around right off the bat and make stick, especially if you're the sort who wants to survey and disambiguate all the facilities of the platform beneath you before starting to code, rather than just trusting tutorials and tweaking code snippets towards some degree of satisfaction if and when they 'just work'. On the Rich Hickey "simple vs easy" scale, Electron is very much leaning to the "easy" side.
52-6F-62 7y ago
Here's a very simple and terrible example. Nothing happens except the time is updated every second in the render process. This runs at 90.3 MB RAM usage on my machine and builds to 165.7 MB. It's about as bare of a reference as you might find. Have at it. (Also there's no Readme, just consult the package file. I only threw this together when I was finding my way around it this spring) https://github.com/Robert-Fairley/electron-typescript-starter https://github.com/Robert-Fairley/electron-typescript-starte...

rado 7y ago

Appreciating the contrast with the 512-byte OS posted today.

mothsonasloth 7y ago
Its a valid point, the average computer in the Western world is at least 4GB. However when I was in South Africa a few years back they were still running with XP and < 2GB RAM with HDDs that I saw in a school and hotel. Ok, hardware components are cheaper and easier to come by but we shouldn't stop caring about system resource usage.
- iamnotacrook 7y ago
  If they're using old PCs running deprecated versions of Windows then they long ago stopped caring about resource usage and efficiency (energy usage and operator time) and are instead optimising for hardware cost. It's no reason to favour this or that platform for development.
  - clappski 7y ago
    > instead optimising for hardware cost I imagine a big reason that they're on old hardware is cost - just because it's relatively cheap for someone in the West to get a decent modern machine at a reasonable cost doesn't mean that it's the same everywhere, especially when there's big disparities in the purchasing power of the native currency vs. the sellers/manufactures currency. It's not so much an optimization, I imagine most users on legacy hardware don't choose to be, it's more likely that they can't afford more modern hardware or it isn't available for them to purchase. Another huge reason for users to stay with older operating systems (especially in business and government) is dependencies on legacy software - if an organization relies on software that has never been updated after Windows 95/XP and doesn't function on later versions then they're going to be stuck using legacy machine configurations until the process can be changed to something else. > stopped caring about resource usage and efficiency (energy usage and operator time) How do you know that they don't care about how efficiently they can use a machine for whatever they're doing? It's a baseless assumption. Even if your user percent that's stuck using older hardware/operating systems is in the single digits, that isn't an excuse to ignore their requirements IMO. Doing so is a sign of sloppy engineering, akin to designing a new mode of public transport, for example, that doesn't cater for disabled people.

Robin_f 7y ago

Great, another release not supported by Spectron so you can't actually write tests for it.

daliusd 7y ago

Almost two years ago I have created app (using Electron) that takes xlxs template and data files and generates bunch of xlsx files [1]. It was Electron 1.7.8 and now it is 6.0.0. I guess I need to check it out again. [1] For curious: https://github.com/daliusd/xlsx-generator https://github.com/daliusd/xlsx-generator

simlevesque 7y ago
You should add a screenshot in the readme.
- daliusd 7y ago
  Thank you. Done.

polote 7y ago

Every time I hear about Electron, I have mixed feeling about it, is it : * one the best thing that happened to desktop software as it enable web developers to build desktop portable app * one of the worst thing that happened, because it makes the desktop world rely on Google and decrease even more the expectations on how much resources an app should consume What are your opinions ?

kgraves 7y ago
The latter, I have a 3GB laptop. Almost any application I use that is electron makes my laptop scream for help (fan spinning furiously) and freezes it up. I have to kill the application before it consumes everything. Electron applications like VS Code are an exception and slightly gives me hope.
- stevewodil 7y ago
  Does anyone know what makes VS Code an exception to this? Going to be working on an Electron app, so I'm curious about what optimizations have been made there.
  - 52-6F-62 7y ago
    I can't speak to VSCode, but I've been probably a hard use case for Electron development as I work in an industry without a ton of resources to throw at development, limited time, and less supportive environment for development (in spite of a pressing need to keep up). I've found keeping as precious little of the work in the render process as possible has helped a great deal. Send everything to the main process and use the event/messaging system to update the state. Then things that you're used to doing to maintain application performance in a web browser apply. Keep the compute in the back as much as possible. And depending on the task, offload compute to a native module [if you're capable and] if the expense between NodeJS <> native module is worth it (more intense compute tasks). There's probably more and more experienced advice out there, but this is my experience so far.
  - jayjader 7y ago

interfixus 7y ago

I once drove a huge refrigeration truck across Australia. The full cooling system was running all the way, although storage was howlingly empty, save for twenty liters of drinking water, kept there because the fridge in the driver's cabin had broken down. Electron always reminds me of that trip.

ktpsns 7y ago
I love that analogy. The fridge in the driver's cabin is a web widget in a traditional toolkit, for instance https://doc.qt.io/qt-5/qtwebengine-webenginewidgets-markdowneditor-example.html https://doc.qt.io/qt-5/qtwebengine-webenginewidgets-markdown... The large cooling system which requires a substantial amount of fuel is Electron.

gingabriska 7y ago

Can anyone suggest a software niche where Electron has not be used so far? Here is one I think: 3D printer slicer, to my knowledge there is no slicer which uses electron I think it limits the contributers who can quickly deploy plugins in JavaScript

nickexyz 7y ago
For slicers there is https://pathio.xyz https://pathio.xyz. Not fully Electron though, which is probably a good thing.. Edit: https://pathio.xyz/hello-world https://pathio.xyz/hello-world "Pathio is built on a mixture of modern web-technology (Electron) and a powerful native slicing engine (written in C++17)"

rvz 7y ago

It's kind of interesting to see this release and previous ones mention 'performance fixes' (V8 and Blink does all the work) that it brings, yet the job postings for desktop software engineer requiring Electron experience also put data structure and algorithms and what I see here is a runtime that is very expensive in both space + time complexity. It makes no difference in using a different language with a faster runtime to combat this. Imagine if I were to write a 'next-gen' CAD program or an alternative 3D modeling program in Electron. I'm not so sure if the manufacturing or the games industry would take a second look at that. But in our industry, it is seen as normal for our text editors, ide's, git clients and video editing software and our messaging clients to be expensive in memory and cpu time. Can't we do better than this? Or do we have to accept and depend on Google to create our desktop software?

ComodoHacker 7y ago
There are better alternatives, in almost every possible way. The problem is they aren't that popular. And you can't reuse code (and coders) with web version of your app.
- dgellow 7y ago
  Alternatives that are supported cross platform? That’s the only reason I would potentially consider Electron.
  - davojta 7y ago
    https://en.wikipedia.org/wiki/Chromium_Embedded_Framework https://en.wikipedia.org/wiki/Chromium_Embedded_Framework is support linux, windows and macos
    - wongarsu 7y ago
      With CEF you can write your business logic in a better language, but the UI suffers from the same problems as Electron since it's basically the same thing.
  - 7y ago

mothsonasloth 7y ago

It seems like you have three choices at the moment for desktop development (for non .NET) that I am aware of. * C++ and GTK or other UI framework : hard but excellent performance. * Java and Swing UI framework : easier but less performant. * Javascript and Electron : easy but terrible performance. Which one will prevail?

shifto 7y ago
Python and TkInter : always better than electron
- royal_ts 7y ago
  can you style anything taht comes with TkInter? It looks ugly af if not
  - shifto 7y ago
    Yes, you can definitely make it way more ugly than default. :)
kgraves 7y ago
Qt & PyQt?
- adem 7y ago
  > [...] GTK or other UI framework [...]
  - roryrjb 7y ago
    Yeah but the list specifically mentions C++, which I think is part of the reason why this category is hard. Python on the other hand is definitely more entry level friendly but it's still Qt. This should be emphasised.
    - 7y ago

Epskampie 7y ago

Can anybody explain why electron includes all off * chromium * node.js * v8 ? To my understanding chromium includes V8, and node.js is built on top of it.

truth_seeker 7y ago
ElectronJS Application Architecture - https://electronjs.org/docs/tutorial/application-architecture https://electronjs.org/docs/tutorial/application-architectur...

wongarsu 7y ago

> Per our support policy, 3.x.y has reached end of life. 3.0.0 was released 10 months ago. If the current frequency of releases stays constant any version reaches end of life after about 9 months.

NullPrefix 7y ago
Electron does not have a LTS branch ?
- giancarlostoro 7y ago
  They have "Stable" releases: https://electronjs.org/releases/stable https://electronjs.org/releases/stable I'm guessing their LTS is whatever Google's released to an extent. Google Chrome is the basis for Electron, it would be a bad move to be over a year behind Chrome, which would lend to poor support from Google Chrome's dev team. At least that's my take on it, I'm not involved with either project. Maybe someone else here has better input over the matter.
- wongarsu 7y ago
  They support the last three major releases, and that's it. So right now that's 6.x.y, 5.x.y and 4.x.y. A new major release is released about every 3 months. To quote the official stance: "If an application has exceptional circumstances and needs to stay on an unsupported series of Electron, developers can silence the end-of-support warning by omitting the final release from the app's package.json" [0] [0] https://electronjs.org/docs/tutorial/support#supported-versions https://electronjs.org/docs/tutorial/support#supported-versi...
  - imtringued 7y ago
    Considering how electron applications are deployed "exceptional circumstances" covers every single electron app in existence.
JCSato 7y ago
Oof. I thought it was surprising to see 6 out already. . .

aorth 7y ago

No mention of Wayland support, which means that desktop applications like Skype and Signal will continue to have a poor user experience on GNU/Linux unless you use Xorg. Using these applications with fractional scaling in Wayland is a bit rough—I guess we are waiting for Google to land patches upstream of Electron in Chromium?

TingPing 7y ago
It depends on Chromium but as I understand it is being worked on.
snazz 7y ago
Have you noticed any issues with XWayland aside from the DPI scaling? I find it pretty seamless on a standard-DPI (or a little higher) monitor.

rhabarba 7y ago

Security Risk 6.0.0.

ksec 7y ago

Hopefully with Apple's Catalyst, there wouldn't be a single Electron Apps ( Ok apart from VSCode ) on my MBP. If you want iOS or iPadOS, you need to be Native. And you can now port it to Mac with ease. The days company ship crappy Desktop software with Electron needs to come to an End.

ausjke 7y ago

Electron is the true and only available cross-platform desktop build environment these days, it actually makes business sense for many. All alternatives(Qt, whatever) come out short in my opinion. The major complain of course is its memory/disk space. I don't see how that's going to be resolved soon even though RAM/Disk is cheap these days, maybe a smaller js engine, or maybe replacing nodejs with something lighter(e.g. golang backend). Another approach is to run a local daemon(e.g. one go binary) that does all the backend operations(filesystem, network,etc), while use browser as your UI.

localhost 7y ago
I have no idea why you're being downvoted for this. I like your idea about a golang backend. In fact, the entire application can be packaged within a single golang binary which provides simple distribution and only requires the user have a modern browser installed on their computer. .NET Core recently added self-contained executable support so there are more options available today than just golang.
ausjke 7y ago
I'm more and more confused these days by the downvotes at HN, I found I need be "100% politically correct" for technical discussions here(i.e. nothing negative at all, even for critical thoughts or neutral comments, neither is enough though, the comments actually has to be perfect positive), people are so sensitive these days, including me who actually cares about downvotes, which is a bad sign.
megous 7y ago
That will not help much. V8/node is not that big. The big part is chromium.
- ausjke 7y ago
  slack desktop is 60MB zipped. after unzip it's 205MB while slack binary itself takes 115MB, indeed node_modules only took 8MB, https://github.com/electron/electron/issues/2003 https://github.com/electron/electron/issues/2003

wlesieutre 7y ago

Not mentioned in the release notes, but if I'm not mistaken this update adds support for Touch ID. I thought that was coming in 5 but it looks like it didn't. https://github.com/electron/electron/pull/16707#issuecomment-506392471 https://github.com/electron/electron/pull/16707#issuecomment... Welcome to 2016, electron apps! This should help BitWarden be a more competitive alternative to 1Password for Mac users.

rafaelvasco 7y ago

It seems to me that the short term solution for the runtime overhead is to have the core runtime running in the background and the applications running decoupled from it on top. Is there any reasonable mature project going this way ?

waldsonpatricio 7y ago

One library that is trying to be the mid-term between native performance and ease of use is Revery[1]. [1] https://www.outrunlabs.com/revery/ https://www.outrunlabs.com/revery/

fohara 7y ago

I'm surprised Kivy [0] doesn't get more attention for desktop app development. Apps are developed in Python, it's cross-platform and MIT licensed. Running the hello world example uses just ~2.5% cpu and ~57mb memory on a 2015 mbp. [0] https://github.com/kivy/kivy https://github.com/kivy/kivy

deleted 7y ago

[deleted]

gpsx 7y ago

I feel embarrassed to ask such an obvious question, but what would it take to _not_ download electron with every app? I assume the main drawback to doing this is having the correct version. This isn't a big problem for web browsers.

edflsafoiewq 7y ago
Arch packages the Electron runtime separately from apps. https://wiki.archlinux.org/index.php/Electron_package_guidelines https://wiki.archlinux.org/index.php/Electron_package_guidel...

dirkg 7y ago

Its always the same complaints about Electron's size/runtime. Try to build a desktop app using a native language/UI framework of your choice (C#/Java/C++ with whatever fancy UI libs you want) which will even come close to the power or HTML+CSS - hint, you can't. Just trying to implement the layout/cascading behaviors, never mind all the stuff on top, would take forever. Next add the fact that you can get true cross platform apps with a single code base in reality, not the pseudo lies promised by ReactNative or the even more ridiculous RN on Web, or new pretenders like Flutter. Electron isn't being used for tiny utilities - its used for apps like Slack/VSCode which really do need to run on multiple platforms and have the exact same UI/UX, which is simply impossible even if you dedicate 3 dedicated teams at 3-5x the cost. Why don't people complain about how bloated browsers are? Electron is simply V8+Node bundled for desktop use.

z3t4 7y ago
If you statically link the ui lib - the binary can become quite large too. Another option is to make a web app and use "add to desktop".