4 ms·

Browser lock-in? What makes you think web applications made with this kit work only in Chrome?

by esolyt 12y ago

addyo 12y ago
One of the core values behind this project is that it should work extremely well cross-device and that most definitely means on devices where Chrome isn't the primary browser. During development we've ensured that we test on Firefox OS, Windows phone, iOS and browsers other than Chrome which run on Android. I want to give people something that they can rely on. Chrome isn't the only browser in the world for sure :)
- gress 12y ago
  Looks like browsersync is a Chrome only proprietary feature.
  - voltagex_ 12y ago
    http://browsersync.io/ http://browsersync.io/ - at least the server side seems to be open.
    - gress 12y ago
      Nope. This is a chrome feature that just happens to have the same name as that site. There is no connection.
      - Flenser 12y ago
        No, it's http://browsersync.io/ http://browsersync.io/ - the readme links directly to that site: https://github.com/google/web-starter-kit#features https://github.com/google/web-starter-kit#features
        gress 12y ago
        I stand corrected. This is a design-time tool. I mistook it for the consumer feature of the same name.
chillingeffect 12y ago
I don't think he means locked into a single browser, I think he miiiight mean "generally locked into using a computer at the level of a browser vs. at the level of the OS." As in, "your mom and uncle will buy a web-browser, they won't buy a computer." Correct me if I'm wrong :)
- esolyt 12y ago
  I don't think so. This is the sentence he replied to: "The only plus I see in all this is that in the end we are now free of the API lock-in that OS vendors traditionally required" The discussion here is about APIs that are specific to Apple, Microsoft, Google etc.
ChuckMcM 12y ago
So understand I've got a bit of history here, back in the old days I was working on Java/HotJava and the whole applet thing. Netscape was doing their own thing with what would become known as Javascript. Our vision was "Gee everything that runs in Java can run anywhere, regardless of OS or device etc etc." its a great vision. In the nearly 20 years since since Java pushed out the door (March '95, best of times and worst of times :-) this has never worked. Not for Java, not for Javascript, not for C#, not anything. Certain browsers work, some don't, there are quirks everywhere. The default defensive strategy is to pick one browser you know work and select that as the 'standard.' Not complaining just noting the lock in is an emergent property.
- jacquesm 12y ago
  I think that to some degree the lack of certification for browsers (and ditto for Java runtimes back in the days) is what is causing this. Write-once-run-anywhere became Write-once-debug-everywhere. Java seems to finally start to deliver on this promise though, the last few years have seen quite a bit of improvement. (Still far from perfect though, just the other day I was fighting some corporate website that insisted I install a certain version of Java in a certain browser in order to be allowed access, and it crashed in terrible ways when I finally did gain access). Imagine that your browser simply wouldn't be allowed on the web until it conformed to a standard. Just like cars aren't allowed to go on the road if they do not conform. This is unlikely to ever happen for various reasons and I don't think it would be a good thing but the number of broken implementations and hacks-that-became-standards is too large to even count by now.
  - eli 12y ago
    Didn't J2ME have a certification process? That was still a hot mess to develop for.

Browser lock-in? What makes you think web applications made with this kit work only in Chrome?

by esolyt 12y ago

Browser lock-in? What makes you think web applications made with this kit work only in Chrome?

addyo 12y ago

One of the core values behind this project is that it should work extremely well cross-device and that most definitely means on devices where Chrome isn't the primary browser. During development we've ensured that we test on Firefox OS, Windows phone, iOS and browsers other than Chrome which run on Android. I want to give people something that they can rely on. Chrome isn't the only browser in the world for sure :)

gress 12y ago
Looks like browsersync is a Chrome only proprietary feature.
- voltagex_ 12y ago
  http://browsersync.io/ http://browsersync.io/ - at least the server side seems to be open.
  - gress 12y ago
    Nope. This is a chrome feature that just happens to have the same name as that site. There is no connection.
    - Flenser 12y ago
      No, it's http://browsersync.io/ http://browsersync.io/ - the readme links directly to that site: https://github.com/google/web-starter-kit#features https://github.com/google/web-starter-kit#features
      - gress 12y ago
        I stand corrected. This is a design-time tool. I mistook it for the consumer feature of the same name.

chillingeffect 12y ago

I don't think he means locked into a single browser, I think he miiiight mean "generally locked into using a computer at the level of a browser vs. at the level of the OS." As in, "your mom and uncle will buy a web-browser, they won't buy a computer." Correct me if I'm wrong :)

esolyt 12y ago
I don't think so. This is the sentence he replied to: "The only plus I see in all this is that in the end we are now free of the API lock-in that OS vendors traditionally required" The discussion here is about APIs that are specific to Apple, Microsoft, Google etc.

ChuckMcM 12y ago

So understand I've got a bit of history here, back in the old days I was working on Java/HotJava and the whole applet thing. Netscape was doing their own thing with what would become known as Javascript. Our vision was "Gee everything that runs in Java can run anywhere, regardless of OS or device etc etc." its a great vision. In the nearly 20 years since since Java pushed out the door (March '95, best of times and worst of times :-) this has never worked. Not for Java, not for Javascript, not for C#, not anything. Certain browsers work, some don't, there are quirks everywhere. The default defensive strategy is to pick one browser you know work and select that as the 'standard.' Not complaining just noting the lock in is an emergent property.

jacquesm 12y ago
I think that to some degree the lack of certification for browsers (and ditto for Java runtimes back in the days) is what is causing this. Write-once-run-anywhere became Write-once-debug-everywhere. Java seems to finally start to deliver on this promise though, the last few years have seen quite a bit of improvement. (Still far from perfect though, just the other day I was fighting some corporate website that insisted I install a certain version of Java in a certain browser in order to be allowed access, and it crashed in terrible ways when I finally did gain access). Imagine that your browser simply wouldn't be allowed on the web until it conformed to a standard. Just like cars aren't allowed to go on the road if they do not conform. This is unlikely to ever happen for various reasons and I don't think it would be a good thing but the number of broken implementations and hacks-that-became-standards is too large to even count by now.
- eli 12y ago
  Didn't J2ME have a certification process? That was still a hot mess to develop for.