4 ms·

A $400B company cannot get their app to work securely & performantly in Firefox, so they’re blocking access via UA sniffing. Seems legit.

Kalium 12y ago
Release early, release often, iterate fast. Google's doing these things. Just because you have the resources to do something doesn't make it a wise use of resources.
- SimeVidas 12y ago
  Achieving web compat with Firefox (and possibly other browsers) is not a wise use of resources? What?
  - Kalium 12y ago
    For an initial beta release on a product with no revenue gains? Yeah, probably not. For later releases? Sure.
    - SimeVidas 12y ago
      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.
      - Kalium 12y ago
        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.
        SimeVidas 12y ago
        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.
        Kalium 12y ago
        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 aspect.
        bzbarsky 12y ago
        > array slicing on sparse arrays in Firefox is much, much slower 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.
        bzbarsky 12y ago
        > They're working to solve it, 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).

Kalium 12y ago

Release early, release often, iterate fast. Google's doing these things. Just because you have the resources to do something doesn't make it a wise use of resources.

SimeVidas 12y ago
Achieving web compat with Firefox (and possibly other browsers) is not a wise use of resources? What?
- Kalium 12y ago
  For an initial beta release on a product with no revenue gains? Yeah, probably not. For later releases? Sure.
  - SimeVidas 12y ago
    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.
    - Kalium 12y ago
      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.
      - SimeVidas 12y ago
        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.
        Kalium 12y ago
        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 aspect.
        bzbarsky 12y ago
        > array slicing on sparse arrays in Firefox is much, much slower 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.
      - bzbarsky 12y ago
        > They're working to solve it, 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).