8 ms·

Part of this communication difference is that the Chrome blog's audience is users, people who aren't concerned with web standards. The Chromium blog, however,

Part of this communication difference is that the Chrome blog's audience is users, people who aren't concerned with web standards. The Chromium blog, however, is where the developer story is told. Chrome 28's was covered the same time as the post you link: http://blog.chromium.org/2013/05/chrome-28-beta-more-immersive-web.html http://blog.chromium.org/2013/05/chrome-28-beta-more-immersi... Here, the W3C standard fullscreen API was covered for Android as well as the web standards WebGL and WebRTC being available through about:flags. Then CSP, @supports, Custom Elements.. all standard stuff. Mozilla does a great job communicating the web standards story of the features they're working on. This definitely inspired the Chrome team when we released Blink, so we worked on http://chromestatus.com http://chromestatus.com to capture the full cross-browser standardization story and give everyone a means to shame Chrome if we're implementing something for the web platform that doesn't have cross-vendor buy in. There is a lot of exciting APIs available in Chrome Apps but it's certainly not slowing down on the web platform side of things. I would definitely recommend you check out the "Intent to Implement/Ship" threads [1] on blink-dev. Here you can see the activity and discussions around compatibility risk, standardization and responsibly adding new features to the platform. [1] https://groups.google.com/a/chromium.org/forum/#!topicsearchin/blink-dev/subject$3Aintent https://groups.google.com/a/chromium.org/forum/#!topicsearch... or spreadsheeted here http://goo.gl/loaQ5 http://goo.gl/loaQ5

coldtea 13y ago
Thanks for the rundown. Checking the chromestatus page, I have another question: why so little movement in relation to the new Javascript features?
RyanZAG 13y ago
That's great and all, but you didn't address the issue. We're discussing this new notification system that will only ever work properly on Chrome. The latest posts on that chromium blog are even worse: 1) Richer access to Google services and better OS integration in Chrome packaged apps - Identity API - Google only - In App Payments API - Google Wallet only - Analytics API - Google Analytics only - Native Messaging API - The problem we are discussing 2) Dart - obviously a way to create a two-tier web with Chrome being the only option for performance. (You can bet it will be incredibly difficult for other browsers to package/integrate the Dart VM easily). Your roundabout answer to this question leaves me very concerned for the future of the web if Google actually thinks this isn't a problem. I do believe it's looking like the only responsible option for an open web is to ditch Chrome and try my best to lower Chrome market share. We're going to look back on this in 5 years and kick ourselves over letting Google do this. I hate to say it, but Google is now the biggest threat to an open web.
- lmm 13y ago
  >Dart - obviously a way to create a two-tier web with Chrome being the only option for performance. (You can bet it will be incredibly difficult for other browsers to package/integrate the Dart VM easily). Doesn't the same logic apply to Mozilla's asm.js?
  - pcwalton 13y ago
    asm.js was implemented very quickly, in about a month, and V8 is already implementing optimizations for it (though without "use asm").
    - kingkilr 13y ago
      It's not an optimization for asm.js if you ignore the "use asm". It's just javascript then.
      - Ygg2 13y ago
        Which is what asm.js is mostly. Subset of javascript.
        justinschuh 13y ago
        No, it's an IR that happens to have an identical representation in JavaScript. But that clever hack gets muddy already with things like Math.imul. And it's going to diverge far more given the demand for e.g. threading, sync primitives, shared memory, and vectored operations. I honestly don't see how asm.js can be made into anything beyond its current demo state without major changes to the JavaScript language and APIs.
        pcwalton 13y ago
        Those changes would benefit regular JavaScript as well, so it's not a divergence. Regular JavaScript developers are already asking for SIMD (and that's why Dart is implementing it, after all). They were asking for more predictable math operations, and Math.imul is good for that. Threading too. Changes made for asm.js lift all boats. The parent comment said that asm.js was a subset of JavaScript. You said "no", but none of the things you said contradict that. asm.js is, right now, a subset of JavaScript. Which, of course, is its entire raison d'être.
riquito 13y ago
You completely skipped the answer about Native Messaging API, is worrysome. And RyanZAG nailed it, the chromium blog is full of references to Google-only apis

coldtea 13y ago

Thanks for the rundown. Checking the chromestatus page, I have another question: why so little movement in relation to the new Javascript features?

RyanZAG 13y ago

That's great and all, but you didn't address the issue. We're discussing this new notification system that will only ever work properly on Chrome. The latest posts on that chromium blog are even worse: 1) Richer access to Google services and better OS integration in Chrome packaged apps - Identity API - Google only - In App Payments API - Google Wallet only - Analytics API - Google Analytics only - Native Messaging API - The problem we are discussing 2) Dart - obviously a way to create a two-tier web with Chrome being the only option for performance. (You can bet it will be incredibly difficult for other browsers to package/integrate the Dart VM easily). Your roundabout answer to this question leaves me very concerned for the future of the web if Google actually thinks this isn't a problem. I do believe it's looking like the only responsible option for an open web is to ditch Chrome and try my best to lower Chrome market share. We're going to look back on this in 5 years and kick ourselves over letting Google do this. I hate to say it, but Google is now the biggest threat to an open web.

lmm 13y ago
>Dart - obviously a way to create a two-tier web with Chrome being the only option for performance. (You can bet it will be incredibly difficult for other browsers to package/integrate the Dart VM easily). Doesn't the same logic apply to Mozilla's asm.js?
- pcwalton 13y ago
  asm.js was implemented very quickly, in about a month, and V8 is already implementing optimizations for it (though without "use asm").
  - kingkilr 13y ago
    It's not an optimization for asm.js if you ignore the "use asm". It's just javascript then.
    - Ygg2 13y ago
      Which is what asm.js is mostly. Subset of javascript.
      - justinschuh 13y ago
        No, it's an IR that happens to have an identical representation in JavaScript. But that clever hack gets muddy already with things like Math.imul. And it's going to diverge far more given the demand for e.g. threading, sync primitives, shared memory, and vectored operations. I honestly don't see how asm.js can be made into anything beyond its current demo state without major changes to the JavaScript language and APIs.
        pcwalton 13y ago
        Those changes would benefit regular JavaScript as well, so it's not a divergence. Regular JavaScript developers are already asking for SIMD (and that's why Dart is implementing it, after all). They were asking for more predictable math operations, and Math.imul is good for that. Threading too. Changes made for asm.js lift all boats. The parent comment said that asm.js was a subset of JavaScript. You said "no", but none of the things you said contradict that. asm.js is, right now, a subset of JavaScript. Which, of course, is its entire raison d'être.

riquito 13y ago

You completely skipped the answer about Native Messaging API, is worrysome. And RyanZAG nailed it, the chromium blog is full of references to Google-only apis