Just like other components of the technology preview, I think it would be useful to have interested developers try it out and give feedback in the form of bug reports -- understanding that things are incomplete and going to change.
I'm sort of holding back at the moment until emscripten has everything integrated to build wasm binaries, even if it is not the final LLVM backend. But I can't wait to flip the switch on the wasm builds :)
BTW We're happy that we got some of your demos into the build-suite, but unfortunately we can't run them anymore. The binaries there are still version 0xA and the .wast files have some errors that prevent translating them to 0xB with the sexpr-wasm tool.
Isn't the purpose of JS that you would easily be able to view the source, that it's actually source code running, and not binary!?
As for view source: on one hand JS is already mostly minimized, on the other hand, WebAssembly has somewhat human-readable lisp-like ASCII representation which can be generated from the byte code. But I think view-source hasn't been useful since many years.
Binary formats are nothing new to the web, it's used them for images and such for a long time now. In fact, the one raster plaintext image format (XBM) is no longer supported.
SVG's are quite popular!
Who said that was the purpose of JS?
Same reason why you don't let invisible aliens on-board your spaceship!
Programs become tremendously more secure when it's possible to read the source code and actually compile it yourself.
This is just barely technically correct, at best.
Chrome launched its first pre-release version on Sep 8 2008 , while WebKit's SFX JIT showed up in pre-release versions of WebKit just 10 days later  (or less, 10 days is when the blogpost came out).
Also, Firefox's TraceMonkey JIT landed on trunk Aug 8 2008  which is before Chrome's pre-release (however, it was not yet turned on by default in nightlies at that time).
V8 is a wonderful VM and Google should be proud of it, but the PR line of "V8 was the first really fast JS VM" is debatable. Something like "one of the first really fast JS VMs" would be more honest.
To a lesser degree we are starting to see a similar post of article starting with Opera, Safari, and IE working on reducing their energy usage while oddly it is Chrome that is silent. Just like before a product with a significantly superior feature has caused me to switched. But this time it was back to Safari from Chrome. But the Chrome team is not asleep at the wheel like the Microsoft was and I am expecting/hoping within a year or two there to be a post with dramatic energy savings made by the Chrome team.
I personally don't think chrome has anything "up their sleeve". From the looks of what they have been focusing on recently, they really dug themselves a hole with their technical debt in the V8 engine.
It's too complicated, and it looks like their upgrade path has it getting worse before it gets better. They aren't planning on switching to "Ignition -> Turbofan" until mid-late 2017 (which is expected to reduce memory usage, but also will reduce speed slightly at first), so that means that until then, it will be "Fullcodegen -> crankshaft or turbofan and sometimes ignition only in some codepaths". It's only getting more complicated as they try to write out their crankshaft compiler. IIRC ignition can't interface with cranshaft, while it can with turbofan, but turbofan is significantly slower than cranshaft for many things right now, and fullcodegen is WAY to slow in parsing (and re-parsing, and re-re-parsing) code to compete with Chakra which just starts SOO much faster because of that.
I hope they prove me wrong, but my hopes aren't high at this time.
But umm... they don't really do that, right?
> This is just barely technically correct, at best.
seriously, that's what you got out of these slides?