[BrendanEich]

Enormous investment? See my estimate (generous) above.

Contrast with the Dart (nee Dash) investment, where a team of at least 60 now labors on a language+VM that cannot cross the chasm to other browsers in any foreseeable future where there are multiple browsers with disjoint source that have significant market share.

Evolution doesn't care about aesthetics (my pelican slide from JSConf.{us,eu}). It doesn't care about wealth-effect follies that can't be standardized among developers without a compile-to-JS plan that undermines the native-VM plan. It does not care about roads-not-taken in the past, so long as the road from here is clear.

Bet on evolution.

/be

[cromwellian]

Bet on punctuated equilibrium. Both PNaCL and asm.js are could follies if you consider mobile games. There is no incentive for someone developing games for consoles or phones to use either of those technologies.

[BrendanEich]

Game devs code to metal, use C++ and OpenGL. This is why Jobs went from web apps to allowing native in iPhone 1 era.

Both PNaCl and Emscripten (or Mandreel -- the relevant comparison, not asm.js which is a different category) work on such source. This is how Firefox OS runs games (Disney Where's My Water, many others). Cross-compilation works.

(Punctuated equilibrium is a bio-crock.)

[cromwellian]

Coding to metal isn't just about source language, it's about optimizing system level performance. Top tier game devs use vTune, GPU profilers, system level analyzers, to maximize overall system performance for a given workload. Developers at studios like Naughty Dog, Bungie, DICE, Infinity Ward, et al don't just delegate to the C compiler and call it a day.

Leaving aside casual games, which are mostly not performance sensitive, top tier game development is very high risk and expensive. One reason why developers like consoles and the iPhone/iPad is absolute predictability when it comes to target platform. Even branching over into the Desktop PC, game tuning requires a ton of testing on a huge matrix of platforms, chipsets, drivers, and other configurations, all of which is a big expense, as well as a big support cost.

What is the motivation for say, Infinity Ward to port Call of Duty to asm.js or PNaCL? Most of the people who would actually buy it will do so on a console, or through something like Steam. You'd be asking them to add an immature and unproven technology into the mix that sacrifices multithreading, or drops a big chunk of performance on the floor, and in return, add back millions of frustrated web users who will be making customer support claims.

I love the web, I have the tons of "native" apps on mobile that don't really deserve to be native apps at all and would work equally well as a URL to a web site that doesn't force an install. But --

Games are not webby. They are not the web, and treating the browser like a C virtual machine that throws away pretty much most of the browser's machinery in favor of just OpenGL bindings is not what the browser was designed to do, and the fact that it does it at all is amazing, but it is not helping the web.

I think both Chrome and Firefox would do the world a much bigger favor concentrating on making the other parts of the browser rendering engine a lot faster. JS performance is not the primary reason that Web apps feel janky compared to native ones, the entire development model for web development is a minefield full of performance hazards.

For years, the JVM had huge performance advantages on JS. It had native code interfaces, it had off-heap non-GCed memory allocation capability, it had high performance, and yet, Minecraft is pretty much the only success story. Now why is that? And why NaCL, which has a rich father (Google) behind it, and the world's largest browser marketshare of hundreds of millions, can't convince many developers to port to it. You think Emscripten ports are easier than NaCL? The best explanation is that the return on investment in making a game that is shoe horned into the browser is not worth it.

If given the option to buy a game on Steam, or buy it via Chrome Web Store or Firefox store, I would buy the Steam version. I bet the majority of people reading this would do the same.

I see that casual, simple mobile games might be suitable for this, but that's a problem for FirefoxOS and ChromeOS to solve. Most game devs will continue to target iOS and Android until FireOS gets a non-trivial marketshare. Crossing that chasm is going to be hard.

To make a TL;DR short, I am frustrated that native is taking over in the non-games space, and the efforts by both Google and Mozilla to get at the real heart of the matter, of making jank-free, buttery smooth, mobile apps easy to develop for web developers is moving far slower than it needs to be.

All this games stuff is a huge distraction.

[BrendanEich]

> concentrating on making the other parts of the browser rendering engine a lot faster.

The fallacy of the excluded middle, yawn.

We're working on perf all over, so are Chrome folks. But unlike Google, we're not building three VMs requiring their own toolchains. We can't afford to, nor can others building browser engines, and developers are not buying it from what I can tell.

> All this games stuff is a huge distraction.

True in deep ways (have to keep my kids away from it or their brains turn to mush).

We agree that hand-coded JS needs pause-free GC and JITting. Pause-free GC is doable, I've advocated it. Top engines' GCs are still optimized for throughput.

Pause-free JITting is harder, and less theoretically tractable. Whack-a-mole is unwinnable, AOT is beating JIT here.

We follow our nose on this one. If AOT == JIT in some utopian future, great. Otherwise, misspeculations and phase changes happen, and using background threads on other cores to recompile can help, but without precog JITting there will be jank and startup pain.

/be

[backspaces]

Well, I agree on the performance (speed) side, VM out, subset In. but feel abandoned on the memory footprint side.

Objects are just huge! Asm.js promises something more like structs, I think. Now making THAT available to JS programmers would be a great help.

I really don't want to go back to C just for faster JS. Lets use the knowledge of the last year to put some of the asm.js goodness into JS hands. LLJS is likely not the answer from a recent jlongster post. Rather than a new language, simply parts of asm.js would be better received by the JS community.

   -- Owen

[BrendanEich]

Typed objects (ES7) offer struct-like packing and heap repr efficiency, independent of asm.js:

http://wiki.ecmascript.org/doku.php?id=harmony:typed_objects

[cromwellian]

* The fallacy of the excluded middle, yawn.

You're an executive of Mozilla. I think you can join threads without being condescending.

As for whether developers are buying PNaCL, asm.js, Dart, or even Javascript, as a major platform for games development remains to be seen. The majority of the game-dev resources are being spent on native, and those that are developing for mobile, are doing so for native. If Javascript is lucky, it might one day be as popular as Flash for doing games, it hasn't even reached 1/100th of the success of the FlashVM in that regard.

There is a lot of time spent on HN arguing over JS vs Dart vs NaCL, meanwhile, the consumer experience is being taken over by native, and it is not because of JIT performance. Failure to see why developers choose native, and why consumers choose it, I think is a tragic tunnel vision.

[BrendanEich]

More executive charm school needed, clearly.

You wrote a tl;dr piece with a whopper in the middle asserting that we should all go work on other perf than JS perf that is attracting game publishers, big ones -- while at the same time, Google is pushing *NaCl (both with and without the P) / PPAPI as the way to get native code including those very games ported to Chrome and Chrome OS.

I think that's at least the false dilemma fallacy I identified, if not something more like a conflict of interest, and I'm gonna say so. Bluntly.

I frankly don't care whether game devs ever hand-code in JS or Dart. They'll continue to use C++ for good reasons (until the Rust-pocalypse). GC is never free, nor is JIT. C++ and other AOT languages endure.

Really, it's not for us to over-sell JS and require rewrites.

And again, Google apparently gets this market need because they have been selling NaCl against it (with limited success). So it's not out of bounds for JS suddenly, in spite of your tl;dr protests.

/be

[Touche]

> We're working on perf all over, so are Chrome folks.

So where are the blog posts about buttery smooth touch interactions on Firefox OS? Where are the blog posts about saving/loading large arraybuffers into indexeddb without it crashing the browser / taking a week and a half on mobile? Because there are asm.js blog posts every other day. I'd love to read about how regular browser stuff is getting leaps and bounds better, but I don't believe that it is.

[BrendanEich]

You are complaining about bugs to fix, in particular typed arrays and indexeddb (I hate typing that). We did fix XHR vs. typed array bug here:

https://bugzilla.mozilla.org/show_bug.cgi?id=866431

but you have a point about indexxxeedddbbb :-D.

Smooth touch interactions are supported better by Firefox OS with touch events, do you have a particular bug in mind?

Fixing bugs and blogging about them would take all blogging energy for little gain. We fix bugs without enough positive noise, but I think the main thing is to fix bugs.

OTOH, Emscripten/asm.js work (which, silly exaggeration, is not blogged about every other day) is not a bug fix. It's a bigger deal, and it needs explication (especially because some FUD about how it entailed new VMs still lingers in the twittersphere).

Also, we're fastest on Emscripten output due to AOT. That is news, news! I say ;-).