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.
If you are looking for a structured language (for front end dev), Typescript is a better alternative imho. Javascript devs can still read it and it's compatible with any JS library out there.
Dart not so much since the semantics are different.You can still interact with JS libs but it's not as straight foward as TS.
I tested a number of options (GWT,Haxe,CS,Dart,Opal,Jsx,...),while i'm not a Microsoft fan(by a long shot),Typescript is the solution that allows the best integration with legacy code and pure JS libraries,while making easy to port old java/C#/as3 code to JS.
I've done a project in Dart and another in TypeScript and like them both a lot more than doing straight JavaScript. I appreciate the optional type checking in both and the IDE support that each enables. TypeScript is appropriate if your project is more quickly completed with existing libraries like jQuery UI and needs to run on older browsers. Dart is appropriate if you don't need to use older established JS libs and IE9 and above are your target requirements. I like having them both in the toolbox, but I prefer Dart slightly more than TypeScript for various reasons.
That's very different from Javascript (and from the untyped-language mainstream) but is it really "horrible"?
The type-checker will give a very clear warning if it catches you putting a non-bool in a conditional context. And make no mistake: the type checker is an important part of the Dart development process.
(One downside of this is that it does push you to working in the -- Eclipse-derived -- DartEditor, which isn't always a wonderful experience. However, the type checker is exposed and available, and there's nothing to prevent it being tightly integrated into other editors or IDEs.)
That's not a horrible semantic. There is one canonical truth value and everything else is false. It's the inverse of the Lisp semantic, where there is one canonical false value and everything else is true. I think it's better than the ad-hoc semantics of other scripting languages,[1] and more appropriate for a dynamic language than throwing an exception if a non-boolean is used as a predicate.
[1] And as a practical matter generates faster code, because it can be implemented with a comparison against a single constant.
Dart does run on the server. The VM runs standalone for scripts and long-running apps, and the dart:io library provides very node.js like file, network and HTTP APIs, with the addition of Isolates for actor-like concurrency.
In fairness to JavaScript, it is absolutely possible to write very large apps and keep them organized and maintainable.
I think the issue is that JS doesn't have strong conventions for how to do that, so you actually need to make good choices that work well with your app.
I have no doubt that Dart makes that stuff easier, but there's nothing inherent to JavaScript that makes it unsuitable for larger applications. It just forces you to make decisions.
> In fairness to JavaScript, it is absolutely possible to write very large apps and keep them organized and maintainable.
I see it a bit like when Dijkstra wrote "Go To Statement Considered Harmful". I have no doubt a lot of developers at the time objected to it and said "that is wrong, it is possible to write good code using GOTO". Because they probably wrote code using GOTOs and some of that code was probably decent quality.
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.
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.
How do you mean "Knuth won"? Can you paraphrase the paper? I couldn't find a one phrase or proof of this "winning".
Here is what Dijkstra said:
> "The go to statement as it stands is just too primitive; it is too much an invitation to make a mess of one's program.
"
How does Knuth win that?
In any case, I think there is a popular understanding of that phrase. It entered folklore to mean something else and regardless if that something else is different, it does make sense.
Excessive GOTOs complicate code and create a spaghetti mess. Today we don't need scientific papers on it. That is how I understand it.
The general idea is that there are better construct and better paradigms out there. Not all programming construct are strictly equal in practice. Yes all languages that are Turing complete can do the same kind of things. We know the theory. But it turns out some paradigms are better than others. OO programming, despite it being hated and derided today, was a better idea that writing lots of GOTOs. Functional programming with immutable data-structures does make sense in a distributed and concurrent environment. STMs compose better than locks and mutexes and so on.
Javascript comes from a school that most people simply didn't attend. But it's actually ahead of the curve by about 10 years, as evidenced by the emergence of Scala and co.
People have found success in managing large Javascript codebases through good design choices like module systems (AMD/CommonJS), using the SRP to keep modules tight, and testing. It's tough (nigh impossible?) to retrofit those design choices onto an existing codebase.
Dart and TypeScript seem to offer a more familiar path to people who are used to Java/.NET/etc and who have been burned by messy JS codebases.
Why don't you choose JSX or TypeScript? The latter is a superset of JavaScript, so migration should be a breeze.
If you'd like the same language for client and server side, try Kotlin or HaXe.
For now, Dart doesn't have a crossbrowser VM yet (except for Dartium), so it doesn't give you any performance boost over JavaScript. Maybe one day there will be a cross-browser Dart VM as a PNaCl or asm.js module?
Dart definitely runs on the server side. We had plain Dart and two of its initial web frameworks, Start and Stream, in Round 7 of our benchmarks project [1]. It performs modestly well, and I suspect there room to optimize further.
I'm curious - what stops you from using dart2js today? Isn't it kinda like CoffeeScript? If you already have the latter, you already have workflow for "something that compiles to JS" as part of your app.
Going forward, the Dart team will focus on improving Dartium, increasing Dart performance, and ensuring the platform remains rock solid. In particular, changes to core technologies will be backward-compatible for the foreseeable future.
Today’s release marks the first time Dart is officially production-ready, and we’re seeing teams like Blossom, Montage, Soundtrap, Mandrill, Google's internal CRM app and Google Elections, already successfully using Dart in production. In addition, companies like Adobe, drone.io, and JetBrains have started to add Dart support to their products.
Congrats to the team on releasing 1. Now to find a project to try it out in...
This is speculation: but JetBrains work on dart IDE, android releasing ART, I'm tempted to say we're 2 years out from seeing DART running on android. It makes sense from a business sense, have the option of running dart apps on android would free the platform from its java dependance.
I hope that you are correct! That would be great. I have experimented with Dart on both client and server and it is a nice language. Fun to develop with.
I think Dart has the potential to become a target for other languages [1]. The already-high-level code has a performant VM and it takes advantage of optional typing (unlike any other VMs I am aware of). In order to do so though, they should at least make a spawnString (like isolate's spawnUri) or even better, have the ability to JIT dart code by string but not execute it right away.
ES4 failed mainly because some people thought ES3 was good enough.
Adobe,harshly critized for Flash was the one pushing for a better javascript.
I will never understand why Microsoft basically killed ES4. They had their own implementation on .net ( JScript.net ) so it's not like it was going to be a huge effort. The only reason would be Microsoft pushing Silverlight at that time which was a huge flop. We basically lost a decade because of it, as i predict javascript will eventually look like ES4,that's inevitable.
People without an investment in Javascript have lost over a decade because of Javascript's monopoly on clients being maintained. If we had not been forcibly locked into Javascript all this time, then competition would have produced a better alternative or whipped the process designing Javascript into shape. Now we are stuck with this ridiculously tall, messy stack which uses an application scripting language as a compile target, still lacks basic features like a standard package system, and pushes trivial language features like iteration into third-party libraries like jQuery. So now we are constantly pushing megs of JS, using insanely complicated build systems to get anything done, and for all this trouble our code runs at a speed roughly equivalent to C in 1998.
(Now that Flash and Silverlight are dead I think it is safe for me to complain about Javascript without being an enemy of the open internet or whatever.)
I don't really care about Dart, but it's way past due that there was something serious to challenge Javascript. All the triumphalism about how Javascript is already a perfect language to use for eternity is explicitly counterproductive. Making the whole internet depend on the fortunes of one language just sucks.
> So now we are constantly pushing megs of JS, using insanely complicated build systems to get anything done, and for all this trouble our code runs at a speed roughly equivalent to C in 1998.
Those who care, just keep happily using plain native applications.
> I will never understand why Microsoft basically killed ES4.
Simplicity of the language.
I'll easily agree that ES4 would have been very interesting, but ES5 (and its spiritual successor features in ES6) gave us subtle low-level power that would have lacked otherwise.
> In order to do so though, they should at least make a spawnString (like isolate's spawnUri) or even better, have the ability to JIT dart code by string but not execute it right away.
Of all of the core libraries in Dart (core, html, io, async, etc.) the isolate library has had the least attention so far. Now that those other libraries are stable, I'm hoping the corelib folks will have the time to give isolates some much needed love.
I definitely want spawnString() too and we've had to do some gross workarounds in pub to deal with its absence (dumping stuff to temp files).
So if i get it right, the way "Google" sees the future, there is Go at the server side and Dart at client side (which is in fact JS). Am I wrong?
I would expect Google, or at least, a team at Google, to take over NodeJS which is based on their V8 and expand it to universal server client language and libs. JS can be complied into go binaries after all, so why not letting people write apps using the same language.
Let alone I see no effort on their side bringing any of those language into the native world of Android, instead we got this cluttering Java thing as almost the only options for most projects.
> So if i get it right, the way "Google" sees the future, there is Go at the server side and Dart at client side (which is in fact JS). Am I wrong?
Yes, you are, in fact, wrong. Google doesn't have so narrow a vision. Dart is server and client side (the native VM is, aside from a for-testing-only build, server-side only now.) But the client side isn't just Dart (or JS, in which Google has also invested heavily), its also C/C++, and other languages, hence PNaCl, which also just went into general release.
And, sure, Go is a server-side language that Google is putting energy into, but so is Dart. And I doubt their vision ends there, those are just a couple of the more visible active fronts.
> I would expect Google, or at least, a team at Google, to take over NodeJS which is based on their V8 and expand it to universal server client language and libs.
The existing NodeJS team is doing enough for server-side JS-on-V8, and its open source -- Google could throw more resources, but its probably not the best bang-for-their buck in terms of developing new technologies that might improve the options for the things Google is concerned about. Doing what other people aren't doing is a bigger win.
> Let alone I see no effort on their side bringing any of those language into the native world of Android
I've seen quite a bit about Dart on Android (though I think there are issues with building the current distribution.) Less on Go.
The point of view within Google that spawned Dart is that JavaScript as a language has major and unfixable flaws that severely raise the cost of developing large apps. It's nice that node.js uses V8, but being based on a Google project does nothing to address the language issues.
Note that that point of view is not universally shared at Google, and many people are fine with JavaScript, and probably would use node.js.
> I see no effort on their side bringing any of those language into the native world of Android
The Dart VM supports ARM, and I've seen prototypes that get it running on Android. The team hasn't had much time to put into it yet, but I wouldn't infer that that says much about what we'll do in the future. (Not that I'm making any promises, either.)
And don't forget AngularDart or whatever for the front-end framework. I wish the name "Google" wasn't attached to any of these projects as I'm a huge fan of them but not the company they're born out of.
They avoid attaching Google name to those projects and their licenses are proper. There is no "Google" word in the dart front page except "Dart is an open-source project with contributors from Google and elsewhere.".
I am a newbie in field of Web Development, and recently I felt in love with JavaScript, especially because of the sheer capability to write Client side and Server side code in same language. Thanks to Meteor.js, it made my bond with JavaScript even more stronger.
But now with the buzz of Google Dart going around, I am afraid that, am I betting on the wrong horse? Is it the right to jump on Google Dart bandwagon? To be honest, it do looks promising.
Please guide me, what should I do, since I am a newbie, I want to take advantage of the fact that, since I don't know anything, I better learn something that have much promising future, and have an edge over technology.
Honestly, JavaScript has orders of magnitude more usage and a lot more momentum than Dart does. I don't think you'll be harming your career prospects in becoming proficient in JS.
I also think there are better choices than Dart if you want to learn something that will expand your mind. Dart strikes me as a very practical language.
ALL the committers are from Google and it is not an open standard which basically eliminates any chance that Mozilla/Apple will ever consider adopting it. And frankly with Apple dominating the mobile web without them any solution will never eventuate to anything.
How many years did it take JavaScript to become a multi-vendor standard?
Let's see... Netscape Navigator 2.0 was shipped with it in September 1995 and ECMA-262 1st Edition was written in June 1997 and finally approved in April 1998.
However, the 1st edition was done entirely by Netscape (by the looks of it). So, this doesn't count as a multi-vendor standard since there wasn't any involvement by any other vendor.
Looks like you're being a bit unreasonable. Dart isn't even shipped yet in one browser and you're already complaining that it isn't a multi-vendor standard yet. Going by JavaScript's timeline, it still has more than 3 years for getting to that point.
I have spent time with both Dart and with JavaScript + Meteor. Both are good stacks. If you are already up to speed on Meteor, why not just use that for a year, build applications, and maybe look at alternatives later.
It is probably best to start writing web apps, and not on learning many tools.
JS prototypes provide a single parent lookup delegation, which is not that different from single inheritance and is mostly used to emulate single inheritance class systems in the wild.
Furthermore Dart supports mixins, so it's not exactly single inheritance classes.
My thoughts exactly. Dart is representative of 90's language design and as such is a step backward. That's not to say JS doesn't have its issues, but Dart isn't the solution.
Could you explain the brilliance of prototypes? Prototypes in JavaScript are pretty awful, but I've never been sure if that's just the JavaScript implementation (for instance, the lack of a good way to clone an object makes using prototypes in JS more painful than it needs to be), or the concept of prototypes more generally.
Psyched! See our HN post about our Dart app (Dart rocks) and our team's disappointment with not being included in the 1.0 announcement. https://news.ycombinator.com/item?id=6735044
I don't know anything about what went into deciding which companies were mentioned in the announcement, but I know for certain I and others on the team have a ton of respect and gratitude for all of the help you and Kai have given us. Thanks!
Sorry folks, I thought and still maintain that our situation was relevant to other startups and hackers. I thought we'd get some critical feedback, and we did. And yes, we wanted to tell our own story with respect to Dart since we had been expecting to do something like that for some time as part of Google's announcement. The post is removed and we're moving on.
Some people wanted to build optional-typing language for real world for decades, and finally made it. That is a great achievement.
From product point of view, Google would be much better to port Android Dalvik to Chrome. You can run GWT Java code in browser years ago. Running the same code using JVM would be much faster with much less code change. 5-10 man-year would be enough to do the porting, and it will share work between Android and Chrome for years to come. Of course, it would be much boring research work though.
From performance point of view, asm.js gets much better performance with way less work. No matter how good Dart performs, it would never make sense to port high performance C/C++ game code to Dart, so you end up having to use both Dart + pNaCl, which is an awful solution. Technically, TypeScript is more interesting if Microsoft can keep it simple and fast, but I doubt Microsoft would make anything simple.
Without any additional special assumptions about the someone and their particular circumstances, learning JS is probably a lower risk investment, learning Dart is probably higher risk and higher potential payoff; thinking only in terms of future income potential.
I really like Dart and hope it - or something like it - replaces javascript soon, but I'd heavily recommend learning javascript instead. I'll be quite some time, if ever till Dart is even 1/4 of the client side market.
Even if you did learn Dart, you'd inevitably have to include external javascript libraries, so you'll have to know javascript anyway.
And Google is still actively promoting javascript in things like AppScript and Angular js.
Even if you use language X that compiles to javascript ,you still need to learn javascript, Or it's a bit like learning rails without understanding ruby.
Why do you need to learn JavaScript to use Dart? You need to understand the DOM and the browser APIs (presented through Dart libraries), and HTML, CSS, but you very much don't need to know a jot of JavaScript to build and deploy Dart or dart2js applications. Even the Dart2js output has sourcemaps letting you view source in the original Dart.
You can do Rails to a fair extent without really knowing Ruby, and just fumbling through it with a bunch of gems and messy code. In some ways it can be the gateway to learning Ruby itself, if you were so inclined to do so.
For things like CoffeeScript, which are fairly thin layers over another language, I'd always advise to just learn JS first. Dart and Clojurescript though are so far removed from their compilation target that you don't really need to know the JS, as long as there's good library support for what you want to do. In the case of clojurescript the interop is so seamless that it puts the focus on learning the APIs, which is where the true complexity lies. Of course, and even more so with typing, you also have the compiler to back you up.
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 think good answers are available to these questions, which makes me hesitant to jump in as quickly.
It adds complexity to the dev process, and I'm not sure of the benefits of said complexity. The devs still at the core need to understand JavaScript it seems like.
> The devs still at the core need to understand JavaScript it seems like.
No, that's not the case. You need to understand the browser DOM, and the various APIs available to you, but these are presented by Dart libraries. If you have knowledge of Java or C#, then that knowledge will be useful, and if you have knowledge of JavaScript's functional elements, then that is also useful, but none of that is mandatory to be effective with Dart.
But if you're using third party JS libraries and want to integrate with a Dart app? Seems necessary to still have to understand JS to integrate properly since you still have to know how those libraries' API works.
Opinion: nobody should be shipping any JS to oldIE, period.
Their JS engines are woeful. Even if you can get something app-like (the kind of thing you would use dart for) to work, your app won't scale w.r.t. perf so you're painting yourself into a corner.
Some do, of course, but some of the rest of us are more interested in future advantages. If you need to target legacy browsers, legacy technologies are widely available.
If you'd like the future to be as good as possible, you might want to build new tools without the same old constraints.
I personally built a single page application about 2 years ago that worked in IE8, thanks to jQuery and the ecosystem of the time. jQuery, jQuery UI, various plugins incl. jsTree & DataTables.
It flew in Chrome, Firefox and Opera, even then. In IE8 it was slow as hell. Event listeners were slow, ajax and parsing JSON was slow. Everything was crazy slow. The app felt lumpy and awful. And when I hit bugs, the developer tools just were not there.
I would never do this again.
I'd wager that for IE < 8, for any non-trivial app, round-tripping to the server will give you a better UX than using JavaScript.
The one I am using (and I don't even remember which one it is or if there are multiple ones) does basic highlighting. There is no re-factoring support that I could find yet.
They need make some changes in Chrome for doing this right. They aim to make DOM nodes garbage collectible with project oilpan [1] AFAIK. Both Dart and V8 VM will benefit from this. So this will take some time. But Dart is already very useful with Dartium for development and Dart2Js for deployment.
They are working on an experimental solution to let garbage collection happen for DOM nodes that are created from Dart or V8. This basically requires a rewrite of the memory management of DOM nodes. This is still very much a work in progress and not ready for prime time.
The solution the team uses for Dartium is not the same as what they want to do for the shipping version of Chrome, so it'll be a bit before that's ready.
> Why doesn't Google include the native Dart VM in Chrome?
Probably because Dartium (Chome w/Dart) doesn't yet have the kind of performance advantage that makes it compelling enough to split the web that way -- making developers use dart2js for client code means that you don't need separate client code for Chrome (Dart) and everyone else (JS) -- and needing to commit to extended support of two different scripting runtimes in Chrome for the future.
> Browser vendors are free to integrate the VM into their products, and if they don't want to there is dart2js which is acceptable.
That's a tremendous amount of effort and it is likely to reduce the performance of JavaScript. Cross-language GC, in particular, is really hard. See Filip Pizlo's message to webkit-dev on this subject (citing two recent papers), which is part of the reason that Dart support was shot down when Google proposed adding it to WebKit: https://lists.webkit.org/pipermail/webkit-dev/2011-December/...
As of today, dart2js is the only way to deploy Dart to users' browsers, Chrome included. It already performs well enough for most apps.
The Dart VM is nice but its primary purpose right now is running the Dart compiler and in Dartium which is only used by developers. (You can use it for other things but the ecosystem isn't there yet.)
Right, I can understand that. It's a lot of effort to put in up-front just to support Google's pet project of the day.
This is a really good reason why dart2js exists and why so much effort has been expended in making it good.
However, I think that if Dart proves to be a compelling platform for developers I don't think it's out of the question for browser vendors to put some serious thought into integrating the Dart VM natively alongside JS.
After all, Google is going to be doing exactly that with Chrome/Chromium...
> Browser vendors are free to integrate the VM into their products
No they aren't. Integrating a Google-controlled VM into any software project (for example, Firefox) isn't trivial (you need lots of resources for it) nor is desirable (the technology is driven and controlled by Google).
You points don't speak to the statement. Browser vendors are FREE to integrate it. Whether they will because of the technical costs is a totally separate statement and quandary.
Google web developers who want to deploy their apps need to use dart2js. Google web developers need to make sure their apps work in all modern browsers. If the Dart team wants to promote adoption even within Google (and they do) they need to support all modern browsers.
Dartium and dart2js already aren't quite in sync; numeric types work differently for example. But they're close enough that for most apps, you can develop in Dartium and deploy on dart2js and the language differences don't really bother you. The language differences between Dart-in-JavaScript and Dart-in-Dartium are a lot less than the differences between browsers that web developers deal with all the time.
If there's enough adoption, then I'd expect other browser developers either to build their own Dart runtimes, or -- since its free -- use or fork Google's.
And, then, sure, Dart2JS stops being important to Google because its unimportant to how Dart code performs on the web. But its unimportant to Google because its unimportant to anyone, since it won't matter to users, either.
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.
People don't really remember what the Web looked like back in Netscape Navigator days. Back then IE replicated some quirks from Netscape so websites would look similar.
Well, Dart will eventually work best on Chrome because of the Dart VM. There's nothing stopping Mozilla from adding the VM to Firefox, of course. Getting an additional 2x-4x performance boost would be great.
There are at least two problems with adding the Dart VM:
1. Standards. The Dart VM is not part of any web standard, nor part of a spec that has interest from multiple vendors, so it should not be shipped in a standards-compliant browser. This is a matter of principle that most browsers agree on these days, see for example Google's Blink guidelines: http://www.chromium.org/blink#new-features
2. Effort. Adding a new VM into a browser is a huge amount of effort. The VM can't just be added even if it is open source (which it is) - it's very hard to integrate such a thing properly into a browser, technically speaking. Also aside from technical effort, there is also effort to start a new standards process for a new language.
> 1. Standards. The Dart VM is not part of any web standard
I can see how many would see that as tail wagging the dog. But I see your point. And I agree it should be part of a standard. However I would imagine (and correct me if I am wrong) it is a lot easier to approve and go through the standard approval if there is already an implementation out there to look at. Standardizing on a hypothetical future feature via a large committee, doesn't work too well.
> 2. Effort.
Here, again, this is not a hypothetical, we haven't proven if it is possible we are just dreaming about adding a VM. Dartium works today. Presumably other would have a bit less work to do but it depends on how DOM interaction differs between them.
EDIT: 2nd part initially completely didn't make sense
> However I would imagine (and correct me if I am wrong) it is a lot easier to approve and go through the standard approval if there is already an implementation out there to look at.
I think you are correct. But that implementation does not need to be shipping on by default in a major browser like Chrome.
If Google would promote Dart mainly through dart2js, but not ship the Dart VM in Chrome, then I have no problem with that, and even the opposite - that would be quite cool, new languages are always nice to have. Then, if Dart catches on with developers in the industry, I think it would be very appropriate to discuss standardizing it. The momentum among developers, plus an existing VM that runs it even better, could be a compelling combination, and browser vendors could discuss that in a fair and open way.
But to ship the VM in Chrome far before any of that is a violation of the basic principles of the standards process. It sends the message that Google intends to use Chrome's huge and growing market share to force the market to do what it wants, instead of following the standards process. Perhaps that is not what Google intends, but that is how it can appear.
For that reason, I think that shipping the VM in Chrome is counterproductive if Google wants to standardize it, since it antagonizes all the rest of the industry.
> But it is also not vaporware.
Sorry if I wasn't clear, I never said anything to the contrary? Not sure what you are responding to here - the quote you refer to is about "Effort", where I talked about the effort for other browser vendors to adopt the Dart VM, not for Google. Clearly Google has a working VM today.
> But it is also not vaporware.
Sorry if I wasn't clear,
Sorry for the confusion, I read that somehow as effect on Google's part to integrate the browser in Chrome in order to have an example of it running to speed up the approval process. I see how it was a total brain fart on my part. Disregard that one. I updated it with actually what I think I was saying.
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.
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).
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.
Unfortunately, though, this kind of goes against your argument which I understand to be "how dare Google release something that is not standards based". I agree principle with that, _but_ in this case a few posts did show example of technologies that all browser vendors introduces that were outside the spec.
> But in recent years, there is growing consensus on the importance of not shipping non-standard things.
Others might read that as no new and meaningful technologies will be seen implemented in the browsers soon. I can't think of too many thing designed and build by an intercompany commetee.
I don't follow, why does it go against that line of argument? If someone else did something bad in the past, it doesn't excuse doing something bad in the present.
(And as mentioned above, I'm not sure about those examples - while it's very possible some were released before being standardized, I didn't see a link showing that, and they are all being standardized now. Need more info.)
Fair point about the limits of things designed by committees. But it isn't always true, just mostly true ;) For example, WebGL was designed through a standards process, and it is great.
Regarding Firefox 22, that is recent, but I don't see a link showing it shipped something nonstandard and that was not being standardized? In fact I showed a link for the standardization process for arrows? Revision history for that page seems to show that it predates Firefox 22.
> Nothing of this is in ES5.1.
They are in ES6, which is being standardized, has interest from multiple vendors, is heavily discussed by multiple vendors, and has implementations by multiple vendors.
I never said everyone should wait until a standard is 100% final. Just like the Blink principles say, it can be perfectly valid to ship something that is being standardized, so long as there is interest from multiple vendors and work on standardization.
The risk is of one vendor shipping something entirely unilaterally, with no respect for any standards process. That's not what happened with arrows.
> > they are all being standardized now
> Yes, just like Dart.
AFAIK no other vendor has expressed any interest in Dart. The opposite in fact, Apple opposed including bindings to WebKit that would allow additional languages to JS. Please correct me if I am wrong?
> Anyhow, you seem to think that this kind of thing is a problem. It's not. This is how the web works. This is how progress is made.
I disagree. Why then do you think Google wrote the Blink principles about avoiding shipping something before it is standardized or has multiple vendor interest? Why did Google stop shipping vendor-specific WebGL extensions? In both cases Google is showing what most vendors consider proper behavior today, and I think Google is doing the right thing. Do you think Google is wrong in both cases?
Not sure asm.js would make sense for something like Dart, since it is mainly intended for things like C and C++ (Dart is a dynamic language, and needs different forms of optimization).
However, I think it would be fun to explore that direction! I'd be happy to collaborate with Dart VM people on that.
I suspect you might be right, but I am far from certain - can you elaborate?
My concerns are about things like PICs, but code generation is possible, so replacing functions to change PICs is one way to implement them. This is, I think, how the Graal project does JavaScript and Ruby, and they get very good performance.
That's a fair point in that yes, JavaScript was nonstandard when it was first included in a web browser.
But it is an incorrect point in that the field has changed a lot, for the better - most or all browser vendors want to play nicely these days. Even Microsoft is supporting the standards process and implementing WebGL, for example. The principles guiding browser vendors are more like these which Google wrote for Blink:
> In practice, we strive to ensure that the features we ship by default have open standards.
That was not the case 18 years ago, but thankfully it is today. 18 years ago it might have been common practice to just ship a new VM in a browser, but to do so today with no regards for the standards process would be unexpected and improper.
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.