We find that it's easy to set up, you can use npm packages. Yet the build size is quite big and it might not support all native features. What's your thoughts?
Seriously, WebKit on Mac and Edge on Windows would be just fine for >99% of Electron apps. Using the available web runtime would be a tremendous saving both in build size and memory usage.
Did you know that Chromium contains 25.3 million lines of code? [1] Each Electron app is bundling a separate copy of that enormous codebase in binary form. It's a terrible waste of memory.
It's true that supporting the native web runtimes would be more work for the Electron framework developers, and sometimes would also mean more work for app developers... But most web apps have absolutely no good reason to be tied to Chromium, so for app developers the diversity would actually be beneficial in the long term IMO.
If someone wants to start a project that's like Electron but uses the native runtimes, I'd actually like to contribute some work. Let's call it "Electrino"?
[1] https://twitter.com/worrydream/status/857794605076500480
Now that I only use Slack to communicate with former coworkers I just keep it on my phone.
Are you short on disk space? Download is too slow? Is this a real problem?
In 1995 my computer had 8 or 16 MB memory... Having a 1 MB app running in the background would have been huge. I certainly don't want to go back to that era.
To make matters worse, memory growth has stagnated. A Macbook Pro today, to give an example has the same maximum RAM (16Gb) it did in 2010. That's zero memory growth in 7 years for a popular developer machine.
Each Chrome tab is a process, but they share the same dynamic libraries in memory. Each Electron app is both a process and a separate copy of the dynamic libraries.
If you run half a dozen Electron apps, those redundant libraries will be taking up roughly a gigabyte already.
But when every utility and menubar widget has its own copy of Electron, the footprint balloons quickly. And people are actually doing those kinds of apps in Electron already!
I was expecting this to happen after chrome discontinued their "chrome apps", that the underlying tech would come back with progressive web apps, but I haven't seen anything in that space.
I think it would solve the problems with Electron apps (wouldn't have to rebundle the runtime for a massive binary size and massive memory use).
If anyone knows if anything is happening in this space (progressive web app installation for desktop) please let me know.
If it's just a web app (network, localStorage etc) then it would be fine. But if you need to read/write to the user's filesystem or need to include other executables then we can't run that in our browser. We don't want a webbrowser to have any possible path to screwing with your filesystem or running executables.
EDIT: Found this: https://mobile.twitter.com/nolanlawson/status/71266809721643...
Static binding vs dynamic binding?
Bundling everything up so no outside deps are needed vs using everything that is on the system to save space?
The Electron approach is fine for genuinely large applications. But I've seen many Electron-based Mac desktop apps where the UI has a handful of elements. The equivalent Cocoa app would be maybe 100 kB.
I understand that people won't learn Cocoa just for tiny UIs, so it would be really nice if there were a mostly Electron-compatible solution that would use the system web runtime which is already there (and probably already loaded in active memory).
They built a framework for, as you say, "genuinely large applications" but it seems to be so easy to use that it's used especially for small ones.
https://github.com/pojala/electrino
Sorry, it's totally empty! But I'm hoping to get around to making a Cocoa+WebKit proof-of-concept this week. I guess the starting point would be to implement just enough APIs to be able to run the main.js example from this Electron tutorial:
https://github.com/electron/electron/blob/master/docs/tutori...
Then narrow the few missing desktop-focused APIs that Electron has but Cordova doesn't have good plugins for. (It would also be nice to support more Node-like background processes in Cordova and more Node-native libraries, but you would need to find a good balance that plays well with mobile.)
https://openfin.co/2016/11/04/openfin-slashes-electron-memor...
Here's the Show HN:
No, it is a terror. Applications produced with it are bloated monstrosities, gobbling up hundreds of megabytes in both storage and RAM before getting round to as much as putting a checkbox on screen. Bundling an entire web browser inside your program in order to provide portable GUI functionality like what Tk managed more than twenty years ago without breaking a sweat, and at roughly 1/100 the size, yeah, sure, it flies. So did the Spruce Goose, sort of.
But then, I never took to js, I never took to Chrome, I never took to bloat as a way of life.
[edit: typo]
It is totally embarrassing that programs are 100-1000 times the size they used to be, and slow. I think it shows an overall disinterest in our tooling and field, and it's shameful.
When unpacked, it weighs about 100MB. This disk space costs roughly £0.004 for an HDD or about £0.020 for an SSD.
In exchange for these extra costs, I get to use HTML, CSS and JS on both our website and our desktop applications and they get to share the same codebase. That alone must saves me 50% of the time. The fact people might have to spend upto 3 more minutes to download my application and that it costs them 2p to install it on their SSD is minimal compared to the fact that I can have twice as many features in the same amount of time.
Why use JS when you can have Lua for scripting and a less annoying programming language for main code? Why use HTML and CSS when you can have a dynamic portable native UI as in Qt?
I smell laziness and cutting costs in those decisions, or rather offloading the costs onto users.
Have you tried NPM? If I want to write every single line of code for my application, I don't expect it to ship (unless it's extremely simple). When there is a library for almost everything, why not use one instead of trying to reinvent the wheel?
We also had libraries long before every language needed it's own package manager.
I have written Java, C and C++ when I was younger but I enjoy scripting languages more and they have provided for me well enough.
But, let's be honest here, "worst" is your bias for the languages which doesn't actually say anything other than your opinion.
However, as the team and product grow up, it becomes less acceptable as users expect more performance by going more native and deeper integration with the OSes.
Sorry but Electron is not the future for me. I dislike the memory consumption it eats up. There is nothing acceptable about a simple chat app eating up 1GB of memory when the identical IRC client I had was using 100KB and has more features and the same client was built back a long time ago.
As for others talking about how there's plenty of disk storage and memory, that's lazy. We're losing a generation of native coders to people who only know about Javascript and never taking the step to learn more about how bare metal works, effectively losing all the knowledge of optimizations, iterations and programming skills we've learnt in the past three decades.
I can assure you, you can stick with Electron apps only for your business but the moment I find a native version of the same apps, I'm done with your business too. Slack, VS Code/Atom, etc, none of them are on my recommendations list and they will never be until they either go native or there's a native competitor. Sublime Text destroys VS Code/Atom completely and yet, the version they've built 5+ years ago is still better than Code/Atom today in pure performance despite all of improvements Atom has done.
I suspect we'll see us going from Electron > React-Native or identical and then realizing the benefits of native stuff and back to native code once MS/Apple/other OS try to replicate the ease development process with their languages like Swift, C#, Go, and etc.
First why would you use web technology to build a desktop app? I could understand if their wasn't a cross platform answer like python and java that are high enough languages that even middle school kids can learn to make desktop apps with. Yet lets default to language and markup language specifically design for a client server relationship.
Secondly from my experience electron runs horribly on linux and windows. I can always tell a desktop app uses electron on my desktop not just by the larger then normal amount of resource it takes to do simple task, but because it will randomly crash. It crashes silently and instantly reboots it self and try to act like nothing happen but it happens so often that I catch it when it does.
Thirdly, I am not about to act like I am some type of security expert, but this is just screaming at me security risk. Electron uses at least 4 engines, how and when do they get updated and security patches installed? Can the programmers stop upgrades of these engines to insure that their app will continue running as is? You can argue all things are security risk, but when you put so many complex engines in one app it is bound to make it difficult to keep up with all the security concerns.
I could keep coming up with more and more reasons why electron is horrible solution to a problem that already has solutions. The appear to webs to keep using technology they are comfortable with is horrible reason to justify this Frankenstein of a code base.
Literally the only advantage of this is the lack of DOM related performance issues. Support for mobile is probably a nightmare and you still have to make the website anyways, so might as well write it once. Also trying to combine cross platform, speed, and 3 sounds like it's own nightmare anyways.
> Java
Much more practical option, main cons involve large JRE download and I still have to write my website in JS anyways, so why write it twice? React Native really brings the mobile performance up to par that fits 95% of non-game use cases.
This next statement is not directly related to the parent comment: I'd like to read more about why eletron alternatives are better (or exist) and less about how electron is slow or some other thinly veiled hand-wavey "bad because js".
>Java Again if you are making a desktop app why would you also need a website performing the same task? React Native is for mobile apps electron is for desktop apps so I don't understand why you are bring this up as well.
Electron exist same reason nodejs exist webbies to scare to learn another language. JS isn't bad, but how people use it makes it bad. I should actually say programmers are to scare or lazy to learn alternative solutions to a problem. It is simpler to use what you already know then to try something else. What does electron bring to the table? A way for someone that know JS, css, and html to produce a cross platform desktop app that is it. You don't gain performance, security, and it isn't the only cross platform solution like Java once was. People use to use Java only because it was the only cross platform solution. It had horrible memory leaks and all sorts of issues that still plague it to today. Yet it was the only cross platform desktop solution of its time. That is why electron is seen as useless to me I know how to program in c, c++, c#, JS, and elixir. I would probably learn python stack if I wanted a cross platform solution to a desktop app.
Python certainly isn't faster than V8. Maybe in the same class of speed, but certainly faster is not one of it's advertisable advantages.
> webbies to scare to learn another language.
> why would you also need a website
> to scare or lazy to learn alternative solutions
This is exactly the useless, vacuous discussion points I'm taking about. You're literally complaining about electron itself and JavaScript (mostly points that are invalid, misleading, or ad hominems, too) and putting zero emphasis on what alternatives are actually good and why they are great on their own merit.
No, but most of the codebase can be reused for the mobile app using phonegap/cordova.
> Electron exist same reason nodejs exist webbies to scare to learn another language.
I hate this way of seeing "webbies" as a lesser kind of engineer. I've been on both sides, doing low-level development in C, full stack on .Net, and now Node.js, and I choose the tool that better serves me at each point.
Many of us choose to use JS/Node/Electron because of practical reasons, not because we are "too scared". You may think we are misguided, and we might very well be, but there's no need to be so smug about it.
1. Ease of building and distributing packages with Electron-Builder. I'm able to build for all three operating systems on my Mac, took a few hours to set up.
2. Access to the vast NPM library for all sorts of functionality.
3. Ability to use CSS libraries for styling. I'm no designer so it saves me some time. Collate uses Bulma for styling.
From what I've seen, users are more than happy to have an application that solves their need no matter what it's created in. Most people don't really think about file sizes, or the fact that Chromium is packaged with Node, they just want their problem solved without visual or performance hiccups.
If it wasn't for Electron, Collate would be a very different application or non-existant. I think people need to look at Electron as opening the door to more possibilities.
- You can find libraries for "all sorts of functionality" with ease for native languages - Swift, C#, Python (Mac, Win, Linux).
- In the end the ability to use CSS is harming user because now you don't have default OS element styling and every app is using it's own styling for things like buttons - this is very bad.
Exactly. If you're building an app yourself you'd never have the resources to make a native app for Mac, Windows and Linux. Nothing is perfect in software development. Electron is a decent tradeoff for certain projects. Regular customers aren't going to even consider disk space or memory usage unlike many vocal commenters in this community.
To be frank, most users often don't have a better performant alternative (outside of maybe a browser tab) so it seems like a redundant point.
The disadvantage that is most talked about is its final bundle size, and I'm not aware of any developments that are trying to solve it. I'm in a project with a number of Electron apps built and in the pipeline, and we're searching for a potential in-house solution, of a central app that hosts/downloads/embeds "mini-apps" that run on the same foundation, to share the same Chromium run-time. Really hoping for a community solution to this though.
It got a bit daunting to see in more detail the potential complexity of the problem. Someone noted in the comments here, that there have been countless attempts at solving this "shared runtime for cross-platform apps" idea, apparently with a still unsatisfactory history.
Reading through the thread does give me hope, since the discussion is on-going after 2+ years, which means people are interested in an efficient solution. Seeing the HN crowd go at this Electron topic again and again, always with a kind of emotional "turbulence", implies that this is a worthy problem to solve.
I like that one of the recent suggestions is to "split the Electron", to accommodate bindings with theoretically any language.
Electron has made me forget those days! Today, most of the tools I use are available on all platforms and while they do take up a lot more ram and disk space - both are generally things I can buy and fit on my computer and will be supported out of the box but not having those apps won't.
I know it's great to hate Electron because of how much ram and disk space it takes, but for those few on Linux, it's truly made life easy!
As you may surmise, I do not entirely agree with you: I have tried the odd Electron application, but I don't think any of them lasted a week on my desktop. It's not just the bloat in itself. Software built on what I consider iffy technologies - somehow I never really manage to trust them or just feel reasonably comfortable with them.
I don't like Electron apps particularly, but I understand why people make them. I think that if your desktop app is "the thing" you're making then you should avoid Electron if possible, as it does provide an experience that's subpar. But if your desktop app is just a convenience offering for your product that lives mostly on the web, I think it's fine to use it.
(there are exceptions like VS code, but they're very finely tuned compared to the average Electron app)
Even the arguably fastest applications that are built with Electron (VS Code) are very slow if you compare them with native applications.
It would seem like building desktop apps with Electron is a big boost productivity wise (shorter learning curves, quicker time to working app) than older alternatives (Java, .NET etc, MFC etc.). If that assumption is correct, then it's trade-off against resource is worth it: get working but resource hungry app quickly in the hands of real users vs. take more time building something resource efficient but with user-validation still to do.
If you need to have a desktop app quickly (for multiple platforms, even) and it's the difference between launching something or not, then yes it is good.
If memory footprint and performance is a critical part of what you're doing (it's not always), then maybe you should look at a different technology.
I think Electron has allowed a lot of cool things to come into existence that wouldn't have if not for Electron.
With that said, IMO Electron is great purely for the reason that it opens desktop development up massively.
I've written native apps before and it has been a world of pain. Electron lets me use tools and skills I already know to spin up desktop apps. I know I'm not the only one who this applies to, and there are a bunch of apps that probably wouldn't exist if Electron didn't. It's usually a false equivalence to compare Electron apps to full native apps.
If the choice is between an inefficient Electron app, or no app at all, I'll take the Electron app any day.
While the things built with Electron may be really great apps, we don't need a full browser running for each application instance eating CPU cycles when the applications are not doing anything except sitting idle.
Just write desktop applications if you want a desktop app. If you want a website in HTML/CSS/Javascript then write a website.
Can we please stop trying to jam square pegs in round holes???????
Yeah ... you 'just' need 3 teams, or you 'just' need to use Qt, which doesn't exactly seem to have 'caught on', and has a piddly community compared to the web & Node communities.
> Just write desktop applications if you want a desktop app. If you want a website in HTML/CSS/Javascript then write a website.
Not sure if you're being intentionally obtuse, it's clearly not that simple.
Especially if your goal is to have a native app experience and not a website in an app. Electron does not really deliver that.
I'd say it's caught on. Only Qt app I'm aware I ever use is VirtualBox?
> Comparing it to web communities is disingenuous.
How? You use web technologies to built Electron apps. The strength of those communities is a big win.
> Heck, Node.js deployments have their share of horrors.
It also has its share of successes, just like any lang/community. Not a useful generalisation.
> Especially if your goal is to have a native app experience and not a website in an app.
FUD. People overstate the 'native experience' argument. Real users don't give a crap, there are tons of apps, even built with 'native' tech that feel unlike any other app. If I ask an average user the difference between Whatsapp/Spotify vs some native apps, are they really going to say 'Whatsapp/Spotify don't feel native'?
None of the apps I listed feel like 'a website in an app'. That's a huge exaggeration.
VLC, Origin, Battle.net, Google Earth, TeamViewer, TeamSpeak, Telegram, Malwarebytes?
All the contrary. Electron requires a minimal amount of Electron-specific code and its API is open-source, not proprietary. Once a new and better webapp-on-the-desktop framework is built, it's going to be easy to migrate to it.
Yes, from a user PoV the solution isn't optimal, but from a developer, maintainability, lock-in and future-proofeness PoV it's not even remotely comparable to Flash.
We should be concerned for their privacy, for their security and for their computers in general. Giving them applications that will eat up their resources as the only option is downright unethical if we remember that our primary concern is "fighting for the users."
I love javascript, I like working the web frontend, but porting the web to desktop by... not doing it, only hiding the browser, is just not the way to do things.
And, by the way, it saddens me that a lot of arguments in favor come down to "we already wrote the website, why do it twice?" That's just lazy and shows a remarkable lack of intellectual curiosity for a field in which being on top of things and updating constantly is key.
Also, bundling lots of different Chromes in apps which may or may not ever be updated feels like a security issue.
It's a trade-off for me, I use it when the trade-off feels right.
Something else to consider are your development skills. If you never worked with something else than web technologies, electron is hard to beat in terms of dev experience.
For product performance: No
It's really a question of what you value more. Personally, I value product performance over developer convenience. I've recently removed all Chromium based applications from main computing use and my computer has been performing a lot better.
The only thing I can't get rid of right now is Slack due to work. I wish it was native, but I understand why it's not.
And as an Old, I do believe there's a serious cultural problem, caused by the Web Rush, where the industry as a whole does not care enough about zero/low-cost abstractions.
- Bindings to Tk (Tcl; cross-platform GUI toolkit).
- Bundled with Python.
- Easiest to use but has the least features.
- Ugly on Linux and is difficult to theme.
- Good choice for small applications if you only care about utility.
PyQt (or PySide):
- Bindings to Qt (C++; cross-platform GUI framework).
- PyQt is GPL licensed and supports Qt 4 and 5.
- PySide is LGPL licensed and supports Qt 4 (support for 5 is in development).
- The pixel perfect purists dislike it on Windows and Mac.
- Good choice for large applications where an almost native look is sufficient.
PyGTK:
- Bindings to GTK+ 2 which is obsolete.
PyGObject:
- Bindings to GTK+ 3 (C/GObject; cross-platform GUI toolkit).
- Comparable to Qt.
- I've heard Windows support isn't the greatest (this may be obsolete now).
- I'm biased and perfer Qt over GTK on Linux.
- Good choice for large applications where an almost native look is sufficient.
wxPython:
- Bindings to wxWidgets (C++; cross-platform GUI toolkit).
- Comparable to Qt.
- Uses native widgets on Windows and Max, uses GTK+ on Linux.
- Good choice for large applications where a native look is required.
Kivy:
- GPU accelerated GUI framework.
- Does not look native.
- Good choice for graphically intense applications that do not need a native look.
My recommendation is:
- Small, utility program: Tkinter.
- Large application: Qt (if an almost native look is sufficient).
- Large application: wxPython (if a native look is required).
- Graphically intense application: Kivy.
So I'd spin the question around: why NOT offer a desktop app option—considering that electron makes it a pretty light investment for any team already building a web application?
If you already need your product to work in the browser, you're a small-ish team, and your feature set is in motion, I think it's a good strategy to do an electron app because it further incorporates your product into the day-to-day experience of your users. There will certainly be a point where offering a native desktop app becomes worth the investment, but that may not be day zero.
Meanwhile, would love to see google work more closely with the electron project to help (1) use the chrome runtime if it's already present and (2) at least allow two electron apps to share a runtime footprint.
I really like the ease of cross platform publishing. Even as a JavaScript developer, I loathe the memory footprint. 100-200mb per app doesn't bother me, though linking to already installed Chromium sounds like a good idea.
For now all the google-about things would always end up to benefit google instead bring convenient to user. Yes I just hate google, And what they bring to the web(For recent years only)
I think something like Electron should have been made but all I could find now is web browser or game engine.
There are already too many silly Apps on mobile platform, and Electron is just another that silly things in my eyes, since I'm just a stupid and arrogant user
If the former, I am on the "Electron sucks" bandwagon. But if it is the latter, the fact that there is even just one app that manages to use Electron to produce a product that does not suffer from these commonly cited issues would make me hesitate to discount it as a whole.
Building a web app and a cross platform desktop app is a common business requirement nowadays. Electron is the fastest way to achieve that with a small team or if going solo.
In many cases your only other feasible alternative would be to use Chromium Embedded Framework or system web views. Those two let you reuse your web app UI but are progressively more work than Electron. Those options don't require packaging a node server though.
PS. I don't think Slack is slow because of Electron. Other Electron apps like VS Code are fast.
I prefer to write apps with separate server and client parts and the client JS/HTML is generated by in-house tools and thus is a fraction of the size of anything that would uses any of the popular frameworks.
In any case, I'm finding that WebApps are easier to deploy and update than writing for native deployment. In the rare cases that I do need native features, I can deploy a local server which can then access whatever I need. The clean separation of concerns between client and server does simplify architectural design.
That said, if you work in a .NET shop already, you're certainly better off using a mono/CEF hybrid app. Just don't expect it to catch on, even if it generates superior software.
On the other hand, my laptop is an aging, refurbished Windows rig with a tiny SSD and all the energy efficiency of a stately Victorian mansion. I really can't afford to run anything Chromium-based when I'm on battery, which keeps me from using any of this generation of slick notes apps (e.g. Collate, whose dev is elsewhere in the thread.) What's more, there are almost no Electron apps where you can choose the installation location (VS Code is once again the exception, proving that it is possible), and the cavalier attitude of some devs when asked about this ([0]) drives me up the wall. So VS Code (and my own toy app) are the only Electron programs on my computer, and I don't see that changing in the near future.
[0] https://github.com/atom/atom/issues/7504 - One example of this attitude
Last time I checked, each window in your Electron app had to run in a different process. This is a design that makes sense for a web browser like Chrome, but not for the majority of desktop apps.
If your app is simple enough to only need one window, this won't be an issue, but otherwise, I found it a major pain.
As a developer, I avoid Electron apps because of the battery consumption. But that's just me. Your end user might not even know the stack or have no idea about it and only cares about the work being done. So yeah, I guess it's great for something which needs to be there as a desktop app.
From a dev's point of view: It's like how React Native is growing as an easy native app development tool. If a team can focus on one codebase instead of multiple, that's a great thing.
While I haven't use Electron, it looks very enticing. In particular the HTML/CSS combination allows to build UIs very fast. WebGL abstracts away the graphics drivers problems (at least in theory?). 2D Canvas is optimized and looking nice. And being non-native shorten the iteration times. Particularly for games it looks very adequate.
Users surely care about download size but not as much as functionality.
Also that a tiny app does not start for 10s on a strong laptop with a SSD.
Would that be a good lasagna? Probably not.
Will it reflect poorly on the restaurant? Most likely.
Why? Because they are OK with serving crap.
In terms of programming and development I think it's great. Not to mention that with JS there's tons of languages one can choose from -- think of Elm, PureScript, TypeScript etc.
It's unfortunate that google has stopped supporting chrome apps as a platform -- this was pretty much the solution. Single runtime + many apps.
It should be up to the community to pick up the slack, and launch a single (updating) runtime, and allow apps to run off it.
- Sensitive data that you do not want to be known by thid parties
- Very interactive applications where consistent subsecond response times are needed
- Applications that rely on data located in the computer (for example from other desktop applications)
Tried Atom and and Hyper and they felt really sluggish.
Only useful for web-only teams who have no desktop experience whatsoever. If you can afford to hire a desktop team, do it.
The relevant bugs are upstreamed to Electron.
for modern [web] developers.
Contrary to what one might think by reading tech blogs and HN, developers come in more varieties than just "web" and "wizard".