[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

[cromwellian]

It's incorrect to view Google as a single entity. There's a large number of engineers each with their own ideas of what should be done, and Google gives a lot of resources for people to explore things. To say that Google is pushing something can only really be understood in context of how much company level priority and head count is put on it vs individual loudness and passion of the teams doing their things.

Some very small teams at Google who work on stuff as 20% side projects are so vocal and active with the external community that they give the impression of huge focus and investment. Others, while mostly quiet, give the impression of almost no investment while large groups of people churn away.

My interests are aligned with preserving and maintaining what is good about the Web: federation, transparency, frictionlessness, indexability, composeablity, linkability, etc. I am more focused about avoiding this future (http://idontwantyourfuckingapp.tumblr.com/). To me the trend towards appification and install of everything is something we should not be chasing. Ideally, web apps should trend towards less code execution, not more.

The first two decades of the Web were mostly about content. Now we're turning it into an entertainment device and a gaming platform, it's this generation's television. Everyone is chasing off into the bandwagon/rathole of trying to be more like iOS apps, because of the perception that it's how you make money. That gravy train will eventually saturate and become a dead end. It's short term thinking. Skate towards where the puck will be or should be, not chasing Apple down the field trying to catch their lead skater.

Long term I want the Web to "win", but not by changing into a platform of binary opaque blobs like native.

[BrendanEich]

Great comment -- with you all the way on this one.

I use "they" for Google on purpose, it's a fleet of ships for sure. But I also confer with my VP Engineering, Chrome counterpart regularly and know (mostly) what projects are official and intentional. :-)

/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 ;-).