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.
This sounds like a mixture of:
"Look, web apps are bad, ok. Really. You cannot just dump native app support, it's insane."
Coupled with
"Yes It is! Only the BLESSED, TRUE mac users, The TRUE hipsters from before Mac became popular, can TRULY appreciate how truly horrible it truly is!"
This is of course, absurd. There is also the Unix greybeards. Remember "The Unix Way" ? "Do one thing, one thing only, and do it right." ?? (You know, the REASON why SystemD is reviled?)
No, that cannot be, because it does not worship at the throne of apple, or some such shit.
The summary is a terrible word soup.
"I think the Mac will prove more resilient than Windows, because the Mac is the platform that attracts people who care."
Ha.
Hahah.
Aaaaahahha.
HAHAHAHAHAHAHAHAH
What kind of hellish world have millenials created where everything is written in Javascript? Could anyone have imagined such a dark turn in the 90s?
I've never used one, and I don't think I'm going to. I don't know anyone who has used one either. I think this technology is way less popular than articles like this make it seem.
It's inevitable. As the open runtime of the web becomes better and better, it will take over everything else. MSIE, Real video, ActiveX, Flash, they all died because of this unstoppable train. And everything else will die too, including all native apps. Native apps used to have a performance edge, but that pretty much only remains for hard realtime stuff and it's just a matter of time before this web runtime takes that over too. It's a pity we ended up with JavaScript, but it's still a million times better than writing your app twice only to have it run on a fraction of platforms. The last major hurdle we need to take, are the platform specific app stores that still provide their owners with a reason to keep favoring their platform specific solutions over a more open approach, but eventually those will die too. It's inevitable.
0x or or snor perron?!
You mean like the fucking idiots who don't put the cancel button on the left like they should?
#DeleteFacebook
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.
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.
I don't know what Electron is, and thanks to this rambling "article" I still don't know.
Good job, idiots. Nothing like providing depth and detail on something that clearly some super-nerd-drama. Oh wait, its Slashdot, who am I kidding.
99% of development are put in web technologies, of course they are going to be better than native at some point. I think they have already taken over. Native programs often feels like clunky squared dinosaurs when compared. I have used Macs for the last five years and have no emotional attachment to the platform, web apps works here too.
As a side note, Microsoft already uses Electron and have for some time, Teams for example.
FIFY
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
Native apps used to have a performance edge, but that pretty much only remains for hard realtime stuff
Or for physically smaller, battery-powered devices where 8 GB of RAM is too physically large, too power-hungry, or too expensive, particularly tablet and compact laptop computers. If your device has 2 GB of RAM, then spending 365 MB per app on something like Skype or Discord (both built with Electron) will cause your device to lose performance to swap pressure fairly quickly, especially if it's running on the same device as a web browser whose user is using multiple tabs for page parking. Even 4 GB will cause more things to end up evicted from disk cache.
You cannot do hard real time over the Internet. It's not about performance, it's about IPv4 offering no guarantees.
You can't replace native applications with web apps because you don't have the bandwidth (you need 50 gigabits per second to emulate native, the US is downgrading its broadband to 1 megabit per second - 50,000x too slow). Unless the Internet switches to Infiniband, you won't get the performance.
That's not to say it won't happen. Java applications are obnoxiously slow compared to native but are run anyway.
And that is the point you miss. Its not about whether it's any good, it's about whether that's what is forced on users.
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
Microsoft had plenty of reasons to abandon their useless garbage web browser. They didn't even ship the thing with their own operating systems! (Windows Server, Windows IoT) They knew it was fundamentally flawed. Nobody wanted to use it, so there is no reason for them to waste development time on it. It's a bit of a blow to the community, because it means we are down to 2 real browsers, so the Chrome/Google monoculture will expand. That's bad for the development community.
Electron is yet another framework on a long history of frameworks that use JavaScript+Node as the basis of desktop development. Microsoft has no reason to fear Electron any more than any other such tool.
I do agree with Gruber though, in that people just don't care about native look-and-feel any longer. It kinda pisses me off. Back in the 1990s, there was this utopian idea that all apps would use native controls and native look-and-feel. That era died, and now every app has a different look-and-feel and different behaviors. Instead, we are now in the world we feared where sometimes check boxes act like radio buttons, and sometimes you click OK instead of Cancel because it isn't consistent if they are on the left or the right.
Why don't we just send all of our money to google and stop thinking about how computers work, as long as we get a free phone from the government later on?
As much as IE has bothered me over the years, M$ caving in to Google in this browser business bothers me even more.
Is Microsoft finally dying?
Only Luddites drive their car down to the Electric Avenue in Montgomery Ward's to purchase a shrink-wrapped box with a 'program' that you install which actually works, not the hippest appyest App Apper who taps on their smart phone, tablet, or $5000+ Apple to run some shitty "App."
Not only did they just buy Github (who created and maintain Electron) but they also use it for a number of their own apps.
The OS vendors/distributors themselves aren't providing coherent, unified UI language
Well, there are GNOME Human Interface Guidelines. But why don't more GTK+ apps follow them?
Why that fucking butterfly keyboard was ever approved
I thought IBM invented the TrackWrite butterfly keyboard for the ThinkPad as a way to fit a non-cramped keyboard on a subnotebook.
PC booter software includes an operating system on the same floppy as the program. Many early IBM PC applications and most Apple II applications shipped as a booter, in part because it made copy authentication more robust. The same is true of games for PlayStation, PlayStation 2, the original Xbox, and all Nintendo game consoles prior to Wii U, which include any needed "library" or "operating system" code statically linked into the application.
Distributing games as PC booters solved that by disallowing concurrent applications in the first place. Nowadays, video game publishers would prefer to disallow concurrent applications for two reasons: no third-party applications taking CPU, GPU, and RAM resources from the game engine, and no third-party utilities for running illegal copies or cheating in online play. Just look at any console-only game, for instance.
... is what happens if people insist on doing their own platform and inflating the development process for it with loads of ceremony. Electron is the extension of this concept. And for most scenarios it makes perfect sense, as it offers useful solutions that run everywhere without too much hassle for the developer.
It should have native platformers thinking twice about their toolchain when the guy of developing desktop apps with awkward web technologies actually less of a hassle than using their native tools.
My 2 cents.
We suffer more in our imagination than in reality. - Seneca
I've never seen an app that I think should pretend to be online when it isn't.
One example is navigation applications. You might want to have, say, Google Maps download a bunch of maps of your home town or a particular city that you are visiting. This way you don't use any of your monthly cellular data transfer allowance on mapping, or in my case, so that you don't have to buy any cellular data transfer allowance at all, instead relying on your wired home broadband connection. Other examples include note taking, word processing (Google Docs), web-based email client, forums, and the like, so that you can download something, compose changes or replies, and schedule them to be sent next time you connect.
And my phone's wireless hotspot does not cost extra to use.
To what country are you referring? Google (the developer of Chromium), Microsoft (parent company of the developer of Electron), and Slashdot (host of the forum on which we are discussing this) are all headquartered in the United States, where use of your phone's wireless hotspot often costs more than a basic cellular plan. (Or at least it did last time I looked, and on prepaid accounts as opposed to multline postpaid accounts.) If you enable the hotspot on your phone without first paying for an upgrade to a plan including hotspot use, then all DNS connections will be intercepted, all cleartext HTTP connections will redirect to a captive portal to log in and authorize payment for a plan upgrade, and all connections other than those will fail. It gets even more expensive when you're roaming internationally.
People are coming up with all sorts of contorted logic about the switch when there is an easy answer - it costs a lot of money to write and maintain a browser engine. So why not re-use the open source one that has the widest usage at a fraction of the cost.
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.
Correction - Mac is the platform of people who care how the box looks while knowing absolutely nothing about the internals. So they pay 3X what it's worth.
Nonsense. A native application is far superior. Faster, cleaner, more compatible with your other apps.
Javascript/browser apps are for amateurs. Yes, there are a lot of them. Even so.
I've fallen off your lawn, and I can't get up.
how much computing performance we gain over the years, worry not, for most of it will be squandered on ridiculous development processes and frameworks in the name of reducing headcounts and making it quicker to develop software.
You're a moron who doesn't know the first thing about what we're talking about. These apps don't require the Internet. The browser is just used as an HTML/CSS rendering engine with a JavaScript host for programming. The Internet or IPv4 or anything else network related is irrelevant.
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...
Anything that might kill Windows gets my attention.
Table-ized A.I.
Java was going to destroy the native desktop apps too. One portable binary that runs on all platforms with JVM. It was going to take over the desktop world.
Memory hungry programs without a proper integration with the desktop, written in a toy language.
It's '90s all over again, and some people living in their tiny little bubble think they're going to change the world.
Uh...what part of "-style chat interface" did you not get?
The fact that people like Drew DeVault and Benjamin Pollack have written blog posts promoting IRC over Slack (and Skype and Discord). On the other hand, Dave Cheney thinks all chat platforms are inferior to forums and mailing lists.
Remember that Skype supported chat, voice, and offline messaging even in the mid-2000s.
Correct. It no longer does, as Microsoft switched off the protocol that the older software used. Part of the reason that the old software became impractical is that so many of its functions relied on peer-to-peer connections between participants in a conversation rather than a server. Peer-to-peer fails in two cases: A. when both sides are behind NAT that they cannot control, which will only become more common with the widespread adoption of carrier-grade NAT by ISPs; and B. when one or more of the receivers are offline. In addition, peer-to-peer connection exposes a participant's IP address, which makes a a participant's network connection more vulnerable to traffic-flooding DoS attacks. I'd be interested to see what the free software community creates to replace it. And back then, people didn't expect to use Skype through native mobile applications. Supporting three desktop platforms (Windows, macOS, X11/Linux) with native applications may be practical, but add iOS and Android and you may end up having to contract the desktop effort to one platform, namely Electron.
Google has failed me. Plenty of references, but no definitions in the first pages.
What a profoundly stupid thing to claim. Most people haven't been born yet. (at least, I hope not.) This jerk is confused between people who have already made the decision presumptively after careful consideration (riiiiight....) about which environment (OS/culture) to use (I'm thinking few 15 year olds are able to make a well-informed choice) and the vast majority of humanity. What a self-righteous prick.
> It is great to have a single cross-platform standard.
No, it's not.
> But really, JavaScript? We could have done far better than that.
Like... VB++?
HTML is optimized for the specific purpose of laying out text and pictures on a display. Not much logic is needed in changing the display of web pages. The JVM is better suited for general purpose logic. As for server side logic, I think a new language (not javascript), should be designed specifically for the server side, which interacts with client side javascript.
So you ship a web browser, and a client, and application logic and call it an "app"?
Yes, but it's not as performant as you make it sound...
"There is more worth loving than we have strength to love." - Brian Jay Stanley
It still boggles my mind that tens of millions of transistors can be bought for less than a Big Mac. Local hosting of Javascript and web browser can be allow for an unpopular application to be written once, and deployed over the internet, and as a local application on Linux, Windows, Macs, and other platforms. A big processor, lots of RAM, and a good internet connection is usable by many different programs, not just one, unpopular, important program.
Nope. "App" is just short for "application," always has been.
"The goal was to make a very modern OS that runs Mac apps."
– Steve Jobs, MacWorld Expo, 1998
https://www.youtube.com/watch?v=3Ov8UP3S0pY#t=39m47s
I'm an Emacs guy. It was the editor most likely to handle large files when everything else failed. Until VS Code - an electron/atom based editor, built by MS (yeah, really) came along. It's my main editor on Manjaro i3 Linux today. I repeat: An MS-lead open source project today provides my main editing tool.
Search and replace is faster than Emacs over large files and it's way more usable with truckloads of features and extensions that don't need a CS degree to assemble.
Yes, back on my iBook G4 VSCode wouldn't even find enough memory to launch and emacs rules for files 30MB and larger. But today is different. When I'm not programming, I'm using a Chromebook. A friggin' Browser with a keyboard and touchscreen. And it's *more* open than Apple or MS, because - you guessed it - it's built on toy technologies that nobody control on their own.
You can rant all you want about toy languages and toy technologies, but they usually win. Precisely *because* no one takes them seriously. Back in the 80ies IBM introduced a toy computer because Homecomputing was becoming a thing. They gave the specs away for free because "we don't sell toys, we sell real computers. Go ahead and copy it if you want, we don't care."
Today the toy architecture x86 rules the planet.
It's the exact same with JavaScript.
Yeah, real men use C, we get it. JS is a toy language for making little effects on website. You're absolutely right.
But JS won the PL wars. True thing. That's a cold hard fact you will have to get over.
Every new PL that comes along better have a JS transpiler and offer some neat web-solutions or it will have a tough time gaining mainstream attention.
Welcome to 2019 my friend.
We suffer more in our imagination than in reality. - Seneca
How many levels of abstraction do we need? We have a browser almost resembling an OS which sits on top of the native OS communicating with the middle tier which also has OS-level features and characteristics and also communicates with the native OS. All this to produce apps that simple enough to have in the past occupied less than 1MB of ram and required a few Mhz to operate. Now each app requires GB and multi-core cpus. Have we all gone mad in the name of developer fungibility and reusable frameworks?
LOL... Node.js being used for desktop app development is a bigger scourge than Chromium being used for desktop apps.
Most standalone applications for people that care are computer games. Most of those applications run on windows unfortunately. Mac is 'the platform that attracts people who are' if you mean caring about their own farts.
(you need 50 gigabits per second to emulate native ... that is all in the 1 - 2 gigabits range.
That is bollocks.
There are services that let you play games from other platforms by basically video streaming the UI to you
Java applications are obnoxiously slow compared to native but are run anyway. ... you must live under a rock.
That is not true since 1995
Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
Hipchat supports all of those capabilities and you can serve hundreds of users from a single server instance that uses less RAM than the client side of Slack.
As of February 15, 2019, the client side of HipChat will use exactly the same amount of RAM as the client side of Slack because of Atlassian's deal with Slack to discontinue HipChat, including licenses for on-premises instances, and migrate all HipChat users to Slack. The server side of HipChat will no longer be available to the public at all, as Slack will host all instances on servers operated by Slack. On-premises users who cannot migrate to Slack will have to export their data and import it to some unspecified competing on-premises chat platform. (Source: "Slack Migration Frequently Asked Questions")
And the decline of native apps
JavaFX is turning out to be a really nice solution now with the module system. You can build cross platform applications with native installers with much a smaller JVM. And you can use real languages like Java, Scala, Kotin etc...
Faster: because native apps can be faster. Fewer abstractions and frameworks can mean leaner, faster code.
Cleaner: because native apps can be much more compact and less dependent upon numerous frameworks.
More compatible between apps: because native apps have available to them more means to communicate with each other. Files, sockets, pipes, signals, shared memory, scripting, clipboard, etc.
That's not required to be true for native apps, and when it is required to be true, such as with a webapp, it's not a feature. It's a limitation.
I've fallen off your lawn, and I can't get up.
Qt can cover Windows, macOS, X11/Linux, and Android, but what on iOS? I'm told Apple has deliberately made its App Store terms incompatible with the LGPL, the free software license under which Qt is distributed. Would you recommend a commercial Qt license ($500 per developer per year) over making a web application, particularly for smaller shops whose developers aren't working on the iOS version full time?
The question was whether you could do hard real time over the Internet. The answer is no.
Ever worked with Internet 2? Thought not. Did you read my reply or just post because you're a whining bastard who posts hatred at random? Actually, don't bother answering. Actually, no point in me saying that, since you're clearly not up to reading yet.
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
Games are not hard real time. Wake me up when you learn your terms.
Elite: Dangerous streams, but it suffers badly from lag. Not even remotely real time.
LibreOffice is crap in terms of performance. I use the latest Java and it is SLOW. I also hand-turn assembly, so know probably a bit more about REAL performance. Where else you fake performance is your business.
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
My workplace gave me JetBrains' Java-based "WebStorm" for me to do my HTML editing. I don't know for sure if Java is responsible for the slowness, but I do know I can't afford to wait 45 seconds for it to launch every time I need to edit a 1k HTML file.
I begged them to let me install Notepad++.
Typical MS move. The Edge announcement last week + this is casting the github acquisition in a new light I hadn't considered before...
Liked VS Code .exe applications. Too slow, too clunky, too much ram used, too wasteful of battery life.
Hated the other Electron or html/js + browser control wrapped in a windows
Went from a desktop version of an application to an Electron based replacement - it doubled the memory and ran 50% slower.
I pushed it to our IT steering committee and now we don't buy or implement any desktop software which is JS/html wrapped in an .exe file. Too costly, only saves the vendor time and money.
Of note Microsoft has Azure Data Manager (yuck JS/html in an .exe) which is supposed to replace native win32 SQL Server Management Studio in the future.
I don't see any commodity trading firms going to JS/html/node in a .exe anytime soon, nor would I want my bank to go there.
You answered to the wrong post ...
Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.