4 ms·

Each Electron app comes with a very specific versions of Chromium and Node.js. They can't run on native frameworks. If native frameworks are updated old apps w

by lcnmrn 8y ago

Each Electron app comes with a very specific versions of Chromium and Node.js. They can't run on native frameworks. If native frameworks are updated old apps would break. If native frameworks aren't updated newer apps would break. What you're asking was already tried with Adobe AIR and failed. Instead we need lighter alternatives to Node.js and Chromium.

azhenley 8y ago
I'm really starting to think it would be a good PhD dissertation project to (semi?) automatically reduce Chromium to the bare minimum needed for a given Electron app. The techniques could probably be applied to reducing any library and would be of interest to researchers in SE and PL, along with industry.
- DonHopkins 8y ago
  That's not just tree shaking, that's more like rainforest shaking!
- cat199 8y ago
  > good PhD dissertation project why? would not existing static analysis/dependency pruning take care of it if someone had the time? I don't see what would be 'novel' here from a theoretical point of view.. still a good project possibly though
  - azhenley 8y ago
    That is the research of it, we don't know if existing techniques would work! And surely there are novel improvements that could be made, particularly for this specific application. Also, I imagine there are many cases where static analysis would not be enough for the JS app.
    - barbecue_sauce 8y ago
      Sounds more like an undergrad thesis.
- andai 8y ago
  An old man once said, "write the thesis you wish to see in the world."
- nickpsecurity 8y ago
  That's exactly what I thought. You just include what you use. Either developer does it on a confijguration screen, a tool does it with analysis on what code reaches what other code, or both. It would also help if Chrome is designed to make this easier. eCos is prior work on OS side that made me always think of designing systems for easy stripping. http://ecos.sourceware.org/about.html http://ecos.sourceware.org/about.html
- Andrex 8y ago
  Hm, would headless Chromium be a good starting point for this?
jf- 8y ago
Or maintain backwards compatibility. You don’t need to remove deprecated API features, just mark them as deprecated. It would add some size but it’s better than the alternatives.
m0dest 8y ago
This concern about breaking only seems true for the Node.js side. The HTML/JS/CSS running in the web view should be pretty resilient to version upgrades; web devs are used to defensive, backward-compatible design that handles multiple browser versions. The bridge itself is API stable. evaluateJavaScript:completionHandler: isn't going anywhere. So the question is whether it's okay to use a native web view while still bundling your own V8 + Node. That seems like an improvement to me!
- dchest 8y ago
  The bridge itself is API stable. evaluateJavaScript:completionHandler: isn't going anywhere. Historically, this hasn't been the case. Apple loves to deprecate stuff (although, thankfully, they are a bit slower to remove it). Before WKWebView there was a "stable" WebView.
  - bunnycorn 8y ago
    And if my memory serves me well, you couldn't even use WK version with local files! Clearly indicating that was not the way to make UIs, but to browse the real web...
cztomsik 8y ago
shameless self-promotion https://github.com/cztomsik/node-webrender https://github.com/cztomsik/node-webrender (not production-ready but it might be soon good enough for really quick GUI prototyping using subset of web technologies - javascript + react + flexbox + styles) HMR & react-devtools are already supported.

by lcnmrn 8y ago

azhenley 8y ago

I'm really starting to think it would be a good PhD dissertation project to (semi?) automatically reduce Chromium to the bare minimum needed for a given Electron app. The techniques could probably be applied to reducing any library and would be of interest to researchers in SE and PL, along with industry.

DonHopkins 8y ago
That's not just tree shaking, that's more like rainforest shaking!
cat199 8y ago
> good PhD dissertation project why? would not existing static analysis/dependency pruning take care of it if someone had the time? I don't see what would be 'novel' here from a theoretical point of view.. still a good project possibly though
- azhenley 8y ago
  That is the research of it, we don't know if existing techniques would work! And surely there are novel improvements that could be made, particularly for this specific application. Also, I imagine there are many cases where static analysis would not be enough for the JS app.
  - barbecue_sauce 8y ago
    Sounds more like an undergrad thesis.
andai 8y ago
An old man once said, "write the thesis you wish to see in the world."
nickpsecurity 8y ago
That's exactly what I thought. You just include what you use. Either developer does it on a confijguration screen, a tool does it with analysis on what code reaches what other code, or both. It would also help if Chrome is designed to make this easier. eCos is prior work on OS side that made me always think of designing systems for easy stripping. http://ecos.sourceware.org/about.html http://ecos.sourceware.org/about.html
Andrex 8y ago
Hm, would headless Chromium be a good starting point for this?

jf- 8y ago

Or maintain backwards compatibility. You don’t need to remove deprecated API features, just mark them as deprecated. It would add some size but it’s better than the alternatives.

m0dest 8y ago

This concern about breaking only seems true for the Node.js side. The HTML/JS/CSS running in the web view should be pretty resilient to version upgrades; web devs are used to defensive, backward-compatible design that handles multiple browser versions. The bridge itself is API stable. evaluateJavaScript:completionHandler: isn't going anywhere. So the question is whether it's okay to use a native web view while still bundling your own V8 + Node. That seems like an improvement to me!

dchest 8y ago
The bridge itself is API stable. evaluateJavaScript:completionHandler: isn't going anywhere. Historically, this hasn't been the case. Apple loves to deprecate stuff (although, thankfully, they are a bit slower to remove it). Before WKWebView there was a "stable" WebView.
- bunnycorn 8y ago
  And if my memory serves me well, you couldn't even use WK version with local files! Clearly indicating that was not the way to make UIs, but to browse the real web...

cztomsik 8y ago

shameless self-promotion https://github.com/cztomsik/node-webrender https://github.com/cztomsik/node-webrender (not production-ready but it might be soon good enough for really quick GUI prototyping using subset of web technologies - javascript + react + flexbox + styles) HMR & react-devtools are already supported.