1. Many web technologies were developed by a single player: JavaScript and Canvas are pretty big examples.

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.

I hope you're not saying that since JavaScript was designed a certain way, we should design all technologies that way. Because that's obviously false. v1.0 JavaScript was a complete mess and it's only thanks to the tireless efforts of the TC39 crew that we have a more reasonable language now with ES5.

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.

"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"

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.

SGI OpenGL isn't really all that relevant in this case. SGI OpenGL is absolutely ancient at this point and modern WebGL has only a passing resemblance to it. The feature set is different, the constraints are different, lots of things have been removed, lots of things have been added, and all of that at the behest of the community.

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.

All recent variants of OpenGL were derived from the most successful OpenGL extensions by vendors like NVidia, ATI, 3dfx, S3, et al. They shipped them first, developers even picked them up in games via extension detection. Then later versions got the extensions.

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.

And which part of the Dart API or language isn't documented? The Dart language spec has been published since 0.1 with every change in the change log, and every change discussed on public mailing lists. http://www.dartlang.org/docs/spec/latest/dart-language-speci... Can you explain to me how this is different than NVidia or ATI publishing an extension for hardware they already spent millions on and 18 months preparing to ship?

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.

I like how I keep saying 'in the open' and you keep saying 'by committee'. OpenGL extensions are the textbook example of what I'm talking about: Published documentation of the API surface, what it does, etc.

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...

Dart and NaCL design are not happening behind closed doors, period. NaCL was first published as a research paper. All development since it was published has happened in the open. None of the popular languages today have been the designed the way you suggest. K&R designed C behind closed doors, ANSI C came later. Python, Ruby, Perl, JavaScript, the list goes on and on, all designed and prototyped first prior to any kind of standardization. Committee driven languages like C++ have shown to bloated monstrosities in terms of complexity. Creating a focus group and committee to design a language is the surest way to lead to failure or to compete with Duke Nukem Forever for delayed completion.

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.

> I have a nagging suspicion that many of these arguments are based around aesthetics and language chauvinism.

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.

I don't know why you're fixated on things like asm.js and C++ here when I didn't bring either of them up. Here's the deal:

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.

It's interesting you mention Web Audio, because Web Audio, AFAIK, is based on a tried and true mature Audio API (Core Audio on OSX, Chris Rogers worked on both) that has had tons of feedback from the professional audio community for years. I wonder, how much of the objection is based on Mozilla because their counter proposal to essentially delegate DSP to JS was rejected?

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.

Web Audio being supposedly based on Core Audio is beside the point; the web isn't OS X. I never claimed that it was designed by someone who was ignorant or designed without awareness of experience.

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.

(I don't know why I keep wandering into this thread; I don't even like Dart, but here goes...)

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=...

I appreciate your detail here and I think I agree with some of your points. What is the source of your PoV on Canvas, though? From my history of using it and the other end users I've interacted with who use Canvas, I just don't understand how someone could call it 'extremely well thought through' as an API.

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.