111–120 of 162 posts
Earlier quoted context omitted.
"The Dart VM is not part of any web standard, nor part of a spec that has interest from multiple vendors" Which is... exactly the same situation JavaScript was in when Netscape introduced it.
Which is exactly the same situation that Javascript is in now . The Javascript VM in Firefox has features that are not part of any web standard, nor part of a spec that has interest from multiple vendors.
Earlier quoted context omitted.
In C it is almost customary to use `goto` as poor man's exception handler: you do `goto cleanup` from inside of nested ifs and loops if a fatal error happens and all you need is to clean up what needs cleaning and return an error code. The problem is that `goto` is easy to abuse, and, worse, easy to abuse inadvertently , e.g. you might produce a `goto` into a loop or something like that during refactoring. JavaScript…
It's important to remember that the "goto" Dijkstra is talking about is very different from the "goto" that C programmers use. He's talk about unstructured goto: jumping from the middle of one function to another, or across scopes . "Goto" as another local flow control construct is relatively innocuous.
Earlier quoted context omitted.
"The Dart VM is not part of any web standard, nor part of a spec that has interest from multiple vendors" Which is... exactly the same situation JavaScript was in when Netscape introduced it.
Which is exactly the same situation that Javascript is in now . The Javascript VM in Firefox has features that are not part of any web standard, nor part of a spec that has interest from multiple vendors.
https://developer.mozilla.org/en-US/docs/Web/JavaScript/New_...
Firefox 3.0+ added support for expression closures and generator expressions:
https://developer.mozilla.org/en-US/docs/Web/JavaScript/New_...
Firefox 22+ supports fat arrow functions. Just open the console and try it yourself:
>>> let z = x => x * x;
undefined
>>> z(5);
25
>>> let y = (a, b) => a * b;
undefined
>>> y(2, 3)
6
Earlier quoted context omitted.
Which is exactly the same situation that Javascript is in now . The Javascript VM in Firefox has features that are not part of any web standard, nor part of a spec that has interest from multiple vendors.
Yea, Firefox 2.0+ is shipped with support for generators/iterators, array comprehension, let, and destructuring assignment: https://developer.mozilla.org/en-US/docs/Web/JavaScript/New_... Firefox 3.0+ added support for expression closures and generator expressions: https://developer.mozilla.org/en-US/docs/Web/JavaScript/New_... Firefox 22+ supports fat arrow functions. Just open the console and try it yourself: >>> l…
http://wiki.ecmascript.org/doku.php?id=harmony:let
Arrow functions are being standardized as well,
http://wiki.ecmascript.org/doku.php?id=harmony:arrow_functio...
and for generators, the standards discussion led to a change in the spec, with the new version replacing the old implementation in SpiderMonkey (v8 recently implemented the new one as well).
In general see
http://kangax.github.io/es5-compat-table/es6/
where it lists compatibility for various new JS features. As it says there, let is supported not just in Firefox but also IE11 and Chrome 30.
It is true that Firefox shipped some of these several years back. I am not sure of the best way to find out exactly what the standards-track status was at those times.
But in general: Talking about the far past is counterproductive. We can probably find stuff that wasn't done properly by any browser if we look back far enough. But in recent years, there is growing consensus on the importance of not shipping non-standard things. That is the important thing I think.
Dart seems interesting, but its sponsorship by Google creates a major problem - what incentive does Microsoft, Mozilla, or Apple have to implement Dart support in their browsers? What about JavaScript devs who choose not to support Dart (especially since many still have to support even as far back as IE8 due to enterprise/companies/organizations/schools that opt for long-term support solutions for software)? I don't…
Earlier quoted context omitted.
Only until there is enough adoption for them to stop caring.
If there is that much adoption then the onus will be on Mozilla, Apple and Microsoft etc to step up and accept the will of web developers. Edit: and push for standardization.
We've seen that game before, played by microsoft.
Other browser vendors know this: Dart is never gonna fly outside of Google's walled garden.
Dart seems interesting, but its sponsorship by Google creates a major problem - what incentive does Microsoft, Mozilla, or Apple have to implement Dart support in their browsers? What about JavaScript devs who choose not to support Dart (especially since many still have to support even as far back as IE8 due to enterprise/companies/organizations/schools that opt for long-term support solutions for software)? I don't…
Dart also compiles to JavaScript, and was designed to do so from the very beginning.
This is really awesome! Congrats to the team! We have a ton of JavaScript/CoffeeScript code and I really wish we could use something like Dart. JavaScript is great for smaller projects, but once you get a ton of code it really becomes a unmanageable mess. I think tho' it would be amazing if Dart could run on the server side as well. This way you could just have one language on both the client and the server.
[1] http://www.techempower.com/benchmarks/#section=data-r7&hw=i7...
Earlier quoted context omitted.
If there is that much adoption then the onus will be on Mozilla, Apple and Microsoft etc to step up and accept the will of web developers. Edit: and push for standardization.
Then get left in the dust as Chrome takes advantage of undocumented features. We've seen that game before, played by microsoft. Other browser vendors know this: Dart is never gonna fly outside of Google's walled garden.
Sad to throw away the brilliance of prototypes to go back to single-inheritance classes. uck