4 ms·

NaCL was already part of Chromium prior to Blink, I hardly see the huge difference between NaCL and PNaCl in this regard. Besides that, Blink is the rendering

NaCL was already part of Chromium prior to Blink, I hardly see the huge difference between NaCL and PNaCl in this regard. Besides that, Blink is the rendering engine, Blink != Chrome. To get Chrome, you have to add in V8, NaCL, codecs, and a bunch of other stuff. I see the promises to which Blink commits itself as being disjoint from Chrome. After all, there are lots of Chrome-only APIs, like Chrome extensions, Chrome sync, Chrome packaged apps, etc.

espadrine 13y ago
It is my understanding that you cannot use Blink without V8. I believe it was part of the incentive to fork. Am I wrong?
- dragonwriter 13y ago
  > It is my understanding that you cannot use Blink without V8. I believe it was part of the incentive to fork. Am I wrong? Part of the incentive to fork was to avoid having to maintain support for multiple JS engines in the core project. I don't think that means that Blink requires V8 so much as that Blink's support for JS engines (compared to pre-split WebKit's) no longer includes explicit support for the engine used by Safari (whose name I can't remember) as part of the source tree, and presumably will over time be more tightly adapted to the needs of V8. This would seem to mean it will progressively become more difficult to build a Blink-based browser using a different JS engine.
  - cpleppert 13y ago
    They intend to tie V8 and the Dom deeper in the next versions of Chrome by using a new garbage collector. I'm pretty sure it will be well nigh impossible to use another Javascript engine.
pcwalton 13y ago
NaCl was never enabled for Web content, only for the Chrome Web Store. PNaCl is going to be enabled for Web content.
- dragonwriter 13y ago
  > NaCl was never enabled for Web content, only for the Chrome Web Store. PNaCl is going to be enabled for Web content. The plan announced from fairly early in NaCl's lifecycle was that when PNaCl was ready to be "fully released", it would be enabled for all web pages. The announcement this article points to merely restates that. It does not -- contrary to the article's treatment -- announce imminent plans to "fully release" PNaCl, or state that that release will happen without standardization. It simply assumes that that is the case. It may be true, it may not, but it certainly is incorrect to state that that is what was announced in the announcement which the article links to and bases its entire string of complaints on.
  - azakai 13y ago
    As mentioned above, I hope you are correct, but Google's announcement and statements in the Google IO PNaCl talk seem to show otherwise. If there is a misunderstanding, then hopefully Google can clarify. If Google only enables PNaCl on the web if/when it is on track to become an industry-accepted standard, then everything is ok from my perspective - I think you agree to that?
    - dragonwriter 13y ago
      > If Google only enables PNaCl on the web if/when it is on track to become an industry-accepted standard, then everything is ok from my perspective - I think you agree to that? I don't see how I could disagree with your description of what would be okay from your perspective. I'm actually not particularly concerned one way or the other; it certainly isn't as if Google hasn't pivoted to whatever the standard solution is in the past even when they've previously embraced (and enabled-by-default) a solution that ended up failing to become the standard. If Google was trying to push developer-focussed tooling as a business model and so was invested in its proprietary solutions winning, that would be different, but AFAICT there business model around improving web performance is to enable people to do more in the browser without relying on external code for the underlying OS, and if asm.js addresses that problem its just as good for them as it would be if PNaCl did it.
azakai 13y ago
> Chrome extensions, Chrome sync, Chrome packaged apps All those things are not enabled for web content. They are additional things that Chrome does, but they do not change how websites are built - they do not change the toolkit of things that web content has available to it. If you add an extension to Chrome as a user, or use Chrome's syncing, that's fine. You're modifying the browser in a way that you want. But if Chrome adds a feature to web content that is nonstandard, then it risks fragmenting the web: Some sites will use it, and they will only work in Chrome. That's what the standards process is meant to avoid.

espadrine 13y ago

It is my understanding that you cannot use Blink without V8. I believe it was part of the incentive to fork. Am I wrong?

dragonwriter 13y ago
> It is my understanding that you cannot use Blink without V8. I believe it was part of the incentive to fork. Am I wrong? Part of the incentive to fork was to avoid having to maintain support for multiple JS engines in the core project. I don't think that means that Blink requires V8 so much as that Blink's support for JS engines (compared to pre-split WebKit's) no longer includes explicit support for the engine used by Safari (whose name I can't remember) as part of the source tree, and presumably will over time be more tightly adapted to the needs of V8. This would seem to mean it will progressively become more difficult to build a Blink-based browser using a different JS engine.
- cpleppert 13y ago
  They intend to tie V8 and the Dom deeper in the next versions of Chrome by using a new garbage collector. I'm pretty sure it will be well nigh impossible to use another Javascript engine.

pcwalton 13y ago

NaCl was never enabled for Web content, only for the Chrome Web Store. PNaCl is going to be enabled for Web content.

dragonwriter 13y ago
> NaCl was never enabled for Web content, only for the Chrome Web Store. PNaCl is going to be enabled for Web content. The plan announced from fairly early in NaCl's lifecycle was that when PNaCl was ready to be "fully released", it would be enabled for all web pages. The announcement this article points to merely restates that. It does not -- contrary to the article's treatment -- announce imminent plans to "fully release" PNaCl, or state that that release will happen without standardization. It simply assumes that that is the case. It may be true, it may not, but it certainly is incorrect to state that that is what was announced in the announcement which the article links to and bases its entire string of complaints on.
- azakai 13y ago
  As mentioned above, I hope you are correct, but Google's announcement and statements in the Google IO PNaCl talk seem to show otherwise. If there is a misunderstanding, then hopefully Google can clarify. If Google only enables PNaCl on the web if/when it is on track to become an industry-accepted standard, then everything is ok from my perspective - I think you agree to that?
  - dragonwriter 13y ago
    > If Google only enables PNaCl on the web if/when it is on track to become an industry-accepted standard, then everything is ok from my perspective - I think you agree to that? I don't see how I could disagree with your description of what would be okay from your perspective. I'm actually not particularly concerned one way or the other; it certainly isn't as if Google hasn't pivoted to whatever the standard solution is in the past even when they've previously embraced (and enabled-by-default) a solution that ended up failing to become the standard. If Google was trying to push developer-focussed tooling as a business model and so was invested in its proprietary solutions winning, that would be different, but AFAICT there business model around improving web performance is to enable people to do more in the browser without relying on external code for the underlying OS, and if asm.js addresses that problem its just as good for them as it would be if PNaCl did it.

azakai 13y ago

> Chrome extensions, Chrome sync, Chrome packaged apps All those things are not enabled for web content. They are additional things that Chrome does, but they do not change how websites are built - they do not change the toolkit of things that web content has available to it. If you add an extension to Chrome as a user, or use Chrome's syncing, that's fine. You're modifying the browser in a way that you want. But if Chrome adds a feature to web content that is nonstandard, then it risks fragmenting the web: Some sites will use it, and they will only work in Chrome. That's what the standards process is meant to avoid.