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.
I feel like I just walked in on a conversation between two people about a topic I care nothing about. Should I care, or maybe do I already care? Possibly, but I have no idea what they're talking about to know.
Better known as 318230.
No, some time around 10.3 Apple forgot what made for a good Mac app. They went for skeuomorphism where it wasn't useful, per-window brushed metal appearance, non-standard UI widgets all over the place, etc. They deprecated actual useful UI features like drawers, and violated their own guidelines left, right and centre. Then they decided they needed to remove "Save As..." at some point, only to bring it back later with different behaviour (making it save at the old location before also saving at the new location).
Sure I dislike apps that don't feel right. I never liked how Qt applications always felt not-quite-native on OSX, and the same with Firefox where menus don't quite feel right because they aren't native. I dislike the situation Linux inherited from UNIX where every UI toolkit has a different look-and-feel so it varies from app to app. Microsoft is a big mess, too. It's probably best demonstrated with settings, where you have classic control panels that open in their own windows and behave like regular Win32 apps, sort of web-like control panels that open in the "All Control Panels" window and can be navigated with back/forward buttons, MMC snapins inherited from WinNT and things that mimic that approach, and then the flat-look touch-optimised Metro-style settings. Nothing's unified at all.
The OS vendors/distributors themselves aren't providing coherent, unified UI language, so how do you expect third-party app developers do do so? Everyone's bundling frameworks with apps now since Apple made it the trendy thing to do (just include the frameworks inside the app bundle), Microsoft made it easy (use WinSxS so you can have per-app versions of DLLs), and the Linux distros jumped on the bandwagon (Flatpak? Snap). Electron may be a particularly heavy-weight framework, but it's definitely not the only one that gets bundled with applications. But this has lead to a vicious cycle where apps bundle frameworks to avoid incompatibilities, so the frameworks are emboldened to make incompatible changes on minor releases, necessitating the bundling. It isn't an option to use a system-wide installation of a lot of frameworks, because they don't maintain compatibility.
Even if MS manages to make a single system-wide instance of Chromium for running Electron apps, it's not going to solve bloat issues with duplication of the JavaScript frameworks used by the apps themselves. You can't use a single instance of them because of incompatibility between versions, and the fact that JavaScript lets you inject members into any object. You'll still have the bloat of loading, JIT-compiling and caching the JavaScript frameworks for every app.
The trouble is, we've reinvented Java but it's worse in almost every way. We're running JIT-compiled code from untrusted sources on a sprawling runtime with vulnerabilities discovered regularly. But now every app also pulls in a huge pile of dependencies, bloating it further, and greatly increasing the number of third parties you need to trust when you run the code. I don't see how this is any better.
Oh, so it sounds like Java apps again.
No. This is much worse than Java.
Java was designed by professionals, like James Gosling, who knew what they were doing. In theory, I was a great solution. It was only when corporations started subverting the ideals and trying to lock in incompatibility that the dream died.
"JavaScript on the desktop" is completely idiotic, even in theory. It is an absolutely horrible thing to standardize on.
I'm not an Apple user anymore, but I completely feel that Electron is the software engineering equivalent of flinging poo.
Let's just look at the minimum requirements to run Atom, an Electron-based text editor with IDE extensions
Processor - 1.8 GHz or higher Pentium 4 (or equivalent)
Memory - 2 GB RAM (minimum 1 GB dedicated to Atom, Molecule node, or Cloud Molecule)
Hard disk - 50 MB for run-time and configuration, 10 GB for data archiving
Are you freaking kidding me? For a text editor? I don't care how much bling it has, that's inexcusable. All this engineering we've done, all the rare earths we've mined, all the research on battery life has to go down the toilet because we're sending Javascript developers to do a systems programmer's job? My phone's battery has to go to shit for Slack, and my laptop has to overheat and stay on a power cord for Atom?
That's freaking irresponsible. There's little these apps do that vim and emacs and IRC haven't done for decades for a tiny percentage of these requirements.
Cross-platform development has been done way better than this already. but the training wheel languages have got to go.
Slack, a simple IRC style chat interface
To what extent does IRC out of the box support any of these?
1. Storage and forwarding of chat history, including messages sent to the channel while your device was offline. If the answer is a bouncer, which IRC server comes with a bouncer, and which IRC clients come with UI to integrate with said bouncer?
2. Storage and forwarding of text, image, and other file attachments. If the answer is DCC, then DCC fails behind carrier-grade network address translation (CGNAT), in which an ISP won't let an end user forward a port to his machine. It also fails when the sender and receivers aren't online at the same time.
3. Server-side link preview bot, so that several dozen clients aren't all hitting the site (and exposing their IP addresses) to fetch a client-side link preview.
4. Voice chat.
5. Sharing membership and permissions for all of the above across a set of related channels.
A number of the website that I have used for a long time seem to recently have taken a HUGE turn for the worse when they unveiled new "app-ified" look and feel and operational flows. These are not widely-used sites, things like the tee-time scheduler at my favorite golf course and the portal site my employers contract with for unified benefits access.
These sites used to be pretty well done, and even as a professional software developer (albeit one who mostly does radar signal processor development) I had few complaints. But over the last year or so, all these sites trashed their old implementations for new ones that look like they've been slapped together by tweens on crack who's only test platform is an iPhone. It may look fine on a phone to have 20mm by 20mm buttons to touch, but those huge buttons mean nothing to my desktop. Having to run through 15 different "next" screens because you can only fit just so many 20mm x 20mm buttons on a phone screen and still present any meaningful information or functions is NOT an improvement when I've got three 27-inch monitors hooked to my desktop.
And it's pretty clear none of the developers have actually USED these appy-apps, even on their phones because they just freaking don't work. For example, the legacy golf course website let you setup "buddy lists" so if you were reserving a foursome (or 2), you could just click 3 or 7 buddies from the list and bam you're done. The new appy-app preserved the buddy list, but it takes two clicks to access, and you can select one and only one buddy per access...each time to click a buddy he is added, but you're also dropped immediately back to the top menu and and you have to continue and make those multiple click for each person. If any of them had ever used the app, they'd realize immediately that "hmm, maybe we can allow multiple selections here before dropping back"...but they didn't have any more room for yet another 20mm x 20mm button...