Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Electron 7.0

electronjs.org

Post reply on HN
Print view View original

71–80 of 289 posts

Re: Electron 7.0

#71

Post by windsurfer »

maxbrunsfeld wrote: post #65
windsurfer wrote: post #35

Earlier quoted context omitted.

Well, Slack is currently taking almost 3 GB of memory on my machine. Not entirely sure if that's due to Electron or Slack, but I have never found an Electron app that didn't consume vast swathes of memory. https://imgur.com/GscRFD7.png

It is not because of Electron. An empty Atom window containing 5 source code files consumes about 120MB of RAM. For comparison with native apps, an empty iTerm2 window uses 100MB, and so does an empty Notes.app window. The base memory footprint imposed by Chromium is not that significant.

On my machine, an empty Atom instance is using about 400 MB: https://imgur.com/S1POSPz.jpg

Re: Electron 7.0

#72

Post by vips7L »

windsurfer wrote: post #35
eicossa wrote: post #23

Wait ... let me see if I can anticipate the top comment "Electron consumes so many resources ... Why so resource hungry ... My workstation already runs Chrome, can't have electron apps bogging it down ... Slack runs on Electron ... VSCode is the only good Electron app ... Why are we doing this ... Dennis Ritchie would be turning in his grave" This topic could honestly trigger the "parse regex with html" kind of reply…

Well, Slack is currently taking almost 3 GB of memory on my machine. Not entirely sure if that's due to Electron or Slack, but I have never found an Electron app that didn't consume vast swathes of memory. https://imgur.com/GscRFD7.png

Slack is currently only using 90MB on my machine...

Re: Electron 7.0

#73

Post by gsaga »

eicossa wrote: post #23

Wait ... let me see if I can anticipate the top comment "Electron consumes so many resources ... Why so resource hungry ... My workstation already runs Chrome, can't have electron apps bogging it down ... Slack runs on Electron ... VSCode is the only good Electron app ... Why are we doing this ... Dennis Ritchie would be turning in his grave" This topic could honestly trigger the "parse regex with html" kind of reply…

I agree, imagine not having a 32gb workstation in 2019.

Re: Electron 7.0

#74

Post by maxbrunsfeld »

windsurfer wrote: post #71
maxbrunsfeld wrote: post #65

Earlier quoted context omitted.

It is not because of Electron. An empty Atom window containing 5 source code files consumes about 120MB of RAM. For comparison with native apps, an empty iTerm2 window uses 100MB, and so does an empty Notes.app window. The base memory footprint imposed by Chromium is not that significant.

On my machine, an empty Atom instance is using about 400 MB: https://imgur.com/S1POSPz.jpg

Do you have some packages installed? If so, can you re-run with `atom --safe`?

Granted, it is totally normal to have packages when using Atom, but their memory cost shouldn't be considered a penalty that you pay due to Electron. Rather, it's a penalty that you pay if you want an extensible application in which extensions are allowed to use JavaScript.

Re: Electron 7.0

#76

Post by The_rationalist »

As in every election threads, people will say "duh each electron has it's own instance of chromium" While you can trivially use solutions such as https://github.com/sentialx/electron-global To fixe the issue. Moreover, Carlo solve this too. Ionic and Cordova (the electrons of the smartphones) already use locally installed browser.

Re: Electron 7.0

#77

Post by rolleiflex »

scrollaway wrote: post #5

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,…

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. (An async collaboration tool for engineers)

Re: Electron 7.0

#78

Post by lukevp »

thrower123 wrote: post #69
scrollaway wrote: post #5

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,…

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 h…

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.

Re: Electron 7.0

#79

Post by emiliobool »

scrollaway wrote: post #39
blux wrote: post #31

Earlier quoted context omitted.

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?

> 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 lik…

not exactly the most performant but there is https://ultralig.ht/

Re: Electron 7.0

#80

Post by coldtea »

scrollaway wrote: post #32
Razengan wrote: post #17

Earlier quoted context omitted.

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?

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…

>Insert any framework in place of SwiftUI. You're describing Qt, essentially.

Only Qt never had the funding or resources or will to get native UI right.

Their non-native widgets are always off, in a way that even Electron, is not (because it being web-based means it at least follows familiar conventions for all web users, where a mimicked native GUI enters the uncanny valley).

There are also custom native but not platform-native (meaning close to the metal, no web-based) GUIs like Adobes, Fruity Loops, and others, that look good on all platforms and users have no issues with them.

Post reply on HN