Hacker News Reader

Comment by bunnycorn | Hacker News Reader

It would be nice to have an Electron 100% compatible framework (drop-in replacement) that instead of using Chrome, it would use Apple's webviews that are of course based on WebKit.

It would be faster and take much less RAM, specially when multiple Apps are open and they could use the shared library.

Also, now that Chromium is going to be part of Windows, the same would also be a good idea, I think.

View on HN

So, every time Apple updates WebKit your app breaks. We've gone through this in the past. There are multiple reasons Electron is a win.

1. It's cross platform

   Don't have to deal with the fact that Safari is missing these 12 APIs or has different edge cases

2. It's stable after shipping

   Users get a new version only when you ship. If you use the native widget then users get a new (often broken) version on every update by a 3rd party (Apple/MS/Google). Example: chrome just deprecated autoplay. If that bubbled into apps your app just broke. Electron could do the same but if you're testing like a good dev that break wouldn't make it to users. You as a dev would find it locally, deal with it, and only after ship to users.

so, no personally I don't want a shared widget. that sounds like going back to DLL hell or worse, just broken stuff.

WebKit is free so you can bundle the library if you want. Or not.

What is the point in that now? It is going to be a similar size as Chromium. You might as well just use Electron.

As a matter of fact, Chromium's/Chrome's engine Blink was forked off from WebKit back in 2013. Current WebKit is Apple's not-quite-as-well-updated version of the engine in old Chrome.

Doesn’t stable after shipping also mean that if a critical vulnerability is found in the version of electron/chromium that you’ve bundled, the user is vulnerable until you are able to issue a fix? What if the app itself is no longer updated?

How is that different than any native app? All native apps have that issue.

Native apps can benefit from using shared libraries, which can be updated in such case. Using WKWebView ensures that vulnerabilities are patched as part of OS updates.

On OSes with sane package managers (e.g. Linux distributions) native apps can share all dependencies, so there is no need to recompile/redistribute each application using affected library.

Sadly, there is no such thing on MacOS (excluding brew/port) and Windows (or even iOS/Android), and even native Linux applications are moving towards bundling all dependencies in a single package.

Typically a native application will depend on shared libraries (or runtime such as jvm, .net) which can be updated independently of the application itself. That said, if the vulnerability is in the application code, you are correct, there would be little difference.

Could you avoid using code blocks for text? They are very difficult to read on mobile.

blame HN, I didn't format them as code blocks. I put #.<space>text<cr><space><space><space>text which in any other context would be text not code

If you use the "API's": standard HTML and standard JS, like a good citizen, I really doubt that would be a problem. And if it is, it's you job to update you app, also Apple provides pre-release versions with good antecedence.

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.

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?

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.

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

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.

Flutter does this. https://github.com/google/flutter-desktop-embedding looks for your local version of chrome. Curious if anyone has thoughts on it.

Flutter doesn't use Chrome. I think you're thinking of Carlo[1].

[1] https://github.com/GoogleChromeLabs/carlo

I was, thank you for the correction

Half of electron is being able to leverage the Node.js ecosystem and Chrome APIs. Creating a "drop in" replacement would require a ton of work and constant keeping up-to-date.

> leverage the Node.js ecosystem and Chrome APIs

Aren't those fairly discrete areas with fairly different levels of work? Doesn't most of what's on NPM run in WebKit / Gecko these days, anyway, since people commonly deploy client-side?

Having a shared electron runtime on each platform is an answer to some of its performance-related criticisms. Hopefully this is what Microsoft are going for with chromium and the github acquisition. There would still need to be compatible equivalents on Mac and Linux however, or it would render the endeavour pointless.

> a shared electron runtime on each platform is an answer to some of its performance-related criticisms

Like…Chrome?

Given that electron is not chrome, no, not chrome. A specially made, backwards compatible chromium/node/whatever bundle, that developers can build against without fear of having their apps broken by future API changes.

Yes, that's the only answer, and it's a good one! It will be great and benefit everyone if Microsoft can pull that off on all platforms.

Check https://terrainformatica.com/2018/12/23/sciternode-versus-el... and discussion: https://news.ycombinator.com/item?id=18746408

In principle that is doable. Not sure about 100% compatibility as only WebKit (particular version) is 100% compatible with WebKit (particular version here). Edge is gone in that fight. Mozilla is standing but is not 100% compatible.

Aren't those just called PWAs these days?

Reply on news.ycombinator.com