Electron sucks because it's in complete defiance of a given platform's conventions. A Cocoa app behaves like macOS itself. For example, keyboard shortcuts and filesystem access are consistent...
This is honestly a terrible article, it manages to mention "Electron' 9 times and the only explanation it gave for why Electron sucks was from a sensationalized quote, half of which was this:
Electron sucks because it's in complete defiance of a given platform's conventions. A Cocoa app behaves like macOS itself. For example, keyboard shortcuts and filesystem access are consistent across Cocoa apps, but really that's just the tip of the iceberg, two of the most obvious and noticeable examples.
Of course, macOS is the only platform that really has conventions, which is exactly Gruber's point. Windows has always been a fragmented mess. "Mac-like" is a thing. "Windows-like" kind of exists, but it's weak. "Linux-like" is even weaker, because Linux doesn't even have a single desktop environment. And there is no "web-like." So Electron doesn't stand out nearly as egregiously everywhere else because there is nothing to fit in to. The platform vendor, if there even is a singular "platform vendor," isn't enforcing or guiding anything.
If you wanted to use a platform which at least tried to maintain some semblance of consistency between the OS, first-party, and third-party apps, the Mac was your only option. Even iOS never really had that, Apple tried in the early years by blocking apps made with anything other than Xcode, and it was just unsustainable. The number of developers who are willing to use a different development environment and toolkit for any given platform has shrunk to zero. There are now "Mac developers," "Windows developers," "Linux developers," "web developers," and "cross-platform developers." There are no "cross-platform-using-native-toolkit developers."
Can you think of any application of any appreciable complexity that is cross-platform and uses UWP or Win32 on Windows and Cocoa on macOS? And if there's a Linux version of the app, uses GTK? No. That's unheard of. If they're old-school they rolled their own or they used (or may still be using) Java, and if they're recent they're using a JavaScript solution.
That's the point Gruber is making. This is only something that old-school Mac users care about, and even those old-school Mac users are now strangers in their own land since macOS is an order of magnitude more popular than Classic Mac OS ever was, and the new users don't care. With "Marzipan," even Apple itself has conceded that Cocoa is history.
What these people want always really confuses me
You're confused because you're inexplicably combining two groups who have diametrically opposed views. The people who whine about porting effort are not the people who whine about interface consistency. The whole reason these groups are whining is because they don't like the other group's approach to cross-platform software development!
Just to add on to this, when the author writes "users who know HIG violations when they see them" and links to the Mac Human Interface Guidelines, it's worth pointing out that Apple's been...
Of course, macOS is the only platform really has conventions, which is exactly Gruber's point. [...] "Mac-like" is a thing.
Just to add on to this, when the author writes "users who know HIG violations when they see them" and links to the Mac Human Interface Guidelines, it's worth pointing out that Apple's been publishing the doc since 1987. It's accurate to say that the conventions exist, and it's inaccurate to say that the existence of conventions means that:
a lot of people in tech just want everything to stay the same, to stay familiar, forever.
...since evidently agreed-upon platform conventions don't preclude progress. The official definition of what "Mac-like behavior" is has existed for longer than a good portion of us have been alive, and there's been no shortage of change in that time.
Actually, I'd argue that at least on that platform, significant change has been driven by the best "developer citizens", like Panic, Casady & Greene, and Omni Group.
IIRC, Qt has the capability of using native OS widgets for each platform. But since I don't develop Qt applications I cannot say how well it works.
Can you think of any application of any appreciable complexity that is cross-platform and uses UWP or Win32 on Windows and Cocoa on macOS? And if there's a Linux version of the app, uses GTK? No. That's unheard of. If they're old-school they used (or may still be using) Java, and if they're recent they're using a JavaScript solution.
IIRC, Qt has the capability of using native OS widgets for each platform. But since I don't develop Qt applications I cannot say how well it works.
I think this is a good basis for the argument that Apple’s HIG and GUI frameworks for macOS are the only real game in town for creating high quality GUIs. Even iOS is a shit show by comparison...
I think this is a good basis for the argument that Apple’s HIG and GUI frameworks for macOS are the only real game in town for creating high quality GUIs. Even iOS is a shit show by comparison (which Gruber whinges about as well). There hasn’t been any other platform besides the Mac that has had the perseverance or continuity to command user expectations in the same way, nor a community of developers who collectively bought in to the vision of GUI consistency. I think Microsoft actually does care about these things and certainly has put a lot of work into things like MS Office and Windows itself. But those softwares have been reinvented too many times such that any expectations of consistency are ingrained at the level of the system or of APIs. And that is something where Apple has been willing to reinvent the wheel. I have much sympathy for any devs who made the Carbon to Cocoa transition.
This contrasts greatly with textual UIs from *nix land where ttys have been largely consistent and developers who go out of their way to be inconsistent in command line interfaces will find themselves with either quick and sometimes brutal feedback from would-be users about what they did wrong, or they simply won’t gain any significant user base at all. Read input as a text stream from ‘stdin’, write output to ‘stdout’, and write errors to ‘stderr’. Keep it simple stupid! Give me usage info for any parameters/flags and a man page if it’s more serious than a screenful. This is a proven paradigm that has aged well in most respects. But, clearly most users are not willing to learn text-based interfaces well enough to use them at all, much less as a primary interface.
Personally, I find the notion of creating a robust human interface that is not text-based to be daunting. How can I be sure that the layout works on the screen sizes/resolutions/display tech of my user’s device? What if they’re using a screen reader? What if they’re color blind? What if they resize the window in a strange way? What’s the right way to show an alert that demands attention but doesn’t interfere with the rest of the user interface, much less any other GUI apps they have running?
I know that Apple has answers to these questions going back to NeXTSTEP. I don’t think any other platforms sweat these details enough. And that is why we have threads like the recent one breaking down the failures of Linux graphical DEs to use the simple fixed menu bar paradigm, even though it has so many clear advantages.
I can empathize with the developer who sees JS GUI frameworks and says, wow, that will let me write once and deploy to so many users! But, when every user’s machine basically is just a box to stand up umpteen instances of Chromium, it seems like a cruel joke. I can’t think of any other industries where customers would be ok with this. The metaphors seem utterly ridiculous! I have to install a different radio in my car for each radio station I want to listen to? I need to install a different washing machine in my home for each article of clothing I want to wash? I need a separate table for each dish I want to serve? It’s unacceptable for developers to have such little respect for users. I think that if you don’t know how to make a native GUI (I count myself in that camp), then either hire someone who can, or don’t make a GUI at all.
While we're throwing GUI toolkits out there, wxWidgets is designed specifically to use native components as well, and is used in several notable applications. (Audacity, Code::Blocks, Dolphin,...
While we're throwing GUI toolkits out there, wxWidgets is designed specifically to use native components as well, and is used in several notable applications. (Audacity, Code::Blocks, Dolphin, FileZilla)
That said, the code is very macro-heavy and gives me constipation.
Despite being a commercial success, Qt has not done nearly enough to attract more developers and to evangelize the platform. I didn't mind writing C++ to use Qt, and the PyQt support is decent....
Despite being a commercial success, Qt has not done nearly enough to attract more developers and to evangelize the platform. I didn't mind writing C++ to use Qt, and the PyQt support is decent. But the world is now JavaScript everywhere thanks to the transpilers/compilers that target the language; there was a window of opportunity to ensure a well-designed GUI framework filled in the gaps for desktop apps and for mobile apps even, but Qt and all other frameworks missed that opportunity.
Imo it's less an opportunity missed than a new field of terrain entered. Desktop apps won't be the default experience of using something, but they'll always be an option. I think there'll be a...
Imo it's less an opportunity missed than a new field of terrain entered. Desktop apps won't be the default experience of using something, but they'll always be an option. I think there'll be a greater decoupling of the front end of apps from the back end, & well see lots more apps w both web & desktop interfaces, with somewhat different layouts & focuses.
DF isn't a news site. It's an opinion site. When you read a post on Daring Fireball, you're getting Gruber's extremely well thought out commentary on the topics at hand; and given he's posted...
DF isn't a news site. It's an opinion site. When you read a post on Daring Fireball, you're getting Gruber's extremely well thought out commentary on the topics at hand; and given he's posted about Electron numerous times before, there's an expectation that the reader is familiar with his past discussions in this area.
Gruber is—rightfully—complaining that Electron introduces a non-native feel into the macOS ecosystem. Furthermore, I'm not sure why you surrounded the word feel in quotes, are you trying to somehow imply it's an unimportant metric of software quality? Because it's possibly the most important aspect of what defines Mac software as Mac software.
Go download Transmit from Panic, or Sketch from Bohemian—you'll get a feel for what a good software application feels like. Electron allows developers who have zero familiarity with the macOS look and feel to target the platform without ever being exposed to its affordances, design philosophies, or interface guidelines. It introduces badly designed software onto the Mac platform.
Gruber is further admonishing Apple for their recent macOS application missteps themselves. Photos.app & App Store.app are just two of many examples of this. At the end of the day, you're probably only going to really care when you understand why people love macOS.
An argument embracing change for the sake of change is as fallacious as it is misthought. What are you changing by switching to Electron that is really groundbreaking, apart from introducing cross-application inconsistencies and destroying affordances users of the platform have associated themselves with? An extreme example would be new applications introducing new keyboard shortcuts for copy and paste that don't match up with what users expect. You get this by default with Cocoa. How is that change for the better?
As a GNU/Linux user, since highschool, I was always always always jealous and envious of Mac users, their apps looked great and were actually user-friendly. But I sacrificed user-friendly GUIs for...
As a GNU/Linux user, since highschool, I was always always always jealous and envious of Mac users, their apps looked great and were actually user-friendly. But I sacrificed user-friendly GUIs for great power (especially the power of Emacs) and it was a worthwhile trade-off. However I believe we shouldn't have to make that trade-off at all, we can decent code and decent looking interfaces for free/open source software.
Go download Transmit from Panic, or Sketch from Bohemian—you'll get a feel for what a good software application feels like. Electron allows developers who have zero familiarity with the macOS look and feel to target the platform without ever being exposed to its affordances, design philosophies, or interface guidelines. It introduces badly designed software onto the Mac platform.
Not only does it look good, I'm sure there are fewer bugs than usual and at less CPU/RAM usage too.
I think there's definitely room for a really vibrant mix of both paid and free/OSS applications that work well on both Mac and Linux. I've never really understood the dislike both groups have of...
I think there's definitely room for a really vibrant mix of both paid and free/OSS applications that work well on both Mac and Linux. I've never really understood the dislike both groups have of one an other—we all run POSIX compliant Unix-based OSes that work really well.
I'd like to imagine if a Linux user couldn't use their preferred flavour of *nix, they'd switch to Mac, and if a Mac user couldn't run macOS, they'd switch to some flavour of *nix. I certainly would.
Oh my, just looking at the screencaps for those apps was a breath of fresh air. Sure, there are some appropriate usecases for apps that don't follow the general design plan (Chat apps like discord...
Oh my, just looking at the screencaps for those apps was a breath of fresh air.
Sure, there are some appropriate usecases for apps that don't follow the general design plan (Chat apps like discord are a good example), but utility apps just feel better when they follow the design scheme of macOS. There's a reason for apple's guidelines, and this is it.
Daring Fireball is aimed at an audience that already knows about this topic. He doesn't need to explain what Electron is, or why it sucks, because his audience already knows that. Electron is bad,...
Daring Fireball is aimed at an audience that already knows about this topic. He doesn't need to explain what Electron is, or why it sucks, because his audience already knows that.
Electron is bad, yes, and it's bad because there are alternatives - that you can use the exact same language, tools, etcetera with, mind - that are less taxing on user hardware and don't have nearly as many security risks. On top of that, it adds to the monoculture of the web, giving Google substantially higher control over it than any one entity should have.
Title [slightly] amended to provide some context for those who don't know that Daring Fireball is all about Apple.
Electron sucks because it's in complete defiance of a given platform's conventions. A Cocoa app behaves like macOS itself. For example, keyboard shortcuts and filesystem access are consistent across Cocoa apps, but really that's just the tip of the iceberg, two of the most obvious and noticeable examples.
Of course, macOS is the only platform that really has conventions, which is exactly Gruber's point. Windows has always been a fragmented mess. "Mac-like" is a thing. "Windows-like" kind of exists, but it's weak. "Linux-like" is even weaker, because Linux doesn't even have a single desktop environment. And there is no "web-like." So Electron doesn't stand out nearly as egregiously everywhere else because there is nothing to fit in to. The platform vendor, if there even is a singular "platform vendor," isn't enforcing or guiding anything.
If you wanted to use a platform which at least tried to maintain some semblance of consistency between the OS, first-party, and third-party apps, the Mac was your only option. Even iOS never really had that, Apple tried in the early years by blocking apps made with anything other than Xcode, and it was just unsustainable. The number of developers who are willing to use a different development environment and toolkit for any given platform has shrunk to zero. There are now "Mac developers," "Windows developers," "Linux developers," "web developers," and "cross-platform developers." There are no "cross-platform-using-native-toolkit developers."
Can you think of any application of any appreciable complexity that is cross-platform and uses UWP or Win32 on Windows and Cocoa on macOS? And if there's a Linux version of the app, uses GTK? No. That's unheard of. If they're old-school they rolled their own or they used (or may still be using) Java, and if they're recent they're using a JavaScript solution.
That's the point Gruber is making. This is only something that old-school Mac users care about, and even those old-school Mac users are now strangers in their own land since macOS is an order of magnitude more popular than Classic Mac OS ever was, and the new users don't care. With "Marzipan," even Apple itself has conceded that Cocoa is history.
You're confused because you're inexplicably combining two groups who have diametrically opposed views. The people who whine about porting effort are not the people who whine about interface consistency. The whole reason these groups are whining is because they don't like the other group's approach to cross-platform software development!
Just to add on to this, when the author writes "users who know HIG violations when they see them" and links to the Mac Human Interface Guidelines, it's worth pointing out that Apple's been publishing the doc since 1987. It's accurate to say that the conventions exist, and it's inaccurate to say that the existence of conventions means that:
...since evidently agreed-upon platform conventions don't preclude progress. The official definition of what "Mac-like behavior" is has existed for longer than a good portion of us have been alive, and there's been no shortage of change in that time.
Actually, I'd argue that at least on that platform, significant change has been driven by the best "developer citizens", like Panic, Casady & Greene, and Omni Group.
IIRC, Qt has the capability of using native OS widgets for each platform. But since I don't develop Qt applications I cannot say how well it works.
I think this is a good basis for the argument that Apple’s HIG and GUI frameworks for macOS are the only real game in town for creating high quality GUIs. Even iOS is a shit show by comparison (which Gruber whinges about as well). There hasn’t been any other platform besides the Mac that has had the perseverance or continuity to command user expectations in the same way, nor a community of developers who collectively bought in to the vision of GUI consistency. I think Microsoft actually does care about these things and certainly has put a lot of work into things like MS Office and Windows itself. But those softwares have been reinvented too many times such that any expectations of consistency are ingrained at the level of the system or of APIs. And that is something where Apple has been willing to reinvent the wheel. I have much sympathy for any devs who made the Carbon to Cocoa transition.
This contrasts greatly with textual UIs from *nix land where ttys have been largely consistent and developers who go out of their way to be inconsistent in command line interfaces will find themselves with either quick and sometimes brutal feedback from would-be users about what they did wrong, or they simply won’t gain any significant user base at all. Read input as a text stream from ‘stdin’, write output to ‘stdout’, and write errors to ‘stderr’. Keep it simple stupid! Give me usage info for any parameters/flags and a man page if it’s more serious than a screenful. This is a proven paradigm that has aged well in most respects. But, clearly most users are not willing to learn text-based interfaces well enough to use them at all, much less as a primary interface.
Personally, I find the notion of creating a robust human interface that is not text-based to be daunting. How can I be sure that the layout works on the screen sizes/resolutions/display tech of my user’s device? What if they’re using a screen reader? What if they’re color blind? What if they resize the window in a strange way? What’s the right way to show an alert that demands attention but doesn’t interfere with the rest of the user interface, much less any other GUI apps they have running?
I know that Apple has answers to these questions going back to NeXTSTEP. I don’t think any other platforms sweat these details enough. And that is why we have threads like the recent one breaking down the failures of Linux graphical DEs to use the simple fixed menu bar paradigm, even though it has so many clear advantages.
I can empathize with the developer who sees JS GUI frameworks and says, wow, that will let me write once and deploy to so many users! But, when every user’s machine basically is just a box to stand up umpteen instances of Chromium, it seems like a cruel joke. I can’t think of any other industries where customers would be ok with this. The metaphors seem utterly ridiculous! I have to install a different radio in my car for each radio station I want to listen to? I need to install a different washing machine in my home for each article of clothing I want to wash? I need a separate table for each dish I want to serve? It’s unacceptable for developers to have such little respect for users. I think that if you don’t know how to make a native GUI (I count myself in that camp), then either hire someone who can, or don’t make a GUI at all.
While we're throwing GUI toolkits out there, wxWidgets is designed specifically to use native components as well, and is used in several notable applications. (Audacity, Code::Blocks, Dolphin, FileZilla)
That said, the code is very macro-heavy and gives me constipation.
Despite being a commercial success, Qt has not done nearly enough to attract more developers and to evangelize the platform. I didn't mind writing C++ to use Qt, and the PyQt support is decent. But the world is now JavaScript everywhere thanks to the transpilers/compilers that target the language; there was a window of opportunity to ensure a well-designed GUI framework filled in the gaps for desktop apps and for mobile apps even, but Qt and all other frameworks missed that opportunity.
Imo it's less an opportunity missed than a new field of terrain entered. Desktop apps won't be the default experience of using something, but they'll always be an option. I think there'll be a greater decoupling of the front end of apps from the back end, & well see lots more apps w both web & desktop interfaces, with somewhat different layouts & focuses.
DF isn't a news site. It's an opinion site. When you read a post on Daring Fireball, you're getting Gruber's extremely well thought out commentary on the topics at hand; and given he's posted about Electron numerous times before, there's an expectation that the reader is familiar with his past discussions in this area.
Gruber is—rightfully—complaining that Electron introduces a non-native feel into the macOS ecosystem. Furthermore, I'm not sure why you surrounded the word feel in quotes, are you trying to somehow imply it's an unimportant metric of software quality? Because it's possibly the most important aspect of what defines Mac software as Mac software.
Go download Transmit from Panic, or Sketch from Bohemian—you'll get a feel for what a good software application feels like. Electron allows developers who have zero familiarity with the macOS look and feel to target the platform without ever being exposed to its affordances, design philosophies, or interface guidelines. It introduces badly designed software onto the Mac platform.
Gruber is further admonishing Apple for their recent macOS application missteps themselves. Photos.app & App Store.app are just two of many examples of this. At the end of the day, you're probably only going to really care when you understand why people love macOS.
An argument embracing change for the sake of change is as fallacious as it is misthought. What are you changing by switching to Electron that is really groundbreaking, apart from introducing cross-application inconsistencies and destroying affordances users of the platform have associated themselves with? An extreme example would be new applications introducing new keyboard shortcuts for copy and paste that don't match up with what users expect. You get this by default with Cocoa. How is that change for the better?
As a GNU/Linux user, since highschool, I was always always always jealous and envious of Mac users, their apps looked great and were actually user-friendly. But I sacrificed user-friendly GUIs for great power (especially the power of Emacs) and it was a worthwhile trade-off. However I believe we shouldn't have to make that trade-off at all, we can decent code and decent looking interfaces for free/open source software.
Not only does it look good, I'm sure there are fewer bugs than usual and at less CPU/RAM usage too.
I think there's definitely room for a really vibrant mix of both paid and free/OSS applications that work well on both Mac and Linux. I've never really understood the dislike both groups have of one an other—we all run POSIX compliant Unix-based OSes that work really well.
I'd like to imagine if a Linux user couldn't use their preferred flavour of *nix, they'd switch to Mac, and if a Mac user couldn't run macOS, they'd switch to some flavour of *nix. I certainly would.
Oh my, just looking at the screencaps for those apps was a breath of fresh air.
Sure, there are some appropriate usecases for apps that don't follow the general design plan (Chat apps like discord are a good example), but utility apps just feel better when they follow the design scheme of macOS. There's a reason for apple's guidelines, and this is it.
Daring Fireball is aimed at an audience that already knows about this topic. He doesn't need to explain what Electron is, or why it sucks, because his audience already knows that.
Electron is bad, yes, and it's bad because there are alternatives - that you can use the exact same language, tools, etcetera with, mind - that are less taxing on user hardware and don't have nearly as many security risks. On top of that, it adds to the monoculture of the web, giving Google substantially higher control over it than any one entity should have.