Electron v5.0 Timeline
electronjs.org
electronjs.org
Favorite recent example, Chrome's audio blocking solution pretty much broke every HTML5 game in existence. 1000s of sites are still broken. To just name some easy categories, every Pico-8 game exported to HTML5, Every Unity and Unreal game exported to HTML5. Even 100s of Google's own Doodles, examples, promotions, etc ... until they pre-whitelisted every domain they own.
The worst is Apple. Trying to do anything game related in a webpage on iOS Safari is a nightmare and is pretty much guaranteed to break with each new iOS release. "minimal-ui" (nope, took that way), "user-scalable" (worked but they keep changing the conditions so old games break and have to reverse engineer under what conditions it's respected). I recently noticed one of my sites broke for audio. No errors, no mention of what changed that I can fine, worked 6 months ago, stopped working, Safari only. Note it's a site about audio and it doesn't start that audio until the user clicks the "Play" button. It's using the "resume" api but no sound comes out. Still works in Firefox and Chrome (after having to update it last year for Chrome's breaking change)
That said, it's definitely not yet feature-rich enough to fully displace Electron.
Give it a couple of years and Electron would be as common as MSHTML, HTA, XUL apps.
Google Chrome went from proposing a new WebAudio method called "start" to deprecating and removing the "noteGrainOn" method it renamed in the span of 12 months. Any sites using the original spec stopped working, some within a year of being released with the latest and greatest spec, one of which was Google's "WebAudio Playground" demonstration site. (There's a fun bug on file where that team had the browser team push back the method deprecation by a release so that they could fix that one website).
Google released Polymer in 2015 or so. Apps written using the latest version of that in late 2015 stopped working at some point in 2017 on Google Chrome.
Web browsers stopped being even a little bit backwards compatible around 10 years ago.
(Did a single site with it, worked for a year and then for 6 months only in Safari/Firefox, and then we ported it to sit atop another Google project... ¯\_(ツ)_/¯ )
You are right, of course: if you use new proposals that have not yet been standardised, you are at risk of them breaking in the future. (I've been bitten by this at a previous employer that insisted on using Polymer as well. Don't get me started on that.)
When you stick to standardised features with multiple implementations, though, I think in the vast majority of cases you would've been fine. (This is also one reason why I was against using Polymer.)
(Obviously this does not cover all Electron features, which is why I don't consider browsers to be a replacement for Electron, at this point. I'm merely stating that it's very much possible to target browsers without having to concern yourself much with their rapid pace of development.)
Unless one only cares about fossilized UNIX and Win32.
They change, but more slowly with better backward compatibility, but more important is when they change. In a corporate environment they might update the OS once a decade and on a schedule you control which is much more manageable than relying on a layer that updates itself every 6 weeks.
> Unless one only cares about fossilized UNIX and Win32.
You say that like stability is a bad thing.
Same applies to PWAs on ChromeOS (naturally given its nature), and Google is ramping up the same capabilities on Android with their initial release of TWA.
Yep, there are a few OSes currently left out, it is up to their masters to follow Microsoft and Google's footsteps.
It is only a matter of time until all desktop and mobile OSes that matter fully support it.
Also there is Qt, wxWidgets, JavaFX, ....
It'd be a sort of cross-platform Google Play Services.
edit: I realize now this is a joke thread... whoosh.
So when is Electron going to support the same features?
Also Android J++ does AOT compilation, as sidenote.
Now that OpenJDK is starting to offer AOT compilation for free, maybe there will be more adoption among FOSS crowd.
For instance, if my app depends on Electron 5.x, then it will only run if 5.x is installed. If other apps require 4.x, then a system needs to be in place to allow both 4.x and 5.x to be installed on the system simultaneously.
This way if—say—you have five Electron apps running on your system, three of them require Electron 5.x, and two of them require Electron 4.x, then you only need two versions of Electron installed to your system instead of today's approach of bundling one with each app.
Honestly not sure why Java doesn't work this way too. I think .NET does, doesn't it?
You end-up having to keep multiple runtimes and hoping they don't step on each-other's toes...
After a while you're still downloading 200+MB runtimes to run your particular app that still requires Runtime 5.05 and hasn't been updated to work with Runtime 6.12 that is required for newer updates of an app that used to work with Runtime 5.84...
Maybe a better idea would be to make Electron's install specific to each app and only include the bits you actually need so it's a 30MB bundle instead?
Just wondering if calling for a runtime isn't going to make things worse in the long run. It 's already often a pain to install an app that target any framework version in particular that may not be installed or may conflict on some user's target machines. Sometimes it's unavoidable, but I'm wondering if this is really the case here.
Which isn't really PWA because Electron do offer slightly more capabilities.
The users have to track the releases of electron themselves and keep on top of security bugs.
While it may be easier for devs to bundle, it's a major loss and a huge risk to users. Probably much more with non-major apps, where the developer may not care all that much to update bundled runtimes, when he's not adding features to the app itself.
Did you check none of the apps you use are vulnerable to this?[1] Now until every single developer and every single electron app in existence updates their runtimes, they'll be potentially vulnerable to this major privilege escalation bug.
You still need to bundle a copy of NodeJS with your app if you're not targeting developers, but that's much smaller.
Of course, this still has many of the issues that a shared copy of Electron will have - you need to make sure that your app stays compatible as Chrome is updated. The HTML/JS side is typically not an issue, but the devtools protocol that you need for this does get breaking changes now and then.
First comment: Hey is X on the roadmap?
macOS is experimenting with UIKit, so we'll see how that plays out. But I wouldn't be completely surprised a few years from now if they announced a Safari-based competitor to Electron that has obvious benefits, like battery life and GPU acceleration everywhere.
The biggest risk, however are those modules that are compiled to the platform and node version in question. There are now some abstractions that make this easier, but it's still far from perfect. And depending on the application there are more or fewer risks of this being a problem.
As it stands SQLite is specifically one of the most used compiled modules alone and is used in many projects.
If you are just using Electron "off the shelf" to host your web app it's generally `npm install` the updated binary, test, and deploy.
Sometimes an Electron-only API changes, but that's pretty rare and most of them aren't "mission critical" if they break. That's always documented well in the release notes and the API and Electron for the most part seems to follow a "deprecate for a version ahead" pattern that you should have plenty of warning.
If you are using native libraries is where things get complicated. At that point you are likely building your own Electron binary, and need to find updated versions of your libraries that support the upgrade NodeJS and/or Chromium versions. Most of that is the same documentation whether or not Electron was in the project, check the related documentation for the appropriate NodeJS and/or Chromium versions, rebuild as needed using the usual tools.
> In the last half of 2018, our top priority was releasing faster and catching up closer to Chromium. We succeeded by sticking to a predetermined timeline. Electron 3.0.0 and 4.0.0 were released in a 2-3 month timeline for each release. We are optimistic about continuing that pace in releasing 5.0.0 and beyond. With a major Electron release approximately every quarter, we're now keeping pace with Chromium's release cadence. Getting ahead of Chromium stable release is always a goal for us and we are taking steps towards that.
Why it needs so much resources just to send a few bytes of text?..
Waste. It doesn't cost them much[0], and they don't seem to care on an ethical level about it either, and wastefulness allows them to achieve their business goals faster. Until there's a business pressure for it, things won't improve, and I have no idea what such pressure could be.
--
[0] - How many of their users are captive anyway? I didn't choose to use Slack, some non-tech folks at the company I'm working with chose it. Elsewhere, someone in the community of a technology I use also chose Slack. So now I'm forced to use them in both cases.
> Sblack works exactly like a browser with small tweaks. We inject the dark mode style at the end of the Slack’s html, and that’s it
I bet it's just embedding a WebView, and the app is small because it uses the system's WebKit2
It just highlights why donation is a terrible business model for open-source.
Come up with a better support model and people will pay.
Slack co-maintains Electron together with GitHub, employing multiple core maintainers full-time, contracting those who can't join us full-time. We've also just hosted (and paid for) the first Electron conference. We're also maintaining a fairly large number of electron-userland modules.
tl;dr: That page might be misleading, we're investing heavily in Electron.
1. Electron is open source, sciter is free as in beer only. 2. Electron implements the exact same javascript as the web, sciter implements its own js-like language. Harder to find developers with experience, and harder move your app from sciter to some other engine down the line. 3. Electron implements the exact same html/css as the web, sciter implements html/css from a few years back plus its own proprietary bolt-ons. Same problems as #2.