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

Electron is flash for the desktop (2016)

josephg.com

Post reply on HN
Print view View original

291–300 of 1001 posts

Re: Electron is flash for the desktop (2016)

#291

Post by vmasto »

carlosrg wrote: post #144
anaisbetts wrote: post #74

Here's the thing. You know what the alternative to all of these Electron apps coming out is? If your answer is "A native Cocoa/WPF app", you are on another planet, the answer is, "It wouldn't exist at all". Nobody in the last 5-10 years cared about writing Desktop apps before Electron came along, there's basically zero money in it, and it's massively expensive, both in terms of actual dev time per feature (easily 10x…

Bullshit. Spotify, for example, existed before Electron, and it was very fast. Text editors existed before Electron, and they didn't require 300 MB minimum to run. Same with collaborative chat programs. Electron is just a way to reuse web developers for desktop development - I.e. a way companies now have to cut development costs.

I'll give it a go to call you on "bullshit": Spotify is not built on Electron. (Surprise, the author is wrong).

It is and was, however, always built on Chromium Embedded Framework (the UI), even when you say it "was" fast.

Re: Electron is flash for the desktop (2016)

#292

Post by mlsarecmg »

josephg wrote: post #199
yesimahuman wrote: post #175

Earlier quoted context omitted.

But the user experience is already great, so what's the gain? Electron and the web clearly make a first class app platform on desktop. EDIT: thanks for the downvotes. I'd love to hear your thoughts on how electron is keeping Slack and Spotify from building a massive business and how their desktop users find the experience so bad they don't use the tools obsessively. Clearly there are things to improve w/ Electron (en…

Its a terrible experience to discover my battery life is cut in half because of a cursor animation in VS Code, or to have my laptop heat up and the fans engage because of an animated GIF in slack. But its worse than that - most users don't even know why their battery life is awful. So they blame apple, or microsoft, or dell or whoever. And they just don't use their computers as much, because its all a bit gross and s…

Hasn't it already been pointed out a thousand times now that this was just a bug in Chrome that has been fixed right away?

Re: Electron is flash for the desktop (2016)

#293

Post by DLudwig »

paraboul wrote: post #14

FWIW, we're working on https://github.com/nidium/Nidium presicely to fix this. A new kind of browser engine, not based on any existing engine, allowing developers to use a subset of the web (webgl, 2d, layout) without being forced to use a bloated ecosystem (and which also works on mobile and low end device). Previous HN discussion : https://news.ycombinator.com/item?id=6314961

Is Nidium being used in any real applications (or games)?

Are the needs of specific applications (or games!) influencing the feature set of Nidium?

Re: Electron is flash for the desktop (2016)

#294

Post by fauigerzigerk »

mentos wrote: post #115
anaisbetts wrote: post #74

Here's the thing. You know what the alternative to all of these Electron apps coming out is? If your answer is "A native Cocoa/WPF app", you are on another planet, the answer is, "It wouldn't exist at all". Nobody in the last 5-10 years cared about writing Desktop apps before Electron came along, there's basically zero money in it, and it's massively expensive, both in terms of actual dev time per feature (easily 10x…

I agree and the author fails to mention the tradeoff between ram/diskspace and development time. >>all you web devs: Go learn C or Rust or something. Your program runs on a computer. I don't think that is a realistic request. When the cost of Slack's ram/diskspace usage starts affecting their profit then they can/will take steps to re-write the application in 'native' code. Until then its premature optimization?

Premature optimization used to mean optimizing something that doesn't cause any noticeable performance degradation.

I think it's a mistake to redefine it as optimization that doesn't affect profits. Companies often get away with painfully broken software for a long time because they benefit from some other moat (e.g banks). But they're setting themselves up for disruption by doing that.

Also, profits are not the only purpose in life if you value your craft. (I'm not denying that you have to be able to afford high standards and economics does play a legitimate role)

Re: Electron is flash for the desktop (2016)

#295

Post by tommoor »

pabloski wrote: post #95
migueloller wrote: post #16

> If you want to use JS and react to make a native app, try react native instead. Given the discussion of the recent ReactXP thread, I'm guessing most people don't realize you can do this today . React Native supports macOS [1] and UWP [2]. Edit: There's even some early work on Ubuntu support [3]. [1] https://github.com/ptmt/react-native-macos [2] https://github.com/Microsoft/react-native-windows [3] https://github.c…

And no, I didn't know React Native supports Windows and MacOS. I did know it was iOS/Android only. I think the choice is obvious at this point, if the Windows version is complete and stable, I will start using it instead of Electron.

react-native-macos is a great project but it's not sponsored by Facebook and is way behind Electron in terms of the exposed API's and stability.

Re: Electron is flash for the desktop (2016)

#297

Post by frozenport »

BuuQu9hu wrote: post #174
anaisbetts wrote: post #74

Here's the thing. You know what the alternative to all of these Electron apps coming out is? If your answer is "A native Cocoa/WPF app", you are on another planet, the answer is, "It wouldn't exist at all". Nobody in the last 5-10 years cared about writing Desktop apps before Electron came along, there's basically zero money in it, and it's massively expensive, both in terms of actual dev time per feature (easily 10x…

Here's the thing. You know what the alternative to all of the JS that's been written? If your answer is "Keep writing more JS," then you are on another planet. The answer is, "We have fucked ourselves as an ecosystem by permitting a monoculture to flourish, especially one which prides itself on worship of bad languages, bloated runtimes, convoluted abstractions, and general fuckery." Nobody in the last ~20 years has…

I know it's a parody but:

https://github.com/jashkenas/coffeescript/wiki/list-of-langu...

Re: Electron is flash for the desktop (2016)

#298

Post by atombender »

Touche wrote: post #113
matthewmacleod wrote: post #97

Earlier quoted context omitted.

That's nonsense . Desktop apps have been frequently released since forever. The underlying issue here is that Electron reduces the barrier to entry for cross-platform development . That is, it's cheaper to build a single cross-platform application in Electron than it is to build two or three native applications, and you can re-use your existing web experience. I can completely understand why companies might choose th…

> They fail to integrate with the host platform Just as a counter-point, because native app fans often make this point as though it is universally recognized to be a good thing. I don't want apps to integrate with the host platform. The host platform is not the thing I care about. I use several host platforms in different contexts (I have work and home computers and a smartphone, they all run different OSes) and I wo…

I doubt you don't care. These are examples "integration with the host platform":

* Text selection

* Caret behaviour (e.g. Option-arrows on macOS)

* Clipboard

* Spell check

* Open/save dialogs

* File system access

* Drag/drop

* Window management

* Accessibility (screen reader support etc.)

* Standard right click menus

* Indexing (e.g. Spotlight on macOS)

* etc.

You may be thinking to native UI idioms, which even Apple threw out the window several years ago.

Electron apps are mostly very good at the things in the above list, because the Chromium web renderer has spent years abstracting the mechanisms needed to feel native where it matters.

Non-native toolkits such as Swing and Qt also spent years trying to achieve native look/feel, mostly through emulation and host OS detection, and they still feel pretty crappy compared to Electron apps.

Slack, Spotify and friends do a good job of inventing their own "web but native-feeling" UI. An example of the exact opposite is Google Docs, which still, for all its technological impressiveness, feels like a crummy Swing app trapped in a web page. For example, Google Docs renders its own right-click context menus, which look and feel nothing like native context menus. Google Docs' mini-apps also have a menu bar and a toolbar, but it's part of the host window, so you get two levels of menu bars and tool bars.

Re: Electron is flash for the desktop (2016)

#299

Post by kevinchen »

wfleming wrote: post #50
Ambroos wrote: post #18

A lot of Slack's high (background) CPU usage is caused by GIFs, in my experience. Just did a quick check on my quadcore MBP, having Slack fullscreen out-of-view with nothing animated in view gives it a CPU usage of 0,1% with spikes up to 2,5%. Switch to a conversation with a single animated party parrot emoji, go to another fullscreen app once again, and CPU usage never drops below a whopping 22%. For an animated par…

I've noticed the same myself, and I'm a bit surprised Slack hasn't done the same trick some of the larger image hosts have and started converting gifs to videos. Those hosts did it to cut bandwidth costs, but it also helps users as a side effect. (I continue to be amused that everyone records & shares gifs for "compatability" and "simplicity", but many of the places they're shared re-convert them into videos.)

I know nothing about how Electron renders GIFs, but can guarantee you that there's no world where 16x16 animation should take up 20% CPU. Suggesting that we should convert them to tiny videos is completely missing the point.

Re: Electron is flash for the desktop (2016)

#300

Post by dheavy »

sametmax wrote: post #182

People complaining about electron are the same type than the ones that used to say : - why are people writing this stuff in C. It's so slow and you don't have as much control on memory. Write it in Assembly. - why are people writing this stuff in Java. It's so slow and you don't have as much control on memory. Write it in C. - why are people writing this stuff in Python. It's so slow and you don't have as much contro…

Amen
Post reply on HN