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

201–210 of 289 posts

Re: Electron 7.0

#201

Post by cweagans »

inferiorhuman wrote: post #196
cweagans wrote: post #178

Earlier quoted context omitted.

> So I can run proprietary apps (because that's what these self-professed app devs are talking about mostly)? Not gonna happen. Well then you don't want it that bad. > I haven't found that killer Electron app just yet so what that means in practical terms is that VS Code goes bye bye when my MacBook Pro finally dies and I move away from Apple (and likely to OpenBSD) on the desktop. You seem to care an awful lot about…

You seem to care an awful lot about an issue that doesn't seem to affect you. Why? Because it does effect me. Electron is promoting a monoculture of apps that don't behave well (resource usage, accessibility, abysmal native integration) and they're not portable to boot. What that means in real terms is that more and more that quality native apps become less common and hacky Electron apps become more common. Unless yo…

> Because it does effect me. [..] VS Code? Definitely not my first choice, but its rust support is still better than IntelliJ

So choose an Electron supported OS or add OpenBSD support to Electron somehow. If VS Code is important enough to you, then that's a trade-off you have to make.

I don't think I'd agree that Electron is "hacky". I'd certainly say it has shortcomings, but what technology doesn't? Rust certainly does, but you tolerate it because you (presumably) enjoy/use the language for things you care about.

At the end of the day, most users aren't going to give a shit about what technology a thing is built with as long as it works moderately well. Solo developers being able to provide an application to 3 desktop platforms (one of which is historically underserved) with a single codebase is a powerful thing. The same argument applies to cross platform mobile technologies. Flutter, as an example, doesn't support WebOS, but it supports the vast majority of users, so it's gaining traction. Yeah, there are some tradeoffs, but I challenge you to find a technology where no such trade-off exists.

Since you mentioned Qt: Qt's main audience is C++ developers. I have no interest in writing C++. There are Qt bindings for other languages, but good luck finding one that's as well supported as Qt's C++ ecosystem. There are a couple of commercially supported Python options, but then you have packaging woes. Plus, you have to worry about licensing. Or I could use Electron, reuse a lot of the code that I've already written for my web app, sprinkle in some desktop integration, and I'm off to the races.

As an aside, the Rust language server (and most other language servers) works pretty well with Neovim. You can probably get at least the same experience with some work on your part. I assume the same can be said of Emacs, but I don't have the dexterity or number of fingers necessary to use it, so I don't know for sure.

Re: Electron 7.0

#202

Post by saagarjha »

killface wrote: post #199
saagarjha wrote: post #166

Earlier quoted context omitted.

> It's a bit silly every application would follow the same guidelines as applications are intended to do different things. Platform UX/UI conventions place too strict limitations on innovation. They really don’t. Have you taken a look at the thriving ecosystem of native, powerful macOS apps that follow platform conventions?

My mac's primary purpose is to run bash, firefox, intellij, and docker. they've all got their own UI, and I don't feel wanting for power.

That’s not the assertion I was refuting, which claimed that Apple’s platform conventions restricted the power of apps.

Re: Electron 7.0

#203

Post by pookeh »

m_fayer wrote: post #151
dewey wrote: post #93

Earlier quoted context omitted.

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.

I think this peaked some time around 2015. Back then, I remember many developers getting up in arms about following Apple's guidelines to a T, or insisting that Android apps look like a hyperactive stack of colorful paper cutouts under a direct light. Since then, I think many of us have gotten tired of looking at overdesigned sameness that by now we all know will age quickly. Programmers no longer see the sense in ch…

You are right but at the same time I am willing to bet you 5 years later someone else will make the opposite argument and be upvoted the same.

It's a pendulum.

Re: Electron 7.0

#204

Post by bhhaskin »

pmarreck wrote: post #200
Hendrikto wrote: post #6

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.

1) Log into Slack in Chrome 2) Log into Discord in Chrome 3) Log into in Chrome Problem solved?

Swap Firefox for Chrome and you are golden.

Re: Electron 7.0

#205

Post by martin1975 »

_bxg1 wrote: post #106
martin1975 wrote: post #89

Earlier quoted context omitted.

ironically, java applets provided via the JVM a way to run multiplatform, perhaps not all applets off a single JVM - I don't remember exactly if each java applet used its own JVM, but it wouldn't be a radical departure to have the JVM run multiple applets, cross platform, which is the entire reason the JVM was invented. Now instead of the JVM, we've these rather beefy runtimes due to Chrome, Node.JS, Javascript (v8).…

The key differences between Electron and Applets are: 1) Java applets were awful to use in the browser 2) The DOM is the most advanced and flexible (and, yes, resource-hungry) UI layout system ever created. Seriously. Swing didn't come close in terms of the sheer breadth of possible interfaces one could create.

what do you make of JavaFX then, which has improved on some of the points you speak of...?

Re: Electron 7.0

#206

Post by yodsanklai »

AnIdiotOnTheNet wrote: post #85
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,…

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…

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

Re: Electron 7.0

#207

Post by alyandon »

crispinb wrote: post #144
mangosherbet wrote: post #29

Is there a good introduction to starting development with Electron as someone who is a C++ developer? I find web development quite difficult to grok in general; lots of frameworks and technologies.

Quelle horreur - clearly web tech is the future of UI, and electron is a reasonable choice until a better solution comes along, but the ecosystem is a foul mess for developers. `npm [anything]` fills your hard drive with an astronomical tangle of hideous code. And there's webpack. You will end up wanting to strangle yourself. Avoid unless you really need it.

I'm normally a backend developer but I was fooling around with using vue.js + jquery to build a simple SPA without the typical process of npm install .

When it came time to finally bundle my app into a single html + js file I settled on (well was forced to really) npm install rollup. After installing rollup, I had a package-lock.json file that was 1880 lines long with approximately 150 or so dependencies and a node_modules directory so huge that vscode choked trying to parse everything in it. To its credit, vscode asked me if I wanted to exclude node_modules from future consideration.

All that from installing a single tool via npm. I just don't get modern web development.

Re: Electron 7.0

#208

Post by inferiorhuman »

cweagans wrote: post #201
inferiorhuman wrote: post #196

Earlier quoted context omitted.

You seem to care an awful lot about an issue that doesn't seem to affect you. Why? Because it does effect me. Electron is promoting a monoculture of apps that don't behave well (resource usage, accessibility, abysmal native integration) and they're not portable to boot. What that means in real terms is that more and more that quality native apps become less common and hacky Electron apps become more common. Unless yo…

> Because it does effect me. [..] VS Code? Definitely not my first choice, but its rust support is still better than IntelliJ So choose an Electron supported OS or add OpenBSD support to Electron somehow. If VS Code is important enough to you, then that's a trade-off you have to make. I don't think I'd agree that Electron is "hacky". I'd certainly say it has shortcomings, but what technology doesn't? Rust certainly d…

So choose an Electron supported OS

Why? My whole point is that Electron is encouraging developers to not support other platforms. That's not helped by simply using something that the Electron devs have blessed. The absolute last thing I want is Electron to dictate which platforms I can and cannot use.

or add OpenBSD support to Electron somehow.

This too seems like a fools errand as the Electron devs have decided that anything beyond Windows, MacOS, and Linux will not ever have official support.

Since you mentioned Qt: Qt's main audience is C++ developers. I have no interest in writing C++.

Then don't. I'm currently working on a project that's using a rust backend and a Qt/QML front end. If you're more comfortable with JS then QML is an easy leap. The caveat being that you've got to drop down to C++ for some things. The biggest example I've seen is table data sources, but even that is due for vastly improved QML support in the next version of Qt.

Or I could use Electron, reuse a lot of the code that I've already written for my web app, sprinkle in some desktop integration, and I'm off to the races.

Right, and now we're back to "this sounds good to the devs" while the users suffer. In the mobile sphere where this has been common for a longer time, reskinned web sites work extraordinarily poorly. For example: Apple adding native app support to iOS, Facebook dropping their HTML5 based apps, and nearly any other app that's a lightly skinned site (BBC and NPR come to mind). It's not any better on the desktop side as evidenced by the poor accessibility and resource usage of Electron apps.

Low effort cross platform toolkits have never yielded particularly good results. And while I think Qt is still pretty damn clunky on OSX, the solution isn't to run towards a product that exacerbates the problems.

As an aside, the Rust language server (and most other language servers) works pretty well with Neovim. You can probably get at least the same experience with some work on your part. I assume the same can be said of Emacs, but I don't have the dexterity or number of fingers necessary to use it, so I don't know for sure.

Yeah, I've flirted with Emacs for a few decades now but never warmed up to it (and it really is the epitome of a non-native app). Vi (typically vim) I use for some things (even with rust dev), but I'm not about to replace a full blown IDE with it.

Re: Electron 7.0

#209

Post by nobleach »

tybit wrote: post #193
rolleiflex wrote: post #140

Earlier quoted context omitted.

That is true and as a user of Sublime myself, I agree. However, VSCode is still a JS app that has to do its computation on a single thread, on a largely interpreted language. If you do it the way I do and use Electron as a skin / thin client to a compiled binary within the package, you remove that bottleneck. That way, you get both cross-OS capabilities, a familiar UI toolkit (JavaScript, I use Vue) and native binary…

I really hope this is the sort of thing products like VSCode will start turning to WASM for. Performance is their Achilles heel for the time being even though they’ve done a relatively good job considering.

A couple of things here. WASM isn't necessarily more performant than vanilla JS. For the web, it'll open the door to the JS engine as a compile target, and that's great.... but it's still not super fast.

Secondly, in the case of an application, WASM is of little use since (with node and almost any programming language) you have an FFI available. One could simply shell out computationally heavy things to C++ or whatever else. This is what many folks do with their Electron apps already (via node-ffi).

Re: Electron 7.0

#210

Post by marmada »

dewey wrote: post #93
rolleiflex wrote: post #77

Earlier quoted context omitted.

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

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.

To be honest, native MacOS UI doesn't even look good compared to the great styling you can get with HTML/CSS.
Post reply on HN