Slashdot Mirror
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.
In Defense of the Popular Framework The
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.
Also I've never heard of this "most sacred tenet" and when I google it the only two relevant hits are the article and this slashdot post.
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.
If they lack good automated testing and so on I can see how the entire process could blossom, particularly if l10n is going to be involved and the tests have to go across many languages. The change itself might not be the long pole in the tent.
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?
Also I've never heard of this "most sacred tenet" and when I google it the only two relevant hits are the article and this slashdot post.
You haven't heard of DRY? Don't Repeat Yourself.
"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 if that's the case, no framework in the world will save him. At best, the framework will do what frameworks tend to excel at: allow you to easily produce substandard, but essentially functional, programs.
Note, I'm not saying that you can't produce great programs with a framework. I am saying that using a framework doesn't actually make doing so any easier, and usually makes it harder.
I wouldn't say "don't repeat yourself" is a sacred tenet. There are situations where repeating yourself is exactly the right thing to do.
It is, however, generally a "best practice".
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.
I'm building across 3 current codebases, and 2 different environments, and 1 change takes about 20 minutes to propagate. Releases, OTOH, are a different story, and may take 3 days, but that's not done for every single change.
The cesspool just got a check and balance.
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.
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.
You haven't heard of DRY? Don't Repeat Yourself.
I'm sorry, what'd you say? :^)
Hey, Windows users, there is no such thing as "forward" slash, there is only slash and backslash.
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?
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)
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?
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.
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.