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…
Your Python example doesn't really support your argument. Python succeeded for data analysis and scientific computing in part because it provided easy access to existing numerical libraries written in C and Fortran. So you got the best of both worlds: ease of use and near-native speed. It would not have succeeded if everything was done in interpreted Python.
Electron is flash for the desktop (2016)
501–510 of 1001 posts
Re: Electron is flash for the desktop (2016)
#502> I just ... don't care about your app enough to justify running more chrome instances Is the author going to uninstall Slack, Atom, Chrome, and Spotify, then? Electron has won out because key apps have opted to use it and decided that the trade-offs of user CPU and battery are worth some amount less than their productivity as developers. Yes, there are alternatives to developing native desktop apps in JavaScript (I'…
> Is the author going to uninstall Slack, Atom, Chrome, and Spotify, then? I read Slack in emacs. I write code in emacs. I browse the web in emacs & Firefox. I play music via my phone's native Google Play Music client, although if I wanted to I could use emms, an emacs music-playing mode. I have no desire to run some GUI-only, CPU-hungry, memory-ravenous, of-the-moment JavaScript nightmare of a program. My productivi…
Food for thought. :)
Re: Electron is flash for the desktop (2016)
#503Earlier 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. 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…
C# has been the default way to write Windows apps since the early 2000s. It is no more "closer to the metal" than JavaScript.
No, it really hasn't. It was just the way Microsoft proposed businesses to write bloated internal enterprise apps, what they used to use VB for.
Those are not the same as desktop apps -- and no, or very very few, desktop apps, ever turned to C#. Not even MS own apps, like Office, and surely nothing like Abobe's or countless others.
>It is no more "closer to the metal" than JavaScript.
Actually it very much is: it is statically typed, it has scalar types and contiguous memory allocation that allow for much better speeds (hence the effort to add some of those things asm.js and the like for Javascript), and it even has AOT compilation.
Besides, it's not JS itself that's the problem (though it took millions and top notch teams to make it fast): it's the web stack on top of it. C# just runs on a thin CLR VM layer -- and the graphics are native.
Re: Electron is flash for the desktop (2016)
#504Earlier quoted context omitted.
Seconded for the Mac app. The current experience is shameful .
The Spotify app is not built on Electron - it's built on CEF and always has been, author was wrong.
Re: Electron is flash for the desktop (2016)
#505> I just ... don't care about your app enough to justify running more chrome instances Is the author going to uninstall Slack, Atom, Chrome, and Spotify, then? Electron has won out because key apps have opted to use it and decided that the trade-offs of user CPU and battery are worth some amount less than their productivity as developers. Yes, there are alternatives to developing native desktop apps in JavaScript (I'…
Jokes on you, I don't use any of those things in the first place! One serious nitpick with you though. "Heavy web pages are heavy because they are multi-megabytes to download...) In my experience, heavy web pages are heavy because of the dozens of scripts being run on the pages, often based on bloated frameworks. Running uBlock and NoScript in advanced, I see it all, and I immediately think less of any site trying to…
Re: Electron is flash for the desktop (2016)
#506Earlier quoted context omitted.
But is that due to technology choices, or due to more attention being paid to UX? (and I do believe webapps give more flexiblity in that regard) I get the feeling that UX and UI designers for web- and mobile apps are just a different breed than their native desktop equivalents. It might just be my Windows bias though, iirc Windows didn't have a strong / great UX guideline until their current one came around - and I h…
That is due to the technologies available on the web being easily more suitable for GUI development than older native tools or desktop frameworks. We're in a similar boat, we made WPF apps. Now we're bringing it to the web and Electron. The things you can do now in React, heck i wouldn't even know where to begin in WPF or QT. If you look at modern Electron apps like Atom, VSCode, Discord and so on, the things they do…
I have a feeling it's more of an experience / competency issue rather than lacking APIs.
Re: Electron is flash for the desktop (2016)
#507Earlier 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…
I think, only a special kind of "developers" is afraid of learning languages. A language is, after all, means to use the frameworks. If you are an experienced developer, moving from a language to a language is a matter of hours to days, depending on paradigm changes. Learning frameworks takes much longer, obviously, but with the wealth of information available out there these days (Stack Overflow, message boards, blo…
I can't speak for others, but for me, the "massive costs" isn't about having to learn another language or framework. It's instead the massive costs to my employer. It might even be a massive cost to me as a single developer.
By developing a cross-platform app using a single set of easy-to-use tools, a large audience of users can be gained, that would otherwise be prohibitively expensive to support if native-only was the mantra. Instead, that application would have to be developed for only one, maybe two of the "major" platforms (and guess which platform it wouldn't be developed for - that would be the platform that I like most).
Supporting and maintaining a single codebase for one platform is a monumental task for any company, let alone a single indie developer. Supporting and maintaining multiple codebases for multiple platforms can be debilitating for a company, let alone a single developer.
I lived and played in those times; back in the "second gen" if you will of the microcomputer days - you had games and apps by different companies, and developers. In most cases, a game or app was only developed for one of those machines (usually the Apple IIe or the C=64, sometimes both - maybe an Atari too), but the other systems were all considered "second tier" by most developers. You might get a port of a game or app - but most times, you had to settle for something else, or buy a second system (ha! only if you had real money! I look back on the costs of those systems back then, and wonder how my parents ever managed it).
There's a reason you see a lot less of that going on today; it isn't because devs are frightened of learning a new language or framework.
Re: Electron is flash for the desktop (2016)
#508Earlier 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…
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.
Re: Electron is flash for the desktop (2016)
#509Earlier 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.…
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
Might just be an accounting difference. Forked process applications in particular are very difficult to account, because even their private/RSS may be COW from another process.
Re: Electron is flash for the desktop (2016)
#510People 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…
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.…
You just ignore what the market is saying because "you are right".
You are completely missing the point.