5 ms·

There's not really a good reason for Google to make applications they create work outside their own run-time environment - Chrome. Any technical reason they mi

There's not really a good reason for Google to make applications they create work outside their own run-time environment - Chrome. Any technical reason they might offer (sparse array performance) is just facetious. They have the technical know-how to solve such problems, but business wise it makes little sense. I use three web browsers for just that reason. Chrome for Google products (YouTube, Gmail, now Inbox, etc.), IE for Microsoft products (Outlook.com, etc.), and Firefox for the open web and general usage.

custardcream 12y ago
Yes there is. It's the world wide web. An interoperable universal interaction standard. Or it was until Google started pulling an IE6 game. I use Firefox for everything because there is no central motivation to specialise. If a site doesn't work well, it doesn't get my business.
- untothebreach 12y ago
  I'm with you. The day Google announced Inbox, and the fact that it wouldn't work with Firefox, was the day I finally got motivated enough to set up my own email server. I ended up just using mail-in-a-box, which doesn't come with the _best_ client, but is good enough, and I can use it from any browser I want without any problems.
- cognivore 12y ago
  Well, yes, that'd be nice if we had a "interoperable universal interaction standard." But now the majority (and soon, almost everyone) will be using the internet on tiny personal computers (smartphones) that run native apps. Using a web browser will become less and less important or even relevant. In such a case the costs of optimizing for multiple run-times makes little sense. Really, abandoning the browser for native apps (in the old days we called them "programs") across the board makes more sense, and leave browsers to what they were originally intended for - document perusal and simple data collection. And web browsers absolutely suck at UI for applications. Imagine the man hours and effort that went into building Gmail. It boggles the mind. Who would even want to maintain that?! All for something that could have been created as a native app much easier. There's a lot of reasons that people have gravitated towards apps on phones, but one of them is assuredly that the experience is better than using a web browser.
  - custardcream 12y ago
    As someone who is old enough to have written "programs" and sees the instant relationship to "apps", I vigorously disagree. Lets consider these points: 1. Firstly there are competing platforms on which to deploy your programs. This means there is little common ground between the three major sectors of the market. You either have to pick one and lose market share or pick all and increase cost. Nothing (yet) has solved this problem adequately without increasing cost or decreasing agility and/or quality and consistency. 2. Each of these platforms has many barriers to entry from subscription fees, having to buy specific hardware and learn how to use it, distribution and vendor costs, QA cost and the risks of rejection and having your product closed suddenly. 3. All of the markets are primarily consumer oriented which makes deploying things to corporate entities a pain in the backside requiring more hoops to jump through. 4. None of the programs have longevity, a stable platform to run on, security guarantees or predictable security evolution. So at the end of the day, you're pitching programs sold behind a walled garden by someone who wants a slice of your cash and doesn't give a fuck if the device works after you've sold it versus a platform with zero entry cost, total ubiquity and importantly absolutely no distribution or sales model at all so you can build your own? Nope. People take apps because they're cheap, free or the vendor is pushing them. That's it. If it wasn't the case, the first thing we'd do when we unboxed a mac or a PC was download and install facebook. Which we don't do. As for mobile first everything, not a chance.
    - TeMPOraL 12y ago
      A small tangent. > and doesn't give a fuck if the device works after you've sold Which is even worse on the web, where most of the time that someone also doesn't give a fuck about you at all and will just pull the product the moment he gets enough users to make an exit. There are good things about having a working binary on your device; the author can't just take it away from you just because he doesn't care about the product anymore.
      - custardcream 12y ago
        Well considering most of these binaries are tied to app stores and talk to the web they're about as much use if the vendor pulls the plug.
- alexbecker 12y ago
  >an IE6 game That's harsh.
  - josteink 12y ago
    It's accurate.
Bjartr 12y ago
>They have the technical know-how to solve such problems, but business wise it makes little sense. In this case, the business priority was a release coincident with Lollipop.
danieldk 12y ago
Any technical reason they might offer (sparse array performance) is just facetious. They have the technical know-how to solve such problems, but business wise it makes little sense. Indeed. They cared about open standards when Microsoft was still dominating and the new categories were in their infancy. Later, they cared because Apple dominated smart phones and tables for some years. But now that Android has an ~85% worldwide marketshare, Google Mail is probably the most popular e-mail provider, and Chrome made serious inroads on the desktop, they feel confident enough to slowly start ignoring standards to lock other browsers and ecosystems out. Of course, the historical difference compared to Microsofts rise is that hackers always had contempt for Microsoft, while Google is loved in large contingents.
voyou 12y ago
"There's not really a good reason for Google to make applications they create work outside their own run-time environment - Chrome" Except that the only reason Google built a run time environment in the first place was to encourage people to use their services - that is, the things that collect the data and serve the ads that make them money. Google has no business reason to block Firefox; quite the opposite, in fact. So it's reasonable to believe them when they say they have a technical reason.
- bzbarsky 12y ago
  When Google _wants_ to make sure something they create works with Firefox, they take some steps to make that happen. Things like filing bugs on issues in Firefox that are blocking it working and contacting Mozilla about those issues directly via the dedicated coordination mailing list we have set up for issues like this. None of those things happend with Inbox. There were no bug reports filed, no mention of issues getting it to work, nothing. So this was a pure business decision to not put any particular effort into making Inbox work in Firefox. Now you might say that simply writing to standards should make it work in Firefox and if it doesn't that's a problem with Firefox, and I agree. But in my experience "writing to standards" doesn't really describe Google properties very well, especially when they try to push the envelope where standards don't exist yet.
Kalium 12y ago
There are always more problems that you can solve before you release a product. This is universally true of all products. It doesn't matter how developed the thing is, there are always more things you can do. But at the end of the day, you do need to ship a product. Which means some of those go un-done. Especially when it's a product in beta where you're looking to get feedback and iterate.

custardcream 12y ago

Yes there is. It's the world wide web. An interoperable universal interaction standard. Or it was until Google started pulling an IE6 game. I use Firefox for everything because there is no central motivation to specialise. If a site doesn't work well, it doesn't get my business.

untothebreach 12y ago
I'm with you. The day Google announced Inbox, and the fact that it wouldn't work with Firefox, was the day I finally got motivated enough to set up my own email server. I ended up just using mail-in-a-box, which doesn't come with the _best_ client, but is good enough, and I can use it from any browser I want without any problems.
cognivore 12y ago
Well, yes, that'd be nice if we had a "interoperable universal interaction standard." But now the majority (and soon, almost everyone) will be using the internet on tiny personal computers (smartphones) that run native apps. Using a web browser will become less and less important or even relevant. In such a case the costs of optimizing for multiple run-times makes little sense. Really, abandoning the browser for native apps (in the old days we called them "programs") across the board makes more sense, and leave browsers to what they were originally intended for - document perusal and simple data collection. And web browsers absolutely suck at UI for applications. Imagine the man hours and effort that went into building Gmail. It boggles the mind. Who would even want to maintain that?! All for something that could have been created as a native app much easier. There's a lot of reasons that people have gravitated towards apps on phones, but one of them is assuredly that the experience is better than using a web browser.
- custardcream 12y ago
  As someone who is old enough to have written "programs" and sees the instant relationship to "apps", I vigorously disagree. Lets consider these points: 1. Firstly there are competing platforms on which to deploy your programs. This means there is little common ground between the three major sectors of the market. You either have to pick one and lose market share or pick all and increase cost. Nothing (yet) has solved this problem adequately without increasing cost or decreasing agility and/or quality and consistency. 2. Each of these platforms has many barriers to entry from subscription fees, having to buy specific hardware and learn how to use it, distribution and vendor costs, QA cost and the risks of rejection and having your product closed suddenly. 3. All of the markets are primarily consumer oriented which makes deploying things to corporate entities a pain in the backside requiring more hoops to jump through. 4. None of the programs have longevity, a stable platform to run on, security guarantees or predictable security evolution. So at the end of the day, you're pitching programs sold behind a walled garden by someone who wants a slice of your cash and doesn't give a fuck if the device works after you've sold it versus a platform with zero entry cost, total ubiquity and importantly absolutely no distribution or sales model at all so you can build your own? Nope. People take apps because they're cheap, free or the vendor is pushing them. That's it. If it wasn't the case, the first thing we'd do when we unboxed a mac or a PC was download and install facebook. Which we don't do. As for mobile first everything, not a chance.
  - TeMPOraL 12y ago
    A small tangent. > and doesn't give a fuck if the device works after you've sold Which is even worse on the web, where most of the time that someone also doesn't give a fuck about you at all and will just pull the product the moment he gets enough users to make an exit. There are good things about having a working binary on your device; the author can't just take it away from you just because he doesn't care about the product anymore.
    - custardcream 12y ago
      Well considering most of these binaries are tied to app stores and talk to the web they're about as much use if the vendor pulls the plug.
alexbecker 12y ago
>an IE6 game That's harsh.
- josteink 12y ago
  It's accurate.

Bjartr 12y ago

>They have the technical know-how to solve such problems, but business wise it makes little sense. In this case, the business priority was a release coincident with Lollipop.

danieldk 12y ago

Any technical reason they might offer (sparse array performance) is just facetious. They have the technical know-how to solve such problems, but business wise it makes little sense. Indeed. They cared about open standards when Microsoft was still dominating and the new categories were in their infancy. Later, they cared because Apple dominated smart phones and tables for some years. But now that Android has an ~85% worldwide marketshare, Google Mail is probably the most popular e-mail provider, and Chrome made serious inroads on the desktop, they feel confident enough to slowly start ignoring standards to lock other browsers and ecosystems out. Of course, the historical difference compared to Microsofts rise is that hackers always had contempt for Microsoft, while Google is loved in large contingents.

voyou 12y ago

"There's not really a good reason for Google to make applications they create work outside their own run-time environment - Chrome" Except that the only reason Google built a run time environment in the first place was to encourage people to use their services - that is, the things that collect the data and serve the ads that make them money. Google has no business reason to block Firefox; quite the opposite, in fact. So it's reasonable to believe them when they say they have a technical reason.

bzbarsky 12y ago
When Google _wants_ to make sure something they create works with Firefox, they take some steps to make that happen. Things like filing bugs on issues in Firefox that are blocking it working and contacting Mozilla about those issues directly via the dedicated coordination mailing list we have set up for issues like this. None of those things happend with Inbox. There were no bug reports filed, no mention of issues getting it to work, nothing. So this was a pure business decision to not put any particular effort into making Inbox work in Firefox. Now you might say that simply writing to standards should make it work in Firefox and if it doesn't that's a problem with Firefox, and I agree. But in my experience "writing to standards" doesn't really describe Google properties very well, especially when they try to push the envelope where standards don't exist yet.

Kalium 12y ago

There are always more problems that you can solve before you release a product. This is universally true of all products. It doesn't matter how developed the thing is, there are always more things you can do. But at the end of the day, you do need to ship a product. Which means some of those go un-done. Especially when it's a product in beta where you're looking to get feedback and iterate.