[FoRK] WebAssembly | Luke Wagner's Blog

Stephen D. Williams sdw at lig.net
Sun Jun 21 00:33:38 PDT 2015

Yea, we were talking about that a couple days go.  Awesome.  I'm getting deep into Polymer, so WebComponents were already on my 
mind.  From that thread:

Kind of cool.  Kind of obvious.  They say they're not going to add / change much or anything, but then they hint about fixing some 
other things.  Could be good.  Mostly, this is just to avoid parsing and not much else different.

Because of the binary XML work, I probably have a lot of insight into the problems here...  If I weren't so busy.  Wonder what it 
would take to get an invite to the group.

The comments about supporting languages other than C/C++ are weird.  What are they doing that is language specific?  I think 
Emscripten already compiles various languages with an LLVM backend to Javascript.  But perhaps not, or they have some other small 
glue to update.

For instance:
> js.js <https://github.com/jterrace/js.js> A JavaScript JavaScript interpreter. Instead of trying to create an interpreter from 
> scratch, SpiderMonkey is compiled into LLVM and then emscripten translates the output into JavaScript.

The more cool thing that's happening is that Swagger is going everywhere.  Apigee has been big, already public.  (A while back, I 
think I met someone who works there.)  I saw a reference to Google doing something with it, but couldn't find that yet. There's a 
mapping from Google Discovery to Swagger.  Microsoft is including Swagger in the next version of Visual Studio.  Etc.

I should have pointed out several big things that were mentioned here or near:

1) Webassemblies will allow asm.js based modules, i.e. C++ etc., to be used easily in web pages as WebComponents, which is a new 
system that allows very easy and powerful combination of web code from many sources, all hooked together with easy Javascript snippets.

2) Adding threads, full SIMD, zero-cost exception handling for C++

3) We've moved to a post-versioned world, at least with respect to the browser itself.  The idea is that you specify that your 
framework, libraries, and other dependencies work on "Evergreen" browsers and other technologies.  This is partially made to work by 
A) everyone upgrading automatically to the newest version of each browser and B) polyfills to fill in gaps when a particular browser 
hasn't caught up with the current consensus target features.  We now have enough building blocks in most cases that new features can 
be implemented somewhat in old features until they actually are native.  In some cases, those features might never actually be 
implemented, especially if the Javascript compile step can implement them.

> In addition, we revised our internal engineering processes to prioritize real-world interoperability issues uncovered by our data 
> analysis. With these processes in place, we set about fixing over 3000 interoperability bugs and adding over 40 new Web standards 
> <https://status.modern.ie/?iestatuses=indevelopment,iedev> (to date) to make sure we deliver on our goals.
> We don’t see this interoperability effort having an end date – we’ll be continuously checking the data and rolling out 
> improvements to the new rendering engine. For users that upgrade to Windows 10, the engine will be evergreen, meaning that it will 
> be kept current with Windows 10 as a service 
> <http://blogs.windows.com/bloggingwindows/2015/01/21/the-next-generation-of-windows-windows-10/>.

Now if we could just get WebGL 2, 3..., WebCL, WebUSB, SIMD.js, etc. in place, we'd be getting somewhere.


On 6/20/15 10:18 PM, Dr. Ernie Prabhakar wrote:
> Drool. If this had been around a year ago, I would’ve built my startup around this...
>> https://blog.mozilla.org/luke/2015/06/17/webassembly/ <https://blog.mozilla.org/luke/2015/06/17/webassembly/>
>> WebAssembly
>> I’m happy to report that we at Mozilla have started working with Chromium <https://twitter.com/jfbastien/status/611201861245399041>, Edge <http://blogs.msdn.com/b/mikeholman/archive/2015/06/17/working-on-the-future-of-compile-to-web-applications.aspx> and WebKit <https://bugs.webkit.org/show_bug.cgi?id=146064> engineers on creating a new standard, WebAssembly, that defines a portable, size- and load-time-efficient format and execution model specifically designed to serve as a compilation target for the Web. As reflected in the high-level goals <https://github.com/WebAssembly/design/blob/master/HighLevelGoals.md>, a central requirement for WebAssembly is that it integrate well with the rest of the Web platform and that the initial version <https://github.com/WebAssembly/design/blob/master/MVP.md> run efficiently on current browsers using a client-side polyfill <https://remysharp.com/2010/10/08/what-is-a-polyfill/>. As demonstrated <https://github.com/WebAssembly/design/blob/master/FAQ.md#can-the-polyfill-really-be-efficient>, the polyfill can leverage asm.js to get great performance. For existing Emscripten/asm.js users, targeting WebAssembly will be as easy as flipping a flag <https://github.com/WebAssembly/design/blob/master/FAQ.md#whats-the-story-for-emscripten-users>. Thus, it is natural to view WebAssembly as the next evolutionary step of asm.js (a step many have requested and anticipated).
>> We’re pretty early into the overall process—there is no draft spec or even final formal standards body chosen, just a W3C Community Group <https://www.w3.org/community/webassembly/>, some initial prototyping and early cross-browser consensus on the high-level design documents <http://github.com/webassembly/design/>. Going forward, there will be a lot more iteration and experimentation under the WebAssembly <http://github.com/webassembly> GitHub organization. For questions, check out the still-emerging FAQ <https://github.com/WebAssembly/design/blob/master/FAQ.md>. Brendan Eich also has a vibrant blog post <https://brendaneich.com/2015/06/from-asm-js-to-webassembly> with more context, history and JS perspective.

More information about the FoRK mailing list