With all this amount of profit and market share they should be more eco friendly and write a native client instead.
When a rewrite isn’t: rebuilding Slack on the desktop
221–230 of 408 posts
Re: When a rewrite isn’t: rebuilding Slack on the desktop
#222Earlier quoted context omitted.
I never heard of ripcord. I just downloaded it and gave it a try. It suffers the same problems as every single native (non-electron) chat client I've ever used. Primarily it's hideous and you can't change the UI size uniformly. As an older dev who's eye sight isn't as good as it was 30 years ago when I started, it's getting harder and harder to use native apps because the default fonts are so goddamn small. Oh sure,…
You can set `QT_SCALE_FACTOR=2` (or whatever) as an environment variable and the entire UI will scale. But by default, it should be trying to use your desktop scaling and DPI settings -- you might want to try changing those, first.
I'm using a mac. QT_SCALE_FACTOR doesn't really help, and most of Apple's native apps are actually sized appropriately. It's everything else that's a problem.
Honestly, I think it's an accessibility issue. Most devs are simply used to the small GUIs, so that's what they build. They don't give it any real thought or put any actual design effort into it. It's the same with accessibility, it's not my problem so it's not a problem. And while native GUI's help with some aspects of accessibility, they don't provide the tools to make scaling easy and obvious so it doesn't happen.
And that's why people throw fits about software being inaccessible, because it's literally unusable for them. I'm lucky, I just want everything to be 20% bigger by default because it makes my life a little easier. Others don't have that luxury. That 20% can be the difference between being able to use your software or not.
Re: When a rewrite isn’t: rebuilding Slack on the desktop
#223Earlier quoted context omitted.
It’s little more than a simple IRC client that consumes 250-500 megs of RAM. I wouldn’t take any victory laps over the supposed “efficiency” of Electron here.
Yeah, and a Rolls Royce is little more than a Honda with worse miles per gallon.
You say this like I should prefer a Rolls Royce to a Honda.
Re: When a rewrite isn’t: rebuilding Slack on the desktop
#224Earlier quoted context omitted.
Teams is winning because it's being bundled with Office 365. The business model and distribution lets them compete effectively with an inferior product. Slack doesn't have that luxury.
Teams is so inferior I'm not sure they compete for the same market, when team chat become really important Teams is just not an acceptable option in my experience (we had to switch away from Teams last year because there was too many bugs/frustrating issues and basic features missing, like a actually usable search feature).
its about momentum though too. your point in time experience is quite different than the trajectory/velocity of the product, and its rate of change.
Re: When a rewrite isn’t: rebuilding Slack on the desktop
#225Could someone please explain to me why a publicly traded company can’t write an actual, native Mac (or Windows/Linux) client instead of force feeding the lowest common denominator approach of React “native?” Imagine the performance and UI improvements of Slack could write a Swift app using standard Mac/iOS conventions. React “native” can be a treat approach for resource constrained organizations, but there is little excuse for a big tech company to shortcut using pseudo-native cross-platform approaches. For what Slack is, it’s still terrible when it comes to efficiency and stability. It’s lazy.
Re: When a rewrite isn’t: rebuilding Slack on the desktop
#226" 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…
Re #2 - sometimes the code isn't all the problem, but it is the schema - and the two can be intertwined in such a way that you can't fix one without fixing the other.
Re: When a rewrite isn’t: rebuilding Slack on the desktop
#227Earlier quoted context omitted.
The performance and resource usage of slack both on the desktop and in a browser indicates that “front end code” is not their strength.
Creating a web app with a multi-billion dollar valuation indicates it is their strength. Who cares about a little superfluous memory usage compared to that.
Drilling and refining fossil fuels are BP's strengths, who cares about a little oil spilling into the environment?
Can you see how maybe other people might have valid concerns about the effects of a product, and ask for more rigor in the company's processes?
Re: When a rewrite isn’t: rebuilding Slack on the desktop
#228Earlier quoted context omitted.
Just because you don't see the browser it doesn't mean it's not still there. No, js/html "applications" are not desktop apps, they're web pages. Doesn't matter how you hide it.
If an app is running on its own and not in a web browser, it is a desktop app. The language or framework it is written in does not matter. Do you consider VS Code a web page as well? What about Spotify?
If you don't see the browser it doesn't mean it isn't there. There's always some chrome instance rendering the html and interpreting the js. Extremely wasteful. (Right now Slack seems to use 600 MB ram on my desktop).
And yes, VS code is a web site by my definition. Not an application.
Re: When a rewrite isn’t: rebuilding Slack on the desktop
#229I 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…
The changes that made it faster and use fewer resources have been incremental for the last year. This is just the last of the modernization updates that has completely removed the last of the original architecture's source code
Thanks for the additional background. So will this release improve performance much for those who have the prior update?
Re: When a rewrite isn’t: rebuilding Slack on the desktop
#230" 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…
3) is usually the only way to go if something has a little bit of history and complexity. It’s almost impossible to capture all features and uses of a system completely and then deliver something that does all of these things. Much better to work in small increments which can be understood. It may take longer and feel less heroic but at least you always have something that works.