Electron is flash for the desktop (2016) • Hacker News Board

Re: Electron is flash for the desktop (2016)

#391

Post by jbeja » Tue, Apr 11, 2017, 4:39 PM UTC

newhere420 wrote: post #368

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…

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

Comparing full blown browsers and IDEs with their anemic counter parts? Seems legit.

Re: Electron is flash for the desktop (2016)

#392

Post by LeoNatan25 » Tue, Apr 11, 2017, 4:39 PM UTC

overgard wrote: post #340

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…

> 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 the cost), and also in finding specialist developers who know these dated technologies. Come on man, it's a little too easy, but NOBODY? People write desktop apps all the time. What you mean is "nobody I…

By "nobody", he means himself and his JS "hacker" "dev" peers (his words from his profile).

Re: Electron is flash for the desktop (2016)

#393

Post by jbeja » Tue, Apr 11, 2017, 4:39 PM UTC

newhere420 wrote: post #368

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…

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

Comparing full blown browsers and IDEs with their anemic counter parts and friends? Seems legit.

Re: Electron is flash for the desktop (2016)

#394

Post by bnastic » Tue, Apr 11, 2017, 4:39 PM UTC

jhasse wrote: post #118

cgh wrote: post #45

Earlier quoted context omitted.

Qt exists and is really nice to work with. It has multiple language bindings. How is it unfeasible?

> It has multiple language bindings. Not many of them are good though, as it's hard to bind C++. If you want to work with Qt, C++ is really the best option. And not many people know that language well enough. They know JavaScript though ;)

Software/web devs are such hypocrites, optimising software for production and not for the platform or the user.

Re: Electron is flash for the desktop (2016)

#395

Post by RedCrowbar » Tue, Apr 11, 2017, 4:40 PM UTC

newhere420 wrote: post #368

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…

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

Each Chrome (and Electron) app instance is a group of processes. You are probably just looking at the main process, while the bulk of RAM/CPU use comes from the renderer processes.

Here are stats on my (Linux) box:

* atom - ~500MiB (one window)

* slack - ~816MiB

* chrome - ~935MiB (two tabs + hangouts)

* google music electron app - ~500MiB

Re: Electron is flash for the desktop (2016)

#396

Post by jernfrost » Tue, Apr 11, 2017, 4:40 PM UTC

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…

1) Why use several host platforms if the platform makes no difference to you?

2) If you know a platform then you should have no problems knowing how to use it.

It would be ridiculous to have an app from Windows behave exactly the same in Mac OS just because you don't want to remember the difference. You don't want minimize and maximize buttons put on the opposite side of all other mac apps because that is how it is on windows. You don't want copy paste in Slack to use Ctrl rather than command key because that is what you do on Windows.

3) Whatever time you save from doing everything the same across platforms would be wasted, for anybody not working cross platform who suddenly have to deal with an app with completely non-standard alien behavior. I want my standard mac hot keys to work in a mac app. I want preferences to be in the standard location. I want my color and font selectors to work the way they work all other places. I want drag and drop to work like in all other Mac apps.

We Mac users have seen this again and again. When companies don't give a shit about our platform, it is usually just a question of time before a competitor arrives which does, and knocks the other guy out. You don't survive that long ignoring the platform unless you got some lock-in advantage.

Why else do you think people make a big point of an app being native Cocoa? It is because they know it sells better, because they know customers want the native well integrated experience.

Re: Electron is flash for the desktop (2016)

#397

Post by MaanuAir » Tue, Apr 11, 2017, 4:41 PM UTC

douche wrote: post #203

I'm surprised to see so little mention of Java as a cross-platform native app platform. Maybe I'm just old enough to remember coming up though when Swing and AWT were the next big thing. Nowadays, IntelliJ and it's derivatives are all Java-based, and pretty popular and performant. I love getting a chance to get out of web-dev world and go build some ugly tools with WinForms from time to time. You have to do more work…

To continue in the Java vein: weren't Eclipse SWT & RCP supposed to be the ultimate answer to native cross platform UI development in Java?

I had no experience with them: did they gain some adoption or recognition at least?

Maybe all cross-platforms app solutions are just doomed to stagnate, at least until the next hype one rises, after all.

Re: Electron is flash for the desktop (2016)

#398

Post by LeoNatan25 » Tue, Apr 11, 2017, 4:41 PM UTC

mlsarecmg wrote: post #329

maxsilver wrote: post #233

Earlier quoted context omitted.

> If your answer is "A native Cocoa/WPF app", you are on another planet If developers weren't so scared of Swift and C#, this wouldn't be a problem. > (writing Desktop apps) is massively expensive, both in terms of actual dev time per feature (easily 10x the cost), and also in finding specialist developers who know these dated technologies. I find the opposite to be almost universally true. Writing a lightweight nati…

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…

Ah, the wonders of discovering the observer pattern. It's really a life "changer". How did the computer world survive for so many decades without it.

Re: Electron is flash for the desktop (2016)

#399

Post by RandomBookmarks » Tue, Apr 11, 2017, 4:41 PM UTC

newhere420 wrote: post #368

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…

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

You need to compare apples to apples:

The right benchmark for VSCode is not Visual Studio, but Notepad++ (5.9MB on my system right now).

Re: Electron is flash for the desktop (2016)

#400

Post by MarkMc » Tue, Apr 11, 2017, 4:41 PM UTC

curun1r wrote: post #336

cpburns2009 wrote: post #229

Earlier quoted context omitted.

> Nobody 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 the cost), and also in finding specialist developers who know these dated technologies. Clearly Java never existed. I've been experimenting with Swing lately because Java has a library I'm interested in using. It's a breath of…

> It may not be proper "native" development, but I don't have to deal with hell. It has proper layout management If you want something that's much closer to proper native, have a look at SWT. It's faster than Swing and actually looks/feels native since it's actually using native widgets. It's really a shame that the poster child application, Eclipse, is so bloated and slow, because people attribute that slowness to S…

I agree. I've been developing Swing and SWT applications for 15 years. SWT has a simple, lightweight API that just works. Swing is so bloated an complicated that you will be tearing your hair out to perform simple tasks.

I feel that Sun's choice of Swing was the main reason Java failed on the desktop.