Does the Electron team have a focus on improving performance? Or is the issue with the developers using electron, should they be optimizing better?
I assume it's some of both, but curious if anyone with more experience in electron can provide any insight as to how the performance changes over time.
- The operating system cannot share memory between different Electron processes. Normally if you start many processes of the same binary, the memory is shared and only copied on write. Since each Electron app is a different binary (even though they are 99% identical) they each eat memory.
- The above applies to disk size as well. Electron apps are usually huge, and 99% of the binary is the same as all your other electron apps.
This is mostly why I'm against electron. If electron worked like the JVM and each app shared a runtime, many issues would be solved, including many electron apps running old, and vulnerable versions of Chromium. Now it's only updated if the developers decide to ship a new version.
This is in no way an endorsement for Electron, just an aspect common to all platforms that rely on an intermediate runtime that could in principle be shared.
But the memory one definitely is, I don't want each app to take 1GB of ram.
While hard drive space is cheap on spinning drives, space on consumer devices has stagnated or even decreased with the move to ssd
Here's one that doesn't suck:
Maybe that was very complicated to make, all I know is that it's blazing fast and doesn't hog memory. Or hey, take OggDrop and LameDrop, I'm sure there's programs that do the same, are 100 times as big and have 3 options. I don't know if there are 10x programmers, but I know there are 100000x programs, with not one electron app among them.
Another self-contained application I like is racket/drracket.
Lately I have been building apps with tkinter/python/asyncio and I can't get over how fast the apps are to load and to use. There is none of this "let's not respond to the mouse for 5 seconds" that is staggeringly common on my mac (particularly for apps like Safari and iTunes that come from Apple) nor the "go for a walk around the block" loading times for Java-based apps on my i7 Windows laptop.
True tk apps are ass-ugly but I find it mind-blowing to use GUI apps that are as responsive as Windows 95 apps were back in the day.
I love Kivy as well as QT. You can make some decent looking apps with the former and some incredible ones with the later. I have never personally worked with Electron.
But yeah, most devs use JS, HTML, and CSS for ui creation because of the Web.
I think something like QML could replace the html and css parts, though.
tkinter specifically does not look very pretty without some effort. I would much rather use GTK or QT. The problem is GTK support on windows is limited, and QT has a weird license model.
Qt is available under LGPL and GPL. What exactly is weird about that?
Up until 2005 or so Qt had indeed a relatively complex licensing scheme where the available (i.e. the license of Qt) and compatible (i.e. the license of the application, due to their GPL exception allowing applications to use MIT, BSD, ...) differed by what was then Qt ports (e.g. Qt/X11, Qt/OSX, Qt/Windows). After that they always had a uniform licensing model for Qt, were the licensing was independent of the platform.
I wanted to like Kivy but it was more clear how to get asyncio support running w/ tkinter. The Kivy folks say they will go to py 3 only soon and support asyncio officially soon but I am in a good place with tkinter.
I am also thinking about a 2-thread architecture which may work well for Kivy since it is so heavily Cythonized.
Also if it's not built in JS, it's not cool these days
To me, it feels like if you want to be cool these days, you look down on JS/JS devs.
JS has plenty of issues, but it's undeniably successful - isn't it more beneficial to either improve the problems or figure out why it continues to be successful despite them and adapt that in your language of choice rather than dismiss the success as being "cool"?
I've developed in a few languages, with JS being the latest, and while I do in fact enjoy it (mostly), it's not because I'm cool. I'm almost never cool, and being a JS dev involves people telling me that remains the case in tech forums regularly.
</rant>
All of my bitterness aside, your point about GUI development is completely correct. I've been happy to see CSS slowly taking lessons from desktop GUI layout and hope for more in the future.
The true hipster developer needs to be able to sneer at JavaScript with true derision while also having JavaScript be their go-to language for everything. Holding incompatible views at the same time about mostly inconsequential things is, after all, the true essence of being a hipster...
I’m incredibly partial to Qt and love the framework (particularly the ability to style it and its C++/Python bindings). But even after making a small GUI application I can see why some would prefer more simple to use frameworks, whatever the resource or performance costs may be.
Ease of use? What's easier, MS Visual Basic/Embarcadero Delphi, or the application-oriented parts of HTML/CSS/JS? Even Python (which is freely available) is not exactly hard, and there are plenty of native apps using e.g. WxPython. It's not "ease of use", it's more like webdev "brogrammers" wanting to have their cake and eat it too.
Um because a lot of them already know HTML/CSS/JS (because they've worked on websites). This the the major reason why Electron is popular - the barrier to entry is very low. That combined with the fact that users don't complain, just makes it a "pragmatic" choice.
I haven’t heard anyone outside of the hn circles moan about slacks usage.
- I'm a JS/TS developer, with it I can make CLI apps, websites, Electron apps and mobile apps. This means I can also use the same set of UI widgets I'm familiar with across all platforms, I can't do that with any other native UI toolkit so far, maybe the situation will change with the advent of WebAssembly, but so far JS has basically been the only language capable of providing this.
- I don't think I've ever used a Java GUI app that didn't look like crap and wasn't a game, I've also never made a GUI app in Java, so this is just a guess, but maybe it's just easier to make prettier apps with web technologies.
I've no idea how good Xamarin is at doing the things that it does, but even if I hadn't invested X into my web-based components Xamarin would still force me to reimplement them again in case I need them in my website. That's not cross-platform enough for me, Electron in better in this regard.
Personally, I liked it back in the Win95 days when everything used the native toolkit and I could change its appearance significantly through a simple control panel [0]. Back then, if I wanted a "dark mode" I just adjusted colors to make things darker, but with modern GUI bullshit it's a newsworthy item when someone adds "dark mode" as a feature.
Customizability-wise I actually prefer Electron apps to native ones, with a few lines of CSS I can remove stuff I don't need and tweak the UI a bit, I'm not quite sure you can do the same as easily for native apps.
Also you mentioned dark mode, an Electron app could support dark mode too, taking as an example macOS native apps they also have to explicitly support dark mode, so I'm not sure what you lose in this regard by non going native.
I would argue that going full-native win95 style has more downsides than benefits, for most people simply being able to change the wallpaper is enough.
That's a fair point. GUIs have tended towards being less customizable, not more, and that's a huge failure in my eyes. However, the customizability of Electron applications is really a side effect of the fact that it runs on top of a web browser. I find it difficult to count that as a point in its favor.
Looking at it from that perspective, there are native GUI systems that load XML files for their GUI that could also be called customizable by your standard.
Native apps use system colors by default. Electron apps tend to use static colors.
If you want to create custom elements I assume is simpler to do it in html with a couple of nested divs, background images and some css rules and some trickery and most probably your custom widget is not accessible and missing some nice features. As an example I know toolkits(Qt,Flex4) that can render huge tables of data, allow customization and are very efficient and you don't need third party libraries for that.
So yes +1 cross platform GUI toolkit
If we could just get a modern UI lib w/ a C FFI you'd see a node wrapper and the complaints would reduce (yes I am aware of lots of efforts and could enumerate them all, but many are lacking).
It looks like Python is your only option if you want a community of any sort who is actually doing GUI development with a scripting language (Perl/Python/Ruby)
I prefer functionality over appearance, but I'm just a crusty old RDBMS DBA so I'm not sure my opinion can count for much.
For me?
Because every API I access returns JSON, and because half those API have a JS package sitting somewhere in NPM.
Bonus, a large % also have typescript definition files laying around.
So my choice is either:
1. Deal with JSON in native, and create my own wrappers for every API out there, because next to no one publishes C/C++ libraries anymore.
2. Give in to the JS behemoth.
tl;dr ecosystem.
You have to parse it anyway, and in either case (native or JS) you'll be using a pre-built facility for that. Plenty of "native" languages can have good JSON support these days, and the "create a wrapper for the API" part is trivial if there's one available already, even if it's JS.
In JS you can just access the fields. With a lot of APIs just being HTTP endpoints, call fetch, get JSON, see if you like how it works.
Move over to a better NPM library that wraps it later on if so desired.
But for prototyping stuff, JSON+JS is stupid fast. JSON store DBs suck for a lot of reasons, but getting something working in them is incredibly easy.
Getting that something to "real product" is probably end to end more work than if a better tech stack was chosen. You win some and you lose some!
I think an updated, nicer ttk would help considerably, as well as a bigger widget library, but there is little information on improvements to Tk as a whole (I can’t even find enough examples for asyncio...)
Anyone have good references for either?
Because it very much feels like so, especially with tkinter. And it's not only the toolkit, it's the OS integration, and installer and so on. Because making a cross platform app with Electron is relative low effort and you get very good results. Most of the other options are not even close.
Though I feel like even if that happened people would still complain about it, mostly motivated by web technologies encroaching on the desktop space, threatening other developers “turf”, so to speak.
Just run them, and drag'n'drop directories with the application's source code onto the electron window, or create desktop shortcuts that run "C:\somewhere\electron.exe C:\your\app\dir".
Better then nothing.
You can probably unbundle thirdparty apps, becuase what electron apps are, are basically "electron" + "other code/resources". But I've never even seen someone else's electron app distribution package, so I don't know how hard/easy it would be. And I wouldn't trust it anyway, if the code is transpiled/minified/unreadable.
I run all my electron apps using a shared runtime.
Compared to Safari, Chrome’s performance is like a fat pig hogging your memory and devouring your battery life.
I think splitting out services from the browser makes it easier to focus on notifications and use window management to change contexts. It is confusing and frustrating that Apple has not allowed saving websites to apps yet.
Sharing libraries is definitely more efficient but at the cost of isolation and versioning issues. Similar to some of the reason vms and containers are used.
Over time I have come to appreciate self contained apps and deal with redundant bytes at a lower level.
On the other hand, requiring a shared runtime has been one the key reasons that a lot of cross platform apps failed in the past. How many times have others decried the fact that they had to install Java or Adobe AIR or XYZ in order to run an app they needed.
You mean like eerr, chrome - and the web :P
That should not be a significant issue in 2018 - all popular operating systems have same page merging support now and at least latest Win10/macOS also have transparent compression of memory pages.
Discord is an intelligent start up that was able to pivot from a chat client to a games marketplace with a one-click update. Their use of the erlang VM shows that they make considered tech decisions based on tested technology. I think their use of electron, at least from this users perspective, was a great decision. I realize they are just one example of electron apps, and I'd have a harder time defending a file-unzipper or some madness using Electron, but it no doubt has its uses. To suggest otherwise would be premature optimization at best.
Noted, and that's a fine use case for the Browser engine + HTML + CSS + JS/WASM tech stack - but how many native apps need that sort of rich view?
Both Slack / Discord use around 400MB including all processes on my machine, tho it certainly varies with what is on screen. In comparison to the gmail tab I have open in Safari that is using 1GB, 400MB isn't bad.
Heck my Digital Ocean dashboard tab is consuming 155MB of memory right now (WTF DO?)
That said, I am blown away whenever I install an "old school" native Win32 app. The 90s APIs may have sucked to program for, but the end results stood the test of time.
Windows 2000 or higher Internet Explorer 6.0 or higher 128MB RAM/512MB for enhanced multimedia features (TOTAL RAM in the system!!!!!) Macromedia Flash Microphone and speakers/headset for voice/audio chat
(Creative Cloud is using 234.9MB and that's nothing more than a damn launcher!)
Now it is 164MB + 104MB + 85MB! And these measurement were not under high memory pressure! This isn't small by any means, still a total of ~350MB for a simple tool, but it is similar to Telegram which is a native Mac App. The two WhatsApp helper were previously using 700MB each!
And the major major improvement is compressed memory. Previously it didn't compress much at all. It was the same 700MB. Now it is 4.6MB + 5.2MB + 8.5MB, that is total of 18.3MB!!!!
I have no idea what happened, but in terms of compressed memory that is nearly 99% reduction in memory!
( Actually I am really interested in what happened, I wish they have changelog or blog post on the fix )
Right now (20181223T1031Z) WhatsApp (87.5MB) + WhatsApp Helper (149.9MB) + WhatsApp Helper (171.7MB) are using a total of 408.5MB.
Everyone's system is different. Everyone's WhatsApp is different. Everyone's memory usage will be different.
Back when I had four megabytes of ram I wouldn’t have been furious over a 50kb editor. 200mb isn’t a lot when most developers are working on systems with 16gb or more of memeory.
If a dev is working on a less capable machine I guess I can see why this is a problem, but a rather simple one to solve, close Slack, it’s a distraction to focused work anyways :)
Yes, I hate Electron with a passion. It's a slow, wasteful framework for lazy developers who can't be bothered learning Qt or something else non-silly. IMHO.
The issue with memory consumption is definitely there.
But the issue for us is that if you're doing ANYTHING with 'content' you just have to use the web platform.
You need CSS, HTML and with pdf.js we have somewhat first class PDF support (though a few features are missing).
If it's a calculator app, then sure. Don't use Electron. It would be too bloated.
One feature in Polar that simply wouldn't be possible is support for web content caching.
We support downloading web pages for offline usage to allow annotation and to prevent bit rot.
It wouldn't be possible without some sort of web control but having full chromium (plus a webserver) means that you can setup a near perfect clone of the web but on the desktop.
Who are all these masochists using Tkinter? There are a ton other APIs to consider, and even more if one wouldn't mind updating an old one to be current (think XUL). I think this is the second or third thread where that particular toolset has been named as if it were the only alternative to Electron
I hate Electron too but is everyone really so new to the game that they do not remember desktop programming?
There's Swing, GTK, QT, JavaFX (maybe), WinForms....
embarassed hand raise
It's not that bad, just pretty bad.
https://medium.com/commitlog/electron-is-cancer-b066108e6c32
Try using the global search feature on Slack and tell me how that already existed in IRC circa 1995.
Isn't that particular feature mostly implemented server side?
On the other hand, yes, I agree that modern messengers has a lot of features that my IRC clients missed (voice comes to mind). Also they are easier for mainstream users to use and administer, and, compared to old IRC, safer in a number of ways (although I'd add that we are seeing a number of new threats now).
I use Discord and like it, but it is incredibly slow at starting, switching rooms, and even just loading new messages.
But the most aggravating thing is that I can't type a message on mobile if I don't have internet connection. It requires connection to load the input field. Affects me every day in elevators. Most native apps just lets you write your message and sends it when connection is back.
Fine, Discord is useful, but I must respectfully disagree that their app is good. And it is definitely possible to make natively.
Telegram on mobile is Android native, while Discord is based on "React Native". Telegram for desktop is based on Qt while Discord uses Electron.
I have a theory that the loudest complainers about this are the leftovers of the computer ricer era, who liked to display a bunch of metrics on their screen that mostly amounted to fluff. Electron solves real problems.
Signed, someone who's built and shipped native apps on the various platforms, and groans anytime he has to do a basic chart or whatever because it'd be 10000x easier in a web browser.
Edit: furthermore, the browser handles caching things like images and what not, which bloats up the memory in Electron. There is a way to force the browser to flush that stuff out, but nobody does it. If you have a local image cache for a native app and you don't flush it, you will get the exact same situation.
It seems to me that most apps are written in Electron for two reasons: it lets you write apps in JavaScript that are conceptually very similar to web apps, so you're not learning a new weird-to-you language like C# or Swift, and it lets you go cross-platform with far less effort--you're writing one app rather than three. But this doesn't mean that you're not making tradeoffs in both performance and usability when you choose to go this route.
There may come a point in time when a well-written native app won't trounce an Electron-based app in terms of memory footprint, startup time, and integration with the host platform. But that time is not now, and it's silly to pretend otherwise.
It's also silly to pretend that users will notice or care, assuming a well written electron app. Again, look at VS Code. Now assume that the app is aimed at a non-technical audience who aren't going to be examining their resource monitors and who would never describe anything as a Mac citizen. If the customer doesn't notice or care, then the superiority of native apps does not exist.
I wish and hope that MS moving Edge to chromium is to provide a single host level run time for PWAs. It's a space they have flirted with and seem to be inching towards more quickly.
Also note that there is nothing keeping developers from adhering to Mac UI conventions that I know of. That's not a fault of Electron at all.
tl;dr - If Javascript and electron are winning it's because others are continually _failing_.
I presume this is true for other platforms/toolkits as well, and it's a tradeoff that doesn't get talked about as often as it probably should be. I'm not using a Mac because I woke up one day fifteen years ago and said, "You know, I'd love to pay a lot more for hardware than I probably should just so I can get minimalist industrial design, too few ports, and dubious keyboards." I use them because I like Mac UX conventions. I've talked to many people who actively prefer Windows UX conventions, or KDE or Gnome. I am not thrilled with the notion of a world where everything is a pseudo-native PWA.
Which is the case with Chrome itself too...a pretty unpleasant experience on the Mac if you have finger memory or want to use your apps together. Sigh.
This application's purpose is to show text and little pictures (and occasionally process a few low-bit rate audio streams).
It is amazing that modern application developers are turning well solved problems for 90s computers into tasks modern computers can barely process.
The only way I think a common runtime could work is if Electron used the Runtime of the Browser. If every browser exposed an API to run JavaScript and Render HTMl using the browser's Engine that'd be great.
Unfortunately (or fortunately, depending upon your point of view), the JVM world has moved to a model of embedding a JVM with each app, as it can be less problematic for developers (and lets Oracle remove a bunch of subsystems from the JDK, reducing their development and maintenance).
On the up side, though, newer releases of Java provide jlink, so that the JRE can be stripped down to exclude subsystems that aren't used by the app. Also, several JVMs still support class data sharing, so if multiple instances of an app are launched, they can share some common class data.
Every interaction ends up lagging like molasses, whether it is text input, window resizing, startup time etc.
We have video games that run 3D environments with gigabytes of geometry and textures at 144hz yet people are making simple text editors and interfaces with a dozen simple components (like the ethereum wallet) that run xwindows streamed over a 56.6 modem.
(My angle on this — I do high-performance 2d/3d animation work in the browser and in electron, with extensive testing of latency, energy usage, frame rate stability, etc)
I think most of the times if an Electron app is not snappy enough then the developers didn't spend enough time optimizing it, take a look at VS Code vs Atom for instance, I haven't used Atom in a while so maybe the situation in different now, but both are Electron apps, VS Code is fast and Atom is (was?) not.
VSCode also uses lazy loading so doesn't initate everything at once you click the launcher icon but does it progressively.
But a couple of years ago even simply writing inside Atom without using any extension felt sluggish to me.
TypeScript gets downcompiled to JavaScript anyway, so I don't think that's directly a contributing factor, but maybe because of the type system they can spend less time debugging and more time optimizing.
Because, you know, Microsoft.
The file searching code is in Rust (IIRC) and runs as an external process, but that is about it.
I think the main issue is the developers, some apps don't use so much memory where others seem to use too much for the features they provide, IMO most JS developers do not understand how GC works and how you can by mistake keep objects alive.
There is also the issue where you do not have a default UI toolkit and some frameworks like angular are bad for performance(I mean how in angular codes I seen data binding trigger tons of unnecessary updates but maybe some will blame the developers using it wrong)
VSCode is pretty much the best Emacs there is right now. Uses JS, has good package management, allows changing settings per "workspace" including enable/disable plugins, has great git support, pioneered LSP, and more.
I literally want to hate VSCode, but there isn't much to hate and any weakness it has can/should/likely-will be addressed by a plugin.
However, it is not as responsive. By that, I mean sub-second stutters, nothing game breaking, but enough to affect the feel.
Note: coding in C++, using the LSP plugin on Sublime, and the standard language support on VSCode. Building and source control done separately on the command line. I use "modific" on sublime to see the differences, and the built-in support for VSCode.