10 ms·

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

138 points by STRiDEX 8y ago

f3f3_ 8y 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 8y 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.
nkkollaw 8y 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.
- kodablah 8y 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.
  - nkkollaw 8y 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
    - untog 8y ago
      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)
      - nkkollaw 8y ago
        Ah, I see what the problem is, then. 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.
- bigato 8y ago
  Using the browser installed in the system instead would reduce resource usage even further </ironic>
  - oblio 8y ago
    You're kidding, but it should.
  - kodablah 8y 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.
  - ttoinou 8y ago
    There's https://nodekit.io/ https://nodekit.io/ But it seems it's a dead project :-( And https://github.com/zserge/webview https://github.com/zserge/webview doesn't seem to offer a lot of cross platform functionality
    - 52-6F-62 8y ago
      > And https://github.com/zserge/webview 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.
      - RussianCow 8y ago
        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.
- lioeters 8y 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 https://github.com/electron/electron/issues/673 A few attempts at solving specific aspects, but no real solution yet..
freedomben 8y 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 8y 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.
- postalrat 8y ago
  You believe it's the best choice and don't want to hear anything different. That's nice.
  - fortyseven 8y ago
    And?
  - freedomben 8y ago
    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.
lern_too_spel 8y 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.
- lossolo 8y 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 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 8y ago
    No, but you can use an extension/native helper and talk to it from the web app using network calls.
    - d4l3k 8y ago
      Might as well just use electron at that point since it's easier on the developer side.
      - solarkraft 8y ago
        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.
      - untog 8y ago
lcnmrn 8y ago
Isn’t possible to replace Chrome with another lightweight browser engine?
- pjmlp 8y ago
  It is called web widget in most desktop OSes.
- snarfy 8y 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 https://github.com/zserge/webview
- gitgud 8y 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 8y ago
Long list of Breaking changes, some fixes, did I miss the features section or are they inspired by angular.XX?
cornholio 8y 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 8y 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 8y 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 https://github.com/pojala/electrino
stillbourne 8y 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.
- stephenr 8y ago
  so you always have your phone plugged into power then?
  - ibrault 8y ago
    Seriously, if it makes a serious dent in my laptop, imagine what it would do to a mobile device...
  - stillbourne 8y ago
    I was thinking more about getting electron apps to work on my chromebook and ios tablets.
    - stephenr 8y ago
      Oh I'm so sorry I've misunderstood completely... So you always have your tablet plugged into power then?
- SiVal 8y 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.
veidr 8y ago
Pooo Opportunity people put dd
styfle 8y 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 https://github.com/styfle/awesome-desktop-js

138 points by STRiDEX 8y 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 8y 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.

nkkollaw 8y 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.

kodablah 8y 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.
- nkkollaw 8y 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
  - untog 8y ago
    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)
    - nkkollaw 8y ago
      Ah, I see what the problem is, then. 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.
bigato 8y ago
Using the browser installed in the system instead would reduce resource usage even further </ironic>
- oblio 8y ago
  You're kidding, but it should.
- kodablah 8y 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.
- ttoinou 8y ago
  There's https://nodekit.io/ https://nodekit.io/ But it seems it's a dead project :-( And https://github.com/zserge/webview https://github.com/zserge/webview doesn't seem to offer a lot of cross platform functionality
  - 52-6F-62 8y ago
    > And https://github.com/zserge/webview 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.
    - RussianCow 8y ago
      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.
lioeters 8y 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 https://github.com/electron/electron/issues/673 A few attempts at solving specific aspects, but no real solution yet..

freedomben 8y 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 8y 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.
postalrat 8y ago
You believe it's the best choice and don't want to hear anything different. That's nice.
- fortyseven 8y ago
  And?
- freedomben 8y ago
  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.

lern_too_spel 8y 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.

lossolo 8y 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 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 8y ago
  No, but you can use an extension/native helper and talk to it from the web app using network calls.
  - d4l3k 8y ago
    Might as well just use electron at that point since it's easier on the developer side.
    - solarkraft 8y ago
      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.
    - untog 8y ago

lcnmrn 8y ago

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

pjmlp 8y ago
It is called web widget in most desktop OSes.
snarfy 8y 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 https://github.com/zserge/webview
gitgud 8y 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 8y ago

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

cornholio 8y 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 8y 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 8y 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 https://github.com/pojala/electrino

stillbourne 8y 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.

stephenr 8y ago
so you always have your phone plugged into power then?
- ibrault 8y ago
  Seriously, if it makes a serious dent in my laptop, imagine what it would do to a mobile device...
- stillbourne 8y ago
  I was thinking more about getting electron apps to work on my chromebook and ios tablets.
  - stephenr 8y ago
    Oh I'm so sorry I've misunderstood completely... So you always have your tablet plugged into power then?
SiVal 8y 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.

veidr 8y ago

Pooo Opportunity people put dd

styfle 8y 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 https://github.com/styfle/awesome-desktop-js