What are the remaining APIs that people need in Electron that are not available in the web browser? And what's the timeline to getting those in the browser to deprecate Electron?
In cases like Slack, I prefer using the webapp because I trust the Chrome team to update quickly if there is a vulnerability in the browser. I do not trust Slack to update its Electron app quickly if there is a vulnerability in Chrome.
> What are the remaining APIs that people need in Electron that are not available in the web browser? And what's the timeline to getting those in the browser to deprecate Electron?
I get what you're saying but to me, even if I could do literally everything that node does inside the browser, that STILL would not deprecate electron for me.
It's not lack of functionality in the browser that's a problem for me. It's mutability of the browser.
With electron, I get to use ONE version of javascript, ONE implementation of the DOM, ONE implementation of CSS. Period.
I do not give a single hoot about that ancient corporate version of IE you have to use at work. About how this looks in safari, versus edge versus, opera, versus whatever.
It simply doesn't matter anymore.
no more shims, and I can dump about half of the frameworks and stuff from my code because of it.
If I get an app going that everyone likes and I actually want it on the web, THEN I can go and add all the cruft I'll need to make it work out there in the wild.
You got a great point. And don't forget that Electron is not a web shell, it can replace native apps. Look at VSCode! It's not just about Electron vs Browser but there are certain cases where you don't want to go into a cloud.
You also get full control over the local file system with electron. There are plenty of system utilities... stuff like etcher.io, disk partitioners, backup software, custom FUSE-based file systems, etc., that you couldn't do purely in a web browser for security reasons, but that can benefit from the portability and sexiness of an electron-based UI (performance concerns aside).
I actually doubt there is anyone who thinks of electron in this way, in that they only use it because X feature isn't in the browser _yet_. Many electron apps could only be done natively, again for security reasons. Things like the slack desktop app don't meet that criteria, however.
I think you meant to say "This website is optimized for IE 5.0 and 640x480 please upgrade your browser". Chrome still lacks something essential that IE had back in the day: API and bug for bug stability. Moving targets just aren't as atractive.
Hmm, I have never seen a conflict like that with any of the Electron apps I use daily: VSCode, Cypress, Wire, and (blecch) Slack.
What app was that, and what platform did you see it on? (I use the apps mentioned above on macOS, Windows 10, Ubuttnu 18.04, but I guess 80% of the time I'm using macOS so I might not have noticed if its a Linux thing...)
tl;dr (as I understand it) is that a change in FreeType invalidated an assumption that programs were making in how fonts were rendered, making text look garbled. It was fixed pretty quickly in Chromium and Firefox, but it took a few months to trickle through to Electron and finally to the apps based on it. In the meantime, Linux distros had started upgrading to the new "fixed" (seemingly broken) FreeType, so the workaround was to downgrade FreeType until any affected Electron apps were updated.
I would love to have the browser be a local "application server" on the desktop. Currently, people hate electron because shipping and running duplicate browsers is heavy-handed, insecure, and silly.
There's definitely a different feeling between having a running Discord/Slack tab vs. using a native app for it, if you're using it a lot. A native notification bar icon, shortcuts in the menus/app launchers, the app not exiting if i need to restart the browser, the app not being affected by extensions I install (adblockers, etc).
The app being separate from the browser is good. But it should still be the same engine running this. The same master process as well, possibly?
Either way, Electron has been a huge boon for apps being available natively on Linux and that's just awesome. I don't want to lose that.
>Currently, people hate electron because shipping and running duplicate browsers is heavy-handed, insecure, and silly.
And because they are bad OS citizens. You can’t use the system’s spell checking, dictionary, undo/redo, shortcuts, abbreviations, better text rendering… the list goes on and on.
If it is a webapp, I can at least use Safari, which has none of those issues.
You're right… kind of.
For some reason it's not available throught contextual menu, like other apps, only in the Edit menu.
https://imgur.com/a/2FDNDu4
And if the App forgets to expose that option (Skype, for instance), tough noogies.
> And when MS made one with MSIE and used that in Windows, we sent the EU after them.
> How times change, eh?
That was a very short story.
Mine is a bit longer and includes MS intentionally crippling HTML if their servers sniffed Opera headers.
Edit: Google employees here, -please remind your bosses and colleagues what happened last someone abused their position to dominate the browser market.
Yes, I had webview in mind when I was writing that comment. But obviously WebViews aren't good enough. We're talking about enough functionality to own a multi-window app.
> A native notification bar icon, shortcuts in the menus/app launchers
This already works out of the box. "More tools -> Create shortcut..." in Chrome will create a launcher in the Gnome menu that will open Slack in its own window without a location bar.
> the app not exiting if i need to restart the browser, the app not being affected by extensions I install (adblockers, etc).
I want to be able to modify web apps, and I want to restart all webapps when I receive a security update for Chrome.
I don't think the advantages outweigh the risks for most Electron apps that also have webapps.
> > the app not exiting if i need to restart the browser, the app not being affected by extensions I install (adblockers, etc).
>
> I want to be able to modify web apps, and I want to restart all webapps when I receive a security update for Chrome.
You guys are sort of talking past each other here --- you both have something different that you want, and since Slack runs in both a standalone Electron shell and in the browser, it's giving you both what you asked for.
Why dismiss the things he likes in a standalone app as not addressing your needs for an in-browser webapp?
A shared runtime, with shared security updates, and applications being spawned as "standalone", with a cmdline parameter like --master-config that would let me enable Inspector and any specified addons. Because I agree, being able to freely modify third party software is huge.
Yeah I mean, Chrome tried to do it with Chrome Apps. It's older than Chrome, too. Firefox did it back in the days using a technology called "Prism": https://wiki.mozilla.org/Prism
It just.. it's not taking. It's not a valid way, right now, of telling people "Here's your native electron-like app". Why? It's hard to tell where the limits are.
One of the things Electron gives you with Node on the backend is the ability to break out into C FFI if you find you need a specific API on your target platform.
I've done this for things like serial device control and the like. You still get the productivity of web apis on the frontend and flexibility on the backend with the caveat that you're going to be building a platform specific version of your native code for each release.
While discussing the Node C binding architecture, I think it's also worth noting The Neon Project* which is extending that lower level binding system into the Rust ecosystem. I'm not personally involved in the project, but I think it has a lot of potential.
Or maybe some form of web archive format signed with a certificate? "Do you want to install Slack? It will have access to X, Y, Z"...
We already download programs off the internet and let them run with local privileges all the time, it should be possible to safely and securely extend the capability to programs delivered as html+css+js.
Also I don't see why Electron+node isn't installed system-wide like Java or .NET. Yes, I know it's because node is a server technology whose devs aren't interested in being Java, while the people shipping electron apps are just interested in the lowest friction to deploying native apps to customers, but it still seems like the kind of thing someone would have done already if only just to show off.
To be fair, .NET has the capability to release applications with all the pieces required in a single exe. At least core does, anyways. That's a pretty big selling point for golang, as well, in my mind. Electron is the same thing in my mind, just on a much larger scale. Maybe it's too large to be sustainable in the long term, but there are definite benefits to having a single, self contained package.
They're still not there with the Golang-style single exe for .NET Core. The default behaviour of the dotnet build tool seems to be to build a .dll file (!)
Sure, such that in my experience users prefer dedicated apps most of the time.
For example, Postman (browser-based HTTP client) has some of the worst UX because it's a Chrome app and not stand-alone. Can't event alt-tab to it. I have to alt-tab to Chrome and then find the Postman window.
Users also prefer to be able to use more than one program at a time on their computer, so please, if you have to use Electron, keep an eye on performance characteristics of your application.
But even worse for the user than a web browser already is.
Can we, instead of combining the worst of native apps, web apps and containerizaton, maybe work towards removing SOME of the terrible aspects for users? If developer comfort is the highest priority you might as well skip making the interface look nice/useable.
Electron really is an extension of Chrome and it'd be damn nice if it could be shipped as one.
As market shows it's not about what you can do but what is the easiest and fastest way to make a product.
I've created Electron application also, not because it's the best solution on the market but because it was fast and easy way to get my app to the users.
If I had time and resources I would probably just use Qt or created native app for each platform.
>What are the remaining APIs that people need in Electron that are not available in the web browser? And what's the timeline to getting those in the browser to deprecate Electron?
The main attraction is the ability to NOT run in the browser, but be a standalone app.
It's not just about the browser not providing some native APIs.
One thing electron offers that is not mentioned is a predictable platform for your application. Users can use different browsers and even today this is still a problem. But distributing an electron app you know at any moment what apis you have available and how they behave.
As far as I have been able to tell the Chrome team considers native sockets something they don't ever need to even pretend to provide in the browser anymore (after removing Chrome Apps support) in no small part because of the existence of Electron, so the powers that be seem to be going in the opposite direction :(.
Going to be starting a new electron app very soon (please, no comments about whether it's the correct choice and we should be using ${favoriteLibrary}. We discussed the pros and cons extensively, and we believe it is the best choice for us and our domain).
Are the breaking changes here significant enough as to render existing tutorials and such obsolete/inaccurate? If so, are there newer tutorials that would be better?
They should be pretty minor. I've found that it's rare you need to rely on any of the Electron APIs. For the most part, Electron just provides a shell to load HTML/JS/CSS and that's where the overwhelming majority of the code lives.
The only time you need to access Electron APIs is to create and manage windows, system menus, etc.
For all the hate against it, we've been very happy with Electron. There's no way we'd have been able to afford to offer Windows and OS X given our limited budget without it.
To add to the other answers here, Electron recently switched to an approach to semver where major dependencies (in this both Node and Chromium) are always considered themselves a semver major/breaking change. This aligns with Node's similar, less recent switch to semver major for all V8 upgrades.
The biggest breaking changes here are very much that Chromium and Node were both upgraded. These are particularly breaking changes if you are using and/or building native Node libraries.
Skimming through the rest I didn't see anything that directly impacted any of the apps that I've worked on or any of the tutorials I've seen.
To have an educated opinion on whether it's the right choice for us, one must know:
1. How much existing code is there to integrate with, and what language is it in?
2. What is the experience level of the existing team, and in what platforms?
3. Who is the target market? How will they use the product?
4. What capabilities will the app need? Will it be graphics intensive?
5. What will the maintenance story need to look like?
6. How much time/money can be thrown at this? (ties into how long we can spend working on it)
7. When must it ship? (Also speaks to iteration speed)
8. How hard will shipping updates be?
And probably more that I couldn't think of just now. In order to have a productive discussion about whether electron is the right choice, I would need to detail all of that. Unless of course you just want to use the "electron is never the right choice" argument without knowing anything about our situation, which is what I see on HN a lot every time electron comes up, and what I was pre-emptively hoping to avoid. I might also say that I am not a fan of electron apps, and only use them when I have to (mostly due to huge size and memory requirements, which I don't fault electron for, but rather I fault the developers that are not conservative with resources and memory allocations). That said, I'm glad it's around because there are apps I don't think would exist without it.
I would actually really enjoy having the discussion about whether it's a good choice or not, but it would be good to have that separate from my original question. It likely would have be drowned out in the noise.
Is there a packaging option for Electron where I can point it to a bunch of html files, and I get a 1MB installer, capable of dowloading and installing the runtime on the target system, if not already present?
It seems like such an obvious solution used by all languages that require a runtime.
There was an attempt with electrino [0] that has ultimately been abandoned (I'm sure the author has posted their story here before). It aimed to provide an electron compatible API over the native browser controls, which is definitely ideal but not so much for those who just want to write for Chrome and nothing else.
I think native app development might have a fair chance if it could adapt to some of the decisions the web dev community (and communities using server-side languages) have made over the years.
- There was a fairly universal rejection of WYSIWYG editors after the Frontpage/Dreamweaver era, once CSS2 and XHTML started to become a thing; yet your default option for building a Mac or Windows app is to download around 6GB worth of IDE, interface builders, and other toolkits you'll never even know you'll need before you can properly get started.
- While you might consider a webpack or babel setup to have appropriated the position, you don't require the solution or project file those editors build to get a hello world up and running by hand. An index.html and an app.js is enough to deploy an entire application.
- hot code reloading and debugging in the UI is a breeze (react native and flutter have been great for this too); no need to manually rebuild on each change.
This comes at the cost of dealing with the usual web-dev bugbears, ones that don't exist when you're working in C# or Obj-C or Swift or whatever, but the browser has almost accidentally become this amazing environment for experimental app development, that I imagine in some ways takes what Smalltalk had to offer in a totally different direction.
It would be interesting to see what OS vendors could do to level the playing field there. I enjoy doing native app development a lot but I do miss some of what you get from working with JS and React.
All of them also weight as much GB as most IDEs and yet not as easy as something like Winforms or Delphi for the complete experience.
Regarding levelling the playing field, UWP supports WebApps and PWA apps delivered via the store have access to UWP APIs, no need to have Electron around.
Electron's API stability isn't awesome, so in practice I think you'd tie html bundles to runtime versions, and just end up with an awful lot of globally installed Electron runtimes on your system.
Nice to see Electron moving forward. Is there a place where a summary of the changes coming in 3.0 can be found? Particularly regarding bloat - both in terms of file size and memory usage?
The V8 memory improvements (as benchmarked in the official V8 blog) should really help, but I agree it would be nice to see a benchmark for an Electron Hello World.
An alternative to Electron is Webview[1]. For OSX and Linux it's based on WebKit. For windows it uses IWebBrowser2. It's a tiny shim around the OS's browser control.
Chrome spent considerable effort making sure things "look the same" across many OS's and hardware.
The argument I've heard, is that With lighter weight browsers you begin to lose that consistency across platforms, so chrome is currently the best solution.
What if you were able to do some kind of pruning with chrome to remove as much dead code from an Electron project. A hello-world in Electron would surely allow compression opportunities, rather than a full chrome instance, right?
Apple won't allow any browser engine except Safari to be installed on any iOS device. And I'm not aware of any movement toward basing Electron on Safari. Unless one of those changes, you can count iOS out with no need to discuss technical questions of power drain, app permissions, or whatever.
What many phone devs do instead is to create a native app as a minimal native shell around a "web view" window that is provided by the OS.
Does it by any chance provide a shared Chrome version across apps?
It seems possible to have a single (or 1 for every version) instance of Chrome on the system, and Electron apps could use the same one, or tell Electron they need another version and it could download it.
This would I _suspect_ reduce memory usage and app size.
> This would I _suspect_ reduce memory usage and app size.
App distribution size maybe, just like any app relying on shared libs on the system, but it needs to be ready to install them if not already present and has to have strict compat guarantees. With download speeds and disk sizes being what they are, most people would just ship the lib w/ the app anyways. It would have no real affect on runtime memory usage; surely runtime mem cost of a browser is more on what it loads/does, not its code.
Now, if Chrome would put chrome.dll (or chrome.so or whatever) in a reliable location and promise ABI compat w/ some functions, there could be some real reuse since a lot of people have Chrome on their systems and could be used as a webview. However, I wouldn't expect Google to do any such thing both because they don't want to restrict themselves with compat guarantees and embeddability has no benefit for them.
Eh, that would save in hard disk space but that's hardly the main concern. What you'd actually want is the ability to use the same Webview runtime across processes, which this wouldn't allow. Android does it, but I don't know if it's possible on desktop OSes (easily)
I've always thought it was something they were going to do sooner or later.
Electron gets a lot of hate, while I think it's a great tech and 90% of the apps I use are available just because of its existence, since I'm on Linux and they wouldn't bother porting them if it wasn't made easy by Electron.
Not to drag this too far off topic—but outside of the API differences between webviews— what do you mean?
I imagine it could be used to serve something like Slack's web app for example which [I imagine] would have been built to bend to each of those browsers' functionality to begin with.
The point is that you would have to re-implement Node's/Electron's APIs on top of each browser engine, so that OS functionality could be exposed to the JavaScript code. That webview project does not expose very much in the way of system API calls, which is what the parent was referring to.
I see now. So basically for anything beyond replicating a web app or pointing to (à la Slack, HipChat, Stride, etc)—or anything else that doesn't require native access.
It's a very cool library outside of that—for any gawkers here.
Unified API for UI dialogs, file handling, file drag and drop, clipboard, keyboard shortcuts, http(s) requests, image loading, OS notifications, OS menus etc.. ?
Maybe one should use the webview repo in conjunction with another GUI cross platform library ?
Some systems don't allow their most modern browser to be easily consumed. Also, Chromium has features that some default-distro browsers don't. Finally, using browsers on the system don't always give flexibility that Electron does and even when they do, the abstraction to the greatest common factors just so you can work cross-platform leave a lot out.
Apps like Slack that expose a web version of the product are tested across different browsers anyway, so that wouldn't change unless your Electron app was desktop-only.
In cases like Slack, I prefer using the webapp because I trust the Chrome team to update quickly if there is a vulnerability in the browser. I do not trust Slack to update its Electron app quickly if there is a vulnerability in Chrome.