Too many Mac apps are being built with Electron | Hacker News Reader

Too many Mac apps are being built with Electron

hyperdiskapp.com

70 pointsJKCalhoun104 comments

I disagree with the author.

I see it as, if not for Electron, this app wouldn't have been made for Mac period or it would not have feature parity or it would be more expensive in terms of subscription or one-time buy price.

Choose 2 out of 3: Low price, feature parity, app performance.

For certain types of apps, consumers have chosen low price and feature parity.

I think it's fine for apps like Spotify, Whatsapp, Discord, Teams, etc to use Electron. They're cross platform apps that also require a web version. Electron provides acceptable performance for them.

VSCode is the prime example of having huge success with Electron. It's free. It supports many platforms. It has feature and plugin parity. It even allows very interesting use cases like spinning up private web instances that have all your local settings.

Obviously there are types of apps such as video editing and rendering that should not be Electron apps - and they aren't.

> I think it's fine for apps like Spotify [...] to use Electron

Spotify uses a significant amount of power/battery while playing music when my laptop is otherwise idle. I can only image that being due to decrypting their drm'd music in javascript. Many people won't notice and therefore not care, but I do think it's quite the drawback. Much more than the ui not looking native or not perfectly integrating into my desktop.

Even running through wine would be preferable to that.

Electron (node) can call into C libs in a couple of different ways in order to do things like decrypt the music. I really doubt that work is being done in the javascript layer.

I've not had an issue with Spotify for some time, I generally like the app other than the odd nitpick here and there. I haven't encountered bugs for a long time, not ones that stop me using it.

Apple Music on the other hand... a native app that, being written by Apple themselves, should be the epitome of how to do it in terms of quality and user experience, is terrible! It feels laggy. I just opened it and clicking between sections there's like a noticable tiny lag in the highlight under the list items where spotify feels immediate. AM looks pretty sparse. But far worse than those things, it often breaks and is unusable. "There was a problem accessing your account" restart and it works. When I first signed up to it I had to contact Apple support because the app just wouldn't work. I guess at least they had a support channel where I could chat with someone. The app quality is appalling though.

Apple Music is the perfect representation of what Apple has become in my opinion. iTunes was a hugely influential, useful and well-made software. Apple Music is a poor imitation of its predecessor and somehow manages to be worse in every metric possible: performance, interface, user experience and even feature set.

All that to access a shitty streaming service that is lackluster on so many levels. Starting by the fact they remove much more of the catalog than Spotify does and they even removed access to tracks I bought on the iTunes Store, which is completely bonkers to me.

After 4 years on Apple Music, I just went back to Spotify, because not only are they significant benefits (don't lose everything if you want to cancel sub and works way better in more platforms) but the app itself is just better. It also starts streaming much faster on any connection, and even though I did like the Apple Music discovery playlist, Spotify is better at this game in many ways.

In the end Apple Music perfectly illustrates the questionnable success of today's Apple stuff because they have a cult following buying anything they do even though they are not particularly features nor price competitive.

By the way, the Spotify app lets you use your mobile as a remote for any running instance on your network, inside the same app, with the same playlist/track saving capabilities. But for some reason, Apple, who control the whole technology stack is stuck with a half assed remote app from iTunes vestige that cannot control Apple Music playlisting (only able to browse and play) and their overloaded (extremely busy full of useless crap irrelevant to the user) mobile app cannot do anything useful.

I really don't understand how people can reason about with today's Apple prices, because they are clearly stuck in another era and sell subpar shitty products...

Literally takes a second or two to load a view, it's insane

The unsaid disclaimer here is "on your hardware." It seems to take mine much less time.

Actually the unsaid disclaimer is probably "the first time" or "when uncached" because AM loads the screens much faster the second time you click into them (still with the UI lag that I'm complaining about). I would actually say that Spotify screens take just as long to load, but the difference is that Spotify seems to implement a progressive load, so even the first time you click it feels faster - you can start interacting with the most important thing at the top straight away. With AM it delays then shows the whole screen.

This is my experience on a Mac anyway.

Would running through Wine really provide that much of a difference in resource consumption?

Wine has almost no overhead, which means a native windows app should be much faster than an equally optimized electron app.

Interesting, because I find that running software like MyLifeOrganized in Wine to be fairly cumbersome versus running it natively.

Indeed Electron apps are not competing with native apps, they are competing with not existing at all, especially for macOS and Linux because of their relatively low market share.

That argument would hold more power if there wasn't an existing native client for Slack and Discord, made by one person, with all the features I needed, working with absolutely no lag and minimal resource use, working on MacOS, Linux and Windows.

Unfortunately the development stopped, or I'd still use it. https://cancel.fm/ripcord/

There's absolutely nothing preventing a large, funded company from achieving the same on the tech level.

Ofcourse there is something stopping it: money. Resources are finite, resources spent on implementing the same features on 3 platforms instead of 1 cannot be spent on other things.

Both Slack and Discord can afford one good person, given that they employ many more and manage to do a UI refresh which mainly makes things worse. (Slack some time ago, Discord recently)

Also, it's not how portable things work. The shell may need some crossplatform work, but the behaviours and core of the app is the same.

This is not a money issue.

It's not an issue of not having the money to pay for it. But it is an issue about how the company makes money.

I say this as someone who loves the Mac, and goes out of his way to avoid electron apps, but in most cases, it doesn't make sense for a company to produce native Mac apps. Especially if that company is VC funded.

I worked in shops in the late 90s into the 2000s that produced cross-platform Windows/Mac programs. It was a lot of fun in many ways. But even the best-run teams with the best cross-platform stacks suffered from slower development times than they would have if they were targeting a single platform.

Even when like 90% of the code is cross-platform.

There are lots of reasons why. Some of it is due to platform differences. Sometimes the same feature couldn't work the same way across platforms. That meant either correctly doing extra design and planning ahead of time, or figuring out that you messed up and calling emergency meetings to figure it out. It meant extra work producing documentation that called out the differences. It meant training support staff on the differences.

Another issue was keeping all the teams on the same schedule. If you've got "one good person" working on the Mac side of things, and they get sick for a week, then either you ship the Mac update late or you delay every other platform.

Finally, there's always been a lot of churn on the Apple side. APIs getting removed. The platform moving to a completely different programming language. Toolbox. Carbon. AppKit. SwiftUI. Pascal. C. C++. Objective-C. Swift.

So a lot of teams went the route of trying to create their own cross-platform framework in C++, and focused their platform developers on just implementing the framework, so all the app work could be done by the cross-platform devs. The Mac people could thus isolate the app from the technology churn on the platform.

This never worked out. It almost always ended up being faster to write separate apps from the ground up for each platform, because the cross-platform framework would balloon into a monstrosity. You'd spend more time on the framework than any app, and somehow, you'd still lack functionality that the cross-platform devs discover they need for the latest top-priority feature coming down from management.

But typically, on the best teams, it wasn't just one person per platform. Because of the need for so much coordination between platforms, lots of time was spent in meetings, so you'd need at least a few people working on each platform. These are things you don't have to worry about when you're an independent developer working on an app that hits the company's API.

You might be temped to point out that this could all be avoided if you just had a server team write the server software, and one-person platform-specific teams that just wrote native apps that communicated with those servers. Sure, you still have to produce different documentation and support resources, but most companies skimp on those anyway.

You'd also have a bunch of apps with different features, shipping at different times, but they're all great apps, so that doesn't matter, right?

The result is that you'd come up with decently great apps for each platform. The project managers might even be able to recognize that they're cool, great apps.

But you'd still be like a cat bringing them a dead rodent. What are they supposed to do with this?

Admittedly, some of this has to do with how middle-level project managers justify their jobs. They spearhead features and make sure they get delivered into the product, theoretically increasing its value, and therefore the value they delivered to the company.

But it's not all that kind of bullshit. Sometimes it's essential to the company's bottom line, or to an attempt to improve that company's bottom line.

To use Slack as an example, at the start of the COVID lockdowns, Zoom usage shot up tremendously. Slack felt that this was a potential threat to their place in the market, and they introduced huddles. It took like a year, and Slack huddles are still worse than Zoom, but it was still probably good enough to retain some subscribers.

If it took a year with Electron alone, just imagine how much extra time it would have taken to plan and coordinate the feature across multiple platforms. Since it's important to the company, you can't just let the platform teams roll it out on their own schedule, or decide it doesn't fit well with the feature set they've cultivated for their platform. You need it out, you need it fast, and you need it to work the same.

Electron was the first cross-platform solution that worked well enough to make that a reality. It sucks in many ways. It doesn't follow platform conventions. But it's good enough that people can use it. And, bonus, the apps are all written in a language and an API that millions of Web devs are familiar with. No need to worry about the schedule slipping because one employee was sick.

In a fast-pased business, you need fast, universal turnaround on important functionality. It's more impactful to your bottom line than customer experience, even if that functionality is just some dumb BS like Discord super reacts or something.

  That argument would hold more power if there wasn't an existing native client for Slack and Discord, made by one person, with all the features I needed, working with absolutely no lag and minimal resource use, working on MacOS, Linux and Windows.

Did this 3rd party app have 100% feature parity with the original Discord/Slack app the moment new features came out? If not, what was the time delta between the two?

Why didn't the author continue development? It seems like it was on sale for $20? Surely because people value native app so much that he would have made more than enough money to continue development?

Can't speak for the author. I haven't seen the reasoning. The awareness of the app wasn't that great though. I only found out it existed right as Slack changed the organisation token/auth which never got fully implemented in Ripcord. There was only one post that got lots of attention on HN and that was before the pandemic. (With a pretty good reception, mostly around being light/not-electron https://news.ycombinator.com/item?id=19617699)

Can't speak to the feature compatibility completely, but testing it over a week or so I've not found anything missing at the time. I think the video calls got added after the development stopped and that never arrived.

Then Discord started banning third party / differently behaving clients, so that part got dangerous.

It did get good feedback on HN. Most people here love native apps. But the real question is, did people here actually support the developer and buy the app?

My guess is no. There weren't enough people who wanted to pay $20 for it. That should tell you how much people actually value native for this category of apps.

Do you realize that yourself, in your own reply, pointed out the fact that it is indeed and non-viable option.

As in it doesn't exist because there is no money in it because it doesn't change the company bottom line in any meaningful way that would warrant additional hiring. And it is not even viable for a single person with reduced running cost to make it a viable revenue stream because they would be too few people purchasing it; since as long as the (maybe worse but still largely viable) official electron option would exist there would be no point for a user to spend money.

The development has stopped, because it doesn't make enough money for even a single guy to justify spending time on it. At some point even if it's a passion hobby project, making software is actual work if you are bound to another entity roadmap...

I agree with this take. Most of the 'good' app listed (and also the ones I love) like Transmit, iTerm etc are mac _exclusive_. They only target Mac.

It doesn't make any sense to do that to Discord because it's cross platform by necessity and design.

The exclusive apps are other side of the coin, even. They show that making something that targets Mac is its own job if you're not using cross platform frameworks. With that in mind, it makes perfect sense that people don't want to target Mac, especially if they're not entrenched in or familiar with the Apple ecosystem.

I wonder what the best example of a cross-platform app that uses the native toolkits on the various platforms is.

I’m going to discount/ignore things like browsers.

Which toolkit do you use on Windows

In defense of the companies that do this - making native apps is extremely expensive compared to just using Electron. If you want to have a native app for Mac and Windows and a website, that's 3 separate frontends that you have to propagate changes across. This triples all the work that you typically have to do (UX changes, platform-specific bugfixes, etc), and getting some fullstack developers are cheaper than hiring Mac/Windows specialists.

I think HN users are in the minority of users who seriously care about speed/performance. Electron is good enough for pretty much everyone else, and it's clearly working well for for Discord and Slack. It makes more sense IMO to invest time in improving Electron efficiency rather than telling companies to just avoid it.

Avalonia https://avaloniaui.net/ QML https://doc.qt.io/qt-6/qmlapplications.html and other options exist. The choice is not between Electron or native. There's lots of options in between "everything native from scratch" and "ship the whole browser".

Also for many electron apps you're going to write a native component too.

By the point you are using QML I don't think it's actually that much lighter than Electron. QtWidgets is probably justifiably better in this regard. Not all electron apps have to be as bloated as Slack, for example. It's possible to design sane applications.

No, it's still not the same category. QML doesn't pull in a full featured Chrome with all its runtimes, dom, full scripting, multiple levels of JIT, etc. You're still significantly lighter. Even Avalonia with bundled .net is lighter.

QML is very efficient. Much of custom QML code ones write actually compiles to C++[1]. All the code of Qt Quick components are written in C++ as well. I'm now creating a block editor in Qt C++ (model) and QML (view) that is 4x faster than that fastest comparable native app on macOS[2]. So, yes, it's possible to write very efficient code with QML.

[1] https://www.qt.io/blog/qml-type-compilation

[2] https://www.get-plume.com/

For paid software at least, it would be a silly strategy.

The point of buying software on the Mac is that it is tailored for the specific environment. Someone who doesn't care about any of that wouldn't even be a potential customer, since they wouldn't even use Macs often enough to consider buying anything.

At most it would only be attracting customers who are forced to buy that software because there are no alternatives.

> We all know how browser-based web apps tend to feel. Things lag, they’re inconsistent, you’re never sure whether stuff like copy & paste or drag & drop is going to work, you’re not sure where (or if) your work is getting saved, the list goes on.

This has not been my experience with Electron apps at all.

> An app that’s under 20MB is very lean. Apps over 100MB better have a good reason for being so big, and apps above 500MB are probably bloated, unless they’re games or legitimate mega-apps like Photoshop or Final Cut Pro.

Smaller is better, surely. But outside of gaming computers and embedded software, how often are most people really scraping together megabytes of disk space to store their 200MB applications? Not very often, is my anecdotal experience.

> While they’re running they also take up RAM (memory,) and use CPU processing power.

Sure, I won't argue at all here. This one hurts a bit sometimes. I suppose it more so hurts people running low end hardware.

This might get filed under my list of "hot takes," but rarely, if ever, is my computer slogging and I open up htop or Task Manager and discover it's some Electron app swallowing my system resources. So I find a lot of the anti-Electron arguments to be a bit exaggerative.

That's exactly the problem, tho - our hardware is playing a game of tag with bloated software, it always needs to keep up with the newest bloat. Buy, why? My computer is extremely capable already, why not use its resources efficiently to get the best out of it? I'm building an advanced block editor (like Notion) in Qt C++. It takes 0.78seconds to load War and Peace on my 2016 MacBook Air. Using the top of the line Electron app (MarkText) takes 34x longer! Also, the same text loaded using the best native macOS app (Bike Outliner), on a 2022 M1 Pro takes 1.5seconds. So, my 2016 MacBook Air is "faster" than 2022 M1 Pro just due to more efficient software.

> it always needs to keep up with the newest bloat. Buy, why?

Because there exists tools that make it easier to ship a good software product to the market, and without these tools, there are many software products that would simply not exist because of the much more prohibitive cost of developing bespoke applications for every platform you want to support. And the flipside to that predicament, not supporting everyone in your target market because you only developed one of the apps you need to develop.

There is a trade off. You aren't getting nothing out of the bargain. Maybe you noticed, but this blog post we're commenting on is actually an advertisement for a software product that only supports MacOS. Seem a bit ironic, doesn't it? I wonder if leveraging Electron might make it simpler to add support for Windows or Linux systems.

Too many APPs are being built with Electron.

There really just needs to be a cross platform API that renders with native widgets and is easy to link / build against for OSX+, IOS+, Android+, and Windows+. Make the platform open spec and free to implement and Linux / BSD will probably follow on their own.

The do or die is shipping natively, with the OS, on the popular closed platforms. Web browsers are where engineering dollars are already spent to adapt a common API (web tech) to native platform tech and that's why Electron and similar things see traction.

There's plenty of cross platform APIs, some of them quite ancient and established, the problem though is too many choices.

I mean there is Qt and wxWidgets but they look dated compared to Electron which supports the latest in web front end technologies.

They "look" outdated because many developers using Qt simply don't care about aesthetics, unfortunately. But there are some few good exceptions. Telegram Desktop uses Qt[1]. Another one is a new app I'm working on[2].

[1] https://github.com/telegramdesktop/tdesktop

[2] https://www.get-plume.com/

I couldn't agree more. Yes there is some utility to things like Electronc and React Native. They are great for small startups that don't have the money to hire a team for each platform. Or they just need to get something that they can demo to investors. But really when it comes down to it, they should take some money and hire some people that can write the app natively.

> In this test, there’s no contest between BBEdit’s 1 second launch time and WhatsApp’s 16 seconds on a 2021 MacBook Pro.

How is 16 seconds even remotely reasonable?

It's not, and it's faster to take my phone out of my pocket and open it there (where it's native)...

...which is exactly what I do.

The desktop app is only really useful for reading images with small text or shunting around attachments. As a messaging app it's a mess, and not even remotely a first-class way to use WhatsApp.

P.S. it takes even longer if you haven't used it in a while while it catches up while re-rendering for some reason so it looks like the whole app is in super speed... rather than just do that behind the startup loading bar and save the useless visual updates that look half-broken?

Yup, I really don't get Whatsapps "catching up" mode, which after only like a week takes significantly longer until the ui is usable than linking a new session

Oh, so not just me that prefers to use their phone for some stuff even if the UX itself sucks? The launch time is a big one for me.

Counterpoint: not enough Macs are selling to justify native development for a lot of apps—but better to ship something than for the Mac to sell even less because of missing software.

You can build for mac and linux at the same time if you plan for it.

Yup—but the average Linux user does not give two shits about the average crapware that corps want to shovel onto consumers as they tend to be much more fussy over privacy and ethics.

Even Apple themselves seem to be taking this strategy! (Note the Apple Music thread above.)

I've been learning game dev recently and I've discovered that the Godot game engine is actually a very capable app builder. It has all the benefits of electron -- accessible to developers, multi platform support -- but it appears the apps are much leaner.

The author mentions the official WhatsApp weighing in at 324 MB. There's an open source WhatsApp clone made in Godot that builds at about 55 MB. Of course with all the media and features of WhatsApp its not a apples to apples, but regardless the results are interesting.

https://github.com/3ddelano/whatsup-godot

Fun fact, Tesla also uses Godot for their mobile app.

The new WhatsApp client for macOS is native, tho.

Ha that's what I get for not fact checking. Nonetheless the app is still extremely bloated.

The web is/has been//will be taking over and it's an unstoppable force at this point. It's the only true universal cross-platform API. To improve cross-platform experiences, the answer is probably not in spending resources on creating native apps for each platform, but to improve the cross-platform Electron (or Electron competitor) experience with web technologies. Unfortunately this is not necessarily in the interests of Apple and Microsoft, so I think it will remain a bumpy ride.

I think what's missing from a lot of these discussions is that web services shouldn't need to write native apps. All they need to do is provide a full API and let third-party native app developers do the rest of the work. The problem is that these companies want to control "the whole experience". People often say, "It was either Electron or nothing", but that's assuming only one company is writing every native app. The real problem with the official Slack Mac app is that it exists! If Slack just got out of the way and let Mac native developers take the opportunity to write Slack apps, we'd probably have a number of good ones.

Consider Twitter. The healthiest app ecosystem Twitter ever had, on both Mac and iOS, was when there was no official Twitter app. There were a bunch of great third-party native Twitter apps. But then Twitter acquired Tweetie, released an official app, and that was the beginning of the end. In the end, Twitter destroyed its own app ecosystem by trying to control everything.

"Why is [web service] using Electron?" is the wrong question. The right question is, "Why is [web service] writing native apps?" Let web developers be web developers, and let Mac developers be Mac developers. Each can do what they do best, without trying to do everything.

> All they need to do is provide a full API and let third-party native app developers do the rest of the work.

The problem with this is that those apps are kind of boring to make and there’s not much money in them.

> those apps are kind of boring to make

Why?

> there’s not much money in them.

Enough money to sustain a big corporation? No. Enough money to sustain an indie developer? Yes.

I can’t speak to everyone but they are boring to me because there’s not much of a problem to solve, just UX. And it isn’t something I need personally, so I just use the api or maybe a CLI.

I just assumed lots of people think like this due to the dearth of nice UIs on top of apis.

> I can’t speak to everyone but they are boring to me because there’s not much of a problem to solve, just UX.

"just UX". I think this attitude separates you from a lot of native iOS and Mac developers, whose primary focus is UX. Indeed, one might say that's the foundation of those whole platforms.

> I just assumed lots of people think like this due to the dearth of nice UIs on top of apis.

What dearth? Like I said, Twitter used to have a great third-party app ecosystem before the company intentionally destroyed it.

Isn’t this article about how people make Electron apps instead of spending time in proper UIs? I think that’s part of an example of a dearth of UIs.

Of course my interest in UX separates me from other developers. There are lots of people making a living doing UX. And I’m not one. But my point is, it seems like those UX people aren’t creating lots of open source projects, or commercially viable projects, to provide nice UIs on top of apis.

> Isn’t this article about how people make Electron apps instead of spending time in proper UIs?

You speak vaguely about "people" making Electron apps, but the big issue is that big companies are making Electron apps for popular web services, and the popularity of these web services is why a lot of people are complaining about the Electron apps.

> it seems like those UX people aren’t creating lots of open source projects, or commercially viable projects, to provide nice UIs on top of apis.

Which APIs are you talking about? It's difficult to make a commercially viable project on top of obscure or unpopular APIs. The point of my original comment is that popular APIs can generate their own native app ecosystems.

App which loads content from cloud infrastructure launches slower and uses more computing resources than a text editor which loads local content. Oh gosh, such exiting and not obvious conclusion. This discovery will push the entire industry forward. I agree that Electron apps are not enough resource efficient but I don't remember them promoting this. CS is always a trade-off, in this case you get cross-platform app for less efficiency. If you're not agree with that, send the email to WhatsApp PM team and try to convince them that they need N times more dev teems, N times more QAs (where N is number of platforms) and spend N times more $$$ on them all to make you happy. Btw, try to imagine how long it's gonna take to build a feature in such environment. The author lives in Wonderland where you can compare whatever you want and where A is worse than B just because the numbers says so, without any justifications.

Yeah I noticed this too. That was a completely unfair comparison, and if the author of this article is a decent engineer, then he has to know how egregiously bad faith that comes across. The author won't have support from a lot of people after two mistakes:

1. He's published the article under his native Mac app's blog, which he has every incentive to do and for that reason is biased.

2. Comparing a local text editor to an app that loads tons of rich media content from one of the busiest servers in the world discredits the argument in a major way

It is interesting that many folks are comparing macOS native apps and Electron apps. As someone who uses macOS for work and Linux for everything else (FOSS, games), I'm thankful for Linux apps using Electron, CEF (Chromium Embedded Framework), and Flutters, otherwise, developers/companies might opt out of supporting Linux. While in many cases writing native apps using one's favorite compiled language such as C++, Swift, and Rust is preferred, many apps prioritize feature parity over perfection, making cross-platform usage perfectly acceptable.

This is so true. Electron is bloated and it's only used because it's easier. Same with React Native. We have got to stop putting DX over UX.

"WhatsApp Helper, WhatsApp Helper, WhatsApp Helper (GPU), WhatsApp Helper (Renderer) and WhatsApp Helper (Renderer). A Mac app shouldn't need any of these. They’re probably communicating with each other using sockets or ports, or maybe shared files. This really isn’t how you’re supposed to build a Mac app. This shouldn’t become normalized."

> ... Not apps that link in a lot of big bloated frameworks like WhatsApp, Zoom, Slack, Discord. (For some reason this category of app just loves huge frameworks.)

I dislike Electron apps, too, but isn’t one reason for that category of apps to use huge frameworks is that they are all communication apps for people on multiple platforms? Apps for such consumer-facing uses would run into a lot of problems if the details of the interfaces were different for users on different OSs.

Better comparison with WhatsApp instead of ancient text editor would be Telegram app [1] built with Swift and C/C++, given hypertext and rich media that is modern messaging app like Telegram, it is resembles more a subset of web browser functionality rather than text editor, so binaries for this around 235 MB in size.

[1] https://github.com/overtake/TelegramSwift

Apple needs to invest in making Swift and SwiftUI more cross-plat friendly, otherwise businesses will continue to use the subpar cross-plat technologies that are at hand to ship to their platforms. I don't think this will happen though because they don't care much about the macOS App Store relative to iOS which doesn't have this issue nearly as badly.

Why not make electron more efficient? Could webasm be the path forward here? Or is it the frameworks themselves that are bloated.

I couldnt disagree more. Many/most of the apps the author lists as "let's write more of these!" are EXCLUSIVE to Macs. Of course it's much easier to develop a native app if that's the only platform you target.

Hell, the author even self promotes his own app as a model to follow. Surprise surprise the only supported platform is Mac.

I don't think it's realistic to expect every company, regarless of size, to redevelop their application in native toolkits for every platform. It's much better overall to develop a one-size-fits-all solution, and Electron is obviously one of the more popular tools for doing this.

Now, I definitely support a leaner cross-platform framework, but advocating that companies "use Apple’s own tools and toolkits, and stick closely to them" is fanboyism at it's most extreme.

Native apps are genuinely better and I don't think it's fanboyism to point that out. But yeah, we're never getting native apps so it's mostly pointless to rehash it.

Better in some regards, but worse in others.

Fanboyism was more in regards to the "follow the examples of these apps", where most of the apps ONLY target Macs.

I totally agree with the author's points, however, I can't understand why people run "apps" for things like WhatsApp (and Slack) when they run just fine in a browser tab.

I love the idea of PWAs as an option for people, but I would 100% rather use a web page than an app.

I have kick ass extensions filtering ads, giving me adjustable/customizable dark mode, I have a great form auto-saver, I have audio scrobblers, I have pinboard and are.na extensions.

I have a url bar! I have tabs! I have back & forward buttons where I expect. I am afforded so much by the browser chrome. I don't want my user experience to be at the behest of some company building an app; I want the freedom and power to go further. And it feels like PWAs are a step back, to a form of computing that doesn't respect user agency.

And alas, a number of permissions are being created that only work for PWAs! This is the biggest threat I see to the web I want: PWAs forcibly removing me from the situated environment I regularly use/enjoy, the browser.

Yes, I feel like the idea of a website/web-app you can install made sense at one point, but the reality is that it's not really much of an advantage on a browser, and if you're still running a browser too, you may as well just use it as a part of your existing browser.

Firefox pulling the plug on their PWA efforts was pretty frustrating.

>I totally agree with the author's points, however, I can't understand why people run "apps" for things like WhatsApp (and Slack) when they run just fine in a browser tab.

On macOS, you get native notifications, a bright red dot on the app icon for notifications, and a separate window from your browser. Lastly, the app might optimize for native macOS APIs strategically.

Web notifications are a thing, and Whatsapp could popout a window without browser chrome from a webpage

None of those are worth a few gigabytes of memory and disk space to me.

It is to some people - like me. Electron gives us that option at a low cost to the developers. You can use the web version. I will use the desktop version. :)

Perhaps at a higher cost to end users.

A lower cost actually to end users typically.

Cost can be quantified on many levels, including performance and quality.

Hence, I said "typically".

Then "typically" it comes at the cost of performance and quality.

And a lower cost, which consumers have chosen. Quality is debatable.

People like to click a dock icon or cmd-tab to an app, instead of having to click a dock icon and then a particular window and then a particular tab, or cmd-tabbing and then clicking to a particular window and then a particular tab.

It had all sorts of limitations & I get why it didn't last & it was overloading even for me, but...

Damn I miss those glorious months or years when Chrome tabs were just app instances.

It's insane to me that the browser & OS both have their own totally parallel/separate ways of managing multiple windows. That the two don't work together at all. The os has seemingly made such faint progress in helping complex apps manage multidocument setups.

I guess I'm just biased because I like to run an OS on my desktop (freebsd) that doesn't support Electron. I've carried that over to my macbook... I've just gotten into the habit of "gmail is leftmost, slack is next, etc", and never have a problem finding slack..

So you're using your browser tabs as an app manager. Most people prefer to use the actual OS app manager.

You can have more than one browser window though.

That’s what I said.

Because with apps, I can download something built proper from the community like Ripcord instead, that uses less than 100mb of my memory.

Sorry Apple, but there is nothing so special about your platform that won't prevent developers from abstracting it away into a general cross platform case.

The problem is that Electron's (and Python's) interpreter(s) add too much bloat... Just change it (them)

->We programmers have got to stop building stuff this way.

Then the platform developers need to work together and offer a better option. Its as simple as that. I dont think _anyone_ is proud of electron apps, but mostly there simply isn't a better alternative, complaining electron sux doesnt solve the fact all the other options suck more.

Qt, JavaFX etc... give me a break.

Weird question, what's the right number?

-1/12

Ha! When you know - you know ;)

If whatsapp takes 16 seconds to launch on your mac I'd say the problem is your mac.

I have 5+yrs of history and WhatsApp takes 3-5 min to update if I have several chats on the phone while the app was closed.

For the web as well.

Both the web client and Mac clients freeze or get really slow if people send reactions to messages, it messes up the sync and any messages that I write won't be sent until all reactions are synced.

It is not a machine problem. It's how WhatsApp works nowadays.

I don't have any of these issues. It was quite buggy during the Apple Silicon transition though. It seems stable now.

I run some communities (WhatsApp communities features) that is open in some countries and I feel like these features are made mobile first, and they f* up the web interfaces.

Some anecdata from daily cold booting my MacBook Pro 16' 2019:

- Slack is very reactive, displays a spinner in <2s, takes a few seconds (<10s) to fully load and draw - perfectly acceptable

- Outlook (new experience mode) is a bit slower, takes a few seconds extra to draw, but is still reasonably fast and manageable considering the amount of data it handles - still reasonable, although a bit laggy at times

- New Teams ® (released somewhen Q3-Q4 2023) takes >15s to open or display anything, >15s to draw, >5s to switch across organizations, >1s switching chat tabs in the same org

I'm not spending 3k$ every 2-3 years because "my computer is the problem".

We need to force devs to use and test on non-workstation machines, that don't have 64GB of RAM and the latest CPU/NVMe drive, especially for Electron apps, which open an entire browser copy for each application.

The only reason you would need to spend 3K is because of Apple. You could spend half that and get a similar/better computer that would last as long. Or spend as much and get something that would significantly outlast any Mac of the same price, at least from a performance point of view.

Apple has been absurdly milking its consumer for quite a while now, without much merit in the form of technological advantage.

It's not the fault of software companies if Apple hardware is overpriced, they don't have to care, their hardware are cheap enough...

I completely agree. It takes less than 3 sec to load and displays chats on a 9 years old PC. So, either he is lying or the mac he is talking about really sucks.

But to be honest it is quite possible since they still sell overpriced 8GB slow as molasse machine that somehow gets hyped up. Their base Apple Silicon machine barely clears the bar for passable (ignoring price) yet we are supposed to believe they are performance monsters; that hasn't been my experience.

If it really takes 16 sec either the mac truly suck or there is something wrong with his setup...

There is no reason why a chat client should take more than a second to launch on any desktop or laptop produced in the past two decades.

On my M1 Pro using the latest Whatsapp version, it launches in 0.5 - 1.5 seconds.

I used to believe the same thing, but that's just Apple propaganda, pretending their stuff is better than everything else when in practice it's not always the case.

It would be an argument if Mac native development could be ported to other platforms relatively easily. But that would take Apple to care about anything else than itself so it will never happen. As is, it only makes sense to develop a Mac native app if you are absolutely sure that it is the only platform you want to target. For this reason, there are some successful niche apps, but I believe that it is not a very good idea for the vast majority of projects.

Apple has some good librairies that can speed up the dev process of some specialty apps, but if it becomes a complex long running project, it is most likely going to bite you; because of being tied to the Apple agenda and the fact that they have zero problem in deprecating everything every 5 years or so, creating much unnecessary work and erasing a lot of value creation.

And this is under the assumption that Apple native stuff is inherently better than other native stuff. That used to be true in some cases, but with recent developments I don't think the argument holds up. Native stuff does not bring a lot of advantages while not feeling much faster than alternatives and recently being even more bugged than you would expect. Anything swift is generally just not very good when it's not just plain bad. I think the native Reminder app just got barely usable, after like 3-4 years. At this point I prefer electron stuff...

The argument about ressources and bloat is typical Mac user stuff. It only matters because Apple is a greedy corp charging way too much for way too little. People using Mac have to care, because there is a very real and large cost to overprovisioning your system to guarantee performance. But the reality is that RAM is cheap and storage is even cheaper (especially if you don't need to have the fastest thing around) so it doesn't matter. People who want/need fast system in all conditions just max out their RAM to 32/64GB and their SSD to multiple of terabytes. It cost them less money than it cost upgrading 8GB of RAM at Apple. And while every Apple fanboy is boasting about Apple Silicon battery thanks to its power consumption the reality is that you will find computers that cost half to 2/3 of the price of Apple's cheapest offering that perform at least as well (from a benchmark standpoint) but in practice much better in real-world use (because of many factors, like application technology just like this post says).

Alos, on Windows 11 WhatsApp uses 50-80MB of RAM but that's not surprising considering how bad macOS is with third-party technologies. In general, there is some widely held belief that macOS (and Apple stuff in general) makes better use of the hardware. As someone who runs both systems concurrently (and even ran 2 identical Mac Minis, one on windows, on on macOS) I can say that this is a load of horseshit. I find Windows to be less ressources intensive, especially if you have a dedicated GPUs, then system RAM use is much lower. A major problem the Macs always had was poor GPU specs, but they made it even worse with Apple Silicon, because, surprise, you need to share your overpriced soldered memory just to display stuff too. Isn't it nice? This was an intended consequence and the unnecessary RAM soldering (somehow justifying the absurd price) just a means to an end: make more money, with absurd margins.

And yet native apps consume as much or even more memory than electron because you have to implement memory management manually which could be very difficult for app like WhatsApp.

Reply on news.ycombinator.com