They are. Check "In Development" section.
http://www.chromestatus.com/features/6682831673622528
So in a few months we will have Google's VbScript available in Chrome.
http://www.chromestatus.com/features/6682831673622528
So in a few months we will have Google's VbScript available in Chrome.
VBScript was IE only, because VBScript didn't compile to JavaScript. Dart compiles to JavaScript and runs on IE, Safari, Chrome, Firefox and Opera. VBScript didn't have a specification accepted by any standards organizations, Dart is ratified as ECMA 408. VBScript is not open source, Dart is.
The fact that Dart has been used in production years before any VM in a browser should show how different they are.
Not all language features can be represented in JavaScript.
Besides, all the languages that compile to JavaScript just add complexity layers to the already complex model of HTML/CSS/JavaScript.
And I bet there is a VbScript to JavaScript somewhere out there.
> Dart is ratified as ECMA 408. VBScript is not open source, Dart is.
Standards by themselves don't foster adoption.
Eiffel, Ada, Modula-2, Extended Pascal, Common Lisp, Smalltalk, ... have ISO/ANSI standards.
In the 60 - 90's being open source wasn't a requirement for multiple implementations for programming languages.
> Not all language features can be represented in JavaScript.
I could not name one (except the dart:io stuff, which is not supported in the JS world). Could you please elaborate?
> Besides, all the languages that compile to JavaScript just add complexity layers to the already complex model of HTML/CSS/JavaScript.
I've found the same, but Dart is a surprising exception. If you are not using any fancy framework (e.g. Angular.Dart), you will be just fine with the close-to-the-browser approach of the language and APIs.
They can be represented in JS, but not natively.
Does it? Because HTML/CSS/JS development is a bit of mess to begin with (and complexity rises when you start adding micro-frameworks into the mix - and you kinda have to if your codebase gets to be a decent size). I've done some Dart web-development, and it's cleaner and nicer.
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.)
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.
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.
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.
WebGL and WebRTC are JavaScript APIs, not alternatives to core web technologies.
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.