Live data from Hacker News

Electron is flash for the desktop (2016)

josephg.com

601–610 of 1001 posts

Re: Electron is flash for the desktop (2016)

#601

Earlier quoted context omitted.

Chrome apps would have solved one of the main problems if they were still a thing (does anyone know why chrome deprecated them?). (by reusing the chrome context, your memory usage wouldn't grow unnecessarily for each new slack/spotify/whatever you open).

Yep, I hate that all of these companies try to convert their applications from tabs to dedicated processes. It would be a huge deal breaker if Chrome Apps could become a thing and replace them. Now I have 4 different Chrome apps running on my computer.

Chrome Apps aren't different from tabs, though.

Re: Electron is flash for the desktop (2016)

#602

Earlier quoted context omitted.

I remember a long time ago people discussing that Emacs would never be popular on PCs because nobody had 10MB sitting around just to use a text editor...

Emacs is not just a text editor. It's an operating system.

All it lacks is a good editor :P

Re: Electron is flash for the desktop (2016)

#603
post #196

Electron is just another proof that ease of programming matters. Node.js too was a terrible idea. Who in their right mind would write server-side javascript? It turns out: pretty much anyone who didn't want to have to screw around for hours before being able to respond to a simple http request. Similarly, it is way harder to write a desktop app than a browser app. DOM / CSS manipulation, however bad they are, are yea…

> Who in their right mind would write server-side javascript? It turns out: pretty much anyone who didn't want to have to screw around for hours before being able to respond to a simple http request.

Or, people who like closures. Or other aspects of JS. Or of the Node platform (like event-loop programming).

Re: Electron is flash for the desktop (2016)

#604
post #232

Earlier quoted context omitted.

Have you been trained as an engineer, in a country where "engineer" is a very specific thing and is held to higher expectations, including the possibility of having your title taken away by your peers if you do not respect your duty to, first and foremost, your users and/or society, like every country that takes the title of engineer seriously? If yes, what in earth makes you think writing Electron apps is a good ide…

> Have you been trained as an engineer, in a country where "engineer" is a very specific thing and is held to higher expectations, including the possibility of having your title taken away by your peers if you do not respect your duty to, first and foremost, your users and/or society, like every country that takes the title of engineer seriously? No country trains software engineers in the way you describe.

So they should not call themselves engineers - any more than they call themselves doctors or lawyers. They are programmers or software developers. Or potentially software engineers - but certainly not engineers.

Re: Electron is flash for the desktop (2016)

#605

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…

Layout management: I do wonder sometimes how much awareness the HTML/CSS/JS community has about how layout management is handled in things like Java's Swing or Apple's Auto Layout - or do people think that "desktop style" UI layout management is the "old way of doing things", and obviously HTML/CSS/JS is much more modern and therefore must be better? I don't think it is better, to be honest, and so I also wonder why…

> I also wonder why people aren't crying out for decent layout management for the web

They have been, and that's why today there are things like flexbox[0] and grid layout[1]. It just took a long time for the browser vendors/standards bodies to be convinced and then spec these things out to work within the confines of the existing layout models.

[0]: https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_Flexibl...

[1]: https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_Grid_La...

Re: Electron is flash for the desktop (2016)

#606

Earlier quoted context omitted.

Software dev is about tradeoffs, and the argument against Electron is that the tradeoff in resource usage is bananas for nebulous claims about "it looks better" and "I wrote my app faster". Every time this comes up on HN, someone says, "wow, Electron is Dracula to batteries, and all I'm doing is sending text to people/playing an MP3/blinking a cursor". Managing tradeoffs is a fundamental part of development strategy.…

This is the problem here. Your post illustrate it perfectly. You just ignore what the market is saying because "you are right". You are completely missing the point.

It's ridiculous to think that the choice of GUI framework would have a measurable impact at a market level. There's no strong correlation between using a fad technology and market success, so it's incorrect to use one as a proxy for the other.

Re: Electron is flash for the desktop (2016)

#607

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 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". A higher barrier to entry has that effect. Low quality crap doesn't get in as easily. > Nobody in the last 5-10 years cared about writing Desktop apps before Electron came along, there's basically zero money in…

Making desktop apps might be a nice lifestyle business for niche segments, but there aren't many (any?) big businesses built on desktop apps any more. Microsoft and Adobe are doing well on the desktop, churning out new versions of apps they've been building for nearly 30 years, but I can't think of any company built in the last 10 years (at least) that came up that way.

In the meantime, here's one of those "web-based unicorns" you so despise: https://www.google.com/finance?q=amazon&ei=viTtWMGfNMWQ2Aa42...

Re: Electron is flash for the desktop (2016)

#608

Earlier quoted context omitted.

It's moot if you're an established company with deep pockets moving slowly. If you're starting from scratch with limited funds, it is definitely not a moot point. Would Slack have been as wildly successful if they had to implement native apps on all 3 platforms + iOS + Android + etc? I'd have a hard time believing so.

You don't have to rebuild your app for all platforms. Desktop widget toolkits (Qt, GTK+, wxWidgets, ...) have bindings out to most languages. If you can run Python, you can run a desktop app on all platforms from a single codebase. Also, all major platforms have C and C++ runtimes; if you write portable C or C++, your codebase should run on any of the big three. It's ridiculous to pretend that you have to write 3 dis…

If you target the native OS widget set, you must have a separate code base for each platform's native widgets. Things like Swing and Qt don't cut it.

Macintosh users in particular are sensitive to things like the placement of and spacing between UI elements; if anything is "off" from the gold standard set forth by Apple, they will scream and bitch at you because perfect UI consistency is paramount with this crowd.

Web-based apps get something of a pass because they look and feel like Web-based apps (though not always; witness the grousing in this thread about the new Mac Spotify client). But things like Qt and the XUL-based Firefox, which try to look native but miss subtle details, fall into a sort of UI uncanny valley and are roundly rejected by the Mac community.

Re: Electron is flash for the desktop (2016)

#609

Typical hackernews a-hole...ignore it.

We detached this comment from https://news.ycombinator.com/item?id=14088559 and marked it off-topic. Please comment civilly and substantively or not at all.

https://news.ycombinator.com/newswelcome.html

https://news.ycombinator.com/newsguidelines.html

Re: Electron is flash for the desktop (2016)

#610
post #252

Earlier quoted context omitted.

> ... Electron applications are shite in comparison with proper native applications. Is that true from a user's perspective? The average user I know would not have the idea that Slack is somehow inherently worse than say MS Word or any other truly native app they use everyday. What would Slack gain by integrating better with my Mac? Slack starts up too fast for me to read the little quotation (penultimate Macbook Pro…

> Is that true from a user's perspective? It is for this user. > What would Slack gain by integrating better with my Mac? Far better resource management, one would hope, for starters. As the article pointed out, when you're measuring your IRC client's memory use in hundreds of megs, there's a problem. It isn't uncommon for me to need to choose which "essential" apps to turn off to get something done on a maxed-out MB…

> when you're measuring your IRC client's memory use in hundreds of megs, there's a problem.

Not really, unless you're using most of your RAM or you treat this as a fundamental principle. I've never checked my Slack RAM usage, and I'm sure it's higher than if they built a great native app, but it's also never had any performance problem with Slack or any other application (okay, except for Eclipse, but I stopped using that when Android Studio came out).

> It isn't uncommon for me to need to choose which "essential" apps to turn off to get something done on a maxed-out MBP

And there's the key. You have a very specific use case that is probably extremely rare. I'm a full-time developer and as far as I know I've never been low on RAM on my first generation Retina MBP.

Post reply on HN