While some misinformed people might make this argument, I don't think you'll find anyone making it at Mozilla or other groups that actually participate in web standards development. We all know that the normal process is to implement first and then standardize. That's what Mozilla has done in the past with features like Geolocation and WebGL, and it's what we're doing today with new work like Audio Data, Game Pad, and Telephony. In fact, the W3C process requires two interoperable implementations before a specification can reach the Recommendation stage.

But there's a difference between a standard that is developed in the open, with the opportunity for all parties to provide feedback and influence development, and one that is developed and implemented in secret, and then deployed to production browsers and evangelized to content authors before anyone else has a chance to comment on it -- or even on whether the fundamental approach is a good idea. (And obviously these are two extreme ends of a spectrum, with a lot of gray area between them.)

The problem with many of Apple's "contributions" (and some of Google's) is that they never write specs for them or bring them to standards bodies. (This is the case for Aplle's -webkit-text-size-adjust.) In some cases they actively fight efforts to standardize them. (This is the case with Apple's touch events.) Or sometimes they do push specs to standards bodies, but only after a highly complex specification has been fully developed behind closed doors. (Google's Dart, NaCL, and Pepper have this problem to some extent.)

That's fine if what they really want is a proprietary ecosystem that works in their own browsers. But if they actually want these efforts to be part of the web, and if they want to be seen as stewards of an open web, then just implementing something is not enough. The web has lots of stakeholders, and the initial implementer needs to find a way to bring them to the table.

NaCl was first announced in 2008, along with a research paper and and source code (http://googlecode.blogspot.com/2008/12/native-client-technol...). The next year Google sponsored the NativeClient Security Contest that awarded prizes to security researchers who could break out of the sandbox. A lot of the design surrounding PNaCl has happened in the open (see http://www.chromium.org/nativeclient/pnacl). I don't think it's accurate to say that NaCl was developed behind closed doors.

Also, other browser vendors seem to oppose NaCl in principle, and it seems unlikely that any other process Google could have taken to get buy-in would have resulted in other browsers accepting it.

I agree that there is a continuum of behavior here; in the NaCl case in particular though, it really seems like Google has done the right thing.

And how could NaCL have been done any better? It's been publicly published for years prior to the first shipping implementation. If Mozilla was interested, they could have put in requests for how they'd like to see NaCl and Pepper changed to better fit a Firefox implementation, or even a counter-proposal for running untrusted native code. But I've seen no such proposals, instead, just a blanket refusal to even consider it. I think there's a philosophical difference such that Mozilla isn't really interested in anything that isn't JS based, so suggesting that bringing NaCL to the working groups would have changed anything is somewhat disingenuous. It's kind of like hoping that Republicans would contribute to a National Single Payer healthcare plan design if it had been brought to the right committee.

It's a shame really, because proprietary native mobile platforms are hurting the web, and consumers don't really care, they just want fast apps which don't kill their battery or phone performance. Something like NaCL for mobile could preserve the DOM, CSS, browser security model, and other good things about the web, but replace JS with something much more performant for games, and this would go a long way to hedging risk against the proprietary native platforms. I'll take portal NaCl C-code calling into browser APIs and WebGL any day over Obj-C code calling into Cocoa that can only be installed through an app-store.

If the Web is to be around for decades more, the religion over programming languages needs to give way to polyglotism.

As on Dart, the language was released at version 0.1. The grammar isn't all that complex, the library is minimalist. It came with a early spec and source. It is not a "fully developed" specification. No one designs language grammars by committee. Languages are highly personal and opinionated. Usually one or two people design the overall structure of the language privately, and then release an initial spec, and it evolves from there.

When Mozilla developed Rust, the first time most of the web heard of it was Graydon dumping a gigantic codebomb into GitHub and it being covered on Lambda-the-Ultimate.

Which I think is perfectly find, but let's try and be a little level headed and fair, and not arrogantly think that what Mozilla does is uniquely better than what others are doing.

(I speak only for myself and I do not work on Dart, NaCl, nor Chrome)

Certainly, every vendor has been guilty here. I at least think that every extension Mozilla is currently encouraging use of is hoped to be a potential future standard. (And no, I'm not claiming this is unique -- some other vendors like Google are also good citizens in this regard.)

I also agree that proprietary platforms are hurting the web, and that the web needs new abilities in order to fight the threat. However, to preserve the openness of the web, new features need to be things that more than one vendor has the resources and motivation to implement; even if Mozilla and Opera thought Dart or Pepper were great ideas, adopting them would put is on a treadmill where Google (with its much greater resources) controls the speed.

And no, I am not claiming that Apple/Mozilla/Opera would have adopted Dart or NaCL if they were brought before the right committee at the right time. Part of getting early feedback means finding out if the community even thinks that your solution is something that's desired in the first place.

"When Mozilla developed Rust, the first time most of the web heard of it was Graydon dumping a gigantic codebomb into GitHub and it being covered on Lambda-the-Ultimate."

This is actually an interesting contrast between Mozilla and Google. The initial Rust code-dump was a barely-running proof-of-concept; it was shared with the world on the same day it was first shared within the Mozilla community. Zero lines of the current self-hosted compiler were written at the time. Most of the planned features (like the task system) were unimplemented. The first actual release (Rust 0.1 alpha) came a year and a half later, and that first release already reflected significant community feedback and contributions. For example, the packaging system in Rust 0.1 was written by a volunteer contributor who happens to be a Google employee. The stage of maturity at which Rust became open source was far earlier than Go.

Some things really are different at a non-profit like Mozilla, and the goal of opening everything up as early as possible is one thing that's unique among tech companies I've worked for or with. We don't always do it perfectly, and we do struggle with the need for people to do some types of design and experimentation without the world looking over their shoulders, but it's very much a unique core principle that affects all of our work.

Almost all of the additions to the browser API that Google has made are desired to make it into spec proposals. There is no desire for Chrome to be the only implementor of Dart or NaCL.

I'm a little concerned what you're saying here. That if an idea is good, it won't be adopted anyway, just because someone else has greater resources to implement it. It sounds like Not-invented-here syndrome to me. No matter what technical specs are proposed, Google is always going to have greater resources to develop them.

Everything you say about Mozilla, I can say about my experience at Google. The first release of Dart was very incomplete, it didn't implement a lot of the type system, no missing method, some stuff like default method parameters didn't exist. It generally really slow and bloated code. It was in a barely working state. The DartC compiler which was implemented in Java was not a production compiler design to be used by people, it was a prototype for research. This idea that Google sprang a fully-formed already finished product on everyone is a gross exaggeration. The Dart VM isn't even in Chromium yet.

The self-hosted compiler (Frog, written in Dart) has been developed completely in the open.

Google is a large company with hundreds and hundreds of projects, so not all of them operate the same way, but many of them are open sourced very early in the process, and Googlers push to release source early for client side web technologies. Google has spent hundreds of millions of dollars on acquisitions which it immediately turned around and open sourced, like WebM, and the first Google Web Toolkit, and Instantiation's products (donated to Eclipse Foundation)

Really, I think the comments on NaCl and Dart are patently unfair. They were released practically as early as they could have been, NaCL took, what, 2-3 years in the open of development before it was finally pushed to production.

Ultimately, if standards committees get gridlocked over political and emotional stuff, instead over the merits of technology, you will see people start to ignore them. A similar thing happened in with OpenGL ARB where vendors who had less resources voted down and blocked companies like NVidia and ATI who were progressing chips at a faster pace. Ultimately, it took DirectX surpassing OpenGL to push it to finally start evolving faster again.

I do think we agree on fundamentals though we may disagree on some cost-benefit analysis. All I meant about the "treadmill" is that some proposals have a much greater cost to implementers than others, and different organizations will weigh those costs differently. While some debaters may throw out "political or emotional" responses, I believe the decision-making process should be (and is, in the cases I've participated in) about allocation of resources, complexity of implementation, and the desired architecture of the web.

Technical issues and process issues are separate, but affect each other. When I say the process behind something like Touch Events was bad, I'm not giving that as a reason to reject the feature -- I think the feature should be accepted or rejected on its merits, like you said -- but it does mean that any technical objections that do appear will be much harder to resolve than they might have been. And as you say, Dart and NaCL have had better process behind them than Touch Events or various other extensions I could name. Dart and NaCL may succeed or they may fail (just as many of Mozilla's current experiments may suceed or fail), but at least their fates will be influenced by feedback from all stakeholders.

You are obviously better informed than I am about Dart and NaCL implementation. (Also, I accidentally conflated Go and Dart in my previous comment, which is embarrassing!) I apologize for any uninformed comments and defer to you on all the facts there.

I really don't want people to see this as a "Mozilla versus Google" thread. I hope everyone cares about standards issues because they help or hurt the web, not because they helps their favorite vendor or hurt a competing one. In the big picture, Google and Mozilla are close allies when it comes to web standards. As you say, the real risks to the open web are elsewhere.

Also:

  > The big issue I have with Dart, which you
  > seem to consider inconsequential, is whether
  > Google forks the web developer community,
  > not just its own paid developers, with Dart,
  > and thereby fragments web content.
  >
  > "A Dart to JS compiler will never be "decent"
  > compared to having the Dart VM in the browser.
  > Yet I guarantee you that Apple and Microsoft
  > (and Opera and Mozilla, but the first two are
  > enough) will never embed the Dart VM.
  >
  > "So "Works best in Chrome" and even "Works only
  > in Chrome" are new norms promulgated intentionally
  > by Google. We see more of this fragmentation
  > every day. As a user of Chrome and Firefox (and
  > Safari), I find it painful to experience, never
  > mind the political bad taste.
  >
  > Ok, counter-arguments. What's wrong with playing
  > hardball to advance the web, you say? As my blog
  > tries to explain, the standards process requires
  > good social relations and philosophical balance
  > among the participating competitors."

Basically he's arguing that the browser vendors of today (not developers/users) are the gatekeepers of what new technologies can be tried. It's like making browser innovation a UN Security Council where every member has a veto over doing anything. If you value progress and innovation, I do not see how you can support such a position.

If Google introduces something like Dart or NaCl, is willing to support standardization of it and even release a free implementation, but other browser vendors don't want to integrate it because they don't like it, that's their problem, not Google's. If that means popular apps become "Works best in Chrome," that is a self-inflicted wound.

A few hours ago at JQuery UK someone asked Paul Irish what he thought of Dart. Then the whole room laughed. PI mentioned 'its complicated' and then that 'Dart has a place' and then everyone laughed again.

So a knee jerk unintelligent response by some random group of Javascript programmers, given without context, is supposed to mean something?

The knee jerk reaction I was referring to was the "the whole room" of js guys that "laughed".

But I cannot understand either the point or why. If you could chip in with some context, I'd be grateful.

Anyone's free to try things. But those things will never become a part of the web platform if other vendors don't think they will benefit from implementing them. The people who make the browsers are gatekeepers of what ends up in the browsers. That's not a statement about how things should or shouldn't be; it's just a tautology.

The job of anyone who wants to create a web standard is to accept that fact, not ignore it. Ignoring it leads to single-browser "standards", which may get adopted by developers but will not become part of the open, interoperable web platform.

And, what are the things Webkit has built that were "overridden" by the standards process? Where did Webkit actually get things wrong?

Just what comes to your mind.

Today, experimental and prefixed features used in the wild are creating real problems for interoperability and competition. But I don't think there's a villain here, and I'm not blaming WebKit. Both the browser vendors and the W3C are using processes that were designed to certain solve problems. Now those processes are creating new problems and might need to change in response.

But, to answer your direct question (although I think this is getting on a tangent from the original post):

> "What are the things Webkit has "proposed" by releasing builds that you don't think should be part of the web platform?"

Dart is an example of something that Google has proposed (not "WebKit" as a group) that I and many others - even others like Oliver Hunt within the WebKit community - do not think benefits the web platform. Some people would put Web SQL Database in this category; I don't have an informed opinion about that one. (Though I do know it's the reasons some versions of Gmail wouldn't even load in mobile Firefox.)

> "Where did Webkit actually get things wrong?"

Apple's "meta viewport" tag is something that they released in Safari and evangelized to developers without specifying it or getting community feedback. I had the pleasure of reverse-engineering it for Gecko. Among other things, it's not even implemented in a layer where it makes sense. (It should be part of style, not markup.) Apple never proposed it as a standard; other people eventually did and are trying to fix some of the problems. Unfortunately, the basic design is locked in by legacy content (and has been since soon after Apple shipped this feature in the first release of mobile Safari).

But frankly, I don't care so much whether they get things "right" or "wrong." As bad as meta-viewport is, at least Firefox and Opera and Android and IE can implement support for it without controversy, and be compatible with sites that use it. The way that prefixed CSS properties are (a) released to market by browser vendors, (b) evangelized to web developers, and (c) deployed on production web sites is creating a situation where new browsers are either locked out of existing sites or have to implement each others' prefixes. This is not a stable equilibrium.

One thing I didn't have going into this thread that I have now is appreciation for how different this problem is in the mobile space than on the "desktop" web. It's easier to be frustrated with web standards in the desktop world, where Webkit seems like an unalloyed force for good. I can see how much trickier it is for your team given the fact that Gecko has been relegated to second class status by the market.

A number of people seem to have a somewhat extremely optimistic view that they're going to make Javascript competitive in performance and memory use compared to native on mobile platforms. There's just no evidence that it's going to happen anytime soon. It's just not even close, despite how magical emscripten or Mandreel might seem.

With more and more browsing activity shifting to mobile, and with the majority apps being entertainment/multimedia/games, holding steadfast to the idea that there are not benefits to alternate VMs is more of a dangerous than transient breakage of pages.

Yes, the prefixes are a problem, but the Web needs to evolve fast to keep up. A period of incompatibility and fragmentation can be tolerated. It's happened before, chaos and disequilibrium followed by periods relative calm.

I'm more worried about stagnation, and a future where the web gives way more to the client-server internet days, with everyone running OS specific native apps that read and store data behind walled-garden non-HTTP clouds.

Note that in a world where the Web was defined as "whatever WebKit renders", which lots of HN readers seem to be in favor of these days, we would of course be stuck with the old gradient syntax forever.

I completely disagree.

First, if a technology is really bad for the web, are you saying other browsers should still implement it, just to not suffer the situation where popular apps work best in Chrome? That's bad enough as it is, but those popular apps are likely going to be Google properties - google.com, gmail. That means Google can basically force other browsers to adopt technologies as it sees fit, even if they are bad for the web.

Second, the WebKit situation on mobile exactly shows why this is wrong. If one popular browser adds special features and leaves them there indefinitely, in release versions of the browser - as WebKit does with its special CSS properties, and like Chrome does with NaCl and perhaps soon Dart - then people will develop for those features. If that browser then becomes dominant, those features will become a de-facto standard. Given Chrome's incredibly rapid rise, we should not assume it will not become dominant on the desktop, so this should concern us all.

--BUT--

With ActiveX, there was no other way to accomplish the same task. With Dart versus JavaScript, I can't accomplish anything in Dart that I can't in JavaScript. And, even if I decided to use Dart for some reason, it would be idiotic of me not to provide a JS version for non-Chrome browsers.

What would be really nice (heck, even something a standards body should have done) is coming up with a standard byte-code for browsers, so I can use any language I want. JavaScript isn't good enough, because I want my sites to load faster, and parsing the code shouldn't have to happen every time somebody visits a page.

I used to think that too, until I read convincing arguments against it like this: http://www.2ality.com/2012/01/bytecode-myth.html

For example, late-binding, boxing/heap-numbers, etc all serve to make it extremely difficult to maximize startup performance, or heap overhead. It also makes the VMs much more complex to deal with optimizing such languages. TypedArrays don't really fix the problem, they just introduce others. For example, by forcing your to implement your own manual memory management everywhere. This is somewhat problematic if you're compiling a language with GC into TypedArray heavy code, since there's no finalizers in JS or Reference queues, you can't really do automatic release if a regular heap object holds into pseudo-objects in manually allocated memory.

The problem is particularly acute on mobile devices which are very resource constrained.

But this is beside the point: Eich never asked if web developers want it or not.

If a technology has only implementation, even an open source implementation, that implementation will have all sorts of hidden assumptions and biases. No one will know about or understand those assumptions and biases until the time comes to use that technology in a new context.

In my work, I've dealt with multiple implementations of things like simulators, models and even languages. The additional implementations usually had some specific reason behind them (performance, alternative features, supporting different execution environments, different mathematical properties and so on). Nevertheless, the value of each alternative implementation (in terms of surfacing hidden assumptions, finding bugs, illuminating more general and flexible alternatives, etc.) went well beyond the specific reason that implementation was made.

These considerations are even more important in the case of software that is part of a large, chaotic, heterogeneous system like the Web. Imagine where the mobile web would be today if there hadn't been a W3C and, at the turn of the century, the Web really had been "what Internet Explorer renders" with no attempt to document and codify anything else.

Or, to take your example of Objective C, how much does Objective C matter outside of Apple's ecosystem?

Contrast this with:

- How much does JavaScript matter outside of Netscape's ecosystem?

- How much does Java matters outside of Sun's?

- Or, to take the granddaddy of examples, how much does C matter off of the PDP-11 and outside of Bell Labs?

None of those languages would be anywhere near where they are today without standards. On the other side of the coin, there is a reason languages like Python, Ruby and Haskell have had (and, each to a varying extent, continue to have) a "bus problem". Standards matter and even just the standardization process itself matters. I wish more people understood that.

It doesn't need to. Apple has demonstrated the agility of a wholly owned, vertical stack. The pace of change has qualitatively changed since the days of language standards set by plodding standards bodies.

But that also means that, no matter what its true potential is, Objective C will never be more than what Apple makes of it. It won't be seriously used outside of application areas Apple is interested in. It won't develop new features Apple doesn't care about. And if Apple decides to go in a different direction and/or runs into serious trouble, well that's it.

Apple has changed the world, but, unlike some other, standardized languages including the ones above, Objective C never will. If we lose the full potential of future great languages because they are limited by a single company and/or a single implementation, we will all be poorer because of that.

As you might guess from my username, I'm a fan of more than a few languages where (at least I believe) the differences go well beyond syntax. That means I want standards because I want to know what I can (or could) take with me to another platform and what I can't.

There are ongoing efforts to standardize a quite sizable subset of Ruby in Japan for later ratifications in ISO. Ruby is also de facto standardized by the test-suite RubySpec.

It is not ridiculous at all, in fact reference documents such as RubySpec have been one of the main reason for which you can move from a Ruby implementation to another without many issues and without having many compatibility hacks included in each compiler/interpreter.

Really? It doesn't sound all that ridiculous if you know cpython is the reference implementation of the language python, which is extended by the PEP process.

It has those too. And IIRC the w3c requires a browser to implement a reference version before something is standardized there.