Slashdot Mirror
Electron and the Decline of Native Apps (daringfireball.net)
SwiftOnSecurity, regarding Microsoft's switch to Chromium as Windows's built-in rendering engine: This isn't about Chrome. This is about ElectronJS. Microsoft thinks EdgeHTML cannot get to drop-in feature-parity with Chromium to replace it in Electron apps, whose duplication is becoming a significant performance drain. They want to single-instance Electron with their own fork. Electron is a cancer murdering both macOS and Windows as it proliferates. Microsoft must offer a drop-in version with native optimizations to improve performance and resource utilization. This is the end of desktop applications. There's nowhere but JavaScript.
John Gruber of DaringFireball: I don't share the depth of their pessimism regarding native apps, but Electron is without question a scourge. I think the Mac will prove more resilient than Windows, because the Mac is the platform that attracts people who care. But I worry. In some ways, the worst thing that ever happened to the Mac is that it got so much more popular a decade ago. In theory, that should have been nothing but good news for the platform -- more users means more attention from developers. The more Mac users there are, the more Mac apps we should see.
The problem is, the users who really care about good native apps -- users who know HIG violations when they see them, who care about performance, who care about Mac apps being right -- were mostly already on the Mac. A lot of newer Mac users either don't know or don't care about what makes for a good Mac app.
The problem is, the users who really care about good native apps -- users who know HIG violations when they see them, who care about performance, who care about Mac apps being right -- were mostly already on the Mac. A lot of newer Mac users either don't know or don't care about what makes for a good Mac app.
Electron is an app "platform" that basically involves installing an app-private copy of Chromium, a node.js webserver, and running the application's logic mostly in Javascript between the two.
To paraphrase Churchill, Electron is the worst architecture for desktop applications, except for all the other ones that have been tried.
Chromium is Google Chrome with the few proprietary components (mostly Adobe Flash Player and video DRM) stripped out.
Node.js is Chromium's JavaScript engine repurposed as a server-side language.
Electron, an application framework that Microsoft acquired when it bought GitHub, is a way to build a copy of Chromium hardcoded to one website, possibly bundled with Node.js. This allows a developer to ship a web application that can be installed as a desktop application.
Electron shares many disadvantages with the web platform. But one significant advantage of Electron is that you're less likely to get "Sorry! This application is not yet available for your platform. Subscribe to our mailing list to be the first to know when the crowdfunding campaign to port this application to your platform begins."
The two alleged problems that Electron solves are 1. ability to hire from the web application programmer labor pool, and 2. less work needed to ship an application across four desktop/laptop platforms (Windows, macOS, X11/Linux, and Chrome OS).
Discord (desktop version), Slack (desktop version), Skype (desktop version), and Visual Studio Code are all made with Electron. But the differences between Discord (desktop version) and Discordapp.com are quite minor: the option to let others know what game you are playing at the moment, system-wide push-to-talk in voice channels, and video chat capability.
Real greybeards call them "programs", because believe it or not everything that runs on a computer is a "program". I know, hard to believe, but computers still work the same way they did since the 1950's.
I'll give a simple explanation, as best I understand it:
In order to make it easier to build applications that work on Windows, Mac, and Linux without completely rebuilding it for each platform, a lot of developers have resorted to basically building web applications, and then making them available in a specialized web browser called "Electron". Electron is basically a stripped down browser that allows the web application to behave more like a native application. So you might care at least a little bit, since it's possible you're already some of these Electron applications and not know it.
So that's kind of a good thing, that developers can more easily make cross-platform applications. The problem is, if each application is running its own web browser, then you end up installing and running a bunch of web browsers simultaneously. That ends up being a bigger drain on system resources than if they were native apps, or if you just had them all running on the same web browser.
Microsoft wants to fix that problem, for Windows at least, by working on how all these Electron apps integrate with the operating system's built-in browser, so that they can manage those resources better. There's a big problem with the idea: Electron doesn't integrate with their own built-in browser. Electron uses Google Chrome, and Microsoft can't easily make the apps use their own browser instead. So instead of trying to make these Chrome-based apps use Edge, they're rewriting Edge to be based on Chrome. Once that's done, they can work on getting the electron apps to use their own built-in browser, and then they can work on that browser to improve performance of those apps.
Back in OS X 10.4, Apple came out with the Dashboard, which let you create applets that were written in HTML/CSS/JS. Except they didn't require you to bundle an entire fucking web browser and support library into each one. But they did that mostly by making it use the WebKit library to become the web browser, which came from KHTML. Since it's a system-common web browser, only one copy needs to be shared among the entire system. I wrote one once, and I liked the DHTML in a single web page model of programming, but had no time to dedicate to doing more.
On the other hand, it uses something like the Windows 8 mobile style applets, where you go into a special screen mode to run them, rather than letting them behave like regular apps. This sort of worked okay with its intended use as a new kind of desk accessories, but didn't go all the way to making something that behaved like a fully independent app. If it is possible, I'm not familiar with anything built that way. And of course it would surely be a Mac-only thing, because Apple so often gets a bit ahead of the rest of the world sometimes, comes up with its own way of doing something, then the rest of the world does it differently, orphaning Apple's earlier work.
#naabhaprzrag, #sverubfr-000, #agi-fcbafberq, negvpyr[pynff*=' negvpyr-ary-'] { qvfcynl: abar !vzcbegnag; }
I spent many years building cross-platform applications using this new-fangled thing called Java.
Then, someone decided it would be great to build web applications in Java. Oh, and use XML as the communications protocol between server and clients. Oh, and transfer not just data, but objects over-the-wire. Then Spring came along to make things "simpler". Like hell.
Node.js, JavaScript (TypeScript if you prefer) and now Electron are all bringing us back to cross-platform nirvana, only this time using the browser/server interface properly, without a bunch of ill-fitting preconceptions carried over from native desktop applications.
Firstly, cross-platform Java GUI apps never really took off (and I say that as someone who paid his rent in 2002 writing one). The Java as the web server/app took off rather quickly and the Java GUI's always looked terrible. Spring and Hibernate did improve things on the server but they should have shipped a default setup so things like transactions got intercepted and handled properly OOB and that never happened. XML was unnecessary but getting network ops to be happy with 20 custom network protocols probably wasn't a good idea either. But it wasn't that hard to get up and running and the web was still very much a moving target in those days. And those were also the days of IE6 so there was that making life hell.
However, moving Javascript to the server is the stupidest idea ever to come out of a human's mouth. I've never seen a node.js app that wasn't total shit and I've never seen someone who wrote a node.js app realize how shitty they app was while the ops get paged for the 74th time this week because his app fell over again.
Electron on the other hand is about client side caching in web apps. This is probably a terrible idea given Google's track record but it does make some mobile interactions easier. And there are better tools for the graphic designers to use to design the GUI when you are doing a web app. But this isn't about the user. This is about saving some hipster JS programmer some actual programming at the expense of your phone's battery life. Sadly this is exactly what Java was supposed to be good at. Unfortunately Java didn't fix its GUI toolkits until far too late (and many say they still haven't). Even C++ has a better GUI builder in Qt than Java has which is pretty sad.
"Those that start by burning books, will end by burning men."
why does Microsoft care enough about the desktop experience to bother doing this?
Well there are a lot of complicated issues in play. Again, to try to keep it simple:
Their vendor lock-in on the desktop is not what it once was, and you see them moving increasingly into web applications and services, open source, and cross-platform projects. They're foreseeing that, even if people continue to use their operating systems, they won't be able to rely on vendor lock-in to force people onto the OS.
They're already knee-deep in this "Electron" stuff. They already have applications on Electron (e.g. Skype, Teams, Visual Studio Code), and I think their "Modern" applications work in a similar way. I would bet that in the coming years, you'll see more and more applications move to being web applications in a wrapper. We may even see them eventually get their Office web applications in this form as a replacement for the existing native apps. That would remove the need for them to duplicate their efforts in making a separate Mac version, and they could even support Linux without extra effort.
Even if they weren't doing this themselves, you have a bunch of developers doing it, and it's going to continue to be a thing whether Microsoft likes it or not. If they want to stay relevant and keep people on their platform, they need to try to be the best platform to run these kinds of applications on.
Aside from all that, it really makes more sense at this point for Microsoft to use Chromium instead of continuing to build their own browser engines. They lost the browser wars. For most web developers, Chrome is their target browser. Safari and Chrome, and therefore pretty much all mobile browsers, are based off of the same code base. They can spend a lot of time and money trying to build something that works just like Chrome, or they can just use the existing open source code.