Electron 3.0.0-beta.1 – Chrome 66 and Node 10

https://electronjs.org/releases#3.0.0-beta.1

by STRiDEX • 8 years ago

138 102 8 years ago

f3f3_• 8 years ago

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?

nbst• 8 years ago

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.

nkkollaw4• 8 years ago

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.

kodablah2• 8 years ago

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.

nkkollaw4• 8 years ago

I see.

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

bigato2• 8 years ago

Using the browser installed in the system instead would reduce resource usage even further </ironic>

oblio• 8 years ago

You're kidding, but it should.

kodablah2• 8 years ago

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.

ttoinou3• 8 years ago

There's https://nodekit.io/ But it seems it's a dead project :-(

And https://github.com/zserge/webview doesn't seem to offer a lot of cross platform functionality

Spivak• 8 years ago

Kind of defeats the purpose of bundling your runtime for the purpose of having a single target to test against.

nkkollaw4• 8 years ago

Yes but then what if apps are built for another version?

lioeters• 8 years ago

There's a long-running issue (3 years~) with discussion around the idea of a shared runtime across apps.

https://github.com/electron/electron/issues/673

A few attempts at solving specific aspects, but no real solution yet..

freedomben• 8 years ago

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?

farnsworth• 8 years ago

Are the breaking changes here significant enough as to render existing tutorials and such obsolete/inaccurate?

That's not likely, the breaking changes are in the details of API. The fundamentals are the same.

cobar• 8 years ago

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.

murukesh_s2• 8 years ago

Even with large budget it's pain to keep two codebase with different issue trackers etc..

WorldMaker• 8 years ago

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.

lern_too_spel3• 8 years ago

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.

lossolo2• 8 years ago

What are the remaining APIs that people need in Electron that are not available in the web browser?

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.

eberkund• 8 years ago

No, but you can use an extension/native helper and talk to it from the web app using network calls.

Asooka• 8 years ago

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.

hanniabu• 8 years ago

Can't there be separate contained instances?

vvanders• 8 years ago

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.

adamcw• 8 years ago

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.

* https://www.neon-bindings.com/

scrollaway3• 8 years ago

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.

josteink3• 8 years ago

I would love to have the browser be a local "application server" on the desktop

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?

lern_too_spel3• 8 years ago

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.

tambourine_man4• 8 years ago

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.

zacmps• 8 years ago

chrome --app="https://www.google.com"

Gives you all of that, shame it's not better known.

plurgid• 8 years ago

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.

this is a very good thing (at least for me).

murukesh_s2• 8 years ago

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.

andrewstuart• 8 years ago

Just refuse to load for browsers other than Chrome.

Some users wont like it but Electron is a price too high if single browser target is your goal.

sam0x17• 8 years ago

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.

coldtea2• 8 years ago

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.

crooked-v• 8 years ago

What are the remaining APIs that people need in Electron that are not available in the web browser?

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?

bigato2• 8 years ago

Do you want to give RANDOM_EVIL_WEBSITE access to your LAN?

Off course not, I prefer to install it as an electron app.

t1amat• 8 years ago

This is already the case. JavaScript from websites execute in the context of the browser which means it has access to your local network.

kyriakos• 8 years ago

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.

saurik• 8 years ago

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 :(.

lcnmrn• 8 years ago

Isn’t possible to replace Chrome with another lightweight browser engine?

pjmlp5• 8 years ago

It is called web widget in most desktop OSes.

snarfy• 8 years ago

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.

[1] https://github.com/zserge/webview

gitgud• 8 years ago

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?

singularity2001• 8 years ago

Long list of Breaking changes, some fixes, did I miss the features section or are they inspired by angular.XX?

cornholio• 8 years ago

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.

cjbprime• 8 years ago

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.

ljm• 8 years ago

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.

[0] https://github.com/pojala/electrino

pjmlp5• 8 years ago

Dreamweaver is pretty much alive.

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.

smaddock• 8 years ago

There's some discussion about this in the Electron GitHub issues, but development is fairly inactive afaik.

https://github.com/electron/electron/issues/673

stillbourne2• 8 years ago

Yeah but when can I start using it on android and ios too? I still don't understand why they don't try to make the platform truly crossplatform.

stephenr2• 8 years ago

so you always have your phone plugged into power then?

ibrault• 8 years ago

Seriously, if it makes a serious dent in my laptop, imagine what it would do to a mobile device...

stillbourne2• 8 years ago

I was thinking more about getting electron apps to work on my chromebook and ios tablets.

SiVal• 8 years ago

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.

veidr2• 8 years ago

Pooo Opportunity people put dd

styfle• 8 years ago

I like Electron, but there are alternatives.

I’ve been keeping a list of Desktop JS frameworks[0] that might interest web devs wanting to make desktop apps.

[0] https://github.com/styfle/awesome-desktop-js

Electron 3.0.0-beta.1 – Chrome 66 and Node 10

Related Stories