People hate on electron, but it's a pretty amazing piece of tech if you ask me. I can turn a browser game into a steam game with basically no effort which is nice because browsers change over time and electron helps you get a working offline snapshot of something you created.
I used VS Code beta and it was slow… I remember an issue in the beginning where the cursor was refreshing at 60fps, causing huge delays. The software evolved really well over the years.
Your specific example highlights the performance difference between VS Code and Atom very nicely, and VS Code is an absolute gem of engineering.
But, for large files, I am not sure it has much to do with Electron in this specific case. Notepad is about as native as they come, and famously struggled with large files - anything over a few dozen KB - for a few decades (maybe still today?). Basically, if you're going to do seriously stupid stuff in an app's code, like loading the entire file upfront and applying word-wrapping, it doesn't really matter if you're doing it 2-5x faster, it will still take too long.
Loading large files need not have anything with Electron. The file can live in another child process either fully in memory or swapped to the filesystem. When you scroll you can load the required contents into the view (Electron). For searching you can build index or even perform search on the swap and show results accordingly.. It's complex but can be done with Electron (as proved by VSCode).
Electron is essentially an operating system that runs on every operating system, so you can target just a single OS and your application works everywhere.
Yes, and that's exactly what people hate about it: every application written in Electron lugs around its own copy of this OS. You can imagine why this might not be a good idea, especially for applications designed to run in the background, like the Slack client. For me, it was a godsend when Slack decided that my Linux version was too old to support and the client stopped working. Then I switched to the in-browser version and never looked back, even after upgrading to a new machine. My laptop's CPU and memory usage are still thanking me...
In the Electron case, it’s wasteful to some degree. Especially if the app is not doing much with files/storage etc. For VSCode it makes sense to not run in the browser but for Slack, not so much.
But generally I feel like there’s too much overlap between OS, browsers, IDEs and language runtimes (JVM, V8/Node etc.). It gets worse if you add containers and VMs.
I wonder how many garbage collectors, file abstractions, JITs, databases, schedulers, GUI engines, indexers and so on are running on my machine. How many flavors and versions of essentially the same libraries are used.
There is no unified vision, of what an OS/runtime/IDE/browser should be. There’s not even a common understanding!
> I wonder how many garbage collectors, file abstractions, JITs, databases, schedulers, GUI engines, indexers and so on are running on my machine
I tried to picture clusters of information as they moved through the computer. What did they look like? Ships? Motorcycles? Were the circuits like freeways? I kept dreaming of a world I thought I'd never see. And then one day …
Teams holds the crown as far as terrible electron apps.
I actually can't run it locally (absurd tech policies), and I am so glad to never run it at all ever. Just easier to load it into an isolated browser tab when I need it, Zoom is so superior it's not even funny...
With regards to various applications, the question seems it is not if Electron is fit for them, but if they really need to be a "native application". Why does a chat application need to have it's own native package and can't run in a browser tab? With all the recent development on WebRTC and even File System Access API, can't really find a sole reason* (but feel free to point them out) for 99% of Electron applications: seems some kind of developer ego "we are not just a[nother] web app, we are native".
* Looking at an arbitrary article, "Why does Slack desktop app use Electron?" [1], the answer seems mostly aesthetics, "faster performance [citation needed] and the frameless look".
When you start building an app that does anything more than what a typical website does – basic stuff like keeping some persistent files, drag and drop, notifications, minimize to tray, using threads, the html5 apis are widely insufficient, performs poorly or – in the case of webrtc – massively over-complicated). They’re (rightfully) designed for the browser with its ephemeral untrusted model.
It’s a shame, because cross platform app building, distribution and updates is a shitshow, even with electron, putting extra labor on the developers, so neither party is happy.
That said, some apps should really be web apps, but are still bundled as desktop apps purely for the frameless “premium” experience, and I assume to not be lost among 100s of tabs. It would be great if there was better browser support for allowing users to “install” web apps, but right now the support for that is pretty poor in terms of UX.
Thought the same. So was using teams and slack in the browser. But at least for new m1 Mac, resources for running a tab and a seperate electron app are pretty similar. It's scary how much memory certain latent tabs use, especially with video ads running.
What's the big deal? Surely you have at least 512 GB of RAM, not the typical 1 TB for good measure these days. Modern computers with these bare minimum hardware requirements can handle a few electron apps.
Kind of defeats the point of having separate operating systems. I think the best environment an OS creates where apps are deigned around that OS is the value an OS brings to the table.
The selling point of Electron is that it is cross platform, but that does come at a cost. The cost is essentially running a separate instance of Chrome for every application you run that is built with it. The runtime overhead for that is significant. It is a tradeoff that works for some applications, but there are a huge number of applications for which it makes them resource-sucking pigs that do not provide value significant enough to justify the resources they consume.
The source of most of complaining about Electron and companies/developers choosing to use it is that it's not just an ordinary trade-off. The gains - being cross-platform - accrue mostly to the producer side (cheaper to develop and maintain). The costs - resource use at runtime - happens entirely on the consumer side.
In other words, it's a typical case of costs being externalized, making the supposed trade-off be a "free win" instead. Since software resists commoditization, consumers don't even have a way to pass those costs back onto the vendor (by e.g. leaving for a competitor).
Java can perform well, and even with all the enterprizey bullshit, it still performs much better than your run of the mill, best practices follower javascript program.
Javascript actually can perform well, not nearly as well as java can, but it doesn't have to be as bad as what you see on most electron applications. But it's not trivial to make it so.
Yeah, I wasn't really thinking of performance. I was thinking of the dislike I have for working with Java. Past experiences with "enterprizey" Java is the worst. AbstractWidgetFactoryBuilderLoaderMaker, etc.
Well, all the discussion about Atom, all around we is about performance. Even when the people in the discussion don't actually notice this.
But I'd put javascript and java on the same cohort when talk about usability (programability?, what name do I use here?). They are not as bad to be dangerous, but neither is any good either. Anyway, the JVM allows some other languages that don't solve all the problems but bring you some expressivity (honestly, I have no idea if this is a positive), while electron can work with typescript (much better than javascript) and can run wasm (what currently implies on rust, what means low expressivity but high confidence on your code).
There was a time when I had an equal revulsion toward languages with a Lisp-like syntax. However, dissatisfaction with the limitations of most other programming languages, and the influence of a bunch of very smart and effective developers was enough to convince me to give them another look (and try to be open minded about it).
As countless others have said before me, the parens really do cease to be an issue over time (and not really very long of a time either). The power and flexibility gained by writing code in Lisp/Scheme/Clojure or other Lisp dialects really is worth the effort, in my opinion. I'm not saying there are no bumps in the road - there definitely are. However, I have zero regrets about taking the time to learn those languages. Even if I never write another line of code in any of them again, it will still have been worth the effort.
There was node-webkit (nowadays called nw.js) that predate electron by quite some times. I remember know about it precisely because I was playing games that was developed with it.
1. Have your application look and act like a standalone application rather than a webpage—Chrome tried to support this with application shortcuts (or whatever they were called), but it never worked well enough
2. Give your application access to native APIs and capabilities that you can't get through the browser, like direct filesystem access
But it doesn’t act like an application. Most of the OS right click services, keyboard shortcuts, menu items are all missing. Accessibility tools don’t work.
It doesn't feel like one either. It feels like a shitty web page, and it costs 500$ to run. I can run apps in python and they don't feel the same way, never mind native.
They are talking in the context of games though, for which there aren’t such strong conventions, besides lives in your applications folder, and runs full screen.
This makes sense from the perspective of the individual developer, but it's also a sad reflection of the sorry state of technology that the only way to be sure a website will work in 5 years is by shipping your own copy of the browser.
