
Web Assembly - Siecje
https://github.com/WebAssembly/design/blob/master/README.md
======
tantalor
Here are some examples of the text/debug format,

1\. factorial in S-expressions:
[https://github.com/WebAssembly/spec/blob/master/ml-
proto/tes...](https://github.com/WebAssembly/spec/blob/master/ml-
proto/test/fac.wast)

2\. ray tracing in a C style:
[https://github.com/ncbray/wassembler/blob/master/demos/raytr...](https://github.com/ncbray/wassembler/blob/master/demos/raytrace.wasm)

------
purplerabbit
Been checking in on this since the initial hubbub a few months ago... It would
be great if it started to swing into high gear.

I'm still in love with the idea of a language-agnostic, web-centric
compilation target, but I think we should all emotionally prepare for 10+
years before it's feasible to use in production, let alone well-integrated
with our favorite languages.

~~~
s3th
Things are definitely picking up speed!

There are already a bunch of awesome community implementations of the MVP
WebAssembly spec [0][1][2]. Meanwhile, the V8 [3], SpiderMonkey [4], Chakra
[5], and JSC [6] teams have all started work on implementing wasm in actual
browser engines.

We've still got a long ways to go, but it's much nearer than 10+ years!

[0]: [https://github.com/WebAssembly/wasm-jit-
prototype](https://github.com/WebAssembly/wasm-jit-prototype) [1]:
[https://github.com/WebAssembly/wasmint](https://github.com/WebAssembly/wasmint)
[2]: [https://github.com/WebAssembly/wasm-aot-
prototype](https://github.com/WebAssembly/wasm-aot-prototype) [3]:
[https://github.com/WebAssembly/v8-native-
prototype](https://github.com/WebAssembly/v8-native-prototype) [4]:
[http://hg.mozilla.org/mozilla-
central/file/ca086f9ef8bc/js/s...](http://hg.mozilla.org/mozilla-
central/file/ca086f9ef8bc/js/src/asmjs/AsmJSValidate.cpp#l2510) [5]:
[http://blogs.msdn.com/b/mikeholman/archive/2015/06/17/workin...](http://blogs.msdn.com/b/mikeholman/archive/2015/06/17/working-
on-the-future-of-compile-to-web-applications.aspx) [6]:
[https://bugs.webkit.org/show_bug.cgi?id=146064](https://bugs.webkit.org/show_bug.cgi?id=146064)

(Disclaimer: I'm a Google Chrome PM contributing to the WebAssembly project)

~~~
ilaksh
What about Servo?

~~~
jmhain
Servo uses SpiderMonkey.

------
dccoolgai
With the adoption of wasm, won't the web become inherently less hackable?
Right now i can pretty-print some minified js and at least have a basic idea
of what APIs are getting called. Difficult to see how one could do the same
with wasm. Not saying wasm is a bad idea (i think it's good), I'm just
concerned about what this will look like in terms of keeping the nuts and
bolts of the web semi-readable.

~~~
s3th
It's definitely a goal to make sure that wasm is as readable as possible. The
binary format will be able to be "pretty-printed" into a textual format [0].
We haven't finalized the exact format yet, but it will be much more readable
than current asm.js javascript [1].

[0]:
[https://github.com/WebAssembly/design/blob/master/TextFormat...](https://github.com/WebAssembly/design/blob/master/TextFormat.md)
[1]:
[https://twitter.com/BrendanEich/status/643828456631857152](https://twitter.com/BrendanEich/status/643828456631857152)

(Disclaimer: I'm a Google Chrome PM contributing to the WebAssembly project)

~~~
pdkl95
The existence of a "readable" parse tree doesn't provide the same level of
"hackability" or openness as a DOM. You're comparing it to asm.js, but that
isn't particularly relevant as asm.js that widely used (emscripten is cool,
but the lack of readability you mentioned is a barrier to wider adoption in
the general case).

WebAssembly will impact a lot more than just the pages currently using asm.js,
and I fear it will introduce the Halting Problem in to a lot more areas. The
concern isn't asm.js - it's frameworks like angular (no-content-without-js
websites are already a problem). The availability of a parse tree doesn't help
if I have to run it to access the structure that is current available in the
DOM. With the current drama over adblopcking, I expect advertisers will jump
at a technology that lets them treat clients as something they control.
(compile an obfuscated version of freetype into small WebAssembly download
will be be the key features).

~~~
reissbaker
This is uneducated FUD.

WASM doesn't "introduce the Halting Problem" — I'm not sure how you could even
think that was possible. JS is already a Turing-complete language, as are C
and C++ (the most common compile-to-asm.js-languages), and the Halting Problem
already affects them as much as it affects all Turing-complete languages; the
way web browsers "solve" the Halting Problem is that if a script takes too
long to run, it's killed. There's no reason that would be any different with a
faster-to-parse and smaller-in-bytesize compilation target, which is all that
WASM is.

If "the concern isn't asm.js — it's frameworks like angular," then — what?
Angular already exists, and is written in regular JS. No new compilation
target needed.

And in regards to ad-blocking: what? Ad-blocking works by not running (or
loading) content from specific, known advertising networks. That would work
regardless of whether the content was written in WASM or asm.js or regular JS
or anything else. Just block the network requests and you're done.

~~~
userbinator
_Just block the network requests and you 're done._

Not if the ad scripts are mixed in with the content-rendering scripts, in
which case you'll need to do some on-the-fly modifying of scripts. Host-level
blocking still works for ads served from exclusive servers, but a lot of them
are starting to realise that it's so easy to block and are resorting to more
subtle methods.

That said, a new type of adblocker based on pattern-matching against a JS
syntax tree would be pretty useful.

~~~
iamsohungry
> Not if the ad scripts are mixed in with the content-rendering scripts, in
> which case you'll need to do some on-the-fly modifying of scripts.

This is true, but it's not problem unique to WASM. In fact, your proposed
pattern matching AdBlocker seems like it would be much easier to produce
targeting WASM.

It's also worth nothing what an edge case this is. Some sites might do this,
but large enough sites to be worth doing this will likely be large enough to
inspire site-specific workarounds. Smaller sites will be unlikely to couple
their ads to their rendering so tightly.

------
cauterize
As someone who works in the web space, albeit on the back-end, can anyone
explain why a project like this is desired over a better language / run-time?

~~~
richdougherty
wasm and asm.js are perfect examples of incremental improvements rather than
building something from scratch. The benefit of this is that incremental
improvements can be built slowly on top of existing deployed JavaScript
engines, whereas writing something from scratch has a serious bootstrapping
problem.

The wasm/asm.js story goes like this so far:

1\. emscripten, a JavaScript backend for LLVM, demonstrates that you can
"compile" C/C++ code into JavaScript.

2\. Some vendors start writing specific optimisations for emscripten-style
JavaScript code.

3\. This is formalised into a subset of JavaScript called asm.js.

4\. More browser vendors get onboard with asm.js optimisations.

5\. wasm is proposed. Initially it is a compact binary format that is
equivalent to asm.js and that can be trivially translated into asm.js at
runtime using a polyfill.

The future might look like this:

6\. Browsers adopt wasm natively, so the asm.js shim can be dropped, giving
more performance benefits.

7\. Further enhancements to wasm follow and wasm perhaps begins to diverge
from its underlying JavaScript runtime.

8\. ???

~~~
cpeterso
How long until someone implements WebAssembly instructions in hardware? ARM's
"Jazelle" supported some JVM instructions in hardware.

~~~
h1282227
Hardware support only makes sense if the optimisations are already included in
the compiler output. The JVM does all the optimisations which makes Java
Bytecode not suitable for that purpose.

------
TranquilMarmot
I imagine a future where instead of the DOM, everything is driven by WebGL
with logic being in Web Assembly. So, basically... a standardized game engine,
running across all platforms.

Almost feels like a throwback to the days of entirely flash-based
websites......

~~~
nathancahill
It feels exactly like a throwback to the days of entirely flash-based
websites. Not entirely sure how I feel about that.

~~~
ino
Big regression in accessibility, copy/paste, automatic translation, everything
that makes the web uniquely great.

~~~
jacobolus
The #1 thing that makes the web uniquely great is that all you need to do to
access a program is to paste a short string into a box, and your browser takes
care of the rest. Anyone can slap a website onto a server they control, and
anyone in the world can then access it.

Outside that one advantage, web applications (not talking about simple
documents here) are worse in almost every way than native applications. (It’s
not without reason that Photoshop, ProTools, Maya, Excel, Final Cut,
SolidWorks, ArcGIS, Sibelius, Mathematica, Visual Studio, and thousands of
other serious tools don’t have credible web alternatives.)

They’re slower. They aren’t persistent. They change all the time with no
ability for the user to prevent it, sometimes spontaneously breaking when the
developer stops supporting the user’s browser or goes out of business. They
make it hard for users to load/save local data, and instead they store
personal data on a faraway server. Accidentally pressing the back button can
destroy hours of user work. They usually have terrible accessibility. They
don’t interoperate with other applications on the system. They flagrantly
violate UI design conventions on every platform. They can’t access most local
hardware devices. They have an extremely limited user input device model.
Their UI layout tools are limited, inflexible, and incredibly hard to work
with. They throw out decades of implementation effort on various standard
solutions to problems and force complete reimplementation from scratch. They
are difficult or impossible to build proper cryptographic primitives on top
of.

In short, web applications are inherently second-class citizens on every
platform.

BUT! Web applications are also amazing. Dropping the barrier to entry – URLs
and HTTP and fairly reliable code sandboxing – makes all the difference, and
makes the web an extremely attractive platform despite its many flaws.

~~~
pdkl95
> web applications are inherently second-class citizens on every platform.

Yes. By design. If a webpage can impersonate a local app, you have a serious
security problem.

> They make it hard for users to load/save local data

There are good reasons for a lot of that, from denial-of-service protections,
limiting stealth cookies, etc.

> They don’t interoperate with other applications on the system.

That's a feature.

> They flagrantly violate UI design conventions on every platform.

The user agent can render the page however it wants. This is a feature.

> They can’t access most local hardware devices.

Are you _trying_ to introduce even more security problems?

> They are difficult or impossible to build proper cryptographic primitives on
> top of.

That's not the place you should be implementing crypo.

> Accidentally pressing the back button can destroy hours of user work.

Ok, that one would be nicer to fix, but that's a problem for the browser, and
shouldn't impact the page at all.

\--

If you want to develop software that uses more than the web can provide, you
should choose a platform that actually provides those features. There is a
trade-off, of course, but making that kind of decision is a an important part
of software engineering.

While many people have been ignoring some or all of the security aspects of
programming, it is important to remember that anything connected (even
indirectly) to a network is under attack, so security must be considered
_first_.

~~~
simula67
I think what your parent comment was saying was that : 'even though web is a
great solution to many problems that can be solved with software, it has its
limitations'. Clearly the problems s/he mentioned are a source of pain for
some users, and many of them do not exist in the native application platform.
Even if those trade-offs look unreasonable to you, it may not look so to many
others. If we have more data to support the statement that somehow the web is
always superior to native, then this discussion can move forward. Without it
we are more likely going around in circles.

------
z3t4
Why can't virtualization and containing of the app be done on a OS level? Why
do we need the browser to run "web" apps?

~~~
nikbackm
Which OS?

