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 the cost), and also in finding specialist developers who know these dated technologies. And as for Qt, Qt has existed for over two decades - if its massive "Beatles walking off the plane" moment hasn't happened by then, sorry, it's not gonna.
But now? People are making all kinds of great new apps, and more often than not, they come out on all three platforms. People are excited about the Desktop again - Electron is so good it's single-handedly revitalizing the platform that
two of the largest tech companies in the world are behind, yet couldn't do.
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 this approach.
The trade-off — and there is a trade-off — is that 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. It's fine to make those trade-offs – in some ways, it's better that you can get an application at all than the alternative of 'no support for your platform'. But let's be honest here – there is nothing preventing e.g. Spotify or Slack from building native clients for each platform they support, and I find it difficult to believe that the costs would be prohibitive.
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 circumstances for those costs not to be internalized in a different form. (These special circumstances might include information asymmetries, harm to a public good, enjoyed by people other than a firm's own customers, etc.--themselves classic risk factors for market failure.)
By the same token, there probably are some truly externalized costs in this example, but I would expect them to be very minor and indirect. For example, most people probably do not pay the 'true' cost of their electricity. So to the extent electron wastes power, some of the cost will be internalized in the form of user dissatisfaction. But some will also be externalized either because the user doesn't know about the extra power consumption, or because the user herself doesn't fully internalize the costs of her power consumption and therefore doesn't care as much as she might if all costs were properly internalized.
> 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.
Precisely. I don't use Slack in part because its desktop application is irrationally bloated for its use-case. Although I have other reasons as well, they are enduring a cost--a small one to be sure, but presumably non-trivial in aggregate--in people refusing to use their service in part because their desktop application is poor.
But I do agree with the general emotion underlying the frustration of "externalities" here. As someone who advocates for high-performance and efficient web applications, I have toyed with the question of whether developers should confront the morality of wasting energy by having selected poor/low-performance platforms. Put in a somewhat comedic tone: low-performance software contributes to climate change.
The problem is that despite how good it feels, individuals simply optimizing their individual activity does not scale to the societal scope. Post-agrarian humans literally behave and think via shared infrastructure. The only way individuals can make lasting improvements to society is to improve the infrastructure.
Does it? Or maybe those individual pop up and do their progressive thing only when existing infrastructure and technological landscape lets them do that?
Why they haven't made Slack a web based chat app like Discord or Wire or even Skype is beyond me. I don't even use their native apps, just open a tab in my browser and run the corresponding web app.
"Along with the features available in your browser, the app loads your conversations more quickly, gives you more control over notifications, and has better support for multiple teams."[1]
Also, the app gets its own entry in the task switcher.
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.
> It's been a LOOOOOONG time since I worked on a laptop where I experienced noticeable performance problems...
Really???
Because personally, I keep having performance problems on all laptops I have. Don't try running on battery saving mode, seriously.
I stop counting the 5+ years old laptops that have to be upgraded, they can't watch a youtube full HD video in good conditions.
----
Fun Anecdote: I had to trial an entreprisey SaaS solution not long ago. A coworker gave me the name and I opened the site on my laptop (on the move outside of work, just taking a quick look).
Their site froze my firefox for 30 seconds because these idiots put a high quality full screen video of a surfer in the background of the main page. Looks cool, doesn't it? https://www.wavefront.com/
Couldn't see the site. Had to be at work to read it, on my top end workstation, the video played smoothly there. Needless to say, didn't take the product seriously.
> I stop counting the 5+ years old laptops that have to be upgraded,
5+ years ago is that LOOOOOONG time that OP was talking about. It's also unfair to compare technical capabilities of old hardware for many reasons. I think the point was that, new hardware, _while its new_, is becoming more and more capable. Any new laptop today, even budget ones, can handle YouTube videos in HD. The problem is that HD today won't be the same HD that exists in 5 years (i.e., 4k), and it's sensible that a budget laptop today will struggle with the 8k technology that comes out 5 years from now. This is an old problem (pun intended) and should not be surprising.
> Because personally, I keep having performance problems on all laptops I have.
Selection bias. Programmers who compile code, run VMs or containers, and process tons of data, are not the average consumer laptop use case and have much stricter requirements. Many people are sitting in Facebook, YouTube, Gmail, or Google Docs for most of their day-- and likely inside of Chrome.
Where are the "Chrome is Flash for the desktop" posts?
The idea that Electron is any different of a user experience for the vast majority of users seems skewed to developer usage, to me.
I don't know, 5+ years isn't that old anymore for a computer. Like, 5 years ago I was running... a core i7 with 4GB of ram. And now I'm running... a core i7 with 16GB of ram. The only things in computers that have really gotten significantly faster are SSDs and GPUs
It takes a surprising amount of power to decode. The cheap CPU from netbooks have been struggling for a decade, especially in battery power saving mode.
Lately, they get hardware acceleration just for that. Special CPU instructions and drivers just to achieve that decently.
For Youtube in particular, they're sending VP9+opus where the browser supports it, without considering hardware acceleration. The rather anaemic Atom chips might have H264 decoding on-chip, but only Kabylake has VP9.
Different people have vastly different use cases. I haven't experienced a performance issue with desktop Slack or any other (non-game) application for many years. Sure, if I look at how much RAM Slack is using I'd probably conclude that it's more than it needs to be, but I haven't had an issue with RAM usage for, gee, probably ten years.
As for battery, again, my laptop battery has been little more than a UPS for at least five years.
It's mostly CPU performances I experience. Rendering any video, gif, website takes sizeable CPU power (for a cheap CPU in power saving mode).
Never had issue with RAM. I can remember a few friends who bought netbooks with 2GB memory some years ago, they quickly realized that they simply cannot run their development environment in that. (I'm talking swap death where a click that should take 1 second to act takes 1 entire minute).
Right now I'm using a backup laptop with Intel Celeron. It runs most apps fine. Web sites like Hacker News come up easily and snappily. The CPU fan kicks in when I watch a high-quality movie. It also kicks in on small, web apps. Kicks in big time on Youtube and Facebook. Everything on those is sluggish compared to my native apps. Even if non-technical, I'd know stuff was about to slow down when I go into my browser.
Just bad tools leading to waste users notice. Best to avoid them if possible. Not always possible...
> I stop counting the 5+ years old laptops that have to be upgraded, they can't watch a youtube full HD video in good conditions.
Are they all netbooks? Because those were crap the day they came out and even more crap 5 years later. You can find terrible discount desktop machines that can't handle anything just as easy as you can find terrible laptops.
My laptop is 5 years old and the only time I feel a lack of performance is when the Swift compiler fires up. Your example link came up right away (OK it burns away 30% of a core, but I got 4 of those).
They are not crap by any standard, they are simply low spec.
A core i3/i5 starts at 150$, most devices don't have these expensive CPU.
Even a 1000$ macbook from 5 years ago would have one of the first i3/i5. It would struggle to read 1080p video, unless plugged to a wall plug with the span spinning seriously.
> It's been a LOOOOOONG time since I worked on a laptop where I experienced noticeable performance problems.
This annoys me a lot, for one of two reasons. Either:
1. Some developers have no idea what performance means -- it's crazy that I have time to notice a spinner when a glorified IRC client starts up or switches tabs, let alone have time to watch it for tens of seconds.
or:
2. If these developers are claiming they have no performance problems, clearly the laptops that can handle modern applications are being hoarded, and I have no way to obtain one of these magical machines. All I can get are recent i7 processors.
On point 1: Also there's still the effect where your app does the same thing a native app would do in an equally reasonable time but uses twice as much power to do it.
>It's especially true with a chat system where the most important feature is that everybody on the team can get access.
That's a complete other story... All that big open source movement for decades and in 2017 we are still depending on proprietary systems to provide a chat(!) for a company.
Yep, and when the government doesn't properly tax those harm-to-public-good things like air pollution to balance the incentives and make it cheaper to do "the right thing" and pollute less, companies (which are made of real people and are not just unthinking machines) will do whatever they can to maximize profits. This is why it's so important to e.g. Increase the price of water to reflect the true cost in the Central Valley of CA instead of letting tons of farmers grow water-intensive crops in open-air, wasting tons of water just because it's cheap (then they complain about "is GROWING FOOD a waste of water?!?", completely un-ironically). Many businesses subsidize their operations using government funding, yet again ironically most of the rich white men running them are staunch opponents of public assistance programs despite owing most of their wealth to similar mechanisms, typically in conjunction with massive tax avoidance.
Pretty funny that the only reply here is 'found the Marxist' (maybe it was supposed to be a joke?) when, in reality, all you're suggesting is that the government set the conditions for the proper functioning of the market, which is an idea straight our of Hayek.
I don't understand. The cost is mostly externalized into, quite literally, massively distributed increased electricity consumption. That an individual's power bill may be subsidized only emphasizes that problem.
It sounds like we agree. To the extent we're just talking about electricity costs, then it's true that easily written, but inefficient code may indeed externalize these costs to the extent that users are unaware of the added power consumption, or that the user herself does not pay the full cost of that electricity.
But these electricity costs struck me as only a small part of the broader point I was responding to, which is what I framed the point the way I did.
I contend that squandering the work and infrastructure involved in converting natural resources into electricity is the main problem with modern consumer software development. Any user's (lack of) perception of waste is irrelevant. The scope of the problem is not any individual literally paying a couple dollars more on their electric bill, but rather it's that gigawatt hours are literally being burned away because software developers who know their code will be running on machines the world over can't be assed to spend a little more time learning to practice their craft correctly.
There is no broader point than converting natural resources into societal infrastructure. Be a responsible member of society. Don't obstinately ship wasteful code. I understand if you legitimately don't know any better, but if you're part of the community that's constantly writing blog posts about computers being so fast that its OK to burn the end users' CPU and storage just so you don't have to spend a couple more minutes thinking about what you're doing, you're adding harm to the world.
Again. I think we agree. You're just making a different point than the one I was making. I was making a technical but hopefully still constructive point about what is an externality and what is not.
You seem more focused on making a case against shipping inefficient code. And you're point is a good one. It's just a little difficult to suss that out since you're framing it as standing in opposition to my related, but very different, observation about externalities.
The vast majority of users (like >99%) don't have a clue why their computer isn't performing up to par. They literally have no idea how any of it works. They might just assume that it's slow because they haven't deleted spam emails in a while (even while they use gmail) or didn't pay extra to get that 3.2Ghz machine instead of the 3Ghz. They certainly don't have any idea how to open up top stats and check what resources a particular app is using, so until that happens and users punish developers for this kind of stuff, expect it to continue.
> The vast majority of users (like >99%) don't have a clue why their computer isn't performing up to par. They literally have no idea how any of it works.
Yes, you'll often hear things like "I think I have a virus" or "I think I need a new computer". They're computer is fine, they're just running slow apps.
I don't disagree, but I'm hopeful that Electron will get better. When you choose an open source platform with a diverse group of major companies using it, part of what you are betting on is that the platform will a) survive for a reasonable amount of time and b) gradually improve.
GitHub, Slack, Spotify, Microsoft, etc., are all using Electron. As their developers gain experience with the platform and as they experience problems with resource usage, I would expect to see the platform improve. Maybe I'm wrong.
I agree. I think it also has the potential to help motivate developers to write native UI rather than use electron.
Currently if for your market, your primary target platform is the web, but other platforms are still important, going electron might make sense because you really don't want to write your business logic natively for each platform.
Web assembly allows us to use the same native libraries for all our business logic and data models, which besides being more performant, means we only need to be willing to write the UI natively on top of those libraries. We've actually taken (very) old desktop C++ code, and compiled it to asm.js and ran it in our web app, and then rendered its outputs with webGL onto a canvas and have had surprisingly successful results. This makes the prospect of WASM becoming standard across the board very exciting.
Now let's hope we don't decide to replace our native desktop app, that uses this old C++ library, with an electron app of our web app, running the asm.js compiled library :).
I've switched from Sublime Text 3 (native) to VSCode (Electron) and I couldn't be happier. If I didn't know it's electron based I wouldn't have been able to tell as a user. YMMV so don't generalise.
If your battery is more important, just stick to Emacs.
What machine are you using ? I have a 2 year old thinkpad, it's still 10h+ in full brightness, vscode, compiling, etc. And it's the screen brightness that consumes the most battery.
It used to do 20h, but the main battery is external and can be replaced so it's a good thing. I would really recommand thinkpads to everyone instead of going for macbooks for example.
VSCode doesn't compete with emacs and vim. VSCode competes with Sublime Text and Atom. Maybe even with WebStorm on the more full-featured end and Notepad++ on the leaner end.
I'm not even sure whether you're trolling. BBEdit provides a tiny subset of the features VSCode offers. VSCode is not a text editor, it's halfway between a text editor and a traditional IDE.
Atom and VSCode are in different leagues with respect to performance, and the difference is growing with time. If you think the reason that Atom is slow is because of Electron, VSCode is the counterexample.
Since both are written with electron the difference must obviously be the actual implementation, not the platform itself.
Keep in mind VSCode was written by Microsoft who have decades of experience writing IDEs and text editors, whereas Atom was written by GitHub who are mostly working on the GitHub product.
VScode runs like a dream on my hexacore/8GB/SSD desktop, but brings my atom/2GB/32GBeMMC based Asus Eeebook X205TA to its knees. Native programs for low power systems seems sound practice to me.
How about PWA, Service Workers, WebAssembly? Thousands of developers are working hard on improving the UX, reduce battery usage, wasted CPU cycles, network traffic, latency.
it's been that way since forever. if you're not employing expensive top-ranked brilliant engineers writing aggressively optimized, completely bespoke c applications tuned to every cpu model's feature set and performance characteristics... you just might be externalizing.
insofar as it benefits the budget, you should probably externalize as much as possible. consumers will provide the fitness function through deciding what products they prefer.
We're not even discussing aggressively optimized C vs web stack. We're talking about a massive segment of today's software developers not even bothering to learn competent C (or Obj-C, Swift, Java, whatever) to build a native application. Hell, it's about the very practice of calling Electron apps native to begin with. The same thing continues to hold across web stack everywhere—reach only for those things that don't require you to learn a new language/paradigm, letting you keep churning out the same thing you build in a browser and call it native for platform X, and let it be on the user to pony up the resources to use it.
C is generally faster, than hand-written assembly, so it doesn't make sense to write software in assembler.
For macOS desktop applications are written with Objective C, which is C with fast message-passing, and doesn't trade much to speed. Swift is modern alternative, but it doesn't trade anything for speed either.
For Linux applications are traditionally written with C and Gtk or with C++ and Qt. Those options are both very performant.
For Windows main language for a long time was C++ and it remains supported language. There's movement to .NET, so Windows is an outlier here. But .NET is generally very performant language, it makes some tradeoffs for safety, but it has enough features to stay fast and its implementation is specifically tuned for desktop applications.
The only terrible platform with slow language is Android and it's well known for its lags.
There's very little desktop software written with Java and Python and usually those are specialized applications, when users don't really care about experience, but rather care about functionality.
So JavaScript invasion here is unexpected and not wanted. I won't use any JavaScript desktop application, if I have choice. I don't like this technology. JavaScript and V8 made for browser with advanced sandbox capabilities. That's fine. But for desktop it's just not needed. And there's no other advantages. UI is terrible and does not conform to any standards. Performance is not good. Memory consumption is abysmal. Energy consumption is abysmal as well.
If I'm about to buy application for macOS, I'm always carefully inspecting its bundle and trying to determine which technologies were used. Unless it's pure Objective C/Swift, I'm usually won't buy it. I hope, more users would do it.
Yeah, but Python still doesn't seem to have a great cross-platform desktop GUI, as far as I can find. I'd prefer to code entirely in Python if I could, but I haven't liked a single GUI library I've tried for Python.
Although to be fair I haven't really tried PyQT out still, but I don't like the idea of having to buy a commercial license for it.
But none of them are close enough to the benefit of being able to use the tone of experience from the Web UI into the desktop.
Eventually all GUI app toolkit ends up with a custom MVC framework, a client/server architecture, some kind of db for persistence, their own implementation of asynchronous event and communication models and a declarative layer to create the UI without code. For the most advanced this layer separate structure and layout.
Well guess what, this is what the Web has natively being doing for ever.
Since the web is now the most popular platform, with millions of libs and tutorials on it, people just reused that. It just makes sense.
The problem is not the concept. The problem is we should have driven this effort with a standard to sanely close the gap between the desktop and the web so that you don't have to spawn a freaking browser-engine-os for every one of your app.
But no, the web is the only platform with a standard. And it flourished while all the big players created closes gardens with proprietary shitty API. And this is the result.
Have you not seen Jurassic Park for god sake ? Life finds a way.
It's completely false.
The web at the beginning was a huge mess of static pages, hacked CGI scripts and no interactivity at all with the need to submit a form to trigger a full reload of the page.
Everything was absolutely synchronous and a lot of times the database was accessible directly from the public interface and some pages did actually have the connection string directly in the HTML for everyone to see.
I'm really not sure in which alternate reality you have seen web apps doing all that forever.
Yep, completely agree with everything you said. I'd love for their to be a standard on the desktop side, but until then, I'll keep using a hodge-podge of technologies depending on the project, I guess.
They should have adopted Qt; it makes it easy to write native C++ code that compiles on different platforms, so you get the performance and RAM usage of C++ but still most of the benefits that web coding offers, without so many drawbacks. (It's also quite nice to work with IMO.)
It's too bad it wasn't more universally adopted, by any of the 3 major platforms (including Linux, where the all-C Gtk+ has become the standard for the most part). Instead, it seems to have found its greatest success in, ironically, small embedded devices. Devices like this simply cannot take the performance hit of something like Electron.
Last time that I tried QT was a huge pain compared to WPF or other solutions, admittedly something like 5-6 years ago.
And it was proprietary and it needed a licence.
With all my good will I find quite difficult to believe that now PyQT is the silver bullet to write all UIs.
For sure it's not for me given that I find python a pretty average language with the huge handicap of duck typing (and before someone starts, yes, I'm aware of the 'type annotations')
> Last time that I tried QT was a huge pain compared to WPF or other solutions, admittedly something like 5-6 years ago.
Shrug, I found it much nicer than anything else I'd used, but I've never used WPF (which is single-platform in any case).
> And it was proprietary and it needed a licence.
Neither Qt nor PyQt is proprietary in the usal sense of the word (nor were they 5-6 years ago). If you're using a non-standard definition it would probably be more productive to use a different word.
> For sure it's not for me given that I find python a pretty average language with the huge handicap of duck typing (and before someone starts, yes, I'm aware of the 'type annotations')
I'm a huge fan of type systems. I wish I could find a UI framework that's anywhere near as nice as PyQt for an ML-family language.
I can't help but think there's a different flavor to this than with higher-level languages. This is adding a platform on top of another platform. The same objections existed years ago with Java when Swing was released. Java is a cross-platform high-level language but Swing is basically an entirely new platform.
It's this platform on top of a platform that is objectionable from a performance, memory, storage, and integration perspective.
We see the same thing with containers. Docker, flatpak, snap... It's just the right time for it.
Languages have evolve to change the way we handle constraints like memory, speed, readability, expressivity etc.
We are arriving at the pick of what languages can bring on the table. Sure we can improve things here and there, but the huge challenges now are integration, packaging, distribution, updates, communications, multi-tiers architectures and all that.
So we now tweak platforms to help us with that.
But because we didn't see that coming, it's not done in any structured way. It's done exactly the way we did everything since the beginning of computing, by stitching together stuff then hitting hard on it with a hammer until the job is done.
This is not new. IT is a joke of an engineering field. We hack everything, don't think about the future, and then end up using the status quote. It's always has been like that.
I agree. Containers should be unnecessary -- all that they could provide could be done at the process level with an operating system designed to isolate computing resources appropriately. But operating systems were not historically designed for that so another (somewhat ridiculous) layer is added on top.
actually all containers do is utilise the very design in an OS like LXC in Linux to form containers. Containers are not a platform on top of Linux, they are a wrapper around different isolation tools build into the kernel.
IT is a joke of engineering for non engineers.
If a pull request doesn't follow some principles agreed a priori it doesn't get merged.
If there are people that like to play the "IT cowboys" just hacking together stuff without any whatsoever process or unit test that certifies the behaviour of what they have written, jeopardising the entire team efforts, it is not a failure of software engineering, it's a failure of that specific team.
And please bear in mind that I worked in such toxic environments, but I never thought for a moment that software engineering and software architecture are jokes.
The joke was the team/organisation on which I was at the time.
>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), so the whole premise is moot.
The few Java desktop apps that were around, people used to hate as memory hogs.
But can you make a website with the same knowledge ? Can you make it portable to other OS ? Can you reuse 20 years of knowledge, resources and libs ? Can you hire tomorrow 10 experts to help you on it ?
Quality of the tech is NOT the drive for success here. You are missing the point.
People used crashy, buggy, slow software for years. Photoshop and Office lost you data on a regular basis in the 2000's. Windows BSD was a common occurrence then. We didn't see a massive exodus to Mac products because of that. The only reason people started to go crazy for Apple was after the iPod came out. And even then, it was still a small part of the market.
You can see everyday that people favor cheapness, easiness and convenience over quality. You would not have so much junk food otherwise.
> But can you make a website with the same knowledge ?
One of my first commercial projects was a web-content management system written in Objective-C. Customers included Siemens and the German Bundestag.
Another couple of projects were written in WebObjects. If I wanted to, I could use Cappuccino, but I am not a big fan of web//client apps, so I don't.
> Can you make it portable to other OS ?
This product ran on: Solaris, AIX, NeXTStep, Linux, OS X. I think we also had a Windows port.
> Can you reuse 20 years of knowledge, resources and libs ?
In the sense you meant it: yes. Except it's more like 30 years. However, programming skills are (or should be) transportable. With virtually no previous experience, I became lead/architect on a Java project, which succeeded beyond anyone's imagination.
> Can you hire tomorrow 10 experts to help you on it ?
>One of my first commercial projects was a web-content management system written in Objective-C
You certainly didn't use any of your cocoa widget for the UI there. It was HTML + CSS.
> This product ran on: Solaris, AIX, NeXTStep, Linux, OS X. I think we also had a Windows port.
Yeah, GNU steps for GUI on windows... This is what you think could be an argument for electron users ?
> In the sense you meant it: yes. Except it's more like 30 years.
Again bad faith. The world has way, way more code, snippets, tutorials and doc about any HTML + CSS + JS code than any tech based on Objective-C.
Programming knowledge is transferrable, but the knowledge of the ecosystem is not, and is always the most consumming.
> Is this a serious question?
Oh yes, it is. Because you see we are living an era where it's hard to find any good programmer at all for anything. They are all taken, and are very expensive.
So basically, on a tech limited to one ecosystem, finding them will be even harder, and even more expensive.
The simple fact that you are pretending it's no big deal (while any company will tell you otherwise, so much that the GAFAs are spending millions just in their recruitment process) illustrate how much a troll you are.
It most certainly is not. You just don't know what you're talking about and keep making up new stuff when confronted with actual facts that contradict your fervently held beliefs.
I'm curious how you get Smalltalk like productivity on objective C? I thought the productivity on Smalltalk comes from its live programming environment?
You bet ? I have 3 software opened right now using Python for their GUI: my rss reader, my torrent downloader and dropbox. And I got many more installed on my machine.
But the thing is, even when I write something for myself, I first write a command line app, then a web service. Never a GUI, because it's such pain.
Of course. Electron is just a layer around the chrome compiled engined as well. If you want anything to display a matrix of pixels changing rapidly, you need low level performances eventually.
Of course, but in your case, the C/C++ libraries you're calling into aren't doing any heavy lifting, they're just making calls to an X server (or equivalent) or perhaps to a graphics card. There's no reason GTK (or the GUI portion of Qt) couldn't be implemented in Python, it's just a huge undertaking and it was started in C (or C++ as the case may be).
>And in fact C/C++ can be as fast, or even faster than hand-rolled assembly most of the time (with few exception)
This is generally true, but to be fair the reason is because we design CPUs differently these days. Modern CPUs use instruction sets that are specifically designed to work well with compilers, and aren't meant to be programmed in hand-coded assembly except for a few critical bits deep within OS code. Older CPUs weren't like this.
It still might be possible to write hand-rolled assembly that beats modern compilers, but you probably need to have seriously super-human mental abilities to do it.
> the reason is because we design CPUs differently these days. Modern CPUs use instruction sets that are specifically designed to work well with compilers
You got the causality wrong. Assembly programmer-friendly CPUs died because CPUs which weren't as friendly were faster and cheaper; those same CPUs were instead more amenable as compiler targets.
Hey, I used to use it! :P I came from BASIC background. VB6 was supposedly good for rapid prototyping of GUI apps (esp CRUD variety). I found it would boot up in 1 second, deploy new project in 1 second, and load new app in 1 second. It was also safer so no constant blue screens over common functionality. It also could wrap foreign code in less safe languages which I could still write in an industrial BASIC. One could also export the GUI to code in different language.
Became one of my favorite toys. I'd still use it for GUI prototyping if it was FOSS and kept getting extended. I found even lay people could learn it well enough to get stuff done. Long after, I learned what horrible things lay people did with it. Yet, they got work done and got paid without the IT budget and staff they would've preferred. (shrugs)
>C# has been the default way to write Windows apps since the early 2000s.
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.
I mean, if you're going to say Windows Forms and WPF apps are not "desktop apps" then you're going to have to do a lot more than just declare that they aren't.
> 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.
You're just listing ways that they are different. They both run in a virtual machine that abstracts away the actual machine. You know, the metal in the phrase "close to the metal."
>I mean, if you're going to say Windows Forms and WPF apps are not "desktop apps" then you're going to have to do a lot more than just declare that they aren't.
Windows Forms is a wrapper on top of MS Win32 API. And WPF is also based on native widgets wrapped (with some extended with managed code).
In any case, C# apps are not much represented in the majority of Windows desktop apps, most of which are written in C++ or similar, and surely all the succesful ones. Can you name your succesful C# desktop apps? (not in-house enterprise apps and no developer tools please. There where the users have no choice, even Java does well) I'll name the succesful C++/Delphi/native/etc ones and we can compare our lists.
>You're just listing ways that they are different. They both run in a virtual machine that abstracts away the actual machine. You know, the metal in the phrase "close to the metal."
A call to a native drawing lib that doesn't pass through 10 layers of abstractions and bizarro architectures is as good as a direct native call. Especially from something like C# that runs circles around JS performance.
But even so, few consider JS to be what makes e.g. Electron slow.
As far as I know there are plenty of XNA games running on both pc and Xbox in C#.
And that is pretty much the worst applications you can use c# for because, you know, latency.
I don't see any real blocker to have complex c# apps on the desktop, apart maybe the quite shitty clickonce and the continuous need to have an upgraded .net framework to use the new features.
But now for UWP apps the default is c#, they can be installed directly from the store, and with Roslyn you basically need only to target .net 4.5 to have all the features of the last version of the language.
And this is a huge win that admittedly JavaScript already had because of transpiling.
If I had to write a commercially distributed desktop application nowadays I would use for sure c# or f#, not JavaScript.
> Yeah, but until Electron and they like, we seldom shipped desktop apps in anything than C, C++, Delphi etc even after all those decades.
So things aren't any different than before. We've just replaced non C/C++ abstractions that were written by the platform-owner company to non C/C++ abstractions that are written by open source projects.
This seems pretty much in line with the general industry trend towards the adoption of open-source software.
>So things aren't any different than before. We've just replaced non C/C++ abstractions that were written by the platform-owner company to non C/C++ abstractions that are written by open source projects.
By "large", you mean some of the UI using WPF, the plugin system supporting C# and some of NuGet?. Not that those are small projects, but considering what is inside Visual Studio, they are hardly "large portions" of Visual Studio.
And because the IDE support (refactoring etc etc), compile time error checking and ease of use more than compensates for Java being a little bit verbose.
Yeah, and they used C because the compilator could optimized stuff the JVM couldn't but now it can. And now Python get type hints so you can have the IDE tools you have with Java like with PyCharm. It's the circle of life.
Not quite correct about type hint. They are only in python 3.
Everyone who adopted python 2 on sizeable codebase is likely stuck there forever, with zero annotations and none of the new tools available, and they'll never be ported back.
But let's be fair, type related tooling in Python are not close to the ones you have in Java yet. It's just that eventually, everything comes around. Java got faster. C++ easier. Python ...toolier ? Etc.
Python broke all retro compatibility and put all existing sizeable software in a miserable deprecated state with the breaking of python 3.
I don't recall C++ getting easier. The few tools and IDE still fail at decent refactoring and code completion. The C++11 movement is adding few stuff more or less useful, piling on top of the vast amount of already existing complexity.
C++11 makes a LOT of things much, much easier. Yes, it does pile on top of existing complexity because they're loathe to eliminate any backwards compatibility, but the nice thing is that you don't have to use older features or methods of doing things. In fact, if you look multiple serious C++ codebases, it'll almost look like they're different languages, as every project basically chooses a subset of C++ they accept. Realtime embedded code doesn't look anything like desktop application code, for instance, but they're both technically C++.
And as far as I remember even google is only supporting python 2.
Their python-go transpiler doesn't support python 3 for example (unless something changed in the last months and I missed it)
And because packaging everything in a jar is easier than pulling 1e3 dependencies for every deployment. Not to mention drpendencies that also require a C/C++ compiler boost or other native libraries.
Yeah and some use C because Java is too slow. The point is, there is nothing new here, the history of computing is repeating itself. It's just now we have better toys, a bigger market and the stakes are higher.
Rust doesn't bring much in that aspect. You could use C++ for performant high level abstraction for many years before Rust. Rust brings memory safety and that's huge. But it's not anything like Java, it's much harder.
Actually, I think it's very similar to Java in terms of what is being offered and at what layer of thought.
It does have a steep learning curve, but it's worth it. The number of concurrency bugs alone that I could have avoided if I had been able to use Rust years ago are sad to think about. Java has great concurrency tools, but doesn't do anything to make sure that your not shooting yourself in the foot.
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.
Do you need to run N programs on N copies of Chrome with JavaFX or use a single VM like all JVM apps do? Because that's the problem with Electron mentioned in the article and that's exactly one place where JVM languages are better.
This is basically a terrible argument in and of itself you would do better to flesh out why yourself instead of expecting everyone to conclude your self evident correctness.
> code written in Java, Scala, Groovy, Clojure, Kotlin, Ceylon, Frege, etc
Your list of 7 JVM languages (both here and in your earlier comment on this submission) seems to be from most widely used to least. Yet in your HN comment from 2 days ago at https://news.ycombinator.com/item?id=14068664 you ordered that list differently, i.e. "Java, Scala, Clojure, Groovy, Kotlin, Ceylon, Frege, etc". Have you changed your mind about the relative adoption of Clojure and Apache Groovy in the last two days?
Not really. Actually, however, there is a recent survey that shows that Groovy is the second most popular language on the JVM, behind Java. Myself, I use Scala, and would like to learn Frege.
Groovy is a quite lovely dynamic language and it's actually the best solution for BDD using Spock.
Sadly I still didn't find anything comparable for BDD in all the languages that I use.
> Groovy is a quite lovely dynamic language and it's actually the best solution for BDD using Spock
There's something wrong when a testing framework hacks into a language parser to make the language statement labels have special meanings like function names do, and overload the `|` operator in expressions so data will appear as a table in the source code. "Lovely" isn't the word for that sort of thing.
>There are costs to developing desktop applications and developers don't want to pay them, so they make users pay for them
That is definitely not the whole story. Costs are shared between developers and users. If it's more expensive to develop an app, you can bet it's going to cost users more too.
Because those costs grow orders of magnitude as they're externalized. $1000 spent during development can offset $1M in energy wasted by a million users. So they should want to pay those costs as responsible members of civilized society.
And if they don't want to, they should be forced to by said society.
To make a quality product and offer a better user experience?
Users may not notice the slowness right away, but if they run a bunch of applications at once they probably will, and they're more likely to notice it while running on battery.
> ... 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). I actually wish it was slightly slower because I like those cheesy quotes when I can catch them. Everything feels almost instant. Not bash instant, but as fast as any mainstream messaging app.
I leave it running all the time and get what feels like normal full hours upon hours of battery life. There are apps or browser tabs that I've noticed destroying battery life, but Slack nor Atom nor MS Visual code are on that list for me.
The anti-Electron complaints all kind of feel like the same argument that comes up as each new layer of abstraction gains acceptance. I'm sure there's a lot that Electron can and should improve. Running multiple copies of Chrome does sound awful, but until I read that I didn't know the atrocities it was committing.
Just doesn't feel productive to try to make Electron go away vs. working to improve it or create a better cross-platform abstraction.
> 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 MBP. So Slack gets turned off, and maybe someone gets annoyed that I don't respond to something, while I run a few VMs in Slack's former memory space.
As far as other things, well, using a platform's capabilities as appropriate is generally considered good form - HCI concerns, and, generally, just people like things to be consistent. I don't know why we're supposed to forget this now.
I personally don't care if Electron goes away or what, but to the extent that I'm forced to run Slack by my cow-orkers' choices, it sure would be nice if it were less of a bucket of ass.
Recently I was doing some mean stack development ram was maxing out 8 GB and system was struggling to run smoothly
Mongo alone was hogging around 1.5 GB and webpack was hogging 1 GB there are three seperate expressjs servers hogging 500 mb each
Finally an argument that is concrete and understandable! Seriously, this is the first comment I've read that is tangible as opposed to theoretical. All the other complaints are on the basis of being morally offended by the ratio of resource usage vs. application functionality.
The nice thing about slack is that it will run about anywhere. The app on my phone magically knows if the app is not running on my laptop and will then and only then send me notifications. But, I'm not suggesting this as a solution for you -- best productivity killer I know is having to pay attention to yet another device while trying to get work done.
Depends on your environment, but I have of one very effective and successful coworker who just flat out refuses to use Slack. The number of companies where that is acceptable is probably limited. Unfortunately.
> I personally don't care if Electron goes away or what, but to the extent that I'm forced to run Slack by my cow-orkers' choices, it sure would be nice if it were less of a bucket of ass.
From experience, using the bridge means pinging the admin on slack about it, and convincing them that it's even worth doing, and then being stuck in "The IRC Room", instead of the others rooms in which people are actually communicating.
I use it extensively for everyday Slack, where I don't care much about inline media and inline formatting. And for a text client, weechat + this plugin handle it pretty gracefully.
I know I am really late to this, but one of the things I have been meaning to try is running Electron apps that have Web Apps with [Fluid](http://fluidapp.com). I think this may give me the perks without some of the drawbacks. I am not really sure, but it is an experiment I would like to try out.
I've never heard of Fluid before, but it seems to be a glorified shortcut with minor features such as notification badges. I really can't tell how this can integrate with Electron at all.
Electron would have you write a web app and package it as an app installed to your Applications folder just like any native app. You'll write this code in JS, HTML, CSS and use Electron APIs.
Fluid also would have you write this in JS, HTML, CSS but use Fluid APIs instead. The two compete for the same role in that sense.
With Fluid, you don't do anything from the web developer's prospective. The Fluid app just packages a Web site as a separate application. So, what this means that any user can take a Web site and make that a separate app if they want it.
> 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.
People are less likely to be spinning up vms but may have far less ram to start with and the more apps they use that are wasteful of power and ram the more likely this becomes an issue for them.
It is truly strange to hear being resource constrained being described as a special case in computing.
Last time I taught undergrads (last semester) their computers were far from anything as good as we'd have. If I asked them to run anything remotely demanding, it really taxed their laptops.
We really do need to be more mindful of resource usage. I'd rather write my own lightweight clone of something I want than use an Electron-based hog. There are menubar-only apps that come with an entire Electron dependency.
Why is that strange for personal computer usage? How common do you think it is for users to experience a performance problem caused by low memory? I'm genuinely surprised that we could apparently have such opposing intuitions. My intuition is that it is exceedingly rare.
Your intuition is badly formed because it ignores how crappy real peoples computers are. The world is full of really bad computers that people don't upgrade because their computer is a low priority item for them and they have lots of other more important things to put their money towards like food shelter, and medicine.
Further their machines are full of software that runs all the time for no reason including but not limited to multiple redundant antivirus that are trying in vain to scan everything in real time in a vain attempt to prevent the next malware infection from taking hold.
Various services like file system indexing and virus scans run at inconvenient times and render things slower than before.
Laptops are super prevalent because their portability is more important than power. Its not at all unusual to keep using the same machine for 5-8 years as long as it still works.
Real people have bad computers with bad specs and in a massive number of cases the browser is already using a significant portion of the entire computers resources.
The electron apps I've seen don't really have much UI. As soon as you build an app with some complexity it will start being a problem.
As a native Mac developer I can drop in things like a predicate editor for defining filters or queries. They come with Cocoa. I can put in sophisticated table views and tree views. I can connect all of this easily to core data which loads from a database objects on demand without any code needed to be written by me.
You see this sort of shortcuts in the electron apps I've seen. They don't have proper GUI for preference configuration like any Mac app as they can't get that for free. Atom doesn't have a regular file open dialog. I use that a lot, dropping a file into it to jump to a particular location I got open in Finder (file manager).
My preferred editor, TextMate has very little development resources behind it compared to Atom, yet it has a far richer GUI. You got a GUI for creating and editing plugins. Not just editing config files. You got native rich UIs for selecting fonts and colors. You don't have to write font names and color names in some config file.
There is a certain irony in the claim about how stuff like Electron saves you cross platform code, when what is usually not cross platform is the GUI, and the electron apps I've seen has very little of it. Try making something with the complexity of Keynote, Pages or Numbers in electron and I think the lack of a comprehensive set of prefabricated GUI components will start making its mark.
Not to mention the numerous native APIs which exist which you have to duplicate, e.g. for vector graphics, animations, 3D graphics, audio, video, font handling, OpenCL.
How about people with disabilities or internationalization? You got great native tools for doing that, how do you accomplish that in Electron without re-inventing the wheel?
I use a macmini for my dev work. Almost every time it freezes out of the blue the culprit was some html based "app" frequently with process nwjs using 100% of cpu and huge amounts of ram.
Honestly, though, the in-client search sucks. I'd much rather search archived text IRC logs through some web interface or locally than try and find something from 6 months ago within Slack.
I totally agree with you. I only use Slack from we app but I'm a heavy user of VSCode and Spotify. I believe in standardized Web API's rather than a clusterfuck of native API's.
The problem here is the base platform Electron and underlying Chrome/Nodejs
But as consumers we feel when our browser lags, so browser vendors optimize speed over memory and cpu, caching the shit out of everything. The Web is a dangerous place so they further isolate every tab as process, sandbox them and keeps lots or copies of the same thing in RAM because a security flaw is a lot more shameful than a memory flaw.
You are right, electron is a hog. Last I checked all, electron, chromium and Nodejs were open source. We can actually make a difference.
Making noise also makes a difference. When someone complained about VSCode cpu usage because of idle cursor and it blew on HN, next month's release had a fix (for all platform)
The truth is you can't move fast doing native development with different libraries. Electron keeps your dev costs down and allows you to move very fast.
> You are right, electron is a hog. Last I checked all, electron, chromium and Nodejs were open source. We can actually make a difference.
Won't that encourage more companies to cut corners? How can producers of quality products compete when other companies can release prototypes that their paying customers finish for them?
There's the argument "Why should I do it? If I'm paying for it then they should do it"
And there's, "This really sucks, its an open source project, I think I can make a difference that would affect millions in a small way but would still make a big impact overall"
Except for the very old 4.x Linux version - which is native Qt - and comparably old Windows ones, I thought, all of the recent versions are webbrowser wrappers (one sort or another) with some occasional native widgets around that.
(Can't edit the post above) But, of course, Skype issues aren't because of their UI nativeness. Their UI layer is... well, tolerable. Heck, I'd be happy if all I'd have to complain about Skype would be a crappy UI.
But I don't think UI implementation has to do anything about why we love it so much. I mean, missing calls and messages every other week, random desync between clients and all the usual rituals that every other group call starts from (you can hear them accompanied with chants "can everyone hear me?", "$name are you here?", "tell me if you see my screen" and "let me drop the call and restart").
i think i was still overreacting to prove a point. everything you're saying is right.
my point is, even if i concede native is "better" or whatever, the difference should be negligible for most apps for all users (let alone "most" users).
You are of course correct. It's possible to make awful native applications, and good non-native applications.
The sliders mean that you will trade performance off against ease-of-development. It will be easier to ship a basic Electron/web-stack app than a native one for multiple platforms. However, it will be harder to do this is in a high-performance and well-integrated way.
I went through all this with Cordova back in the day when trying to build cross-platform mobile apps. I was able to ship apps quickly, but at the expense of quality – it's okay to do this so long as you are aware of the trade-off.
yep definitely. and there is definitely a cost and effort required to make Electron feel as good as native. depending on your feature requirements, this can get really hairy.
i'm just exhausted by the "web apps feel so much worse than native!1" argument which is an over simplification and not a rule.
Skype for Linux is a web app. It is a lot worse than the old Qt client.
Are the other platforms native? I thought they switched to webrtc in 2015 to be able to just use a simple web window wrapper for all platforms, just not Linux.
Slack behaves perfectly fine for me and I don't have incredible hardware. It's non-Electron apps that are typically mentioned by macOS' energy management system as "consuming significant energy", in my experience.
Edit: Mass downvotes; lol ... Just stating my personal experience!
> 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.
I'm currently booted into Windows for work, looking at my current process stats, the top memory consumers are:
* Visual Studio (hodge podge of all kinds of things, 800MB)
* Chrome (215MB)
* Microsoft Intune (presumably native, 114MB)
* GitHub (.NET WPF application, 108MB)
* Explorer (native, 103MB)
* Search Indexer (native, 107MB)
* Lync (who knows, 98MB)
Meanwhile, the supposedly terrible Electron apps:
* Spotify - 58MB
* Slack - 93MB
* VS Code - 60MB
As far as interfaces go, Spotify, Slack and VS Code easily outclass GitHub, Visual Studio, Explorer and Lync in usability.
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.
Nope, those figures were after adding up all the processes. What I have noticed in switching between platforms is that applications tend to report a far lower memory usage in Windows than on Linux or OS X.
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.
My figures exclude shared memory and are calculated as VmRss - Shared from /proc/<pid>/statm.
If you are using Windows 10, your missing Atom processes will be under Background Processes in Task Manager. For the sake of the argument, I just did a fresh install of Atom and this is what I see on the first run: https://i.imgur.com/0ZRSumF.png. ~220MiB (no files open, zero extensions).
That's really interesting! I have an up-to-date atom install that i've been adding plugins to for about a year now (up to like 50 or so), and has been running for at least 12 hours (windows 10), and currently has 7 ~500 line files open.
Adding up all the processes' (7 of them) private memory gets me 194mb.
VS Code has way fewer features than Visual Studio, especially for C#/.NET development. VS Code is a minimalistic IDE, very useful, especially for javascript development where tooling is quite minimal anyways. But let's not think that VS Code outclasses visual studio.
VS Code is not an IDE in the classic sense of what IDE is - integrated development environment. It's a text editor with some debugging extensions. I don't think it is even comparable to Visual Studio at all.
That line is getting really blurry with both Atom and VSCode. Haven't used VSCode, but the only feature I recall missing in Atom right now is refactoring; and to be fair, last time I used a real IDE (XCode), I couldn't refactor there either.
For me, refactoring is something that is nice to have, certainly, but not what defines an IDE. The debugging and development facilities are what matter most.
A lot of that is available in "text editors" like Atom (and I assume VSCode). Of course, it depends on if someone wrote a plugin for your language of choice.
IMO it qualifies as an IDE for Typescript, and borderline with Javascript — slightly better than WebStorm in the former case and slightly worse in the latter — but not so much other languages.
I agree with you, but there doesn't really seem to be any native application that occupies the same space as VS Code or Atom. VSCode is not just a text editor like vim or Notepad++, as some people here imply. As you say, it's a miniature IDE. And it's far more comprehensive than Sublime Text.
For .NET Core + TypeScript, VS Code is almost feature parity with full blown VS, while being an awful lot faster. The only thing I find particularly lacking is debugging, but even that is coming along well.
I agree, I use VS Code because its the best choice I have for Typescript development on the Mac. However, I still miss Visual Studio while using it. The debugger especially wants to make me cry, though this might have more to do with Chrome than VS Code's front end for it.
But it's impossible to do a real apples-to-apples comparison, because I use Atom more like an IDE than I ever did with notepad++, and Atom has magnitudes more features for me than notepad++ ever did and most likely ever will.
I don't care about the difference of 175mb of ram between the 2 as one of them (atom) is infinitely more useful for me than the other (notepad++)
Maybe for one of the processes, but on Windows Spotify needs at least three processes usually to run (five if you count the Web Helper and Crash Service which are probably native code). On my machine the three main Spotify.exe processes take up at least 170MB of RAM, often more. Although I wasn't aware they were using Electron as their app has a standard, native Windows menu bar.
Hard to answer your question without hijacking the thread, but here goes:
• It's got pretty much all the power features out there like Snoozing, Open Tracking, Send Later, Reminders, Enriched Contacts (i.e. Rapportive), Unified Inbox, Swipe Actions, Templates, etc.
• It's open source and super easy to extend with JavaScript plugins. Developer have made dozens of themes and some cool plugins including PGP, Unsubscribe, Translation, Todoist, Trello, Markdown, etc.
• It's cross-platform for Mac, Windows & Linux with custom UI styles for each.
• It works with all mail providers including Gmail, Yahoo, iCloud, Outlook and even vanilla IMAP and on-prem Exchange servers.
• It syncs your data directly (not via a cloud service) for speed and security.
• It works offline, so you can use it on a plane or when you don't have WiFi.
There are other comments in here comparing react-native to Electron. Do you know if you could build Nylas Mail at the same pace with react-native? Will the binary size/RAM usage drop significantly on react-native?
I haven't yet seen a substantial desktop app built with React Native and afaik neither FB nor GitHub is investing in React Native for desktop so generally this is hard to say. React Native is more of a framework whereas Electron is a runtime-- much different goals though both are super cool and I'm enthusiastic about the future of both!
I'm holding off my downvote to see if i can get a straight answer out of you. Nylas Mail bills itself as the best email app. Them's strong words, but maybe you're worth the claim? Let's see!
I see from screenshots that Nylas has folders and labels. Can i use either of these in the following fashion?
- i can have a tree structure of them
- an email can be in two separate folders/labels at the same time
- folders/labels can be configured to learn which emails to automatically sort into themselves, based on the email contents, by dragging and dropping the email into or out of them
• If by "tree structure" you mean a folder hierarchy, yep that's supported. I think we have a current bug with dragging nested subfolders but we're working on a fix. (Surprisingly >99% of users have a flat hierarchy.)
• A thread can certainly be in two separate folders (e.g. Inbox and Sent) but an individual message can't be in two folders at once. In that situation there are two copies on the actual mail server. For Gmail/Gsuite this is possible via labels where any thread can have an arbitrary number of labels. We support both systems.
• "labels can be configured to learn which emails to automatically sort into themselves, based on the email contents" -- this is a really cool idea and something we've talked about internally. AFAIK there is no cross-platform mail client that does this today beyond things like manual Gmail filters. It could also be an interesting plugin that anyone could build on NM. We have a Slack chat room where folks discuss stuff like this if you're interested: http://slack-invite.nylas.com/
• And for your bonus round (haha) yes there are 2 different ways to configure the UI. One of them is 3-pane with a reading mode like Outlook, and the other is 2-pane that navigates like Gmail. http://i.imgur.com/Lt0x7O4.png
Also in 3-pane if you make the message list wide enough it will switch into the compact version: http://i.imgur.com/SaGp9eV.png
(Obviously it will show your real mail data. We have a "screenshot mode" for sharing stuff like this without revealing sensitive information.)
That's worth upvotes for the effort alone, thanks. :)
> Surprisingly >99% of users have a flat hierarchy
You tend to end up with it only after really long-term usage. All the folders with sub-folders i have got them after they got too big to be just one, e.g. "Perl coding stuff" has several subs, "Shopping", "Clients", "Computer Game Emails", etc. Some clients have additional subs. All started out as a singular one though.
> threads, not singular mails
Ok, fair enough.
> labels auto-learning by drag&drop ... AFAIK there is no cross-platform mail client that does this today beyond things like manual Gmail filters
Opera M2 does it extremely well since ~2000. Google Inbox does it ... eh. Mobile and PC, none, right. The filtering is honestly super easy to implement. It's a bayesian filter. In older email clients those were used to filter out spam. Opera M2 simply gives each folder one (user-configurable) and runs all the filters on each mail that comes in.
And to be fully honest here, i still use Opera 12 as my main browser, along with its mail client and don't see myself jumping ship ... anytime really since for me the combination of mail client and browser is key. However to respect an email client i expect it to be a feature match to Opera M2 at least.
Not interested in Slack. If you had an IRC channel tough i wouldn't need to sacrifice a chicken and a CPU core. :)
> UI
Ok, that looks fine. I personally prefer to have the email below the mail list, but that's not a huge thing. Maybe an option to consider. Screenshot mode is cute. :)
I haven't tried Opera M2-- I'll check it out. Might be a fun hackathon project to train a Bayesian filter on every folder and auto-suggest routing at least.
And simply adding up all the processes will count all the shared memory multiple times (which will greatly inflate the "final number" to much larger than it really is)
Steam always used a HTML renderer, even in its 2006 first incarnation. Nowadays it uses the same CEF (chrome library) as electron uses.
So Steam was one of the first "Electron" apps. A very first one was Windows Explorer as of Shell update that came with Internet Explorer for Windows 95 (included by default in Win98). All the sidebars of Explorer were HTML based.
Valve used a very ubscure/niche HTML render engine initially for Steam (2006). The company/website behind that isn't online anymore. An older version of the Wiki had some brief info, but all these info vanished.
It talks about the Steam overlay. Parts of the Steam application were always HTML. First the little known HTML renderer from a defunct company, than Trident and later CEF.
>A very first one was Windows Explorer as of Shell update that came with Internet Explorer for Windows 95 (included by default in Win98). All the sidebars of Explorer were HTML based.
That's a stretch; X/SG/HTML user interface APIs are not the same as a whole browser with Javascript VM, full networking and security stack, full-featured/standards-compliant (X)HTML/CSS rendering engine plus support for legacy features, UI assets, multimedia support, sandboxing, resource caching/persistence, and so on.
Win95 with shell update up to Windows Me and 2000 had the full trident engine (same as IE 3-5.5) in the Shell (Active Desktop, Explorer bars, etc.). Windows ME/2000 can play audio and video previews in the side bar (all HTML based).
Also WinXP used a forked Trident engine with some removed features for "Software" dialog and various other features (Windows Help, etc).
If you basically agree with the parent post, why do you say it's nonsense?
> The underlying issue here is that Electron reduces the barrier to entry for cross-platform development.
Precisely.
> The trade-off — and there is a trade-off — is that Electron applications are shite in comparison with proper native applications.
But native applications are shite in terms of portability.
> But let's be honest here – there is nothing preventing e.g. Spotify or Slack from building native clients for each platform they support
See the part where the original post said "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". The costs may not be "prohibitive", but they certainly would multiply effort and resources, and divide profit.
Well they were exaggerating but I think they had a point, til recently on my Desktop machines I only cared about having a web-browser, terminal (+ Steam at home).
Lately there are more UI-ish apps I value having everywhere including desktop (Spotify, Hipchat, Whatsapp, VSCode). I'd also love a decent cross-plat podcasts app.
I think it's clear there's now more demand for certain types of consumer-ish desktop apps (chat apps & music apps especially) than there was a few years ago.
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 would prefer that Slack look like Slack and not have buttons in different places with different UI interactions just because that's the way Reminders.app works.
For me, the web is the host platform I care about. It's the one that I can use anywhere and only have to remember the URL.
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 threw out the window several years ago.
Electron apps are mostly very good at the things in the above list, because the Chromium web renderer has spent years abstracting the mechanisms needed to feel native where it matters.
Non-native toolkits such as Swing and Qt also spent years trying to achieve native look/feel, mostly through emulation and host OS detection, and they still feel pretty crappy compared to Electron apps.
Slack, Spotify and friends do a good job of inventing their own "web but native-feeling" UI. An example of the exact opposite is Google Docs, which still, for all its technological impressiveness, feels like a crummy Swing app trapped in a web page. For example, Google Docs renders its own right-click context menus, which look and feel nothing like native context menus. Google Docs' mini-apps also have a menu bar and a toolbar, but it's part of the host window, so you get two levels of menu bars and tool bars.
Qt done well comes a lot closer to native look and feel than any Electron app I've ever used. The problem is that a minimum-effort Qt app falls into the uncanny valley. Slack is clearly foreign, but it's polished.
While true, Google Docs' collaboration capabilities are fantastic enough that it's worth using, though. We use it all the time to work, anything from tiny scratchpads to big documents.
To do the same in Microsoft Office, you need to dick around with OneDrive and/or SharePoint. The last decade or so, I've only touched Office when someone sends me some .xls or .ppt file and I'm being lazy and just want to view it.
I am referring to Google's realtime collaboration features. Given a URL, you can enter the document and see it being modified in real time, as well as edit, annotate and comment in real time.
It's 2017, this is how we work now. My colleagues (literally) across the world are not going to connect to some shared NFS drive or whatever via VPN to store documents.
What if the shared drive is automatically mounted on your computer when you log on?
One drive for your personal documents only for you. One drive for your team only visible and editable by people in your team. One drive company wide with common stuff.
You can send a link to your colleagues and it just works! That doesn't support multiple editing though. That's how things were done historically.
Google doc is good to send a documents to a bunch of emails and see/edit the documents. It's terrible to write longer documents with advanced formatting, pictures and schemas.
I often get frustrated when discussions about user interfaces in the context of native/non-native don't distinguish between 'skin' and 'ui'.
For the most part I think what people care about is that things work as they expect, which is primarily 1) placement of UI elements, and 2) interaction with/between these elements. If that's done right, nobody cares if the UI is flat, dark, light, or has a leopard print background.
Now I do understand that there's some overlap in ui/skin concerns, but the distinction still seems crucial to me.
For example, the web is clearly not consistent on the 'skin' of things. But I often know where to find things based on their location (header nav menu's, footer contact details, etc.), or general look (loupe for search, wide rectangle for inputs, some kind of wide rectangle with a doodad on the right hand side for a drop-down). Or a combination of placement and look (a search input field is an input field in the top right of a typical page).
Even lots of computer-challenged people I know seem to do pretty well in this regard.
But as you say, when it comes to interacting with elements, as long as the developer doesn't override 'native' behavior, a web-solution can be very native.
On the other hand, the vast majority of cross-platform native apps I use often look close to native, but their 'core', inputs, selects, text fields, and so one, often feel off.
Honestly, I much prefer a non-native looking app that uses native UI elements over an app that has an 'uncanny valley' native look that is slightly off and UI widgets that don't behave natively.
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?
Of your examples, I know Slack fully supports all of them except indexing and accessibility. For those two, I don't know because neither are of concern to me.
No, I don't care about most of those things. I don't know why you didn't believe me when I wrote it the first time :). "Caret behavior", I use a Mac 8 hours a day and I have no idea what option-arrow does.
That clipboard shortcuts work the same is the only one that I'm used to enough to be annoyed if it were done differently.
There's something about Mac fans that are very preoccupied with all of the details of how Macs work. I'm not criticizing that, you like what you like, but you shouldn't be surprised that I don't care about Spotlight indexing.
Cmd+arrows — jump to beginning/end of line or text
Shift+Option+arrows — select words or paragraphs
Option+Backspace — delete one word back
Cmd+A — select all
I actually used all of these except the last one while writing and formatting this comment! Plus clipboard shortcuts.
If you use vim in a terminal 100% of the time, none of those will matter to you because vim invents its own keyboard universe. But if you don't, I don't understand how you can have this opinion.
I get super annoyed with anything that somehow overrides these standard keyboard shortcuts, which is suprisingly often. Non-native UIs typically have to reimplement them because modern OSes have made the curious choice of not abstracting them.
I don't think it is a "Mac fans" thing. The exact same principles apply to Windows. Even to Linux, although the keyboard standardization there is next to non-existent. (I don't use Linux desktops often, but when I do, I get really frustrated that the terminals use Ctrl as a meta key instead of Command. So "copy" isn't Cmd+C, it's something like Ctrl+Alt+C.)
I use Cmd+A, that's it. It has a close corollary on every OS.
> If you use vim in a terminal 100% of the time, none of those will matter to you because vim invents its own keyboard universe.
I do, and this is one of the reasons I've never bothered with all of the details and shortcuts that you like.
Vim attempts to make the best possible text editor. It doesn't let "OS conventions" dictate what makes good text editing experience. What you get from apps staying to strict OS guidelines is a bunch of average -- not terrible but not inspiring -- applications.
Sorry if this sounds negative, but I'm perplexed why you would even involve yourself in the discussion when you don't have an opinion. It's like asking a bicyclist about how highways should work. They might go "I don't want any highways at all", but that's hardly useful to highway users (environmental concerns notwithstanding).
I accept that not everybody will feel the same way – I do care about my local platform. I want to hit 'space' when I have an item selected and see quick preview. I want my documents indexed in Spotlight, I want to drag-and-drop files between applications, and I want all the rest of the UI niceties I am used to.
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.
> 1) Why use several host platforms if the platform makes no difference to you?
I don't, I use The Web for 90% of all things I use on a computer. A Chromebook is one of the computers I use the most when not working for precisely this reason.
> 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.
I think you're mistaken, the fact that so many company are switching to Electron is evidence that it doesn't sell better.
I think you're mistaken, the fact that so many company are switching to Electron is evidence that it doesn't sell better.
Hold on a bit with that assertion.
First: which apps built on Electron are being sold, period? All the ones I'm aware of are open source, like Atom, or front ends to services, like Slack.
Second: which companies are switching to Electron for development? Again, all the Electron apps I'm familiar with are ones that started out that way. While I'm sure there's probably an app or two out there that began as a native client and then went to "let's just be a web wrapper," I don't know of any big ones offhand. (I've come across companies that have shifted their strategy to using true native applications, however. Facebook famously shifted their mobile strategy from HTML5/JS to native apps some years back, and I know of several iOS apps that were using "write everything in JS, it'll be great!" toolkits that switched to actual native AppKit.)
Third, and admittedly anecdotally, in both my experience and what I've consistently heard and read from people who've had the opportunity to study the UX of both native and "wrapped web" apps, just because users don't use the language of developers doesn't mean they don't notice when apps are slow, resource-hoggy, and behave kinda weirdly compared to other apps. I run a Slack for a writing group that's mostly populated by non-technical people and it is not uncommon for users to complain about Slack "slowing down their machine." Just because people don't know the term "native app" doesn't mean they aren't going to be able to tell "this app over here is nicer to use than that app over there," and that might be because "that app over there" doesn't minimize properly, or has weird menus that put common things in uncommon places, or doesn't do what they expect when they right-click on selected objects.
> The underlying issue here is that Electron reduces the barrier to entry for cross-platform development.
Actually, the incentive is even stronger than this. The ability to visit a website and start using an identical version of the app immediately is just as important - I doubt that Slack and Discord would have had half the success they did if users had to download the application before using it, regardless of them being available on all platforms.
Discord has had the ability to give links to others to join a chat server since its inception, resulting in a two-step process to use it: click the link, type a name. This is miles less of a barrier to entry than: click link, download app, find downloads, install app, run app, create account, join server (rough process for most text/voice apps up to this point).
It's a difficult trade-off, even for me as a user. The fact that I can load Slack on all my devices and in the browser definitely played a role in my adoption of it. The fact that Slack is dog-slow and a memory-hog on my MacBook Air, on the other hand, has kept me from using it as a central part of my own work. Similarly, I am actively pushing everyone I communicate with the switch from WhatsApp to Telegram because the latter has a performant native app.
If I were to build an app where cross-platform support was crucial, I'd probably start with Electron as well because of time and budget concerns, and switch to native if the app 'takes off'. But on the other hand, I can imagine there being serious risks to building out an entire platform that way and having to rebuild it from scratch later on. Maybe there's never budget/time for it, leaving me locked in?
This issue is so furiously divisive, and I feel like it brings out the worst in HN.
I'm from a web dev background. Some of the comments here make me feel like I should be ashamed of that fact.
I can see both sides of this argument (every time it comes up)
As a consumer of apps, I want the leanest, most minimalist, fastest thing going. I want native apps on my devices (If you think slack is a hog on the desktop you should try it on Windows Phone).
But as a developer, I know that electron is a shortcut that means my app will take less time to build. I can take my existing skills, take work I've already done on a WinJS app and publish it on Mac OS, Linux and Win 7. I can spend more time with my family, instead of spending all my evenings learning py+qt, or xamarin, or react native, or whatever the new fangled thing is. And I know people will use it.
Hell, I've even got better odds of pushing an electron app than a native one, as I can submit a pull request and maybe have it appear on https://electron.atom.io/
Obviously, seeing the Electron hate always gives me pause for thought, but at the end of the day it feels like the hatred is from fellow coders (if a dribbling front-end-js writing low-life such as myself can call you writing-assembly-on-a-napkin-while-you-quote-stallman-types fellow coders) and my apps user-base is overwhelmingly non-technical.
Honestly seems quite sad that developers today know only one (quite awful) language and have no whatsoever interest to learn new things because they can just write an application (probably with a quality not much better than the aforementioned language) that can be used everywhere but taking a huge amount of unneeded resources.
The thing that I like the most in software development is the ability to continuously learn new techniques and new, better, ways of solving problems.
I'm really afraid to think what would have happened if VbScript would have won the race as the de facto standard for the web..
..but actually thinking about it probably it would not have been that different from today.
We would have had VisualElectron instead of Electron, but with all the same problems maybe in a slightly worse or slightly better language, depending from the point of view.
> This issue is so furiously divisive, and I feel like it brings out the worst in HN. I'm from a web dev background. Some of the comments here make me feel like I should be ashamed of that fact.
I'm an embedded devices programmer and I'm proud of it. Proud to know a little bit about my hardware, and proud to get the most out of it. And I'm ashamed when I find a more efficient way to do something: it's not an optimisation but a bug fix.
Your non-technical users are capable of noticing that a certain application makes their computer slow or drains their battery or doesn't support a certain feature of their platform. It may take them longer to notice, and they won't know why, but that won't stop them from switching if a better alternative comes along.
Delivering high-quality web apps generally requires knowing JavaScript and CSS. Delivering high-quality desktop apps generally requires knowing the tools of that ecosystem. Sometimes we compromise to get things out the door, but we should be honest with ourselves when we do.
I'm honest with myself. I'm not disputing that Electron is not the most optimal way to create a desktop app, I'm saying that it makes desktop development (particularly cross-platform development) faster and easier. I know I could make a more efficient app by going native. And hopefully in time, I will. But for the sake of getting it out the door I'll most likely go the Electron route.
I meant that as a general statement, not a challenge to you specifically. I wish I'd phrased it more kindly, because dismissing criticisms as "hatred" and implying that non-technical users don't care about battery life are the sort of thing I'm advocating against.
Proper this and proper that, and don't get me wrong, I agree, but parent is correct -- and that is these apps wouldn't even exist if it wasn't for Electron. It just wouldn't have been a consideration for it to be a desktop app. Instead it would have just been thrown up on the web. For example VSCode would have just been some type of online IDE clone like Cloud9 or something similar.
If you think this is nonsense, you are out of touch, and I don't mean this as an insult, although I realize there isn't a good way to say that.
Yes. Electron enables some new stuff. New stuff that wouldn't exist otherwise.
Yes. Electron is a bucket of bloat that saddles what should be small, simple apps with enormous amounts of crap that has nothing to do with the app's functionality.
I think that's the real take-away here. There are upsides and downsides; I am pleased that it is easier to release desktop applications, but sad that the performance of them is so much worse.
I wonder if one of the issues is that so many developers have now worked almost exclusively in the 'web' sphere, and aren't aware that native development maybe isn't as difficult as they think.
Perhaps someone with both native and web development can set me straight on this; I have very basic knowledge of the former.
I've done the latter for a long time now, and only now I'm trying to teach some people, I properly realize much knowledge is needed to do it right. It's not just arcane knowledge of the quirks of CSS/HTML/JS, but also tooling, build steps, knowledge of 'expected' web behavior, frameworks, libraries, etc. Much of this complexity is still there and often worse if you go for vanilla js and static html/css (in part because expectations of a web app are higher these days).
I started learning native iOS development and expected things to be much easier and more sensible, but instead I get the impression that it's not that different.
Xcode is apparently a piece of shit, and everyone tells me to avoid Xcode's interface builder. There's tons to learn about how a project is set up, as well as stuff that just isn't a concern for the web like packaging it up submitting to the app store (hours just figuring out how to correctly supply icons and get a certificate). More than once, as I'm following an online course, the lecturer will say something like 'this might seem like a logical approach, but DON'T DO THIS and do <unintuitive thing x> instead.
Again, please correct me if I'm wrong. Perhaps when you put it all together it is significantly easier than doing the equivalent on a web platform. I'm just saying that I expected my initial foray into native, in particular Apple's 'walled garden', to be at least a little more like an actual garden rather than the chaotic, exceptions-for-every-rule (but kinda fun!) scrap-heap of the web I am familiar with.
On the plus side, this is an ideal situation to take advantage of - by creating native and fast applications, it becomes easier (compared to before when everyone was doing it "the hard way") to distinguish your product in a bloated market.
In discussions like this its important to try to distinguish between a priori reasons and post hoc justifications.
The real reason that parties like slack and spotify choose electron is because its easy for the devs they have that only really know JS/HTML.
Its not that they couldnt hire more/different devs that could do it in a saner way, its not that its too expensive or that the ROI is not good, when we are talking about companies worth hundreds of millions to billions of dollars focusing on a core market, that is just completely laughable post hoc bullshit.
Its that they dont give a shit, either about the user experience, or improving their toolset. They are happy where they are, and see no reason to change.
OneNote is a great example. It has fairly well-regarded native apps for each platform it supports, _and_ a decent web (HTML5) interface.
I think the issue is time and resources. Small teams, like Slack, would like to create a slick experience but they don't have the time.
Companies like Facebook went the other route -- HTML5 on mobile, got their fingers burnt, and went all-in on native. StackOverflow's iOS app appears to have improved a lot too, in v1 it was a thin shell around the web interface.
I hope React Native catches on. I'm not a huge fan of how 'heavy' Electron is myself.
Facebook's HTML5 app was 5 years ago, this example comes every time but it's outdated. technologies like Electron or React Native didn't even exist at the time.
5 years is huge when it comes to web technologies.
Electron is like almost any other cross-platform VM, including Java (which is living under most of the "native" apps on the world's most popular platform), .NET, and so forth. It doesn't share resources between instances but then you also don't get dependency hell (wrong version of Java for application X, etc.)
Subjectively, I'd say that Electron's performance overheads are not bad compared to, say, Smalltalk in the 90s, where one Smalltalk application could bring a fully loaded state of the art workstation to its knees.
And don't get me started about Flash. I had a whole project cancelled after an engineeer brought up the CPU meter during a fairly simple animation.
I've never seen anything performant built on top of Smalltalk, including the Xerox Star's built in apps which were developed by universally acknowledged geniuses. Flash's performance issues were legion.
Chrome is widely considered the best current desktop browser in a very competitive space. If it has problems it's definitely in idle power consumption (which indicates wasted idle CPU) but it is used by a hell of a lot of people who have free alternatives.
Those who forget desktop Java will be doomed to repeat it.
For those of you who aren't old enough to have been around, Sun initially pushed Java as a "write once, run everywhere" GUI language. It quickly became clear that Java applications were ugly and terrible everywhere, even in the primitive days of X11R5, when programs used a mixture of Xt, Motif, Qt, GTK, and raw X11 protocol (xv was awesome). Having a Java program for some task was worse than having no program at all, since it would discourage someone from writing a decent native solution.
Fortunately Sun found ways to make money using Java server-side, and Apple helped kill it client-side by not providing it by default.
I would like to offer http://openstreetmap.org as a counter example, where the best editing app is made in Java and the most used one is Javascript. There have been QT4 editors but they have never gained traction, I never found the problem to be performance between native and Java.
I think Javas problem was it's Unix engineering roots, with too little focus on UI, and perhaps a little too much of the "we don't care about performance"-mindshare. The latter being the only problem I see with some electron apps.
The cost argument is indeed a moot point - look at all of the major software companies, and you'll see that actual development is nowhere near their primary expense. They can afford to implement their own programming languages and OSes (and some do), but apparently it's too expensive or too difficult to make native apps for the respective platforms?
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 distinct codebases to get a multiplatform application. Are there 3 Firefoxes? 3 Chromiums? 3 VLCs? Back in the day, applications like Banshee, which written in C#, were the rage and were distributed as core parts of GNOME.
Why is there this belief that we have to use JavaScript for multiplatform?
This is a tangent, but CMake is incredible for building cross-platform C++. I had a project a year or two ago that was developed as a .so for Linux, using CMake simply because I like it.
When I went to go build a Windows .dll, I rolled up my sleeves and expected to have a bad day. `cmake -G "Visual Studio 14 2015 Win64"` just went ahead and made a Visual Studio project from my source tree, and that project built and worked first try. I was using all C++14 stuff like std::lock, std::thread, etc, and there wasn't a single #ifdef required in the entire project. Amazing!
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.
Overall, that sounds like an argument to exclude Mac support, if anything. But I would suggest that if it's so difficult to get the widgets exact, it's better to use a toolkit that can provide widget portability as well as precise implementations that pass through to native OS windowing.
>If you target the native OS widget set, you must have a separate code base for each platform's native widgets.
I want to clarify the subtle distinction here. If your code's concerns are separated, having to directly provide native widgets on some platforms means a different "codebase" for windowing and widgets only, not for everything. You'd still compile your normal code, and use an #ifdef or equivalent to include the appropriate windowing/widget library.
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 watched performance plummet.
Using Electron as a cost-cutting measure is fine, but it's not good for user experience and it's OK to be honest about that.
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).
Point taken – 'issue' is not the correct term here. Perhaps 'cause' is better.
Lowering the barrier to entry is great, I agree. It's awesome that Electron and web technologies can be used to quickly launch proof-of-concept desktop apps. I find it significantly less awesome that companies with hundreds or thousands of engineers continue to use it after the concept has been proven, however!
But these apps aren't "proof-of-concept" apps - they are fully functioning, working cross-platform applications.
So are you saying that these companies which have implemented these apps should instead say "You know what, we have this app developed, and working on the major platforms - but let's instead devote three new teams, one each for Windows, Mac, and Linux - to re-implement this app natively! I'm sure upper management will agree!"
That's not going to work. That's going to be shot down and laughed at. No company is going to re-implement a working cross-platform application over to three separate native contexts, and maintain all three. That just won't happen. It works already. The users probably like it just fine. What benefit to the company will this get them? Nothing - just more costs for maintenance across three platforms.
If native is wanted by the users, likely what would happen - if it happens at all - will be the company says "Ok - we'll make it native for Windows, maybe even Mac - maybe. Linux? Forget it!"
It's not the developers. Developers would love to make native apps, for all the platforms. But developers are limited by the companies they work for, and by the economic realities that all the platforms can't be supported natively; at most, only one or two can - because at that point, with the number of users on those platforms, the additional costs of maintenance and support are pretty much saturated. Adding additional native platforms doesn't just add onto those costs, it actually (in theory) multiply them - because a single person might use the application across multiple platforms. So if they have problems on two or three different native platforms, now there are three different support issues (needing more people to support) - instead of a single complaint for a single platform.
I get it, though - it would be great if these apps were native, and worked on every platform, from now and into the future (even on platforms that don't exist yet!). That's just not going to happen; if native is wanted, then only the most widely used platforms will be supported, and even then, one of those will likely be dropped, and it won't be the one from Redmond.
So - what can be done? I dunno. The concept the author brings up ("use React Native") might be the solution. Or some other interface that abstracts a platform's OS and other native functionality out to an API that is the same for all platforms. But now you have issues with security and other access - which you still have with Electron, but it is more contained and constrained, since it has to go thru the Chrome engine and the various rules/settings browsers have for sandboxing bad actors. Or - you leave it to the user and their operating system (and slim it all down - maybe that's what React Native does; I don't know, I've never used it).
Or - you (that is, the company) just says "Sure - we'll do a native only implementation - for Windows only." - because that's how it usually goes.
> It's not the developers. Developers would love to make native apps, for all the platforms.
I don't think that's true in the case of Slack. They only have JS "hacker" webdevs, and those are notoriously resistant to any change to their comfort zone. C++? WPF? Swift? Cocoa? Scary stuff.
"The easier we can make it for people to get started, the better, isn't it?"
Would you like to use an application that would not have been written without a low barrier of entry? Powerfull and easy tools are not necessarily the same thing.
"the easier we can make it for electricians to wire up my house, the better, isn't it?"
Unfortunately, no. Just as a trained electrician will wire up your house so as to not set it on fire as soon as you turn on a lamp, a trained developer will make apps that use a minimal amount of resources.
Especially more hilarious if someone writing Electron apps call him/herself an engineer.
As computer programmer in the web field, I find it awfully pretentious when web developers or any other programmers call themselves engineers when they are not legally licensed engineers.
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 idea?
If no, back to my point.
To quickly answer JetJaguar below you, yes, I am an utter cunt, but being called a typical hackernews one hurts, considering how I can't stand most HNers.
> 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?
I have been trained as a Software Engineer in Istanbul. I am very sorry that my country doesn't fulfill your expectations.
> If yes, what in earth makes you think writing Electron apps is a good idea?
Engineering is about making trade-offs. There's enough discussion here about what those are for writing Electron apps.
> If no, back to my point.
What, "no"? What was your point? ...that I'm not an engineer? As I said, I am one.
> yes, I am an utter cunt, but being called a typical hackernews one hurts, considering how I can't stand most HNers
I don't think you are a cunt. I think you are uninformed and have concrete opinions based on limited or self-fulfilling-prophecy-boosting experience.
> 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.
I think Germany was the country described in the post. Whether it's true to the fullest extent is hard to say, but having worked and socialized with them for years it seems mostly true. Engineering is the country's actual official religion. And I mean that as the highest compliment.
(No offense to any other country's engineers -- the engineer mindset is the same everywhere, but the mindset of the non-engineer in other countries is the distinction. That is, Germany grants engineers a degree of respect, almost reverence, that I've never seen in the US.)
Our company recently purchased some Hardware I/O devices that came with software (both made in Germany). Lets just say, I'd much rather buy their cars than their software.
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.
Are there standardized licensing bodies for software developers in the EU and Canada? I'd be really interesting in learning more about them if so.
I sympathize your argument and I think the field is doing a great job right now demonstrating some of the upsides of a licensing authority, but actually getting one would be bad IMO.
Most software is not life and death, and licensing authorities, like unions, quickly become gatekeepers that work to prevent competition whilst simultaneously enriching themselves through extortionary means (today, these are mostly indirect because everyone is on the look out for them, but they are nevertheless still there). There are good arguments that the AMA and ABA have both seriously contributed to the astronomical expense of their respective services.
>Are there standardized licensing bodies for software developers in the EU and Canada?
For engineers, absolutely.
For software engineers, absolutely, because they're still engineers.
Software development? Go wild, anyone can do it.
>licensing authorities, like unions, quickly become gatekeepers that work to prevent competition whilst simultaneously enriching themselves through extortionary means
That seems like a terribly US centric that I keep seeing online. Unions in France, as it's the one example I can be certain of, are in no way gatekeepers, and we are a country where they've been immensely powerful when it comes to influencing the state (whether talking about worker's unions or CEO unions). But you can get any job without being in an union, all they're doing is bringing everyone on an equal footing when it comes to negotiations.
Licensing authorities are purely a society thing. Either you have a numerus closus, because the end goal is for everyone that passed the selection to have a guaranteed job, with good living conditions, or anyone can pass, and good luck everyone. It works in some cases, doesn't in others.
I've never heard of some governing body in France or England taking away the title of "software engineer" for someone who wrote faulty code. What are these governing bodies?
Maybe I have the wrong impression, but I feel like the author of the original post never wrote anything cross platform that's sufficiently complex (ie, more than a "let's fill out a form and press OK" Qt app).
> The trade-off — and there is a trade-off — is that Electron applications are shite in comparison with proper native applications.
There's nothing inherently electron-specific that makes an app "shite" any more than writing one in Qt would. You can write shit in any language, framework or platform. The day someone invents a system that protects us from our own stupidity will be the day humans become obsolete.
> They fail to integrate with the host platform,
Untrue. You can—if you need to—integrate with the host platform by writing a native node module, however it becomes less cross-platform at this point.
> they are slow, they hog memory and drink power.
Yes web apps use a bit—sometimes considerably, depending on what you do—more memory, and a bit more CPU (and hence bettery),
but they are not perceivably slower, unless you're doing something stupid (in which case the equivalent Qt app would probably suffer in the same way).
> But let's be honest here – there is nothing preventing e.g. Spotify or Slack from building native clients for each platform they support, and I find it difficult to believe that the costs would be prohibitive.
Maybe, maybe not. I think using a cross-platform solution wouldn't be ideal for them (they'd need to either rely on something like Qt, write their own rendering engine, or use something like SFML; all of these are overkill compared to Electron), and the alternative is writing it in different languages for each platform, which would probably inevitably cause the projects to get out of sync in one way or the other over time.
in my opinion this is an hiring problem, they assume that if you know javascript you can be spendable on more things and not only on the desktop to write an application.
Can't say I agree. Native apps are often garbage. Discord is another Electron app that I think is actually quite a bit better in most dimensions (attractiveness, functionality, speed) than the native apps it replaces (Mumble, Teamspeak, Skype, etc.).
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 haven't used many modern windows apps yet, the ones I do use are stuck in the 90's with their button bars and such.
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 and how flexible they are, this would mean so much hardship and pain in older solutions to the point where it's probably not viable any longer.
It's the ease of declaring components and structuring complex applications with it. There is nothing in WPF that is comparable to it unfortunately, except Redux.NET maybe, but XAML is a lost case against JSX. You'd have to see it, or work with it. The bottom line is, drastically less code, clean structures, things become simple to do.
Like hot module reload where you write your app live. You edit one component, everything else stays in place and maintains state. Or time travel with Redux, where each piece of state is inspectable. You roll back or slide through the apps history and see it literally build and deconstruct itself. That's possible because UI is just a function of state. Same state, same UI.
It's never going to be possible to fully separate the factors out. With infinite time and effort by the exact same set of devs, I'm willing to grant that electron apps will be worse than native apps. But that hypothetical circumstance (same set of devs, infinite time and effort) does not exist in reality.
Facebook still has not made any desktop apps available, leading me to rely on a hodgepodge of 3rd party, electron-esque shells to provide a desktop experience.
This is despite their mobile apps being the most minutes used apps of any company. Even then, they tried to go with a electron-esque approach and only backed off when the performance and UX tradeoffs became unacceptable.
If one of the most profitable companies in the world can't see the business case for supporting a first party desktop ecosystem, it's very hard to believe many other companies have the justification.
This isn't an engineering problem, it's a business problem.
They don't. Java apps have been cross platform since their inception, .net is extremely close to being just as versatile, x11 is available on mac and pc, and python will run on literally anything. There's a pile of cross-platform options out there for you. What electron does is reduce the barrier to designing UIs, since you can do it all in html and javascript and its just as easy as hiring the guys who did your website to design. Because the one thing all those platforms have in common? Aside from .net (which isn't mature), they all have absolutely hideous windowing systems. Just ugly.
The main challenge, I think is that all of those apps are cross-platform, but also want to keep the same look and feel on all platforms - they're using their own UX patterns inside the container which generally don't match up with their host OSes.
There are some applications that do try so - 1password, GitHub for Mac/Windows to name a few that come to mind - but they seem to get less love than the cross-platform webapps. It feels like they get a certain amount of dev time before going to minimal maintenance mode.
This reminds me of what's happened with Unity (the game engine). There's a completely false perception that Unity is eating other engines' lunch. It isn't. All that happening is that game development has been democratized on an absolutely massive scale. So more games are being made. Most of them are bad. Most of the best games are made with either Unreal, or much more commonly, proprietary C++/asm engines.
Spotify, Slack and Atom are no longer hip startups though - they're established applications, and at least two of them have a very lucrative monthly subscription model. They can afford to optimize.
But the user experience is already great, so what's the gain? Electron and the web clearly make a first class app platform on desktop.
EDIT: thanks for the downvotes. I'd love to hear your thoughts on how electron is keeping Slack and Spotify from building a massive business and how their desktop users find the experience so bad they don't use the tools obsessively. Clearly there are things to improve w/ Electron (energy usage), but "terrible experience" is not how I'd describe Spotify and Slack on desktop, and their businesses clearly reflect that.
Moving to a native stack has major tradeoffs, would it 10x their business at least? I strongly believe that answer is "no."
Its a terrible experience to discover my battery life is cut in half because of a cursor animation in VS Code, or to have my laptop heat up and the fans engage because of an animated GIF in slack.
But its worse than that - most users don't even know why their battery life is awful. So they blame apple, or microsoft, or dell or whoever. And they just don't use their computers as much, because its all a bit gross and slow. And thats bad news for our entire industry.
Sorry, I'm confused. Which part of this bad performance was a bug in chrome? The peaking up to 100% usage for a few hours? The shockingly bad performance rendering GIFs? The super high idle CPU usage? The high download size and ram usage?
I used the desktop slack client all of last year, and these kind of problems were present the whole time. This isn't some "oh, yeah there was some particularly egregious bug we shipped accidentally in October" thing. Whatever is making the slack client a bloated ball of crap is much worse than a simple, quickly fixed chrome bug. Its endemic.
A bug that it's a lot more easy to be discovered and fixed when it affects so many people, How many "native" apps have similar battery hogging bugs that are not fixed because nobody founds about them?
Anecdotally, I had to cancel spotify due to shitty experience. One of their app updates on my phone left it completely draining my battery in a few hours even when not using the app, with no way to keep it from running in the background other than to uninstall. (ok or possibly rooting my phone to install more recent android with better background process control)
I pay for Spotify but I don't see it's poor UI/UX problems. The sections make sense, the color contrast is good, browsing through an artists albums and songs makes sense, the playback functions bind perfectly to the media buttons on my physical keyboard. What else could I want?
The user experience of Slack as a desktop app is not great. The UI is consistently one of the highest energy users on my machine, despite being one of the worst performing (have you ever tried scrolling up into a conversation's history?)
None that I can think of, really. This is one of the cases where a desktop version of a web app exists and I'm not aware of why.
Spotify makes sense as it can reliably use your file system for storage and thus download songs so you're making fewer network requests. Perhaps Slack could keep a short log to prevent "scrolling up"-related network requests?
Choosing a platform isn't really premature optimization -- if you base your project on electron, and electron is too slow, your alternative is to... rewrite your project?
> You know what the alternative to all of these Electron apps coming out is?
A single page web app?
That's all most of these are. Particularly the Slack/Hipchat/Discords of the world.
> People are excited about the Desktop again
If by desktop, you mean "need to be connected to mains power to run for more than 10 minutes", yeah, people are excited for desktops again.
Electron only really makes Javascript developers happy; they don't have to learn another language or framework to make "desktop" apps now. As a consumer, I fail to see the value in having to download large single page webapps that are equivalent (or worse) than their online counterparts.
Cross-platform applications like Chrome and Firefox and Steam and Doom and Factorio and... these have existed for years, and so have cross-platform programming languages and frameworks. Java, TCL, Qt, Flash... Electron is simply the lastest in a long line of cross platform frameworks, which is currently in-vogue with developers solely because it uses HTML and JavaScript.
>> As a consumer, I fail to see the value in having to download large single page webapps that are equivalent (or worse) than their online counterparts.
I use the Slack app for Windows, and the value for me is that it gets its own easily identifiable presence in my Windows task bar.
I have a (self-inflicted) problem with tab proliferation, and because I rely heavily on Slack, it's just way more convenient to use the self-contained version than to have it running in a tab buried in one of my browser windows.
It doesn't bother me at all that the Slack app is an over glorified web browser running the Slack web client.
> It doesn't bother me at all that the Slack app is an over glorified web browser running the Slack web client.
It kinda should, though, because if the browser component isn't up to date on the regular then it's possible you're looking at (what should be) a simple chat app with a potential RCE.
Discord desktop is electron. Only our iOS app is react native. We spend quite a lot of time and effort optimizing performance however, something thats required given the number of large servers with many thousands of concurrent users.
What planet are you on? I've been using great native apps since forever. I don't know what it is but there is a certain segment of the computer user population who don't seem to notice that awesome native apps exists for all sorts of stuff.
"actual dev time per feature (easily 10x the cost)"
Yeah seriously what PLANET ARE YOU ON!!! I can make native app functionality in a fraction of the time it takes to do it in a horrible mess of a language that is JavaScript. Poor type system, shitty REPL, shitty module support, shitty debugger. Shitty GUI design tools. Shitty performance measurement tools.
"And as for Qt, Qt has existed for over two decades"
It is C++, and we got great alternatives on Windows and OS X. still if you have to stick to C++, then Qt is probably the most widely used GUI toolkit.
"People are excited about the Desktop again"
I don't know what bubble you live in. This is just a bunch of hipsters who are excited because they can suddenly use their only programming skills to hack on desktop apps.
Lets get real, this is all about the numbers and not the technology. Due to the the need for lots of custom made web apps, there is a huge population of JavaScript developers. These can now be utilized for desktop app development. It isn't like it wasn't possible before, it is just that these guys could not be bothered to learn anything else.
And it isn't all that important. Hardly any of the applications I use daily are Electron. I occasionally use Atom. Other than that great apps like OmniGraffle, Pages, Pixen, TextMate, Ulysses, Marked 2, Charles, Dash, Kaleidoscope, Tower, Keynote, GitUp, 1Password, Magnet, iBooks, ScreenFlow, Terminal etc none of them are electron based.
He's right, and you're right. Web technologies have a low barrier to entry, so it's easy to go from inexperienced to productive.
Advanced native tools with a powerful language in the hands of a master programmer will be much more productive for the reasons he cites. The type system in particular, with a well-worn toolbox of primitives can make you extremely effective.
So, web technologies are more effective in aggregate across the entire industry, but native technologies can be more effective in the hands of an experienced single individual.
>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 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.
I find this argument absurd. Desktop (and mobile native) apps are multi-tens of billion business. Ask Microsoft, Apple, Adobe, and thousands upon thousands of smaller businesses (down to SMEs like Panic and one-man-shops like Sublime Text).
If anything it's those web-based unicorns that are either merely burning VC money, or selling the user to advertisers -- in both cases, there are not much money in selling them directly.
And there's nothing about web development that couldn't be achieved just as easily if instead of all those money on browser engines and teams to create things like Dart, there was some effort towards a nice, cross platform, mobile and desktop UI library.
It could even have JS bindings for all web devs to use -- just without the web stack crap. React Native is something akin to that, but imagine if it had been going for years, and had more industry support, instead of the nth attempt to put lipstick on the web stack.
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.
If you can't think of any companies that have built significant desktop apps recently, you're just not looking. I don't even get how this is an argument. "Well I haven't personally installed a native app recently, so obviously they're unimportant."
You know what's never going to go out of fashion? Performance. Especially since CPU speeds have stalled in the last decade. you will never get good performance if your design is: "embed an entire browser, and then use a small piece of it"
> Nobody cared about writing Desktop apps before Electron came along, there's basically zero money in it
Wut? So the whole Mac App Store, MS Office Suite, Adobe's apps, many other stuff were just a dream? Until Electron desktop was dead? You're bending facts here, and I hope that's because you don't know much about the stuff you're talking about.
Desktop is big, just that other things have grown bigger. That doesn't mean desktop is/was ever obsolete or losing it's utility.
By "nobody", he means JavaScript "hackers" (his term) and webdevs. How joyful that those types of "devs" are now excited and "care" about desktop and mobile development.
Limiting oneself to JavaScript is quite limiting. Just like a polyglot person is has access to way more information, cultures and fun than a monolingual one; a polyglot programmer too has access to more tools, paradigms and fun. Also, hammering everything as if all the stuff was nails is not hacking at all.
And also on Windows, and even on DOS, before Windows.
Googling terms like "shareware" and its history (not the only model, there were, of course, outright paid products too), will show some stories, maybe not a lot, since some of this was before the web, so not archived. But will show enough to get an idea. Jim Button was a classic example, but there were many other indie devs (many of them one-man shows), who may not have made it so big, but made good money from desktop apps.
Ironically the Mac App Store itself is basically just a WebView in a window, and you're essentially browsing a website (DOM and JS and everything) with extra privileges with the host OS.
Bullshit. Spotify, for example, existed before Electron, and it was very fast. Text editors existed before Electron, and they didn't require 300 MB minimum to run. Same with collaborative chat programs.
Electron is just a way to reuse web developers for desktop development - I.e. a way companies now have to cut development costs.
Chrome was released as a beta the 2 September 2008. The first version of Spotify was released 7 October 2008, and the download size was around 5 MB. I know because I've using Spotify since it was invite-only, back in those days.
So according to you Spotify was able to build a full featured client using a beta technology in a month. Impressive.
Vim and Emacs are probably much slimmer, but a comparable GUI editor- Sublime Text, is using 311 megabytes for just one window of a folder that has 200 files in it.
Yeah... I opened a 500KB log file in vim and Notepad++ and they are using 5 MB and 7 MB of RAM, respectively. They both also manage to use no measurable amount of CPU (even to blink the cursor!) unless you interact with the window.
I should say "measurable in task manager" - which reports in increments of 0.1%.
Realistically I would imagine that a native Win32 app (Notepad++) that's totally idle except for message loop and cursor blink requires less than a microsecond of CPU time per wall clock second.
It gets better: the caret in "real" Win32 is not rendered to the framebuffer or any memory-backed surfaces, but is "inlined" in the video output the same way the (hardware) cursor is - it's effectively an old-school console sprite.
But it does mean you're limited in the things you can do with it - when Office 2013 gained that fancy animated caret they had to do it themselves, similarly the caret in Atom and VSCode are both software-based.
But - can I get a copy of Notepad++ on my Linux box? No?
Now - I know there are a ton of other options for Linux, but the thing is, I can't jump from system to system and have the same app with the same experience - even if the app was developed as a native app for all of the platforms, because each has a slightly different native GUI implementation and usage which doesn't translate fully between each.
So now I have to learn and use potentially three or more different programs/apps/whatever to do the same task. Or, I have to remember the quirks for each native implementation.
...and let's be honest: Not many companies out there are going to develop a native version of the same app for all the platforms, because most platforms have a lower number of users than others (in many cases, much lower - depending on the genre of the app in question - like games).
It's an economic tradeoff: We either get a balkanized system where for certain kinds or types of apps we need a particular machine for the native implementation, or we have the case of these larger cross-platform apps that anyone can use on any system, in the same manner everywhere.
Here's another thing - most of these complaints seem to have to do with laptop users. I don't really worry about these issues on a desktop, because there I can have a ton of memory and way more CPU than what I can get in most laptops, and I don't have to worry about battery power.
But for those who are stuck with laptops - maybe they need to bother manufacturers to increase the amount of RAM and CPU available, to handle these larger apps.
It's also funny that I hear people complain how these apps are too big, and use too many resources for editing text or whatnot; you make the case that vim and notebook++ use only a few meg of memory, and no CPU.
I tend to wonder how well they'd fair on my old TRS-80 at home - you know, I had a full-screen text editor on it that didn't use much CPU (sub-1 MHz) nor memory (less than 64K) - so why can't we return to that?
Honestly - I don't want to; but we can take this argument down the rabbit hole, because the argument that today's stuff is bloated compared to another case, can easily be made about today's stuff vs older stuff. Most of that bloat of your "smaller" example comes from abstraction; the same as the "new bloat" - not many years ago a program taking of 10 MB of RAM would have been insane. Today, it's normal and expected.
I daresay that in the very near future, programs taking up several hundred meg to a gig or so will also seem normal, because by then we'll have even better CPUs (with maybe hundreds or thousands of cores) and way more RAM (terabytes).
Some might argue that this is the case today, in the form of cloud computing and SaaS - browser-base stuff, in other words.
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...
Wow, that's bullsh*t. Sorry but what you said was factually incorrect.
What Electron did is it enabled all those web devs (even front end guys) to write "desktop" apps. And trade offs are certainly visible.
I am boycotting Electron. I have zero Electron apps installed, and recommend strongly against it. I hate that web dev mindset that has been pushed into desktop userland. It just doesn't work that way. Write native desktop app yourself and you will see how wrong it is.
Can you expand on your last sentence? How is React + browser rendering any different then QT rendering? How is HTML/CSS any different from QT layout xml? How is QT sockets/threading any different from NodeJS sockets/threading?
They are very very close to each-other. Obviously they are not exactly the same, and I used QT in this example. But they are not wrong, or completely different.
> How is React + browser rendering any different then QT rendering?
Qt has far less overhead. A small Qt program can be in the single digit megabytes in both disk and RAM consumption, while using near-zero CPU for the UI.
> How is HTML/CSS any different from QT layout xml?
My understanding is that Qt's layouts are translated to native code at compile time, resulting in native performance and overhead on desktop. Browsers' dynamic rendering is relatively intensive and expensive.
> How is QT sockets/threading any different from NodeJS sockets/threading?
When it comes to I/O I don't think there's a significant cost to using Node/V8. I'm totally fine with CLI applications written in Node but when it comes to UI, a browser is just too heavy.
Haven't wrote a lot of QT, but Cocoa/DELFI felt totally different than writing Electron app GUI.
Writing Electron app felt like sketching, at least to me. You place one line of code with tags and boom there's a button. Now QT takes place somewhere in between, and it still provides nice native multiplatform environment that could be appealing to web developers.
> Writing Electron app felt like sketching, at least to me. You place one line of code with tags and boom there's a button.
Runtime issues aside (bloat, cpu, etc), why is this a bad thing?
I like that I can write a single line of code and "bam!" get a button (or any number of things) to appear. Why would or should I want things to be more difficult for me to develop a piece of software?
Sure, I could do things in some other language - I mean, I know a ton of others. But implementing the same functionality can be a much larger pain in those other languages (and honestly, for app gui development, I haven't found anything that beats the drag-n-drop editor of VB3/4/5/6 - there was something close to it in Visual Studio for C++, but it still required some manual "hook up" with the code for callbacks and event handling and such).
I mean - if I really wanted to do things "right" - why don't I just whip out my text editor and write assembly for whatever CPU I'm targeting? I can full control over everything, then! Best performance! Those guys and their compilers, I tell ya, they don't know what they're missing!
(heh - sometimes they don't - there's a whole generation or more out there who've never coded for a CPU by looking at a datasheet and finding the byte values needed to represent op-codes to hand-assemble a piece of code - sometimes I do miss hacking on the Apple IIe and monitor - CALL -151 ftw)
Anyhow - as someone who's been coding for longer than I really care to say (of course, I kinda gave my age away above!) - I don't want to return to those days; I kinda like living in the future of computing I could only dream about as a kid.
And you really envision the future as webtech? That's sad commentary in and of itself, isn't it? You lament old ways of work in one sentence and glorify the most terrible ecosystem and methodology in the next.
Simplifying in itself is not bad. Improving API with newer and better is not bad. Adding language features to advance productivity is not bad (thinking of C# iterations vs Java). Basing the future on a terrible language, ecosystem, practices and "developer" mindset is very bad.
So do you think that the future of computing is blinking cursor in code text editor consuming 13% of CPU? Or maybe small gif using 30%?
You presented like the problem was in writing of the code, it's not, that's Electron's biggest strength. The problem is the bloat that it comes with in order to provide you with that experience. Like everything, it's the matter of tradeoff. For me, it's not worth it, nor I like writing HTML and CSS.
The problems you get from Electron apps isn't V8, it's Chromium. React-native apps will behave and consume resources much more like a native app than an electron app, hence the name.
I'm not even boycotting it, I just don't use it (or any apps built on it afaik).
Unless they significantly rethink their approach it's significantly flawed without much room for improvement. Plenty of room for something better to come along. Even if it saw mass adoption, the demand for a better base would invite an alternative to gain traction against a sluggish goliath a la Firefox-vs-IE (or Chrome vs Firefox).
> Nobody cared about writing Desktop apps before Electron came along, there's basically zero money in it
I would acutally pay Spotify extra money if they brought back the old, snappy, pre-Electron version of their Windows desktop app.
<edit>They replaced it with something that is simply too heavy to manage larger playlists (except maybe on the max-spec MBPs it's being coded on) just because they could iterate more quickly on some non-essential features which they might have packed inside a WebView, leaving essential features intact and responsive.</edit>
What is there to be excited about? Having your battery drain every-time your browser runs some JS app? Wasting CPU and memory that I paid for? Lost productivity waiting hundreds of milliseconds (sometime seconds) for any UI response? I dread using any technology coming out of a SV startup, and its rather sad. I want to be excited, but can't get myself to be. As an aside, with all due respect to these startups, calling them successful is premature. They only appear successful because they're burning through someone else's money.
These technologies you diss have been reliable and stable for over a decade. As an embedded developer, my code has to be running 24/7 for months without rebooting, without running out of memory, without crashing. But forget embedded, and imagine a web service. Can you truly honestly say that an app written in electron will give me that reliability? Or should we just accept that if you want to write apps using "modern" tech, you'll just have to deal with it? I personally can't imagine any web framework ever maturing and being stable enough to where you can invest money in it knowing that it will be around 10 years from now. Having your underlying technology platform in a constant flux makes your entire product stack brittle. That is a Big Deal.
> 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 native desktop app is almost always cheaper than trying to build a JS-heavy app that has to run well in Mobile, and Tablets, and in a standard web browser, and in Electron fake-native-desktop web browser. Yes, you have separate projects with separate codebases. But two or three small lightweight projects is almost always cheaper than one big codebase with lots of targets, in terms of total cost of ownership.
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, blogs, etc.), "hacking" on new frameworks is also quite easy.
I think all these "massive cost" comments come from sheer ignorance. Those "devs" are frightened at the need to learn a new language and frameworks, overestimate the time required to learn those, look around them and only see likewise clueless "devs", frightened of changes, and extrapolate some comically high overestimation of cost and time, when in reality, a properly written software is much more accessible to join in and support than a web "app" with the contemporary "sexy" observer pattern nonsense splattered all over, coupled with a horrible, horrible dependency management system and a language/framework combo that requires multiple dependencies to perform the most trivial of array loop.
Spot on, I serioulsly don't understand people that are Java developers/front-end developers/technology X devs if you're not talking about you're currently working on, and instead treat that as their profession.
Anyone would think it to be ridiculous if a carpenter told you he only works with saws because he is a saw carpenter and that for other kinds of work you should see the plane or sander carpenter. To me saying you're an [insert tech here] developer sounds the same...
> Anyone would think it to be ridiculous if a carpenter told you he only works with saws because he is a saw carpenter and that for other kinds of work you should see the plane or sander carpenter.
...and yet there are specialties within like "framer" and "finisher", among others. Then you have interior workers like specialized custom cabinet makers, flooring specialist, drywallers, painters, etc.
What I'm trying to say here is that even in "carpentry" for putting up a house, there are numerous specialties.
> I think all these "massive cost" comments come from sheer ignorance.
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.
meaning he works for a company that heavily leveraged an existing protocol, IRC, for which there are already a metric fuckton of native clients and libraries for every platform under the sun.
Implementing their shitty web client was undoubtedly far more work than supporting a handful of native clients.
With my company, our users have always begged for an Mac OSX and iOS app. We never provided it, because we have zero-internal expertise with any of the technologies involved. We could contract, or hire for that specific purpose, but the moment that team member was gone the project would be dead and out of sync with the rest of the codebase.
The codebase isn't lightweight to begin with, and duplicating it for a native app that maybe only one person could maintain was a non-starter.
What'd be a good example for the kind of lightweight project that can reasonable be duplicated for Native Mobile, Native Tablet, Native Desktop, & Web Browsers?
> We never provided it, because we have zero-internal expertise with any of the technologies involved.
Couldn't your team learn the technologies? These days there is an abundance of resources available (online tutorials, books, bootcamps, etc), especially for ecosystems as popular as the Appleverse.
I can't pretend to know your situation, but as a reference point we had an iOS project come up at work a couple years ago and I was able to pick up Objective-C and the Apple libs in a few weeks while still being productive on other projects. I followed Apple's official tutorials[0] and built some toy apps, then learned the rest as I went on the real project. This is after having never owned an iDevice and doing mostly web and devops work in scripting languages for many years prior. A few peers of various experience levels were able to ramp up in about the same amount of time, so I'm not special.
> With my company, our users have always begged for an Mac OSX and iOS app. We never provided it, because we have zero-internal expertise with any of the technologies involved. We could contract, or hire for that specific purpose, but the moment that team member was gone the project would be dead and out of sync with the rest of the codebase.
I don't see how that is any different. If your Windows team members all left, that project would be dead or out-of-sync too. Wouldn't you replace valued team members who leave, in both cases? Or is this a concern that you won't be able to find developers willing to work with OSX and/or iOS tech?
> With my company, our users have always begged for an Mac OSX and iOS app.
Repeating this again because this should be telling. If your getting feedback begging for an OSX and iOS app, there's probably a number of really good reasons for that.
> What'd be a good example for the kind of lightweight project that can reasonable be duplicated for Native Mobile, Native Tablet, Native Desktop, & Web Browsers?
Spotify, Slack, Twitter, Facebook, any streaming video service (Hulu, Netflix, Amazon Prime Video, HBO GO), etc.
Note that I'm not using "lightweight" to mean "small weekend project", but to mean "less complex than the codebase needed to reproduce these features in a browser or Electron browser".
--
If you are truly a small company / startup, and you truly have to support all platforms with a small team, then sure Electron makes sense despite all the drawbacks. I totally understand that.
But I usually hear this excuse from big companies, that still want to perceive themselves as small, but aren't. Slack is a billion dollar company, they are not a small business / small startup. If a company is large enough to have more than two people working in HR full time, then they are probably big enough to do this stuff right. "We're a small team" simply isn't true for them.
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 not want to go back. Case in point, modern apps like VSCode, Atom, Hyperterm, Discord do things that would be very hard for a native app to mimic, and they do that with absolute ease.
I agree though that Electron is a problem. React native will probably be the best way forward. Microsoft has recently taken over RN-Windows and ReactXP, a RN-web clone. RN runs natively, doesn't need a browser, while being able to tap into the JS eco system.
Redux and co are still the same pattern fundamentally, it's just that the implementing code is spread throughout your stack, instead of in an "Observable" implementation. That combined with an optimisation allowing identity and state equality to be conflated.
I don't know what you're saying, this is the complete opposite. Redux was made to centralize, because observables are literally spread throughout the stack. The entire logic is combined in composeable containers, later wrapped in a single store. Flux pattern is also completely different in how it works, there's almost no similarity whatsoever.
That is the whole point of immutable state, and it is very effective because parent props are also notified through shallow checks, while observables have to bubble up and keep track of their relations.
You also seem to agree now that both are completely different.
That's not MVC. That's the MVC Facebook attempts to show in a ridiculous presentation that finally convinced me how much they had to misinform to get these silly concepts any legitimacy.
See the wider picture, how flexible they are and how fast they grow. Their freedom in making things possible that would be very hard to realize.
The shell that i'm using for instance, Hyperterm, it does things no other shell can do, and they had more than a decade to evolve. JS doesn't have a problem displaying json as json, display webpages on link clicks, moving up git logs with my trackpad, adding tabs with a plugin that contains a few lines of code and a little css, ... it just comes easy to JS.
The same flexibility you see in Atom, VSC and the others.
> JS doesn't have a problem displaying json as json...
You know what else doesn't have a problem doing this? Literally any other programming language or tool that I've ever used to look at/edit Json.
> Hyperterm, it does things no other shell can do...display webpages on link clicks moving up git logs with my trackpad, adding tabs with a plugin that contains a few lines of code and a little css, ... it just comes easy to JS....
Any pretty much any other terminal built with flexibility and extensibility in mind (even the base terminal in Linux can handle links lol, that's definitely not exclusive to js). ZSH springs to mind, with the benefit of being written in Case, so that you know, it's actually fast...
> The same flexibility you see in Atom, VSC and the others.
Ah yes, including the freedom to not open any binary file, or any file >2mb in size!
> 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.
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.
> these technologies aren't even close to what you have available on the web
Yeah, they're that much better, that we grumpy old non-JS programmers keep wondering what the big deal is when somebody comes along and rewrites something that existed 20 years ago.
That isn't the point. JS does something the others can't. It has flexibility and a community that's larger than anything you know plain and simple. Btw, i am a grumpy non JS developer, or used to be. Started with assembler, c/c++, then c#. That sums up most of my professional career. I was wrong judging JS too fast, that's all i'm saying. Many of my colleagues are still grumpy about it, they'll get over it over stay behind. If they do move on they will see what they're missing soon enough.
There have been so many desktop apps released since 2007-2012 that I really don't know where to start:
- Everything GNOME does
- Everything MS does
- Everything KDE does
- All the apps in Mac OS
- Every browser
- Emulators
- Office suites
- Messaging apps
- Adobe's Creative Suite
- Blender
- All the content creation apps for video games
- Video games
- Editors
- IDEs
- Audio production suites
Web developers are excited about the desktop again, because to them the desktop is some kind of new frontier that Electron has opened up to them. I get that, but please be aware that just because something is new to you doesn't mean it's actually new.
> 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 fresh air compared HTML/CSS/JS. It may not be proper "native" development, but I don't have to deal with <div> hell. It has proper layout management instead of, what, 4 quirky CSS layout styles: float, table-, flex-, and now grid-. Sure if you want to hack something together, Electron may be quicker short term. But I question if it will actually be cheaper in the long run for non-trivial applications.
> It may not be proper "native" development, but I don't have to deal with <div> 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 SWT when it's really primarily the plugin architecture that's responsible. And I actually find the more spartan developer interface to be more pleasant than Swing, so to me it's win-win. Swing will always have an uncanny valley, SWT has never had that issue, yet still allows you to write for the desktop in only Java.
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.
Thanks for the tip. I'll have to look into SWT. I only chose Swing because it was included by default, but I would prefer to have the actual native look on each OS.
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 people aren't crying out for decent layout management for the web - is it just lack of awareness of how good things could be, or...?
> 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.
Can't help thinking that Visual Basic had a better layout manager than CSS. I hate fixing CSS issues with a passion. I watch a designer whip up something in Illustrator and can't help thinking that CSS & HTML are a primitive way to do layouts.
Smalltalk had a GUI based approach to design in the 70s on a 2 mb disk, and most web layout is generating html & css, then tweaking that stuff. It doesn't feel like web layout is a progression.
Interestingly, Visual Basic did it all with absolute (pixel-by-pixel) positioning. Some (not all, but some) of the issue is that we have moved forward in what we expect out of UIs.
(The rest, of course, is that the Web front-end is a shitshow of epic proportions)
The largest barrier to good layout on the web is that you can't measure text. All you can do is measure a node that has a specific text, which takes a long time and includes a reflow, which means either a) abysmal performance, or b) an entirely async layout algorithm, which would be much more complicated.
Java isn't new and shiny anymore. Having been around for the great Java hype of the 90s, it's crazy that Javascript has now replaced it. Nobody would have predicted that back then.
I really hate Netscape & Sun for causing that confusion, and making Javascript look like Java on the surface, particularly as it obscured the prototypal model of JS and made anonymous functions clunky until the arrow functions of ES6. But it was good marketing.
If, instead of Swing, you use JavaFx (which comes included with Java) your UI will look nicer. It even has an embedded Webkit browser that can easily interact with JVM code. This means you can program your UI in any HTML/CSS/JS framework you want, and any other logic in any JVM language (Java, Scala, Groovy, Clojure, Kotlin, Ceylon, Frege, etc.)
I can't speak for large companies trying to make the call on Electron versus multiple OS-specific apps, but for indie devs this is absolutely critical.
Imagine being a small shop of 1 person (or even 5) and having to learn desktop programming languages, conventions, and native APIs for the web, Mac, Windows, and Linux. Then on top of that to develop and maintain a product that moves at the pace of customer feedback.
That's why Electron is powerful. I could not write and maintain the Hemingway App for Mac and Windows without Electron. My tens of thousands of users would not get to use that software _at all_.
Off topic but I just checked out your app. Very clever! I'd love to see a world where it is integrated tightly with iOS. Writing concisely is especially useful on mobile. Also I dig the demo. Great example of why developing electron apps can be really beneficial.
Thanks for your insight. The part that confuses me as a non-native developer is the folks in this thread who seem to be implying that there are only marginal amounts of additional time needed to release cross platform, fully native apps.
I think the implication is as much that developers who label themselves like you have as "non-native" or "JS" or "web" developers don't have the perspective to make an informed decision on the matter.
Many of the rest of us know how to build React SPAs (and have been doing it long enough to have used Angular 1, Backbone, Sproutcore, ...) but "JS + Framework of the Week" is just one of the many tools we could turn to when building a UI. Many of us have also used cross-platform native libraries like QT or GTK, or platform-specific toolkits like Cocoa or .NET.
Basically, if the only tool you have is a hammer... it might be time to learn to use some new tools.
Are you saying that building a web version and two (or five) native versions of an application is equivalent to building a single JS codebase and having it just run? It certainly sounds wonderful to learn new tools, but how does that stack up from the engineering (cost-benefit) side?
> 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 know", which probably says more about your social circle.
One more "Big Deal" is that both Chrome and Electron are not accessible by default like native apps and take performance hits when VoiceOver is enabled.
I'm not "excited" that macOS is flooded with apps that have poor accessibility experience while Apple itself is fanatical about delivering first-class accessibility experience - like Safari having accessibility always enabled.
The other thing I find ionic about this whole article is that it's perfectly easy to only use Slack within Chrome as a normal web app. And the UI is almost exactly the same because it's nearly all the same code.
So if the Electron bloat is such as issue for you, just hit Slack in the web directly.
>So if the Electron bloat is such as issue for you, just hit Slack in the web directly.
That's even more horrible, i've tried it. Chrome uses his own notifications on macOS instead of integrating with systems notification manager and always when one of these ugly, poor animated guys pops up, i can search through my 100 open browser tabs to find the damn chat. Millions of flamewars were fought about what's the best window manager and we are ending up with a single window with a tabbar? Are you kids serious?
So just run it in a dedicated chrome window so you can alt+tab to it directly?
This was the main reason I used the electron version of slack and tbh it makes little difference if I run a dedicated Firefox window or the app since my laptop is less than a year old and could run a few hundred instances of either without sweating..
I have Canary installed for this very reason. My mail app, Slack, Jira and any 'productivity' sites live on that, whilst everything else stays on good old Chrome. Switching from one context to another then becomes very straightforward.
Safari just doesn't work for me.
It's my favorite browser ui wise, every time i'm getting a new machine i first stick with safari, but after a while under heavy use i notice all the problems with Safari getting slow, doing weird things, etc and i find myself on the Chrome download page again :(
While I was on mac i got an extra few hours of battery life from using safari.
I'm on Firefox these days; with noscript (once you go through the initial few days of pain whitelisting things) it works brilliantly; I would suggest you give it another chance..
Unless you try to book flights from britishairways though.
People are making all kinds of great new apps, and more often than not, they come out on all three platforms. People are excited about the Desktop again...
You could have expressed pretty much the same sentiment about Java ~20 years ago. The trade-offs (high resource consumption, additional complexity, but less demanding of developer time) and even the fundamentals of the approach (an additional abstraction layer that works as a VM, APIs oriented around all the latest thinking) were also very similar.
Java is used for a lot of things, but mostly not as the basis of mass-market cross-platform applications the way it was originally intended.
> 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".
This comment is completely wrong. You know what Slack was before it was an Electron app? It was a Cocoa app. Sure, it wrapped a WebView, but given Slack's nature that's not a surprise. Regardless, the Cocoa Slack app, while not great, was still much better than the Electron crap we have now.
I don't know if you're simply ignorant of the fact that the app this article is focused on actually was a native desktop app before it switched to Electron, or if you're just ignoring that pretty important information in order to try and make your point, regardless of whether or not it's true.
Oh interesting. So why'd they even try to make the argument at all? Are they a new hire and simply aren't aware that Slack had a native app until recently?
What? Qt is very popular and I use several Qt apps. Same for GTK. And there is MUCH more desktop software out there than functional web apps. I don't know what kind of Windows 10 fantasy land you live in but there has long been an answer to desktop apps.
What Electron has done is allow people with a particular skillset to apply it to a domain where it is both unnecessary and wasteful. These "developers" would be better off generalizing their understanding of software and UI design to the point where the tools used are irrelevant
> finding specialist developers who know these dated technologies
WPF is newer than Javascript and the DOM. Using native desktop GUI frameworks isn't some sort of ancient dark art. It's easier than web development!
>if its massive "Beatles walking off the plane" moment hasn't happened by then, sorry, it's not gonna.
The same thing applies to the quality and performance of javascript apps. Decent performance and feature parity is always just about to happen when the next iteration of the standards is implemented, but it never arrives.
Wasn't this basically true of Java in 1995? Everyone was excited about finally being able to easily write cross platform apps. And then there was flash that anyone willing to pay for the designer could build apps that could run on any platform. So now we're on to the third 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".
Agree fully with this. I find the complaints about how appalling it is that apps use a few extra 100MB of RAM and disk space really tiresome and impractical when laptops + desktops typically have lots of RAM and disk space now. Many of these cross platform apps either wouldn't exist or would exist on only one platform if everyone insisted on native apps especially for apps made my small teams or individuals.
I'm not saying Electron is perfect but easy cross platform support is a huge benefit and one of many. You also have the huge JavaScript community, pool of developers and available libraries to draw from as well as being able to share code between your desktop app and web app. Tossing that all away to save resources that most users aren't even going to notice isn't a good business decision in my opinion.
"Everyone has Jesus of memory, or doesn't matter if we chew through a bunch of it because we were to lazy to use the right tool for the job".
Just because it's there doesn't mean you need to use it all, that's like spending your whole paycheck at once because "you'll get another one in 2 weeks!".
Any application that does the same job with less resources and the same or greater performance is unequivocally, objectively better.
Also, benefits of claims like easier and faster updated are rendered pretty moot when developers next spend that time changing things for the sake of it: Spotify app feels like it has since pointless, un-requested UI change every month. And VSCode can't even update Idle, decor that being one of the lauded benefits...
> 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
What are you basing this on? There are plenty of iOS developers, and developing for Mac vs iOS is more similar than pretty much any two other dev platforms you can name.
The weird thing is I'm almost certain you can build the exact same thing with e.g. python+Qt, do literally all the drawing using python code in custom widgets, and the result would still be nicer to use than the status quo. I'm not advocating switching to the PyQt stack, I just want the electron stack to be saner, in particular
1) Electron is obviously a system library now. Treat it as such. Install ONE copy of electron per version, not ten private copies of electron in npm. It should be simple to integrate with at least Windows and OSX install systems - instead of downloading the full electron module, download an installer that installs the required version system-wide. This can be done as a step during installation like desktop programs have been installing required dependencies since the dawn of time.
2) Find some way to make it slimmer. Maybe not every app needs the entirety of the browser loaded. Maybe we can do lazy loading of certain components? Maybe optimise the most used critical paths, and provide tools to developers (if those don't already exist) to show exactly what is causing all those wakeups?
Moving off Electron is not an option any more, it's just such an easy and familiar platform to develop for, it's not going anywhere. Maybe we should accept it as the victor of the cross-platform desktop application toolkit and work to make it better. It's shitty, but it's the right kind of easy, like PHP.
I agree and the author fails to mention the tradeoff between ram/diskspace and development time.
>>all you web devs: Go learn C or Rust or something. Your program runs on a computer.
I don't think that is a realistic request.
When the cost of Slack's ram/diskspace usage starts affecting their profit then they can/will take steps to re-write the application in 'native' code. Until then its premature optimization?
C is not that hard! If you're a programmer, and you don't know C, you're not good at your craft. I realize that sounds incredibly harsh but it's true: your job is to make a computer do a task efficiently. If you can't even read the language that makes that possible, you don't know what you're doing.
I could re-write your argument by replacing "C" with "x86 assembler" - but I won't. However, the argument could still stand, but I'd hesitate at saying it's a wholly valid argument.
My own prejudice aside - I honestly do think that if you don't have an understanding of how a CPU works at this very low level - maybe even lower - you don't know what you're doing; that, and I have done hand-assembled x86, 6502, and 6809 code in the past...
It's a different time; knowledge of lower level languages isn't needed today to be a successful software developer who knows their craft. And I recognize my prejudices as such, thus while I tell them, I understand that they really can't apply. Would I like it if these new guys all knew this kind of stuff? Well - yeah; but the same could be said of me by guys long gone and dead as to why I don't know how to wire up an analogue computer to solve a calculus problem, or why I can't wire up a plugboard to compute something on a IBM 401 or such. That doesn't make them a better developer, nor me or anyone else a worse one. We're just using different technologies.
That said, I do think developers should branch out, and at least have an understanding of other languages; maybe C/C++ - but even Java, Python, GoLang, Rust, etc - all could be just as useful to know.
Today - career-wise - I am a javascript/node.js developer - before that, I mainly used PHP. At home, I play with Perl, C/C++, and Python (these latter two more recently being involved in machine learning, TensorFlow, and Keras). Occasionally, I'll get a bit nostalgic and break out BASIC (my favorite today is QB64). Can't say I've done any recent assembler coding - but it doesn't scare me, either. Just another way of communicating with the machine.
I get that everyone has their specialty -- Im not trying to imply that someone that writes javascript for a living is a lesser coder or everything should be native. My point is that there are fundamentals to this craft, and all these web developers acting like C is exotic knowledge baffles me. With regard to your first point though, I actually do think knowing some form of assembly is also super useful. I just tend to focus on C since as is well known, its basically portable assembly.
>If you're a programmer, and you don't know C, you're not good at your craft.
Even as someone myself who knows (more or less) C, this is quite an elitist statement, and doesn't do justice to say, Lisp and people who use functional languages. The goal of programming isn't necessarily efficiency.
How is expecting competency elitist? Theres plenty of free resources to learn C. I learned C when I was 14.
Im not trying to claim low level knowledge of the machine is inherently better than high level knowlege. What I am claiming is you need both and knowing how this stuff works isnt a charming novelty reserved for the curious
Premature optimization used to mean optimizing something that doesn't cause any noticeable performance degradation.
I think it's a mistake to redefine it as optimization that doesn't affect profits. Companies often get away with painfully broken software for a long time because they benefit from some other moat (e.g banks). But they're setting themselves up for disruption by doing that.
Also, profits are not the only purpose in life if you value your craft. (I'm not denying that you have to be able to afford high standards and economics does play a legitimate role)
Hm? How come? Is there a mental barrier here that I'm not understanding? (C and Rust are "hard" languages?) I taught myself to code on my parents' hand-me-down Pentium 100Mhz in the early 2000s, and I started with the K&R C book. Python and C were my swiss army knives at the time. I really can't see this stuff being super difficult, I mean I was a teenager and I had no understanding of algorithms.
Why would native apps be so expensive? Are they 10x slower to write? Isn't the tooling etc for making a WPF app at least as good as it is for electron? Obviously if you have a web app or node backend already you might have code you can re use but that's not the case generally.
Just being able to not use Js should be a pretty big win (although .ts is also available for electron I suppose). Not to mention that libraries etc are specifically created for desktop and not web (e.g the xaml layout model vs the DOM). Or are they expensive because traditional desktop devs are hard to find and/or cost more?
I think it's sad that both Apple and Microsoft dropped the ball on desktop because they are only focusing on funneling users to their stores. If the Microsoft of 2017 (with open source .NET and Linux as a focus) had been around a few years ago when WPF was invented, they could have made a decent cross platform toolkit now that didn't come from html/CSS/js
If more developers had a second look at FreePascal/Lazarus [1], they'd realize they could do pretty much the same thing, but with native compiled speed, minimal memory usage (no bundled JREs) on all the desktop platforms.
It's graphical GUI builder is out of this world, and it works flawlessly on all three desktop platforms. It did even compile without a single code change on windows, after I finished coding in ubuntu, a utility tool for some researchers in my organization [2].
And about the language ... I finished my utility tool project in 80 hours, from initial concept to happy customer, while learning the language in the process.
It is really such a shame that people have so strong aversions against Pascal, for no good reason other than subjective feelings.
Bologna: nothing truly performant uses Javascript because Javascript can't get at hardware accelerators in their full glory. Apple's macOS and iOS are themselves desktop apps, in the latter case for a pocketable desktop, and they resolutely don't rely on the very constrained subset of 50 years of engineering called Javascript.
Have you seen how many messages you can pump through and transform on a node process? Yes, there is an abstraction and that's a cost, but v8 perfomance is "good enough" for almost everything.
Maybe not a coin miner or a graphics engine; but cpu is never really the constraint for applications such as those inside electron containers. Where you see them chewing 100% of a core, those are bugs.
Also, while th e language has flaws modern; JS vms are pretty bleeding edge....
Who gives a shit. The point of writing natives apps isn't just to check it off your bucket list - natives apps can have advantages over web apps if done right. Those advantages include better performance, integration with native UI components, integration with native APIs, and integration with the file system. The only one a "native" electron app can accomplish that a web app can't is the last one. If your app doesn't require integration with the file system beyond a file selector then an electron app offers no benefit AFAIK. Companies do it purely so they can tell everyone they have a native app without having to invest the work required to get a real native app. My suggestion for the author is to find a browser they like, and then run all electron apps as web apps within the browser whenever possible.
> Nobody in the last 5-10 years cared about writing Desktop apps before Electron came along
What?... Are you saying what I think you're saying. I must be reading this wrong because surely you don't wish to imply that people didn't write desktop software before Electron came along?
What about NW.js, It's the real hero here. They spent 5 years building up the platform, being used by thousands of companies and apps, basically inventing this technology; just to have GitHub buy up their intern and pay him to make a shitty knockoff called "atom-shell". You're excited because someone tossed a marketing department at a shitty knockoff?
NW.js uses less resources (less ram, smaller distribution sizes).
It is updated more often (within 24 hours of every Chromium and Node.js release, ensuring access to latest technology).
It supports about twice as many OS's (XP+, OSX 10.6+, Debian 8, Ubuntu 10+). Electron doesn't even care enough about Linux to merge in simple bug fixes.
It's much easier to get started with and takes a no-nonsense approach to everything. (thejaredwilcurt.github.io/website/quickstart.html)
Allows for HTML or JS entry for apps.
It offers actual source code protection, and even recently updated this so that there is no longer a performance hit when using it. Which is a pretty serious technical achievement.
The only thing wrong with it is that it's got a shitty name/logo, and has a smaller ecosystem. If you can get passed that you will have a much nicer experience.
How many electron apps can run on the same machine? For many of them it can be beneficial to just be a website.
Wouldn't it make sense to run a caching proxy on desktop and use a browser that is already there? That way you could still use some functionality not available to plain websites, like access to computer. But use system browser for rendering. Your proxy would also cache your website so it would run faster than normal website.
I understand, that this way you have to support more browsers, but you probably already have a web version of your app.
The problem could be with users seeing localhost address. How to overcome this issue? Virtual interface on which DNS server could run?
Maybe running from a file:// could be a solution for some apps?
Nice rant, can you name at least one of those mind-blowing apps that happens to be sold for real money?
Everyone in the last 40 years built and sold a multitude of destkop apps and they never stopped. Stop drinking the cool aid, and even if some bozo upvotes you on hackernews it does not mean that you are right (actually nowadays the opposite is more probable).
Completely agree. I simply have no interest in learning any native desktop programming and if I did it would be for my platform only and I wouldn't waste my time writing it for linux and definitely not for windows. I'd release what I had on github and move on. Now I can throw together a small (small by custom code sizes, I know electron is heavy) amount of code and get a cross platform app that doesn't look terrible in relatively short time. I think it's a great first step for a PoC. If it gains enough interest AND (<- big and) you NEED to go native for some reason you can go native later. There are a lot of things you can say bad about electron, yes it's heavy and "bloated" for most uses of it, but if people think empowering others to build things they couldn't or wouldn't before is bad because of how they built it then they are already a lost cause and probably think we should all be writing assembly still.
> I simply have no interest in learning any native
> […] programming
And it is amazing to see how many bad reinventions of the wheel happens because of this.
People claiming that writing electron app is 10x faster than native have absolutely no idea what they are talking about. The only think web-based tech will give you is ability to push out raw cross-platform prototype. Now try to polish that to the acceptable quality across the platforms and the many wins start to turn into loses.
I am a web developer, I know that might be a dirty title in some circle but I really don't care. There are countless amazing things built on technology that people hate for whatever reason. PHP, JavaScript, and even Flash comes to mind. Guess what wins in the end? The thing that gets the job done quickest and easiest. It's one thing I really dislike about HN, the need to let everyone else know how terrible their decisions are because they didn't go as low level as the person posting the comment. "Oh you used PHP? Real programmers use C++" "Oh you used C++? Real programmers use C" "Oh you used C? Real programmers use assembly" "Oh you used assembly on a CPU? Real programmers design and build their own FPGA's for their code". Nothing is forcing you to use things built in electron so if it's so terrible then don't use it and move on with your life.
A better alternative is actually making a web app, and ship the server together with the client, for example a Node.JS script that does the stuff not supported by the browser, and runs the default browser for the graphical user interface.
Does the weight of these just irritate you because of how wasteful it is (it irritates me for this reason alone) or does it actually have an impact on you?
People said the same things about gtk or qt when we had motif right? Apps are going to keep getting bigger, our machines get bigger too. I'm not sure what he problem is.
I think I'd like to do more with my machine as it's getting bigger and faster, not the same things from 10 years ago that now hog all of my excess. I have twice the cores, four times the RAM and an order of magnitude more disk space to play with than 2007, I don't think it's acceptable to just have applications take up an extra thread, twice the RAM and more GBs just because it's free; that hardware certainly wasn't free when I bought it.
or, you know, a chrome app which works exactly like an electron app except they don't all require their own separate chrome instance. I mean an electron app is literally just a chrome app packaged with its own version of chrome.
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.
Here's the thing. You know what the alternative to all of the JS that's been written? If your answer is "Keep writing more JS," then you are on another planet. The answer is, "We have fucked ourselves as an ecosystem by permitting a monoculture to flourish, especially one which prides itself on worship of bad languages, bloated runtimes, convoluted abstractions, and general fuckery."
Nobody in the last ~20 years has cared about writing Web apps before JS came along. There's basically zero money in it, and it's massively expensive, both in terms of actual development time per feature (easily 10x the cost of working in sane languages with sane runtimes), and also in finding trendy hipsters who don't know algorithms or data structures but took four weeks of coding academy classes a couple years ago. And as for Electron, Electron has existed for over three decades (Project Athena launched in 1983) -- if its massive "Nixon throwing the peace signs before getting on the plane" moment hasn't happened by then, sorry, but it's not going to happen.
But now? People are making all kinds of great new languages, and more often than not, they don't repeat JS's mistakes. People are excited about programming again -- JS is so bad that it's single-handedly revitalizing interest in languages which two of the largest tech companies in the world are behind, yet couldn't make popular.
This is a Big Deal.
(You are being parodied mostly for being a Slack developer, not disclosing it up front, and then trying to convince folks that Electron is good, which makes you sound a lot like a pig farmer trying to sell pigs' feet.)
Desktop apps like Word, Excel, Powerpoint, Photoshop? I too can pick a few ridiculous outliers. Honestly I'm not sure if you're right or wrong but either way that argument isn't good.
You have it exactly backwards. JS succeeded because it's not a monoculture. Within JavaScript there are multiple frameworks, even multiple languages (CoffeeScript, TypeScript, ES6, etc).
Win32, Java, MacOS, et al lost because there were such strong standards for doing things the One True Way that competing standards couldn't flourish and the APIs stagnated.
In JavaScript, a new framework comes out every year and goes straight at the throat of the old one. The reason there is churn is because these new frameworks are actually solving problems better than the old ones, and because of the LACK of a monoculture developers will actually switch to them. Which in turn is why framework designers are drawn to it, which in turn leads to more new frameworks.
Is iOS solving problems better today than they were last year? Or in 2015? Because JavaScript is solving problems way better this year than last.
JavaScript frameworks are ultimately solving problems that the Web/DOM/JavaScript infrastructure created in the first place. The amount of technology required to create a single page application is staggering yet on the desktop that's just "an application". The technology has been around for 20 years and we're just getting to point in JavaScript where we were 20 years ago.
Yes, of course JavaScript has made tradeoffs to get where it is. Those seem like problems in isolation, but look what we got in exchange:
- apps from untrusted developers can be run safely
- app installs are measured in milliseconds and don't require switching windows
- app updates are invisible to the user
- beginners can modify apps without leaving the app itself (MySpace profiles, etc)
- references deep inside one app can be embedded in another
- apps run on nearly every device from one codebase
Native app programming can do many things well, but failing on these counts is a deal breaker for many purposes. You act like JavaScript's weaknesses are somehow due to ignorance on our part, but they are tradeoffs made deliberately.
And for the most part, the things JavaScript is bad at (high performance graphics, professional ergonomics, etc) are things that are improving. I don't see native apps getting millisecond installs any time soon. It's a classic disruptive technology.
>But now? People are making all kinds of great new apps, and more often than not, they come out on all three platforms. People are excited about the Desktop again - Electron is so good it's single-handedly revitalizing the platform that two of the largest tech companies in the world are behind, yet couldn't do.
>xpaulbettsx: JavaScript Hacker at Slack
Ah, yes, we are all grateful for Slack's 850MB of memory used when idle.
I can live without it, personally. Actually, if it could crawl back into whatever hole it came from, I'd be glad.
Electron isn't good. Electron is absolutely awful. Web applications aren't good. Javascript isn't good.
At what point of dementia do you say "hey, web APIs are easier to use, let's bring the entire damn browser along with it!"? The normal reaction should be fixing current APIs, making good wrappers around them.
One of these days, you'll look at 850 MB of RAM like I used to see 4K of RAM: Amazed at how small it was, and how much we have today.
My first computer saved data to a cassette tape; today, terabyte hard drives are nearly give-away prizes in cereal boxes (yeah, I know they don't do that anymore, either). We have machines in our pockets which are arguably (in some ways) more powerful than the machines only government-funded agencies and such could afford when I was a kid (and they took up entire rooms).
I hope I live long enough to think of 850 MB as a small amount of memory (and 8-cores at 4 GHz each a slow machine; actually, there are some multi-cpu server mobos I'd love to have as a desktop, but I can't afford it - yet).
Honestly, I'm amazed that we do have enough memory to support these huge apps. Sure they're bloated; I won't argue that - but at the same time its amazing that we can run them at all - a decade ago it would have seemed ludicrous!
Could it be better? Sure - but in my mind, all software is bloated - because even the simplest piece of compiled code I can't run on my old TRS-80 from when I was a kid (heck, even an Arduino has better specs!).
Desktop development has stagnated because of the proliferation of web technologies, not because desktop frameworks aren't very good. Qt is great, gtk is great, hell, with the right configuration, working with WinForms can be pleasant.
Electron packs a browser with each app, and that's unacceptable. Adobe used to have something called AIR, years before electron, but idk if they were just packing up a browser or not. I used to use the desktop version of tweetdeck, which used AIR, and it was pretty damn fast.
Anyways, you clearly don't know anything about desktop development, so rather than make claims that are wrong, just stick to what you DO know.
It is good that there is a nice cross platform 'thing' you can use to make desktop apps. But it would be better if the best thing that existed for this wasn't so slow.
Perhaps someone can clone the outward api of electron with only a ~10% performance penalty instead of Two orders of magnitude
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 control on memory. Write it in Java.
Eventually people want to solve a problem with the best ratio cost/quality for them, not "doing it the proper way".
So unless you provide a better solution for them to do that, or pay big money to create such solution, they will find the ugly-hackish-half-baked-working-for-them solution that let them do this.
We had PHP. Now we have JS.
I hate it. You hate it. We all hate it.
But I created portable GUI apps with an installer before in my favorite language and others and it was a pain. All of it. The UI, the event model, the API, the portability edge cases, the new stuff to learn, the packaging, the dependencies...
It sucked.
So get over it or provide a solution, but stop complaining.
And before you start providing an EXISTING solution, remember people tried it and they didn't like it as much as electron. And since electron is so bad, that should tell you something.
So the market is saying you are wrong. You can ignore it from your better tech tower... Try to boycott electron apps all you want. But we know how it has played for betamax, lisp and the ogg format.
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. Don't. Care. We only manage to kill it because we finally replaced it with systems that could compete on easiness and features. So you know what to do.
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 can ramp up quickly in a productive language like Python and then stabilize on a more efficient language like Java. New platforms like Go/Swift/Kotlin are trying to get in this sweet spot (and mostly succeeding), and existing platforms are trying to inch closer towards it (Python/JS with performance and Java/C#/C++ with ease-of-use features) to avoid the "do over"
> And before you start providing an EXISTING solution, remember people tried it and they didn't like it as much as electron. And since electron is so bad, that should tell you something.
I doubt everyone who's built a desktop in Electron tested Qt first. Definitely not in C++, but probably not even in QML or Go.
> People. Don't. Care.
People absolutely care, they're just not software engineers so they can't articulate precisely what they care about. It's like you never heard someone complain about shit battery life, unresponsive web pages and apps, or slowness in general.
Most of these Electron apps work in network effects. People have Spotify because their friends have Spotify; people have Slack because their work uses Slack; essentially people are generally saddled with your app for non-technical reasons. But that should be an argument for giving them good tech, not an excuse for giving them bad tech. "Well, you'd have to use this anyway so I can get away with burning through your battery life and you'd still count towards my usage numbers". Ick.
I guess I don't know what your point is then. Isn't your argument: "progress means taking advantage of hardware advances to use more productive tools?"
I disagree with your assertion, because I don't think the only measure of progress is how productive programmers are (time-to-market, whatever). There are other measures:
- user experience
- program efficiency (battery life, fossil fuels burned)
- program security
- ease of contribution, maintenance, and improvement
I mean, correct me if I'm wrong. But I feel like I've directly addressed your points. I simply don't think that you can say, "well it's X% faster to build an app on Electron, therefore Electron is the best... even though it runs Y% slower and burns Z% more battery". That's why I talked a lot about tradeoffs, because there's more than one issue.
For what it's worth, I also dispute the productivity argument. It's hilariously easy to build an app in Qt Creator. Maybe web devs can build Electron apps faster, but that's because they're web devs. I'd bet if a web dev took a month to get to know Qt they'd be as productive. The difference is that the resulting app would be a lot more efficient.
No, my point is people will use anything that allow them to do what they want the easiest way possible, not matter the cost and cleaness.
The point is the web is the most active platform.
The point is doing things right is not winning.
The reason you are missing the point is that you think it's only a technical problem.
It is not. It's technical + cultural + societal + historical + economical.
> It's hilariously easy to build an app in Qt Creator.
You fail to put yourself in a web dev shoes:
- they are the majority on the most popular plateform
- they don't have the time to lear a hole new tech or API. You don't realize the ton of stuff you need to learn to do half of what you can do with HTML + CSS + JS with QT. It's huge.
- then you have to learn all the edge cases for packaging, distributing, updating and maintaining this software. On multiple OS.
- then if you need a tutorial or a doc to help you, how does it compare to the web stack ?
- then if you need to have new people added to the team ?
- then if you need a custom widget ? reuse something that has been done ?
- then the licence ? The versions conflicts ?
And if only QT was much easier than the web stack. But as a Python dev, I did PyQT dev. And Web dev. And the ratio power/easiness/flexibility is not on QT side at all, it's a mess of a badly documented powerhouse with abstractions everywhere. You want to get the value of a cell in a table as a date ? Unwrap 3 layers of composed classes, each of them with their own API.
Then of course you will end up creating a client/server architecture (with threads, multiprocessing or else) for your app eventually to deal with background tasks, an MVC layer on top of QT's, and then some DB for persistance. And use their markup to generate the UI in a declarative way.
So basically all what constitute a web app.
Basically, you have to put all that in the balance VS speed, memory and battery life. What do you think won ?
If we want native clean apps back in the game, we need to make it easy and convenient for the new generation of devs to provide the features the new generation of users want.
Otherwise, we have lost and we'll be dinosaurs, while people will just buy more powerful computers because "32gb of ram is not enough to display all those albums, you need to upgrade".
Thanks for clarifying :) You're right, I missed the point.
> people will use anything that allow them to do what they want the easiest way possible, not matter the cost and cleaness.
I disagree, because people are implementing things in Rust right now even though it's harder than doing it in JS. Generally, they do that because they care about things like performance, safety, and maintainability. For them, "harder" is a broader term than just, "I wrote this quickly", because they factor in things like bugs and performance.
> The reason you are missing the point is that you think it's only a technical problem.
> It is not. It's technical + cultural + societal + historical + economical.
I do not believe these problems are only technical, which is actually why I feel so strongly about this topic in particular. There's a certain level of "I know this is bad, but [my boss told me to do it]/[I have a deadline]/[competitor X is right on our heels]" in tech right now. No other serious profession acts this way. Doctors don't say, "I know this surgery is wildly unsafe, but my chief told me to do it, so if people die oh well, it's not my fault". They have professional organizations and laws to back them up, and maybe more than that they have professional ethics and pride too. I'm not trying to say all doctors/lawyers/etc. are perfect, nor am I saying devs are bereft of ethics, but software engineers need to realize that our work is shaping society in a fundamental way. We need to start sticking to our ethics, our judgement, and our values when faced with economic or cultural pressure, because there are more important things than shipping and making money.
In particular, we need to start taking security seriously. Starting an app in C/C++ should mean 100% test coverage, thorough fuzzing, and pervasive use of tooling to avoid security issues, and honestly it's better to use a memory-safe language like Go/Swift/Rust/Java/C#/Kotlin whenever possible.
We need to take performance seriously. Our code takes electricity, and we mostly still get electricity from fossil fuels. I'm not trying to dip into moral hyperbole by arguing that the cursor in Atom is causing future famines, but we need to realize that performance isn't some nebulous concept. Slow code costs money and burns things in real life.
We need to take user experience seriously. PGP is the poster child for this, but this concept exists elsewhere too: the best security software is the security software you use (the best exercise is the exercise you do, etc.). It doesn't matter if you built the perfect programming language if it's too opaque, it doesn't matter if you built a decentralized Facebook if users don't use it.
We need to consider that not everyone has fast computers, fast phones, and fast, low latency, ubiquitous Internet access.
We need to say no to addictive features and dark patterns. A lot of the reason the web is a cesspool is that we've allowed companies to build products that are addictive, or that are very difficult to get out of. Good luck building an open Facebook; they have huge teams of people working on ways to keep people on their site forever.
We need to push back on closed-source. Tech has boomed in the last 10-20 years because of FOSS. Linux is the leading server and mobile platform. Security research is where it is because of FOSS projects like OpenBSD. Practically all of our development tools are free software. Our web servers, our browsers, our JS engines, our UI toolkits, that's right, it's all FOSS. If you want an example of what happens without FOSS, look at the state of messaging.
> You don't realize the ton of stuff you need to learn to do half of what you can do with HTML + CSS + JS with QT. It's huge.
Having done both, I do. I prefer Qt because I can use pretty much any language I want, Qt Creator is great, and I have better tooling in general. Web dev requires JavaScript and a bananas toolchain, neither of which I'm a fan of.
You act as though web dev is the easiest thing in the world, but just look around for JavaScript fatigue posts. All the toolchain stuff you have to set up, all the library/framework decisions you have to make, all the knowledge about the DOM, Babel, ES2017, CSS quirks, blah blah blah. It's "easy" (kind of) for web devs because they've been doing it for a while, but it's definitely not prima facie easy.
> they don't have the time to lear a hole new tech or API.
They absolutely do, and if their jobs don't give them time for professional development they should find ones that do. Lots of professions get this, nurses, teachers, attorneys, managers. This is in line with my "professional standards" rant above.
> - then you have to learn all the edge cases for packaging, distributing, updating and maintaining this software. On multiple OS.
> - then if you need a tutorial or a doc to help you, how does it compare to the web stack ?
> - then if you need to have new people added to the team ?
> - then if you need a custom widget ? reuse something that has been done ?
> - then the licence ? The versions conflicts ?
I guess just look at Qt projects like Telegram Desktop. Hey look they managed to distribute their code. Hey look custom widgets. Hey look, a lot of people worked on it. Or even stuff like GitHub Desktop written using WPF. Or major desktop apps like Photoshop, Nuendo, etc.
The Qt license comes up all the time, and it's seriously just don't link your app statically. Or advocate for your product to be open source. Or just Google LGPL.
> If we want native clean apps back in the game, we need to make it easy and convenient for the new generation of devs to provide the features the new generation of users want.
I view this from the "professional standards" perspective as well. I don't need to change my values and prioritize developer productivity above everything else, in fact I think that's disasterous. Instead, I think we need to advocate our values to "the new generation of devs": be willing to learn new things, take responsibility for the major role your work plays in society, realize none of this would be possible without FOSS, and consider that "better" doesn't just mean "I shipped faster".
> Otherwise, we have lost and we'll be dinosaurs, while people will just buy more powerful computers because "32gb of ram is not enough to display all those albums, you need to upgrade".
Re-reading your posts, I kind of get the feeling we're on the same side. While I think it's important to create a better culture in software dev, I also think it's probably just as important to make it easy to write a program "the right way". Right now, it's just way, way too hard.
I kind of blame Electron for making it easy. It's sort of a trick right, "hey, I don't know what those C++ people are doing, just use JS, it's super easy". I don't necessarily think projects should post a table of pros and cons of their software -- there's definitely a certain level of "do your homework" involved -- but I do think some level of self-awareness is warranted. Think of SQLite's "Appropriate Uses For SQLite" page.
> If we want native clean apps back in the game, we need to make it easy and convenient for the new generation of devs to provide the features the new generation of users want.
Yeah, thinking about it a little more, I super agree. I don't think we should compromise all our values, but we definitely need to spend some time making software dev a lot easier.
I don't think there are many people in the industry who are in denial (though I am known to over-estimate the average Homo Sapiens' abilities).
The reality is already well-acknowledged. What would you do next? Surely, trying to beat people's faces in this reality via your 10+ comments in this thread isn't a next step, more like infinite repeating of the acknowledging part.
I'd definitely volunteer to make Qt more dev-friendly. As it is though, I am too late because my personal life and health are in a dire need of attention and money. So I'll sadly leave it to others. But if these others only repeat the reality, then what hope do we have, I wonder.
Business interests and the resulting pressure have been a fact ever since first written history. Again, the reality is well-acknowledged for a LONG time now.
I work on Wunderlist. One of our key differentiators, the thing customers love, love, love, is native apps on the major platforms (iOS, macOS, Android, Windows), in addition to an outstanding Web app.
We quickly got several million customers, were acquired by Microsoft for "an undisclosed amount".
Slack has a native app on every platform, too. Including Linux.
Users don't care what the app framework is. They just want something that isn't in a browser and does stuff like notifications. That's what native means to them.
They don't care what the framework is. They do care, strongly, about how native something feels. Slack doesn't in lots of naggy and laggy little ways. Look up the "uncanny valley" of native apps.
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.
> So get over it or provide a solution, but stop complaining.
Complaining is a necessary first step in finding a better solution. Before being able to solve a problem, you need to first articulate what the problem is.
> 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. Don't. Care. We only manage to kill it because we finally replaced it with systems that could compete on easiness and features. So you know what to do.
I really miss the simplicity of a self contained swf file that could be embedded in an html page, but was usually also self contained and could be downloaded and run on its own. And of course they are tiny and fast. And I could run them in Linux, or even on my Palm Pilot. Except for battery consumption, were they really that bad?
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.
Most of those problems have been replicated with HTML5. Yes, HTML5 can do some cool things. But I also find myself missing flash sometimes. HTML5 was not a replacement.
And, based on the direction things are going, I think it's only a matter of time until you can't even select text properly or scroll in a predictable way.
Few people rewrite scrollbar with HTML5 based tech. I have yet to see a virus propagate because of a W3C web API. For the memory/battery though, you are more and more right every day.
That's always been the trade-off: high-level development environments with a great developer experience and a pleasure to deploy to users... at the expense of premature pessimization. In all my years managing applications built for mobile (whether phones, tablets, or laptops) any time someone says, "let's use webviews," you know there are going to be performance issues down the road. You'll get to market quickly but you're going to spend that development effort down the road closing the gap and trying to tame a vastly complex VM to make your users happy again.
I'm hoping react-native like dev experiences will make us re-think how we can have our cake and eat it too.
Wordperfect is famous for failing because they sticked to assembly while the competition moved to C.
> this one is odd to me considering Python came first...
It is indeed. But date of creation has no importance in this. Java became popular first, and is faster and consume less memory than Python. I'm a Python dev now, and I when I picked up the language more than a decade ago, people where looking at me like I was crazy.
That was a common refrain through the 90s and early 2000s – compilers, and especially open-source ones, have improved significantly since then but at the time it was relatively common for someone to replace a hotspot with inline assembly for a significant boost.
The flip side perspective of this is that end users are forever plagued with poorly-performing/behaving software, because developers favor their convience over user experience by continually moving on to new technologies before they're mature enough to be satisfactory replacements of the old stuff.
But the majority of users/clients/bosses won't pay for better software. They want it now, for free.
The market is asking for more and more software, with more and more complex features. And they must be usable on many platforms, by users incapable or writing their name correctly, let alone comprehend a computer.
In the mean time you have a bit more trained programmers, but not that much more. And most of them are not remotely good enough to provide fast, reliable and usable software. The ones that can are expensive.
In this situation, any shortcut you can take, you take.
It's like the quality of food or kitchen wear. You want 1000 of fruits available all year long ? Ok, but the quality will suck. You want everybody to be able to afford 10 machines to do every single things instead of you. Sure, but they'll break in 2 years.
My mothers kept her machines for 20 years, and I can seldom keep mine for 5. I eat tasty tomatoes 25 years ago. Today I have to look for them with expert knowledge and a bag of money or they'll taste like plastic.
As long as everybody wants a piece of the cake but nobody wants to pay for quality and don't want to wait, well, you'll end up in those situations.
For software, this is only going to get worse. Every year, I get paid more and more, I accumulate more knowledge that the newcomers are struggling with. I refuse work. And I don't get penalized for any shortcut I take.
But the author says right there at the bottom, the problem isn't JS or web APIs, just that we don't need to be running a chrome underneath everything. They suggest React Native, I don't really know enough about it to judge, I've simply never been a fan of the resource toll electron apps have on my computers.
There are situations where one has a choice between putting in the required work and becoming competent at a task, or waiting and hoping that the task will be simplified so that they can approach it with their current level of understanding. Unsurprisingly, the latter is not the path to personal growth.
A good example is the tech competence of the general population. Computer savvy or proudly dismissive? Now we have seen the technological improvements that allow people without tech skills to perform all sorts of tasks that they couldn't before.
The drawback is that the general population is at the mercy of the providers of these magic tools. If the provider decides to increase prices or move to a subscription model, they have to accept it. If the provider adds tracking & analytics and other privacy-invasive functionality they will be outraged, and then accept it. If the provider updates their app and puts features behind a paywall or completely redesigns the UI because their designers were getting bored, those people will have to grin and bear it.
e.g: Microsoft has decided to transform Windows into spyware: they can run code remotely, log keystrokes and upload them to their cloud, etc.
Most people either don't have a clue or can't do anything about it, because they outsourced their software skills to Microsoft, which worked well enough until Microsoft decided that their interests are not aligned with those of their customers.
JS developers are another example of this - they are prisoners of JavaScript, although I wager most of them would say that they're happy to live in their golden cage rather than in the technological jungle that they're unfamiliar with.
Condemned to go along with any decisions made by Google, Github, Apple or other companies that they have no influence on, because by not challenging themselves to learn, they gave up their freedom.
You mentioned that (some? most?) web developers don't even know what linking is and you support going on the same false path, dumbing down things until they are understandable to those that didn't take the time to educate themselves. This will only result in a generation of helpless individuals cobbling components together in a decent enough way to call it software.
A new kind of browser engine, not based on any existing engine, allowing developers to use a subset of the web (webgl, 2d, layout) without being forced to use a bloated ecosystem (and which also works on mobile and low end device).
Both your webpage and your docs are riddled with typos and the like. While it isn't indicative of code or project quality, it sure makes taking the project seriously a lot harder.
Hey, I think you're doing the right thing, in 1) asking for help from the community in an area where you feel lacking, and 2) by making it available to the best your ability. Many projects fail at one of those two, which dooms them to never have a community. Keep up the good work.
Seems an easy question. English is basically a/the global language. If you want a massive portion of the community to find the content inaccessible, making it available only in French is a good way to do so.
Well it depends on how much you have worked with a person who was still learning English. For me it highly depends on the kind of typos:
- They're vs Their and similar normally denote uneducated native English speaker. The code might still be okay, but these typos passing to production makes me check code quality in case some similar QA mistakes are passed in the code.
- Grammar mistakes normally show a foreigner for whom English is not the main language. A small example just in the first line, "to create apps, games that run" => "to create apps and games that run", but this is normally due to a different language constructions. Similar to graphical softwares => graphical software.
So, kudos for OP to write the documentation in a non-native language! (upon light investigation it seems the main writer is French and his coworkers fix typos from time to time).
> They're vs Their and similar normally denote uneducated native English speaker.
in germany only grammar nazi's would actually hate such things. they are too common, to say that only uneducated people do it.
people who write code and distribute code to the whole world are not writers, there is no need for "perfect" grammar and typos. i mean in my first application i've written quanity instead of quantity (inside the code), somehow it slipped in a lot of places, but i think many many people who will read the code would still understand it.
as long as the user interface is checked, i think it's okay if the readme/documentation has typos or grammar mistakes (on open source projects).
the most important thing is, is that people understand each other/understand what it's all about. which is just fine for nidium.
Really? I have seen it in many "comment sites" but rarely see it in technical documentation and blog posts. And I don't hate that at all! I'm just pointing out that someone who makes these kind of mistake is probably native and that a large number of these typos indicate that:
- The writer didn't do proofreading (or did it but is not aware of the mistake).
- It's made by a single person with no one else to check on the documentation.
Now while they are not technically a display of low code quality, they are normally indicative of low attention to detail and lonely programming, which is not the optimal situation for high code quality. For people using English as the second language I'm a lot more forgiving since they and their coworkers might not even know how to properly express some things due to translation issues (and not due to lack of proofreading/lonely programming).
In my experience when I'm doing proofreading of my own libraries I also catch ambiguous sentences, lacking documentation or examples and many other things that could be improved upon.
Building Chromium/CEF requires several times more disk space and takes several hours on my new MacBook Pro. So I guess the answer is "not abnormally large".
It may be less an issue for games, but I'd have to wonder about stuff like accessibility. While I agree that the web platform has many things that can likely be removed in a pure app platform, I have to think that there are also many pieces built up over the years that are important and would have to be rebuilt.
But I was hoping for something like Electron/Node.js with a different/smaller engine like Ducktape. There seems to be a Chakra version of Node.js so this should be possible in the future.
The only heavy weight in this constellation remains Chromium...
I've applaud the effort but I don't think I would use this over electron. Without HTML/css how do you make an interface? With canvas directly? I can't find any examples other than three.js stuff.
> If you want to use JS and react to make a native app, try react native instead.
Given the discussion of the recent ReactXP thread, I'm guessing most people don't realize you can do this today. React Native supports macOS [1] and UWP [2].
Edit: There's even some early work on Ubuntu support [3].
There still seems to be a big problem that Electron is addressing that these React Native solutions aren't bothered with: it seems that users need to have Windows 10 whereas if you look at the OS market share, Win 7 still has the most usage at almost 50%
I was about to call bullshit on the blog author, but I guess we are getting to that point. I've been hoping for a React or Vue-native version for desktop so that the Chromium in Electron could be avoided.
I'm probably in that camp too, I thought it was just for android and iOS still (even though I consider myself to keep up to date with these types of things).
I originally thought React Native was for all platforms, then I read their website and docs which made me realize it was only for mobile. That all went down a few weeks ago. Now, today, I find out I had it right the first time. How big a shortcoming is it of their website that it made me go away thinking it was something it wasn't when I had the right thing in mind?
You can also currently use React to share code across iOS [2], Android [3], UWP [4], macOS [5], web [6], VR [7] and a bunch of other stuff that is there mostly for fun (like React Hardware [8] and React Sketch.app [9]).
There's also experimental work on defining a set of primitives that works across all of these platforms [10].
Ubuntu support? Are you kidding me? Is Ubuntu an OS? Is it an UI tookit? So what in fact is React Native Ubuntu? Probably a React Native backend that displays the UI on Shuttleworth's ego.
At Nylas we made a huge bet on Electron-- our desktop app Nylas Mail actually started as a fork of Atom Shell before the project was rebranded to "Electron."
To be honest, we would have never built this app without Electron. It allowed us to have a small team (2 devs) ship the first version of the app without learning an entire new dev toolchain on multiple platforms. There certainly can be performance issues with building on Chromium/Node but those can be pretty easily addressed.
We even had an early engineer with tons of Cocoa/ObjC programming experience and they still preferred shipping with Electron.
The HN crowd complaining about Electron kind of feels like the early criticism of Dropbox or the iPod. "This is technologically inferior and has fewer features so it is clearly worthless."
For some reason there's a deep-rooted philosophical opposition to Electron-like technologies from lots of hackers. But I predict it will be like Java-- everyone "hates" the JVM for years and calls it slow and then one day it's running nearly every mobile device and being used across Google.
It's not crazy to think Electron will evolve like this-- it certainly has the momentum. And the ideas of a web-based desktop app platform have been pushed by Google, Apple, and Microsoft in the past. Seems like we're finally getting there...
It pains me to see how a person responsbile for a pretty important app is as oblivious as you are to the real issues.
Many people use laptops and their battery life matters a lot, being one "minor" factor. Not to mention that in a technical sense, your app really shouldn't take any CPU while idling. Doing a socket wait is something a Raspberry Pi Zero handles without going to more than 1% CPU, for half a second.
> [...] oblivious as you are to the real issues [...]
I understand that you're frustrated, but this kind of language does not foster productive discourse.
As I understand it, Nylas (grinich's OSS Email product/platform) wouldn't have been possible to build with a two-person dev team had they chosen to implement it in something other than Electron.
Are you suggesting we're better off without competitors to the existing email desktop-clients?
> Are you suggesting we're better off without competitors to the existing email desktop-clients?
This is a false dichotomy and you are aware of that fact. This polarization shouldn't exist in the first place. And it can be eliminated with a small time investment.
As developers of important apps, your contribution to the world influences culture. Other follow in your wake. Is that the influence to the world you really want to give to other programmers and business people? Time to market is not the only priority.
That you treat a non-flattering language as me being frustrated tells me you will not understand that side of the argument however. So let's agree to disagree and move on.
> [...] you treat a non-flattering language as me being frustrated [...]
You're right; I was being presumptuous about your emotional state. I apologize. -_-
Let me try to clarify: Companies like Slack and Nylas and Spotify understand the performance implications of using Electron and it _is_ a real problem, but the _benefits_ of using something like Electron, at least currently, outweigh the performance troubles.
There's simply a _much_ lower cost to iterate quickly on a web-driven application.
That said, we're all frustrated about the performance implications (users and companies alike), and this this is reflected in the direction the industry is taking.
I predict Electron _will_ become less popular in the next year or two as React Native desktop support becomes proven by one or more major players:
> You're right; I was being presumptuous about your emotional state. I apologize. -_-
Upvoted for you being nice and constructive. =) I could've been less harsh myself. Sorry!
> ...the _benefits_ of using something like Electron, at least currently, outweigh the performance troubles.
I get it, man. I've been there in the past. I understand your position.
> There's simply a _much_ lower cost to iterate quickly on a web-driven application...That said, we're all frustrated about the performance implications ...
Not arguing that, that's an undeniable fact.
> ...as React Native desktop support becomes proven by one or more major players:...
Yes. Nothing would make me happier. I started with Windows' crappy MFC, ATL etc. horrifying libraries and I've been immensely let down by the promise of Java Swing community that never managed to get its act together well enough to give you a quick and easy way to create cross-platform UIs. Desktop UI is like a hobo on a celebrity wedding: everybody knows it's there, everybody feels awkward about it, and nobody wants to improve its situation. And that's going for like 20 years now.
Us the slightly older generation of devs are guilty for the situation as well. We too had to go on about our day jobs and find a quick way around.
I guess I was a bit harsh because I expected the next generation to pick up the ball and dribble it better than us... >_< Which is a very wrong and egotistical expectation, I'll be the first to admit.
Just don't give up! Make sure that you educate management periodically. Talk to them, convince them, give them analogical examples from the physical world so they get the problem on their level. Never give up the good fight; educate, iterate, improve.
I loved your app, by the way. I only uninstalled it because I am moving away from Gmail.
I really hope React Native Desktop works but I am very skeptical since there still isn't the same coalition of large companies with apps in production using it. Right now React Native Mobile is being pushed by FB, Airbnb, Tesla, Bloomberg, Uber, Soundcloud, etc. and there are thousands of apps using it. React Native Desktop has nowhere near that momentum or support. It would probably be more effective for React Native Desktop to jump on the ElectronJS bandwagon and use it to push awareness, integration, and distribution since it's a pretty close use case.
After you do that a number of times though, promise me something: please reflect on my words again in the future. Devs at important app shops are influencers for much more than technology. You should try and be a positive influencer of culture. Sometimes it comes with a financial cost and I've been guilty of going the way of the money in the past myself.
I'm not saying other things aren't important or should be sacrificed. Just that when building a startup, if you can't get to market... you die. Having a great culture or clean code or beautiful design doesn't save you if you don't ship. Those are still all things which can kill the company later, but none of them kill you as immediately and completely as failure to ship. So time to market becomes the ultimate priority.
> To be honest, we would have never built this app without Electron. It allowed us to have a small team (2 devs) ship the first version of the app without learning an entire new dev toolchain on multiple platforms.
There are a number of email apps around, why would I want to use one from developers that put their convenience above mine (and my batter life)?
> But I predict it will be like Java-- everyone "hates" the JVM for years and calls it slow and then one day it's running nearly every mobile device and being used across Google.
Notice how the jvm is dead on the desktop? Notice how android apps are incredibly slow compared to a native one? Also, android has never run on the JVM, they created their own VM because the JVM was too slow.
I say this as someone currently writing a native desktop app and someone who doesn't like Android (having shipped substantial Android and iOS apps):
Android apps are not incredibly slow compared to native apps, and the ones that are aren't due to Java. Android has always _used_ the JVM, just not run binaries _on_ the VM – they created their own (Dalvik) because they couldn't ship a Java virtual machine, so they shipped a virtual machine and played bytecode games so the thing that ran wasn't Java bytecode, and it wasn't run on a Java-compatible VM.
Also, Android has and will be running on the JVM, because they're transitioning to OpenJDK.
> Android apps are not incredibly slow compared to native apps
I still have to wait seconds for simple apps to startup. Apps of the complexity that would have opened instantly on a desktop of 20 years ago. Part of that is the speed of java and part is the extra memory it uses.
>Also, Android has and will be running on the JVM, because they're transitioning to OpenJDK.
Android is switching to the OpenJDK class libraries, not the VM, they've already built their own VM twice to avoid it. I think your confusing the VM and the libraries everywhere else too.
* Don't use PHP its a fractal of bad design - most popular server side language before
* Don't use JavaScript its a scripting language - most popular programming language
* Don't use Flash its bad for security and accessiblity - most popular authoring tool for animated web apps.
* Don't use WordPress its a spaghetti mess - most popular CMS
* Don't use VB6! - most popular rapid application development tool
The most popular techs are the most practical and easy-to-use ones. Im not dismissing the arguments. The "dont use" arguments are valid. HOWEVER, you can't just tell people to "do the world a favor and don't use this tech because". That doesn't work. Unless you can release a competing tech that does better, with less amount of work.
A lot of Slack's high (background) CPU usage is caused by GIFs, in my experience.
Just did a quick check on my quadcore MBP, having Slack fullscreen out-of-view with nothing animated in view gives it a CPU usage of 0,1% with spikes up to 2,5%. Switch to a conversation with a single animated party parrot emoji, go to another fullscreen app once again, and CPU usage never drops below a whopping 22%. For an animated parrot cartoon.
I'm not sure if this is a bug in Slack or Electron. Doing the same in Chrome does not cause any issues, as GIFs seem to be suspended when the window is not in view. CPU usage goes down to almost 0 when you switch away from your GIF-filled Chrome window. For Slack, however, it barely changes. A big shame.
(On that note, I wonder how much power is wasted by party parrots via CPU usage. Where I work at least one is almost permanently visible in any conversation as a reaction emoji, so it's probably not insignificant.)
Well, back then we didn't have a composited desktop, so when the browser was out of view, no drawing was taking place. I kind of wish we would still have the option of programs just drawing directly to the screen rather than caching everything in private back buffers, but still use modern graphics techniques. I have a hunch that would actually be faster, since cpus have severely outpaced memory.
The GIFs were significantly more complex than the single emoji that the parent comment mentioned. Actually, I think even a four-frame 48x48 gif is more complex than that "single animated parrot emoji" :-).
Post author here. I thought about that, but there weren't any visible animations playing when I took those measurements. And the 5% figure survived a restart of the client. Its possible there were gifs playing above-the-fold somewhere and reloading themselves, but if so I'd say thats a bug somewhere in the interaction between the 15-20M lines of code in slack, electron and chrome.
Its also worth noting that blog post is from a few months ago. Its possible the slack team has fixed the issue now. I wouldn't know because I deleted the slack desktop app and haven't looked back.
Comparing CPU usage % across machines (or even runs on the same machine) without know the p-state doesn't make for a good comparison. This is especially true if you're on a fairly new processor with wide frequency operation range, 5% @ 1.3Ghz != 5% @ 3.5Ghz
How can animating a few gifs (or a few hundred) even use a noticable fraction of CPU? It's small images blitted from memory to screen. I agree with the author. Get off my lawn.
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 release required nobody to even glance at a CPU graph.
I think this thinking is exactly how it gets past testing. You could force every engineer to have a CPU meter, but that alone won't help; they'll ignore it, assume it was a coworker's change that made the usage higher, or just assume their CPU is high because of their 30 Chrome tabs currently open while developing.
A better solution would be to have CI monitor CPU usage so that increases/decreases could be monitored and reported over time/per commit.
You could force every engineer to have a CPU meter,
No, you should force every developer to have a shitty Core 2 Duo CPU from 10 years ago. A lot of devs are working on new shiny i7s and that will hide a lot of performance problems because it's a top end CPU. Do your testing on a cheap box and if it is still smooth then you can ship your product.
> 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.
Most bugs are of the form "do X then Y then it doesn't work". These idle CPU bugs are reproduced simply by opening the application.
I accept that 13% idle usage is invisible for most developers - but that's a bit disappointing. I notice stuff like this just by idly glancing at my CPU meter from time to time. An app that's sitting on high idle usage sets off klaxons for me.
You're missing my point. All software has bugs; something always "makes it past test". Pointing at whichever bug did make it into production and saying "gosh those developers must not be testing anything" is silly.
I assume that's been patched; I just tested it and VS Code sat at about .01-.03% of CPU with a blinking block cursor (VSCode vim extension. Maybe it's better than the default I?).
I noticed a few moments after startup that the CPU usage jumped to the 5-7% range for a couple seconds, then it notified me that an update was ready (I assume it was downloading/checking/processing that update). I don't know if this is Electron, or just a general trend in desktop apps, but it seems to be getting a lot easier to update them. So when those pesky CPU/memory hog bugs are found, they can be quickly patched. As for the general trade off that comes with running an extra Chromium process, I suppose it's up to users/developers as to whether it is worth it in each case.
I've noticed the same myself, and I'm a bit surprised Slack hasn't done the same trick some of the larger image hosts have and started converting gifs to videos. Those hosts did it to cut bandwidth costs, but it also helps users as a side effect.
(I continue to be amused that everyone records & shares gifs for "compatability" and "simplicity", but many of the places they're shared re-convert them into videos.)
I know nothing about how Electron renders GIFs, but can guarantee you that there's no world where 16x16 animation should take up 20% CPU. Suggesting that we should convert them to tiny videos is completely missing the point.
The problem is that in popular usage many GIFs are not 16x16. People are sharing high resolution GIFs that can weigh tens of MB, and rendering several of those at once (whether directly in Chrome or in Electron) is not a negligible amount of CPU. It shouldn't peg a core, of course, but it's definitely higher impact than videos of similar sizes, since video rendering is considerably more optimized for these cases than GIFs are.
But they have responsibility as to what underlying tech they use. A responsibility they happily offload to someone else and go on their merry way -- and that's one of the big issues here.
I didn't use that app ever but I guess w/ or w/o a gif, it won't use much CPU when it's idle. When scrolling a page-like thing that's already rendered, also then it probably doesn't do much computations. What, at all times, will be overtly consumed is going to be memory space. That may cause battery drainage and general slowness in the OS due to swapping, and even quicker wear-out of storage hardware. AFAIK Chrome takes hundreds of MBs of memory just right after startup, with nothing open.
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 years ahead compared to what you can easily do with WPF and friends.
And what about Python for data analysis? The one language that is known to be 10x slower than C becomes the de-facto standard for a field where what matters most is code performance. Again: ease of programming.
The success of electron only shows that there is a market for a UI library that can be written just like what you do in the browser but for native desktop apps... Please someone, write that !
> And what about Python for data analysis? The one language that is known to be 10x slower than C becomes the de-facto standard for a field where what matters most is code performance.
Almost everything done in Python for data analysis is just a thin wrapper on top of a fast C/C++ library: Numpy, scikit, Pandas, Tensorflow, etc
That's a good point. You can get away with quite a bit of non-performant user code if the majority of the actual code execution is in the "inner bits" and not the user code. The user code ends up being the "driver" and the heavy lifting is all done by code that is able to provide the required performance. It's also a good reason why PHP has been able to become so pervasive.
> 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.
Pretty sure you could do that as easily in PHP, Ruby, Python, Perl before Node.
> And what about Python for data analysis? The one language that is known to be 10x slower than C becomes the de-facto standard for a field where what matters most is code performance. Again: ease of programming.
When code performance matters most, you're probably still using Hadoop, C/C++, Fortran. Python is mostly in competition with R, Matlab, SPSS and Excel. Julia is the new kid on the block, and it was designed to be more performant than Python and R.
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.
Yep, WPF is probably the best platform at present for creating rich GUI apps. It's failure to really take off is overwhelmingly caused by its complete lack of cross-platform capability. If you're creating a new Windows app from scratch it's really hard to justify using a GUI framework that eliminates the option of going cross-platform in the future without needing to do a near-total rewrite.
>And what about Python for data analysis? The one language that is known to be 10x slower than C becomes the de-facto standard for a field where what matters most is code performance. Again: ease of programming.
That is likely not the only reason. A lot of the libraries like NumPy, SciPy etc., that are one of the reasons (but not the only one) why Python is used so much for STEM / data analysis / data science etc., are written in highly optimized C or C++ or FORTRAN, with maybe thin Python wrappers over them. So ease of programming alone is not the reason. If it was easy but too slow to run (remember, many such apps process huge amounts of data), then people would not use it.
> 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.
Having learned Ruby on Rails before Node, I view Node as "screwing around for hours before being able to respond to a simple http request."
> 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).
We actually have written something similar for our product Elevate Web Builder (commercial, closed-source, written in Delphi), and have considered moving it to Free Pascal in order to allow developers to use it in portable, native desktop applications. The IDE for Elevate Web Builder has to provide a browser-like design-time environment for the WYSIWYG designers, so we created one. It effectively uses a DOM element tree structure like the browser, but doesn't use HTML or CSS. Instead, it surfaces all declarative styling as element properties (with real types, not everything as a string), provides its own layout management that is more application-oriented instead of document-oriented, and has a great batch update functionality that allows you to suspend updates/repaints until you're done making all necessary changes to the element properties of one or more elements.
The reason why it's such a compelling idea for us is because Free Pascal is a blank slate with all of the support code for multi-platform development, and we already have all of the code written for Windows. The reason why we're hesitant is because it's all in Object Pascal, so I'm not really sure if it's a compelling draw for JS developers that want to create desktop applications.
If we ever do something with it, though, we will certainly post it here as a "Show HN".
We have a product for web development in Object Pascal, Elevate Web Builder (http://www.elevatesoft.com/products?category=ewb&type=web) that includes an IDE with a WYSIWYG design environment (the IDE is written in Delphi for Windows). In order to supply the design environment, we had to write an emulation layer that mimics the DOM tree and can perform the necessary drawing operations to satisfy all DOM CSS style properties. This layer is ~80% of what you would need to implement a UI toolkit in native Object Pascal using Free Pascal. The last ~20% would be dealing with surfacing the native OS input controls (single-line edit, multi-line edit, etc.), which are just stubbed out right now because the design environment doesn't require them. We've considered finishing this last bit and making the whole thing available for Free Pascal.
It's worth noting that Node.js - similarly to Python for data analysis - drops down to lower level code for a large chunk of its code base and makes it pretty easy to bind to other languages where performance matters.
Developers are often willing and able to produce high-performance code when the barrier to doing so is low enough.
That would seem like the best possible outcome for everyone, really, but you're not going to get much karma on HN unless you're either showering JS with praise or vilifying it as cancer.
It's appropriate to call Chrome an OS-like platform, and it's quite convenient to ship apps with, but it's not "Flash for the desktop". As someone who is opposed to bloat but sometimes appreciates convenience, I think Electron is getting a bad rap here for something that was screwed up by the JS app developers.
Go to Electron's website and download the demo (called API Demos). It's 3 processes and consumes 0.0 CPU on idle. Is it super efficient space-wise for what it does? Certainly not. And RAM usage is a valid concern. But churning CPU cycles on idle is not Electron's / Chrome's fault. I also suspect that if an app is behaving grossly on Electron, it's probably a bad actor within a generic browser environment, too.
My recommendation would be to not ship simple web apps wrapped in this huge machine without a good reason. But there are good reasons to use Electron or NW. It's just a poor choice when all you need is a thin wrapper around your website.
Blog author here. Thats a fair criticism. I wanted to pick on Spotify and Atom more in my blog post, but both Spotify and Atom have cleaned up their act. I couldn't get either one to reproducibly use lots of CPU. Props to everyone involved in fixing that.
But I'd also argue that Flash could always be written to be efficient too. The problem with flash was never the little games people made. The problem was that one tab with a stupid punch-the-monkey banner add playing somewhere that would sit on 20% cpu even when the tab was in the background. I think Electron is similar, except in the desktop space. Well written apps seem to be able to keep CPU load down (although they still have a huge download and a huge RAM footprint). But there's been a running trend of noticing some dumb software running somewhere on my machine eating all my CPU. And in the last year or two its been an electron app, every time. Just like flash before it.
>I wanted to pick on Spotify and Atom more in my blog post, but both Spotify and Atom have cleaned up their act. I couldn't get either one to reproducibly use lots of CPU. Props to everyone involved in fixing that.
Gotta agree with the other response here. If you have shown that what would seem to be much larger and more CPU intensive applications have been able to reliably perform well, why suggest moving away from electron instead of suggesting that users learn how to use it correctly, or perhaps suggesting that electron better educate users on how to use it correctly?
A while ago I had been working on a native Mac slack app. I was 70% complete but sidelined it. Should I pick it up again? Would ppl here be interested in paying for something like that? Here are some links to screenshots so you know its not just vaporware :)
I believe it would get a fair amount of attention if it were open sourced. There's lots of Apple platform devs out there who'd love to have a more native Slack experience and would contribute to such a project in a heartbeat (myself included).
Most users will accept issues with their free program if the alternative is to pay. I'm pretty sure the message pane you have there is a WebKit controller so it is debatable how native this would be.
This is Electron scapegoating. The real issue is twofold:
1. Electron makes it trivial for developers who don't regularly reason about native performance to release desktop apps. The result: a flood of apps that "don't do much" but use more resources than you'd expect.
2. At the other end, Electron makes complex apps easier to build. The Slack app might be low-to-medium complexity, but the Spotify app has a ton of functionality, and I bet dev effort was orders of magnitude lower than for a native app like iTunes. The result: in this day and age, complex cross platform apps with higher resource requirements are more likely to be built with Electron.
In short, there's some selection bias going on in both cases, and it isn't directly related to Electron. Electron is just the enabler.
I agree with the author on point 1: performance matters, memory usage matters, and we as web developers should broaden our horizons and learn lower-level languages. I feel that way regardless of Electron though.
On point 2: I spent the last year building a cross platform continuous sync app (basically, a Dropbox V1) in Electron [0]. We were a team of 2. I also write C and C++ for a living, and I simply can't imagine building the same thing in a lower level language in the same timeframe. It's not just a UI concern either: writing a sync engine in node (the backend half of any Electron app) worked out amazingly well. Node is a great I/O orchestrator. The app runs at < 1% cpu when not actively syncing, 40MB backend process, 70MB frontend process. Reasonable for what it does. Dropbox uses more than double that although, granted, it's also not native code.
Why would a tech company not build its flagship product natively on the platforms where it runs? It seems like a generation drift: an obliviousness to the world outside of JS/web dev, and a general disregard for application performance.
Put simply: time to market. Experienced front-end devs with a designer on hand could put together the UI inside of a day, with a workable user experience.
Hell, if you're not afraid of bloating in the codebase, you could use a large number of libraries to put together a basic, working version inside of a day or two. Stretch that to a couple of weeks (at most) and you have a prototype you can release.
The proof is in Atlassian and Microsoft chasing after Slack on this. Very few people came forward to wave the "Let's just go back to IRC" flag.
It's shiny, new, you can drag and drop gifs and files into it, and it runs pretty swiftly (ignoring all of the obvious flaws). Most, especially less technical, users would find it a charm to work with. In my experience, they do -- and above all of the competitors.
The rest of your points are rather valid. But maybe its not so much obliviousness, as eagerness and impatience, and the reality of the market being as timely and pressing as it currently is. It's a race -- just like the telephone and the radio (for my point I'm ignoring the scale of impact here).
That's the problem right there(?). People bringing a DOM to the desktop because the developers were fluent in JS.
> time to market
If there were no drawbacks in terms of complexity/performance/size etc then I'd agree, but now when you have a perf issue that is too large it might be a huge issue to fix. You also only get one chance for a first impression - and poor performance is a huge turnoff. Looking blingy and having all the features doesn't save an app with a 200ms lockup. or a 10% CPU at idle.
Agree, I think this is a combination of lack of imagination by developers who only know JS, and management who has bought the myth that cross platform development is 3x faster than making native apps.
I saw this happen at work. My team were all experts on native mobile development. We could crank out stuff fast, because we knew our tools well. But then some management dude got the idea that we would do it 2-3x faster if we went with JavaScript.
Turns out it was more like 2-3 slower than making all the native versions, because we did not have strong experience with these tools and APIs were more limited, poorely documented, buggy, and the tools were subpar.
because they don't need to. Our phones and computers aren't where they were 10~15 years ago. The end user doesn't even notice if an app is native or running in Electron.
Given that constraint, time to market becomes crucial as the huge cross platform barrier is significantly reduced by Electron.
It's also a demographic shift. Young developer's aren't coding in Java peak world anymore. We haven't even reached peak Javascript yet.
Definitely a demographic shift. And maybe business smart: cheaper to hire and onboard web devs etc. But that doesn't mean the company and its product shouldn't be critiqued for its architecture (even more so because it is a software company).
> I can see someone is downvoting comments that doesn't agree with time to market being an important driver in influencing architectural decisions. This is someone who is very mature and well seasoned in Java architecture.
Ah yes. Someone who downvotes you, which you assume to be about the time to market comment of your argument, must naturally be a person "who is very mature and well seasoned in Java architecture".
What does that even mean to be "well seasoned in Java architecture"?
Telegram Desktop is very good example of modern desktop client done in the most efficient way. C++ and qt, nothing else. Works like a charm an all major operating systems. Easy to install, use and update. Great stuff.
I downloaded this and signed up just to give it a try, since I've never used a Qt app on the Mac that didn't fall in the uncanny valley of UI -- trying to be native, but failing.
This doesn't break the trend.
Some problems:
- Text boxes are non-native and do not support any standard keystrokes for navigation (this is huge!)
- The division between the titlebar and the main app body is weird looking
- Highlighting around a focussed text box is weird
- Weird inline dialogs
- No bounce scroll
Some of those are debatable (not everything has to be done using the standard system stuff, of course), but to me the overall effect is very alien.
Slack, for all its inefficiency & handful of annoyances (not actually using unicode / text to represent emoji, anyone?), "feels" like a better Mac citizen than this app.
Three of your points use the word "weird" which immediately puts them in the subjective category (hint: zero argumentative value). "No bounce scroll" is subjective as well, hence no real argument there as well.
Non-native text boxes is a 50/50 issue. I get that it can be alienating for some and that's just as valid as me not caring. But it's still subjective and bears zero argumentative value as well.
Telegram Desktop works very well and is easily the most lightweight messaging app my Macbook 12" has ever seen. And I don't have to fear that I'll get back to my machine after being away for 25 minutes, only to find it losing 40% battery to Slack and Atom.
Well, clearly you're either not sensitive to or don't care about look-and-feel issues. To those of us that do care, it's a big deal. Just not being able to use C-f, C-b, C-e, C-a &c keyboard shortcuts in text fields is pretty much a deal-breaker for me.
No argument here that Slack is hideously inefficient.
Mac citizen. Perhaps you should think of your computer as a thing computing things and showing them on the screen. There were many people in history obsessed with uniformity and it usually didn't end well. Yes, uniformity in UI has benefits, but you should appreciate every single deviation from that. In this case, it's the price for "write once, run everywhere", something that isn't appreciated by Apple and Microsoft.
> There were many people in history obsessed with uniformity and it usually didn't end well.
Right yes. Lets argue against uniformity in the (visual) design of a UI based on pulling in all of known history and the atrocities that have been committed during that time.
Is it hurting you in any objective way? That is the better question here. What objective value do you get from a 100% uniform UI? I can very easily orient myself between using my Win10 and macOS Telegram apps.
I'll give them credit where it's due, it's a great app. That being said, if you've read the source, it's not exactly the most approachable thing in the world.
Also, if you're not making your code LGPL/GPL, be prepared to pay $300/person/mo for Qt Creator (seriously - https://www.qt.io/buy-product/)
They didn't rewrite the app. There are multiple official apps, you could also write your own (that's what is happening for Unigram, an open source UWP client for Telegram)
All of this extra memory and CPU power has made us lazy.
Simple applications often lag, because they are written on top of heaps of crap. Yet you look at a 4k demo that does more impressive stuff with a fraction of the resources.
When we step really far back, an application should not require that much code. Nor should the process of abstracting an application on top of a native system. These things only get muddled when you depend on specific functionality of the system that is difficult to abstract (i.e. native GUI component and layout), which you can easily simulate with your own GUI renderer, potentially in a more optimal way.
Anyhow, I'll sit here waiting patiently until someone figures out how to write once, run everywhere in a relatively bloat-free manner. :)
I've been working on a hobby app for some years that is a modern refresh of an old idea. As the article exhorts (and just for funsies, it's just a hobby) I'm writing it using native code and to be conservative on resources.
Every place I need to render text or make a thing respond to a mouse click I need to manually do all my own text layout and event handling and so on. (The app is in a domain where it needs special rendering -- I can't just reuse a system widget or library like Qt for this.)
Meanwhile, people are making apps similar to mine on top of Electron and banging out features way faster than I ever could. If they want some popup to have some bold text, or use the GPU to animate, or properly handle Arabic text layout, they get it all for basically free, they just need to bang out some divs. I am jealous.
Well, the question is: Does your app run always like a daemon or just when you actually need it?
It can be fine to prototype in Electron, or to make tools in it. But if you're making a chat program or anything similarly long-lived, it's the worst decision you can make for your user.
"it's the worst decision you can make for your user"
- Is it? Because there are a lot of Slack users who don't care at all about your tradeoffs. Most of them don't even notice. We're just the unfortunate ones who do notice.
Very timely article. But I have been told to shut up and use Atom/VSCode/Slack like everyone else and upgrade hardware if software runs slow.
I find memory/cpu efficient applications not just useful but respectful to users specially when upgrading hardware is not possible due to financial or policy reasons.
We're also in an era when the speed of laptop and desktop CPUs has essentially stalled. Put another way, if our apps hog more resources there aren't necessarily faster machines we can buy.
Yes, this is extremely important to remember. The days of "who cares if we use a few extra bytes of RAM or a few extra CPU cycles here and there as computers will be twice as fast and have twice as much memory this time next year" are long over. And with the huge push for mobile and slim, portable computers, power efficiency is paramount as users really care about battery life. Yes, sure you can get a more powerful laptop than your nice, sleek, portable macbook air, but it's going to weigh 5x as much and the battery life will suck, especially if you actually use that power. People want to be able to use their CPU and RAM to run multiple applications efficiently, not waste it on a few laggy memory and CPU hogs.
I'm running VSCode and Slack on an 11" MB AIR with 8GB Ram (Early 2014). I'm not really seeing performance problems, even with about 40 tabs open on my Google Chrome. While I do occasionally see Slack occasionally popping up on my Activity Monitor, as a user I don't feel I've actually been negatively impacted by this.
I think JavaScript is the new PHP -- it's accessible enough that people are going to be coding in it for the foreseeable future.
Chrome eats a lot of RAM, and frankly, most of these apps don't need all of Chrome. But any solution that requires moving away from JavaScript (e.g. C++/Qt apps) is too expensive in terms of retraining developers. (Facebook found it was cheaper to create Hack and HHVM than to train its engineers to stop writing PHP-like code.)
Maybe the answer here is a "React Native" library that results in native Windows/Linux/OS X desktop apps. But, with larger corps focusing on "mobile first" and "responsive design" memes, I don't imagine either Facebook or Google being the first to build such a thing.
Electron is flourishing because of low barrier to entry like many already touted. But lets ask something [probably] more constructive?
I've made 3 apps with Electron that I could probably never make since I would be busy learning OS specific things.
Can we not have low barrier to entry for creating native apps? Are there any solutions/frameworks that one can utilize? Is it just a matter of poor documentation/support from OS makers? What is it?
Edit: Some of the contents that said something along the lines of: Is it really slow? It opens so fast for me...
The worse thing a developer can do is judge their application anecdotally and not through something more empirical. Its our job to make our shit available to more users and support more platforms (hence Electron is used) but it is also our responsibility to make sure they can use our app and have 50 tabs open and do other more important shit like... watching genitals in a flash player. I was in this Electron phase but I started to run traces and see how much of a hog it is.
If you really care about what you are working on, use Electron as a prototype, get it out there, then start making a native app. I think this is the best of both worlds. You get your shit out there, people let you know how it stinks and in the mean time you make something that is better suited for their OS.
P.S: Sorry for the overuse of "shit". I am fishing for upvotes.
> Can we not have low barrier to entry for creating native apps? Are there any solutions/frameworks that one can utilize? Is it just a matter of poor documentation/support from OS makers? What is it?
Won't happen. All the signs point to more and more developers understanding less and less of what is going on underneath the covers.
If anything, we are < 50 years away from only AI and machine learning algorithms understanding chip design and microcode. Soon enough, no human is going to be able to parse the tech stack below the operating system.
The best perf improvement for slack is to disable animated images in the Accessibility Settings... this also removes some of the fun from Slack. I have suggested to them that they should have a setting to only play gifs when they're hovered-over, but still waiting on that to be implemented...
Other tips I've ritualized, use /collapse very often when on slack, and avoid message reactions with animated gifs. Animated things are why Slack will idle at 5%+. Lots of them and you're going to idle even higher.
Don't leave slack open on a channel where people frequently use /giphy or post lots of animated emojis (#random, etc). Reactions to comments with animated gifs are the worst, because /collapse wont hide them.
In my test locally, a chat window with no animated things is idling at 0-1.5% CPU. I just added 1 animated gif reaction to a comment and it's idling at 4-6%. It's absolutely horrible. I removed that comment and then posted using /giphy, now it's idling at 2-3%. A Slack Helper task started to run at 12%. Ran /collapse and both are back down to 0-1%.
Reacted to a message with 10 animated gifs, slack is idling at 9-12%. Slack Helper is at 26.9%. Brutal. Can't /collapse to fix this, either.
- In Advanced Settings, just turned on "Disable Emoji Spritesheet" and slack is idling at 7-9%, Slack Helper at 27-30%.
- In Accessibility Settings, disabled "Allow animated images and emoji" and Slack is idling at 0-1% and Slack Helper at 0-1%.
How much of all this nonsense is caused by devs using any and every JS library out there? We've seen this problem on the nodejs side before, and it's even more painful on the browser side. Sure, Slack almost certainly doesn't know all 15m LOC in Chrome, but they sure as hell should know every LOC in their JS, whether that's from in-house code or 3rd party libs.
There are two totally different points mixed up in that blog post.
1. Delivering your app with electron
2. Writing a web app versus writing a 'native' app
Yes, delivering an app with electron might be subpar as it brings code to your computer which it probably already has. Most Computers which are targeted by electron apps already have a browser and lots of them have up-to-date chrome or firefox browsers which offer features very similar to electron. So I don't say there is no reason why one should use electron, but I urge every developer to make their web apps accessible to browsers too and let people use their browser if they want. Even offlines usage is no problem anymore as we have serviceworkers in the majority (by market share) of browsers nowadays.
The second point, however, is very poorly laid out in the blog post. Web apps do not have a general problem with performance as suggested by the article. Maybe some are badly developed but in the end, they are all backed by the tremendous efforts that were put into browser performance in the past years. The question if web apps can deliver the required performance was answered by the 60 FPS discussion a few years ago.
At the moment, the web is the only truly OS independent platform I know of. That is a very valuable feature and one we should treat with the deserved respect. So please write quality web apps and do us all a favor, instead of just choosing one specific platform. Yes, react-native is an option too, but I think it is a bit limiting to define just one framework as the one true way.
Saying that "React and friends" are the good thing you want (without Chrome) is kind of nuts. React is insanely bloated for what it is, and it's also highly dependent on the bloated browser (and especially Chrome). React Native is an intermediary layer between a work in progress VM and JavaScript. So, we can't win there.
In a sense what we really want is for the browser to be an OS-level feature so that the browser-based-app is low cost, as is the case with chrome OS and you could argue was Microsoft's vision with IE. This is doable today if you write cross-browser code and wrap your web app in a platform-native web view, but then you lose the conveniences of Electron (cross-platform APIs to solve common problems such as menus) AND you have to deal with browser incompatibilities. All this to save RAM and 5% Of one CPU core.
Perhaps in an ideal world we'd have a lightweight VM with nice JavaScript APIs. The immediate problem we run into is that really fundamental UI gadgets, such as styled text fields and canvases, are not implemented similarly on the platforms we care about (Windows, Mac, Gnome, Android say), so we have to reinvent that wheel and before you know it you have another bloated virtual machine, except this one isn't battle tested and it only exists three years in the future.
I have a couple of hobby desktop (macOS) applications in various stages of done-ness, which, if there were a low-effort solution, I'd like to port to Windows. Yet even with the business logic nicely separated out into portable C++, it's a huge pain. In the 10 or so years since I've done Windows, the development environment on that platform became totally foreign. C++/MFC seems to be dead and buried, now we have WPF (which is also going away if I'm reading things right) and C# and XAML and Windows Universal and all these layers of exotic technology I now need to learn and master just to get a simple native looking port of this thing. Screw that, I'll find something else to work on thankyouverymuch.
I totally see the pain and the burning need out there for a way to write something that works across the "big three" platforms that have grown more and more distant from each other over the years. But Javascript and a browser? Really, that's the answer? I'd even be willing to toss out my investment in Objective-C native code on macOS if I could keep my C++ business logic. Is Qt really viable? My understanding (again, maybe dated) is that a Qt application looks like a Qt application, not a native application. Is this still true?
> Maybe we should be buying slower computers so we feel the pain. Facebook has been internally intentionally slowing down their office internet once a week to help build empathy with their users in other 3rd world internet speed countries (coughAustraliacough).
Yep. I've just got back from spending over a month on a ship in the middle of the Atlantic, with two very flakey 256kbps satellite connections (capped to like 125kbps each as well). Shared between roughly 50 people. Our policy is to let anything through (it's a research ship, so being able to look up stuff on the internet is a must) but aggressively apply QoS rules and caching to the network. With the sheer amount of applications that assume they have a low-latency high-bandwidth connection which they can open hundreds of TCP connections on, just tweaking the firewall / bandwidth shaper / application control is a full-time job just by itself.
First observation, relevant to Slack: Before we locked down the firewall, Slack running on 2 laptops was by far the highest traffic application. Even though the few Slack users just had the client open but minimized - not actually using it. It was persistently using 20kbps, all day every day, until we blocked it outright. What the hell other stuff does it have to do other than download text!? Slack / other devs using Electron oughtta test their apps on extremely slow shared internet.
Second comment, relevant to Facebook intentionally slowing down office internet: The Mobile Facebook site (m.facebook.com) was by far the nicest to use on our severely degraded uplinks. No timeouts, pages took under 10 seconds to load, we didn't have to wait several minutes of blank page while another F%$£ing web font that's Arial but with the letter T slightly more aesthetically pleasing to download. No massively parallel loading of resources. Good use of caching.
It struck me that a lot of our problems were problems because devs never have to deal with that kind of crappy internet, it's not an edge case that gets tested. It results in people unable to load important stuff like Google, GMail, Outlook web app, and as such their products lose users. No matter how much we tweak our network internally, even restricting the internet use to a single computer doesn't result in usable web apps anymore. This is probably something that we share with third-world internet; a much larger market than our "research ship" niche.
Finally: People who put company logos in their email signatures hate other people. Base64-encoded PNG images make one-line email responses increase in size by like a factor of 100.
Good someone pointed it out. The web hype has gone of the rails. We got perfectly good development tools for native development which works fine. There are lots of cross platform GUI tool kits too. They offer a better development experience, more dev tools and better performance and memory utilization. It is only because the world is drowning in JavaScript developers who don't want to learn anything else. They want to reuse their latest hipster framework everywhere.
They go on and on how terrible desktop development is, because hey it wasn't equally fast as JavaScript when they had never tried it. Newsflash it is slow and hard to do things you have no experience in.
As a counterpoint, I was able to create a mobile app with native tools for both Android and iOS in less time than it took me to create one in JavaScript. Cross platform JavaScript is highly overrated. It really isn't all that cross platform, often buggy and with primitive debugging and development tools.
...and you know what Flash did for the web when it came out?
Allowed us to watch videos, drag and drop, consume all kinds of media and have interactive applications on the web which were at the time totally unachievable with JavaScript.
Is the internet's memory so short that you've forgotten how recently we have largely switched to HTML5 video?
We've just spent the last 10 years spinning to get back to where we were, because Steve Jobs vetoed Flash support. Before that, we bailed on similar capabilities from Java applets, and had to reimplement them.
Doubtless there's multiple technologies before my time that gave us the same powers, but were abandoned because reasons.
The other day I read a blog post that argued how "Fight for the users" should be a core tenet for every developer. I agree; and, unfortunately, the main undercurrent of the defense of electron, at least in this thread, is one of almost complete disregard for the users.
Yes, most of them probably won't notice the performance impact. Most of them also don't notice whether their applications are insecure or overstep their privacy boundaries. It doesn't mean we shouldn't care about security or should build hidden trackers into all the code we produce.
That aside, Electron is just an ugly idea in general (obligatory IMO). I wouldn't want to run an entire browser just to run my own apps, next to the actual browser.
And I say this as someone who works almost exclusively in web development and who likes javascript.
If I wanted to make a desktop App work on Windows and macOS today, without using Electron, what are my options to build something very quickly that also include the benefits of Electron: self updating, app crash reporting, windows installers, no licensing fees?
Long time javascript programmers are the loser (if they never learned more than javascript) they don't know how to programming an almost perfect program. That is the reason why they using javascript on Desktop. The average programmer learns just one fucking language but being a good programmer you need at least to learn 2+ languages. That you can see the performance issues in your stack. I started with PHP and javascript while this time I didn't care about performance and now I'm a c/golang programmer. When I started to study c and golang I just released how bad the whole javascript stuff is actually.
Or maybe it has something to do with time-to-market for existing web apps, or other loserish things. No, can't be. You must be right. Especially because you know more than one language. After all, when you learn more languages, it makes your words more true!
Can you tell me why Microsoft and google trying to write either supersets or a javascript clone to replace javascript? Because that language is an issue itself. I don't know one good programmer who is saying that you need javascript to make real money or that language is awesome. This language is a bug nothing else.
Just because that tangential point can be made to appear valid in a different context, it does not mean that it is the proof to support your original argument. Sounds like you're primarily just upset about Javascript and/or front-end web technologies.
Meanwhile, we're still waiting for those "pro-native" people to give us better user experience.
I agree that Electron has its issue like having multiple copies of Chromium (and not Google Chrome).
Obviously native apps are better overall, but only if they provide a better UX. Being a vscode user, I don't know which native editor provides the same UX.
Emacs provides a better UX, Visual Studio (proper) provides a better UX, Sublime provides something close, although not as good. Slack's UX is incredibly basic. It's a couple of steps above a basic CRUD app. There are billions of IRC and XMPP clients ranging from toy to professional-quality, I use IRSSI, which is admittedly basic, but I find it hard to believe that there is no better native chat UX in existence than Slack's.
There are native editors reaching from very bare bones (vim) to medium like VS Code (Sublime) to full IDE (Visual Studio). All of those run native interfaces.
If you like Node.js and HTML/CSS, just have a node daemon running in the background with an HTTP server to your app! It's just like Electron, but without the CPU/RAM/Battery usage. You can even have binaries that stay open after a double-click and automatically open your browser to localhost:40023 (or whatever).
Seriously, if browsers supported an app:// URL which just ran a local site with special privileges and allowed for some custom branding Electron would be dead overnight.
if they'd be giving you access to the complete node.js ecosystem maybe.
With electron you can easily integrate native c++ libaries for high performance stuff or things that require hardware access. It's not like electron is just a webbrowser.
Would it make more sense to distribute electron as a dependency and allow apps to use it? That way, instead of 10 apps requiring 10 different electrons we have 10 apps that can use a pre-installed electron.
No, because history has shown that shared libraries on any and all platforms inevitably become bundled into applications themselves (leaving one wondering WhyTF someone would choose something as unnecessarily complex as Docker over, you know, static linking).
Those who do not know history are doomed to reinvent it, poorly. Or something like that.
How does an app bundling Electron in that way differ from an app using a native embedded browser widget (other than that it can run in Chrome vs. Edge/Safari/etc.)?
The problem is: most people don't bother learning new languages unless it's very easy (well, Pascal is!). I hope Go will have a cross-platform UI soon.
And Go already has bindings for QT which is a cross-platform UI framework.
This has nothing to do with people not wanting to learn new languages, it's just the time it takes to build an app. For you to build a QT hello world app takes probably 20 minutes worth of downloading, setup, and coding. To do the same you download electron, create an index.html with hello world and drag and file into electron, bam a hello world app.
The problem is desktop development is overly complex. React and modern Javascript make creating desktop apps using HTML/CSS with some combination of Javascript easy.
What we need to do is find a way to create a very slim browser that contains just an HTML/CSS to 2d context and a Javascript engine. Call it Electron slim and release that.
It's the RAD choice for beginners since... ca. 1997?
> For you to build a QT hello world app takes probably 20 minutes worth of downloading, setup, and coding. To do the same you download electron, create an index.html with hello world and drag and file into electron, bam a hello world app.
Perhaps the first time ever, the 2nd attempt you will be equally fast.
Does a well-funded startup not have 20 minutes to test a platform?
As far as Lazarus is concerned: give it a try, it won't take 20 mins.
> What we need to do is find a way to create a very slim browser that contains just an HTML/CSS to 2d context and a Javascript engine.
Christ, no. There are no slim browsers anymore and it's a pitiful environment for native applications.
Electron is a sub-optimal solution to the fact that desktop development today is horrible. You either have to write your app twice (or three times if you want Linux) or use Qt, which limits you to either C++ or this weird langauge/ecosystem nobody knows called Qt Quick.
Electron lets you write desktop apps that work decently well everywhere in a language you already know.
The electron bundle zipped without any extra app code is only 40MB. This is barely any bigger than the smallest of most iOS that get auto-downloaded to your phone every day. I haven't ever noticed any significant performance hits and I use Slack/Spotify every day. The problem you are speaking to is the same one that comes with any framework that is distributed. Any app using Swift 1.0 had to ship the Swift runtime with the app bundle until they eventually baked it into the OS and allowed sharing framework versions. The same problem happens with JVM if you've ever used a java app on Mac that doesn't use the built-in Java runtime. Its not really a concern to me, as I think this size is negligible and the runtime for Chrome is already the model of isolation so this just extends that slightly further. However I'm sure the Electron folks would be happy if you wanted to contribute to further the performance/usage requirements of the platform.
I'm a big fan and total believer that deletion of few apps like Spotify, Slack and Atom could improve the performance of CPU. Recently I have been getting lags with my WebStorm for even firing up smallers commands like
$ git status
$ git log
I downloaded bunch of cpu profiler tools to observe how much CPU does spotify, slack and atom and also some other fancy react, electron app built apps take. Results are unbeliavale.....FYI: My Ram is 4GB with two 2GB slots. But after a complete cleanup and deletion of above troublesome apps performance is just amazing. I'm having a happy life with my WebStorm. I'm very positive that for my future node.js apps that is running nodemon would be fine too.
Yes, they would simply link stuff dynamically (.so, .dll, .dylib files).
But everyone is using a slightly different version of Electron and macOS and Windows don't have a good enough package manager, so everyone is static linking everything.
I don't understand the React Native comparison. AFAIK, you can't build desktop applications with that, nor can you build mobile applications with Electron like you can with React Native.
That is why I do not use Slack for Desktop, and just keep a pinned tab of Slack open almost all the time. I also tend to reduce my usage of any Electron-based app because I want to better make use of my laptop resources in my development workflow requirements.
I feel like I agree with most what's said there, the same would apply to NW.js and the likes.
This should be a heads up for GUI developers to [re]consider Qt and QML. It made real progress in the last few months. and there are some nice bindings to it.
I love how the latest generation of interest in a particular development area like UI goes down the road of reinvention thanks to the latest in thing or programmer prejudice. The wasted bandwidth is insane.
Somebody needs to write a variation of Sisyphus that turns the boulder into UI development. Suggest not spreading this web dev lunacy onto desktop. The issue has already been solved with reasonable solutions for 25 years. Desktop development, automatic software updates, all that stuff.
The best way forward for Electron is probably to get a very thin, light core instead of the current Chromium-based one. Even on a good 16 gigs of ram and an i7 you feel Electron-based applications' effect on a system.
If you want a compromise between easy multiplatform desktop app development and not wasting resources, the ideal way there may be something like Microsoft's React-based desktop framework that they just released. (in my opinion at least)
People grew up and stopped using Flash, slowly phasing it out. If Electron is as influencial as some comments here seem to think it is, the big players in the desktop market will (hopefully) step up and put together new APIs and tools which fill the gap Electron is currently filling. And they'll do it all natively and without the terrible bloat, poor productivity and bad accessibility that Electron currently brings to the party.
I've slowly started to remove Electron apps from my workflow. I used to use Atom, but I've switched to an paid for Sublime. The last two apps I have which use electron are Hyper and Slack. Hyper could go, but I really like the interface and Slack probably isn't going anywhere.
Real-time update:
I just checked Activity Monitor and Hyper is leading average energy impact followed by Xcode. Looks like I might be switching back to iTerm this weekend.
It runs Javascript! You can tune and theme it with CSS and JS!
That's actually the biggest selling point. I couldn't imagine using Hyper: I open terminals very often and waiting for Chrome to load when I need to just run a command would be very exhausting.
Honestly, and I know this is stupid, it just looks better and can be customized a bit more. Since I really should be more focused on performance, I'm going to switch to either iTerm or Terminal.
I won't touch these kind of apps until Servo is here, with 60 FPS animations. If they can deliver that it will be a game changer.
I find disgusting that Electron (or even UWP apps) can't do that on PCs with high-end hardware. A simple laggy fade effect on a modal and my eyes start rolling to the back of my head.
Electron has its place, but I'm not entirely certain touting Electron-powered text editors is a satisfactory success story. The success story is on the business side, IMO: it is another write once, deploy everywhere mechanism. Text editors are a very personal choice, but if I had to choose between an Electron-based text editor or Emacs in say, a developing world context, Emacs would win every time because re-purposing a 5+ year old laptop that only gets power from a solar panel is feasible with Emacs, at the cost of a steep learning curve. There are always tradeoffs.
Electron is very suitable for the particular contexts that it fits within, and OP made some salient points that there are some settings where it clashes with user demands. For the paying market that say, Slack cares about though, they are not sensitive to the tradeoffs made to run Electron underneath to the point that it hurts Slack's revenue to a level Slack cares about. This opens up an opportunity for someone else to step in and take the niche that Slack has currently declined to occupy, and that's not a bad outcome.
I always thought Electron was a great idea, but it definitely seems like something that should only be used for prototyping.
There's some excellent software that uses it, but using the Chromium browser as a runtime is a dirty half-measure. I hope they're trying to pare it down in future releases and make an effort to utilize host-OS resources.
I get the idea of Electron Apps having some hate for the performance. I mean if I have to open a large SQL file (> 250MB) and compare the performance between Atom and Sublime... well the difference will be day and night.
But there are a few differences between Flash and Electron that are not small. I mean the first thing is, Electron is open source in a open Standard, and have a fast development cycles to fix performance and security issues.
I think it's like a PHP situation. Electron is easy to use and sells itself as a cheap way to build apps, so this attracts lazy developers so we have a lot of problems, but that doesn't mean the technology is bad. But this is not a Electron problem, I mean web pages right now are heavy and slow for nor real reason. We need better fron-end developers.
I love VS Code, Hyper, and others, so maybe I'm biased, but I think Electron will be a interesting option to make desktop Apps something again.
Sorry I was vague, and yeah you're right they have never stooped.
I was thinking more in the Hype thing for new developers. You know like a small Renaissance in the Desktop UI/UX deparment, you know would be cool see beautiful desktop Apps in sites like Behance, Dribbble, etc spotting the first places, instead of the classic App with default OS UI or weird adapted ports of Mobile apps.
All nice comments from the author. Good ideas, except that most of the time these should come from upper-management: security and performance? They are additional features. We'll bother with them later.
Lots of developers have great ideas when they are given space, meaning when it's in the "sprint". Some developers simply don't know about the existence of benchmark tools, etc., but, by experience, many of them know how to google.
What matters is 1) time-to-market, 2) it's swooshy enough, 3) it does what it's supposed to do.
I may also completely wrong: it's not always management to be bad here. Sometimes, it's a "bunch" of people who think they are doing the right thing (like choosing a technology instead of another). Management can't always be blamed for it (of course not) - especially when one of the people choosing is trustworthy.
For something like a music player maybe electron it's not the best choice. But Slack might have several features where they need to parse and show html. Also, they're probably using webrtc for calls. On top of that, they can reuse most of their code which is a web app. That means less bugs and if they fix a security issue in the web app they also fix the desktop/electron app.
I wonder why the author doesn't just use the web app in chrome. The notifications works pretty well.
Personally, I prefer the performance penalty and enjoy apps in Linux than having great desktop apps that only work on Windows and/or Mac. It would be great to not have to choose but we all have limited resources and Linux often doesn't make it in native desktop apps.
On macOS, the alternative would be to use Fluid[1]. You can build mini-apps from a lot of websites and the footprint is very little. (No affiliation, just a happy user)
Unless I'm missing something, isn't that just wrapping the webpage in an embedded WebView? If so its basically doing the same thing as electron, except using Safari instead of Chrome and not giving the app any native API access.
This helps in 2 ways:
- Safari is less of a resource hog than chrome
- It avoids the huge 380 meg download of electron
But it doesn't solve the runtime problems. The app is still running inside a VM (safari), so its still going to be way slower than its native equivalent and it'll use way more memory. Also in a real browser background tabs get throttled in dozens of ways. But I bet none of that throttling happens via Fluid, because even background windows can be visible at any time on macos.
I'd be curious to see a quick comparison of CPU and RAM usage of slack-for-desktop and slack-in-fluid if anyone is willing to give it a whirl. I'd do it myself except I deleted slack after writing that blog post.
This app provides video communication, screen sharing and chat so is comparable with the Slack, Skype and others.
Sciter core is a single dll of 5-8 mb in size (StartMeeting uses it as a static library ).
Sciter does not create any processes or even threads (modulo HTTP client that uses thread pool). StartMeeting runs the same UI on all supported desktop platforms: Win/Mac/Lin.
Electron as is, consumes relatively more resources than QT and it's obvious because uses Chromium under the scene. But this is not the only reason for a slow electron based program. Code is the most important thing in any application and it's the primary cause of bad performance. A well writen and optimized application will have a good performance, no matters on which platform is based (good ones, obviously). "Electron is slow" is like "Java is slow" right now. Do you want a probe of a well writen electron app? Check VS Code; it's fast, it have a good performance and consumes a lot less resources than Atom, for example.
yeah yeah. It's bad. So big. So slow. So bloated; so... What's your alternative?
I don't see any meaningful suggestions in this article, just complaints.
You don't like how resource intensive electron apps are? Well, don't use them. If its really a big deal, people not using the apps will inform the people making the apps that they're bad.
That's not happening, so clearly it's not a big deal for most people.
Still... things could always be better in a perfect world.
Are you building desktop applications? What are you using for it then, and whats your cross platform perf story like? How long do cross platform releases take you? What are you paying for your tools and tooling?
Here's some irony for you: You really need an SSD in a modern PC - largely because of exactly this sort of insane bloat - and as a consequence, no, disk space isn't so cheap anymore.
On Windows I was a huge proponent of Chrome's "save to desktop" feature, which basically gave me the same experience of a native app (separate window, no window chrome, pinnable to start and taskbar, notifications, links open in separate window, etc).
I have recently switched to Mac and I miss this feature so much. I have found https://applicationize.me/ but it's not seamless as "save to desktop".
I wonder why they dropped it from the Mac version of Chrome...
From what I understand, a barebones JS-on-desktop framework at minimum needs blink, V8 (or equivalents) and some custom bridges to provide native APIs to JS, right?
I'm not going to offer an opinion, but just anecdotal evidence. We don't use Slack, but since we have Office 365 I was tasked with evaluating if Microsoft Teams was something we should start using instead of Skype, etc.
I have advised to wait. I was seeing similar metrics to what OP is describing where the Teams Client was using 200+ Mb of RAM (many times more than VISUAL STUDIO).
Also the UI seemed laggy. I'm not 100% sure it is Electron, but the installer and interface seemed as much.
I would prefer progressive web applications, which are stored in a cache and run in the available "browser" of the system, might it be Chrome, Safari, Firefox, or Edge.
Good article. I've almost always had slow computers... My current cell phone is faster than my netbook, with more RAM too. So I know the pain. So please give everyone a break. My internet access isn't crap either, but when browsing the web is painful to the point where the only thing running on your 'desktop' machine is the browser, there's a big problem. Not only the machine, but developers' mentality.
I disagree with the "flash" sentiment. The biggest disadvantage of Flash was and is that it's closed-source. Which means it's likely still filled with exploits waiting to be exploited. Also, it could not be ported to any other platform by the community.
Electron, on the other hand, is open source and can be built for a wide variety of systems and CPU architectures, as well as it can be audited for security issues.
There is competition, for example between Slack's electron app and their website, or between Sublime, Atom, and VS Code. It seems like the author of this post doesn't trust users to choose memory usage and battery life over other things.
I expect that's correct - they are sometimes less important to users than other things. Emacs is tiny now, but at one time it was considered a memory hog and people kept using it.
While I love Node.js and its environment, I totally agree with this post. I don't have the Slack client installed for this reason and only use Electron when I write code. React Native seems like a nice middle ground: Javascript, but compiled to native.
PS, I notice that the author is using Ghost for the blog, so I am guessing the author is in the same line (like Node.js but not Electron).
Just to note, React Native doesn't compile Javascript to native code. It uses Javascript running in a Javascript engine (JavascriptCore usually) to control native views through a bridge. You're still running Javascript on user's machines, but the UI is native.
Not sure what line that is but Ghost's desktop app is definitely Electron. For the record, it was also built handedly by one open source contributor (Felix Rieseberg) and absolutely would not exist if not for Electron.
There actually is a Flash for the desktop. It's called Adobe AIR. And it suffers from the same CPU/energy hog problems.
I do wish big, well-funded companies would invest is proper native apps. I get that making it easy to crank out cross-platform apps has benefits, but is it really too much to ask for nice native implementations of our most important tools?
There was some effort in the past to allow browsers to provide desktop app-like experiences for webapps. Progressive Web Apps are doing similar, though the target is very strongly toward mobile. It would be more efficient for disk space, though likely not CPU/RAM, to just make webapps be able to work more like desktop apps.
It seems to me that there is not much to worried about ... it is an ecosystem ... things would naturally evolve ... if electron happens to consume too much power n conserving power is an important concern ... the developers will need to do the right thing .. otherwise the app developed will not get used by that many ppl ...
Lately I've been playing around with Red language and their view feature. Easiest way I've created an interface before. The Red language is really interesting and cool, but their view construct is the coolest. If you haven't played around with it, it's worth about try at least.
When I profile Slack on x.slack.com, it seems to be pretty good about being "idle". The flame chart is mostly empty. As the article also points out, I think this is a problem with Electron/Chrome. Just want to be sure the Slack devs get their credit here.
I understand why you'd want to wring every last efficiency out of your computer, but I run Slack, Spotify, and many windows of VS Code on my bottom of the line MacBook all day, frequently on battery power, and don't have a problem. What's the big deal?
Btw, I can tell you exactly what the "Preventing Sleep" is all about. I'm 100% positive there's a bug in Chrome's WebRTC stack that causes that to happen.
Fire up Chrome, doesn't happen. Go on a Hangout, yip "Preventing Sleep".
I think Electron is really great for developing an MVP. But yeah, Slack should probably build their next version with Visual Studio and Xcode the way Microsoft and Apple intend for people to build apps for those platforms.
So minimize your use of the Electron APIs. And then when someone releases a leaner Javascript runtime, port to that, keeping 90% of your application intact.
This would be a good idea even if Electron didn't have these problems.
I'd take this a step further and posit that JavaScript is the modern equivalent of Ethernet (the original protocol): simple enough to actually work despite all its shortcomings, hence doomed to success.
> 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'm not sure I've seen React Native used this way, but it probably exists somewhere out there.) People opt for Electron because it's holistic, battle-tested and easy to use.
I'm not excusing Electron's (many) flaws. There should be a concerted effort by the team to "disable" parts of Chrome that don't make sense for native apps, or at the very least let it be configurable. He's right, there's no reason Slack should have access to the GamePad API (or WebVR, etc.)
My overall point is that like everything, productivity of the end-user is always going to have some kind of trade-off with the productivity of the developer (or more specifically, the business considerations of the company.) Always. We don't write assembly anymore even though the apps would be a gajillion times faster than writing Electron-wrapped web apps.
Now, complaining that Electron/Slack/etc. are CPU/battery-hungry is completely valid and a good discussion to have, but you only get me to jump into the HN comments once you start delivering global developer edicts with no regard for the other considerations those projects have made.
> The other sad fact is that even most developers have no idea that this is even happening on their computers. They run slack but have no idea how hungry it is. As a developer its your responsibility to know this stuff.
I'm not sure I completely agree here, "responsibility" is a bit heavy of a word.
> Users: Please complain more about slow programs. Its 2016. We carry supercomputers in our pockets. Its simply not ok for apps to be sluggish.
Wait, this is the first instance (edit- second, but mentioned in passing in the previous paragraph) the author mentions "sluggishness" as a metric. IMO sticking with measurable stats like CPU and battery life are better because you have no idea if someone other than yourself experiences or even perceives this sluggishness. What about non-developers at BigCo that only run Chrome, Slack, Spotify, and Word? Would they feel sluggishness? I would guess not, since I rarely experience it as a developer on a Macbook using Chrome, Slack and Atom. (Things only get dicey when I start doing Vagrant stuff.)
> Also all you web devs: Go learn C or Rust or something. Your program runs on a computer. Until you know how that computer works, you're doomed.
Doomed to have a successful career? I prefer being "doomed" then. (For the record, I do know
> And until then get off my lawn shakes fist.
Aaaaand there we go. Maybe next time don't bury the lede? :P
> Oh, and read this talk on the website obesity crisis. Its very funny. And very sad. And very true.
This is an entirely separate concern (and one I agree with.) Heavy web pages are heavy because they are multi-megabytes to download, not because their "installed" wrapper (Chrome) is hundreds of megabytes.
> 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 productivity as a developer is hindered by those things. I have no desire to write JavaScript: I'd rather write Lisp, or Go, or Python.
Yes, it's possible — and preferable! — to uninstall Slack, Atom, Chrome and Spotify. Try it today.
I find it interesting how many devs I have met in the last few years who seem so tied to GUI's... as a sysadmin who lives mostly on the cli, I never understood it.
Side note; many of said devs also used OSX instead of linux, maybe some correlation there.
Emacs is where it's at. Really, it's my main operating system. Email, org-mode, erc for IRC, RSS reader, editor, twitTER, eww (for some things like documentation), dired for folder management etc. Currently working on learning ledger.
"Using a free version of vi is not a sin but a penance."
This comment is semi-ironic to me because traditionally Emacs had the reputation of being bloated and slow compared to its competitors. Maybe in a few years hardware will similarly catch up to Electron?
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 load more than 3 scripts. Often I come across sites trying to run 20+. That's why the web is heavy today, not because the sites are huge to download.
You're not wrong, but the article the author linked to[1] specifically deals with the problem of modern web page size bloat (which is why it feels out of place to the rest of the article, IMO.)
I don't think that apps necessarily chose it because of the reasons you mentioned. It is most definitely due to productivity, but there are ways to mitigate the CPU and battery usage -- I often have Spotify open on my Mac and it really doesn't use much CPU (often less than either Safari or Docker), and it doesn't suffer from poor performance most of the time. I would say that while Electron apps, as a whole, are generally worse than a native app, there are ways around the issues that plague some of them that depend on the developer(s). For example, VSCode and Spotify having pretty good performance and not hogging CPU, while Slack and Atom the opposite.
I just noticed this morning that VSCode has started causing my MBP's fans to spin up whenever I type in it. I spent about an hour updating my MacVim setup to replace it.
Flash player was A pretty minimal download and was not a resource hog. Shitty punch the monkey ads hacked together by people who couldn't program were the CPU killers
Electron is amazing. It's the best thing to happen to desktop since I can remember.
Yeah it makes slow apps, but these apps wouldn't be possible otherwise. It's perfect for prototyping new exciting ideas, it's fun to use, and there's no alternative.
When your app get super popular maybe you should rewrite it in gross native code though.
"The modern web makes me want to throw up", "Electron is flash for the desktop", "Databases have failed the web" — wow... author does not look very happy with the state of the web development today.
Why not? People do native mobile apps despite those platforms being more or less at parity, while desktops are overwhelmingly just one platform. The tools to write cross platform mobile apps that aren't just a browser with lipstick (like xamarin) exist for both desktop and desktop.
Then don't, it's really wasteful to have webdevs write desktop apps using Electron. I don't see a gain over using a webpage. I use slack this way and I don't see any problems.
No one would bother writing Electron app if there was no demand. Most users, (even tech savvy users) prefer using Electron Slack instead of keeping the webapp open in a browser.
So I've liked what I've heard about Progressive web apps, but I was wondering if there is a solution for desktop? can you create a native icon that opens a new window with a PWA?
Quite the opposite, they wanted to prevent vendor lock-in, so they pushed for standards like service workers and NaCL that eliminate the need for Chrome Apps.
But aren't those two only for getting better performance for web apps? Chrome Apps actually help getting a web app integrated into the OS, I don't see where (P)NaCl helps me with that.
I was just trying to look into this, I can't see a way for this to happen on a desktop, is my google-fu broken or is coming later. I was also looking for a desktop icon (or file or whatever).
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.
My point was they could convert their web applications to Chrome Apps which has better native api support and experience if Chrome Apps could become a thing.
That's the entire rationale behind e.g. using python or php on the backend. Oh, the requests are IO-bound, we don't need to use a cumbersome language like C++ or Java to develop our backend, we'll just throw more cores at it if it gets too slow. Developer time will always be the first thing to be optimised, not least because the first to ship win and the first to ship is the one with the fastest development stack.
So many divisive opinions here, but in case anyone reads this far down, here's my 2 cents:
- Yes, desktop apps existed before Electron. But the top comment is right. How many desktop apps. NOT utilities but full featured apps (like Spotify and Atom) that you loved either got swallowed up by other companies (Mailbox) or discontinued due to "lack of use" (read: lack of profitability). I'm sure if you dig deep you can remember quite a few...
I'm a game developer with a background in C++. But I'm developing my company's prototype in electron. This is because I can do it myself without needing to tap a bunch of people to help and find funding. I can bootstrap. Electron allows this and it's incredible. I couldn't make a cross platform game engine in a year on three platforms using native. Maybe you can and you're just a better human/coder than me (but seriously, email me in a year with your progress!) but Electron is allowing it.
What does this allow? This allows me to release a product (yay) and maintain a product easily (double yay!) and when you guys don't throw money at me.... I can KEEP maintaining it because of my low overhead. With native code and a staff of 20 I would be forced to shut down the product.
I can't speak for Spotify or Slack or any of the people mentioned (yes I know Spotify isn't using electron) but for a small company of 1 and a half people Electron is allowing innovation and project completion in a way that nothing else is for me. It's a great door to open to allow future optimizations. And hey, maybe Electron will slim down too... give it time. Remember how bad Windows development was? No? I do. But .NET has come a long way, maybe electron will too. If not, we can always port!
If you're doing a 2D game, won't SDL with Python and the assorted ecosystem be better than react native? IIRC the sprite operations are even accelerated with OpenGL these days.
1) After years of C++ in games, I've written a lot of JS. I believe in where the language is going and I saw an opportunity to use JS to write a cross platform 2-D game engine with low overhead and went for it
2) Unity lends itself very well to 3D games in my experience, or 3-D games with a fixed camera to look 2D. So this would likely lead to overhead involving "Well, let's just render the 2-d components in 3-d" which easily spirals into needing a modeler, a rigger, an animator, a concept artist and a programmer MINIMUM to run the game. As it stands now I need a 2-D artist and a single dev.
Oh, I lied:
3) I can't create a business as easily marketing a unity mod than marketing a stand alone FOCUSED engine on one type of game. But if my plan fails, I can still write a unity renderer for my game since most of my logic is serverside and platform agnostic. So who knows! :)
I don't get this article. What does the author propose instead? Cross-platform is tough to get right and it places much burden on developers focusing on application logic for his niche.
I don't think it's fair to label Electron as Flash just because it's doing things in the background that Chromium authorizes. We know that Chrome Browser and it's underlying technology is in use everywhere and anyone can open it up and take a peek or embed Chromium in their C++ projects.
On top of that Electron takes care of cross-platform issues, and it's performance is under constant iteration by Google, so you have a much better chance of getting to market without having to do the plumbing work.
While I share the concern that Electron seems to spin up fan on my Macbook, it's quite rare that I don't think much about it.
If anything, Electron improves desktop user experience by leveraging web technology. I shudder to think what Slack will look like if it was done with Java Swing. But in some HN'ers mind, that is the "right" way of building this world. I see a big split in thinking amongst the demographic well marinated by Java Is Everywhere (TM) vs Javascript is Everywhere.
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 yourself, but there's so much less magic involved.
I'd like to suggest an edit to two kinds of programmers: There are programmers that care about the quality, elegance, and beauty of their code, and there are programmers who just want to make the most people happy as fast as possible. Fine dining vs fast food.
> programmers that care about the quality, elegance, and beauty of their code
this seems less like fine dining, and more like a fancy kitchen. this is much more about the chef (though there are possibly secondary effects for diners).
There's a difference between writing maintainable code and premature optimization. Experience is knowing the difference between you can and you should.
It is easy to talk about premature optimization in a world like ours; the hardware industry spits products twice as fast and generous in regards to memory every three years or so, to keep up with software designed by programmers who think likewise. You just replace your two-year old laptop with 4GB of RAM---which became unusable all of a sudden because now it keeps hitting virtual memory, which is I/O expensive---for one with 8GB of RAM.
If you consider hardware is a commodity and the cost of opportunity for replacing hardware instead of optimizing software is worth it, then formulate it better.
One may object by saying that the burden on hardware resources is higher because we consume more data, which is partially right. Although I don't intend to give a thorough objection here, please consider those two points:
- The payload fraction is larger in multimedia applications, for sure, but I can't see a reason why the "propellant mass fraction" equivalent in software should be bigger than it was, for example, 10 years ago. If we consider text-only data as an example, we notice that the propellant mass fraction increased as well.
- Higher level languages undeniably consume more resources by orders of magnitude; hardware frequencies must keep up by orders of magnitude as well.
The desktop is a dying platform, and if you're on it you can probably afford the overhead. From a global perspective if you're after accessability you'd be targeting the web and android. Both of which lend themselves nicely to react/react-native. And if you already have this architecture you can package it for desktop basically for free and integrate with the needed platform features that way, along with an upgrade strategy if you use react-native for OSX/Win.
Just checked the all recent the crash reports saved on my Mac. Slack has crashed more than anything!
This is especially surprising because I'm currently writing a custom crash reporter and part of that was experimenting with the builtin crash reporter by crashing a test app.
Just to be clear Slack is ahead of everything, even my artificially induced crashes..
Funny how much of HN is happy to see people dismantle social contracts or break the law to "create value" in startups, always justified with the idea "people want a thing", but shit bricks if someone wants to spend more time worrying about the UX of an app than micromanaging bytes of memory.
"Dorks who care about programming, and programmers who care about creating deliverable value."
I'd rather have 95% of the code on my machines written by those from the former camp.
And if you think about it, the 5% of it is the stuff that comes & goes. Slack? Big now, but will anyone remember it in 5 years after the next big thing?
And what was organizing your memory regions as you posted that? Some piece of javascript written by some hipster second week out of a hacker bootcamp or a properly designed malloc implementation?
You're countering by arguing that JS is a well engineered tool created by highly experienced engineers? I guess we'll just have to agree to violently agree.
I don't think developers have anything to do here. There are two kinds of companies: those which don't care for quality, security, performance, good/evil and those which are bankrupt, because they were constrained by those ideas while their competitors were not.
That leads to a very strange sentence since 'programmer' is already used. More importantly 'programmer' doesn't work well as "thing you don't want to be". Instead you've left that category of word entirely. "Dork" is about as minimally-derogatory as you can get without losing the meaning entirely. And it doesn't feed any kind of discrimination.
You don't actually need to use derogatory words at all to win the argument. In fact, your more likely to change a person's mind if you avoid personal attacks like 'dork' and 'neckbeard bullshit'.
One problem, you cant optimize at all with electron, you are stuck with shoving a complete web browser solution into your program to make a GUI.
You are stuck with a massive amount of dependencies (html/css parser, javascript VM...) to various massive projects for what, easy cross platform support? Sure cross platform GUI's have been a problem, but any developer can agree that dependency to this level within professional code is a great way to cause a massive amount of headache from required library changes, bugs and memory leaks that you have NO control over due to it not being your code, required security updates that require code refactoring for no fault of your own, etc.
People keep bringing this up because it is a bad solution to a large problem. Maybe the reason its being rehashed so much is because there is truth to what is being said.
I would try finding a graphics library such as opengl, and build a UI in the spirit of something like:
Your solution to memory leaks is using a lower-level language? I should probably stop reading there..
How do you make SSL connections? How do you parse JSON api's? How do you play audio, integrate with platform features (menu bars, dock dropping etc)? How do you create P2P WebRTC connections that capture camera and mic inputs? Let me guess, you have libraries for that.
People keep bringing this up because they're insecure about their role as programmers in a world where creating useful functionality is becoming easier and more accessable. People keep bringing this up because they don't comprehend what business requirements actually are and the cost of rolling your own technology and battle testing it.
I promise you. We're not all stupid. That's all I'm asking of people to consider before they start solving all the world's problems.
> Your solution to memory leaks is using a lower-level language? I should probably stop reading there..
Lower level than sandboxing into a js VM? yes. Writing everything in assembly, or in an unmanaged language? no. Adding unnecessary complexity to a program increases possibilities of bugs, which in this case, will be outside of your control. And this is a perfect example of unnecessary complexity.
> How do you make SSL connections? How do you parse JSON api's? How do you play audio, integrate with platform features (menu bars, dock dropping etc)? How do you create P2P WebRTC connections that capture camera and mic inputs? Let me guess, you have libraries for that.
Simple libraries that intend on doing the job and getting out of your way, yes. I wasn't aware you needed to embed a web browser to parse a json string, or to establish an SSL connection? There is a large difference between what a library is, and what electron aims to be... There will always be system apis that you will have to interface with, these are apples and oranges.
> People keep bringing this up because they're insecure about their role as programmers in a world where creating useful functionality is becoming easier and more accessable. People keep bringing this up because they don't comprehend what business requirements actually are and the cost of rolling your own technology and battle testing it.
Thank you for reminding me what the phrase "argumentum ad-hominem" means.
> I promise you. We're not all stupid. That's all I'm asking of people to consider before they start solving all the world's problems.
I can't speak for anyone else but I don't believe anyone who finds electron appealing is stupid. I am sure these people are more than capable programmers, and electron is a very appealing way for a web-based product to be able to quickly produce and distribute a desktop client. Most just desire for people to understand that most large-scale projects will dig their own graves in the promises of cross platform support and a fast production cycle, which has been a growing trend in software development for quite a few years now.
The basic premise for this entire blog post is that people who use electron don't know that lower level technologies exist.
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.
So yes, this is in-fact an ad-hominem attack. There's a certain type of person who rehashes this old stupid argument. A few years ago they'd berate you for using a LAMP stack to set up your clients wordpress blog. A couple years ago they'd give you shit for using Node on the server and not being a "real" developer.
Point being, if the author of this blog post resonates with you - I can guarantee you with a high degree of certainty that I can fit your world view in a tiny little box.
Having trouble figuring out what "dork", "hipster", and "neckbeard" have in common other than the latter two terms both having become completely meaningless due to abuse and overuse.
Well said. Being able to write an application and have it work on multiple platforms without any major UI inconsistencies or UX idiosyncrasies is a major benefit.
You're joking, right? Electron apps are fully inconsistent with any environment they live in. Want right-click? Sorry. Platform-standard control elements or animations? Nope.
Reminds me of some of the worst excesses[1] of AAA Windows software - now available on Mac.
Edit: I think it's ironic that Macs were criticized for years for having single-button mice but now developers are more than happy to ship apps with no right-click support at all.
I'll admit my experience with electron apps is limited to Slack - where right clicking. Gives you "Copy Link" and "Go To Link". Having said that, do you have an example of an electron app that's not a design misfit within MacOS and Windows?
Most users will never notice this, and if some problem is solved using Electron well then Electron solved the problem, life goes on. If you don't like an app or how it behaves then just don't use it.
It's not flash for the desktop, the author just wants to say something mean about electron cause he's angry.
The flash analogy doesn't hold in any way. "Well, flash was errr ummm BAD you know.... and this electron thing it's BAD too .... err umm SAME AS FLASH!
I am a young programmer, student, front end developer/designer, with some knowledge of languages such as java, php.
I am developing one electron app, and it is going great. And I don't even know javascript that much. But in my case, usage of browser engine is essential, since it has to do with rendering HTML and so on. I have less than 1000 lines of javascript and almost everything was working after 2 weeks.
It is not that big of a project anyway, but from the begging I knew that it should be fairly easy and doable.
In fact, I can imagine that I could do so many kinds of apps with electron, and I can easily see how I would approach it.
Let's say music player. No problem. I believe that electron can easily play media, and it would all look great. Or some productivity tool, or note taking app. Working with files, editing text files, even viewing documents like .pdf would be easy (would just use some plugin). Or even embedding youtube videos in notes would be easy. And all that with easy control of layout and great rendering of fonts and images, plus animations.
With little knowledge of front end stuff, and some general programming principles, you can already see how you could build app on the top of electron, which is a platform everyone here knows without even trying. It makes me feel kind of powerful to be able to do such a nice apps myself.
but if there was something exciting like red-lang with easy to do custom UI ( if needed ) and with some ecosystem around it, i would definitely look into it
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. And as for Qt, Qt has existed for over two decades - if its massive "Beatles walking off the plane" moment hasn't happened by then, sorry, it's not gonna.
But now? People are making all kinds of great new apps, and more often than not, they come out on all three platforms. People are excited about the Desktop again - Electron is so good it's single-handedly revitalizing the platform that two of the largest tech companies in the world are behind, yet couldn't do.
That is a Big Deal.