Mozilla can produce near-native performance on the Web

What a formatting mess -- I hope you can you still edit your post and put two newlines after the >-cited lines from my post, and the text where you start replying? Thanks.

If I can read through the mess, you seem to be saying you can't evaluate PNaCl, so you'll just make airy and overconfident assertions about it. Even on HN, that doesn't fly. -1!

When I challenge your further assertion that something is "easily integrated into any browser", you switch subjects to arguing for prototyping and developing a complex system before standardizing it. Good idea (but beware the difficulty standardizing it late if simpler evolutionary hops beat it in the meanwhile; more below on this). However true, that is a dodge, it does not excuse your assertion about "easily integrated".

Doubling down by citing "the DOM" as if Pepper were only about OS and DOM APIs, or as if even just the DOM implementations in different engines had enough in common to make interfacing from native code (not from JS, which is hard enough even with a decade+ history of written standards and market-driven interop testing) easy, just repeats this bad pattern. So -2.

Then you seem to confuse ES4 with Harmony (which I made clear came about after ES4 failed). -3.

At this point on USENET, you'd hear a plonk. But I'll close with one more point:

Mozilla and Google using LLVM does not equate to standardizing PNaCl. Pepper is one problem, a big one, but not the only one. Consider also the folly of using a linker-oriented intermediate representation for a shelf-stable Web-scale object file format. See Dan Gohman's "LLVM IR is a compiler IR" post:

http://lists.cs.uiuc.edu/pipermail/llvmdev/2011-October/0437...

Shortest-path evolution usually wins on the Web. Trying to standardize PNaCl -- including Pepper and LLVM IR abused or patched into shape as a long-lived object file format -- is an impossibly long, almost exclusively Google-dependent, path.

Extending JS among competing engines whose owners cooperate in Ecma TC39, via a series of much shorter and independently vetted and well-justified (by all those engine owners) path-steps? That is happening in front of your eyes.

You may not like it. You may want to say "Go home, evolution, you are drunk":

http://wtfevolution.tumblr.com/post/40659237456/this-pelican...

But it would be foolish to bet against evolution.

/be

The problem with the DOM is not that it's intrinsically slow, but that it's very easy to do slow things with it inadvertently. There are often N different ways to do things, due to the evolution of HTML. The newer approaches tend to be designed with things like GPU acceleration in mind (e.g. CSS transforms), whereas older methods often had lots of heavy interactions and computations because they weren't expected to be used dynamically.

Just like optimizing any software takes skill and knowledge, so too does writing HTML, whether dynamic or not. Tools for understanding what's going on with the DOM and with dynamic HTML are slowly becoming available as well, which will help with this.

Quick reply (thanks for the well-formatted cited text!).

* Java didn't have the bad security rep until relatively recently. Java had nice-looking UX in the 90s (Netscape bought Netcode on this basis), much nicer than Web content. Didn't help.

* Web != Desktop. Large desktop apps are the wrong paradigm on the web. You won't see a Web-based Mathematica rewritten by hand in HTML/JS/etc. You will see Emscripten-compiled 3DS Max (see my blog on OTOY for more). The reasons behind these outcomes should be clear. They have little to do with JS lacking Java's big-OO features.

* Large mutable-state collection libraries are an anti-pattern. Functional structures, when hashes and arrays do not suffice (and even there), are the future, for scaling and parallel hardware wins.

* Conway's Law still applies. Too often, bloated OO code is an artifact of the organization(s) that produced it. This applies even to open source (Mozilla's Gecko C++ code; we fight it all the time, including via JS). It definitely applies to Google (e.g., gmail, Dart at launch). Perhaps there's no other way to create such code, and we need such programs as constituted. I question both assumptions.

* Glad you brought up refactoring. It is doable in JS IDEs with modern, aggressive static analysis. See not only TypeScript but also Marijn Haverbeke's Tern and work by Ben Livshits, et al., at MSR. But automated refactoring is not as much in demand among Web developers I know, who do it by hand and who in general avoid the big-OO "Kingdom of Nouns" approach that motivates auto-refactoring.

In sum, if the web ever becomes big-OO as Java and .NET fans might like, I fear it will die the same death those platforms have on the client side. Another example: AS3 in Flash, also moribund. These systems (even ignoring single-vendor conflicts) were too static.

The Web is not the desktop. Client JS-based code can be fatter or thinner as needed, but it is not as constrained as in static languages and their runtimes. Distribution, mobility, full-stack/end-to-end (Node.js) options, offline operation, multi-party and after-the-fact add-on and mash-up architectures, social and commercial benefits of the Web (not just of the Internet) -- all these change the game from the old desktop paradigm.

JS has co-evolved with the Web, while the big-OO systems have not. This might still end up in a bad place, but so far I don't see it. JS can be evolved far more easily than it can be replaced.

/be

Indeed. See also JSON.

ES6 brings Map, Set, WeakMap, and WeakSet. First three are already prototyped in Firefox and (under a flag) Chrome.

/be

Not looking to argue, just add some value: you say "too much time until it happens" and I've heard that before, many times -- most recently re: Dart (see that Channel 9 Lars&Anders interview).

Funny thing, it has been years since Dart started, ditto PNaCl. Who says JS is the slow path? I suspect it will get there faster (for tangible definitions of "there", e.g., a Rust2JS compiler for you) with well-focused work.

/be