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.