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?
> 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.)
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.
> 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.
> 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.
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.
The VBScript comparison dig is as old as it is wrong.
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.
Context: I'm using Dart for app development for two years now.
> 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.
The main example is that Dart's basic numeric types can't be represented in JavaScript. Dart VM integers are bignums, while dart2js numbers are IEEE754 doubles.
>Besides, all the languages that compile to JavaScript just add complexity layers to the already complex model of HTML/CSS/JavaS
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.
It doesn't look good. It's very well possible, but the other parties just do not seem interested. Maybe because they are currently investing in Javascript related technologies.
It's important to distinguish adopting a Dart VM from supporting Dart the language. Dart works fine in all modern browsers now by being compiled to JS. Doing that gives you the developer-time productivity boost of using Dart (which to me is the most compelling aspect of the language) while letting you ship your app to the entire web.
The VM is neat too, but from the user's perspective, it's an implementation detail. It's a really nice development tool, because it lets you run and debug your Dart code straight from source instead of trying to deal with generated code.
But I think it's relatively less important that the VM be shipped to end users. I think Dart can be a great, successful product without that happening.
It's not an issue. I've noticed dart2js performance is as good as hand-written js.
At least with dart2js I have just one "VM" to target - Google have sorted the x-browser issues for me. Imagine the peculiarities you'd find in Microsoft's implementation, for example.
One of the examples reminded me of some xml/html trivia I picked up a few years back -- attributes do not need to have double-quotes. (Yes, in practice you can leave out quotes altogether if the attribute has no spaces because browsers are tolerant, but the spec allows for single or double quotes, so if you're going to parse markup you need to allow for both.)
It occurred to me that HTML5 might have tightened up this rule, but it remains as before:
Implicit coercion is often a source of bugs. Some languages simply mandate that you be explicit about your intent. It can be slightly more verbose, but you gain clarity and reduce ambiguity.
With implicit coercion, the programmer must mentally keep track of how values get coerced (are negative numbers truthy? are empty strings? empty lists? empty objects?). Different languages have different answers for all of these things. As a result, I prefer to always be explicit.
If you've never seen the WAT?[1] talk, I suggest watching it. It has some great examples of type coercion gone wrong in Ruby and JS.
It's actually important to prefer .isNotEmpty over .length here. In some iterables (think generators, or sequences transformed by higher-order functions), calculating the length requires traversing the entire sequence where .isNotEmpty can stop after finding a single item.
I think this is wrong or at least misleading. According to the Ecma standard:
Boolean conversion maps any object o into a boolean. Boolean conversion is defined by the function application
(bool v){
assert(v != null);
return identical(v, true);
}(o)
Reading your quote from the ECMA standard, "no implicit conversions are supported" may be wrong but at the same time not generally misleading. That is, that function errors on null values and returns false for anything that isn't identical to true, so while it does provide a conversion to boolean from any non-null value, anything that isn't exactly a boolean "true" (unless I misunderstand what "identical" does) is going to return false on conversion. This is consistent with other writings on booleans in Dart [1]. So it appears that Dart has implicit boolean conversions, but it converts everything that is not the single "true" value to false, so using an expression that never can evaluate exactly to boolean true in a conditional (unless you mean it to be a wordy way to create unreachable code) is never something you want to do.
It's subtle. The conversion rule states that only `true` is true, `null` is an error, and everything else is false. However, the type annotation of `bool` means that in checked mode any non-bool value will cause a type error to be thrown.
The reason it's defined this way is for efficient compilation to JavaScript. Control-flow constructs don't have to perform a type-check, just a null check (which can be left out in cases due to null propagation).
Are you really worried about having to type 2 characters ('>0') more? I think people are too worried about syntax when it comes to programming languages. I guess it makes sense because that is what is most obvious when you look at a language for the first time.
There's an error in the section on literals. Literals used outside of classes do not have to be const. Not sure where that notion came from, but this is totally valid:
var l = [];
Also, the example of looping over characters in a String using substring is very odd and expensive. Generally, if you want to iterate over a list of single-character Strings, you'd use String.split():
for (var c in str.split('')) {}
split('') is necessary to be unicode safe. There's also String.codeUnits and String.runes (an iterable of code-points).
It seems to me that the majority of the time learning any new language is not the syntax itself, but memorizing function names and parameter order. Has there ever been an effort to design a family of languages which use the same function names and order of parameters for the same operation so that switching between them would be a matter of learning basic syntax?
This has got to be the worst learn x in y minutes that I've ever read. Whitespaces, anyone? Every example is compacted and very hard to read. Comments should document each line instead of a huge wall of text before the function.
Naming everything ExampleX is very difficult to see what is being talked about in this particular function.
I'm lucky to know enough about Dart already, because this is a very bad representation of it, IMO.
Perhaps you could contribute to the file via a PR instead of ranting at a post on a news aggregator? If people like you did then the open source community would be a better place.
41 comments
[ 2.6 ms ] story [ 84.1 ms ] threadhttp://www.chromestatus.com/features/6682831673622528
So in a few months we will have Google's VbScript available in Chrome.
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.
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.
The VM is neat too, but from the user's perspective, it's an implementation detail. It's a really nice development tool, because it lets you run and debug your Dart code straight from source instead of trying to deal with generated code.
But I think it's relatively less important that the VM be shipped to end users. I think Dart can be a great, successful product without that happening.
At least with dart2js I have just one "VM" to target - Google have sorted the x-browser issues for me. Imagine the peculiarities you'd find in Microsoft's implementation, for example.
It occurred to me that HTML5 might have tightened up this rule, but it remains as before:
http://www.w3.org/TR/html-markup/syntax.html#attribute
With implicit coercion, the programmer must mentally keep track of how values get coerced (are negative numbers truthy? are empty strings? empty lists? empty objects?). Different languages have different answers for all of these things. As a result, I prefer to always be explicit.
If you've never seen the WAT?[1] talk, I suggest watching it. It has some great examples of type coercion gone wrong in Ruby and JS.
[1] https://www.destroyallsoftware.com/talks/wat
The Angular team, for instance, has defined toBool() (which they use in directives like ng-if) like this:
It treats true and non-zero numbers as true, and everything else (including null) as false.At least for this particular example, dart supports an 'isNotEmpty' property on all iterables[0], so it'd just be this:
The core libraries support a lot of useful properties like that.[0] https://api.dartlang.org/apidocs/channels/stable/dartdoc-vie...
[1] http://blog.sethladd.com/2012/02/booleans-in-dart.html "The only value that is true is the boolean value true. [...] In a boolean context, everything that is not true is converted to false."
The reason it's defined this way is for efficient compilation to JavaScript. Control-flow constructs don't have to perform a type-check, just a null check (which can be left out in cases due to null propagation).
I rather like that you're forced to be explicit. Often, the (hidden) conversion is a source of bugs or confusion.
Naming everything ExampleX is very difficult to see what is being talked about in this particular function.
I'm lucky to know enough about Dart already, because this is a very bad representation of it, IMO.