Hacker News Reader

Comment by lcnmrn | Hacker News Reader

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.

View on HN

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.

That's not just tree shaking, that's more like rainforest shaking!

> 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

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.

Sounds more like an undergrad thesis.

An old man once said, "write the thesis you wish to see in the world."

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

Hm, would headless Chromium be a good starting point for this?

shameless self-promotion 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.

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!

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.

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

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.

Reply on news.ycombinator.com