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

471–480 of 1001 posts

Re: Electron is flash for the desktop (2016)

#471

Post by fenomas »

josephg wrote: post #80
and0 wrote: post #20

Earlier quoted context omitted.

I want to say that VS Code had the same issue because of the blinking cursor, which was controlled by a CSS property to toggle.

I'm consistently blown away that stuff like this gets past testing. Personally I think every software engineer should have a CPU meter of some for running on their machine while developing. Its an essential element of seeing what you're doing. How can you write decent software without having even that much visibility over what your computer is up to while your code runs? These huge CPU sinks making it through to rele…

> These huge CPU sinks making it through to release required nobody to even glance at a CPU graph.

Every bug looks egregious in hindsight; just because an app has one is no reason to assume the engineers who made it don't bother to test anything.

Also: that particular issue only hurt idle CPU usage, and the usage was something like 13% CPU usage IIRC. It wasn't exactly the kind of thing that sets off klaxons.

Re: Electron is flash for the desktop (2016)

#472

Post by smokeyj »

MarkMc wrote: post #446
smokeyj wrote: post #403

There's two kinds of developers. Dorks who care about programming, and programmers who care about creating deliverable value. What do consumers think about electron apps? That's all that matters. Consumers don't know what the heck electron is, only that their apps work seamlessly across platforms. The only people who complain about electron apps are dorks who have an axe to grind with web developers. I'd rather have…

I completely agree with the content of your message, just wish you had used a word less derogatory than 'dorks'

I don't think it's derogatory enough. There's always these same rehashed arguments against electron - and it's always because of the same reason. The developer thinks he's a special snowflake and knows something that everyone else doesn't. He knows the "right way" and everyone else is dumb for not realizing it.

FTA: It turns out modern operating systems already have nice, fast UI libraries. So use them you clod!

FTA: Also all you web devs: Go learn C or Rust or something.

I just want to know who the hell keeps upvoting this neckbeard bullshit.

Re: Electron is flash for the desktop (2016)

#473

Post by LeoNatan25 »

grinich wrote: post #444
newhere420 wrote: post #368

Earlier quoted context omitted.

> Electron applications are shite in comparison with proper native applications. They fail to integrate with the host platform, they are slow, they hog memory and drink power. Are they though? The two applications that use the most energy on my Mac - by far - are Steam and Skype. Steam still has trouble with HiDPI and freezes when performing various UI interactions. The number of problems with Skype are uncountable.…

Another one for your list: Nylas Mail. We straight up would have not shipped it without Electron and the CPU it uses to sync is on-par with apps like Apple Mail & Thunderbird.

Nylas Mail

> Nylas Mail - The best free email app | Nylas - The best free email app

What exactly makes it "best"? It looks to offer nothing more than other "best" mail apps.

Re: Electron is flash for the desktop (2016)

#474

Post by brightball »

pdabbadabba wrote: post #172
Veen wrote: post #116

Earlier quoted context omitted.

What you call "trade-offs" appears to me to be developers externalizing their costs onto users. There are costs to developing desktop applications and developers don't want to pay them, so they make users pay for them in wasted hardware dollars, bandwidth, RAM, battery life, and poor integration.

Well, to the extent that these costs degrade the user experience, I'm not sure they really are externalizing them. Presumably they pay this cost in the form of decreased user satisfaction. It's just that this is a cost they are willing to pay. There may be an interesting economic lesson here: it really is not that easy to externalize costs. It surely can be done (air pollution), but it requires some special circumsta…

The real trick is whether or not users care about:

A) This works on all of the platforms that we use

vs

B) Performance could be better on my computer

It's been a LOOOOOONG time since I worked on a laptop where I experienced noticeable performance problems...which is almost entirely because SSD's make them so much less noticeable if you start dipping into swap unless you're really working out your machine.

For most users, just knowing it will work on their machine is a bigger influence in using the product...and therefore a greater influence on business...than the performance of that system. It's especially true with a chat system where the most important feature is that everybody on the team can get access.

Re: Electron is flash for the desktop (2016)

#475

Post by nulagrithom »

atombender wrote: post #298
Touche wrote: post #113

Earlier quoted context omitted.

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

I'm a little confused by your list... In what way are text selection, caret behavior, clipboard, spell check, open/save dialogs, drag/drop, accessibility, and right click menus not available in the browser?

Re: Electron is flash for the desktop (2016)

#476

Post by sametmax »

apostacy wrote: post #461
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…

> P.S: oh, and if electron is flash, remember that flash won the web for 15 years while it sucked. And you know why ? Because it allowed people to do stuff they wanted easily, like videos and animations. And it's not because we couldn't do it any other way, we could. Yet we had to wait almost 2 decades to see it dies, at the price of battery, stability, security and everything else. Feature trumps everything. People.…

They were crashing your browser all the time, hogging randomly CPU and were the worst vector of malware infection ever. They destroy select, right click, history, scrolling and copy/paste.

But I get your point, it's was really handy. Only this year HTML5 videos are starting to be on par with flash videos. Those were so light to download.

Re: Electron is flash for the desktop (2016)

#477

Post by edko »

user5994461 wrote: post #262
sametmax wrote: post #159

Earlier quoted context omitted.

Computing for ever. We use C to avoid writing assembly. Use Java to avoid writing C. Use Python to avoid writing Java. The world is asking for more and more software, and the resources to provide it are not following so people are taking shortcuts. Want something better ? Someone has to pay for it.

We use Java because Python proved to be too slow.

Java also has JavaFX, which comes with an embedded Webkit browser. I can create my UI with React, or any other HTML/CSS/JS library, and make it interact with code written in Java, Scala, Groovy, Clojure, Kotlin, Ceylon, Frege, etc. very easily. I think this provides all the benefits of Electron, but is even more flexible and powerful.

Re: Electron is flash for the desktop (2016)

#478

Post by mpweiher »

coldtea wrote: post #445
sametmax wrote: post #159

Earlier quoted context omitted.

Computing for ever. We use C to avoid writing assembly. Use Java to avoid writing C. Use Python to avoid writing Java. The world is asking for more and more software, and the resources to provide it are not following so people are taking shortcuts. Want something better ? Someone has to pay for it.

> Computing for ever. We use C to avoid writing assembly. Use Java to avoid writing C. Use Python to avoid writing Java. Yeah, but until Electron and they like, we seldom shipped desktop apps in anything than C, C++, Delphi etc even after all those decades. Which are all as close to the metal as can be. And in fact C/C++ can be as fast, or even faster than hand-rolled assembly most of the time (with few exception), s…

Actually, I've been shipping desktop apps in Objective-C for roughly a quarter of a century.

Gets me the high-level, Smalltalk-ish productivity when I want it (most of the time) and the low-level C efficiency when I need it (sometimes).

Having my cake and eating it, that's me :-)

Re: Electron is flash for the desktop (2016)

#479

Post by dangoor »

mtberatwork wrote: post #405
mlsarecmg wrote: post #329

Earlier quoted context omitted.

No one is scared of C# and Swift, XAML and so on, but these technologies aren't even close to what you have available on the web. React and Redux make apps possible that you wouldn't get with older technologies, not even with 10 times the effort and code. The animation possibilities, transitions, the flexibility overall, the eco system, debugging capabilities, hot module reload - if you have worked with it, you will…

> React native will probably be the best way forward. ... RN runs natively, doesn't need a browser, while being able to tap into the JS eco system. Similar arguments were made when Java first came on the scene. "Write once, run anywhere." [1] Years later, here we are again with "native" Javascript libraries. I'm sure in another 20 years or so we'll be rehashing this again, just with some other language. [1] https://e…

Java Swing wasn't native, though. SWT is more comparable.

React Native isn't "native" (in quotes), it's native... it uses the actual widgets provided by the host OS. You use similar techniques to create your UI for each platform, but you do generally need to create separate UI for each platform with React Native.

Re: Electron is flash for the desktop (2016)

#480

Post by BrunoWinck »

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…

Agreed, I'm back to thinking desktop apps, thanks to electron. I did a project with Qt last december. It's usable but very old style and the license is not very permissive. A small electron app is not as heavy as I though first.
Post reply on HN