Now I’m not going to suggest that C++ is “more productive” than Python - but I do have a strong suspicion that the sheer magnitude of the “shortfall” has actually much more to do with the difference in “team size” - i.e.:
Conway’s Law [quote]Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations.[/quote]
That excuse has been used to justify all sorts of bad software. While it’s true that developer time is expensive from an accounting perspective - shoddy software can get expensive a lot faster - inside the enterprise because employee productivity is killed because everyone is using every conceivable excuse to bypass “the application” and with public facing software because potential customers just get up and leave in a fit of frustration.
Personally I’ve never paid much attention to Electron. To me its use of JavaScript smack of Golden Hammer and One Language. As far as I’m concerned JavaScript belongs in the web browser (and “business logic” belongs on the server anyway) and possibly in the web development tool chain - anywhere else I view it with suspicion. Probably makes me old fashioned.
I know a lot of people hate Java, but I’d honestly prefer it for most apps. Something like Postman is ok with electron, although I just use a shell script. And VS Code is an outlier in terms of performance, probably due to many hacks on Microsofts part, although compared with vim/emacs/sublime it is slow when working with large projects. I agree c++ is hard for a solo developer to create something on par, but people do it all the time or take a look at Howl Editor written in moonscript (transpiles to Lua, I believe). So electron is definitely not the only answer for solo devs/small teams.
It is weird that a lot of “front end” devs don’t want to learn anything else beyond javascript…I think that is a bad idea in our field, I often “waste” time learning or playing around with technologies that I drop. Trying to use one language for every situation is unrealistic, IMHO.
I use a few Electron apps on a daily basis, but my work consists on maintaining a 410k LOC C++ app. Visual Studio on my app takes about 1GB. This is HUGE. Any Electron app takes 1.5GB to exchange a few messages.
I’m not sure that’s true. Electron may not be perfect but there is a lot of imperfect in computing these days. I’m generally pretty happy with both Slack and Discord. They both send tons of messages.
Slack is currently taking up…53MB
Discord is currently taking up 23MB
Windows Calculator app…33MB
Chrome…220MB
So either Electron isn’t that bad, or some people are simply doing Electron better than others. Plus there are tons of people who are experts in the current HTML web stack. Being able to leverage these same people to create native clients in addition to programming browser clients, is a pretty powerful thing for a company.
I like a good flame train and I’m sure Electron could be better. Yet I’d probably still use it, if my current 2 person web team needed to create a native client app for Linux, Windows, and OS X to communicate back to my server in 8 weeks. What better options exist for that? React Native?
You may be seeing some decent results with electron apps on your computer but that is just your experience. Its is just anecdotal because it is only one case. In the same token, my results with electron apps like Atom have been extremely terrible even with a fairly robust machine. On the same machine, I have had no problems running postman and VS Code (though I tend to use Emacs for most things).
Outside of all of these personal experiences, the folly of Electron has been fairly well documented in the community. Even the people over at Github have admitted that it needs to be much lighter and faster. If you look at the comparisons between Sublime text/Vim/Emacs and Electron based editors, you see rather large differences and this has a lot to do with both the JavaScript engine being used and the use of the DOM to render the view layer.
I do like HTML and SCSS as technologies and I actually do prefer them over something like android XML and GTK# but the fact that you have to use JavaScript to actually work with them is what makes them extremely cumbersome and unappealing. Building an app with Qt is much cleaner and faster then building something in JavaScript/HTML/CSS because you don’t have to worry about using these large DOM trees.
React Native has proved rather decent for Mobile applications. I haven’t looked at it for Desktop application development but I do know that the react native that you use on your android or iOS app is a bit different from the react native you would use on a desktop machine. That is to say that the backbone of the API that connects the React layer to the native layers is much different. As far as mobile is concerned; I have been liking Flutter and Kotlin for building nice snappy mobile apps with really fast and flashy User Interfaces. As far as cross platform desktop is concerned, I personally have been using Qt for at least 10 years now and there are a plethora of languages that you can use along with it.
I’m just running an experiment here running Slack in Firefox Quantum (nightly) which is blazingly fast on the Mac, faster than Safari or Chrome.
First column “actual” memory, second is “compressed”. Guess which web content helper is Slack
But it’s weird that this memory compresses so well.
Anyway, I’d love to have something like Chrome for UIs, but using the native APIs instead of Node. This would allow me to pick my own cross-platform library for doing filesystem stuff. I can easily do something like that on the Mac with WKWebView, but it’s not cross platform.
Edit: Why world, have you made me come to the defense of Electron…
Possibly not. I just took a quick look at whatever the Windows 10 task manager displays. On my Windows 7 work computer (yea, I know, corp IT), I see it taking up around 700MB.
Chrome, not written in Electron, is taking up 10GB.
Both of these values seem pretty absurd and I echo the statements about desktop apps typically being allowed to use obscene amounts of resources without anyone calling them on their crap.
Yes, Electron can/should do a better job. The second part of the last post is that unfortunately, companies will continue to gravitate to Electron because there isn’t a better way to immediately turn their existing HTML 5 + JS developers into native app developers. I’m not saying that those with native app expertise should start using Electron for no reason.
But, cross-platform native apps aren’t easy to create, and native app developers aren’t as plentiful as HTML developers. As long as there’s an itch to leverage HTML/JS developers for things they weren’t originally intended to handle, there will be a need for something like Electron. The next big thing like Electron might be a project that transpiles JS to C++11 and dynamically links it against a chosen ubiquitous UI toolkit for each native platform, while also delegating to the idiomatic abstractions for common services for each platform. You’ll also need to work around the bloat of the standard UI toolkits to get memory usage down, but can probably wait until a patch release before people give you too much grief. Write that and charge $100 for an enterprise license. You’ll become an immediate (multi-)millionare. And when you’re done supporting JS, start supporting the rest of the languages out there.
Also, IDEs are some of the more complex desktop apps around. Them taking a bit of resources is somewhat understandable. That still doesn’t justify a horrible user experience. But I’d be a bit more critical if my DropBox tray app was taking 1GB vs my IDE. Once Atom stops lagging during development people will stop complaining about it.
Yea. It’s not that Electron yields crappy bloated apps. It’s that it yields cross-platform crappy bloated apps. My Slack experience is still better than my Skype experience, for example. Bloated or not. These days even the back to school special laptops are shipping with 8-12GB of RAM. And people usually only have 3-5 apps they really care about.
I can’t say bad word on VSC, IT is very responsive for me. About RAM I have 32GB
But as more editors will be compatible with Microsoft language server protocol, it will be easier to switch editor and maintain the same level language support.
In the end you don’t have many options. You can’t write a cross platform GUI in Elixir. You could, but binding to QT or GTK+ would suck and I’m not sure you would get better performance/memory consumption than Electron.
If you want to have a high performance, battery/memory saving, good UX deal; you need to go for Objective-C/Swift + Cocoa on macOS, C++/C# + WPF on windows and probably C + GTK on Linux. I’m not sure anyone can afford this. If you are not an expert in this technologies you may end up with memory leaks and crashes.
Electron provides a way better development experience. I feel sad when I see new desktop apps not being Electron based.
Or you can just go with Qt and write all clients in one of many languages that Qt has bindings too. This way you can write high performance C++ Apps without the need of dealing with the dreadful undefined is a JavaScript. Or you can use Qt Quick http://doc.qt.io/qt-5/qmlfirststeps.html and write JavaScript like QML and… behold… still have a way, way better performance than electron.
I see very big, yet very disturbing trend. It seems that somehow JavaScript developers tend to forget that they’re mostly write applications for consumers and not themselves. And I as a consumer will always use high performance application over the electron one, even if it means that it does not look as good, or does not have all those needless bells and whistles, if only the core functionality is on the same level.
Since we’re talking about UI, I’ve written a small (and yet incomplete) mini GUI library called ReaQt that adds reactive programming (using RxPy) and 2-way data-binding to PyQt. It’s poorly documented but there are examples under tests/ that show how it’s used.
It was inspired by Vue.js. Like Vue.js it has a concept of Widget templates that can render dynamically based on conditions, or even render lists of widgets that update automatically when the list updates (the list is actually a RxList, a class that acts as a list but instrumented do that destructive operations send out events that can be bound to the GUI).
An interesting concept would be to control this library from the BEAM using a port. Because the UI is mostly a function of the state, you could probably send state deltas from the BEAM to PyQt and back to the BEAM. You’d have to write the GUI in python, of course, but you could move most of the logic to the Elixir side.
I use slack because my company uses it. I use sometimes VS Code, but used it for longer only for Rust until I moved to IDEA and rust plugin. I tried postman, but I moved to just writing scripts in python since. Does Opera count as electron app? Anyway that’s all I can think off.
At my previous job we had many in-house C++/Qt desktop apps (only targeting Linux) and they were a disaster. Freezing and crashing all the time. We had competent developers writing them, but if you are not an expert in Qt’s abstractions you end up with a worse experience than Electron based apps.
Running into undefined can be a problem in JavaScript, but so is every other construct in C++/Qt. Add multiple threads and you have a recipe for failure. In the end you are still abstracting away the native operating system optimised library with Qt’s library.
