I'm getting a little sick of the level of entitlement in tech conversations — every firm must adhere perfectly to some set ideals or else the most vocal members in the community turn the conversation into an end-of-the-internet melodrama.
We laud companies that start by doing something small well, yet the second they don't support our platform of choice, it's time to banish them to the hills. (In this case, clearly there are material differences in video chat performance across browsers, or else why would Slack force Chrome support?)
We preach focus, then act appalled when customization feature X stagnates on the backlog.
We castigate businesses that spend investor dollars frivolously, and are then furious when well-funded companies act frugally and choose to make tradeoffs (like, say, only supporting one browser for a feature that doesn't work the same on all browsers, until they can achieve a certain quality threshold.)
I look forward to the day when we collectively accept that companies are groups of humans generally working in earnest to do their best, not some faceless behemoth that responds only to screaming "you're awful, do my feature or I'm leaving and tweeting about it" like some petulant child. Maybe there are cases where that is a reasonable response, but when the volume is always turned up to 11 it's hard to tell the real crises from distractions.
Without the heated tone ("entitlement in tech conversations") there's often no response to a valid complaint.
We only get clear explanations from a company's engineers after a discussion is raised.
> In this case, clearly there are material differences in video chat performance across browsers, or else why would Slack force Chrome support?
I look forward to a post on https://slack.engineering detailing the challenges. I'm not demanding a response, it's just a wish.
My decision to use a product takes certain principles into account; Slack is the kind of product that is often chosen for you by your company/open source project/community. A bit of "entitlement" — not meant as scare quotes, I just don't share the viewpoint – makes sense here, because sometimes you can't just choose not to use it.
In principal, I agree. I'm certain Slack has run the numbers and decided the ROI of implementing cross-browser video calling is lower than whatever else they're investing engineering time into. Sure, they have a lot of capital, but it's a large undertaking. A vocal minority of Twitter users shouldn't sway this.
In practice, it's pretty lame that they've had voice calling for almost two years, and this has never been available in Firefox. We're not talking about old IE here. A basic implementation of voice only calling is not hard to do.
I disagree. If we let little monocultures exist they grow into big monocultures (Windows "monopoly", Facebook "monopoly" etc). I put "monopoly" in scare quotes because they had the de facto high ground rather than being monopolies in the Standard Oil sense.
I've noticed the same thing -- often people refer to the "hive mind" feeling one way or another.
Rather than assuming individuals are just fickle, I think it makes much more sense that individuals are often only vocal about things they disagree with. We as readers don't know those individuals and lump them into our "hive mind" concept, as mistakenly assume that people's minds have changed.
I'm getting a little sick of the level of entitlement in tech conversations
I'd argue it's gotten worse over the last few years, to the point that even questioning the attitude or bringing it up in conversation is frowned upon and heavily argued against.
I bet they are using the money to strengthen their position, with marketing and enterprise penetration through integrations, etc. screenhero acquisition is an example.
If their screenhero acquisition and subsequent integration is any indication of how they're spending their money, color me unimpressed.
edit What I mean is Slack ruined screenhero, which was amazing before they bought it. Slack's screen sharing is among the worst screen sharing tools I've ever used. It is beyond broken. It uses a massive amount of memory and cpu cycles while being too laggy to use for basic text editing. I actively hate it.
Yeah, we pay for Slack for chat and 1:1 voice/video, but all our group meetings at work are using Zoom. Far better experience, and the video quality has been great. Have had a few instances recently where people couldn't join the call and had to re-create the meeting, though.
Building an ecosystem. Slack's a business-- not some initiative to build cross-browser web apps. There's a lot to prioritize. When is the last time you've heard a company avoid Slack due to poor browser support?
Contrary to popular expectations not everything is about profits. Better user experience trumps $$ since once users are there, money will come in - it is literally Slack's business model where they charge for each new user.
Also, while people may feel frustrated about Firefox, I bet they have data showing that users are willing to switch to Chrome for Slack chat or calls when push comes to shove. Otherwise, you bet they would have prioritized this. Data driven development is all about making these kind of tradeoffs.
The main point which I am making is that better user experience trumps everything. As we have seen time and again, once users love your product money will get figured out.
This is starkly different from your opinion above where all you care about is money and why ff doesn't fit into that narrative. Strong companies don't operate or think like that.
The tangent was yours. You set "profit" against "UX" and used "the ability of UX to generate money" as the rationale. From a corporate perspective, "UX" is a tool to generate profit, nothing more.
To get things back on track, Slack feels that supporting video chat for FF is not the most profitable thing it could do with its money factoring in the profit derived from the improved UX. This is different than "they have a quarter of a billion of dollars in investment and they think that's not enough to build voice chat for FF", which is the implication of the post to which I originally responded. Slack's purpose is to make money, not to "build as many video chat apps for as many platforms as possible"--modulo corruption or incompetence, it will only build clients for new platforms if the opportunity value is higher than the value of other opportunities.
Now, if you think that Slack's assessment is wrong and building a FF video chat app is the most profitable thing they could possibly do with their investment, then that's another conversation. I'm going to assume the people who operate the business, who have troves of information about the company and its opportunities, and who are deeply invested in its success are many times more likely than you or I (random Internet strangers) to know where the best opportunities lie, but that's still a separate conversation.
I'm curious why more money equals faster or better software engineering. Didn't we collectively learn from the Mythical Man Month and others that throwing people at a software problem doesn't scale? More engineers on a project increases communication and administrative overhead; the additional overhead and context costs quickly exceeds any productivity gained.
Given this: Why would more money scale, when people - presumably the thing the money would pay for - has already been shown not to scale?
That applies to a single project and a single team.
With much less than a quarter billion dollars you could spin off new companies, "Slack Calls For Firefox Inc." and "Slack Calls For Edge Inc." each with it's own development team dedicated to supporting a given browser, and still not break the bank.
It's just a business choice. It's not they can't, do just don't feel it's worth it.
It shouldn’t be hard to document their API’s and then build a unique team to develop a front end for each browser. With $250M in funding and three major browsers I think it’s reasonable they could support them all that way.
one would hope that if you had skilled upper management sitting on 1B they would be able to invest that in both good engineers, and good builders of teams. and if those people weren't able to be effective to be able to track that and take appropriate action (again, with that giant financial lever).
the screwy part is that effective upper manager needs to have a deep and intuitive notion about software development organizations in order to be able to evaluate statements coming out of software effectively. but thats alot to ask, so they hire a vp eng with a nice sounding resume. that person turns out to not be very effective, and they translate their lack of discernment into a tier of equally useless middle managers. and if by accident a effective engineer gets hired they are completely unable to change things for the better because all the useless padding drowns out their voice.
everyone big company says that they have the resources of a big company but the tactical flexibility and empowerment of a small one. imagine what would you could accomplish were that to be true.
Another reason to dump this fad. I've been using slack for my jobs for years, and it wastes more time than saves. No real work gets done in a chat room, which is what slack is. It's a shame a private, bad experience is so popular now.
Try search for a conversation with someone in a channel about topic X. You can't do it, because there is no context. Search for the keyword or person? Good luck with that. Even then, if you find it, it just scrolls you to that spot, which is terrible UI.
Are our Slack versions different? I use both desktop and browser depending on what machine I'm on at the time, and searching for text snippets or just keywords brings up a side panel with search results and messages in context of when they happened, along with a link that will let me scroll if I chose to the moment in time it happened.
The UX you describe is one I haven't seen in Slack since very early releases.
Yeah, that's my problem. The tiny sidebar is not a great UX. The core problem, I think, is the lack of real threading options. Conversations never really start or end in a chat room, so even if you find the keyword you are looking for, find the start and end of that conversation is very difficult. Mainly because it's usually interspersed with tons of other chats in the channel. I guess you could make tons of channels, but that that bogs you down in having to check them all for stuff you actually care about. :/
I'm sorry if this sounds snarky but a lot of your criticisms of slack so far just don't seem rooted in anything resembling the recency of development within the platform.
Threaded conversations have been supported for a full year now, you have the ability to specify and narrow your searches down to specific rooms by using "in:#general" or by conversation by using "in:@dave", but a plain search will search as best the application can public rooms, private rooms and private messages, and the application does a great job I think telling you exactly where the search results come from, when they happened along with a contextual view of the conversation that happened before and after the search results-giving you the precise context of what was talked about, and allow you to both jump back in time to the moment the keyword appears, and jump back to "Now" very easily.
Again, sorry if this sounds snarky, but I don't think your critiques are really lined up with how Slack has been developed in the last year. Many of your problems have been directly solved.
Nobody uses threads, look at any public slack. They are too difficult and unfriendly to use. The entire idea of a "thread" is broken in the slack ecosystem if you can just post in the channel without starting a new one. It makes no sense.
The fact at that slack has to blog about how to search proves my point, IMO. Gmail doesn't need a post about that. I'm talking about context, which is where search fails, because threads don't work. I can find keywords in slack just fine (which is all the blog post talks about, really). I can't find and save an entire conversation about something important.
:/ I've tried slack and all the shortcuts. It fails as a business tool. Simple email and chatting produces more productivity.
> I've been using slack for my jobs for years, and it wastes more time than saves. No real work gets done in a chat room, which is what slack is.
Speak for yourself. Our DevOps uses it extensively, and gets plenty of work done. It's been a great tool, has saved time, decreased ticket response time, and increased follow up. If we didn't have it, we would have to scramble to find something to replace it.
The only thing Slack provided for the longest time was chat. Essentially it was nothing more than a decent, private IRC implementation. I'm curious what your DevOps team found as a pain point in communication. Were you just using email?
Slack now is a significantly improved tool that we use all the time for everything except large or external video chatting. It's a very nice tool for centralization of alerting, monitoring, etc. We'd find it very hard to move elsewhere as a company.
We started using it when the API was already available, and tied in error alerts from our integration server on day one. We've added a lot more since then, among them jenkins, monitoring thresholds on our AWS instances, etc.
Yeah, we're in a similar boat using it to monitor Jenkins, Datadog, Zendesk, JIRA, and a whole slew of other things aside from chat. It's hard to find a better bang for your buck if your company is bought into the ecosystem.
There's more context if you scroll down in the thread. In my opinion, they should try to support more browsers sooner and build on standards, but I do understand starting with the browser that has the biggest market share to prove out the feature, then expanding from there.
---
"We're afraid our first response may have come off a little more limiting that we meant it — we're focusing on Chrome for our calls support specifically, but that does not mean we have no plans to expand to other browsers in the future!"
---
"Apologies — our initial tweet wasn't as clear as it could have been. We didn't mean to imply that future support for other browsers is off the cards, just that it's not on the cards right now."
> We didn't mean to imply that future support for other browsers is off the cards, just that it's not on the cards right now
If something is not on the cards RIGHT NOW then it doesn't mean "we released this feature on Chrome first and the rest is following", it means "we don't believe in cross browser support (=diversity) unless enough people scream loud enough". A very web damaging attitude in my opinion.
I could push for another discussion medium at my company, but the thing is that I'm connected to a lot of FOSS slacks (elixir, elm, postgresql...). I don't want to give more GB of rams to another client that I'll have to run in //.
I still have my irssi in a tmux terminal when I need it, but it's not a UI I can push over to my teammate (not mentioning the lack of voice call).
Slack somehow did a great job at solving "something", I'm not sure if it was the lack of communication or something else. Sadly, it's taking more and more RAM and stance like not supporting non Chrome makes me even less comfortable using it.
Love and use IRCCloud everyday. Well worth the $5 or whatever to have a truly great IRC client in browser (and it's by far the best on Android). People still ask me why I pay for IRC because it just sounds crazy given the glut of high-quality free software IRC clients but my answer is always just that it's the best and since I spend a lot of my time in IRC I prefer to just pay for the best software/experience.
Users are very attached to avatars, which IRCCloud was lacking last time I checked. Also I don't know if modern IRC supports audio/video calls.
Thinking about it, screensharing is becoming more and more important too. We still use teamviewer, I didn't want to move to slack built in screen sharing in fear of vendor lock-in (we had teamviewer for so long, if we move out, I'd like something a bit more open).
Reminder: IRC works on literally everything, uses kilobytes rather than gigabytes of RAM, and is a widly supported open protocol with many competing implementations.
IRC can also be hosted locally --- so using it to communicate with your coworkers in the same building does not involve sending data out far away into the Internet first, nor does it fail if the Internet connection goes down for whatever reason.
There is also email and mailing lists which have those things. IRC can also have public logging and full text search in a universal client called a web browser.
Mailing lists on their own do not provide ACLs, and the only way to read existing private topic is for somebody to forward you all the messages. Are there existing nodes, that do that automatically for you?
You can use other tools for those features, why do you need a single one? The other ones do it better than Slack, too. Focusing on a single idea and polishing it to a mirror shine is better than a single monolithic product which does everything poorly.
The submitted title, "Slack can't afford to support browsers other than Chrome", broke the HN guidelines by editorializing. The text says nothing about not being able to afford. It may sound the same if you don't look closely, but please do look closely, because even tiny distortions in titles can have large effects on HN discussion.
If you need to paraphrase a title to make it fit, or change it because the original was misleading or linkbait (as https://news.ycombinator.com/newsguidelines.html asks), do it by finding the most representative language in the text itself.
Funny thing is I am aware of another product from a better funded company that doesn't support video chat outside of Chrome...
I am not sure if this is a problem with Slack's attitude or if it's that the overhead for creating a voice/video chat app in browsers besides Chrome is much more substantial...
Has anyone tried to implement a web based video chat in Firefox before? Is it really that challenging?
Folks often ask "what's the problem, why not just have Blink be the only browser engine?"
One important reason is that there's a lot of innovation that happens outside of Blink that will not happen inside Blink. Blink shows no sign of permitting Rust components such as the parallel restyling engine that Gecko uses.
Another issue is that Blink is not designed to be embeddable in other browsers like Safari. The friction of having to maintain multiple "ports" in one codebase was much of the reason for the WebKit/Blink fork to begin with.
This is an opportune moment for me to say thank you to everyone at Mozilla for maintaining and improving Gecko.
That there's a browser as good as the current Firefox is another reason to not lock ourselves into a Blink monoculture.
Of course, even if FF was in a bad state we should try to avoid de-facto standardization of Chrome, but with FF improving with each version, there's a practical, sellable argument for diversity.
We started using Discord and we really like it. It is targeted towards gaming communities (basically to replace TS3, Ventrilo, Mumble etc) but I think it's comparable to Slack too
Our company recently started using Chime [1] it supports Chrome, Firefox and afair Edge, it's quite pleasant to use for video-audio chats in a browser. It uses WSS and WebRTC so it works behind NAT where SIP can't, also it looks like it's a P2P technology so your voice and video traffic doesn't go to central server (I might be wrong about it).
At first I thought you were talking about the Amazon service. It turns out that Amazon has a voice chat service called Chime as well, though it's more narrow of focus than the CafeX system that you are using.
So how much money did google float them for exclusive features. For me it recalls when skype limited the number of participants in calls if you used an AMD processor or limited the resolution unless you purchased specific webcams from partners.
I doubt it. They're built on Electron, they get Chrome support free and probably just don't want to spend any resources on making it work in other browsers because most of their users use the native apps.
I don't think this is an issue specific to Slack. It seems like the trend with nearly all real-time video/voice software. You either use chrome or get the desktop app.
You raise a good point. This conversation would benefit from someone articulating what particular issues are making it hard to support certain features in other browsers.
This is literally the exact argument people made when only supporting IE6 (and remember at that point in history IE was arguably the best browser, warts and all)
WebRTC is somewhat new and complex, and browser support varies greatly. I don't know what kind of unlimited resources behemoth you imagine Slack to be, but I can definitely see how doing consistently working cross-browser WebRTC would be too much effort to be able to pull off at a given time.
Given Slack's desktop app is Electron-based, and the electron renderer is ~chrome [note the tilde!], they may be effectively developing for [web + MacOS + Windows + Linux] without bothering with any other browsers.
”It requires significant effort for us to build out support and triage issues on each browser, so we're focused on providing a great experience in Chrome and our desktop apps. ”
They are not saying they can’t afford it. Money they have, engineering talent tends to be always on short supply. You need to think where you put the effort.
Why should they support browsers that make dramatic, arbitrary changes on a whim? Chrome is the only browser that remains stable. Who knows what Firefox or Edge will look like next year?
Do you have proof that Chrome is the only "stable" browser? Is your standard for stability Chrome, meaning that by definition Chrome is stable and other browsers aren't if they aren't exactly like Chrome?
Look like? In what way does the interface of a browser changing make it more challenging to support as a website? Firefox looks a bit different now to a year ago with Quantum etc, and add-ons are very different, but I can't think of a single website that would be affected by those changes. Can you elaborate on what you're getting at here?
This is a bogus headline. They can't justify the cost of developing video chat for other browsers. The truth is much less interesting than the misleading implications.
NOTE: I posted this comment before the title was corrected by the mods for editorializing.
We laud companies that start by doing something small well, yet the second they don't support our platform of choice, it's time to banish them to the hills. (In this case, clearly there are material differences in video chat performance across browsers, or else why would Slack force Chrome support?)
We preach focus, then act appalled when customization feature X stagnates on the backlog.
We castigate businesses that spend investor dollars frivolously, and are then furious when well-funded companies act frugally and choose to make tradeoffs (like, say, only supporting one browser for a feature that doesn't work the same on all browsers, until they can achieve a certain quality threshold.)
I look forward to the day when we collectively accept that companies are groups of humans generally working in earnest to do their best, not some faceless behemoth that responds only to screaming "you're awful, do my feature or I'm leaving and tweeting about it" like some petulant child. Maybe there are cases where that is a reasonable response, but when the volume is always turned up to 11 it's hard to tell the real crises from distractions.