Nobody has the resources for that. Some companies make OSes, and some companies send rockets to space. Those feats are also powered by thin wrappers over electron. /s
People seem to forget that C++ and opengl is cross-platform. And there are projects far bigger than slack, like ffmpeg and OpenCV that have existed for decades, always had very fast development cycles, with only a subset of the funding and money that Slack has, and stayed native and close to the metal forever.
A better answer would be, that Slack has deemed the benefits that would result from this as not that important. Or that the current team's expertise cannot handle the task. But they always looking into ways of improving the core product and experience.
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.
Slack didn't win because it was better, it won because businesses thought they were better. That's how most business software works: it creates a problem in the customer's mind in such a way as the customer naturally sees the product as the solution.
Slack is successful because of marketing, not technical superiority.
I worked at a small company that used Google Talk for office chat, and us developers complained because it was difficult to have a group conversation with. We started using Discord (we were familiar with it and liked the dark theme) and it caught on and we were quite productive with it. Our business types saw it and decided to "formalize" it, so they picked Slack and rolled it out company wide. Most people actually preferred Discord, but the business types preferred Slack (probably mostly because of marketing), and now we're all using Slack.
Now, Slack also didn't royally screw up as it scaled up (outages were rare and transparently reported), which is a credit to the developers and PR people. That being said, just because something is successful doesn't mean it's good; it could be, but that's tangential to the topic at hand.
Sure, but there are multiple "OpenGL on Metal/Vulkan" projects. Because it's possible to do so without all that much of a performance loss.
OpenGL effectively should die... but it's not going to be in favor of raw Metal/Vulkan, except in rare cases. Most people already use engines that abstract most of that away, and Metal/Vulkan are in basically every way better for those engines.
It is telling that the person arguing in favor of native C/C++ has to use a throwaway account for fear of going against the dominant force of opinion in our industry. We should be able to have these conversations openly without wondering if it makes us less employable.
Fair point. It's a thought that has gone through my head a few times. There are places that want you to conform to whatever it is we call "modern" software development, and I often find myself feeling uncomfortable about expressing an alternate viewpoint.
There's no conspiracy or anything going on here, and you're right it's wrong to assume. That's the general sentiment of what I was trying to say though.
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 maintain than typical HN posters claim.
3. For all everyone complains about Electron, maybe the current app is good enough for pretty much everyone, including the complainers, and those complaints are largely just hot air.
or 4. A few good, Open Source native ports already exist, and people are just unaware of them.
Regardless, the HN crowd is made up of developers who know how to develop things and use experimental software -- most people on here know how to extract a login tokin, and a lot of people on here are willing to put in a lot of effort to solve problems. If there isn't a native port already, there's very likely a good reason for that.
If there isn't a good reason for it, and it's just that somehow nobody on HN has thought to sit down and build a native app yet, then I'd welcome one, I suppose. But obviously I'm not annoyed enough by Slack to do it myself, and I suspect that most other people posting here fall into that category as well.
Most of these clients don't support 100% of Slack's features, aren't as pretty, and are generally not as 'polished' as the official client. But they're also mostly written by individuals in their spare time, as opposed to a team of full-time employees. So no, I don't think that native clients are 'actually a lot harder to build and maintain'.
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.
Maybe on some platforms. I'm a Mac user, so speaking for that platform, AppKit has had built-in animation support for over a decade (and now with Catalyst you can also use UIKit if you want). Drag-and-drop in particular has animations out of the box when using certain built-in widgets – e.g. when you're dragging an item into an NSOutlineView, the existing item at the cursor will slide down to make room for it. (But what in Slack is even draggable? I can't seem to drag to rearrange channels, for instance.)
Exactly my point, OS X has tons of prebuilt designs with knobs for customization. But at the end of the day they can still be built rather quickly. Drag and drop the components in Xcode, tweak a few variables and animations here and there and you have a perfect looking app that is coherent and consistent with the rest of the system. On the other hand, a modern successful SaaS requires hundreds of man hours of work just on design and UI alone. For web, nobody wants consistency. People gets upset if every site looks exactly like bootstrap. Sites have to be styled, branded, made unique. Yet for traditional desktop i.e. not electron, the moment a cross platform native UI library look vaguely off, devs throw a fit. Think Gtk, Qt, Swing etc.
Nice -- I assumed there were at least one or two, didn't know there were so many!
Once Riot and Matrix pick up steam, I suspect the Electron debate will be even less of a real issue, since you can pretty safely build a native client for Matrix and know for sure that nobody on the corporate side is going to get annoyed and tell you stop.
5. how can I make $$$ from spending a few months writing a native client? Slack can cut me off anytime they get annoyed with me. So even if my client is better, they can decide i am a threat and cut me off.
Never build your future on someone else's platform.
I completely agree, but this would fall under point 1 for me.
See Twitter for a good example of where business interests and API stability intersect in negative ways. I would make the point that if you don't trust a business to keep their official API stable, you probably shouldn't be building a community around their tools in the first place, regardless of whether or not they have a native app.
It's absolutely \#1. I tried switching to Riot (Matrix), but the integration with Slack was painful. You can get it to work well, but what's to stop Slack from breaking/changing their API periodically to make your app stop working as reliably?
If I'm going to put my resources into building a client for something, it's not going to be based on some closed source backed that could change at any time, it's going to be based on something open and forkable (worst case scenario, I can just maintain my own backend).
Slack bills itself as a complete solution, not a piece to a larger puzzle, so third party clients and plugins will always take the backseat. Who is going to try to build a serious competitor when they can't really rely on the backend staying consistent?
Building a decent frontend isn't particularly difficult. It's not trivial, but it has been done. For example, Pidgin, while a little ugly (I prefer "functional"), works well and has been around for years. I used weechat and irssi for IRC chat before we switched away from IRC, and it worked really well (didn't see pictures, but I think that's more a feature than anything, and links were more than sufficient).
The problem is that business types prefer hosted, "batteries included" solutions, and those types tend to not be very friendly with third party add-ons. If I end up being able to use Matrix/Riot, maybe I'll try my hand at a native, cross platform client. But until then, I'm not going to throw my effort toward something that can change at any moment.
I use weeslack and matterbridge.
Weeslack is a python plugin for the irc client weechat.
Matterbridge syncs slack channels with other services like telegram and irc.
I was also a little confused about this, because I vaguely remember slack locking down its API, and people complaining of the resulting inability for switching to a different, and possibly more efficiently implemented, UI
can't comment on the original comment you made here https://news.ycombinator.com/item?id=20500181 because it's now flagged, so commenting here to state: There is a deafening irony in deplatforming a post arguing against deplatforming as a valid tactic. I hope it is not lost on the HN mods. ;)
Bringing ideological battle into completely unrelated threads is definitely not ok. Please don't do this again. We want less ideological battle on HN, not more.
It's not an "ideological battle" if it's empirical (based on evidence and rational discourse).
The only "ideological battles" are religious in nature. I'm fine with keeping religion off HN, but you can't just call a contentious topic "ideological", especially if there is evidence and/or rational debate to be had. The fact that an insufficient number of people opt-in to discussing some topic in that way does not make it "ideological". Would you also consider conversation about climate change "ideological" and thus unworthy of HN?
In any event, the original post (interestingly) got unflagged, so this was superfluous anyway.
No matter the available resources, maintaining three separate desktop apps as well as a web app would mean fewer features and more bugs across the board. And Linux would probably be left on Electron (with less support attention), if not abandoned altogether.
Pretty sure we crossed the Rubicon in the other direction, as it was basically the popularity of Electron apps that forced Microsoft to abandon their own browser rendering engine in favor of Chromium.
If you had come to me 10 years ago and said "Microsoft will drop their browser and use Google's code," I absolutely would not have believed you.
What I've noticed is that much of the distaste with Electron apps has more to do with the idea of waste than with the actual practical implications. Programmers like things to be efficient and optimized. Electron sacrifices those traits in a couple of ways, in favor of actual productivity.
So "the downsides of Electron outweigh the downsides of native apps" when you're someone who patrols the task manager looking for things to be upset about. Your chat client - one of half a dozen applications you realistically have open - using 400MB of RAM on your 32GB workstation does not have a meaningful impact on your workflow. It's just offensive.
I think it definitely depends on your use-case. Like you wrote, if everything else you have open also churns through battery life, it's unlikely having Slack open will make a difference.
However, if your other applications are a terminal, other efficient text editor (e.g. Sublime), and other generally respectful apps, I've found having Slack open is the difference between having enough battery life to work all day, and not.
But that is just one one electron app. Imagine that every desktop app you use is written in electron. I am pretty sure that even 32GB workstation would be stretched to the limits.
32GB workstations are the exception, not the norm. I'd wager most people are using Slack from computers with 8GB RAM (e.g. every 13 inch Macbook Pro that isn't built to order) and at least one browser open at all times.
(I'm not against web APIs as a platform for desktop apps, but I'm happier using Webkit wrappers and I think this would be improved, cross-platform, if Chrome could effectively host the apps that currently ship with their own instance of Electron or CEF)
That's nice for them, but no matter what OS you're on the desktop client is probably crappier than loading up the webpage, with the one upside of giving you a separate icon in the dock and app switcher.
Even with the performance improved, the "stuff the whole app in one web view" implementation is still showing. Clearly this isn't an Electron limitation; VS Code handles multiple windows just as well as any other text editor.
Slack's desktop client is basically "It's a web browser except worse and with the URL bar hidden." Since chat requires an internet connection and it's not like Slack's desktop version launches particularly fast, I'm not sure that it does anything better than using a browser.
We'll see if they support multiple instances on iOS 13. If they do, maybe we can get a Mac version based on that for something closer to native desktop behavior.
You're right, I, a user, don't perceive any of the upsides.
The upside that keeps getting paraded around is that it's a huge boon for product velocity. But that's just objectively false because Slack-the-product hasn't meaningfully changed in years.
React Native isn't a zero-effort way to port a web app to a native app. It lets you share code where it makes sense, but you're still maintaining separate applications targeting different platforms that each have their own quirks and needs. It's similar to how you can't just port a regular native desktop app by using a different compiler; your business logic may be compatible, but you'll still have to do legwork on top of it.
I'm just saying that "native client" doesn't necessarily mean separate Mac, Windows and Linux ports; furthermore, for a billion dollar company, a native client of _some_ kind isn't an unrealistic demand.
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 I'm mistake and these run on the native mobile apps.)
No company has infinite resources. Maintaining native mac and windows apps to appease the few people who have an irrational hatred of electron doesn't make good business sense when those resources could be going work that actually improves their product in a meaningful way.
Slack is the only web-app I’ve seen that routinely triggers the safari warning about its resource usage/affect on performance.
For years slack has been a resource pig on desktop and on the web. So what improvements are you imagining they’ve been working on? Chatting on the internet is hardly such a groundbreaking subject that it can’t be done efficiently.
Chat apps have been around for literally decades. There’s plenty of prior and current competing apps that do essentially the same thing and use a fraction of the resources.
Very few prior apps did what Slack is doing [1] And there are not that many actual competitors if you start counting them.
[1] It's still strange to me that many people compare Slack to IRC and XMPP and complain that they were doing all the same things, why have people abandoned them. Even though they (and especially the clients) were doing (or capable of doing) just a small fraction of what Slack is doing.
there's also web-based chat apps that use next-to-no resources. If slack's webapp is so heavy, what makes you think a native app from the same company would be considerably better?
As much as I'd love a native app, for a fast moving company with rolling releases it's probably very hard to keep three platforms at the same level especially if you want to do experiments too or roll out features to a small subset.
Name three major feature improvements to Slack in the last three years.
I can think of one, threads, which are a fucking usability disaster and should have been killed immediately. I can't think of a single other major feature.
Why would they do it? I want a native Slack app, but they have no incentive to do so. Look at where Slack has grown with their current app and ecosystem. I’ve never heard a single company say they’re moving to Microsoft chat because of Electron, or going back to IRC.
It seems Slack has addressed the major issue with their current app with this rewrite — multiple workspaces.
People seem to forget that C++ and opengl is cross-platform. And there are projects far bigger than slack, like ffmpeg and OpenCV that have existed for decades, always had very fast development cycles, with only a subset of the funding and money that Slack has, and stayed native and close to the metal forever.
A better answer would be, that Slack has deemed the benefits that would result from this as not that important. Or that the current team's expertise cannot handle the task. But they always looking into ways of improving the core product and experience.