I say this with sincere respect for all developers, if you feel burdened by cross-browser support (for top browsers), you are definitely doing something wrong. Browser vendors and the open-source community took the significant effort on themselves to achieve near-parity support.

Six years ago, when it was "hard" to support Internet Explorer, @reybango and I would run through dozens of sites each month that "only work in Chrome," only to find that a few small changes brought a near-equal experience in Internet Explorer too. Stop leaving people out.

Regarding @SlackHQ and their decision to only support Chrome-to-Chrome voice-calls, I'd like to remind everybody that Google and Firefox announced interoperability 5 YEARS AGO.

Jonathan .. what I find so odd here is that Slacks desktop app uses electron .... its litterally chrome running. Also, dont forget about web extensions:

Platform I built does do video and audio calls between chrome Firefox iOS and android quite successfully damn it even does on new safari. That doesn't change the fact I see slacks point and most likely apps are the main platforms they care about and web is more of a partner app.

One thing that always bothered me was that those tweaks were never collected into an authoritative, holistic, or searchable resource. The Compat Cookbooks were a good start, but they should've been open sourced on GitHub for everyone to contribute to. (It could still be done.)

Oh, @reybango and I wrote articles showing our approach, and specific issues. More often than not, it was just a matter of doing feature detection, and creating a small branch of alternate logic to handle IE. Standards-first made a huge, huge difference.

Of course now features added to chrome become standards. Which is what Msft got slammed for. 🤔

People whining about how hard it us to do cross browser support get no sympathy from me. No shit. Then write a desktop app instead and you get control.

Building web apps *is* hard. Lots of devices, browsers and bandwidth considerations. It's not a freebie.

"write once, run everywhere" is hard, yo :)

This feels a bit tricky. I assume the problem with slack is they are locked in by being an electron user first. And since brave is too and runs on chrome code only it feels like you’re in a similar position or at least could be.

Obviously this isn’t a problem right now since you all don’t offer any web services but I’m just trying to say that slack probably got here by using chrome as their primary platform which is true for you too. I just get how chrome dominates market share is all ❤️

problem seems to be they jumped on chrome WebRTC implementation long before the standard and haven't kept up (it's specific to voice calls)

It's not @SlackHQ leaving people out but browser vendors not implementing required features fast enough. Many years IE was the most hated browser now I think that pleasure falls onto Safari. Stop moaning about developers not supporting your platform make it better then we will.

Many years ago IE was hated because developers targeted it explicitly. Then open web advocates like @zeldman, @adactio & @mholzschlag & @mozilla helped establish standards to ensure consistent experiences. That’s what @jonathansampson is talking about.

And groups like WASP and folks like my teammate @AaronGustafson worked hard to ensure the web was accessible to all which is actually what the Chrome team wants as well. If you’re targeting one browser you’re doing the web a disservice.

True and totally agree but if only one platform support features you need and want to implement without a hassle of patchwork and writing the code multiple times and have to target platforms for subtle API differences it's more constructive to build on one that has all you need

I'm not saying it didn't get better but there are still many APIs not implemented throughout browsers even not have well working polyfills or none of them at all.

Your comments remind me of the days of past when developers would say the same thing about IE. It's precisely why the open web standards groups came about.

And its brilliant but I don't agree with statement of leaving people out. It's not leaving people out when other platforms can't give the full experience and I totally understand @SlackHQ statement about receiving enhanced experience in chrome over others.

It depends if those enhanced experiences are based on accepted standards or features proposed but not approved of widely (or incorrectly implemented features). If it's the former, then there might be an argument but if it's the latter then I can't agree with your statement.

Well from my own experience of implementing WebRTC conferencing and screen sharing it's in many places those differences that make it still impossible to "write once works everywhere" without being a code gymnast and directly target platforms or write extensive polyfills

All I'm saying is that I understand @SlackHQ choice and don't see as leaving people out. You want them to get full experience.

Having said that my platform works on all top browsers but to get it there wasn't easy.

Glad to hear it. And yes building cross-browser can be challenging. I appreciate you doing that.

Always... But I also understand the choice not to do that. You can't drive Lamborghini without having engine installed 😉

Can you talk in specifics? What would you define as “critical and missing” in cross-browser scenarios?

I did further down the conversation there are certain APIs like WebRTC, WebAudioAPI, WebAnimationAPI which are implemented differently or not at all by different vendors which won't allow for exactly the same experience on all platforms selecting one as your go to... 1/2

Have you looked into Chrome and Firefox's WebRTC stacks? They've been interoperable for half a decade.

Of course I'm working with WebRTC every day. I'm in no way advocating for what slack is doing more of that I understand their decision from business standpoint. And the interop isn't without it's niggles and problems as I encountered a lot.

Isn't the job of a web developer to figure out those niggles and problems? Otherwise, you're not really a web developer. Slack was started by a fan of the Web. Too bad the company isn't acting like it cares about the Web as a platform, only Google as a platform.

Of course it is that's why the platform I am involved in building is doing feature sniffing and support IE10+

What then is your position, Vic? Respectfully, your argument has changed from the start of this thread to now. What part of their decision makes sense?

My position from the beginning was that I didn't believe it was devs conscious decision to lock in. Had no idea it actually was the case. From a business standpoint I understand it you have only one platform to debug one platform consistent throughout the OS-es.

Having experienced myself plethora of issues when developing with WebRTC WebAudioAPI and others I still can understand why they have done it from a business standpoint.

Again, though, Google and Firefox announced interoperability 5 years ago today. To this very day. I can think of no justification for not, at the very least, supporting Firefox. Edge would make sense, with its ORTC support. But not Firefox.

As a web developer I sign with my both hands under your answer there's no reason why they couldn't do feature sniffing. But from a business side as they stated themselves it's not their priority which I also understand and strongly believe that was the case.

That was the same argument that companies (wrongly) made in the early 2000s when the Web was dominated by Microsoft and it was considered reasonable business practices to lock out anyone that wasn't using IE. That was the argument that ceded the Web to Microsoft 15 years ago.

Are you OK with one vendor owning the Web platform?

Working for slack competitor I don't use slack so I don't really care about who owns it. Personally I don't think it's a good choice but I can understand if it's business one. their devs don't deserve backlash for something they probably have no influence over.

Their devs should push back harder against (mis)management. The Web is their platform, not Google.

I don't think it's that easy in a corporate multi billion company I might have completely the wrong idea how they operate. I can understand why they chose chrome and stick to it. If they did only mobile apps I don't think they'd get so much grief for doing only iOS for example.

Of course it's different on native Mobile which requires two entirely different code bases in different languages. On the Web, that's not the case. The Web is a standards-based platform.

True, but business side dictate what's important and sets priorities. In a perfect world it would work everywhere and we wouldn't have this discussion. But @SlackHQ guys in the same thread said it's not priority for them which sounds to me like a business over open web.

A business decision to treat Chrome as if it was the Web.

Are you saying you can't use slack on other browsers?

Not how I want to use Slack. It's feature crippled in Firefox for no good reason.

I have no answer for it really. I wouldn't do that. I'm not sure what led to that decision I assume it's business. I don't think any web developer would lock their platform if feature is consistent and widely supported.

It is a pain though to make stuff work everywhere that somewhat support features you implement

Yeah. The web platform is imperfect. It's still the best thing going, IMO.

I agree it's a good time to be a web dev...

I like a challenge ;)

The Quality Fail of the platform is we forgot one of several core ideals: #interoperability. Despite attempts by many across the world, no baseline curriculum is available anywhere. We self-teach, teach each other, help when we can. It's patchwork, as is every viewport. #browsers

It's a genuine question I haven't used slack since 2015 so I have no idea if they completely locked it in.

I don't want you to get the wrong idea about me I'm not advocating for platform lock in. In my work I've never done it and probably wouldn't do it ever. But I understand if that was a business choice.

As a developer my answer is no. My business side though is not so much of a no but more of "it depends".

And their business decision might be favouring their electron apps over web.

Their electron app [is] web. Their claim is not that you should use their electron app, but that you should use Chrome.

I'm not sure what to think to be quite honest with you. I can see it making sense business wise. One dominant platform to worry about on which their desktop apps are built.

I had no idea that it was their conscious decision to lock in one platform which from @zeldman tweet looks like it was. I can still though understand the business side of it.

Yeah. And they picked the Google platform over the Web platform. A shame.

2/2 get the full benefit of our platform shouldn't be ostricised and its common sense that you'd receive "cut down" version on platforms that don't implement or implement very basic functionality of APIs youcan take full advantage of on chrome or electron for example.

Except in this case, Firefox and Chrome have had interop APIs for about 5 years.

If your platform is meant to be cutting edge it's a very hard job to implement those cutting edge technologies cross browser without some or even substantial sacrifices to the experience of your platform.

Having said that the platform I built does audio and video calls between vendors it supports quite well chrome to Firefox to iOS and Android.

But it was quite hard and it did take substantial amount of research and far more work than supporting one.

Why would you sacrifice your platform to give people sub par experience ? I've been developing a platform for years now where I literally have to target platforms so people get cut down or enhanced experience depending on what their platform support or is able to do.

this is why the 'X is the new IE' meme is bad; the monoculture effect today has different causes & need different approaches

I agree but without being evergreen and only rolling out updates once a year or so when new OS is released is also bad and holds the innovation back as by default we all have to support obsolete or old platforms.

Are you talking about the long dead IE model? Another reason this meme is unhelpful

No this not really has anything to do with IE I accept their limitations. The main issue that I'm having is that somehow it's a bad thing to want people to experience your platform fully and selecting one that'll let your platform flourish and achieve goals reasonably fast.

For browsers. *the web is the platform*. Want to feature a platform? *native apps*

Well but you have to admit that all browser vendors have their own ideas on how standards are implemented otherwise we wouldn't have so many polyfills and code bloat to support them all.

no; polyfills are there as one of the implementation options needed BEFORE proposals become standards

once a standard is agreed browsers should & do implement, albeit on their own timetable; implementation details irrelevant because standard

^^ This. And it also signals that developers should remove the polyfill after testing.

yes, I was getting to 'code bloat is developers who coded early and didn't support wide adoption' ;)

If the platform you are making is using cutting edge tech that is not necessarily well implemented on others. I'm talking from my own experience of doing cross browser web conferencing and audio capture. It felt bad that I had to sacrifice in order to achieve wide support.

And some users because of their browser preference would lose quite significant parts of the platform. All that is avoidable by encouraging people to switch. That's why I completely understand why @SlackHQ is doing.

disagree; the point of this discussion is that devs aren't taking notice of how widely implemented standards are. five YEARS in this case

I'm pretty sure they are perfectly aware of what is available. And I don't believe it was devs decision more of a business one.

devs tend to be the people saying 'oooh, we don't have time to build or test for more than Chrome'

^^ This

Well then that's just poor development team. I still don't believe multi billion dollar company is employing bad developers.

Slack is facing the tension of wanting to be an enterprise vendor without doing dev, test, support on enterprise scales

Having said that platform I built does work on Safari but with some unsupported features disabled.

Web Standards are called that for a reason. I’m still amazed at how few people and companies use the standards and conventions many of us used years ago. Like you said, back when it was difficult.

Although, I still fondly refer to IE as “Internet Exploder”.

Over the din of this pitchfork waving I haven’t heard exactly which APIs @SlackHQ are using in Chrome to make video calls. A lot of people (video) calling them out but maybe they are feature detecting and maybe it is a web standard that FF hasn’t implemented.

My experience from developing a WebRTC video conferencing application does not confirm your statement. Even with open source shims, supporting Firefox in addition to chrome is nearly twice the effort. During development AND testing.

Thats probably right but imho it's part of the job. We need to keep the web open and diverse. You shouldn't force the user to use a specific browser. (Even if i sometimes really wish i could 😂)

The WebRTC site is an addition to our native application, for macOS. We “force” our customers to use macOS when they want to use our software. The same reasoning applies here, and its about feasibility and costs, not about what we think would be “right”.

For the most part i think excluding potential customers isn't the right choice. But if you do cutting edge tech there might be no other way. Most web based apps however do stuff where it is very reasonable to support all major browsers. Exceptions always prove the rule ;)

What about Safari (11) and Edge (15+)? Do they match Chrome, or Firefox, or differ again? Would supporting all four mean 4 times the effort?

Probably not 4 times, no. Haven’t looked into the state of WebRTC in Safari 11 and Edge 15+ since they weren’t out during initial development. Maybe things got better. However, having one browser change its implementation from version to version is hard enough already…

I remember when Chrome and Firefox added WebRTC support. They worked on it together, from the same spec. I’d understand added effort for Edge, and ORTC, but what major issues exist between Chrome and Firefox today?

haven’t checked in the last year TBH. We have very specific requirements regarding camera resolution, noise cancellation etc., that uses vendor-specific media queries. Also: removeTrack was not available in Firefox AFAIK.

Simple audio calls have been working for a long time, but anything more complex needs to handle different SDP formats, for one. Consider, too, different levels of support for RTCDataChannels, BUNDLE, simulcast, bandwidth constraints, and stats.

There definitely are a lot of areas where things can go wrong; my primary point here is that Google and Firefox (the two browsers at the center of this issue) have enjoyed basic support for half a decade. If we were discussing Edge and Chrome, ORTC and RTC, I'd understand.

Has anyone bothered to find out which API's Slack is using for voice calls in Chrome? Are they actually supported in Firefox?

Search for the issue on webcompat.com If there is no issue, create one. Mozilla runs this service to decrease the number of browser compatibility on the web.

Chrome and Firefox launched support for WebRTC at the same time, via a joint effort 5 years ago.

Is that _all_ Slack voice chats depend on? Do we know that for sure?

Honestly, if you can't open a voice-only channel between peers, on a stack that has been interoperable for half a decade, you're still doing something wrong.

this is not between peers, it is between peers and a server. And how to transport multiple streams over a single connection has been subject to fighting for more than half a decade (@adambroach might know how long exactly)

Assuming you mean Unified Plan (rather than, say, Bundle), everyone involved came to a detente on the topic in summer of 2013. It's just taken a while for everyone to get around to implementing. Pressure has been low, since it works fine with one-to-one conversations.

Also, it works fine if you create a new PeerConnection for each pair of participants, which remains a reasonable workaround. The only cases you can't do until everyone implements Unified Plan are kind of esoteric, like having two tightly-synced video streams.

There is no reason @SlackHQ couldn't use the one-peer-connection-per-stream approach, which works with Firefox's standard implementation just as well as it does with Chrome's pre-standard implementation.

also note that 80% of their conversations turned out to be 1:1 where this is not even an issue. Looks like we guarded the "the average meeting has 2.x participants" secret too well!

See Facebook as an example, which supports 1:1 calls with Firefox, but not group calls. Slack instead decided to not support Firefox at all.

If not supporting Firefox was needed to support multi-way calls, then that seems like a pretty rational decision, if I'm understanding correctly. Features for users >> rhetoric about "open web"

Sorry, you're not understanding correctly. There's an easy way to do multi-party calls with Firefox, based on the WebRTC standard. There's an easy way to do multi-party calls with Chrome, based on a non-standard mechanism that Google implemented. [cont.]

And, most importantly, there's a relatively easy way to do multi-party calls that work in both browsers by creating one PeerConnection for each party you're talking to.

Facebook: 1:1 calls between all browsers work & group for Chrome user. Slack: 1:1 & group calls Chrome only. Who’s user win?

I guess it depends on what % of users need group calls, and what % of users use Firefox. But from other responses it seems both may be possible anyway.

Nothing depends here: Firefox user get more features on FB. FB shows 1:1 for all is easy. Is not group calls XOR Firefox support.