Hacker News Reader

Comment by anaisbetts | Hacker News Reader

This is literally what Slack moved from years ago, because it was very problematic, let me tell you why since I'm the one who did it.

* Adding new APIs was a huge pain in the ass, you had to write all of this ugly bridge code in Objective C, and the APIs ended up being super unnatural on the JS side. As a result, desktop integration wasn't done much since it felt like a "Black Magic" type thing. Writing new APIs in Electron is Just JavaScript, so you can make something much more natural.

* We could literally do fuck-all for people running old versions of macOS - you can't upgrade Safari on old machines, you just Get What You Get. For awhile, every YouTube video on older macOS versions had a pink shade to it. Users write in, "This is clearly wrong!" "Yep, but we can't fix it. Sorry."

* And big spoiler - WKWebView uses _basically_ the same amount of memory give-or-take a few MBs as Chromium. It's the content that sets the memory usage bar, not the host.

View on HN

It also removes pretty much the only reason to use Electron despite its shortcomings - the ability to ship and run the same code on multiple platforms.

Secondly, you lose control of your application runtime environment version - need a new WKWebView version to ship a feature? Time to tell your customers to upgrade the app and their OS.

I’d maybe consider this to cheaply ship a feature inside a Mac app, but this really isn’t an option for like 99% of dev teams considering Electron.

It’s not the only reason. First of all: you can use JS and HTML with all frameworks. Some people consider it a superior solution for GUI. Second: you can easily upgrade your app on iOS without moderation.

We did this too, so many reasons. Lots of bugs, no printer support without using private APIs, etc etc.

It’s really not an option. That and you have to rebuild everything for Win/Linux builds. Just makes no sense.

Also you can’t ship your own updated WKWebView.

For what it’s worth, all of the arguments against your choices are inadequate and don’t really wrestle with the complexity of the domain. And I suspect the authors are not considering this as though they’d be the one responsible for making these decisions for a company like Slack themselves.

Fun fact: Slack has native iOS and Android apps, with all their platform-independent logic abstracted away in a C++ library. I see no “complexity” in making a native macOS app with this.

From a cost-benefit point of view there’s nothing in it for slack. They’d have to rewrite and maintain three separate versions of the same app they already have, and what would the payoff be? It would mildly please a handful of bellyachers, who would then immediately move on to the next grievance. For the majority of users it would be wasted money and effort.

There sure is.

They've have an app that doesn't suck for one. Which you know, would help conversions.

Its not hard to write a Mac app, and its even easier to maintain it. ESPECIALLY if you already have an iOS app.

There is no reason not to just make a decent Mac app. NONE.

Using caps isn’t a substitute for having a point, nor is it a refutation of the effort involved to make three separate native apps instead of one. Also you’re not supposed to use caps here.

I don’t think it sucks, most users don’t think it sucks. You represent a tiny, vocal minority.

My argument is that this is not actually all that much effort, and it would make far more people happy than you’d realize. While not everyone can verbalize their complaints about Slack, I’m sure many feel the performance issues; and they would certainly notice if Slack happened to load five seconds faster or their computer’s battery lasted a couple of hours longer.

I think you’re underestimating the work involved, plus switching from electron to native won’t make people’s battery last hours longer.

> I think you’re underestimating the work involved

This was the amount of work necessary for me to ditch running Slack in a Safari tab, and basically consists of being able to talk to people and send them attachments–the things I do 99% of the time. If I need something advanced like voice calling I’m more than happy to fire up actual Slack. Assuming libslack (or whatever it is called) handles the core protocol and communication layer, I don’t see why it would be difficult to write a bit of Cocoa code around it; I could even pull some of this straight from the iOS app.

> switching from electron to native won’t make people’s battery last hours longer

It does, though. Opening Slack on my computer reduces the battery life by around two hours; a well made native app will have a reduction that can be measured in minutes. Native apps are just better at idling and using fewer resources when they are in active use.

Which application as complicated as slack do you run 24x7 on your computer, with a persistent connection to a server updating the ui that only reduces your battery by a few minutes versus two hours with slack?

Do people still regularly try to ship common platform code as a shared C++ library to minimise unique code bases for their mobile apps? I recall reading years ago Dropbox trying this, but in 2018 is this really the best approach we have?

I can see why it might potentially be attractive in purely architectural terms, but I wonder if the “savings” meaningfully materialise in practice when so little pure native development occurs in C++ on iOS and Android.

Regardless, there’s still a complexity cost - unique native platform UI code is still unique native code, plus all the localisation, QA testing, etc, etc fun that will entail for an app the size of Slack.

Facebook shares a huge chunk of core code between Android and iOS with C++. Even with Electron, VS Code also writes a lot of the core modules in C++. At the end of the day, it's just a clever way to write performant code that can be shared.

> Do people still regularly try to ship common platform code as a shared C++ library to minimise unique code bases for their mobile apps?

I think Microsoft Office does this too, and I’m pretty pleased with the results, performance and UI wise. In my opinion, this is probably the best way to actually do decent cross-platform development. One of the projects that I am tangentially involved in is doing this, but swapping out C++ with Rust.

> I recall reading years ago Dropbox trying this

Last I heard, Dropbox has moved towards using Python for everything, which gives them kinda horrible performance IMO.

> I can see why it might potentially be attractive in purely architectural terms, but I wonder if the “savings” meaningfully materialise in practice when so little pure native development occurs in C++ on iOS and Android.

Generally, all the cross-platform, UI independent bits go into the framework, and then you write a thin UI layer on top of it using your platform’s native UI APIs. The benefit of using C++ is that you can call it easily from most languages.

> Regardless, there’s still a complexity cost - unique native platform UI code is still unique native code, plus all the localisation, QA testing, etc, etc fun that will entail for an app the size of Slack.

Ok, sure, but most of this work has already been done for their iOS app. I’m making a shot in the dark here, but I’d think that given access to their iOS project I could whip up something passable within a couple of months, if not less.

> Last I heard, Dropbox has moved towards using Python for everything, which gives them kinda horrible performance IMO.

The opposite is the case. New components are typically written in Go on the backend, Rust in the sync engine and the respective native toolchains on mobile platforms.

I haven’t used Dropbox in a while, so I’ll have to take a look at it sometime. Is Dropbox back to using Cocoa again?

I was tech lead for a project that did this, about 7 years ago. C and C++ for all the business logic and core functionality. Objective-C, Java, and Qt for native bits. Worked great and was the obvious solution that allowed for shared code. I don’t see why you wouldn’t do the same thing today. The capability is still there.

I’ve lived through decades of promises of “write once run everywhere” development technologies but they have always come with significant drawbacks vs native applications. Performance, memory footprint, native look and feel, ability to take advantage of os specifics.

> WKWebView uses _basically_ the same amount of memory give-or-take a few MBs as Chromium

It really doesn’t. A “Hello, World” WKWebView is a couple of megabytes. The same in an Electron app is hundreds of megabytes.

This is a useless comparison. Once you're hosting an actual app, the content matters way more.

Messages uses webviews and manages to do much of what Slack does with a tenth of the memory footprint. I still have not found any evidence for your claim that Electron and WKWebView use the same amount of memory.

You're literally comparing two completely different apps. If you want to compare Apples to Apples, host 5 teams in Slack, in both Chromium and WKWebView

What if I only have one team and a handful of channels, though? In that case I prefer starting with a lower constant memory overhead.

calm down friend

No personal swipes on HN, please.

There is of course value in comparing Messages-the-HTML-app to Slack-the-HTML-app. If they can do it in a fraction of the memory with comparable functionality, I wonder why Slack can't

Unfortunately, I’m in a place where I can test your argument, so the best evidence I can give you is the personal anecdote that I run Slack in Safari rather than using the Electron app for performance reasons. It’s not quite WKWebView, but I think it’s a relatively decent approximation. With that said, I still think you’re missing the point: it’s completely possible to make a messaging app that uses significantly less memory than Slack does and does basically the same things, even if you ditch native controls (which is not something I prefer people do, for reasons other than performance, but it’s something I am willing to tolerate). Loading an entire browser with its associated baggage rather than using the platform’s native web view will almost always use more resources, because you will have bloat that is not necessary for what you are doing and some features will end up being reimplemented in Electron. Just because Slack might perform poorly in both a web view and Electron (which I still believe is not equally poorly), does not mean that it could not perform well at all. There are multiple issues here.

Here's a simple comparison using nativefier (electron based single-site-browsers) vs something using WKWebView:

https://imgur.com/oG2Dm5y

Both are playing low-quality HTML5 video.

For any sites I could think of, the memory usage, thread count, CPU time, and idle wake ups were considerably smaller using WKWebView.

The disk usage was also crazy smaller, as is expected. ~122MB for nativefier vs ~14MB for WKWebView (and a lot of that is due to being written in Swift).

Even if memory usage is the same, there's a world of a difference when it comes to executable size, and for most Electron apps, I doubt the content will outweigh the runtime.

I don't find disk space worth optimizing for in 2018. For $2 you can buy a USB Thumbdrive that will hold every Electron app you'll ever use.

It's opinions like this that cause first day downloads for new games like Red Dead Redemption 2 to be 55GBs.

In the case of an Electron app disk space might not matter as much, but it's absolutely worth optimizing in 2018, at least because not everyone has high speed connections (e.g. in Germany, a lot of infrastructure is built around DSL, which obviously doesn't get great speeds).

You’re comparing apples to oranges.

3D models vs. app code.

You will be hard pressed to find any Electron app that exceeds 200 MB in disk space. Most are ~50 MB. Overall in 2018 that is not a big concern.

In gaming, high definition graphics are going to result in massively larger files. That’s not going to change anytime soon and no gaming company will prioritize a small download over better graphics.

Yes I know, and the size of an Electron app versus a AAA game is sometimes 3 orders of magnitude in difference, which is why I pointed out that even a "small" app that's 100MB is still a lot to download on a limited speed connection.

> You will be hard pressed to find any Electron app that exceeds 200 MB in disk space. Most are ~50 MB.

Huh? Looking at my applications folder right now:

Atom 1.31: 822mb

Daedalus 0.8: 265mb

Mist 0.9.2: 186mb

Neon 0.0.7: 180mb

Patchwork: 185mb

Riot 0.11.4: 160mb

VS Code: 193mb

The electron framework alone is 117mb on MacOS. Honestly, how many copies of that do I need?

I don't understand why apps don't download an Electron runtime on launch and store it in a shared location. That way, if apps share a required runtime version, only one copy of that version runtime exists.

carlo by Google Chrome team

https://github.com/GoogleChromeLabs/carlo

If you have 20 such apps, you use 1% of your 250gb SSD (which is on the way low end) on redundant framework copies, with the benefit that the developer gets to test on the version of Electron you are running.

50MB isn't a big of a concern until you realize high quality native app would do it in less than 5 and probably in less than 5% of RAM usage

>It's opinions like this that cause first day downloads for new games like Red Dead Redemption 2 to be 55GBs.

RDR2's size comes from media files (high-resolution textures, models, audio).

Pray-tell, what magic compression technique would you use to do better AND still support 4K textures?

> Pray-tell, what magic compression technique would you use to do better AND still support 4K textures?

How about downloading textures and movies on demand in the background when you enter new areas? It's not like all that stuff is required for the game to start.

Given 55GB of data and the internet speed the average person has, the fact that most users will ultimately need to load most data, and the fact that a huge mass of users will need the data on day one this seems like a bad strategy.

A lot of space in some recent games, truly a bizarre amount has been in some cases dedicated to uncompressed audio.

Given that most people can't tell the difference between high grade mp3 and uncompressed it seems likely that this could be something like mp3.

I suspected you meant lossless, but no, Titanfall literally did include 35GB of uncompressed audio. Their reason was to lower the CPU overhead from decompression, which sounds like nonsense to me.

tbh I'd use configurable installer: download only these assets you'll be using at worst case allow us to set up everything with full version installed and then cleanup

Sure. For the price of increased complexity, you can get something going (and in fact some games do do that, e.g. WoW), but to be clear, you're still downloading 55GB of assets. The game isn't actually any smaller, which is what OP was complaining about.

Also, this is why the big console makers are investing in cloud-consoles.

Hey, that's not fair to RDR2! I actually bought it the day it came out because it _didn't_ have a huge day one patch. I think it was only about 4 GB, which is barely a blip on my ISP's arbitrary data cap. Fallout 76, however, had a patch that was larger than the disc itself, so that was an easy "pass" for me.

Edit: I just checked, and even now that they've added multiplayer to the game (which didn't come on the physical disk), the patch for a new installation of RDR2 is 8 GB. Meanwhile, Fallout 76 is 50 GB and COD:BO4 is 65 GB.

Ridiculous. I have a 256 GB hard drive, which is pretty common even on new machines. I’m constantly having to delete stuff to make sure I don’t run out of room. It’s absolutely an issue.

I'm hoping you have a 256 GB ssd. In any case lots of bad stuff is common and hoping the universe changes seems like a bad strategy seeing as a 500GB ssd is about $85 and a 500GB hd is like $30.

If you want more future proof a 1TB ssd can be found for around $150.

Unless you're on an Apple laptop. There's no upgrading of the components. And before the "you made the choice" guys start chiming in, some people didn't make that choice. If IT says "Dude, you're getting an Apple", then it is what it is. Just because "hard drives are cheap" is not an excuse to ship bloated software. At some point, the app has the features it is meant to have. At that point, it is a good time to refactor bloated code before proceeding to new features. The bloat will just continue, and eventually cause issues that come to a head.

Sure, but the issue there is the poor value offered by Macs (not hating on Mac, I also use one, but bang for your buck is absurdly low). If you have a non-Mac then you likely have a decent sized hard drive. While electron resource use is not ideal, on modern hardware it really shouldn’t be the issue that it’s being made out to be.

On the practical side, why not do as gp suggests and use an external drive? You’ll likely need additional storage with any of the lower spec’d Macs anyway, electron or not.

Of course I use external storage. USBC->SATA SSD has been amazing. Would love to be able to get a USBC->M.2 for the speed difference. Non-techy people that buy Apple might not though, and they're the ones installing stuff with little concern. It's easy to lose sight of the avg user.

single electron app is not an issue, especially high(ish) quality one (I'm positively surprised by low resource usage of messenger for desktop, I know it loads webapp from the web so local space usage isn't that big but RAM usage is also surprisingly low)

but if you have dozens of these it becomes a struggle even for high end desktops

Since when can you not upgrade the ssd on an apple laptop?

As of the touchbar version, they’re now soldered on.

Excuse me while I laugh my ass off. Looking at the 15" pro with touchbar to name one model it starts at about $2400 with no upgrades. An upgrade to 512 can be had for $200.

In order to be in your position your company had to simultaneously overpay AND underpay. How can you be so cost conscious that you say nah give them the tiny ssd it costs less while shelling out 2400+ per unit

You’re talking to the wrong guy buddy.

That got a downvote? For telling the other guy he was addressing the wrong user. Ha, it's actually funny.

Why are you blaming us as users for a decision made beyond our control? Yes, we "get it" already, Apple is overpriced. I'm really happy for you that you get to decide what gear you use. Rubbing it other peoples faces really makes it better, so thanks for that.

I'm not blaming you just laughing at the absurdity of the matter not you personally.

Funny way of putting it, yet so true. My employer decided (without asking me) to get me one with 128GB storage. IN 2018!

the moment IT guy tells me that I respond with the letter of resignation

actually I'd do the same with any netbook, but being limited additionally by the OS is even worse

either I get the proper tools or refuse to struggle

That's a bold statement. Especially without knowing the full set of facts. In this case, with your stance, you'd be the only computer in the place not on an Apple device. It's a small video/photography shop. Everyone involved uses a Mac including the freelance guys that get hired.

What exactly are proper tools? I'm designing a set of web-based tools to help their day to day operations. Lots of shell scripting and what not to just allow people to drag-n-drop and automagically get things to happen, consistently. Are you saying that the proper tool to write php/css/js/shell scripts/etc can only be found not on a Mac? I have found the world becomes a much easier place to live in if/when you can just accept what is on hand and get the job done. Could it be better? Possibly. Is this my favorite laptop? Nope. Can I do what I've been tasked with to get it done? Absolutely. I'm actually quite thankful that I'm not a one trick pony and I can use pretty much any OS put in front of me.

I can use mac if I'm forced to do but my sanity is worth more than some extra money I can get doing so

and seriously, using slow and noisy machine with poor multitasking and overall terrible UX WILL slow me down considerably, it's not worth it also for employer

and you know what? I've done it before already and been the happy guy in the office laughing at all the trouble people forced to use macs had

EDIT: ofc if I'd know beforehand that mac is the only option I simply wouldn't apply to that place, there's no reason to make your own work lower quality

Meh, I have an SSD of similar space, and the only stuff I ever have to delete is old Xcode-related data that refuses to go away. Periodically, some Rust build-related stuff I guess.

The litany of Electron apps don't even come close to being an issue (I arguably have more than the average person, too, thanks to every stupid crypto wallet from the past few years).

tl;dr you're making a mountain out of a molehill.

You assume that how you use a computer is how everyone uses one. Your molehill might be someone else’s mountain.

Mmmm no, this isn't really in line with my comment at all.

There is a long history of sophisticated applications being written in less than a hundred megabytes, so where's the budget going? Hero images?

You made the original claim. Do you have any data to back it up?

...ugly bridging code in Objective-C. I have had a similar issue getting the Unity team at work to use native plugins but they’re inability to be comfortable with C++ is not an issue with the platform but with the programmer. Moreover, the ugliness of the code is definitely a quality of the programmer!

Why doesn’t Slack write an actual Mac app in Swift? For small companies with limited resources, I understand the attraction of “cross platform,” but it would seem that performance and uasability would be vastly improved by writing actual native applications — especially for a billion dollar company that can afford to do it and especially since Slack is one of those apps that is constantly open and performance and efficiency have a real benefit.

They've cornered the market and don't have to care anymore.

A lot of Slack's audience is captive - employees, contributors to open source projects that chose Slack as their social outlet, etc.

The only way this will change is if Apple starts using more "stick" approaches. Marzipan and whatever other technologies they're working on are the "carrot".

Amen. “Cross-platform UI” has always meant “doesn’t work well.”

Yeah at this point they are basically jerks for not building something better. The reality is they dont have to care.

Telegram, an Open Sources IM, has Native Clients on Mac, iOS, Windows, and Android.

Do you all have any plans to test out flutter with desktop embeddings? I see that the productivity is as fast as javascript based stack. Flutter desktop seems to be consuming way less RAM than an electron app. Is there any POC ongoing at slack?

Edit: Never mind, I misunderstood.

This quote was inside a list of negative experiences with WKWebView. It wasn’t intended to be positive.

Huh, I think I got confused when reading it, thanks.

Reply on news.ycombinator.com