191–200 of 408 posts
I will consider this benchmark vindication both for myself and the times I've had to argue as to why Electron isn't the issue, as well as the commentator from many moons ago who worked at Slack, dropped in here and explained why Electron wasn't the problem (rather, poor engineering on Slack's part was), and then was ripped to shreds over it. In fact I'm sure this comment will bring out native fanatics in force. At an…
In their side-by-side memory usage comparison, what the hell is happening on the left at 6 teams that isn't happening at 5 teams and happening at 3 teams that isn't happening at 2 teams? What the is happening on the right at 6 teams that isn't happening at 5 teams?
They're buckets, it's 6 or more teams ("6+") not 6. The only one that doesn't make sense to me is _2 teams_. Unless they had some specific hack to reuse processes for a 2nd team, how can the incremental memory usage of that 2nd team be almost nothing? Thinking about it, though- separate teams were lazily loaded and the usage behaviors of people with different numbers of teams probably varies substantially enough to c…
Earlier quoted context omitted.
The native client they were referring to was mIRC, which does much less than Slack does. A better comparison might be Discord, which performs much better than Slack and is also written in Electron. VSCode, written in Electron, performs much better for me than Visual Studio (a native app), but I wouldn't use that as proof that Electron is faster than native apps because Visual Studio does so much more
The major differences I can think of off the top of my head are threading, reactions, voice chat, and history. Voice chat is the only one that should use significantly more resources than mIRC.
Earlier quoted context omitted.
Too high compared to similarly featured (or even more full featured) programs built on other technologies. 3% on an Electron chat app here, 5% on an Electron text editor there, and pretty soon you’ve managed to replace what could’ve been several apps with small memory footprints plus several gigs of efficient file caching in a users’ RAM with just a few bloated programs crowding out the cache, and made their entire m…
If someone is running so much stuff that an app (or a few apps) using ~250MB of ram instead of ~100MB (or whatever) of ram is a huge problem they can easily spend $200 or so for an extra 8GB of ram. Ram is cheap. Usage at this scale just doesn't matter to the vast majority of users.
Earlier quoted context omitted.
Funny how a google images search for limechat fails to find a single screenshot with inline images. But I'll take your word for it. I guess that settles it. People will dump Slack and Discord on mass and move to the amazing IRC clients like LimeChat which are so much more efficient. it's well known that the number one thing people look at when choosing software is how efficient they are. Nobody cares about looks or f…
If people cared about looks or features, Slack certainly wouldn’t come out on top. No, what people care about are primarily network effects. They'll use whatever someone in the company decided to use (frequently Slack because it’s always been Slack since someone back in 2013 decided it was the hip choice, before it even had a desktop client), and they’ll put up with whatever dogshit client they’re served, because it’…
And what about Discord? It's almost exclusively used by people in their homes, there is no company pushing it down their throats.
I went to get the update on my Mac, and it shows a new version from July 8. The release notes say: "Slack is a little faster, thanks to a few small but important changes". Huh? This seems to be the right update (4.0.0), but on Slack's website the release notes [1] show the release date to be July 15. Is this the same version as I'd get via the Mac update? If so, what's with the press push today (Verge and others), if…
" Conventional wisdom holds that you should never rewrite your code from scratch, and that’s good advice. " Speaking as someone who has done a fair number of rewrites as well as watching rewrites fail, conventional wisdom is somewhat wrong. 1. Do a rewrite. Don't try to add features, just replace the existing functionality. Avoid a moving target. 2. Rewrite the same project. Don't redesign the database schema at the…
There's this classic article on the topic: https://www.joelonsoftware.com/2000/04/06/things-you-should-...
(I think this article should be the new classic.)
> My takeaway from these stories is this: Once you’ve learned enough that there’s a certain distance between the current version of your product and the best version of that product you can imagine, then the right approach is not to replace your software with a new version, but to build something new next to it — without throwing away what you have.
Earlier quoted context omitted.
That's fair; although I'm pretty sure they wouldn't be able to have such a consistent and unique look-and-feel with React Native (you can correct me if I'm wrong). It's debatable whether that's a good tradeoff, but it's totally one that some people would make.
well, consistent with what? If you mean the native Mac/Windows/Linux desktop experience, yes, it's definitely impractical to do that with any size budget. But the current Electron app isn't either. But if you want consistency with the web app, I don't see anything difficult about that. I do wonder if the plugin/extensibility architecture — "Slack Apps" like Github and IMGUR and OpenTable — is the real answer. (Unless…
Earlier quoted context omitted.
Too high compared to similarly featured (or even more full featured) programs built on other technologies. 3% on an Electron chat app here, 5% on an Electron text editor there, and pretty soon you’ve managed to replace what could’ve been several apps with small memory footprints plus several gigs of efficient file caching in a users’ RAM with just a few bloated programs crowding out the cache, and made their entire m…
If someone is running so much stuff that an app (or a few apps) using ~250MB of ram instead of ~100MB (or whatever) of ram is a huge problem they can easily spend $200 or so for an extra 8GB of ram. Ram is cheap. Usage at this scale just doesn't matter to the vast majority of users.
RAM is cheap...and not upgradeable on the majority of devices in the world.
Earlier quoted context omitted.
I’m still skeptical. The memory usage chart from the article shows only a slight (10%?) improvement for single-workspace Slack clients, now at around 250MB. Yes, getting a 5+ workspace client down from ~800+MB to 300MB should be applauded - but the 250MB floor is still too high. I want to know what’s in the 250MB it’s still using.
iTerm2 eats 150mb+. Any cocoa app use that much of memory. App Store is 500mb just after launch.
What gives you that idea? Lots of apps have cruft, but that's nothing to do with Cocoa.
A "Hello, world!" in Cocoa uses around 13 MB, and the application bundle weighs in at 79 kB. The fact that Electron uses a bare minimum of over 100 MB just to get an application running is a source of some understandable consternation.