> What are the remaining APIs that people need in Electron that are not available in the web browser? And what's the timeline to getting those in the browser to deprecate Electron?
I get what you're saying but to me, even if I could do literally everything that node does inside the browser, that STILL would not deprecate electron for me.
It's not lack of functionality in the browser that's a problem for me. It's mutability of the browser.
With electron, I get to use ONE version of javascript, ONE implementation of the DOM, ONE implementation of CSS. Period.
I do not give a single hoot about that ancient corporate version of IE you have to use at work. About how this looks in safari, versus edge versus, opera, versus whatever.
It simply doesn't matter anymore.
no more shims, and I can dump about half of the frameworks and stuff from my code because of it.
If I get an app going that everyone likes and I actually want it on the web, THEN I can go and add all the cruft I'll need to make it work out there in the wild.
You got a great point. And don't forget that Electron is not a web shell, it can replace native apps. Look at VSCode! It's not just about Electron vs Browser but there are certain cases where you don't want to go into a cloud.
You also get full control over the local file system with electron. There are plenty of system utilities... stuff like etcher.io, disk partitioners, backup software, custom FUSE-based file systems, etc., that you couldn't do purely in a web browser for security reasons, but that can benefit from the portability and sexiness of an electron-based UI (performance concerns aside).
I actually doubt there is anyone who thinks of electron in this way, in that they only use it because X feature isn't in the browser _yet_. Many electron apps could only be done natively, again for security reasons. Things like the slack desktop app don't meet that criteria, however.
I think you meant to say "This website is optimized for IE 5.0 and 640x480 please upgrade your browser". Chrome still lacks something essential that IE had back in the day: API and bug for bug stability. Moving targets just aren't as atractive.
Hmm, I have never seen a conflict like that with any of the Electron apps I use daily: VSCode, Cypress, Wire, and (blecch) Slack.
What app was that, and what platform did you see it on? (I use the apps mentioned above on macOS, Windows 10, Ubuttnu 18.04, but I guess 80% of the time I'm using macOS so I might not have noticed if its a Linux thing...)
tl;dr (as I understand it) is that a change in FreeType invalidated an assumption that programs were making in how fonts were rendered, making text look garbled. It was fixed pretty quickly in Chromium and Firefox, but it took a few months to trickle through to Electron and finally to the apps based on it. In the meantime, Linux distros had started upgrading to the new "fixed" (seemingly broken) FreeType, so the workaround was to downgrade FreeType until any affected Electron apps were updated.
I get what you're saying but to me, even if I could do literally everything that node does inside the browser, that STILL would not deprecate electron for me.
It's not lack of functionality in the browser that's a problem for me. It's mutability of the browser.
With electron, I get to use ONE version of javascript, ONE implementation of the DOM, ONE implementation of CSS. Period.
I do not give a single hoot about that ancient corporate version of IE you have to use at work. About how this looks in safari, versus edge versus, opera, versus whatever.
It simply doesn't matter anymore.
no more shims, and I can dump about half of the frameworks and stuff from my code because of it.
If I get an app going that everyone likes and I actually want it on the web, THEN I can go and add all the cruft I'll need to make it work out there in the wild.
this is a very good thing (at least for me).