Live data from Hacker News

Electron 7.0

electronjs.org

31–40 of 289 posts

Re: Electron 7.0

#31

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

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?

Re: Electron 7.0

#32

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'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 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.

Re: Electron 7.0

#33

Earlier quoted context omitted.

> "Separate instances of chrome for every app is dumb and consumes too much memory" That one is true though. Different Electron apps could at least share the runtime.

Is that really possible? I feel like it would only work with considerable engineering effort, and even then, probably only if the bundled Chrome instances were all exactly the same version.

This is literally how every gui library on planet earth works. Developers all build against a particular recent released version with all apps in the system expected to build against a small number of recent versions.

If this is hard maybe its because the browser isn't a very good runtime to build against.

Re: Electron 7.0

#34
post #13

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

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".

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?

Re: Electron 7.0

#35
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

Re: Electron 7.0

#36

Earlier quoted context omitted.

I imagine the different electron versions and different Chrome versions would make this hard without breaking things. Maybe a config option for "allow chromium between versions x and y" would solve this.

Shouldn‘t Chrome be backwards compatible? I would hope so at least.

Most electron projects I've seen have used webpack targeting ES2017 or earlier anyways which makes this unlikely, but if you compile for ESnext (or don't compile at all) and use a new V8 feature, you wouldn't want Chrome 69 running your app and getting stuck on old V8 not being able to use the new feature.

Re: Electron 7.0

#37
post #13

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

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".

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.

Re: Electron 7.0

#38
post #9
post #3

Since this is inevitably going to generate some discussion over native apps vs. Electron (ah there's already a fellow comment about it), I'd like to point out an example that is important to me of why Electron is an inferior experience for users: In the GitHub Desktop client, which is an Electron app, I can't spell check my commit messages, something that every text field in every native macOS app gets for free.

Web text fields should also support that functionality, so it may be a question of GitHub breaking/disabling it in some way.

You're right; I just tested it in Discord, which does have a spell checker, and it seems to use the system dictionary (but it seems one way when teaching it new words), but it's still missing other global text field functionality: https://i.imgur.com/qpOU9dz.png

The point remains: Electron apps generally lose many of the features that the host OS gives native apps for free.

Re: Electron 7.0

#39
post #31

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

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 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.

Re: Electron 7.0

#40
post #13

Earlier quoted context omitted.

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".

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?

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.
Post reply on HN