Electron 3.0.0-beta.1 – Chrome 66 and Node 10
electronjs.org
electronjs.org
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.
https://nodejs.org/api/index.html
I don't think APIs like full access to filesystem will be available in browser because any malware could do anything it would like with your OS/files.
So in a lot of cases you can't really replace Electron with just normal webapp in browser.
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.
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.
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.
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.
https://docs.microsoft.com/en-us/dotnet/core/deploying/
On the Windows side, .NET Native does static linking.
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.
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.
Back in the days we called that a WebView.
And when MS made one with MSIE and used that in Windows, we sent the EU after them.
How times change, eh?
Big difference, sure.
> 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.
They got rich(er) and crippled competition for years to come?
But then again, I know nothing. This is just a feeling I have.
[0]: Yes, and I think they also got the message loud and clear that this would just be a start unless they started behaving
[1]: not saying they are saints yet, but as a nix user out in the trenches I very much prefer the current Microsoft.
That was because they were a monopoly (among several other reasons, such as "bundling", threatening OEMs and so on).
Not because they offered webviews (which was totally irrelevant).
Edit: What I more specifically had in mind was Firefox Prism, from circa 2007. https://wiki.mozilla.org/Prism
Why this stuff didn't take / isn't more popular now, I don't really know.
It’s a lot easier to argue that a web browser is an essencial part of an OS this way.
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.
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.
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?
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.
https://www.dropbox.com/s/348mh6wlmuayflp/Screenshot%202018-...
And if the App forgets to expose that option (Skype, for instance), tough noogies.
Gives you all of that, shame it's not better known.
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.
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.
this is a very good thing (at least for me).
Some users wont like it but Electron is a price too high if single browser target is your goal.
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...)
https://github.com/electron/libchromiumcontent/issues/384
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 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.
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.
Broad-use network access, including local subnets.
> And what's the timeline to getting those in the browser
Do you want to give RANDOM_EVIL_WEBSITE access to your LAN?
Off course not, I prefer to install it as an electron app.
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?
That's not likely, the breaking changes are in the details of API. The fundamentals are the same.
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.
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.
It seems like such an obvious solution used by all languages that require a runtime.
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.
https://www.adobe.com/products/dreamweaver.html
And it has Animate (nee Flash) and Spark as companions.
https://www.adobe.com/products/animate.html
https://www.adobe.com/products/spark.html
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.
I’ve been keeping a list of Desktop JS frameworks[0] that might interest web devs wanting to make desktop apps.
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?
So you always have your tablet plugged into power then?
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.
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.
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.
I meant more that Electron would add ~/.electron/chrome-66.so, and guarantee that it will be there or downloaded if required by an Electron app.
Then, all apps that are built against Chrome 66 would all use a single ~/.electron/chrome-66.so
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.
And https://github.com/zserge/webview doesn't seem to offer a lot of cross platform functionality
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.
It's a very cool library outside of that—for any gawkers here.
https://github.com/electron/electron/issues/673
A few attempts at solving specific aspects, but no real solution yet..