However, Dart is a 'full stack' solution. This means that any developer taking over Dart would have to support the IDE, the VM, the javascript transcoder, the language, integration with new browser features, cross browser compatibility, etc. This is practically impossible for hobbyists to do properly.

Why would Google drop Dart? Google is almost guaranteed to drop any project that does not have high traction and/or high income within a few years of release. Dart has neither income nor traction. If Google does not drop it, I will be very surprised and impressed.

I highly recommend avoiding Dart, but obviously the choice is yours. You've been warned.

EDIT: Just to add, Google can artificially increase traction of Dart by putting the Dart runtime inside Chrome and using that as a weapon to increase Chrome adoption, similar to Microsoft's ActiveX strategy. If Google does this it would be a pretty evil thing to do and go against the spirit of the web.

If your ethics are a bit lacking, you may want to try betting on this effect which would create a demand for Dart dev houses in the future, and could make you some cash.

Likewise. As it happens, my model's* 5-year survival prediction (=Dart being supported by Google in ~March 2018) is just 21%. I can't say I really disagree.

* http://www.gwern.net/Google%20shutdowns

This is entirely hyperbolic. ActiveX was an entirely closed source system including the browser it ran on. Not true for Dart or Chrome. In fact you can already get Dartium (http://www.dartlang.org/docs/dart-up-and-running/contents/ch...). These scenarios are not even remotely similar.

It may not be a Microsoft feature but it's basically being treated the same as one. Native Client is getting similar treatment.

Dart's also friendly with the web. It has a full DOM API and JS-interop. It's not a plugin.

Also I don't think it's clear whether or not Opera will include a DartVM by virtue of Blink.

I think it's pretty likely that Opera might include it, and that could change things - even though their marketshare tends to be kind of small they've traditionally had some power in terms of boosting adoption of new tech.

Chrome itself gained in traction because V8 was faster for a while. Putting Dart VM in Chrome and getting another competitive leap seems like a no-brainer. Not sure how that is evil or going against the spirit of the web. It's a one-liner to have it use the Javascript version, making it available in other browsers. It's not like ActiveX, as far as I can see.

In practice, Dart is a decent enough compile-to-Javascript alternative with a low barrier to entry. And it works as advertised. Easy to learn, use, and debug. And the claims about structure are true.

As far as I can tell, the lack of conviction is as much about seeing where developers are headed as anything. Why spend a lot if there won't be adoption. It's a tough call for Google in a pretty crowded and evolving space (ie, compiling to Javascript).

I should add tha NaCl and LLVM complicate the vision of the future for web technologies as well. Hard to place a bet at the moment.

It's against the spirit of the web because:

1. Dart is controlled by a single player

2. Dart was implemented by a single player

3. Dart was designed for the needs of a single player

4. Dart was designed in secret before being released to the world

Those four factors combined make it seem evil even if it's not, and definitely contributed to the negative reaction it got from WebKit.

If using Dart means relying on Dart2JS (which it does, because Google completely failed to get any other browser vendors to consider adopting it so far), then Dart is now just another competitor to things like GWT, Emscripten, TypeScript, etc. Dart2JS at least delivers reasonable performance thus far but it's hardly a compelling option compared to actually writing the language that runs in the browser, especially given that it has an entirely new home-grown set of libraries that aren't mature yet.

If Dart is still alive 5 years from now, however, a lot of these factors could change. If it manages to prove itself somehow, maybe a Dart VM would get into WebKit or Gecko (seems unlikely due to implementation hurdles though), and the libraries will absolutely be mature by then.

2. Goes along with (1), for something at this stage. That will change if Dart is successful.

3. False. Dart is designed for the needs of larger, structured web apps and teams. That certainly includes more than Google.

4. Dart was released pretty early in it's development cycle. The language has changed a _lot_ since then. We've gone though a couple of complete compiler implementations too. It's generally good to have some working proof of concept when announcing something like this.

The Canvas spec is a complete steaming pile of nonsense that again, has only been iteratively improved into a more useful state by the tireless efforts of the whatwg (and whoever was maintaining it before them, I don't remember). Canvas delivers miserable performance and a crippled, arbitrary feature set that was clearly designed for the specific purpose of solving whatever problems Apple had at the time.

Compare Canvas with WebGL, if you like: WebGL was developed in the open, based on an established, proven API that had been used to solve problems for decades, and it is quickly gaining on Canvas for many use cases due to that - even though it's lower-level, harder to use, and less widely supported.

You can say Google is designing Dart for everyone, but because design occurred behind closed doors at Google, nobody else had a say. It doesn't matter how hard you tried to anticipate people's needs if you didn't ASK THEM or let them tell you what their needs are!

You don't have to announce a project the day you start working on it, and there's a huge difference between announcing an idea or an initiative with a proof-of-concept and what Google did with NaCL and Dart, where something was announced along with the intent to ship it as a built in special-purpose binary blob in the browser and expose it to the web, regardless of the thoughts or intents of web standards folks and the community at large.

WebGL is, as you alluded to, based on OpenGL, which at one time came from the "single player" of SGI.

If traced back far enough, virtually every useful technology was at one point the product of a single person or single team trying to solve a problem. I can't think of a single situation in which a committee of companies came together and said "We must solve this problem", and then successfully jointly produced a technology which solves real world needs that wasn't based on something a single player had initially produced. Useful technology always has a range of being the product of one team, becoming some level of de facto standard, and then eventually (if the industry benefits from doing so) becoming a more committee-based standard.

The Mozilla folks, with all due respect, tend to suggest that any new technology they adopt must be created by large committees initially whenever they are getting on Google's case for things like Dart and PNaCL, while conveniently ignoring that nothing ever works that way, even the technology that they do decide to support.

Yes, Khronos is gross, OpenGL is gross, whatever. None of that undermines the stunning success of WebGL when compared with similar young web technologies. I don't even like OpenGL, I'm a Direct3D fanboy - but WebGL is still the model to follow here based on how things have turned out, IMO.

I've yet to see an API come out of Google's current approach (build it quietly in private with the design driven by what the very smart Google employees think is right, then ship and refine) that really feels like it was a success in the design department, even if they have whip-smart engineers and designers and they do incredibly good work. The Web Audio API is a mess and it's obvious what kind of problems have come up with Dart and NaCL; every other Chrome prototype API I've looked at seems to be struggling under the weight of similar issues. It's just really hard to anticipate customer needs and potential issues when you're working in a silo, and fixing mistakes is hard once you've baked them into your design for over a year.

I won't even say Google's approach is wrong for them, the track record just seems to indicate that it does not work well on the open web.

NVidia Cg preceded GLSL. Lots of stuff stolen from DirectX "behind closed doors"

OpenGL is not a good example of companies designing things in the open by commitee.

OpenGL extensions would be pointless without documentation. If NVidia adds Register Combiners or Multitexture extensions, how else would developers use them without docs? Don't sugar coat what happened in the 3D industry. NVidia would introduce new HW with non-standard features, create an extension for them, and then secretly work with triple-A developers in the industry on it before publishing it in the open. Microsoft's process of herding them into an interoperable spec was actually far better than OpenGL, and yet we still got the whole PS1.2/1.3 vs PS1.4 affair.

All of the development happened in secret, including the final, taped out chip and shipping card, before the first external person got to comment on the extension.

I'm not trying to be insulting here, but this criticism on Dart seems deranged. The Dart Team published a language spec, documentation, held 3 years of open discussion on mailing lists, changed the language 42 times based on feedback, generates most of its documentation directly from standard WebIDL and from MDN (!), and every commit to the dart VM and dart2js compiler has happened in the open.

EDIT: However, I should be clear that you are correct that their initial design was traditionally done at a vendor behind closed doors, so they certainly could have been more open than they were. Whether that would have actually been possible in the IP-laden, slow-development-cycle of hardware graphics is another question, but nonetheless...

I have a nagging suspicion that many of these arguments are based around aesthetics and language chauvinism. The people who are super critical of Dart or NaCL are also the people who intersect with people with absolutely love Javascript, and dislike class-based OO and other paradigms. There is no such thing as a unified web community. Everyone has difference preferences and opinions on the way to write web apps. The forest through the trees is that consumers and developers today increasingly don't care and are seeking out native, battery efficient, mobile applications. It's an incredible threat to the Web, and all of this bickering over people's attempts to find more performant ways of shipping apps within the Web model, but not use JS are IMHO, missing the point. While Mozilla and others think the fight is against Dart and NaCL, Android Java and Objective-C are crushing on mobile. I have grave doubts that FirefoxOS + asm.js can rectify any of the core issues. The desktop is going bye bye.

Anyway, Dart was announced in 2011. It still isn't finished and it has been changed radically since then based on community feedback from the needs of developers.

Everyone ships binary blobs to the Web today. Gmail is a binary blob. It's a red herring.

I love the Web with all my heart. I don't think JS is the Web. The Web is HTTP. It is URL. It is transparent content. RESTy semantics. It is indexable, federatable. You can ship JS based apps that I don't think quality as very Webby.

My big fear is, 5-10 years from now, everyone is publishing "sites" that are app store distributed, and all information is siloed behind private repositories. Is asm.js going to stop that? Is it going to make mobile web apps as battery efficient, memory efficient, or performance efficient, with less jank, than iOS? I don't think Dart will either, but we need to figure out a solution.

No. People are just sick of one company unilaterally making decisions. It makes life harder for developers and consumers.

More well designed, open, across the board supported standards is what we should all be aiming for.

Yes, C++ is a monster. Yes, asm.js might be doomed. I don't really care, because I don't like C++ and I don't have any intent to use asm.js. Given that, however:

C++ may be a monster but it's the monster that won. Worse is better, or whatever: C and C++ are tremendously prevalent languages and nothing anyone has done has managed to displace them even one bit. We've got new languages like Java and JavaScript that have managed to carve out footholds, but it's still a fact that when you grab a modern piece of software, it's almost always written in C, C++, or a weird C derivative (like Objective-C).

Note also that I've never argued here that the design behind closed doors is the problem, merely that it is a root of the problem. The design behind closed doors leads to poor/misguided design decisions being baked into a project and then cemented by years of engineering and derived decisions. You can certainly undo all that bad decisionmaking after you put your project out in the open, but it's not free, and it comes at the cost of severe resistance because people aren't excited by the idea of throwing out all the work they did. You can see this by looking at the mailing list for the W3C Audio group right now and observing just how hard it is for them to specify the Audio API that Google designed behind closed doors. An equally troubled API could have been designed in the open, but being designed behind closed doors is why it ended up with a narrow design that wasn't informed enough by a wider set of use cases and customers.

It's incredibly easy for software engineers to convince themselves that they are expert enough to make all the right design decisions and lock them in. We've seen it again and again. That is why it is important to work in the open and that is why Google's reluctance to do so early on causes lots of friction for (technologically stellar) projects like Dart and NaCL.

Were Dart already an established language player like C or even Java, these complaints wouldn't really matter, because at that point a language is a thriving, living thing that can evolve as time passes to become a better language and overcome its own faults. The problem here is that Dart is not there, it's not anywhere close to there, and it's not clearly on anything resembling a trajectory to there. If the software engineering community as a whole - not just people at Google - don't start learning from these mistakes we're just going to keep adding to a long, dire list of failed languages, libraries, and platforms.

Asking people to adopt a new language you designed for your needs, learn a bunch of new libraries, and rewrite all your code in order to run it in a small subset of available runtimes is simply not a winning play. As a developer I have literally dozens of great languages to pick from to write my applications in - Haskell, Scala, C#, Python, etc. Why would I pick Dart if the toolchain isn't there, the runtime isn't there, the libraries aren't there, and Google might abandon it in 5 years when it doesn't catch on?

And now you know why I'm writing a transpiler for an existing language that outputs JS, instead of hacking on something like Dart: Because I don't want to waste my time.

And how do you define working in the open? Isn't dropping design docs and sample implementations into open repositories, and then iterating on them in public, open? Asm.js was just dropped like a bomb on everyone. When they announced it, they had running code already, and V8 at the time ran it very poorly. When Mozilla announced their Device API effort, they completely avoided the parallel W3C effort at first (I don't blame them) There's a kind of bizarre mismatch in the treatment between Google's work on projects in the open, and Mozilla's code dumps which get a pass.

The specs-first-implementation-second approach is IMHO a ret-con of how things are done in the industry. Rough consensus and running code is the usual model. You need experience from implementations in the wild to inform the specification, feedback from actual people trying to develop applications or implementations. Pretty much everything that went into each revision of OpenGL started life as a "behind closed doors" OpenGL extension, that was subsequently generalized, and incorporated into the base spec.

We tried the "do everything at the standards committee level first" in the 00s at the W3C and the Web stagnated. XHTML, XForms, XSL, XPath, XPointer, SVG, SMIL, on and on. A long list of mostly failed standards that took forever to get standardized, and by the time they did, the world had moved on. Really, only SVG remains viable and the spec is crazy complex.

Look at how C# evolved vs Java. Java worked via a community process "don't break existing semantics", and as a result, we got really shitty generics, and hardly any improvements to the bytecode or VM. Microsoft took a shotgun to C# 1.0, and as a result, IMHO, C# 3.0+ is way better than Java.

Frankly, I don't believe Javascript's semantic model can be evolved without breaking backwards compatibility. For example, Javascript is fundamentally single threaded and non-shared memory, yet today's devices, even mobile ones, have 2-8 cores on them. You can introduce shared memory, but then what, how do you implement concurrency primitives? You're retrofitting a memory model into a language that didn't have one, unlike Java which introduced the JMM early on. To me, Javascript's memory and execution model makes it fundamentally incompatible for something like an intermediate representation for portable code for high performance games. Yes, the demos are impressive, but who is going to ship Infinity Blade 3 as asm.js on mobile if there's a native OpenGLES API? The TC39 committee is essentially operating with design constraints that inhibit solving real problems with the language due to concerns with backwards compatibility. It's mostly syntactic sugar.

Everything has to start somewhere. Java started out from zero, backed only by Sun. C# as well. A whole community of libraries and tools had to be built. All languages go through this process.

I work on GWT, it outputs JS, so I understand the power of leveraging existing libraries and toolchains. But there are always pioneers and early adopters who want to work on fresh new platforms and throw away existing paradigms. Why oppose them?

I think it is important for people to sometimes ignore what exists and see what can be done if you start from scratch. That's how we get breakthroughs instead of incrementalism.

I already made this point but I'll make it again: The problem here is not that Google engineers are stupid, the problem is that they are making decisions behind closed doors based on only their knowledge. It doesn't matter that their knowledge may have come from decades of experience, the fact is that it's very hard to accurately predict customer needs based on only your knowledge.

For the Web Audio API specifically, its problems run the gamut, from poorly specified features, obvious missing features that are needed for basic use cases, clumsy APIs that require lots of boilerplate code and GC pressure to do simple things, and a myriad of race conditions resulting from a mixture of underspecification and specification of behaviors that don't make sense in JS. It also shipped in Chrome with a couple blatantly bad design decisions that have only now been removed from the spec because crogers didn't even remember they were there, among them an API that blocked the UI thread to decode audio and wasn't clearly documented as doing so. My objection to the Web Audio API comes from being forced to use it for over a year due to Google's reluctance to ship a working implementation of <audio>, thereby forcing their half-baked API on everyone. I can't comment on DSP to JS as a feature because I have absolutely no interest in it, I just want to play sounds.

Can't comment on the Device API effort either, other than that I sat in on a couple conference calls about one of them a couple years back and it was definitely open to the public, and I believe some of the participants were random community contributors. Not just Mozilla or Google employees.

How do I define working in the open? Here are a few things worth trying:

1. Don't drop a huge new surface area of APIs and behaviors on people in the form of a new prefixed feature in your browser that is immediately set in stone because big names (i.e. Rovio) are using it in content that can't be broken.

2. Actually specify the thing you claim to be proposing so that other people can implement it compatibly, instead of leaving out parts of it that shipped content uses and underspecifying other parts.

3. Actively solicit collaboration from users and/or other browser vendors before shipping your prefixed APIs and setting them in stone. If this was done with Web Audio I certainly never saw it; it seemed to be news to everyone. Even the initial publication of the draft spec had one name on it.

Again, I've never argued in the thread that something has to be a W3/WhatWG spec before you can implement it, just that you have to actually collaborate with the community. I see a lot of hiveminding here where I say 'in the open' and people like you interpret that to mean 'by committee', when the former does not require the latter. Just actively communicate with developers and tell them why it seems like you're screwing them, instead of expecting them to bend over and put up with whatever you've decided - for them - is best. "Specs-first" is not a term I have ever used or implied here either, and it feels like another sort of hivemind PoV where you're used to the word "open" meaning something other than what it actually means.

Maybe asm.js felt like it was dropped 'like a bomb on everyone' to you from inside Google HQ, but as a complete non-player in its development, I was aware of it months before it ever shipped in a Firefox nightly. The people behind it were publishing draft papers that described intended behavior, demonstrating sample code, developing a compiler that targeted it in the open, developing a validator in the open, and actively soliciting (and responding to) feedback from all takers. This is what I mean by working in the open: Active communication, frequent sharing, and actually responding to feedback in early stages of development. The asm.js spec and validator lived in a git repository, readable to the public (accepting issue reports and pull requests) from pretty close to the beginning, before that feature ever shipped (prefix or otherwise). I cannot say the same for any Google prototype I ever interacted with, even if I applaud your frequent publication of papers after you've done a huge chunk of the design and engineering work. Those papers are great!

It's also important to point out that asm.js gracefully degrades, so other browser vendors didn't have to do any work to be compatible with test cases. The same is not true for NaCL or Web Audio. Dart passes this bar, as long as you are willing to tolerate Dart2JS's rough edges. When they supposedly 'dropped it like a bomb' on you, the demos were 100% possible to run in any browser, regardless of support for asm.js. When you guys dropped Web Audio like a bomb on developers (while <audio> was still completely broken), we were now presented with two equally awful choices: Continue to have nonfunctional, crashy audio in Chrome, or build a Chrome-specific audio backend for our games and hope that it would work. Asm.js presented no such dilemma for anyone.

If you're arguing in favor of the strength of breakthroughs instead of incrementalism, I won't disagree with you - sometimes we really need them. But Dart doesn't feel at all like a breakthrough to me, so maybe that's why I don't get excited by the promises or consider it worth shipping an entirely new VM as part of browsers and complicating the whole web platform with things like cross-language GC and a required compiler toolchain.

We agree that the browser market of 1995 is not one we want to replicate, but the rest of this is revisionist to a fault. The development of the open web itself has consistently been a messy business. There's a reason that the single-champion model has been adopted by several groups, including TC39: it works really well, and a lot of good standards have come out of it, whether on purpose (many recent specs) or not (many of the features we can thank old IE for). Even when things have been going great, people try to use committee maneuvering to torpedo things, or patent claims come out of the blue and suddenly you're turning to a different champion for your touch events.

Pretending that we now have a one true way of developing the open web is silly, because it's not even a little true.

> The Canvas spec is a complete steaming pile of nonsense that again, has only been iteratively improved into a more useful state by the tireless efforts of the whatwg (and whoever was maintaining it before them, I don't remember). Canvas delivers miserable performance and a crippled, arbitrary feature set that was clearly designed for the specific purpose of solving whatever problems Apple had at the time. Compare Canvas with WebGL, if you like: WebGL was developed in the open, based on an established, proven API that had been used to solve problems for decades, and it is quickly gaining on Canvas for many use cases due to that - even though it's lower-level, harder to use, and less widely supported.

The canvas spec is extremely well thought through because it's an API that was copied virtually verbatim from CoreGraphics/Quartz2d, which has a lineage that's been hammered on since QuickDraw came on the scene. What it is, however, is out of date in a world that is constrained on bandwidth to the GPU, but has computation power to spare once there. Apple has worked hard to efficiently implement Quartz2d on top of modern GPUs, but, yes, it's silly for everyone else to spend as much energy as they have bending over backwards for something inherently less efficient. The spec is slowly being brought up to speed.

Meanwhile, WebGL, which has indeed been a model of open development, would of course have been similarly hampered if it had come a little earlier and been based on OpenGL ES 1.0 (though less so than Canvas), but it also proves my point: Khronos is a famously not open standards body, incredibly bound by the patent and disclosure agreements that the member organizations require of them, and though the WebGL group has done more than admirably in that environment (even driving changes on what should be common-sense notions like conformance tests), the spec that WebGL is based on, OpenGL ES 2.0, was produced in that closed environment on private lists, and is especially favored because it discards its decades of legacy.

WebGL is "gaining" on canvas (whatever that means) because it enables a whole world of high performance effects (3d and otherwise) that were before impossible. And this largely in spite of the API, which was of course designed not to favor usability or abstract the hardware, but to be an efficient foundation for the type of libraries like three.js that have been driving the popularity.

> You don't have to announce a project the day you start working on it, and there's a huge difference between announcing an idea or an initiative with a proof-of-concept and what Google did with NaCL and Dart, where something was announced along with the intent to ship it as a built in special-purpose binary blob in the browser and expose it to the web, regardless of the thoughts or intents of web standards folks and the community at large.

Neither of these things are true, and you don't even have to search very hard to verify it. NaCl is the farthest from your description, as it was released as an initial proof of concept via a browser plugin[1] and even ran in Firefox, Safari, and Opera at the time. Pepper is what most open standards objections revolve around, as there has never (AFAIK) been an effort to standardize it in spite of its very long development time (beyond some early initial discussions with Mozilla[2]), but its actual development has indeed always been in the open as part of the chromium code base.

As for Dart, there was an initial "surprise" unveiling for the language, but my understanding is that there have been significant changes in the core libraries in response to community feedback (in the language itself as well? no idea). And, of course, there's the small detail that it has never actually shipped as a special-purpose binary blob in a browser and been exposed to the web. They certainly don't get points for maybe someday moving Dart to a standards body, and so they certainly aren't harming the web for maybe, someday shipping Dart in a browser.

[1] http://googlecode.blogspot.com/2008/12/native-client-technol...

[2] https://wiki.mozilla.org/index.php?title=NPAPI:Pepper&oldid=...

Canvas literally prioritized narrow support for things like drop shadows over support for basic, established rendering essentials like blending operations, well-specified clipping/sampling semantics, control over scaling, and basic image data filtering/transformation. Many of the obvious features Canvas is missing have been in SVG for years now, and have been in applications like Photoshop and in most game-oriented rendering libraries for decades. This is fine in an early vendor-driven prototype but the fact remains that even now many of those things I described are still not possible with Canvas, and Apple has no excuse: They needed only look at things real software did in rendering.

Canvas also remains an incredibly slow API by specification, not just due to poor luck of aligning badly with the GPU: The bread and butter drawImage operation is itself specified in a way that makes it considerably more expensive to implement (for general cases) than it needs to be, and I can only blame this on Apple's PoV on rendering at the time infecting the design of the spec. There are other design decisions that unnecessarily cripple its use for image rendering and image processing; the need to render an image to a canvas and read it back just to get at pixel data is a big problem that is only now being addressed thanks to the valiant efforts of the WhatWG. Canvas's incredibly poor performance also undermines any attempt to claim that Apple might have left key features out 'to make it fast'. I will note that most browser vendors have gone to valiant efforts here to make Canvas fast, and they've done a good job - but it still performs terribly.

The Canvas API also has severe underspecification/poor specification problems when it comes to image quality concerns; its treatment of sampling/filtering (in particular when dealing with subrectangles) and its handling of color profiles/gamma are both hopelessly underspecified to the point that it is no longer possible to fix either of them without breaking applications that have accidentally relied on the arbitrary behavior of existing implementations.

HTML5 Canvas is unfit for: Realtime rendering scenarios, offline rendering scenarios, and 'real' image processing/editing scenarios, among others.

Also, your edit doesn't strike me as evil. It's only evil if they prevent other vendors from putting in a Dart VM. The language is opensource, and so is Chromium where their VM implementation would be, so that seems unlikely. They'd have to put in quirks that make it "work best" on Chrome that they somehow hide from the competition.

I mean, was SPDY an evil move? It was originally baked into Chrome but the spec and implementation were open. It just took Firefox and others longer to decide to add support.

Oilpan is an wholly unrelated project that's investigating moving some of the DOM lifetime management over to GC rather than it's current reference counted structure [2]. It will have to integrate with any language engine, of course, but the work is being done as part of Blink and V8, not Dart. The impetus for the project is to address various recurring issues including: memory consumption, GC performance, object lifetime bugs, and general code readability.

[1] https://lists.webkit.org/pipermail/webkit-dev/2011-December/...

[2] https://groups.google.com/a/chromium.org/forum/#!topic/blink...

https://lists.webkit.org/pipermail/webkit-dev/2011-December/...

"You'll need to make sure that the different GCs can coordinate, which will induce overhead. Otherwise you will either not have an story of object reclamation, or you'll have memory leaks. It's just sufficient if one program, in one language, can reference a window containing code written in a different language. Doing this right is hard. See either Wegiel and Krintz OOPSLA'10 or Pizlo, Hosking, and Vitek LCTES'07 for studies of prior attempts to have interoperability between independent GCs. Both seem to indicate >5% throughput regression. Are you claiming that a 5% throughput regression is worth it to support a new language, that is not an open standard, and currently has nonexistent adoption?"

There were no replies from Chromium's side.

My information regarding Oilpan was based on Justin Fagnani's message in this thread: https://groups.google.com/a/dartlang.org/forum/#!msg/misc/ym...

"We're hoping to not have to re-introduce scopes, since in dart2js we don't have a memory leak, and Dartium will be able to collect cycles across heaps when Oilpan lands. This would mean that there are leaks in Dartium until Oilpan, but that's similar to the leaks that GWT-Exporter has, which I've seen go into production with no problems, so I'm hoping it's manageable."

Here's how I interpret the situation: Cross-VM memory leaks are a blocker for shipping in any browser; you cannot reasonably say the implementation is done if it is leaky (on this I assume we agree). Dartium currently has cross-VM memory leaks ("cycles across heaps" as above). Upstream WebKit raised issues regarding the performance cost of collecting cross-VM cycles, which Dartium currently does not do. Chromium's plan to mitigate this seems to be Oilpan. This is fine—it's the most logical response!—but doing the same in other browsers is going to be a huge burden, since all browsers use reference-counted DOM handles.

If things have changed since then, please let me know and I will happily correct my post.

I assume no one replied because the argument was a broad generalization that wasn't relevant to the proposed patches or the actual code under discussion. Did you bother to look at the actual code?

>There were no replies from Chromium's side.

You seem to be conflating the members of the Dart project with the members of the Chromium project. The only responses I see from Chromium developers on that thread are from active WebKit contributors who are simply clarifying a few technical details. The multi-VM patch itself was clearly proposed and being argued for by members of the Dart project, not the Chromium project.

>If things have changed since then, please let me know and I will happily correct my post.

I'm not sure if this is trolling, or if you're actually serious. You outright flamed about how invasive Dart is and that Chrome's DOM is being rewritten just to support it (which it clearly is not). And your sole supporting evidence is two engineers discussing how an implementation detail of Dart would change if Oilpan lands.

So, is that really your argument, that an engineer being aware of a highly relevant, potential change discussed a few weeks earlier on a public mailing list must somehow mean that his team is forcing it to possibly happen at some unknown point in the future? I mean, the Dart leads were explicitly CC'd on the Oilpan announcement, and I'm sure the teams do communicate at least occasionally. So, I would hope that Dart engineers would be aware of the potential impacts. And he even expressed it as a hope, with the rest of the context making it pretty clear that he was prepared to re-introduce scopes if Oilpan didn't work out or arrive in time.

Thinking about it, your citation does an even better job than mine of demonstrating that Dart isn't in any way dependent on Oilpan.

It certainly seems relevant, because Dartium has cross-VM leaks.

> I'm not sure if this is trolling, or if you're actually serious. You outright flamed about how invasive Dart is and that Chrome's DOM is being rewritten just to support it (which it clearly is not).

I am sorry that you interpreted my concerns as flaming or trolling. My point is quite simply that the cross-VM garbage collection story is one of the chief concerns that other browser manufacturers have with Dart, as evidenced by that webkit-dev thread as well as conversations I have been a part of or witnessed since Dartium was announced. As of the time that message was sent the Chromium story has been Oilpan, and that does not assuage this concern. An alternative story from Dart's side that could be demonstrated to prevent DOM leaks in a reference-counted DOM world would go a long way here, but it does not seem that Dart is currently taking this into consideration.

I hope you will forgive me for not wanting to escalate this back-and-forth further.

Edit: I was pointed by a colleague to this presentation by Lars Bak which confirms this. Page 44: http://commondatastorage.googleapis.com/io-2013/presentation...

According to him, the Dart VM causes leaks: "Impossible to guarantee unused objects are reclaimed; this implies memory leaks", and Oilpan is presented on the next page as the solution.

Edit 2: Another colleague of mine pointed out that I said "memory model" when I should have said "memory management implementation". Apologies for being inaccurate there.

Sorry, I must have looked at the wrong message, because reading it now, that's not at all the context I was responding to. However, that message was so late in the thread that are you really surprised it didn't get answered? The conclusion had been reached hours earlier and the broad consensus was clearly to not support multiple run-time VMs in WebKit.

> I am sorry that you interpreted my concerns as flaming or trolling. My point is quite simply that the cross-VM garbage collection story is one of the chief concerns that other browser manufacturers have with Dart,

Mozilla has had support for multiple VM bindings for as long as I can remember. I know at least ActiveState has shipped products based on it. So, it strikes me as very dubious for you to argue like this is some sort of fundamentally intractable problem.

> as evidenced by that webkit-dev thread

It seems like you read a tremendous amount a late response to a concluded thread.

>as well as conversations I have been a part of or witnessed since Dartium was announced.

Forgive me, but you haven't cited any of those.

> As of the time that message was sent the Chromium story has been Oilpan, and that does not assuage this concern. An alternative story from Dart's side that could be demonstrated to prevent DOM leaks in a reference-counted DOM world would go a long way here, but it does not seem that Dart is currently taking this into consideration.

To be honest, I don't really know what Dart is doing beyond what shows up on mailing lists. It's not part of Chromium so it's not a pressing concern for me. I have had involvement with the team working on Oilpan, because it's a Chromium project and it looks like it could help address object lifetime issues, which are a major security concern. And regardless of anything that may or may not happen with Dart, the outcome of Oilpan is very important for Chromium and V8.

> Edit: I was pointed by a colleague to this presentation by Lars Bak which confirms this. Page 44: http://commondatastorage.googleapis.com/io-2013/presentation....

The whole first half of that presentation enumerates the issues with V8's current GC. So, are you really still disputing that the primary purpose of Oilpan is to address issues in V8's GC?

> Edit 2: Another colleague of mine pointed out that I said "memory model" when I should have said "memory management implementation". Apologies for being inaccurate there.

One statement implies that there's some fundamental incompatibility affecting any design. The other implies implementation details that need to be resolved. I think an objective observer would find that the distinction between the two is very important.

To translate for others: browsers tied the DOM memory model tightly to the single Javascript VM because it was a lot easier that way, and expanding support to multiple VMs will take a lot of work. This is one reason why you don't see many browser forks running with the "let's just add python to browsers" idea that so many have had. It's also why we still have no canvas or WebGL in web workers: no one has a DOM that sufficiently supports multi-threaded access.

I have no idea what "ignored" means in this context, since Dart bindings obviously weren't added to webkit, and Oilpan is replacing the GC model for the DOM in blink. That might make it easier to support Dart (that's still only something I've read here on HN, but I don't follow Dart lists), but it's a performance improvement that has long been needed. Try tracing garbage collection in Chrome sometime in an app that manipulates the DOM; the typical pause will spend most of its time trying to collect memory on the DOM side, not the Javascript side, even for some of the simplest DOM manipulations. My understanding is that (somewhat humorously, in the context of the above) this is because of the more inefficient bindings created to allow V8 to work with Webkit, where it used to be that only JavaScriptCore bindings were needed.

Having suboptimal GC performance in the DOM can be solved in other ways: for example, the cycle collector that Gecko uses. (That said, Servo [full disclosure: I'm a Servo core team member] is pursuing a more Oilpan-like approach, but not to support multiple languages.)

As for DOM GC performance, yes, it could be solved in other ways, or you could move it to the same GC-able heap as the language manipulating it. I'm still not seeing the connection to Dart, but, again, maybe I'm just out of the Dart loop (some simple searches haven't revealed much beyond the blink-dev list and associated code reviews). AFAIK oilpan is coming out of long-time work by haraken et al in webkit and now blink to bring huge performance improvements to the V8/browser bindings, which have historically been much slower relative to other browsers and their javascript engines.

[1] https://lists.webkit.org/pipermail/webkit-dev/2011-December/...

Google will never drop support for their 2 crown jewels, Chrome or Android. When Dart gets into Chrome and some of their big internet properties start to depend on it, you can pretty much guarantee that they'll never drop support for it. One of the mandates Google has is to improve the web, make it faster and make it possible for everyone to build richer more interactive web experiences so more people use and spend more time on the Internet. More time on the Internet means more time on Google, so developing and investing in technologies like Dart indirectly benefits them. It's also why any investments on improving the Internet remain supported, free and Open Source e.g WebP/M, SPDY, Chromium/Blink, V8, Closure Library, GWT, mod_pagespeed, Polymer and now Dart.

People like to confuse Google's dropping of support for their products where everything they create is fair game and can be dropped at anytime, what's not looked at, is how the product to relates to their entire ecosystem, whether it adds value and is in a growing technology/market.

> Never rely on Google for anything

First, you're expectation that Google will drop Dart is based on what exactly? A few SaaS product cancelations? The "never rely on Google" meme is getting so old, mainly because it's overly applied to Google when all SaaS providers have this issue, and it's been a known downside for years: when product support ends for an installed app, you still have the old installed app to use, when support is ended for SaaS users have a problem. I hope this can be mitigated one day, but that's a whole other topic. The differences with Google is that we have a ton of users even for our "small" products, and there's a single name to attach attention to, rather than the numerous shutdowns that have happened in other companies, or the startups that have bee bought and killed.

The important bit for the discussion at hand is that Dart is not even _anything_ as a service. It's a set of installed, open source compilers and libraries. They will continue to work in the (unlikely, IMO) event that Google drops support.

> This means that any developer taking over Dart would have to support the IDE, the VM, the javascript transcoder, the language, integration with new browser features, cross browser compatibility, etc.

Dart's more of a collection of independent pieces. If Google ever did completely drop Dart I'm pretty sure that the parts could be maintained by the community (assuming the community hits critical mass). The dart2js compiler is the most important part and it's well structured, easy to understand code. The IDE could be abandoned in favor of plugins for WebStorm (already maintained by IDEA), Sublime, vim, etc.

> Dart has neither income nor traction.

Dart will never have income, that's not its purpose. Dart's purpose is to make web development easier, more productive and more scalable, and web apps themselves faster. This goal is both for internal development, for which we badly need something like Dart, and for everyone else because we want to see more and better web apps.

As for traction, if Dart doesn't get any traction (after it's actually released, and had a good chance to succeed of course!), inside Google or outside, then it probably _should_ be abandoned, right? In that case, who exactly is there to care that it's not developed anymore?

I've heard some people point to GWT as an example of what might happen to Dart. I don't agree, but for the sake of argument, let's look at where GWT is: 1) There's an official community maintaining GWT, 2) Google still has a team working on GWT, and large projects using it. 3) GWT will still get better as Java gets better. There are other factors that apply to GWT and it's language that don't apply to Dart. If Dart's fate was ever the same as GWT, I'd say it'd be a pretty soft landing for everyone.

> Just to add, Google can artificially increase traction of Dart by putting the Dart runtime inside Chrome and using that as a weapon to increase Chrome adoption, similar to Microsoft's ActiveX strategy.

This is still a ridiculous comparison. ActiveX was a plug-in architecture. Dart compiles to JavaScript. We support all "modern" browsers, IE9 and up.

Look, we've made no bones about wanting to get the VM into browsers some day. And obviously, being part of the Chrome team, we'd like to see it in Chrome. Lars pointed out at Google I/O that there's work already being done to pave the way for this on the memory management side. The Dart VM does enable faster and quicker to startup applications, no doubt.

But we all understand that Dart will be distributed as JavaScript for the foreseeable future, and we do considerable work to ensure that programs behave the same in dart2js and the VM, and that the JS output is very fast. The Dart and Chrome teams firmly believe that the adoption of Dart will entirely depend on it's success as a compile-to-JS language. How Dart helps developers will be its main draw, and hopefully there's organic demand for the VM as an accelerator for apps that already work well across the web.

This will not be "evil" in anyway, but one of many ways that the browser vendors have pushed the web forward. There are so many examples of a vendor pushing something that's initially totally or somewhat proprietary but end up being a great thing for the web, that only comparing Dart to ActiveX is just juvenile and annoying. Consider JavaScript itself, XHR, <canvas>, CSS, SVG, WebGL, setImmediate() and so many other DOM APIs, CSS extensions like rounded corners, shadows, transforms, etc. Some of these have actually been much more backwards-incompatible than Dart which primarily _compiles_to_JS_.

The FUD around Dart is just incredible. No matter though. We see the benefit every day that we luckily get to code in Dart, and so does our community. Those who wish to reap the benefits Dart can opt-in and those who don't can ignore it.

   First, you're expectation that Google will drop Dart is based on what 
   exactly? A few SaaS product cancelations? The never rely on Google meme is 
   getting so old, mainly because it's overly applied to Google when all SaaS 
   providers have this issue, and it's been a known downside for years: when 
   product support ends for an installed app, you still have the old installed 
   app to use, when support is ended for SaaS users have a problem. I hope this 
   can be mitigated one day, but that's a whole other topic. The differences 
   with Google is that we have a ton of users even for our small products, and 
   there's a single name to attach attention to, rather than the numerous 
   shutdowns that have happened in other companies, or the startups that have 
   bee bought and killed.

   As for traction, if Dart doesn't get any traction (after it's actually 
   released, and had a good chance to succeed of course), inside Google or 
   outside, then it probably _should_ be abandoned, right? In that case, who 
   exactly is there to care that it's not developed anymore?

   The FUD around Dart is just incredible. 

* The only way to get the best of an argument is to avoid it.

* Show respect for the other person's opinions. Never say "You're Wrong."

* If you're wrong, admit it quickly and emphatically.

* Begin in a friendly way.

* Start with questions to which the other person will answer yes.

* Let the other person do a great deal of the talking.

* Let the other person feel the idea is his or hers.

* Try honestly to see things from the other person's point of view.

* Be sympathetic with the other person's ideas and desires.

* Appeal to the nobler motives.

* Dramatize your ideas.

* Throw down a challenge.

Frankly, you should relax. Google's Go ate tons of shit on HN, and now gets nothing but praise. If you wan't to persuade people to the way you think, then persuade people correctly. If you are offended by some argument, grow thicker fucking skin and don't lash back. If you must lash back do it from a throwaway account and don't mention you work for Google. Let the arguments rest on their own merits.

The important bit for the discussion at hand is that Dart is not even _anything_ as a service. It's a set of installed, open source compilers and libraries. They will continue to work in the (unlikely, IMO) event that Google drops support.

... I recognised that you'd missed the original article's point, which is that enterprise customers won't adopt it. If Google wants Dart to be of interest to more than tech startups or hobbyists, then ongoing support, patching, commitment from the vendor is ab-so-lute-ly necessary. This is why Rails succeeded, for example. And poor old godforsaken Java.

It's just the reality of technology component selection for IT in the mundane non-tech-sector.

As for your tone in here:

expectation that Google will drop Dart is based on what exactly? A few SaaS product cancelations? The "never rely on Google" meme is getting so old

that's just plain bitchy, sorry - and not at all convincing. If your intention was to make Google insiders look like disconnected academics in an ivory tower, you succeeded; if your intention was to make Dart look like an attractive prospect for developers to choose to invest their time in learning and developing with, I suggest you should rethink your pitch.

This doesn't make any sense -- there is no "the vendor" providing those things for Rails. If anything, this illustrates the parent's point that the Dart community (like the Rails community) can support the Dart compiler and other tools if Google ever pulls back from it.

I'm not here to "convince" people to use Dart. That will only happen because of it's utility to developers, and I'm more than fine with slower organic growth if it develops more from actual problems being solved, and less from hype. If anything there's a ton of anti-hype around Dart, so it has a lot to overcome with some people even if does address their problems. Such is life.

I'm pretty sure there will be such an explicit commitment to Dart communicated externally, but since I'm speaking for me, and since the question at hand had to do with what would happen _if_ Dart were canceled I addressed the hypothetical situation. Maybe a PR departments would have danced around that and simply said, "we're committed to Dart. Next question", but I'd much rather dig in say that we're committed, but sure, "what if". To me that's a real discussion, not a rhetoric, not a pitch.

As for my tone, can you imagine what it's like to have the company you work for called "evil" because they shut down a RSS reader or move away from using XMPP in their chat app? Or that you can't rely on Google because of the Reader shutdown, or the price increase on App Engine when it came out of preview. I hardly agree with every things Google does, but the hyperbole surrounding it is incredible. Not every product that any company makes will be successful, not every product can be kept alive indefinitely. Google receives an inordinate amount of flak for it's changes, mainly I think because we have so many products that it's easy to keep seeing a small fraction of them change it's still seems like a lot because it's all under Google. Meanwhile there's multiple instances a day of some other companies products changing, or shutting down, or being bought to be shuttered later, but because they're spread out over many brands. The recent constant chime of "evil" and "unreliable" is so often drawn on really warped and rushed comparisons that don't make sense if just a little thought is put into analysis, so yes, it gets really old, to me, personally.

Not only that, it could cause a "the sky is falling" perception of communities like HN. This is a real concern of mine because many times there are legitimate points here and several of us like to represent them back into the company. If HN reflexively interprets everything that Google does as evil and bad, it becomes harder for the Google members of the community to go internally and say "this isn't being received well, is there room for improvement?". We haven't reached that point yet, but it's something I worry about. The reaction to the "no servers on Fiber" rule is the type of thing that several of us try to represent back to the company. I, and many Googlers, respect the hell out of this community, but the more ridiculous the FUD and conspiracy theories get, the more the reputation erodes. I don't want to see that happen, so I actively combat it when I can, by trying to dispel the falsehoods, and also by chiming in when I agree with some of the negative sentiments. But yes, it gets really, really old.

  "...my personal point of view, which now happens
  to include a lot more information from inside this
  company that I work for. ... "

You said Dart VM is free and can be added to any browser -- except it has deep roots into the Chrome code so this is a ton of work to do (global garbage collector between Dart, JS, DOM for instance).

You said you "ensure that programs behave the same in dart2js and the VM, and that the JS output is very fast" when dart2js doesn't support big integers or operator overloading on any numbers, among other differences, and it's ~30% slower than normal JavaScript (is much slower than TypeScript code for instance).

Dart designers have for a year now knowingly lied about dart2js DeltaBlue benchmark performance (they optimized DeltaBlue when porting it to Dart, then compared the optimized version back to the original JS). For me, I would never use a product who's designers lie to me about it.

  can you imagine what it's like to have the company you work for called "evil"...

Here's the Dart code for Delta Blue: https://github.com/dart-lang/benchmark_harness/blob/master/e...

Here's the JavaScript code for Delta Blue: https://code.google.com/p/v8/source/browse/branches/bleeding...

I see a JS class for Constraint, and a Dart class for Constraint.

I see a JS class for Strength, and a Dart class for Strength.

This goes on and on. In fact, I see a top-level function for chainTest() in both JavaScript and Dart.

It is very costly only if JIT is particularly bad at eliminating redundancies. Crankshaft is not and (I hope) neither is IonMonkey.

If you try removing it yourself from JavaScript version and replace every new OrderedCollection() with [], .add with .push, and so on then you will discover to your amazement that resulting code became 7-10% slower on V8 [try it, I am not joking :-)]

Now if you replace [] with new Array() then you get code that overall is 3-5% faster on V8. That is about how "costly" this indirection is.

Overall it seems that this is irrelevant in the large picture of things: Dart VM is around 195% of V8, dart2js is somewhere around 100%.

I do agree however that this OrderedCollection looks completely out of place and it is not clear to me why it appeared in the original JavaScript benchmark code at the first place. It is not idiomatic.

I found both V8 and Ion to be >10% faster using array. I no longer have the results but IIRC it was 11% for V8 and 14% for Ion on i7 (ivy bridge). I moved remove() from OrderedCollection to Array prototype. Perhaps you made some other change.

> Overall it seems that this is irrelevant in the large picture of things: Dart VM is around 195% of V8,

There are 3 benchmarks. That is not enough data to say anything meaningful about Dart VM performance.

> dart2js is somewhere around 100%.

How can dart2js results be compared to the original JS if the data structures used are different? It makes no sense.

I tried with both global remove and remove on the Array prototype.

V8 has recently improved DeltaBlue score by, I think, ~6% so it can be that before this improvement OrderedCollection overhead was more noticeable. (some of that improvement comes from tweaks in the inlining heuristics AFAIK).

> There are 3 benchmarks.

I was stating performance numbers for DeltaBlue only. Sorry for not being clear.

> How can dart2js results be compared to the original JS if the data structures used are different?

Substract 5%. dart2js is around 95%. Does it make sense now?

Ultimately, everything everyone does can be considered evil. Plant a tree? That tree is turning CO2 into oxygen that a murderer will one day breathe. How could you aid and abet a murderer like that? You're evil!

Maybe Google will someday be truly evil, but you don't have to make that decision now. Ultimately, you're deriving income and enjoyment working on a programming language that will improve software engineers' ability to produce high-quality computer programs. The language, libraries, and discussions are open for anyone in the world to participate in. You're not doing anything wrong, and you shouldn't have to justify your actions to anyone but yourself.

I think the real criticisms of Dart boil down to: "I don't want to learn a new programming language, and if some random crackpot was making Dart, I wouldn't have to. But with Google's engineering prowess behind the project, it's probably going to be popular, and I'll have to learn it. Better kill it while I still can."

Really, that's a completely reasonable reaction to a new technology. If the new technology replaces the old technology, it means someone invested in the old technology loses everything: their reputation in the community of programmers, their familiarity with tools and libraries, and everything they've ever done with their life as a programmer. That's pretty scary, so there's going to be resistance on programming forums when you suggest a new way to do things, and I think that's what this thread has devolved into. FUD is a good way to make other people emotional, and there's safety when other people share your views. Doesn't mean the views are correct, however.

I am critical of it because I am sick of companies coming up with their own proprietary technologies and trying to force it as a defacto standard. It hurts developers. It hurts consumers. It has real economic and productivity costs. It undermines the fabric and stability of the web as a platform for humanities' information.

Google, Microsoft, Mozilla and Apple have a responsibility to work together to create open, widely adopted standards. And they all deserve criticism when they deviate from this.

Just how do you think software gets made?

Reddit is the same way, but at least people on Reddit don't take themselves so seriously.

But unlike Go, Dart is in the web terrain.. things will be much more difficult.. because there are much more people married with javascript .. and the fanatism and emotional reaction is much worse

Well, Google does get treated better than Microsoft.

How about that Unladden Swallow that was announced with fanfare back in the day?

>The "never rely on Google" meme is getting so old, mainly because it's overly applied to Google when all SaaS providers have this issue, and it's been a known downside for years: when product support ends for an installed app, you still have the old installed app to use, when support is ended for SaaS users have a problem.

You actually reinforced that the "never rely on Google" is not old, but complete revelant. If anything, you didn't knock the meme down, you only made it stronger: "never rely on any SaaS".

That's not a fair comparison: Unladen Swallow was designed to be completely compatible with CPython, so it wasn't a 'new platform' that people would depend on Google to support. Also, when Unladen Swallow was abandoned, it didn't leave anybody stranded. Unladen Swallow was abandoned because it wasn't appreciably faster than CPython, so nobody was using it anyway.

Probably the only thing I don't like is optional typing...

I'd love to see great numeric and stats packages for Dart. I think it'd be a great replacement for R.

Interesting. I've held off creating anything serious in Dart because I'm waiting for it to be built into Chrome directly. I know compiling to JS is important, but I feel like other browsers will add Dart support shortly after Chrome, and in the meantime I'd use the Dart2js as a stopgap.

Yeh no.

Both Microsoft and Apple have stated that they don't believe in the premise of Dart and the fact that Google designed it unilaterally doesn't help. Without Apple in particular (dominant mobile browser) any technology like this will never gain serious traction.

Yep. So goes the argument. When/how is it going to be released in a meaningful way, such that it can 'actually' gain traction?

People are using CoffeeScript and Typescript in production right now. Dart has been a theoretical project for far too long.

>The Dart and Chrome teams firmly believe that the adoption of Dart will entirely depend on it's success as a compile-to-JS language.

Yep. It's not doing so well.

>The FUD around Dart is just incredible.

Maybe it's not FUD, maybe it's legitimate criticism.

In any case, I wish you good luck.

But I can't believe you complain that it's not released yet, and that it doesn't have much traction in the same post...

I think Dart adoption is going along just fine, considering it's pre-release state for the last two years. If too many people had already starting using it, they might have had unmeetable expectations about it's stability and readiness. Better that there are fewer early adopters who are aware of and willing to take the pain of the evolving platform.

Where's the contradiction?

For one, other projects have gotten traction LONG before the stable release. Mongo and Node.js come to mind.

Second, the complaint can be stated as: "If you want it to gain traction, why do you keep tinkering on it for such a long time without a stable release"?

If they were to bake it internally first until it is stable and then release it "done", then everyone complains about a closed process.

And do you have any numbers to compare Dart vs Typescript vs CoffeeScript adoption?

Well, Go did just that, and I didn't see anyone complaining.

There's nothing regarding fear, uncertainty, or doubt in that assertion.

That said nothing like Dart exists, which is a ground-up new implementation of a new structured web language to build and maintain high-performance complex web apps. There are many parts to Dart, like the Dart SDK which provides a set of well-written and consistent APIs, smoothing over the DOM and browser quirks that also introduces a new Future/Streams composable async model simplifying IO and handling events in js web apps.

The dart2js component is what Dart shares with other transpiled languages like CoffeeScript, TypeScript and asm.js. Out of this only TypeScript shares the goal of a structured/toolable language for building complex web apps, which is essentially just an optionally-typed superset of JS that's forward-looking to features proposed by the ECMA standards committee. Since TypeScript is a tooling/transpiler that sits on top and is dependent on JS it will have a slower dev/edit/reload cycle since it always needs to compile before running, its tied to JS semantics so it wont be able to have the same level of advanced tree-shaking Dart can and as its performance is tied to JS VMs it wont be able to take advantage of DartVM "Snapshots" for instant start-up times or the 2x faster predictable runtime performance of the DartVM.

Dart is also the only strategy that allows us to get a "clean-break" from JS. Personally I think it'd be a tragedy if in 10 years time everything still depends on and we can't innovate past JS, killing any hope being able to natively run other languages in browsers. I strongly believe in order to progress we need to re-invent, to tear things down, keep what's good and discard the warts and legacy, not build on top of it. Maybe it turns out Dart isn't it, but I sure hope something better succeeds past JS.

Sounds like RxJS to me.

"If I could take a clean sheet of paper and write [a new language] that retains all the goodness of [JavaScript] ... I would not have come up with anything like Dart." -- Douglas Crockford

How is this legitimate criticism? Especially since Dart has all the goodness of JavaScript except monkey patching (or is that one of the good parts?)

Anybody with even half a brain can see this. It's an exercise in futility, like trying to build a whole new web browser and expecting it to dominate within five years' time. Including Internet Explorer. Worldwide. Such fantasies are ridiculous and a waste of everybody's time. Get back to the drudgery of your actual lives, folks.

The world does change, even dramatically, sometimes.

(Not that I believe Dart is interesting or useful enough to drive dramatic change, I find your approach overly pessimistic).

We didn't quite get this "for free" as I had originally hoped, as the libraries to make HTTP calls are different between the client and the server (complicating the API is something called "HTTP over RPC" that we use for authenticated requests to servers from workstations).

I also prefer class-based OO to prototype-based OO and wanted to be able to write thorough tests without requiring them to run in a browser, so Dart fit those requirements better than a Javascript-based framework.

After about a year of working on this project occasionally, I've found Dart code to be much easier to read and refactor than Javascript, but it also ends up being a lot more verbose. Dart lets you encode a lot more of your intent into the program text, which I generally see as a good thing when you plan to have more than one engineer work on your code.

Go is definitely picking up steam, and there have been a couple of fairly high-profile projects talked about publicly (the dl.google.com rewrite from bradfitz and YouTube's MySQL proxy)

GWT doesn't have nearly the team it used to have, but its still being supported by Google.

EDIT: to add, GWT has recently transitioned to a non-Google site[1], run by the GWT committee. As well, a GWT focused conference is being organized by Vaadin[2].

[1] http://www.gwtproject.org/

[2] http://gwtcreate.com/

I'm sure that if you have code that works today it will continue to work if you change nothing (although there is talk of dropping support for IE8) but there are a lot of rough edges that will now never be improved. That's not optimal for people who bought the story that google was selling to developers just two years ago at IO -- that this was the wave of the future and well worth devoting effort to learning and pitching to clients.

Well, if we're being pragmatic and cautious ("never rely on Google for anything"), then expecting Dart to get support post Google because "it's open source" is an even more dangerous idea.

For one, all of Dart's core developers are Google employees. If Google kills it, I seriously doubt others will take their place.

We have many precedents of abandoned open source projects where the community consistent 90% of some companies paid employees.

And it's not like Dart has gained any traction from programers using it to get stuff done either.

Couldn't Microsoft put Dart in IE today? This argument boils down to: "nobody should ever work on any programming language, because any company could add support for it to a web browser." It's technically true.

It depends. I spent a lot of time looking at Dart in the first part of this year. My impression is that the team developing Dart is very serious and enthusiastic about it. Dart makes web development fun again. It's easy to try things and throw them away if you get a better idea in the process. Building large apps is easy. The success of Dart doesn't only depend on success in the browser, because a lot of effort is being put into Dart on the server, where it hopes to compete with Nodejs and replace Java for some uses. Another motivation for Dart is that it is not influenced in any way by Oracle, who has sued Google over Java. Dart may shine on mobile devices where old browsers are not an issue, that remains to be seen.

Who is not enthusiastic about Dart at Google? I would say the Chrome team and the Closure team, based on a lot of reading and watching videos, are not enthusiastic. This is just my impression. I have no inside information. As far as I know, Dart is not being used internally.

The Chrome Frame issue caused me to switch to TypeScript, which I also really like. It's not as much fun as Dart, but it certainly makes JavaScript a lot more verifiably correct, with type annotations making code refactoring and type checking possible. TypeScript is an ok alternative to Dart. They feel similar, they each have their uses.

I wouldn't bet the company on Dart, but I would on TypeScript, which could go away and you'd still have perfectly readable and sensible JavaScript files to work with. As Anders Hejlsberg (designer of C# and TypeScript) says, "we don't obfuscate your code."

It's easy enough to learn Dart. There are places even now where it makes sense to use Dart. If JavaScript is an old internal combustion engine car, then TypeScript is one with automatic transmission and power steering, while Dart is a new electric car. I'll drive all three as long as they get me where I'm going.

And Dart's part of the Chrome team, if Chrome wasn't enthusiastic about Dart, Dart wouldn't exist.

https://www.youtube.com/watch?v=TlJob8K_OwE

Skip to &t=17m26s and you can hear them talk about it. Judge for yourself.

TypeScript + ReSharper (recently announced) => cold-fusion powered flying car :).

I'd love to know if there's an internal debate inside Google and if they are aware of how much recent decisions have damaged their reputation amongst a critical demographic.

I could not understand the decision to drop Chrome Frame. It seemed like a good strategic product but even more so - a lot of people had staked their reputation on a technology choice because of it's existence. These people were the thin end of a wedge inside enterprise cultures that were historically dominated by Microsoft evangelists. Google has now pissed off these people and made them look bad.

They didn't drop Chrome Frame. It was a stopgap solution from the very beginning. It gave companies 4 (!) more years to fix their infrastructure. It did what it was supposed to do.

If you haven't done anything within those 4 years, giving you another 2 won't help either. You're clearly waiting for everything to fall apart.

So what were they thinking? Is the number of large organizations stuck on old IE (<=8) not important enough to Google? Or - more worryingly - did they not think it through properly?

I just don't see how that decision got made. Even freezing/slowing development on Chrome Frame would have been bearable - but dropping it?

The only problem I see is that Dart developers are focusing to much in the newer stuff w/o ironing the basics first, for example, the DateTime datatype can't parse this: "2013-08-03 12:00" but can parse this: "20130742", and to me is more important to work in those basics than all the fancy Canvas stuff or polymer.

We don't know the level of compromise Google has with Dart, I'm taking the risk cause I think is worth it.

It would take a lot of effort to do worse than JavaScript.

CoffeeScript is basically just JavaScript with a Ruby-inspired syntax.

TypeScript is only a very minimal set of improvements to JavaScript.

If it's doing things right, it should be blowing all three of those away with ease, especially given its origin. The fact that its uptake is so slow suggests that it isn't competing against them very well, which I take to be a bad sign going forward.

Thanks for using Dart!

http://blog.chromium.org/2013/06/retiring-chrome-frame.html seems like a pretty good reasoning w.r.t stopping updating Chrome Frame and lists alternatives. What's all this noise about? And what the hell does this have to do with Dart?

Why it's being picked up by HN is beyond me... maybe because Google is the favorite scapegoat recently? Certainly few people bothered reading what he wrote and just started commenting/complaining.

It's astonishing to me that Google is getting flak for dropping (in 5 months) what amounts to a 3rd-party-patch for a browser that'll be turning 5 years old. They already dropped support for IE8 in Google Apps, and jQuery dropped support several months ago.

If Fain wants to play with fancy new technologies, he should find clients who want to use new technologies.

5 years is a lifetime in web technology. 5 years ago nobody was using coffeescript, angular, ember, or any of that. They didn't exist, or if they did they were crude ancestors of what they are today.

I just don't think you can have this expectation of any guarantees like that in web development. Things move too fast. If you want that kind of guarantee, use open source stuff and acknowledge that you'll have to support it yourself when the rest of the world moves on.

Angular, Ember, etc are just frameworks. They're not likely to be as long-lived as the triad of front-end web development technologies because the creation of such a framework has a significantly lower barrier to entry and adoption. There's no W3C committee overseeing development and there will be no W3C draft or standard for any of these somewhat ephemeral frameworks.

Core web development technologies are very stable and their development, deployment, and adoption happens quite slowly; on the order of decades. If Dart does become widely adopted (and with the support of browser markers) it'll likely remain in place for a long, long time, far longer than the latest JavaScript framework or veneer language de jure.

Even if Dart does become widely adopted, Dart hasn't got a hope of truly replacing JavaScript, at least for the foreseeable future (>10 years), as both a Dart VM and a JS VM would have to coexist in all browsers for reasons of backward compatibility. Yay, browser codebase bloat!

Seems like a non-issue to me. When we run out of real criticism against Google we just make some up because they're big and.. you know.. playa hatin'. ;)

Try to remember that it's first and foremost a search engine with ad-revenue. Anything else is a product of a liberal work environment and driven employees.

But that's actually a really good reason to hesitate a bit before betting your own project's success on anything they put out that isn't directly related to the search engine or the ad products. It's not "playa hatin'" to recognize that things from Google that aren't strategic to them may get dropped some day, it's just being pragmatic.

You're blaming Google for not supporting a dead platform that not even Microsoft is going to support any longer.

It's time to upgrade your internal systems. Don't blame Google for not wasting resources on a shitty broken browser that causes developers to waste time supporting.

IE6 needs to die, die, die.

It doesn't have the money of Google, but it has been around for 8 years, and is backed by its own non-profit foundation. It just recently hit version 3.0: http://haxe.org/manual/haxe3/features

It continues to make steps forward with new cross-platform development frameworks like openfl. http://www.openfl.org/

Err, Google Frame is not a "solution" for Dart not running on older IE browsers and it doesn't just download "Chrome's Javascript VM". It's (was) a way to install a different web engine for IE altogether, based on Chrome.

Second, it's not "automatically downloading" (which might give the impression that it's transparent to the user) -- you have to install it.

Chrome Frame on older Internet Explorer versions shouldn't really need to be updated that much, since those browsers aren't changing that much. Also, I find it really hard to believe that the kind of IT department that decrees that everyone has to use IE6 (or whatever) would ever allow such an invasive third-party plugin as Chrome Frame in the first place.

The limited browser compatibility of dart.js is a real issue and probably is a dealbreaker for some enterprise situations. But there's no need to bring Google Reader into this-- it has literally nothing to do with it.

The other thing which everyone seems to be missing here is that even if Google does "become bored with Dart," there will still be an open source community to support it. Coffeescript has been around forever without any sugar daddy. A big part of the reason for using open source technologies is to avoid vendor lock-in and other similar questions about the future.

If things like design docs & decisions, the main bug tracker, commit rights, and so on are all internal you end up with no one with the institutional knowledge to take over if the company decides to drop it. The most famous example of this is probably the open sourcing of Netscape Navigator which lead to a four year gap before the next release, due to a ground up rewrite.

Yes, you have the source code, so you can fork Dart if you want, I guess. How are you going to get your Dart fork into a browser?

Sounds like any other language or any other piece of technology. No one starts with standards. This always happens some time after 1.0.

http://en.wikipedia.org/wiki/JavaScript#History

first shipped in beta releases of Netscape Navigator 2.0 in September 1995

In June 1997, Ecma International published the first edition of the ECMA-262 specification.

> you can fork Dart if you want

You don't have to. The tools and the VM will continue to work. In the late 90s, I used a compiler from 1989. It still worked fine and it still works fine today (e.g. via DOSBox).

I really don't know why everyone here seems to think that these kind of tools will self-destruct if left alone. They really don't do that.

> How are you going to get your Dart fork into a browser?

You don't have to. You can still compile to JavaScript. You can still use the VM on the server, for command line stuff, or on Android devices (there will be an ARM VM soon).

It would be only a problem if you wouldn't be able to use browser with native Dart support for client-side web development, because compilation takes a few seconds and because you wouldn't be able to debug from within the IDE.

Is your concern that Google's name behind it will give it more popularity than its design/implementation merit, and you'll have to use it instead of Javascript because employers/clients will demand it? The job market is much bigger than you are imagining: I'm sure someone out there will still pay you to write COBOL. So I wouldn't worry too much about this yet.

The current community seems pretty active, and Dart isn't even at 1.0 yet: https://groups.google.com/a/dartlang.org/forum/?fromgroups#!...

I respect your work a lot, but are you sure your view is not biased a bit by working for Google? It's sometimes hard to disconnect from that kind of working environment to see the kind of issues into the future certain practices can have.

Dart turning into something bad for the web is really not all that unfounded or unjustified. You don't have to agree, but you shouldn't dismiss that argument so quickly.

Dismissing this kind of thing is what leads to 'impossible' scenarios happening. The point needs to be raised, repeatedly, and hopefully within Google as well. As long as a possibility exists for Google to misuse Dart, there needs to be voices speaking out against that possible misuses before it occurs, not after.

Google is interested in making the experience of developing web apps better, and making web apps more performant. They have many different strategies for this: Chrome DevTools, AngularJs, Web Components and other spec improvements, Dart, Closure Compiler, GWT, etc. The company does not make money from selling the Chrome browser, and unlike Microsoft, it doesn't make money from selling an OS. The incentives are not aligned like the way they were with IE and Windows. At the end of the day, Google makes money from people using the web. The real threat is from the Web falling too far behind Native.

Also, the Web is far far bigger than the programming language Javascript. For the first 10+ years of the Web, people hardly even used JS except for form validation, and in general, on mobile, excessive amounts of JS lead to poor performance.

There's still a ways to go on just HTML and CSS, and I'd frankly be more concerned about fragmentation in that area rather than fixation on Javascript.

The way I see the potential of a DartVM is the same as OdinMonkey+asm.js. Dart compiles to JS, but DartVM will run it slightly faster, but it will always work on all browsers. Likewise, asm.js will work on all browsers, but will always run faster on OdinMonkey. Both Mozilla and Google have VMs that potentially bifurcate performance across browsers, but still produce outputs that can run (albeit slower)

The concerns you should have about Google misusing Dart I think should really be about Google misusing market share. It's not really Dart per se that's the issue, it's the fact that if Chrome is the dominant browser, Google can drop anything they want into it, not just Dart, but any APIs they want.

It's much harder to write cross-browser CSS, with full GPU compositing, and responsive layout than it is to compile Dart to JS. What is the incentive for the developer not to do is and leave a huge chunk of marketshare on the table with little effort?

Stuff like prefixed-CSS is a far far worse threat to the Web than a DartVM.

History tells us what will happen.

Again, I'm not disagreeing that there is a danger of fragmentation, but this won't happen because of Dart, but because of other forces. The criticism over the DartVM is being blown way out of proportion.

The best defense against any of this happening is not to protest Dart, but to make sure the browser market is competitive.

Why wouldn't you? Minifying Dart or compiling Dart to JavaScript is basically the same. You invoke the very same command line tool just with different switches.

Why would you do one thing in your build/deploy script but not the other? Especially if doing so makes it incompatible for a significant chunk of your users. Most people won't even drop a 5% chunk (e.g. something like IE8).

>or not testing it [in other browsers]

I don't see how that's specific to Dart.

Regarding the Dart language, I agree fully. It's another option like the ones you mentioned. They all generate JS, and since we have pretty good guarantees of JS running the same on different browsers, everything is interoperable.

But regarding the Dart VM, there is a concern. Of course the Dart VM on the server etc. is fine, but there is an issue in the browser: If Google ships the Dart VM in Chrome, and the Dart dev tools generate a 'fat build' containing both Dart and JS, and Chrome runs one while the rest of the world runs the other, we are at risk of fragmenting the web.

As Chrome's market share rises, many people are testing first and foremost in Chrome. It is possible that they will not include the JS part and ship only the Dart part, or that they will do far less testing of the JS part, leaving it suffering from bugs and performance faults.

Even if the Dart VM is open source, that is a bad situation that could break the web as we know it.

> The way I see the potential of a DartVM is the same as OdinMonkey+asm.js

The crucial differences is that asm.js is a strict subset of JS. There is 0 risk of someone shipping something that only runs in one browser - it is literally JS, and will run fine everywhere.

(And not just will it run, but it also runs quickly everywhere, because asm.js is not a random new subset but the result of a long-running industry trend, for example in this link asm.js code was fast on 3 different browsers http://j15r.com/blog/2013/07/05/Box2d_Addendum )

prefixed CSS and APIs are far more of a fragmentation threat. WebKit on mobile, for example.

But I disagree it is 1% for the risks mentioned before regarding the Dart VM in Chrome. It's hard to estimate that. If Chrome continues to increase in market share, it will no longer be a "huge chunk" of the market that they lose if they do not support dart2js, and furthermore, it isn't just a matter of working or not, but also how much focus on bugfixing and performance work they put on the JS fallback. It's easy to imagine many developers (especially smaller ones) developing in chrome and testing in chrome, and just verifying basic stuff works in other browsers.

We are not far from that risk today in other areas, for example important sites like Google Docs already say "For an enhanced and optimized experience, use Chrome". The risk gets that much worse when Chrome is actually running completely separate content in the Dart VM from everyone else.

The only defense against this is to preserve competition. My continual criticism in these HN threads is that people's vision is too narrow, too focused on irrelevant battles, focusing energies in the wrong place.

These are two battles going on right now. WebKit derived vs Mozilla, and Web vs native Mobile. The latter is a serious threat and no one is really offering anything to attack the problem. And no, FirefoxOS and asm.js doesn't.

Simply put, consumers find it easier to find and buy content on native platforms, and developers find it easier to use tools on native platforms. The Web has a huge looming consumer and developer problem. A lot of people who sit around in VIM/Sublime all day hacking MVC or jQuery websites don't seem to realize the looming problems.

Web Development needs to be made radically more productive. Web Performance needs to be radically upped. The current tap dancing around ES6 improvements or ION/ODINEngine are nice, but simply too underwhelming.

Web Components are a step in the right direction. But honestly, if I wasn't working for Google right now, I wouldn't be writing a web app these days, I've be writing an iOS or Android app.

Both Google and Mozilla have huge problems to solve IMHO, and this bickering over Dart, NaCL, Asm.js, et al is a big distraction. These organizations need to work together to make the web delightful on mobile and for developers as the whole industry transitions.

People make iOS apps and not web apps because iOS apps perform better on iOS than web apps on iOS. And iOS is where most app money is made. Making the web a better platform in general won't directly help with that, important as a goal it is.

I don't agree there is "bickering" over Dart, NaCl/PNaCl, asm.js. There are issues of principle there. For example, if we make the platform stronger but it loses some of its core attributes (like portability were NaCl to be adopted) then the whole thing is at risk of becoming pointless. At the same time, we do need to make the platform stronger and competitive in terms of speed with native as much as possible, which is a fine line.

Google commands tremendous marketshare with Chrome now, and so people are going to be hyper-sensitive about anything it does. But I would read PPK on Blink for example (http://www.quirksmode.org/blog/archives/2013/04/blink.html) to see how Google is treating the Web.

Honestly, the Web has been driven forward tremendously in the last few years with HTML5, CSS3, WebRTC, etc but Javascript hasn't budged much, although performance has increased, the warts of the language have not been fixed, and TC39 is taking too long. That's why you're seeing everyone create languages that compile down to JS.

My biggest concerns are that if the problems of the Web platform aren't fixed, especially for mobile, a whole generation of people will be raised on native apps, and the most amazing platform for distribution of federated, transparent information in human history will lose.

Simply put, the Web is more important than Javascript.

There's plenty of examples that show Google has a pattern of abandoning open-standards in favor of proprietary solutions. XMPP, WebKit, RSS: embrace, extend, kill. Now JavaScript is in the gunsights.

Stay away from Dart.

RSS, by kill I assume you are hinting at how all the feeds were available through Google Takeout and Google Reader APIs that other SaaS applications used to very quickly get up to speed. And how it was recently reported (on Verge?) that these providers are doing great. Heck, I remember reading a Google blog post that even listed these alternatives. So as it was said elsewhere in this thread, stop spreading false information.

Are you talking about JavaScript? ;)

http://en.wikipedia.org/wiki/JavaScript#History

It's true that Dart and JS are the same in this regard, but it's not 1995. If Dart was introduced in 1995, it'd certainly deserve to beat LiveScript and we'd probably be using it now.

Furthermore, this person didn't care about tooling and he also didn't have any clue about optimizing virtual machines.

Anyhow, any language or piece of technology needs to reach a certain state of maturity before it can be standardized. Once you standardized something, things are pretty much set in stone.

when a project is open source with a permissive license as dart is, how can it become a walled garden?

walled garden to me is a closed platform, where nobody can change or see whats happening inside.. how that reality maps to dart?

and people believe things like javascript are open standard, just because it have a commite? isnt that why javascript is stuck in the nineties and cant move forward?!

Dart is a cool, modern and fast language designed from the ground up to give us a choice against the ugly javascript..

nobody really likes javascript, people just have to deal with it, because is there no option (until coffescript, dart, typescript and others came by)

why is so bad to have options? and what could be the evil plan of google behind the creation of dart?

there a lot of things i disagree the way google has being doing things.. but this technological fanatism will hurt us all..

Personally i dont care it came from google, or any other company.. actually from what i understand from the hystory of dart, it came from a V8 developer and its passion to make a better language that could be better for bigger projects and compile faster.. isnt cool that google believe in this project and put so many badass vm people behind it to make it work?!

i just dont understand what could be bad in this sort of move.. its innovation, and its open.. its miles away from a walled garden.. and any browser or any application can adopt it and make it even more open and widespread adopted