7 ms·

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 po

by 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.
        justinschuh 13y ago
        My statement was correct. It's not JavaScript, which is why you use a keyword to switch to a different compiler mode. It's a clever hack to use an equivalent subset of JavaScript as an IR (accepting a few polyfills). However, it's not exactly honest to frame it as "just JavaScript." What really does worry me is the ugly things that will be necessary to make asm.js genuinely viable as a platform. Yes, some proposals will have general utility for JavaScript, but many will not. And some will be downright dangerous. For example, how are you going to address pthreads compatibility, which e.g. Epic is saying they need?
        13y ago
  - mraleph 13y ago
    Did you actually want to say "OdinMonkey was implemented very quickly, in about a month"? I am not sure I understand what people try to prove or imply when they say that. OdinMonkey takes an extremely limited statically typed language with an almost non-existent runtime library as an input, checks the types and pipes fully typed IR further through the existing backend (IonMonkey). Does it come as a surprise to anyone that this can be implemented quickly?
    - pcwalton 13y ago
      Yes, I meant to say Odin, sorry. Thanks for the correction.
- hrjet 13y ago
  asm.js works on all standards compliant browsers. Dart is a new language / VM and it's not standardized. So the logic is definitely not the same.
ahoge 13y ago
> Dart - obviously a way to create a two-tier web with Chrome being the only option for performance. The performance of the generated JavaScript is okay. Typically, it's somewhere around 75% of the performance of handwritten JavaScript and it's still getting better. Those -25% may sound like a big deal, but it's comparable to the performance from JS engines from last year.
md224 13y ago
To be fair, the first one you cited is for Chrome packaged apps, so I feel like it's a little different than special APIs exposed to normal web page javascript. It's the difference between saying "build apps for our browser, we give you powerful features" and "build web pages that only work in our browser." Now, if you think it's bad that Chrome is trying to entice browser app developers with powerful feature sets, that seems like a related but different complaint. It's possible I'm unclear on the scope of the Open Web movement. When it refers to web technologies, does it mean technologies employed in the service of presenting web pages (i.e. everything you can do with javascript, html, css, etc.), or any technologies that a browser serves as a platform for? Because the latter seems like a wider scope that encompasses more than just web pages.
- mtrimpe 13y ago
  It's not just this though, there are even more damaging cases of embrace extend extinguish going on right now like With PepperFlash for example. There Chrome has broken video recording three times the past year by pushing untested code, it's not possible to permanently disable it and the last change actually requires users to click both the Flash allow box and the WebRTC allow box! That's without even mentioning the bug that if a user doesn't notice the second allow and refreshes the page, like every user does, the Allow box is never shown again.
  - jrockway 13y ago
    One wonders if users would even have Flash installed if it weren't sandboxed. http://www.cvedetails.com/vulnerability-list/vendor_id-53/product_id-6761/Adobe-Flash-Player.html http://www.cvedetails.com/vulnerability-list/vendor_id-53/pr...
jfoster 13y ago
It's worth noting that all of the APIs you mention in (1) are only available to Chrome packaged apps. These are essentially the .exe files of Chrome OS. They cannot be hosted on webpages (otherwise Google calls them hosted apps, and they can't access these APIs) and can only be distributed and accessed via the Chrome Web Store. It's essentially not much different from Windows having Windows-specific APIs for downloadable programs. "Chrome Packaged Apps" are the downloadable programs of Chrome OS.
jrockway 13y ago
I'm pretty sure dart2js runs faster than Dartium. Dartium is just for reducing the time the edit/test cycle takes and from what I've read on the mailing list, not intended to be something that end-users will ever see. In that respect, Dart is exactly like CoffeeScript or the many other attempts to fix Javascript. The Dart FAQ says: Q. Is Dart going to divert community effort from JavaScript-based web development? If people like Dart and use it, then to a certain extent, yes, but isn't this true of any improvement to existing web development? Nothing is zero-effort to learn or 100% back-compatible to legacy browsers, so people use both new and old. You might look at it this way: Google is putting significant effort behind both Dart and JavaScript, choosing to develop Dart while at the same time using JavaScript extensively, and working on JavaScript tools, implementation, and language spec. We're doing both because we think Dart is worth it. Server-side web programming finds room for many languages: does Python divert effort from Perl, and does Java undercut C++? Again, to a certain extent, yes they do, but people generally consider that a healthy situation, better than if we all used a single programming language. Multiple languages have allowed for faster change than any single language has achieved through a standards process. Furthermore, languages coexist in different niches: does Groovy really compete directly with C++? People face different engineering tradeoffs and choose different languages to meet them. Ultimately, we think client-side developers should have this kind of flexibility. Q. Is Google planning to put Dart under the control of a standards body? Yes, we hope to. Once Dart reaches a certain level of maturity and acceptance, we expect that a standards process will be the next step. As for the various APIs you describe above, those are all for packaged apps, which really have nothing to do with the web except that they happen to run inside Chrome. It's like complaining that iOS in-app purchases go through Apple, or that Gnome has Bluetooth support. (Or even that Firefox extensions don't work in Safari.)
- coldtea 13y ago
  >I'm pretty sure dart2js runs faster than Dartium. Not according to the benchmarks they give: http://www.dartlang.org/performance/ http://www.dartlang.org/performance/ Dart VM (Dartium) is about 2x as fast as Dart2JS (which is around 80%-90% of JS).
  - 13y ago
paulirish 13y ago
I think other folks covered this one, but yeah the difference here is that this expanded notification API is for Chrome apps, much like Mozilla has non-standards track APIs that are targeting Firefox OS apps. Chrome supports the W3C standard Notifications API: http://caniuse.com/#feat=notifications http://caniuse.com/#feat=notifications as well as edits the spec for it: https://dvcs.w3.org/hg/notifications/raw-file/tip/Overview.html https://dvcs.w3.org/hg/notifications/raw-file/tip/Overview.h... This works today in Chrome, Firefox, Opera. The permission model on packaged apps is completely different, and allows for APIs that have a lot more power (raw USB, TCP access) and as such, it's hard to find a way to expose them to the open web without permission bar overload. :/ I'd personally love to find a way to bring some of the powerful APIs that browsers are developing and exposing them to the web, but it seems like we're not there yet. For Dart.. think of it as another compile-to-JS language that was designed for large app authoring & maintenance productivity. Its performance as compiled JS seems to be pretty good already so you can target all modern browsers with Dart apps already. But, ultimately, I'm an open web kind of guy. My money's on APIs that the web shares and I see compatibility across the web as the characteristic that drives its power and reach. Chrome's working on a lot of APIs for the open web platform (see my links above) and is constantly working with other browser vendors to get feedback, buy-in, and identify the best APIs that the web can share.

by RyanZAG 13y ago

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.
        justinschuh 13y ago
        My statement was correct. It's not JavaScript, which is why you use a keyword to switch to a different compiler mode. It's a clever hack to use an equivalent subset of JavaScript as an IR (accepting a few polyfills). However, it's not exactly honest to frame it as "just JavaScript." What really does worry me is the ugly things that will be necessary to make asm.js genuinely viable as a platform. Yes, some proposals will have general utility for JavaScript, but many will not. And some will be downright dangerous. For example, how are you going to address pthreads compatibility, which e.g. Epic is saying they need?
        13y ago
- mraleph 13y ago
  Did you actually want to say "OdinMonkey was implemented very quickly, in about a month"? I am not sure I understand what people try to prove or imply when they say that. OdinMonkey takes an extremely limited statically typed language with an almost non-existent runtime library as an input, checks the types and pipes fully typed IR further through the existing backend (IonMonkey). Does it come as a surprise to anyone that this can be implemented quickly?
  - pcwalton 13y ago
    Yes, I meant to say Odin, sorry. Thanks for the correction.
hrjet 13y ago
asm.js works on all standards compliant browsers. Dart is a new language / VM and it's not standardized. So the logic is definitely not the same.

ahoge 13y ago

> Dart - obviously a way to create a two-tier web with Chrome being the only option for performance. The performance of the generated JavaScript is okay. Typically, it's somewhere around 75% of the performance of handwritten JavaScript and it's still getting better. Those -25% may sound like a big deal, but it's comparable to the performance from JS engines from last year.

md224 13y ago

To be fair, the first one you cited is for Chrome packaged apps, so I feel like it's a little different than special APIs exposed to normal web page javascript. It's the difference between saying "build apps for our browser, we give you powerful features" and "build web pages that only work in our browser." Now, if you think it's bad that Chrome is trying to entice browser app developers with powerful feature sets, that seems like a related but different complaint. It's possible I'm unclear on the scope of the Open Web movement. When it refers to web technologies, does it mean technologies employed in the service of presenting web pages (i.e. everything you can do with javascript, html, css, etc.), or any technologies that a browser serves as a platform for? Because the latter seems like a wider scope that encompasses more than just web pages.

mtrimpe 13y ago
It's not just this though, there are even more damaging cases of embrace extend extinguish going on right now like With PepperFlash for example. There Chrome has broken video recording three times the past year by pushing untested code, it's not possible to permanently disable it and the last change actually requires users to click both the Flash allow box and the WebRTC allow box! That's without even mentioning the bug that if a user doesn't notice the second allow and refreshes the page, like every user does, the Allow box is never shown again.
- jrockway 13y ago
  One wonders if users would even have Flash installed if it weren't sandboxed. http://www.cvedetails.com/vulnerability-list/vendor_id-53/product_id-6761/Adobe-Flash-Player.html http://www.cvedetails.com/vulnerability-list/vendor_id-53/pr...

jfoster 13y ago

It's worth noting that all of the APIs you mention in (1) are only available to Chrome packaged apps. These are essentially the .exe files of Chrome OS. They cannot be hosted on webpages (otherwise Google calls them hosted apps, and they can't access these APIs) and can only be distributed and accessed via the Chrome Web Store. It's essentially not much different from Windows having Windows-specific APIs for downloadable programs. "Chrome Packaged Apps" are the downloadable programs of Chrome OS.

jrockway 13y ago

I'm pretty sure dart2js runs faster than Dartium. Dartium is just for reducing the time the edit/test cycle takes and from what I've read on the mailing list, not intended to be something that end-users will ever see. In that respect, Dart is exactly like CoffeeScript or the many other attempts to fix Javascript. The Dart FAQ says: Q. Is Dart going to divert community effort from JavaScript-based web development? If people like Dart and use it, then to a certain extent, yes, but isn't this true of any improvement to existing web development? Nothing is zero-effort to learn or 100% back-compatible to legacy browsers, so people use both new and old. You might look at it this way: Google is putting significant effort behind both Dart and JavaScript, choosing to develop Dart while at the same time using JavaScript extensively, and working on JavaScript tools, implementation, and language spec. We're doing both because we think Dart is worth it. Server-side web programming finds room for many languages: does Python divert effort from Perl, and does Java undercut C++? Again, to a certain extent, yes they do, but people generally consider that a healthy situation, better than if we all used a single programming language. Multiple languages have allowed for faster change than any single language has achieved through a standards process. Furthermore, languages coexist in different niches: does Groovy really compete directly with C++? People face different engineering tradeoffs and choose different languages to meet them. Ultimately, we think client-side developers should have this kind of flexibility. Q. Is Google planning to put Dart under the control of a standards body? Yes, we hope to. Once Dart reaches a certain level of maturity and acceptance, we expect that a standards process will be the next step. As for the various APIs you describe above, those are all for packaged apps, which really have nothing to do with the web except that they happen to run inside Chrome. It's like complaining that iOS in-app purchases go through Apple, or that Gnome has Bluetooth support. (Or even that Firefox extensions don't work in Safari.)

coldtea 13y ago
>I'm pretty sure dart2js runs faster than Dartium. Not according to the benchmarks they give: http://www.dartlang.org/performance/ http://www.dartlang.org/performance/ Dart VM (Dartium) is about 2x as fast as Dart2JS (which is around 80%-90% of JS).
- 13y ago

paulirish 13y ago

I think other folks covered this one, but yeah the difference here is that this expanded notification API is for Chrome apps, much like Mozilla has non-standards track APIs that are targeting Firefox OS apps. Chrome supports the W3C standard Notifications API: http://caniuse.com/#feat=notifications http://caniuse.com/#feat=notifications as well as edits the spec for it: https://dvcs.w3.org/hg/notifications/raw-file/tip/Overview.html https://dvcs.w3.org/hg/notifications/raw-file/tip/Overview.h... This works today in Chrome, Firefox, Opera. The permission model on packaged apps is completely different, and allows for APIs that have a lot more power (raw USB, TCP access) and as such, it's hard to find a way to expose them to the open web without permission bar overload. :/ I'd personally love to find a way to bring some of the powerful APIs that browsers are developing and exposing them to the web, but it seems like we're not there yet. For Dart.. think of it as another compile-to-JS language that was designed for large app authoring & maintenance productivity. Its performance as compiled JS seems to be pretty good already so you can target all modern browsers with Dart apps already. But, ultimately, I'm an open web kind of guy. My money's on APIs that the web shares and I see compatibility across the web as the characteristic that drives its power and reach. Chrome's working on a lot of APIs for the open web platform (see my links above) and is constantly working with other browser vendors to get feedback, buy-in, and identify the best APIs that the web can share.