6 ms·

I don't get why people make this VbScript comparison (sneer, actually). Yes, it is a language introduced by a single company, but then again many languages have

I don't get why people make this VbScript comparison (sneer, actually). Yes, it is a language introduced by a single company, but then again many languages have started that way, and in this particular case there are big differences between VbScript and Dart. I think Dart is a better language. Do you disagree?

dragonwriter 12y ago
> Yes, it is a language introduced by a single company, but then again many languages have started that way Including JavaScript. Acceptance as a standard usually happens after someone implements it, makes it widely available, and proves its merit, not the other way around (and standards that happen the other way around tend to be dead on the vine.)
- azakai 12y ago
  It's true that many current standards became accepted by force, after a powerful entity pushed them on the development world. However, that doesn't mean it's a good model. We do have a well-functioning standards process in the web space now - which we did not have back when JavaScript was introduced. The process isn't perfect of course, but nothing is. It seems quite insulting to that process for Google to go completely around it and ship major new features that have no interest from other parties, like PNaCl and Dart. With that said, I do agree with Google about its recent choice to go back to prefixed features, but only ship them to 50% of users; that avoids websites relying on them, but does allow testing "in the wild". I think that would be a far better model than Google has taken with PNaCl (shipping it to 100% of users). If Google took that approach with PNaCl and Dart (instead of what it has been doing with PNaCl), much of my objections would go away.
  - dragonwriter 12y ago
    > We do have a well-functioning standards process in the web space now - which we did not have back when JavaScript was introduced. The "well-functioning" process, to the extent it exists,includes the same features -- things are introduced by a vendor and proposed for standardization, but generally do not become standardized until there is uptake in the wild of the implementation. And, to the extent processes exist that didn't when JavaScript emerged and are even arguably "well-functioning", they apply largely to modifications to existing core web technologies (particularly HTML and JS), and not to new alternative or supplemental technologies, where, to the extent that processes exist, they are largely similar to (or exactly the same) processes that were available when JavaScript emerged.
    - azakai 12y ago
      > The "well-functioning" process, to the extent it exists,includes the same features -- things are introduced by a vendor and proposed for standardization, but generally do not become standardized until there is uptake in the wild of the implementation. True, but also one vendor does not ship the feature in a unilateral way, in opposition to all the others. > And, to the extent processes exist that didn't when JavaScript emerged and are even arguably "well-functioning", they apply largely to modifications to existing core web technologies (particularly HTML and JS), and not to new alternative or supplemental technologies, where, to the extent that processes exist, they are largely similar to (or exactly the same) processes that were available when JavaScript emerged. True to some extent (most standards work is incremental), but also entirely new web technologies have arisen through the standards process, such as WebGL and WebRTC. New web technologies can be added without unilateral and controversial action.
      - dragonwriter 12y ago
        > but also entirely new web technologies have arisen through the standards process, such as WebGL and WebRTC. WebGL and WebRTC are JavaScript APIs, not alternatives to core web technologies.
        azakai 12y ago
        > WebGL and WebRTC are JavaScript APIs I don't think that's a fair description. Yes, WebGL is a JS API but it is basically an entire interface to an OpenGL driver, it exposes a completely new language to the web (GLSL, OpenGL shading language), and it opens up huge new possibilities to the web platform. It has it's own standards group for good reason. It is not just a small incremental JavaScript API addition. Similarly, WebRTC brings with it codecs and networking capabilities far beyond what was possible before, but I do agree with you there that it is more incremental. But it is also not a mere "JavaScript API"; it is a networking API for the web. The web uses JavaScript, so it has a JavaScript interface. If it were meant to interface with GPU shaders, it would have a GLSL interface too, etc. > [WebGL and WebRTC are] not alternatives to core web technologies. Interestingly, one of Microsoft's objections to WebGL was that it competed with core web technologies. The argument was that hardware accelerated rendering was already possible through canvas and CSS. Technically that's true, but of course it misses the point that it gives full programmable GPU control, which canvas and CSS do not. But Microsoft did have a point, in that if you look at many graphical applications on the web, a lot of them can render to either canvas2D or WebGL. In some sense, the two do compete. There is also lots of experience with competing APIs. Like Pointer and Touch events, WebRTC and Microsoft's alternative, etc. So that something is an alternative to part of the web stack doesn't mean the standards process can't work for it.

dragonwriter 12y ago

> Yes, it is a language introduced by a single company, but then again many languages have started that way Including JavaScript. Acceptance as a standard usually happens after someone implements it, makes it widely available, and proves its merit, not the other way around (and standards that happen the other way around tend to be dead on the vine.)

azakai 12y ago
It's true that many current standards became accepted by force, after a powerful entity pushed them on the development world. However, that doesn't mean it's a good model. We do have a well-functioning standards process in the web space now - which we did not have back when JavaScript was introduced. The process isn't perfect of course, but nothing is. It seems quite insulting to that process for Google to go completely around it and ship major new features that have no interest from other parties, like PNaCl and Dart. With that said, I do agree with Google about its recent choice to go back to prefixed features, but only ship them to 50% of users; that avoids websites relying on them, but does allow testing "in the wild". I think that would be a far better model than Google has taken with PNaCl (shipping it to 100% of users). If Google took that approach with PNaCl and Dart (instead of what it has been doing with PNaCl), much of my objections would go away.
- dragonwriter 12y ago
  > We do have a well-functioning standards process in the web space now - which we did not have back when JavaScript was introduced. The "well-functioning" process, to the extent it exists,includes the same features -- things are introduced by a vendor and proposed for standardization, but generally do not become standardized until there is uptake in the wild of the implementation. And, to the extent processes exist that didn't when JavaScript emerged and are even arguably "well-functioning", they apply largely to modifications to existing core web technologies (particularly HTML and JS), and not to new alternative or supplemental technologies, where, to the extent that processes exist, they are largely similar to (or exactly the same) processes that were available when JavaScript emerged.
  - azakai 12y ago
    > The "well-functioning" process, to the extent it exists,includes the same features -- things are introduced by a vendor and proposed for standardization, but generally do not become standardized until there is uptake in the wild of the implementation. True, but also one vendor does not ship the feature in a unilateral way, in opposition to all the others. > And, to the extent processes exist that didn't when JavaScript emerged and are even arguably "well-functioning", they apply largely to modifications to existing core web technologies (particularly HTML and JS), and not to new alternative or supplemental technologies, where, to the extent that processes exist, they are largely similar to (or exactly the same) processes that were available when JavaScript emerged. True to some extent (most standards work is incremental), but also entirely new web technologies have arisen through the standards process, such as WebGL and WebRTC. New web technologies can be added without unilateral and controversial action.
    - dragonwriter 12y ago
      > but also entirely new web technologies have arisen through the standards process, such as WebGL and WebRTC. WebGL and WebRTC are JavaScript APIs, not alternatives to core web technologies.
      - azakai 12y ago
        > WebGL and WebRTC are JavaScript APIs I don't think that's a fair description. Yes, WebGL is a JS API but it is basically an entire interface to an OpenGL driver, it exposes a completely new language to the web (GLSL, OpenGL shading language), and it opens up huge new possibilities to the web platform. It has it's own standards group for good reason. It is not just a small incremental JavaScript API addition. Similarly, WebRTC brings with it codecs and networking capabilities far beyond what was possible before, but I do agree with you there that it is more incremental. But it is also not a mere "JavaScript API"; it is a networking API for the web. The web uses JavaScript, so it has a JavaScript interface. If it were meant to interface with GPU shaders, it would have a GLSL interface too, etc. > [WebGL and WebRTC are] not alternatives to core web technologies. Interestingly, one of Microsoft's objections to WebGL was that it competed with core web technologies. The argument was that hardware accelerated rendering was already possible through canvas and CSS. Technically that's true, but of course it misses the point that it gives full programmable GPU control, which canvas and CSS do not. But Microsoft did have a point, in that if you look at many graphical applications on the web, a lot of them can render to either canvas2D or WebGL. In some sense, the two do compete. There is also lots of experience with competing APIs. Like Pointer and Touch events, WebRTC and Microsoft's alternative, etc. So that something is an alternative to part of the web stack doesn't mean the standards process can't work for it.