In Defense of the Popular Framework Electron (dev.to)
Electron, a popular framework that allows developers to write code once and seamlessly deploy it across multiple platforms, has been a topic of conversation lately among developers and users alike. Many have criticised Electron-powered apps to be "too memory intensive." A developer, who admittedly uses a high-end computer, shares his perspective: I can speak for myself when I say Electron runs like a dream. On a typical day, I'll have about three Atom windows open, a multi-team Slack up and running, as well as actively using and debugging my own Electron-based app Standard Notes. [...] So, how does it feel to run this bloat train of death every day? Well, it feels like nothing. I don't notice it. My laptop doesn't get hot. I don't hear the fan. I experience no lags in any application. [...] But aside from how it makes end-users feel, there is an arguably more important perspective to be had: how it makes software companies feel. For context, the project I work in is an open-source cross-platform notes app that's available on most platforms, including web, Mac, Windows, Linux, iOS, and Android. All the desktop applications are based off the main web codebase, and are bundled using Electron, while the iOS and Android app use their own native codebases respectively, one in Swift and the other in Kotlin. And as a new company without a lot of resources, this setup has just barely allowed us to enter the marketplace. Three codebases is two too many codebases to maintain. Every time we make a change, we have to make it in three different places, violating the most sacred tenet of computer science of keeping it DRY. As a one-person team deploying on all these platforms, even the most minor change will take at minimum three development days, one for each codebase. This includes debugging, fixing, testing, bundling, deploying, and distributing every single codebase. This is by no means an easy task.
Honestly this is the first time I heard of it. Most likely as the explanation illustrates it isn't a tool that I need to solve my problems. But still if a tool was really that popular I would had heard about it before.
If something is so important that you feel the need to post it on the internet... It probably isn't that important.
The headline makes it sound as if Electron is being defended. Then it starts talking about how slow Electron is. But then some "developer" (of what?) says that his fast PC runs it without any lag. Okay. And *then* it talks about how bad Electron is for not being supported on cellphones... or something. I can't make out the point of any of this.
What is this world coming to? Even worse, there's no women-in-tech or global warming angle to get the click count up.
Ms. Mash, I'm very disappointed in you.
In Defense of the Popular Framework The
As a one-person team deploying on all these platforms, even the most minor change will take at minimum three development days, one for each codebase. This includes debugging, fixing, testing, bundling, deploying, and distributing every single codebase. This is by no means an easy task.
What BS. A minor change takes an entire day per platform? Every time. I'm a developer and I know that "little" changes often take longer than it seems like they should to a client or end user. But this is nonsense.
Also, who the fuck said that software development was supposed to be easy? Maybe if this guy wasn't mashing the "easy" button, he could get himself paid appropriately without massively padding his hours.
I had never heard of it so I googled it.
Oh, a new text editor, maybe I can use it. Click on the download link.
163MB for a text editor, ouch!
I do not know about RAM usage but that thing is already a hog on my hard drive...
16gb being standard on PCs is probably still a decade away.
If you have a webapp you've covered the three desktop platforms, plus web. So now you just have iOS and Android. If you're making money on them to justify the developer cost, I don't see the issue. If you're not, don't support Android. Seems straightforward.
The question is marginal cost marginal revenue. The question is not eat a shit sandwich yes/no.
Modern appy app apps like Apptron let you app apps while apping other apps! You can't do this with LUDDITE C++!
Apps!
Let's face the truth: Electron delivers a Chromium engine, Node.JS and V8, all rolled into one package to you. So of course it's a memory hog, depending on what you are going to program, like a terminal, clipboard manager or tiny frontend to FFMPEG [all existant projects]. All those programs alone need 200 MB for the runtime engine, to just do really simple stuff.
It also needed 13% of CPU time to just draw a blinking cursor (!).
It's mostly used by shitty webhipster design startups, which are just way too lazy to learn a proper programming language, and it even doesn't fit well with the UI of your operating system. And since the underlying parts of it, when a program gets delivered, aren't for sure update as frequently as Chromium alone, it's a security nightmare as well.
"allows developers to write code once and seamlessly deploy it across multiple platforms"
now I'm pretty sure I've heard this before somewhere, in fact multiple somewheres, over the course of the last 3 or 4 decades.........
They must be nearly finished ironing the kinks out by now.
All desktop applications -- Chrome, Vivaldi, Atom, Brackets etc -- based on Chromium browser are very well know as suffering from the Memory Hog Syndrome . Firefox also included.
Keeping it a web application won't satisfy the "I refuse to turn on scripting in the browser" crowd who frequents sites like this, if comments to stories about Chrome's adoption of WebAssembly on Slashdot and on SoylentNews are any indication. Or by "web application", do you refer to an application where all scripting is server-side and all interactivity is through link navigation and form submission?
"Electron, a popular framework that allows developers to write code once and seamlessly deploy it across multiple platforms"
Oh, my. Someone has balls of brass to even imagine that someone could fall for that old line.
It still can't beat that timeless classic, "Would you like to come up to my apartment and look at my etchings?"
So far my experience has been atom and mattermost desktop.
For atom, everyone was swearing*so hard* about how good an editor it is, and it's frankly not that good, a resource hog, and just generally a bit glitchy around the edges. Slow to start. Sure it's 'extensible', but the extensions have thus far for me been extremely ill-fitting and low quality. It reminds me of the 'plugin' fad of the late 90s/early 2000s when a lot of applications pretended to be incredibly extensible but really it was just providing clunky entry points to pretty much standalone apps.
For mattermost, it was basically loading the web gui in an app.... no value over the 'normal' web gui. For atom at least you have the excuse you are dealing with offline material so a 'normal' browser hosted approach doesn't fit, but in mattermost you are connecting to a server anyway. I might have found other reasons to be dissatisfied, but the complete lack of benefit over the browser version just made my interest evaporate.
I don't understand the fascination with using the web development trappings when you don't have to. It's one of the most tedious approaches to application development.
XML is like violence. If it doesn't solve the problem, use more.
> "But aside from how it makes end-users feel, there is an arguably more important perspective to be had: how it makes software companies feel."
WTF? What kind of poison has that dude been smoking?
It pretty much just boils down to ignorance. There are a lot of "programmers" (I use that term very reluctantly) who only know JavaScript, HTML and CSS. Only a fraction of them know PHP or Ruby on Rails. That's as deep and as wide as their knowledge and experience goes.
They don't know C. They don't know C++. They don't know Java. They don't know C#. They don't know anything other than web development.
Being so ignorant, they don't realize just how awful their preferred technologies really are. They also don't realize how much better the alternatives can be.
So what do they do? They write absolutely everything in the only language they know: JavaScript. They build their applications (or their half-arsed attempts at applications) using the closest thing to a UI framework that they know: HTML and CSS. And the results are disastrous.
We see the same thing happen with databases. People who know nothing about SQL or relational theory find that they need to store data, and instead of using a real database, they choose some shitty NoSQL database instead.
The worst part of all of this is that these people refuse to learn how to use real technologies. They're so ignorant that they're unwilling to look beyond what they know. So this problem just gets worse and worse. They try to write more and more software using JavaScript, HTML and CSS, and the end result is that we see more and more extraordinarily bloated and slow applications.
"Build cross platform desktop apps with JavaScript, HTML, and CSS"
I don't see anything remotely related to programming about it.
Why do you allow software written in languages other than JavaScript?
Because it is free software that is included in the repository of FreeBSD, Fedora, or Debian, which means it has undergone at least some level of third-party code review. Most applications that use script-in-the-browser have not. Some people who consider script-in-the-browser a "trap" make an exception for free software with machine-readable license markup.
Appern appy app apps app Apptron app app app apps while apping app apps! App app't app app app LUDDITE App++!
AppApps!
Java, a popular framework that allows developers to write code once and seamlessly deploy it across multiple platforms, has been a topic of conversation lately among developers and users alike. Many have criticised Java-powered apps to be "too memory intensive."
Electron is basically Chromium.
There are a few extras here and there but in the end an Electron application is some html, css and javascript code packed together with a browser - so it's not that suprising that it eats up ram just like Chrome.
Real life is overrated.
To be precise this guy doesn't necessarily have a 3GHz i7 laptop, except these things do "turbo" to over 3GHz for CPU hungry burst single-thread tasks, such as running javascript. Even the netbook-like Macbook may go up to 2.8GHz that way and that's the Skylake CPU architecture - it has more IPC than even Skylake-X and Threadripper. So that's one of the most powerful CPU on Earth for the task, barring 4.4GHz+ CPUs like 4790K, 6700K or higher (e.g. 5GHz IBM POWER CPU)
By no means am I 'most people'. I use a relatively advanced laptop: a 2016 MacBook with 16GB ram (which came standard). But advanced development machines of today are the entry level computers of tomorrow. Electron’s dream world would be one where every computer user had a luxurious amount of ram. But I think this world is fast approaching. Do we wait till then to begin taking advantage of a plentiful world, or do we start planning now?
If I were a convenience framework developer, I ought to be more concerned with where the trend in memory is going rather than where it has been. The computer industry has been stuck on 8GB for what seems like far too long, but a 16GB standard reality is imminent, if not inevitable.
Advanced dev machines of yesterday aren't the entry machines of today. e.g. a machine from 2010 with eight CPU threads and 24GB RAM will demolish most new hardware sold today. Give it enough time : maybe a cheap dev machine from 2006 or 2007 had 2GB or 4GB RAM. This would match actual entry level from today : Atom/Celeron/Pentium machines that are built like a MacbookPro, but with a fanless Atom CPU, 2GB or 4GB soldered RAM and soldered eMMC flash. (with SD slot, HDMI and USB-A)
There's always $0.10 or 0.1mm or one gram of heatsink to shave from the consumer laptops, and there's relatively slow-motion technical progress. Hence the computer industry is not even at 8GB yet. Perhaps it will in 2019 (16GB on midrange) after/if the DRAM shortage ceases.
Maybe advanced dev machines become the new entry level machines, after ten years (this about matches the useful life of hardware, and by that I mean that a 10-year-old computer is like a 200,000 mile car, still useful but needs a bit maintenance, or to decide what to do or not do when the back window wiper stops working)
Thus, I hereby predict super hungry software might work very well on old computers and entry level computers in about year 2027.
They don't know C. They don't know C++. They don't know Java. They don't know C#. They don't know anything other than web development.
That or a developer has tried writing applications in C++ before, but he has run into political problems getting corporate, school, and public library IT departments to permit installation of applications written in C++ on machines that they own. In addition, most end users have shown themselves unwilling to download C++ source code and learn how to compile it, nor to install a Linux virtual machine in which to run an executable version on Windows or macOS. Or should a developer instead build web applications in C++ using Emscripten or WebAssembly?
Seriously. 'Framework' part is just a wrapper around a whole, full fledged Chrome browser. And there's your problem. If you have Atom, Slack and any other Electron app, along with your 'regular' Chrome, you have *four* copies of Chrome on your computer. If you think that is silly, yes. It is.
Which is why it's crazy to run any Electron app that is available on the web. Run Slack in Chrome, pin the tab, enable notifications and that's it. Identical, and one less Chrome installation.
has run into political problems getting corporate, school, and public library IT departments to permit installation of applications
Yes, if you're aiming your software for specialized environments then you have to adapt to what the environment requires.
most end users have shown themselves unwilling to download C++ source code and learn how to compile it
If you're requiring users to compile the code themselves, you're doing it wrong. The least you can do is actually produce a build for the operating systems you support.
"...as a new company without a lot of resources, this setup has just barely allowed us to enter the marketplace."
OK, so you've solved your problem as a startup. And you did acknowledge the user, barely.
"But aside from how it makes end-users feel, there is an arguably more important perspective to be had: how it makes software companies feel."
And then you let us know what your priorities are. The users can pound sand, you're a Startup dammit! And you have Needs! All your users need to upgrade to High End Equipment for the privilege of using your indispensable App!!
You might want to rethink your priorities, before your precious startup collapses due to market disinterest in your bloated POS. Maybe Facebook can get away with that attitude, and maybe Twitter. You cannot.
surprisingly - given that its basically using chrome as a platform
Yes, if you're aiming your software for specialized environments then you have to adapt to what the environment requires.
And in practice, adapting to the environment of "people who regularly use a PC that someone else owns" means script-in-the-browser.
The least you can do is actually produce a build for the operating systems you support.
Between C++ and script-in-the-browser, C++ will leave more users staring at "Sorry, we do not support your operating system yet."
BlueStacks App Player [...] doesn't work for Android apps that are exclusive to Google Play Store or rely on Google Play Services.
There are many android emulators out there for the pc. Bluestacks or whatever it's called was one I used.
I mentioned that earlier. But if an application for Android is offered only through Google Play Store, what should an individual who wishes to use it in BlueStacks App Player do to convince its publisher to make it available to users of BlueStacks App Player?
You're so full of shit, tepples. Use C++, use Qt, and you can support Windows, macOS, iOS, Android, FreeBSD, and many other OSes. Offer binaries for Windows, macOS, iOS, Android and FreeBSD, and that'll cover just about 99% of users. The rest are running Linux. You can generally ignore them, since they represent such a small portion of desktop users. Or if you really must support Linux, just offer Ubuntu binaries, and that will cover nearly all Linux users.
I think the editor left off the sponsored tag.
Use C++, use Qt, and you can support Windows, macOS, iOS, Android, FreeBSD, and many other OSes.
Though an established business can afford the ongoing cost of hardware and developer program subscriptions required to test on all those, a hobbyist or startup cannot necessarily.
Didn't you programmers have this conversation 20 years ago with Java? I understand the performance gap between java and C is almost imperceptible now. Nevertheless, the reports of C's death remain exaggerated.
I was playing final fantasy record keeper, which I downloaded from the Google play store on bluestacks.
Tired of my customary (Score:1)
"a multi-team Slack up and running"
A polymath of a developer, pulling the strings in several places at once.
"As a one-person team deploying on all these platforms"
Hope there's more than one person in at least one of the other teams.
And why are those particles so popular? Are they more popular than Protons? What makes an electron a "framework" electron? Framework of what? Something beyond what electrons normally do?
I'm still not convinced. You download a 2 MB HTML+Javascript application which comes bundled with the whole Chromium+Node.js engine?
And that duplicates with every new app?
Yes, yes, you code once and deploy everywere, but it feels like you're bundling a website + apache2 + postgreSQL + a browser just to edit the contents of your to-do list.
Sorry, but I pass.
How does one lawfully obtain a copy of the proprietary Google Play Store app for use with BlueStacks App Player? I thought it was lawfully available only as a preinstalled on certified mobile devices.
Using a cross-platform framework does not save you from having to make some effort to support other platforms, whether it's C++ or Java or electron. For example, you have changes like this in Atom that are having to support specific platforms:
https://github.com/atom/atom/c...
And you have platform specific issues still:
https://github.com/atom/atom/i...
https://github.com/atom/atom/i...
https://github.com/atom/atom/i...
So the statement that electron saves you from having to make any effort to support other platforms is just wrong. We went through all of this when Java appeared on the scene, with the 'develop once run anywhere' and subsequent attempts at that vision have not fared that much better.
Sure with C++ you have to bother to build for each supported platform, but there do exist cross-platform APIs to target that are approximately the same amount of work to create and support as Electron and Java, which is not zero for any 'magic bullet' people want to claim...
XML is like violence. If it doesn't solve the problem, use more.
This desperately needs to be modded up. This sums it up exactly.
Or conversely, you can develop the webapp and not try to pretend it's a native executable because a webapp in an exe isn't really distinct from a webapp in a browser, but it is a fair amount more maintenance work to bother.
If you want a desktop app specifically, design in a way that delivers something of value over hosting it in the users web browser.
That's fine so long as you don't need system APIs that the browser doesn't expose. For example, two things that work in Discord's Electron app and not in Discord's web app are push-to-talk for voice chat and automatically setting the "Playing" message based on what other executables are running. Are those big enough to be "something of value"?
I remember the days we had [to use applications exclusive to several different platforms] in one of my work places. Most of it was resolved with a Citrix-like solution that ran on a webpage.
Except nowadays people expect to be able to use applications while away from a desk. In order for "a Citrix-like solution" to work, then either your task would have to be one that can always be performed in Wi-Fi coverage, or your work place would need to cover the cost of cellular Internet.
They don't know C. They don't know C++. They don't know Java. They don't know C#. They don't know anything other than web development.
I know enough C++ to know that nobody knows C++.
No, crap like this needs to be modded into oblivion. You can argue JS is slow crap, you can hate standalone webapp frameworks all you want. But if your perception of opposing viewpoints is that they're too stupid to hold their opposing viewpoint, stop and reconsider your perception.
You lot shouldn't have made fun of java and its abstraction from the CPU. Now look what you got to fill the cross-platform void: Electron apps.
Don't you guys think its stupid that notepad.exe contains machine code? Surely operating systems should deal exclusively in bytecode.
We should just embraced java properly and built proper runtimes into operating systems. Then nobody would have needed to make web apps.
Why do I need to reconsider my perception? My "perception" is based on several decades of computing, including programming and administration. The fact of the matter is that the industry is absolutely flooded with people who are textbook definitions of the Dunning-Kruger effect. People think that they read a tutorial on javascript and now they're suddenly programmers. That's the problem with Javascript. It is VERY easy to get started on. There is virtually zero barrier to entry.
Javascript is now in the same position that Visual Basic was a couple decades ago. Everyone gets to be a programmer and pump out products regardless of how god-awful they are.
Combine that with the fact that the average desktop or laptop hardware is now so powerful that your application will likely appear to run just fine, no matter how god-awfully inefficient your code is, that it just exacerbates the problem.
We are now caught in an endless cycle because applications have become so bloated and inefficient, that it is no longer possible to use even basic desktop applications unless you're running with at *least* 8GB ram and a generous sized SSD, because going even slightly less is excruciating.
Why do you think, for example, that Facebook+messenger takes over 750MB of storage? Shitty programmers that think they're good.
Honestly, the number of examples are literally endless. Have you ever seen code that iterates through a hashmap to find a desired value? I have.
I stand by my "perception", thank you very much.
"The search Electron developer jobs in Raleigh, NC did not match any jobs."
Not touching it.