201–210 of 217 posts
tl;dr: here are a couple stabs at why, but I still don't know.
Earlier quoted context omitted.
Like accessibility, web compatibility is harder to achieve (and requires more resources) when addressed late in the development process. A web app must be accessible and compatible with the major browsers, so ensuring this from the start is the optimal approach.
And it's clear that they were looking at it from the start. If you read around a bit, you'll see that they ran into a particular performance problem with Firefox. They're working to solve it, but decided they could release something usable for Chrome users immediately.
They are?
They didn't even take the first step to solving it, which is filing a bug about it with Mozilla. When they mentioned the problem on HN, a Mozilla developer filed the bug for them and fixed it within a few hours.
So had they been _working_ to solve it, it would have been solved long ago. Like within days of them encountering it (adding some extra time to pin down the problem, which they _did_ do before not bothering to tell anyone about it).
Earlier quoted context omitted.
Still, I suspect Google’s developers are too focused on development in Chrome-only. If true, this may have contributed to perf issues arising in Firefox, in the first place. I also suspect that Google’s web compat team is not sufficient to handle their products.
Did you read the clearly documented technical details? Basically, array slicing on sparse arrays in Firefox is much, much slower than on Chrome. It's not a matter of lacking competence or skills or anything of the sort. It's a basic question of what level of resources you are willing to put into a product before you have something to beta-test. Inevitably, that's less than the amount required to be perfect in every a…
You mean "was", since it's fixed?
> It's not a matter of lacking competence or skills or anything of the sort.
Yes, it is. Not reporting a bug when you run into it but instead just complaining about it is in fact lack of competence.
Arguably using super-sparse arrays in JS is also lack of competence, but the other is much more obvuous.
> It's a basic question of what level of resources you are willing to put in
Filing a bug takes about 5 minutes.
Earlier quoted context omitted.
Go on, I'm interested - what extra cost do Google have if I use the same service in FF as I would otherwise have to switch over to Chrome to use; given that they say up front that other browsers aren't supported and that this is a beta so expected to be shonky. What cost is there? If I've switched UA string Google might not even be able to tell, without actively seeking out the information, that other browsers are us…
It takes resources (mainly developer time) to ensure that an application is working properly on multiple browsers. If you read the article you can see that a simple UA string change does not fix the problem.
Remember, there isn't any kind of really legitimate API for 100% determining which browser you're running in. There's a lot of ad-hoc methods which usually work.
These folks spent extra effort to block it from even TRYING to run in FireFox.
How are the FireFox devs supposed to see the bad performance that they need to fix for Inbox to work right if they can't run it at all?
Google have produced a product which offers a great experience on one browser. They are happy with the performance of the application on that browser. They have no doubt tested it on other browsers and found the performance to be sub par. That application is clearly still in 'beta' mode (The app is still invitation only). I am sure that they will 'un-block' the browsers that Inbox doesn't perform well on once they've…
Or, you know, a third option. They could always do what every other web developer must and make their software progressively enhance so it works at the very least on a few major browsers.
Google have produced a product which offers a great experience on one browser. They are happy with the performance of the application on that browser. They have no doubt tested it on other browsers and found the performance to be sub par. That application is clearly still in 'beta' mode (The app is still invitation only). I am sure that they will 'un-block' the browsers that Inbox doesn't perform well on once they've…
They also produced a product that leaks user data (mostly to them). In their book, 'How Google works' they claim to settle with more what's best the user than their customer. That's such a bold claim when you are a monopoly.
Earlier quoted context omitted.
Google blocked Windows Phone from accessing Google Maps in the browser (both the desktop and mobile versions) with the claims that IE was unsupported, even though Google Maps UK worked just fine. Google does have a history of blocking browsers they don't support, no matter how functional it may seem.
Were there differences between the IE on mobile and desktop though? I recall back in the IE5 days that IE on Mac was a significantly different beast than IE on Windows despite being named the same.
Earlier quoted context omitted.
They also produced a product that leaks user data (mostly to them). In their book, 'How Google works' they claim to settle with more what's best the user than their customer. That's such a bold claim when you are a monopoly.
I get really frustrated with the monopoly attack on Google, and really, with any attack on a company that is a monopoly through being great at what they do. Google is the best search engine; we use Google because it's really fucking good at what it does. Yes DDG exists but it doesn't compete, Bing is well, Bing, and others don't hold a flame. You may not like that they are a monopoly but for 99% of people, Google is…
Microsoft has done it, and got busted. Apple has done it, and got busted (albeit in a fairly small way). People are I think rightfully worried that the same thing could happen with Google. Even more so because of how respected they are with the hacker community and the tech community at large.
It's not about how they got their first monopoly, it's about how they got every one after that and what they do with them that matters.
Earlier quoted context omitted.
It takes resources (mainly developer time) to ensure that an application is working properly on multiple browsers. If you read the article you can see that a simple UA string change does not fix the problem.
There's a big difference between "provided a degraded experience in non-Chrome browsers" and "actively blocking non-Chrome browsers by means more invasive than UA checking" Remember, there isn't any kind of really legitimate API for 100% determining which browser you're running in. There's a lot of ad-hoc methods which usually work. These folks spent extra effort to block it from even TRYING to run in FireFox. How ar…
Also, with respect to performance, this comment in the article might shed some light:
"Also see Bugzilla entry. The use of spare arrays with huge indexes was a performance issue in Firefox. It's been fixed in Inbox and in FF but not shipped in FF yet. (https://bugzilla.mozilla.org/show_bug.cgi?id=1087963)"
Earlier quoted context omitted.
Go on, I'm interested - what extra cost do Google have if I use the same service in FF as I would otherwise have to switch over to Chrome to use; given that they say up front that other browsers aren't supported and that this is a beta so expected to be shonky. What cost is there? If I've switched UA string Google might not even be able to tell, without actively seeking out the information, that other browsers are us…
It takes resources (mainly developer time) to ensure that an application is working properly on multiple browsers. If you read the article you can see that a simple UA string change does not fix the problem.