
You have turned Google Chrome into IE - edgarvaldes
https://twitter.com/ramsey/status/1304642404419538944
======
jlarocco
I won't reply on Twitter, but the first response I see is: "You're attacking a
website that only supports Chrome because it is the _only browser that
supports the API that its entire product is based around_ "

Kind of misses the point, because the same thing could have been said for
every "IE Only" website back in the day. Microsoft was notorious for "Embrace,
Extend, Extinguish," and a lot of the incompatibility back then was them
Extending the web with things like ActiveX.

The only real difference now is that Google effectively took over the web
standards bodies, so they can point to the W3C and say, "But this is
standard!" and conveniently not mention that they were the one who wrote the
"standard" and forced it through the standards process.

Edit: On second thought, another huge difference now is that most web
developers are dependent on Google, either directly with advertising, or
indirectly via search results, and I bet a lot of devs are worried about
stirring up too much trouble and getting cut out. That may not come into play
here, but it's definitely been an issue with things like AMP.

~~~
hn_throwaway_99
As another Twitter reply said, this was a nonprofit product created by one guy
to make video content on the web more accessible, and this jerk goes on to
complain that "You're turning the web into IE again". That's nonsense.

~~~
pas
It's not nonsense. Market forces are made up of locally sane choices (but in a
usually orthogonal aspect).

Sure, it's good intentioned, but still, it pushes the needle a tiny bit, and
all those add up.

Just the fact that the developer thought, okay, sure we'll just require
Chrome, no biggie, instead of providing something as a browser extension or a
desktop thing means that either a) for some people the functionality that this
thing offers is king, so they would install even Baidu Browser too if they
could just to get this functionality, or b) Chrome's market share is so
dominant, that ignoring other browsers is a non-issue.

And of course Google has vast resources to win the feature war. This alone
means a lot of niche products will be Chrome only. And then others can play
catch-up if they want, but the first mover advantage is very big when setting
web quasi-standards.

~~~
ironmagma
Is there something preventing Firefox or Edge from adopting this API? This is
how browser APIs have worked for many years. If someone doesn’t like that
their browser doesn’t support speech recognition, isn’t the main party under
fire the browser vendor who hasn’t prioritized the work?

~~~
pas
I have no idea, but the Firefox dev teams are always behind the clock, so even
if there's nothing conceptually blocking them, bandwidth is an issue.

------
btrask
One of the comments points out the site in question is purely built around
this feature (the Web Speech API):
[https://twitter.com/hammerlockddt/status/1304658792467116033](https://twitter.com/hammerlockddt/status/1304658792467116033)

However, I think the original complaint is still legitimate. Why is Web Speech
a thing, and what browser developers are poised to support such a feature,
aside from Google? If Google wants to open source their speech tech, why don't
they just do that?

I don't really blame Google, because they're just building a better browser
than anyone else can build. But the effective result is definitely "embrace,
extend, extinguish."

Perhaps it's not too late to refactor the web into a layered architecture so
that it's possible to replace parts of it. But as long as we keep adding every
feature under the sun, that goal is getting farther and farther away.

~~~
paulryanrogers
Would you say premature standardization is a part of the problem?

It seems marginally better that Google at least asks others in an open forum.
Microsoft basically dictated defacto standards by leveraging their dominant
OS.

My preference is for vendor prefix like namespacing and waiting for at least
two independent implementations before any serious standardization. But for
web dev on the cutting edge I can see the temptation to play with new toys.

~~~
btrask
> Would you say premature standardization is a part of the problem?

More than that. It's a joke to try to standardize something that is still an
open research problem. If something is going to be a standard, there should be
at least one off-the-shelf algorithm you can implement that is roughly on par
with the competition.

I'm not saying there shouldn't be any room for innovation, but... Well, maybe
there just isn't. A standard probably has to be a lowest common denominator.

------
vinkelhake
I'm not sure that people who repeat this meme realize what the situation with
IE was. The bigger problem back then wasn't that they added new features, it's
that they basically packed up and did nothing after IE 6 had "won". There was
a _5 year_ span between IE 6 and 7.

The problem nowadays seems to be more that Chrome is adding features at a pace
where few others can keep up. But they are also very active in
standardization. Real-world experience with features is crucial when it comes
to standardization.

~~~
vezycash
Internet explorer also added features at a pace others couldn't keep up with.

Then came the lawsuit that threatened to break up the company over a free
product.

That's what made Microsoft stop work on internet explorer rather than the, 'we
won!' narrative.

By over-extending chrome, Google's exhausting the competition to extinction.

Right now, only Firefox's remaining.

Apple's decided to go at their own pace.

Once Firefox dies, Google will go after chromium forks and start stop updating
some key areas, turning them proprietory. Or better yet, packaging em to run
on their own servers.

It's what they did/are doing with android.

~~~
pas
Is there a list of things that are not in AOSP only delivered through Play but
are basically required to have a functioning Android phone?

~~~
vezycash
Basically anything that's been added to play services.

Here's an old - outdated list.

[https://arstechnica.com/gadgets/2018/07/googles-iron-grip-
on...](https://arstechnica.com/gadgets/2018/07/googles-iron-grip-on-android-
controlling-open-source-by-any-means-necessary/)

------
asn0
Tweet seems pretty click-baity. Reality seems much more boring -- Google
probably isn't going to be our evil overlords just yet.

Summary of [1] (detail from the "redacted" site) and [2] (linked from [1]):

Google was the first to implement a W3C spec (not a standard, nor on a
standards track [2]), and I guess this Web site is one of the first to use the
spec.

Other actively-maintained browsers are in various stages of implementation or
haven't announced plans.

1\. [https://webcaptioner.com/help/getting-started/web-speech-
api](https://webcaptioner.com/help/getting-started/web-speech-api)

2\. [https://wicg.github.io/speech-api/](https://wicg.github.io/speech-api/)

------
recursive
Monoculture is bad, but this is a different kind than IE ever was. IE once
went 5 years without a release.

~~~
9HZZRfNlpR
> Monoculture is bad, but this is a different kind than IE ever was. IE once
> went 5 years without a release.

Indeed, it was the other browsers that kept pushing innovation, MS just let
their IE to rot and updated it with windows after every decade. The real
criticism is Google having extreme power over what are new standards because
of their monopoly they have garnered too much power over it.

------
d3nj4l
People are getting hung up on the particular example in the tweet, but this is
a broader phenomenon.

Slack _still_ doesn't support calls on Firefox, two years after they said
they're "listening to feedback" about it [1]. Discord won't let me screen
share on Firefox on Linux, but it will gladly allow it on Brave, the only
Chromium browser I'll touch without a ten foot long pole. These aren't
impossible problems to fix. These companies just don't care about fixing them.

1:
[https://twitter.com/slackhq/status/958645632620748800?lang=e...](https://twitter.com/slackhq/status/958645632620748800?lang=en)

------
ajflores1604
As someone getting into front end dev with WebGL I constantly want to do this
but with a message to specifically call out Safari. Just yesterday I found out
they don't support navigator.hardwareConcurrency

My creativity and explorations shouldn't be limited by one vendors intentional
gimping of the web to shield their app store revenue. And calling for devs to
not push things where possible but instead go at the pace of the slowest
player feels very "No Child Left Behind", which also leaves a bad taste in my
mouth.

~~~
readarticle
It was supported for a while but just ended up being more free bits for
fingerprinting, Firefox spoofs it if resistFingerPrinting is on for example.

~~~
ajflores1604
I have no proof, but I feel like it's more than that. I don't think getting
number of threads is fine grained enough to make a meaningful difference on
identifying a device. Especially compared to fine grained numbers I've seen
extracted doing audio fingerprinting with AudioContext. At least with firefox
I can give the user instructions on how to enable it again if they want to and
they can make the decision for themselves. From what I read briefly last night
about safari, it's impossible to get a number directly unless you wanted to
recompile the browser yourself. I found this package
([https://github.com/oftn-oswg/core-estimator](https://github.com/oftn-
oswg/core-estimator)) which seems to give an estimate, but its something
someone who wants to fingerprint could also implement on a library level, so
we're back to square one except with worse developer and customer experience.

Offscreen canvas is also something I wish more browsers supported, along with
webgl2 (need for fbo). Although, I've heard rumors webgl2 might be finally
coming to safari soon.

I also wouldn't have an issue with safari taking hard stances on these things
if only they allowed competing browser engines on their phones.

------
fred_is_fred
Funny, I don't remember IE surreptitiously signing me in to website and
scraping everything I do in order to sell me more ads. Chrome is much much
worse than the old "Works in IE buttons" the web used to have.

------
temporallobe
It’s actually not the developers’ fault — Chrome has non-standard features not
available in other browsers. As I was reading through the comment thread it
seems like in this case, it’s the MIDI API. This of course presents potential
developers with a dilemma: develop an application using the exclusive API and
therefore lock the user to that browser or don’t develop it all due to lack of
cross-browser support? In essence this is not dissimilar to choice companies
used to have to make when developing IE-specific enterprise applications, only
the reason was more nuanced; Because of the sheer ubiquity of IE, it made
sense to develop to that platform and accept its quirks and features, or not
develop it at all, since developing cross-browser compatible applications
could be prohibitively expensive and time consuming, if it was even possible.

~~~
schwartzworld
Seriously, the tweet calling out devs for trying out a chrome only feature is
misplaced. Enterprise apps should be cross browser compatible, but many
personal projects come out of wanting to play with a new API.

------
deelowe
I'm guessing this is chrome supporting something that's in the w3c standards
but other browsers dont support yet. That's what this used to mean at least.

If this is the case, this is google literally being the opposite of ie and
trying to push everyone to support standards.

------
Waterluvian
To my own peril I’ll support whatever browsers and platforms I want to be
bothered with.

