Electron and the Decline of Native Apps (daringfireball.net) 328
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.
Wha?? (Score:5, Insightful)
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.
Re:Wha?? (Score:5, Insightful)
Re:Wha?? (Score:5, Informative)
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.
Re:Wha?? (Score:5, Insightful)
Re:Wha?? (Score:5, Interesting)
That explains a lot about 2018.
It says a lot about the human condition. We have a terrible habit of settling on suboptimal solutions.
It is great to have a single cross-platform standard. But really, JavaScript? We could have done far better than that.
As nerds, we have collectively failed humanity.
Re:Wha?? (Score:5, Insightful)
Re:Wha?? (Score:4, Insightful)
To me "GUI" still spells "child's toy" most of the time.
That's fine but enjoy your increasingly isolated part of the IT world. The vast majority of users use GUIs. For system level work, CLIs still rule, but that's a tiny fraction of the people.
Even if you're working on back end systems, there's likely a GUI on the front for non-techies to use the system. It's useful to be at least a little empathetic to how they use it so you don't screw them over.
Re:Wha?? (Score:4, Funny)
Shhh. He likes his rock. Don’t disturb him.
Re: (Score:3, Interesting)
You should not be knocking on JS. It's a perfectly fine, sophisticated, expressive language
JS can get things done that all other languages have failed at over multiple-decades of trying. .
As evidenced by the existence of Electron. The only existing, drop dead simple, way to make cross platform GUI apps.
Yes, you nerds failed. Younger nerds have succeeded.
Re: (Score:3)
Re:Wha?? (Score:5, Interesting)
It is great to have a single cross-platform standard. But really, JavaScript? We could have done far better than that.
As nerds, we have collectively failed humanity.
s/JavaScript/x86/g
Thing is, as an app developer, I really don't want to write a separate app for iOS, Android, macOS, Windows, and Linux. We've been trying for years to develop platforms to abstract away the GUI from the platform to solve this problem. I've seen at least a half dozen come and go. They all are great in some ways and all suck in significant other ways.
You'd think by now we'd have found a good compromise. But we haven't. We're still exploring human-computer interfaces and it seems we still keep finding good but mostly incompatible ways to interact. And about the time we figure out we don't care about fighting GUI wars any more, we'll have to worry about writing cross-platform skills for Siri, Alexa, Cortana, and Google.
Re: Wha?? (Score:3)
Because then you can avoid situations such as Windows dominating the desktop because rewriting apps is prohibitively expensive. Why do you think Microsoft fought so hard against platform-agnostic middleware?
Re: (Score:3)
Rather than building a native application, you ship a web application bundled inside of a specialized browser that makes it seem more like a native app.
There are already tons of developers doing it. It didn't start in 2018, and you may be using some applications that work that way without realizing it.
Re:Wha?? (Score:5, Insightful)
Nope, I always notice because I wonder why the app is such a resource hog, then I find out it's one of these Chromium things.
Re: Wha?? (Score:4, Interesting)
You can do it that way. But you can also just ship the JS/HTML/CSS in a bundle and rely on the client to already have the required electron libraries installed.
You know, like every other piece of software in the world. Your feeble attempt to make this somehow new and weird and bad is pathetic.
Yes, but... (Score:4, Funny)
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...
Re: (Score:3)
If your only tool is a hammer, then you just wack everything with it as hard as you can.
Re:Wha?? (Score:4, Interesting)
Electron's issue is that it can't share resources. If you are running 2 electron apps, you're basically running two wholly independent instances of Chrome and node.js, in addition to everything else.
Chrome's PWA support alleviates that because it runs the PWAs basically like a tab. The bulk of the browser engine exists in a single memory space.
So given that Microsoft was already starting down the PWA path in Edge + Windows 10 (plus Windows store), it makes me wonder why Electron is even relevant. Proper PWA support makes Electron most irrelevant - a stop-gap transitional measure to show there was an audience for that sort of thing.
Electron is still useful for apps that have to read-write from the local filesystem (editors), as a way to package relatively simple Node.js apps with a GUI attached, but one must accept the resource hogging that goes with it.
Things will change again, but often you can't know all the problems a particular architectural approach (like Electron) will have until you do it. Then use that to come up with something better.
Re: (Score:3)
I think a calculator is the most complicated software I have locally installed that doesn't regularly read or write local files. I don't really see the point of PWA or the like if they are only accessing web resources or data that are private to the app.
Re: (Score:2)
You need PWA to access cached web resources or private data while your device is not connected to the Internet.
"Then just go online!" Cellular hotspot data transfer is not free.
Re: (Score:2)
Why do I need that? I've never seen an app that I think should pretend to be online when it isn't. And my phone's wireless hotspot does not cost extra to use.
Hotspot surcharge common in the USA (Score:2)
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 li
Re: (Score:2)
PWA's can 'install' and run in a browser that doesn't look like a browser without ever requiring contact with an internet server. PWAs can read/write local files (with restrictions).
Re: (Score:3)
Yes, a PWA that is just a UI for a cloud service, with no need to save content locally other than configuration, is really just a glorified bookmark (with a nicer page for telling you there's no f'in' net).
But that doesn't mean "glorified bookmarks" aren't without some additional value. Having my apps (or "programs" if some jerk down below wants to be pedantic - it is all "applications" and has been for decades now) be treated as apps, no matter their source, is a useful thing. I see them in my apps folde
Re:Wha?? (Score:4, Informative)
Back in OS X 10.4, Apple came out with the Dashboard, [wikipedia.org] 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.
Re: (Score:2, Interesting)
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.
It doesn't sound like it meets Churchil's criteria at all. It sounds like it's building cruft no one understands on top of cruft no one understands on top of cruft no one understands, and no one is bothering to understand each of the levels, and each level already does what you think you need the other levels for.
I think you could fix the quote by removing all the words after, "applications"
Re: (Score:2)
Would "We're sorry! This application is not yet available for your platform" architecture be less bad than Electron?
Re: (Score:2)
PC booter (Score:2)
PC booter software [wikipedia.org] 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.
Re: (Score:2)
Disallowing concurrent applications (Score:2)
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.
Re: (Score:2)
Re: (Score:2)
Without downloading an entire lightweight operating system to run in a virtual machine, and without paying three teams (or doing the work of three teams) to produce three applications, how would you prefer to make your application run on three different operating systems?
Re: (Score:2)
Would "We're sorry! This application is not yet available for your platform" architecture be less bad than Electron?
In the short run, anything is better than nothing.
In the long run, no, it is a terrible mess, and it should not become a universal standard.
Electron fills a vacuum, but it still sucks.
Re: Wha?? (Score:3)
Vacuum...sucks.
Very clever.
Oh heck no (Score:2)
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.
Re:Wha?? (Score:5, Interesting)
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.
This is bad because it's the developer offloading their problems onto the user. The user can just download the 100M zip file which is a 40-line shell-script wrapper, the user can just easter-egg hunt to figure out the UI, the user can just pull the web platform into their local domain and hope for the best as far as security, etc. Since the app is based on 96 third_party dependencies, the user can also pay the price nine months later when the app stops working because while the OS developers are paying attention to not breaking their exposed APIs too badly, nobody can really maintain that amount of API surface coherently.
Basically, Electron is Flash.
Re:Wha?? (Score:5, Interesting)
No, It's a native app greybeard, and a "TRUE apple hipster!" that are upset about something,
That something being Electron, which from the sound of things, is a solution looking for a problem. (Or a problem pretending to be a solution? Hard to tell anymore.)
Basically, somebody got the bright idea that thin clients were awesome, and are trying OH so hard to drag the world back into that dark and dismal corner. The sensible native app greybeard says "Uh, that's retarded." and the "TRUE apple hipster" goes on some tirade about how Apple was supposed to save us from this horror, but True Apple HIpsters are rare now, because apple became popular, and no longer hip.
Re:Wha?? (Score:4, Informative)
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).
Re: (Score:2)
It's more about 'We want to cater to people who don't install our 'App' and for those who scream 'we want a desktop client', being able to fake providing that by shipping a bundled browser. Most don't care about supporting macOS and Linux desktops that much, and ChromeOS, well Electron doesn't matter because you are forced to deliver it as a browser extension anyway.
Re: (Score:3)
ChromeOS, well Electron doesn't matter because you are forced to deliver it as a browser extension anyway.
Electron allows your Chrome OS browser extension to share code with your Electron-powered "native" applications for Windows, macOS, and X11/Linux.
Re: (Score:3)
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 brow
Re:Wha?? (Score:4, Informative)
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.
Re: (Score:3)
It also has a sort of side-benefit for applications like Slack, where they can build their application once (as a web application) and then “port” it as a native application across all those platforms while keeping the UI and operation consistent.
If you’ve used Slack, then you know how to use Slack anywhere, on any platform. It’s all the same. It looks the same and works the same way everywhere. You don’t really even lose features when you run it in your browser. That mean
Re: (Score:3, Insightful)
TrackWrite butterfly keyboard (Score:2)
Why that fucking butterfly keyboard was ever approved
I thought IBM invented the TrackWrite butterfly keyboard for the ThinkPad [wikipedia.org] as a way to fit a non-cramped keyboard on a subnotebook.
Re:Wha?? (Score:5, Informative)
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."
Re:Wha?? (Score:4, Interesting)
Discord, Slack, Skype, and Visual Studio Code (Score:5, Informative)
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.
Re: (Score:2)
Re:Discord, Slack, Skype, and Visual Studio Code (Score:5, Interesting)
Oh, huh. That is pretty cool. I am not sure what those are, except for Skype, but sounds very good. I can feel my ironic beard growing.
What Tepples doesn't point out is that Slack, a simple IRC style chat interface, can easily consume multiple gigabytes of RAM and the more instances you have your slack client connected to, the higher the GB consumption soars. Discord also causes performance problems on my gaming PC when certain things happen. I'm not sure what event is causing it, but it temporarily hangs games while playing some sort of chime over my headset. And that's with a very high end gaming PC.
Re: (Score:3)
Re:Discord, Slack, Skype, and Visual Studio Code (Score:5, Insightful)
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.
Re: (Score:3)
"JavaScript on the desktop" is completely idiotic, even in theory. It is an absolutely horrible thing to standardize on.
JavaScrip on the desktop is 100 times better idea than JavaScrip in a web browser.
It is a full fledged programming language wit very fast interpreters. No idea what you dislike about it: probably you simply have no clue?
E.g. I love being able to script my Eclipse IDE in JavaScript and automate setting of breakpoints via a Lauerbach emulator on my ARM device, inject test code, to the Device
Why not just use IRC (Score:2, Insightful)
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 for
Re:Why not just use IRC (Score:4, Interesting)
Remember that Skype supported chat, voice, and offline messaging even in the mid-2000s. [archive.org] It was built to work even on old Windows 2000 machines and in 2005 when even cheaper new machines were shipping with 512MB standard, it required that the machine have a minimum of 128MB of RAM for Skype plus the entire OS and other running software. Meanwhile, the post you responded to complained about multiple GB of RAM used by Slack a single application that doesn't do very much more than Skype from 2005 did and offers a proprietary system only instead of a universal standard like IRC or XMPP.
Re:CGNAT, offline, IP exposure, and five platforms (Score:4, Interesting)
Microsoft centralized Skype for data siphoning and control; everything else is a side effect. [arstechnica.com] Skype has also been absolute trash ever since they did so. P2P Skype worked just fine when both people were behind NATs; it's called UDP hole punching and it is quite effective for the type of NAT that is in widespread use in homes and small businesses. [wikipedia.org] I'd hardly call Electron a native application; if anything, it's more of an elaborate emulator.
Re: (Score:2)
Nope, at least nothing people actually use. You see, writing a web page in a Javascript framework that'll go out of support in 3 months is considered acceptable by companies' oh-so-wise decision makers as 1. they'll make another project to replace the website again in a year or two, with big marketing fanfare, 2. other popular web platforms (PHP, etc) suffer from the same problem. Not so for actual programs (as opposed to "apps") where the concept of "software engineering" is not only known but teached on
Re: (Score:2)
Hundreds, probably thousands. ...
I have a dozen on my Mac
Re: (Score:3)
Slack is a 50MB download when I last checked. Slack is barely more than an IRC or Jabber client. I won't deny that people seem to love it, but it is bloated. I don't recall AIM or MSN being a 50 MB download, or even a 15 MB download.
DLL hell is a real world problem if you have a complex application that needs a lot of support libraries. A chat program that display images inline? I'd argue that's maybe not so complicated to need a lot of DLLs.
Sadly Windows is terrible at handling shared libraries. And Linux
Re: (Score:2)
Electron is the strategy for 'webapp hipsters' to displace native applications. So if you are of a mind to call people 'webapp hipsters', Electron represents the worst nightmare of letting the webapp hipsters displace native application.
Re: (Score:2)
Re:Wha?? (Score:5, Insightful)
Re: (Score:2)
Re:Wha?? (Score:5, Informative)
Re: (Score:2)
We call them "programs" not "apps". Stupid hipsters.
"Program" and "app" are not synonyms. An "app" is a GUI program that interacts with a user.
iMessage is an app. Grep, sed, and perl are not. They are all programs.
Electron is used for apps. You would not use it to make, say, a compiler.
Re:Wha?? (Score:5, Insightful)
tl;dr: all apps are programs, not all programs are apps, GEOS is better than Windows 10
Re: (Score:2)
node.js and Chromium are technically native apps. They toys that run under them are what is at play here.
Re:Wha?? (Score:5, Informative)
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 [electronjs.org] 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.
Re: (Score:2)
Re: (Score:2)
Any explanation which drops the "simple" bomb at word four sets itself up for an ankle-high bar, but that was awesome.
Left unexamined: why does Microsoft care enough about the desktop experience to bother doing this? Governments have nowhere else to go, anyway (not since Linux came down with Munich syndrome). Or is Chromebook ultimately a viable threat in the hidebound arena of the public purse? If so, that would be the real story here.
Re:Wha?? (Score:5, Informative)
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.
..Oh.. kaayyy.... (Score:2)
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
Business as usual (Score:4, Interesting)
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.
Re: (Score:2)
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..
Were you they guy who got my company to switch over to IE6 apps? You sound very familiar.
Re: (Score:3)
These things died because Microsoft lost the monopoly on the OS / platform used to access the internet, because Steve Jobs wouldn't allow those technologies on the iOS platform that wrested control away from Microsoft, and finally because of the fundamental paradigm shift that also occurred (mouse / keyboard input on a PC to touchscreen on a tiny mobile display).
Electron loses performance to swap pressure (Score:2)
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 [nngroup.com]. Even 4 GB will cau
Re: Business as unusual (Score:2)
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
Re: (Score:2)
As the open runtime of the web becomes better and better, it will take over everything else.
It will be interesting to see what's left to parse the JS
Who is it that thinks this?
I think the other AC was trying to be cute. In context, I understood zmooc's comment as meaning "the only native app left will be the web browser," while AC wanted to push it further: "once the web browser goes not native, what will interpret it?"
HIG violations (Score:4, Interesting)
You mean like the fucking idiots who don't put the cancel button on the left like they should [apple.com]?
Re: (Score:2)
Unfortunately this is one of those cases where Apple decided to be different from everyone else, so there's no winning here.
Re: (Score:2)
Who's different from whom? Which widespread applications had "OK to left of Cancel" prior to the 1984 introduction of Mac OS 1.0?
What a load of shit (Score:4, Insightful)
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.
GNOME Human Interface Guidelines (Score:2)
The OS vendors/distributors themselves aren't providing coherent, unified UI language
Well, there are GNOME Human Interface Guidelines [gnome.org]. But why don't more GTK+ apps follow them?
Re: (Score:2)
That's my point - the OS/DE people provide guidelines, then violate them all over the place themselves. They're leading by setting a very bad example.
Not a fair fight anymore (Score:2)
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.
Re: (Score:2)
Doesn't make sense to me (Score:2)
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 framewo
Re: (Score:2)
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.
Eh, I would argue that in theory that's the case, but in practice it's better.
The theory assumes that all the stakeholders stand as equals and describe perfectly specific standards in W3C and any discrepancies uncovered in implementations are reconciled in W3C and any vendor is equally likely to have to modify their behavior. In this theoretical world, Microsoft's investment in taking care of their interests focused on W3C participation and their own implementation, without following Blink development too
I can see why they want to make it better (Score:2)
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 Way as universal platform ... (Score:2)
... 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
Money (Score:4, Funny)
Apple aside... (Score:5, Insightful)
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.
Re: (Score:3)
There's little these apps do that vim and emacs and IRC haven't done for decades for a tiny percentage of these requirements.
Vim and Emacs I'll grant. But IRC out of the box doesn't do chat history, file attachments, link preview, voice chat, or channel groups (Slack "workspaces" or Discord "servers").
And yet they are winning. (Score:3)
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
Re: (Score:3)
Funny. It's the native Mac apps that always seem to take up several GiBs of memory each. Run XCode plus a web browser and you're already past the available RAM on a Linux machine where I'm running half a dozen electron apps at a time.
Try again.
I've got 3 Xcode Projects open right now and it is consuming 161MB of RAM. Safari is consuming about 1.2GB. When I used to have to run slack for work, it would easily consume over 2GB of RAM. Opening Atom consumed 500MB of RAM without a single file open, though it did eventually slim down to 200MB. But I can see that Atom has a problem because RAM consumption is increasing by over 10MB every 10-20 seconds and it is sitting in the background doing nothing without anything open. It is now up to 350MB of
No matter (Score:3)
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.
Does this explain app-ification? (Score:5, Insightful)
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...
What the hell is a HIG violation? (Score:3)
Re: The summary is a terrible word gumbo. (Score:2)
FIFY