Electron, a popular framework that allows developers to write code once and deploy on multiple platforms like Mac, Windows, and Linux, has been u...
For further actions, you may consider blocking this person and/or reporting abuse
Software devs who ignore the engineering principles of yesterday in favor of hogging resources because it's convenient for you are what's wrong with the world today. People like you are dragging down the software industry by adding garbage to your apps faster than hardware can expand. This needs to stop. God knows what amazing things we would have now if everyone programmed like it was the 80s instead of starting 5 processes taking 200MB of RAM and using 15% CPU for a hello world app.
Also congrats: reddit.com/r/programmingcirclejerk...
If everyone programmed like it was the 80s we'd have 1/1000th of the available software we have today because everyone would be programming in C and assembly, and having to completely rewrite their entire codebase to release it on a different platform. It's a double-edged sword. Electron is convenient, enables multi-platform releases from a single codebase, and runs flawlessly on every computer I own or use. Is their room for improvement? Hell yes there is. But trying to say that Electron apps are somehow "dragging down the software industry" (a claim I'd LOVE to see some data on, especially data that shows the software industry being dragged down by ANYTHING,) is just ridiculous.
IMHO, it's people who use phrases like "... are what's wrong with the world today" are, in large part, what's wrong with the world today. Get some perspective.
Hm. Isn't the Linux kernel written in C?
Don't blame the language, blame the coders. Today's programmers are making all of the same mistakes, and new ones, in Node and Ruby and Python.
Yeah, it is. My comment was not meant to bash C at all - C was my first programming language, and I think that some truly excellent software has been, and continues to be, written in C. My point was that "software isn't as good as it was in my day, when everything was in C or assembly!" is a rather rose-saturated view of the past, and ignores the mountains of good software that's been written with more modern languages.
In fact, I pretty much agree with your main point. VS Code, for example, is an electron app that starts up instantaneously, doesn't slow down when dozens of extensions are added to it, has a ton of functionality, and maintains a memory footprint of about 26MB when I have a 20k file project open. Atom is a bloated monstrosity compared to it, yet they're based on the same app wrapper package... so obviously the problem isn't actually electron (or, at least, not all electron).
Alexa, how to write an Operative System in jQuery
You just assume that the 80s had only primitive languages like assembly. Smalltalk came out in 1980, decades before "modern" languages like Java and JavaScript, and imo it's still a far better language than both of them.
Ah yes, and we all know of such smalltalk-based software masterworks like... uh... hmmm.
Actually, I've used smalltalk - had a class that used it at Georgia Tech - and while it's certainly an interesting language, and extremely useful for learning about OOP, you'll notice it's not actually very popular outside of research projects and other academia.
Also, I'm wondering what the point of your comment was. Yes, I know there were lots of programming languages that existed in the 80s. However, I was replying to a comment about how great software was in the 80s (HA!) because it was hand-crafted by skilled monks trained by the Dalia Lama using nothing but the finest assembly.
You're too young to remember them. Look here: wiki.c2.com/?WhatsBeenDoneInSmalltalk
In short: for example, the whole WIMP (Windows, Icons, Menu, Pointer) interface happened only because it was prototyped in XeroxParc using Smalltalk. And it wasn't resource hog crapware. It was light and snappy.
I notice on that link that the WIMP interface (which, admittedly, is a hell of a good example) is pretty much the only well-known project, and that was like 40 years ago... which kinda reinforces my point that People Don't Use Smalltalk unless they're in school.
I remember when we got our first IBM PC with 128K (yes, people really did useful stuff on 48K TRS-80s, Apple ][ various CP/M boxes).
My first reaction:
"128K! This is just going to lead to sloppy programming."
I was spot-f'ing-on then and its been repeated several times since.
No way I'd ever want to go back.
I'm not sure why anyone developing/using an electron app is shocked by its resource requirements. Modern browsers are basically a separate OS and runtime environment running in some other host environment (Win, Linux, MacOS).
How does that NOT consume vast amounts of resources?
Hi Jon, I invite you to check Nintendo64 games and architecture.
You'd say that's not related to the topic, but I think it does.
The most of N64 games are stored in 4MB, some of them finally came in 64MB.. And there was lots of textures, logic, among other things; CPU was 96Mhz and RAM just 4.5MB Rambus. Play those games were more complex than a desktop application to edit text, however, to execute Atom (for example) means lose at least 1GB of RAM..
Well programming in the current time has been forgotten, because everything is about time-to-market, but after that, companies forget to improve the logic of their apps, they continue adding more and more features without think in resources that these are consuming..
Do you want to build once and execute everywhere? Use Java.. As simple as that, it exists since 25 years ago and is one of the most mature technologies out there..
I don't hate Electron, however, it has to be improved urgently.. Frameworks are a double-edged sword..
I'm not surprised by it. I am, occasionally, surprised to find an app I'm interested in using is built on Electron. As soon as I find it is, I delete it. Because battery life matters.
According to Mozilla the most common number of RAM in the world is 4 GB and that is apparent in my country Pakistan. Most of the new laptops even come with 4 GB ram and people seldom upgrade. I was also using 4 GB ram till march when it no longer was able to carry all the web development tools in a smooth way and extended it with 12 GB. But since I have it now, doesn't mean this is getting standardized as there's just a very small proportion of programmers and gamers who will go to this extent.
Most of the people still use 4 GB in the world and RAM is a very expensive type of memory.
Also, Electron is a lot of Bloatware, on 4 GB ram it never works. Maybe you don't have to think about users all over the world but some people have to and for them performance and optimizations matter. Consider Slack, even though they have a pretty cool electron app, I don't have it installed, as it has a lot of overhead I did not need in any case and was unnecessarily playing a role in slowing down my computer. Their web app does all the things and is optimized, much smaller in size, it even has push notifications, so there's no need for me to install slack app.
Well... just because there's a trend toward 16 GB standard doesn't mean we're anywhere near that yet. And I assume you're talking about the upper segment of the US, right? In a lot of other places of the world (India, Africa, eastern Europe), even 8 GB of RAM can be a luxury.
I agree that Electron gets a lot of unnecessary hate, but the point about RAM just irked me :-P
Electron clearly has value as evidenced by Slack, Microsoft Teams, Atom, Webtorrent, and all the other inventive apps out there. However, there's a not insignificant amount of waste going on here if every electron app must have its own copy of chromium. Nobody needs a fully independent copy of Chrome just for an emoji picker.
I tried using Atom once on a computer with more than 4GB. It worked fine until I added more than one plugin, then there was visible interface lag between the time I hit a key and the letter appeared in the editor. In a world where tons of other editors get this right (Notepad++, Kate, Sublime, PHPStorm, VSCode, etc) there's clear evidence that Atom is just sub-par, and I think this can be attributed to Electron.
VSCode is also built on top of Electron, so I don't think Electron is the culprit of input lag.
Well, I wasn't trying out VSCode with any plugins, so it might still be Electron, and where I was using VSC was on a work computer with 16GB of RAM, so again, that would mask most issues.
But when I can even run a full blown IDE like PHPStorm of Netbeans and it runs faster on the same machine than Atom, I'd say that Atom has some issues...
It is a sad state of affairs when the best we can do with more ram is just run a text editor made with bad engineering. We should aim higher.
What the f*** are you talking about? Do you have any idea how much work has gone into both Atom and VSCode by hundreds, perhaps thousands of engineers? Surely some of which are more accomplished than you.
Not only that, but I would classify neither of those products as "text editors", and more along the line of extremely extensible IDEs, Atom for example has some 2000 more plugins than Sublime.
Finally here is a list of other applications that run on Electron, some of which were mentioned in this article and certainly more diverse than 'just a text editor.' If you can't contribute more than a strawman argument with no facts, why say anything at all?
electron.atom.io/apps/
Despite a richer ecosystem of plugins, Atom is fundamentally similar to Sublime. It's also significantly slower, consumes dramatically more memory, and is dramatically worse for battery life. The cases where it's noticeably slower, it's often so much slower that it is effectively incapable of performing the task at all. (Yes, opening and working with a million-plus-line file is a thing I do often enough that having to switch to vi or some other editor for it is a significant drawback.)
Further, I have yet to encounter any set of plugins in Atom that are even close to being compelling enough to justify giving up a large fraction of my on-battery time.
Definitely no arguments about power consumption, and will concede that it does fall over on really big files - I will occasionally accidentally click on a compiled JS file or something and immediately regret it because Atom slows to a crawl. Come to think of it, I might write an extension for that.
I'm happy to have a discussion about how Electron can be improved or what pain points are for developers. What I cannot stand are ad hominem attacks on the language or the developers that contribute, simply because somebody has had a bad experience on open-source software that they are using for free.
For instance, I would really love to see a shared runtime among all apps. Sure targeting your own specific runtime by bundling it in is great for compatibility because you always know what the behavior will be; but I would argue for the vast majority of use cases it is not necessary. This would potentially save on storage and a bit of memory due to all of them sharing the master process.
FWIW, VSCode is becoming very good - even with non-crashing for large files, though 1M lines is quite a lot and YMMV :) I know that they don't "render" text that is not within the viewport, but I'm curious if there could be further optimizations by just tracking a line position in memory and then streaming parts of the file in on demand. Of course that breaks search.. hmm.
Energy usage is not fixable, without fundamental changes to how Electron -- in particular the JS engine underlying it -- works.
Sharing a runtime in memory is a good way to amplify problems associated with memory fragmentation and also cause instability in one application to affect other applications.
Another thing that affects JS' suitability to some classes of problems is the fact that all numbers are IEEE 64-bit floats. No integer arithmetic at all. While FP is much faster than it used to be, it's nowhere near as fast as integer arithmetic. Thus, even if a Sufficiently Smart JIT could eliminate all other JS overhead, even calculating offsets into the text buffer in Atom would have a significant disadvantage performance-wise. (And that happens more than you might think: consider syntax highlighing, as well as layout and navigation.)
At the end of the day, JS is unsuitable for writing well-behaved desktop applications if only because of the energy impact. If it were a constant overhead then the argument could be made that it's more suitable for large desktop apps, but it's not: it scales up with the complexity of the problem. It starts out bad, which makes for a markedly worse experience for users when the app is small/special-purpose/utility-like in nature, and then gets worse when the app is complex enough to have logic that might not finish in a small fraction of a second.
Even the Atom project has had to accept reality here: 1.19 includes an experimental native-code implementation of the core text buffer!
Because JS is just the wrong tool for the job. And while the Atom project might blunt the worst of the problems by dropping down to C/C++ for the most performance critical pieces, that energy impact overhead still remains.
In contrast, Dropbox on OSX/Windows is written largely in Python (using wxPython/PyObjC to access the native UI system), and suffers no such energy impact problems while still maintaining a high degree of portability, a smaller install size.
The bottom line here is that when you use Electron you are trading your customers' resources for a reduction in development overhead. To the extent that that matters to your customers you are choosing to create an extra barrier to adoption. On mobile, this is already a sensitive enough point for people to scream bloody murder when a developer gets it wrong (see: Facebook having to gut their app). On laptops I only see it becoming more of an issue as Apple and Microsoft are putting more and more emphasis on battery life -- both in enabling well-behaved apps to be better behaved (e.g. Timer coalescing on macOS) and by identifying and calling out badly behaved apps (energy impact).
It is unreasonable for someone to come on here and whine about how unfair it is that their app is being judged by how the app actually behaves or even by a really good proxy signal for how it must behave.
This is your potential and actual customers providing you feedback. Maybe you should listen.
Also, I should note it's not just the JS engine: Chromium itself still doesn't play nice with things like timer coalescing. Until and unless that is fixed, Electron remains a significant liability in terms of user experience.
As another example: the idea of keeping a window of the file in memory is not a bad idea -- if only for the sake of search. The best way to handle it is using mmap. However that's going to be a dangerous thing to try and expose to JS if the runtime uses a copying garbage collector. So instead you're going to have some very... interesting... shenanigans you need to go through to make that possible. And you're going to need to break out of JS into native code to do it. And if you forego mmap then you're going to be fighting a losing battle, with a ton of wrong ways to achieve the goal -- but very few right ways.
Using a sliding window for actual editing is just trading increased I/O for reduced memory usage. It's not a clean win, just a different tradeoff.
Sure QT can create cross platform UIs, but with a $300 yearly price tag for one developer and no support.
How can a framework that is developed openly, for free, in which multiple companies have built successful businesses on and millions of people use products powered by it be a 'disgrace'? Because people like you judge a language that was created 20 years ago on the properties that it had back then, not today.
Also, I just checked and you can find more than one laptop with 16gb RAM and i7 processor for less than $1000 USD on Newegg. I find your claim about not being able to run those apps dubious - because I'm running about 20 tabs in Chrome, Spotify, Steam, Discord and 6 other things on 4.5gb RAM right now. Maybe you wouldn't be so salty and a bit more productive if you weren't sitting there choking on budget hardware.
The LGPL version of Qt can also be used in commercial proprietary software. You have to provide only the source code of the Qt libraries, not of your code, and you can sell your software (and only the Qt libraries, which are public anyway, can be redistributed by your users).
The licensing fee argument was valid back when the Open Source version of Qt was QPL- or GPL-licensed, but not anymore.
PS: Oh, and if you cannot use LGPL code, then you cannot use Electron either, because it contains LGPL code from WebKit that survives in Blink/Chromium. And it is actually harder to comply with the LGPL requirements for Electron than for Qt, because Electron upstream does not help you, they do not even mention the LGPL on their licensing page.
I'm not choking on budget hardware, but Slack is the second biggest energy drain on my machine -- behind Safari. I have dozens of tabs open in Safari right now, and it's only a bit ahead of just Slack in energy impact. My computer remains responsive, and useful, and gets a solid amount of time on battery precisely because I simply refuse to use Electron-based apps (unless I'm literally being paid to, as in the case of Slack).
Your entire defence of electron is that your $1800 computer runs electron programs fine, that it allows you to throw software together very quickly, and that eventually normal people will also have computers as shiny as yours, so the excessive resource consumption doesn't matter.
That's a really bad and selfish position to take, both from an engineering and an ecological standpoint, and utterly hostile to the user also.
Most people don't have $1800 computers, they have closer to $500 computers. What inevitably happens is that by the time average joe's computer catches up to your performance, you yourself have also kept moving, and the software you write has bloated to match.
That electron allows you to throw together your software in less time is no concern of the user. What concerns the user is that the software works well and provides a good experience.
So what you've done when choosing Electron is to make a very particular tradeoff: You've lowered development costs for yourself, and in exchange the user gets to "enjoy" a program that ignores the target OS's UI completely, hogs resources like mad, and comes with all the quirks you'd expect of someone trying to create serious application software entirely in Javascript - compounded by the fact that anyone doing so in the first place is doing it because they don't have the skills and experience of a non website developer. It's really quite amusing seeing "multiplatform" Electron software take years for a linux release - hello discord.
It's like trying to ice skate uphill, any initial timesaving from not putting the right shoes on is quickly eaten by the fact that the tool you're using was never intended for the job.
That's why people don't like electron. If you don't have a monster computer it runs worse, and even if you do, it behaves like a bad houseguest. Windows has it's own native UI, please use it. So does MacOS. Linux has several that run on the former two. "I optimize code by buying a new CPU" isn't something to be proud of.
+1 to exactly this.
16gb of RAM is "standard", because it came with your NZ$4000 computer? Not everyone is privileged enough to be able to drop that kinda cash on a computer, and may have to compromise.
Also, spin up a couple of VMs and you might get towards the limit faster.
100% agree with the business case, but "I have lots of RAM available therefore everyone in the world has lots of RAM available" feels like a poor leap of logic.
This. It also says a lot about how much we're ripped off in the Shaky Isles.
And therein lies the problem. When tomorrow actually rolls around, you think the application's resource needs will have been frozen in the past? This seems like a slightly disingenuous argument. If we know one thing about software applications, it is that they will continue to require more and more resources at time goes by.
Don't get me wrong: I use atom sometimes; in fact, it's my tool of choice for writing ReStructuredText (the pandoc plugin is very nice). But it is a resource hog: it takes up close to 1/2 gig on disk, uses a lot of memory, and relatively frequently spins our of control, necessitating a restart to get my CPU back.
I run on a 16 gig high-end laptop too, and it's doable, but it's bit a bloated.
Agreed. I especially appreciate you addressing the point about software resource usage increasing over time. Its target is an old hat argument, and a strawman: just because you have a machine with 16GB of RAM doesn't somehow mean that running programs that consume prodigious resources is justified.
It's more than disingenuous: it's brain-dead. It's an attitude that leads to software obesity, where a chat client (Slack) now needs 2GB of my 8GB of memory all for itself. And no, "Just upgrade your machine" is not a valid argument in defence of software bloat.
Why do you think Adobe Air failed?
Because mobile and light web apps took over.
Reason why NodeJS and Electron is taking off is simple - because anyone can bang out a Javascript function and use it in a few minutes. Compared to C++/Rust.
But should they? This reminds me of the mess that Visual Basic developers caused in the late 90s. I was one of them, and wrote pretty good code, but the amount of money I made cleaning up OPM's was at least 100x what I made writing my own code.
Making code accessible and fun is a great goal. Making it easier for armchair architects to create black holes is not helpful. And if we don't keep them from peeing in the (npm) pool, then everyone's gonna suffer.
"And if we don't keep them from peeing in the (npm) pool, then everyone's gonna suffer"
And unfortunately it's going to end up this way. Rome didn't last forever.
But it's what makes the job market interesting.
Bloated tech gives rise to something more efficient that entails more training and skills. Differentiating the job markets.
It seems interesting the first one or two times you go through it, but in my experience it ends up feeling less like progress and more like wasted time. It's like tearing down a house because there are too many layers of paint and wallpaper on the walls.
I would much rather see some kind of third-party repository that helps to curate libraries according to varying levels of quality, and offers a contracted level of service to consumers. Sort of like what RHEL does for Linux.
Right now, Slack is the second biggest hog on my machine, after Safari -- in terms of the metric that matters most to me: Energy impact.
I compute on the road. A lot. Battery life matters.
I have 31 Safari windows open, with about 4 tabs each. And the energy impact is only a little above Slack.
Yeah, no. I use Slack because I have to -- but on my machine: Atom is no danger of replacing SublimeText, and StandardNotes is in no danger of replacing EverNote.
It simply does not matter to me that you don't have the resources to build an app that meets my needs. That, as they say, is not my problem.
"But advanced development machines of today are the entry level computers of tomorrow."
This statement seems to be less true every year. The RAM that I purchased in 2014 is now more expensive than it was then. CPU Advancements seem to be incremental.
I will use electron based apps , If you are willing to give me your laptop :P
In My country Computer Hardware is so expensive that I can afford one year living expenses with the money for an Apple Mac Book Pro latest model .
Electron will grow over time .
The problem with electron is every single electron take up its own space and performance.
My Browser is Chrome . If my editor is VSCode and I'm running other other electron apps like whatsapp for desktop.
Wordpress
GitKraken
GitHub Desktop ...
If i run every thing as an electron app My computer will never recover from the hangover I gave .
So Instead of complaining Give me your laptop , I'll use electron apps!!!
I'm on a late 2017 Macbook Pro (16GB). I have the following open all day, every day:
They're all Electron based.
They all work perfectly.
I do not have a problem, even thought I'm probably running Photoshop, Lightroom, Zeplin, Whatsapp, Spotify, multiple windows of Chrome, Firefox, the odd note taking app and at least 20 background utilities.
And goodness me, the people slating Electron because it promotes Javascript, a "buggy" programming language: are you kidding? Disliking Javscript because it is less rigid than C++ (a fantastic language if used appropriately and for the right thing) is a symptom of lack of understanding of the technology as well as a severely parasitic mindset in the world of science.
I will agree with others in saying : this post has zero scientific or engineering value. Its' basic argument is "if it runs well on my machine" and "it's easier for us to save money in development". Well those are two very light (to be polite) arguments.
Unfortunately this is the usual level of articles in this page.
Moore's law is not an excuse to design crappy software. Not everyone who criticizes Electron's resource usage is a Unix fetishist that thinks all programs should be small C utilities. It's important to balance performance and productivity, but Electron completely blows this ratio out of proportion. It wouldn't need so much testing and debugging if its design wasn't so convoluted to begin with.
Web technology is for the web. Leave it there.
I have a five year old mac book pro. Quad core & 16 GB. 8 GB is a (bad) choice and has been for some time. Like the author, I have atom open around the clock, slack running. In addition I run stuff like intellij, spotify (which is also a web based UI), chrome, and several docker containers. When my laptop runs hot, the usual suspects are spotify and rogue jvm processes, not atom or slack. Yes atom and slack probably use a bit more CPU and memory than it should but it's fine as long as you have enough RAM.
On the balance of things, optimizing for five year old hardware when writing software for the next five years is not a winning strategy. I can tell you from experience that running a small company targeting more than one UI platform is a royal pain in the ass and a very unrewarding and expensive strategy. It will suck the life out of your company just managing the complexity of that many platforms and getting anything done takes ages. Throw mobile in the mix and you are sure to fail. Most people that actually know what electron is ought to be running decent hardware and are in all likelihood a tiny percentage of your user base. So ignore those people and focus on your real users that actually bring in revenue. As it is, Spotify and Slack are market leading productw, Atom is shaping up to be pretty popular, and I know absolutely nobody in my wide network of developer friends who has done any native desktop UI work in recent years. It's all web based these days. Native UIs on the desktop are dying out rapidly.
The reason that atom is so popular these days is that it actually is pretty damn good. A lot of that has to do with them using electron and using javascript to implement a lot of the features. When it comes to shipping javascript based desktop apps, there are not a lot of options and electron is one of the better ones. Forget about atom being ever reimplemented in something else.
Please share some specific examples of what makes JavaScript buggy, because I use it extensively every day at work and the only bugs I ever see are the ones caused by not thinking of some needed logic when I wrote the code. And don't use any examples from any versions of the language prior to ES2015, because it makes no sense to judge a language today on its problems from years ago.
I cannot stand electron.js apps, they absolutely DEVASTATE battery life on anything mobile I own. I can stream Steam fine, I can play Minecraft without any issues, I can even make calls with Skype, the second I start up a Discord call my laptop/ surface starts screaming at me and dies within a few hours, heck the Surface can't even charge fast enough to keep up with this horrible garbage.
DEATH TO ALL ELECTRON APPS!
Here in Brazil the reality about the amount of memory is quite different, and at this point I agree with the other comments.
On the other hand in recent days I have tested the vscode, and unlike Atom, it has behaved much better compared to the use of memory and cpu. In part, I think, for the better quality of the code.
In the long run I believe that the average amount of memory should increase, just as Electron should gain many improvements. As a tool developer for other devs I'm betting on.
Electron is pretty wasteful, and still not portable to mobile. It is a wonderful solution to create applications fast when resources are only an unimportant issue.
Still, I believe it is bound to be replaced by something else in the near future, and that's progressive Web Apps that are augmented with some extra capabilities (requiring the user's permissions).
This way, the browser engine that runs them is already on the system and you can have graceful degradation by running those parts that doesn't work in the client on your server until it is supported.
Am i reading that wrong? $100k divided by 2,000 users is 500? According to my calculations that would be $1m of profit, not 100k.... And i'm supposed to trust you with the crypto protecting all my sensitive notes?
As a user and a developer, I love Electron and the concept of it. I hate what it does to my system though. It's February 2018 and I have a (still relatively) beefy laptop - Dell XPS 9530 (16 GB RAM, quad proc Core i7, SSD) and it introduces very substantial lag to almost everything I do. I just had to close out all my apps and chrome windows and went looking for when this resource allocation issue was going to get fixed and found this post.
As more apps are built on Electron, it eats up more resources. I suspect graphics RAM usage is the main culprit here (Intel embeded 460 graphics, probably 4 year old tech now but still very functional) and this needs to be fixed in order to keep everyone happy.
As for the apps I know are built on Electron that I use: 3x Slack teams, VS code, Atom, Postman, and Azure Storage Explorer.
This is the same argument made by [pick a vendor] since [pick a year].
Seriously - Sun, Oracle, Microsoft, IBM have all been in this situation over the past twenty-five years, for both server apps and developer tools. Heck, even for some versions of MS Office and Oracle Forms.
If it's been that way since 4MB of RAM was a lot, what makes you think that getting to 16GB is somehow going to fix things? The platform tools will continue to expand, slightly overflowing whatever size container you provide, until we learn how to stop wasting so much CPU and RAM.
How? Now that is a blog post I'd like to read.
You don't? Even when using Atom? pavelfatin.com/typing-with-pleasur...
(I realize you are on a Mac but I suspect the performance is about as optimized on mac as it is on Windows).
I think electron works in really specific things, and even then, it won't be for everyone. Like someone already said, a lot of applications that have good electron apps, have an already amazing web app that already works like a standard app, with even push notifications. In my case, with my 16gb I tend to use the slack app as a way to have it separated from the browser. But in my Macbook with 4gb. My good.
I've been working a lot of time lately with my macbook and I started with Atom. It was a really bad experience in the long run. I liked it at the beginning but it got worst. At some point, even using VS Code that felt a little bit better than Atom, and having chrome with some tabs and some other thing... It felt like I was typing in a virtual machine with 1gb of ram to a ssh pc connected in china... really bad.
And in response of some comments saying that electron makes web developers don't get stuck with just the web... couldn't disagree more. Electron separates you completely from the desktop part. You won't have control and at the end you won't be caring about your user experience that most likely won't have the performance it could have even in simpler cases.
I am using an i5 with 16GB RAM and a want more cores and at least 32 GB - but why? - my computer is lagging more than it does in 2002. Do I use my computer harder? No! Do I use more applications at the same time? - Not really! So why is using a computer still a pain? Because of stupid lazy programmers loading the whole internet as libraries to do - what? - some chat oder canban boards.
2016 Macbook with 16 GB of RAM? What a big boy you are! /sarcasm
Electron went from a crossplatform dream to a mainly Mac-Only product. Very few apps are truly crossplatform.
Not all of us have 16GB of RAM to spare, Mo. It's that simple.
I have a genuine questions for those who oppose using Electron. What solutions do you propose to the problems that it addresses?
Learn a compiled programming language. Write software instead of web pages.
The operational benefits you spoke about are the single largest driving force behind its adoption.
Thanks for this post! It is very well written and it sums up my thoughts about Electron exactly. Hopefully all the negativity doesn't discourage you. I wanted to add my experience and reasons for choosing Electron.
I've been developing software for 20 years, using a multitude of programming languages (C and C++ to a limited amount), Java (during my early days) and later .NET in combination with WPF for the UI. .NET has been my go to framework during and after my day job for 7 years. I gained a lot of expertise using the framework and had training and experience in software design. So I do not consider myself a bad or lazy engineer (as some users believe we Electron developers are).
The software I'm talking about was written in .NET during my free time after the day job. It is available free of charge. It gained more user interest over time, more than I ever imagined. Due to the chosen framework it was limited to Windows. Requests for Linux and Mac ports increased over time. So, in the very recent past, I had to make a decision:
From the start, option 1 was unacceptable. Option 2 was unrealistic, since I'm a one man shop, my software is written during a limited amount of free time and it doesn't pay my bills. So only option 3 remained.
The quest for a common framework took weeks. I considered Python and .NET Core. They had potential. Both had a common problem though: what UI framework should I use? There was just none that provided the same amount of flexibility that WPF provided. All cross platform UI frameworks either don't look native at all, or look native on only 1 of the supported platforms. They mostly just look bad and very dated. In my case, user experience would suffer and would take the user experience back 20 years. The only UI framework that came close, is Avalon UI (which is a open source reverse engineered WPF). Since Avalon is still experimental and considering that I've had performance problems even with the real WPF, this was not an ideal choice either.
In the end, after a lot of investigation, the only framework that fitted the needs was Electron.
So, the choice of Electron doesn't come from laziness or bad engineering. It's usually a every well though off decision. To this day, there is just no other framework that comes close to the portability, user experience and development experience that Electron provides.
I completely understand the sentiment: you're right that platforms like Electron are the ONLY way for many small and mid-sized dev shops to build cross-platform apps. I love Electron and want to use it myself. But bloaty software development approaches like this are contributing to major global problems. They're the reason why perfectly reasonable machines become outdated after a couple of years even though the user's needs haven't changed much. They waste resources, both in terms of energy usage and obsolete hardware. Also, betting that everyone's machine will have 16 GB and the horsepower to run an Electron app could be more risky than it seems.
So, nah. But wouldn't platforms like React Native for Desktop - where JavaScript and React's JSX are used to compile into a native binary - be the ideal solution here? (Sadly, RN for MacOS/Windows seem very far away from maturity at this point.)
Would this approach not work much better, while providing the same benefits?
wxPython. Xamarin. If I were feeling a little experimental, maybe Kivy.
Electron is not the only way for small/mid-sized dev shops to build cross-platform apps. It's merely the one that's caught the zeitgeist.
Electron is a great way for JS developers not to get stuck with just the web.
This is something I see a lot of times when people talks about Electron, but I simply can't think just the opposite when hearing this. I mean, The developer will actually be stuck at they knowledge about what he's developing, without actually acknowledging that he is working in a completely different platform from the web. Not caring about the performance that the user will get is completely abstract the developer from the platform he is launching the product on. It
won't get stuck in the webis just for the fact that It willdevelop a desktopapp but really, is just that, the developer doesn't really have any control over it.Would it be possible for a startup to focus on one platform first? E.g., address the Mac users? I have seen multiple successful examples of this strategy.
The bigger problem for me is not ram. It's the effect that Electron has on battery life. 16GB ram will become standard, eventually. But batteries are still stuck in the past.
At first I thought you're joking and then I told myself, whoah there Roach, why's there so much bad code in the world?
I like Electron already yet Electrino makes good sense: github.com/pojala/electrino