25 ms·

For Chromium, developers do not need to publish apps through the Chrome Store, nor do you need a Google account to use such apps. Chrome has the same side-loadi

For Chromium, developers do not need to publish apps through the Chrome Store, nor do you need a Google account to use such apps. Chrome has the same side-loading capability of Android allowing install from unknown sources. There are apps that Google refuses from the Web Store that are distributed this way. I don't think you're going to get many people to believe that apps which target a platform that is mostly based on a spec controlled by a consortium, and for the most part, are cross-platform, are somehow more locked down and proprietary than a native apps platform. This is pretty much the first time I've seen anyone on HN try to argue that web apps, even chromium apps, are harder to port, and more of a walled garden than Android. It's a difficult to pull off argument, and I don't think it works.

fidotron 13y ago
Except Chrome increasingly doesn't implement the standard. For example, Adobe's recent CSS stuff isn't in, and instead an early version of the shadow DOM stuff which even Mozilla doesn't agree with is going in, on top of all the Chrome app API itself. As I keep pointing out, you can literally implement something that presents the user a button and on pressing it downloads an apk, installs the package and runs the content in about 10 minutes. Can you do that with crx files in Chrome or Chromium without it triggering a nasty popup? Can your locally installed app then provide services to this other app we just downloaded without needing an intermediary server? If not, it's not as open as Android is.
- cromwellian 13y ago
  This is really a red herring grasping for straws. All browsers have proprietary extensions and have differences from the spec. HTML5 for the most part works because people use what's portable. Html5test.com wouldn't need to exist if this weren't true. The fact of the matter is, Web apps are more portable than Android apps, period. Take a random sample of the Chrome Web Store apps, how many of them do you think are tightly bound to be Chrome proprietary API only and won't run elsewhere? How many of them won't install or run on a forked Chromium? Now go take a random sample of the Play store. And test those apps on say, a Chinese AOSP fork or Amazon's fork. How many of them will run without breaking? In no way can you compare GMS dependencies to a handful of Chrome-only APIs that barely any web developers use. And when we talk about open-ness, we're talking about open source and how open the project is developed. Web standards have working groups to agree upon a spec. For the most part, the majority of new CSS or Javascript features are decided on at the W3C and TC39. That is a far cry different than the way say, future versions of Android are developed in secret. I understand some of the restrictions on why Android is developed like that but to compare it to the web or iOS is a false equivalence. The fact that Web apps can't do the kinds of things you're talking about with respect to inter-app services has nothing to do with openness and more to do with the sandbox that the web puts apps into. That said, locally installed apps can provide services to other apps through multiple techniques: * Background pages (invisible HTML pages running in the background) * Shared Web Workers (spawned process that lives at a known address) * Custom Protocol Handler * Service Workers (intercept HTTP requests for resources) * Chrome Extension content page * WebRTC or local web server * Web Intents/Web Activities (got shelved by Google and Mozilla) From your perspective, you're talking about what's presented to the developer. But this discussion is about Independent Hardware Vendors. What does it take for someone to build their own usable ChromeOS device vs build a modern smartphone starting with only open source. For ChromeOS, you get very very far with the existing open source and most apps will run unchanged. For Android, if you start only from AOSP, any apps dependent on the Google cloud will be broke, and the question is, how easy is it to shim those services out and replace them, and it is far more work. This is not a bash on AOSP or Android. It's just a retort to the ridiculous idea that somehow web apps on ChromeOS are more locked in than Android.
  - fidotron 13y ago
    It's not clutching at straws at all - they very clearly are diverging from the spec everyone else is using, moving to not prefixing, and shipping as on by default. This might as well be in secret, since the Chrome group are developing the habit of dictating specs by pushing implementations out regardless of the community, and thus is no better than the OHA, who at least talk amongst themselves. There are also proprietary Android libraries that exist for different manufacturers, but you're probably insane if you rely on them. I used to work doing games on Android across all varieties of it, and the differences are nothing like as big as people that haven't looked properly seem to think. In fact for many titles without push or in app billing it was simply a question of testing, and these things ran perfectly, or no worse than any other issue you might have with a device on the Play Store. It is most definitely less than the difference between different web browsers, and far better defined. Do this a few times and it can be abstracted away (to the point of portability to iOS abstracted). Let's say I'm an OEM without an existing contract with Google. I could either build a Chromium device or an Android one, and shove some other app store on it. Unsurprisingly many are doing the latter, and they're in the wild, but has anyone seen a Chromium device actually out there? Given how many Chromebooks are selling you'd think maybe one enterprising Chinese OEM would do it, but they seem far keener on Android. I wonder why. You are greatly overestimating how hard it is to implement services on the device. The only hard part of implementing a store and in app billing, for example, is the server. The clients practically write themselves by comparison. Given that the entire Chinese Android market exists without Google's cloud services it's clearly nothing like as big a deal as you and Google wish it were.
    - cromwellian 13y ago
      Apples to Oranges. You're asking why there aren't as many ChromeBook vendors as there are Android vendors? Maybe it has something to do with the fact that consumers are buying less traditional computers and buying more phones and tablets. No one is wishing anything is a big deal. I am not attacking Android or the bogus Ars Technica articles which keep pushing the line that AOSP isn't open. I'm criticizing this weird claim that ChromeOS is more of a walled garden, which it most decidedly is not. Chromium is "more" open source than Android because it is developed continuously in the open, there's no "code bomb" that publishes the entire Next version once a year. Secondly, the surface area of Chrome-specific APIs or services are tiny and insignificant compared to native devices. Those two features limit platform lockin and increase portability. The Chrome Web Store/Chrome Apps are simply a red herring. The vast vast majority of ChromeOS "apps" are links to hosted sites, the majority of which work on any browser. That's been the major problem getting people to pay for stuff in the CWS as you can cut/paste the URL and avoid the store entirely for many apps. Leaving aside Chromium, many people have taken WebKit and made desktops based on it. WebOS, the new SteamBox uses a frontend built with WebKit, the PlayStation UI has various parts built with a browser. There was also Jolicloud. It is not hard to take a Linux distribution and slap a browser on it as the desktop launcher. Sorry, it's just not. Whether people are interested in doing that and think it is something they could sell for a profit is a different story that has nothing to do with the technical difficulty of doing it.

fidotron 13y ago

Except Chrome increasingly doesn't implement the standard. For example, Adobe's recent CSS stuff isn't in, and instead an early version of the shadow DOM stuff which even Mozilla doesn't agree with is going in, on top of all the Chrome app API itself. As I keep pointing out, you can literally implement something that presents the user a button and on pressing it downloads an apk, installs the package and runs the content in about 10 minutes. Can you do that with crx files in Chrome or Chromium without it triggering a nasty popup? Can your locally installed app then provide services to this other app we just downloaded without needing an intermediary server? If not, it's not as open as Android is.

cromwellian 13y ago
This is really a red herring grasping for straws. All browsers have proprietary extensions and have differences from the spec. HTML5 for the most part works because people use what's portable. Html5test.com wouldn't need to exist if this weren't true. The fact of the matter is, Web apps are more portable than Android apps, period. Take a random sample of the Chrome Web Store apps, how many of them do you think are tightly bound to be Chrome proprietary API only and won't run elsewhere? How many of them won't install or run on a forked Chromium? Now go take a random sample of the Play store. And test those apps on say, a Chinese AOSP fork or Amazon's fork. How many of them will run without breaking? In no way can you compare GMS dependencies to a handful of Chrome-only APIs that barely any web developers use. And when we talk about open-ness, we're talking about open source and how open the project is developed. Web standards have working groups to agree upon a spec. For the most part, the majority of new CSS or Javascript features are decided on at the W3C and TC39. That is a far cry different than the way say, future versions of Android are developed in secret. I understand some of the restrictions on why Android is developed like that but to compare it to the web or iOS is a false equivalence. The fact that Web apps can't do the kinds of things you're talking about with respect to inter-app services has nothing to do with openness and more to do with the sandbox that the web puts apps into. That said, locally installed apps can provide services to other apps through multiple techniques: * Background pages (invisible HTML pages running in the background) * Shared Web Workers (spawned process that lives at a known address) * Custom Protocol Handler * Service Workers (intercept HTTP requests for resources) * Chrome Extension content page * WebRTC or local web server * Web Intents/Web Activities (got shelved by Google and Mozilla) From your perspective, you're talking about what's presented to the developer. But this discussion is about Independent Hardware Vendors. What does it take for someone to build their own usable ChromeOS device vs build a modern smartphone starting with only open source. For ChromeOS, you get very very far with the existing open source and most apps will run unchanged. For Android, if you start only from AOSP, any apps dependent on the Google cloud will be broke, and the question is, how easy is it to shim those services out and replace them, and it is far more work. This is not a bash on AOSP or Android. It's just a retort to the ridiculous idea that somehow web apps on ChromeOS are more locked in than Android.
- fidotron 13y ago
  It's not clutching at straws at all - they very clearly are diverging from the spec everyone else is using, moving to not prefixing, and shipping as on by default. This might as well be in secret, since the Chrome group are developing the habit of dictating specs by pushing implementations out regardless of the community, and thus is no better than the OHA, who at least talk amongst themselves. There are also proprietary Android libraries that exist for different manufacturers, but you're probably insane if you rely on them. I used to work doing games on Android across all varieties of it, and the differences are nothing like as big as people that haven't looked properly seem to think. In fact for many titles without push or in app billing it was simply a question of testing, and these things ran perfectly, or no worse than any other issue you might have with a device on the Play Store. It is most definitely less than the difference between different web browsers, and far better defined. Do this a few times and it can be abstracted away (to the point of portability to iOS abstracted). Let's say I'm an OEM without an existing contract with Google. I could either build a Chromium device or an Android one, and shove some other app store on it. Unsurprisingly many are doing the latter, and they're in the wild, but has anyone seen a Chromium device actually out there? Given how many Chromebooks are selling you'd think maybe one enterprising Chinese OEM would do it, but they seem far keener on Android. I wonder why. You are greatly overestimating how hard it is to implement services on the device. The only hard part of implementing a store and in app billing, for example, is the server. The clients practically write themselves by comparison. Given that the entire Chinese Android market exists without Google's cloud services it's clearly nothing like as big a deal as you and Google wish it were.
  - cromwellian 13y ago
    Apples to Oranges. You're asking why there aren't as many ChromeBook vendors as there are Android vendors? Maybe it has something to do with the fact that consumers are buying less traditional computers and buying more phones and tablets. No one is wishing anything is a big deal. I am not attacking Android or the bogus Ars Technica articles which keep pushing the line that AOSP isn't open. I'm criticizing this weird claim that ChromeOS is more of a walled garden, which it most decidedly is not. Chromium is "more" open source than Android because it is developed continuously in the open, there's no "code bomb" that publishes the entire Next version once a year. Secondly, the surface area of Chrome-specific APIs or services are tiny and insignificant compared to native devices. Those two features limit platform lockin and increase portability. The Chrome Web Store/Chrome Apps are simply a red herring. The vast vast majority of ChromeOS "apps" are links to hosted sites, the majority of which work on any browser. That's been the major problem getting people to pay for stuff in the CWS as you can cut/paste the URL and avoid the store entirely for many apps. Leaving aside Chromium, many people have taken WebKit and made desktops based on it. WebOS, the new SteamBox uses a frontend built with WebKit, the PlayStation UI has various parts built with a browser. There was also Jolicloud. It is not hard to take a Linux distribution and slap a browser on it as the desktop launcher. Sorry, it's just not. Whether people are interested in doing that and think it is something they could sell for a profit is a different story that has nothing to do with the technical difficulty of doing it.