I am expecting that they'll rewrite it into a proper native desktop client. :( Anyway, I'll just use the browser version.
When a rewrite isn’t: rebuilding Slack on the desktop
311–320 of 408 posts
Re: When a rewrite isn’t: rebuilding Slack on the desktop
#312Earlier quoted context omitted.
A lot of people are saying that the new-but-not-really-new React Context API and useReducer hooks are sufficient to cover redux. My team isn't convinced, we see immense value because we're big fans of using Redux Saga-- a model that isn't well covered using Context or hooks, although we do use those APIs as well when needed.
Suspense for data loading seems to cover that side of things quite well in the experiments I've tried with the current API. I use Sagas as well though, and Ive found them ok...really easy to test but feel very heavyweight and clunky; personally, I don't _really_ like the loading/error state to be handled by Redux: the more years I work on React/Redux app the more I prefer for a section of an app to be mounted -> trig…
That's what I've been trending toward as well.
There's a tremendous amount of work out there for how to get redux to completely handle async and branching methods, and I think the best solution for most cases is to not have it handle any of that.
Keep your data fetching in normal everyday functions, have react components call those and funnel the data you need in the global store back to redux, and then have the components that need that data read it from the global store.
Re: When a rewrite isn’t: rebuilding Slack on the desktop
#313Is it still an Electron app? The only reason for using Electron is surely because you don't have the manpower to develop a proper native app. But then how have you got the manpower for a rewrite?!
The post shows a wireframe that says it is still an Electron app, which blows my mind because the last language anyone should use to build a native app is JavaScript.
Re: When a rewrite isn’t: rebuilding Slack on the desktop
#314[deleted]
Re: When a rewrite isn’t: rebuilding Slack on the desktop
#315Earlier quoted context omitted.
What is the goto for web if Redux is dead? I am not super knowledgeable about all the exact architectures, but I thought mobile was just starting to adopt the redux architecture vs MVP, MVVM, etc
A lot of people are saying that the new-but-not-really-new React Context API and useReducer hooks are sufficient to cover redux. My team isn't convinced, we see immense value because we're big fans of using Redux Saga-- a model that isn't well covered using Context or hooks, although we do use those APIs as well when needed.
I think once you grok sagas, they're very difficult to replace. I think it's such a neat mental model to be able to dispatch global actions and having async tasks able to respond. I think it leads to nicer decoupling in components between UI & data.
Re: When a rewrite isn’t: rebuilding Slack on the desktop
#316I was so hoping that they had dropped Electron.. but nope. At least they’re focusing on performance, but the achilles heel will always be there. That said, as much as I dislike Electron, Microsoft has done a fine job with VSCode, so there are ways to do Electron “better”, even if the “best” Electron apps are still mediocre compared to native apps
> Microsoft has done a fine job with VSCode
Microsoft has done a fine job with VS Code considering it is built on Electron, but it's a freaking text editor ffs! It has basically zero need for a UI. If this were 1990 and there were no cross-platform filesystem, i/o, network, async, etc. APIs available for native applications, it might make sense. But a text editor is basically the very simplest cross-platform UI you could ever need to design (proper text metrics and rendering is the only gotcha, but if you just shell out to freetype and DirectX rather than doing it all yourself, it's not really a problem).
VS Code is only fast because people compare it to the likes of Atom (which has thankfully dwindled in usage), GMail, and Slack. It doesn't hold a candle to the responsiveness of, say, basic native text editors like Notepad or Text Edit.app, or even horribly written "native" software like Notepad++ back in its heyday (although they might have cleaned up that mess in the decade and a half since I last used it -- I see Scintilla has switched to C++17!). Sublime Text was originally written by just one person and doesn't use a pre-packaged cross-platform editor widget, yet Skinner managed to do it without bundling in the kitchen sink and it shows.
Microsoft has realized this of course, and since the initial release VS Code has shied away from actually using Electron and many features are not implemented as HTML elements/nodes and instead are written bypassing the abstraction entirely because it's literally not possible to get the sort of responsiveness users (sometimes, incredibly meekly and never if they have to actually pay something for it) demand from a code editor if you have to go through Chrome/Chromium's abstractions to do it.
Re: When a rewrite isn’t: rebuilding Slack on the desktop
#317Creating native Slack client with the same features as current is not trivial. Just think all the apps, their embedded UI, voice/video calls.
Likely the only reasoble way to have all this and keep it compatible with the browser version is to either build on browser or embed a browser in the native app.
You can argue that all those things are not needed in a group chat, but Slack clearly feels otherwise. They are building a platform, some sort of groupware - not just chat.
Check for example the Doodle bot demo: https://slack.com/apps/AFA5VQJKX-doodle-bot
Re: When a rewrite isn’t: rebuilding Slack on the desktop
#318Creating native Slack client with the same features as current is not trivial. Just think all the apps, their embedded UI, voice/video calls. Likely the only reasoble way to have all this and keep it compatible with the browser version is to either build on browser or embed a browser in the native app. You can argue that all those things are not needed in a group chat, but Slack clearly feels otherwise. They are buil…
Well, that's the problem. It does too much, poorly.
Re: When a rewrite isn’t: rebuilding Slack on the desktop
#319Earlier quoted context omitted.
The fact that nobody's gone out on their own and built a native client means at least one of four things is true: 1. Slack is too restrictive, and its API is too poorly supported for anyone to create a port. I find this unlikely, given that the API is extensively documented and that an Emacs port already exists, but maybe there are problems I'm not aware of. 2. Good native ports are actually a lot harder to build and…
> 4. A few good, Open Source native ports already exist, and people are just unaware of them. Native GUI clients: - Ripcord: https://cancel.fm/ripcord/ - Wey: https://github.com/yue/wey ("written in Node.js with native UI powered by the Yue library") - Volt: https://volt-app.com IRC bridges (allow using Slack from native IRC clients): - wee-slack: https://github.com/wee-slack/wee-slack - irc-slack: https://github.com…
To be fair, if you want it to be that pretty you will have to either reinvent two-thirds of a browser or half a game engine. There's a reason "rich UI"s are a pain to build compared to native GUIs (MSFT Xaml is more similar to a web browser than traditional winforms-style UI).
The best compromise right now is to aggressively build pretty, heavily themed prebaked designs. Think Material Design, Cupertino etc. so native UI is somewhat good looking too even though it may not be as "rich" as a React one with all the drag and drop animation and flashy trinkets. Feature wise of course there's only marginal improvement to old school Java Swing, but it's certainly easier on the eyes.
Re: When a rewrite isn’t: rebuilding Slack on the desktop
#320It isn't just about memory, though that's a big issue with Electron apps. It's still running probably a couple orders of magnitude more instructions per operation than an equivalent native application.