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.
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.
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?
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.
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.
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.
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 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.
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.
(not production-ready but it might be soon good enough for really quick GUI prototyping using subset of web technologies - javascript + react + flexbox + styles)
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.
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.
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.
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.
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.
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.