Electron is flash for the desktop (2016)

Post by artursapek » Tue, Apr 11, 2017, 4:13 PM UTC

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…

Post by bitwize » Tue, Apr 11, 2017, 4:15 PM UTC

srssays wrote: post #305

matthewmacleod wrote: post #192

Earlier quoted context omitted.

No, and that's fine. I don't think anyone is going to begrudge a small team the power of developing a 'desktop' application using cross-platform tools like that. It's great that the barrier to developing an application in that way is lowered. But that doesn't excuse the abuse of that platform. Spotify used to have a pretty convincing native Mac app, which was spiked in favour of their current abomination, and I've wa…

Electron is great for user experience. Compare to something like JetBrains' IDEs which are written in Java and are much less native feeling than Atom (and just as resource-hungry).

Post by true_religion » Tue, Apr 11, 2017, 4:15 PM UTC

maxsilver wrote: post #233

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…

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

Post by buremba » Tue, Apr 11, 2017, 4:15 PM UTC

mijoharas wrote: post #70

lazarus101 wrote: post #46

Earlier quoted context omitted.

Development time needed to create desktop apps (for Windows, Mac and Linux) given that there's already an existing webapp: - using Electron: 1 month - using QT: 2 years

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

Post by abdulkareemsn » Tue, Apr 11, 2017, 4:16 PM UTC

_jal wrote: post #252

ballenf wrote: post #235

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…