As much as HN hates Electron, it's probably one of the best things to happen on desktop, especially on linux desktop ironically.<p>It works, it's beautiful, it's easy to use, and unlike many people here, I believe the HTML/CSS/TypeScript/React is rock solid and the closest thing to THE solution to the UI problem.
Does anyone else feel that there's a huge hole in the UI world?<p>I like the electron/react/react native ecosystem - I really do, and this is coming from someone who dislikes javascript a priori. But is HTML/CSS/JS really the best we can do for desktop and mobile applications? I know responsive-cross platform saves money for a lot of startups and orgs, and I'm not saying the web stack doesn't have it's place.<p>I frequently imagine something that takes the best ideas from react/redux and from other ui and layout frameworks and lets you build something that has consistent, cross platform (desktop and mobile, maybe even web with some kind of compilation pathway to js or webasm), responsive ui, without the huge web stack. Maybe Python? It's got lots of competent developers in the market to support it. Maybe Rust or Go, if something lower-level was desired. Or language-agnostic, though sticking with one might be valuable.
Sadly the biggest problems with Electron are not yet solved:<p>1) There is no way to separate the Electron engine from your app, so you have to bundle Chrome and Node with each app.<p>2) Electron has an autoUpdater API, but since Electron doesn't solve the installation/updates problem e2e (packager + installer + updates server) it's really a half baked solution. This is specially bad in Windows since Squirrel for Windows is in my experience a disaster.<p>I have a number of Electron apps in production, internally and for our customers, and for our next desktop project we won't be using Electron.<p>The idea of using web technologies for the UI is still very valid IMO, but considering the 2 previous problems it's way less of a headache to just make our own native wrapper in C# and Swift (sorry Linux) and finally distribute the app via the official stores. At least for our use case.
I agree with all the complaints about electron performance, but the thing that really gets me is how horribly developers fail at responsive design, with a toolset that is probably the most suited for responsive design since terminals.<p>How the hell do slack, discord, and gitter STILL not collapse their sidebars when you resize the containing window to be tall and narrow? It makes them unusable in a tiling WM, and it's generally disrespectful of screen real estate in any WM.<p>This is the price of easily accessible development. We're doomed to relive past mistakes in UI, as new developers are blissfully unaware of lessons learned by existing frameworks.<p>Many people here are saying electron is popular because of a lack of sane, consistent toolkits across each OS. There's also security to think of too. Electron is likely very insecure relative to native software, but the responsibility is purely on the electron devs: freeing the app developer of that burdon. Electron rose in an environment with no competition in that regard. But now, Windows has UWP, and Mac has their own app platform. I sincerely hope we see these more universally leveraged, such that developers will stop abusing the web for app development.<p>And I guess Linux will just have to make a WINE for UWP, I can't imagine the Linux community coming together to create something like that for themselves.
It's really sad that in spite of the main glaring problem of Electron apps they didn't as much as even mention any work done on performance optimization in 2.0.0. The changes mentioned are just make up when compared to the real problem.
I wonder if it would be possible to change the electron build process so it builds 2 outputs: 1 "big" package with full Chrome inside and 1 "light" package that just contains the application code.<p>The light package could then be offered as an alternative download on the website to run on a specific "electron-runner" that can run multiple electron apps side by side.<p>I know that I just described a regular browser with tabs or windows but hey, Electron is what we have right now and it is not going away soon. This might be a solution for people running multiple Electron apps side by side.
Since it’s something I’ve been paying attention to for a while: this (beta, sure, but soon to be full. Probably would work fine for doing some dev work) release of Electron finally bundles the version of Chrome that implemented SharedArrayBuffer support. This means that developers can now spawn web workers (real parallelism) and communicate with them much faster than previously with message passing. So there could be some big wins for things like developing games in Electron since you’ll be able to do some big number crunching off the UI “thread” and hand the results back to the UI with little performance penalty. (Especially if there are a lot of results, such as a theoretical fully-updated scene graph worth of matrices in an array) Hooray for less jank on the renderer!
People not satisfied with Electron's performance might be interested in fbs [1]. It makes it very easy to create desktop apps with Python and Qt. It was in the #1 spot here two weeks ago [2]. (I'm the author.)<p>[1]: <a href="https://github.com/mherrmann/fbs" rel="nofollow">https://github.com/mherrmann/fbs</a><p>[2]: <a href="https://news.ycombinator.com/item?id=16318677" rel="nofollow">https://news.ycombinator.com/item?id=16318677</a>
What would be interacting is an electron like environment with a pared down JS/CSS engine which only let "modern JS/CSS" (maybe something like Servo). It can be optimized for that, and you don't really have to render electron apps from the 90s anyways.<p>Another idea is that when wasm will be able to interface with DOM, you'd be able to write GUI code in any language which compiles to wasm. So you won't _need_ Rust (or Go, or Haskell, or D, or your up and coming toy language) bindings for win32, Qt, GTK, etc. Just waste a few hundred megs (only partially /s) and you've got a full ui.
We have been using Electron for <a href="https://tradedash.io" rel="nofollow">https://tradedash.io</a> (our crypto currency trading platform) for some time now. There are some minor issues with the platform itself but there are a lot of good things too.<p>The JS ecosystem as a whole needs to improve but as far as Electron goes, I must say that I am pleasantly surprised with how well it has been doing even though we are handling data from multiple exchanges at a rate that is not so trivial.
You can use React and js to build native desktop apps without electron today. Use <a href="https://proton-native.js.org/" rel="nofollow">https://proton-native.js.org/</a> (based on libui).
I wonder why there is no runtime package for all your electron applications, so you only have to install the runtime once and every app can depend on this runtime. This would greatly reduce download sizes of individual applications.
What is the stack behind RStudio? It isn't electron, but it is an HTML app, run by a browser (safari on my macbook pro, wonder if it is IE on windows)<p>It doesn't feel as heavy as electron apps.
I have only a very cursory look at Electron, but I find two things problematic: Lack of support for legacy systems, and the complicated build process of apps built with Electron, most can't successfully build unless you download a ton of stuff from npm. The kind of place where I am with many many older machines, never connected to the internet, Electron hardly makes any sense.
Never really heard of Electron before I tried using KeyBase on Windows. It seems electron is the reason that it doesn't work on my machine.<p>Ran into this last night.
<a href="https://github.com/keybase/keybase-issues/issues/2813" rel="nofollow">https://github.com/keybase/keybase-issues/issues/2813</a>
Does anyone know if there has been any work on bringing the work from “headless chrome” to electron?<p>It would be awesome to be able to use the full node.js environment with a headless browser natively.(headless chrome with puppeteer is good but electron would be better)
Can anyone explain for me: WHY is electron such a resource hog? Is it just because chrome is a resource hog? Could it be trivially re-engineered to wrap quantum instead?
With all the GUI crap going on in software development, I am starting to miss MFC and BCG libraries, I know it is not feasable for most developers to code in c++ but at that time the GUI, even if run over RDP, was fast, responsive, now I having a feeling like 386 was faster than todays i7+. And to cirmuvent obvious incapability of RAD to provide decent user expirience, they are changing our UI percepction from trendy perspective, leveling everything to flat and extremly simple, like ncurses on graphical desktop. =/
Just a reminder to everyone who says there's no way to write cross platform apps:<p>TCL/TK is still a thing and MacOSX still ships with wish, it even runs on android. The one platform you can't use it for is the iPhone.