
WebAssembly becomes a W3C Recommendation - galaxyLogic
https://www.w3.org/2019/12/pressrelease-wasm-rec.html.en
======
c-smile
Some retrospective ...

Ten years ago browsers were capable to do pretty much the same but with Java
on board that they all had at those times.

WebAssembly is conceptually close to JavaVM (JITed bytecodes) but due to its
architecture Java allowed as a) reflection (JS to Java calls) as b) exposure
of DOM model into Java execution space - DOM API even now is defined in terms
of Java interfaces by the way.

WebAssembly is a step in right direction but the evolution looks as Waltz -
two steps forward two steps back with the twist.

Now we are able to run ray tracers compiled to WA on browser side but we've
lost an option to apply the results to DOM elements directly.

To say in CSS:

    
    
         my-component {
            behavior: my-native-event-handler url(controllers/my-controller.class); 
            flow: my-native-layout-manager;        
         }

~~~
nine_k
JVM is seriously more complex and heavier-weight. It does too much, and is
shaped by Java the language too much (no functions, only objects!). It brings
in mandatory GC. It's built around shared mutable data.

WA is much smaller, assumes way less, is isolated from DOM and JS code way
better, communicates with them via message-passing. It has a smaller attack
surface, and less room to screw up in the implementation.

Yes, I think not having WA married to DOM is a good idea from many angles. One
of them is security, of course. Another is wider applicability: a WA VM could
be useful outside the browser, and it already is.

------
kllrnohj
Does anyone have any good success stories with WebAssembly in the actual
context of using it on the web? That list of testimonials doesn't seem very
inspiring as to whether or not the standard has seen actual production usage
to justify being a recommended standard...

~~~
pteredactyl
Good questions. WASM at this point seems more a locus of JS hate than anything
practical. To create something cool, novel, and useful should be the goal, not
avoid or use a certain language.

~~~
steveklabnik
There's a pretty stark difference between those working in and with WASM, and
people commenting on the sidelines. Almost everyone involved with WASM itself
sees it as complimentary, and explicitly is not trying to "kill javascript."
Random commenters on the internet do say this a lot though.

~~~
pteredactyl
Cool. Thanks

------
Boulth
Is this the same case as with HTML5 that W3C takes what WHATWG creates, stamps
their "approval" and then it's the W3C that "brings new language to the Web"?

Could someone in the know shed some light in this matter?

~~~
dmitriid
It looks like w3c is just late with the announcement. From
[https://webassembly.org](https://webassembly.org):

\--- quote ---

Developer reference documentation for Wasm can be found on MDN's WebAssembly
pages. The open standards for WebAssembly are developed in a W3C Community
Group (that includes representatives from all major browsers) as well as a W3C
Working Group.

\--- end quote ---

~~~
nerdponx
Off-topic, but I wish Markdown had a proper "multi line" block quote syntax
like this. The current standard of ">" is open to too much interpretation
around paragraph breaks. Similar to how fenced code blocks with ``` are a
major improvement over prefixing the line with 4 spaces.

~~~
thaumasiotes
In Markdown you can generally produce a single block quote with paragraph
breaks by including quoted empty lines:

    
    
        > Paragraph 1
        >
        > Paragraph 2
    

Whereas you'd get two sequential quote blocks by using an unquoted empty line:

    
    
        > Quote 1
        
        > Quote 2

~~~
infogulch
That doesn't work here

> because if you have multiple lines not separated by an empty line, > > even
> with a "quoted" extra line, it's not formatted on hn as such, and everything
> collapses into a single line.

~~~
steveklabnik
Hacker News comments are not Markdown.

[https://news.ycombinator.com/formatdoc](https://news.ycombinator.com/formatdoc)

------
duxup
I wonder if people think work involving web assembly will coalesce around a
few languages over time?

~~~
diegoperini
LLVM kinda proved having a common target back-end doesn't kill language
diversity, it actually achieves the opposite.

~~~
adrianmonk
One could still ask the question, though.

The way that coding language and deployment/executable language have been tied
together (JS for both) has served as a force that pushed everyone toward that
single language.

Now that WebAssembly promises to remove that force, will it be a free-for-all,
or will other forces push toward standardization on a few languages? And if
so, what will those forces be?

~~~
int_19h
Likely the ones that are on the bandwagon early.

To be even more specific, in the early days now, the main allure of wasm is
performance. So the focus will be on languages and toolchains capable of
generating optimized native code. Out of those, look at which ones are easy
for the developer to set up (both in general, and for wasm) on all popular
developer OSes.

So, I'd say that Rust will probably be the biggest beneficiary.

~~~
snak
C#/.NET will be in that bandwagon. They have been pushing WebAssembly usage
with their Blazor framework.

------
fizixer
Is it safe to say, future frameworks/websites can choose to stick to
HTML/CSS/WA and completely bypass JS?

~~~
zamalek
It would be hard (maybe not impossible) to access the DOM in WA without a GC
making sure everything is sound, because the DOM and JS (meaning the GC) are
very coupled. Currently, JS is used as a mediator between the two - so you do
need some JS (but it could well be JS that you never have to write yourself).

I recall one of the spec authors saying in an HN thread that a GC would be
added eventually, back in the infancy of WA. I'm not sure if that's still on
the cards or if there have been any updates on the subject.

~~~
tenaciousDaniel
I'm a web dev and I don't know much about WASM. I've been wondering - will it
be possible to render _something_ to the screen without first going through
the DOM? Or is the DOM literally the only way to display content?

It's enticing to imagine being able to open a wasm file and seeing an
application on the page. Kinda like how you can just open an image or a video
in the browser, without rendering it via an html document.

~~~
calaphos
You can take a Canvas element and draw anything you like on it - even hardware
accelerated 3d using webGL. I think there are some projects trying to (re)
implement a 2d user interface, rendered onto canvas. However the issue id that
you will need to reimplement a lot of things the browser already does for you:
rendering text, scaling, zoom, input methods, highlighting text, accessibility
features, etc... Unless you use case is very different from normal browser
usage (e.g. 3d graphics) the advantages seem dubious to me.

~~~
tenaciousDaniel
Mostly I was just curious, although I could see one argument for it. HTML/DOM
was meant to display interactive documents, which is far smaller in scope than
what browsers are used for today.

A lot of the web today (web applications in particular) are therefore _hacks_
of HTML. I know that the standard has responded to these uses by incorporating
more application-level features, but IMO this has become burdensome and
bloated.

There are lots of issues coming from the fact that we're attempting to write
application-level code on top of a platform that has historically been
designed for documents.

You could argue for an alternative to html/DOM - some kind of rendering format
that is meant specifically for full-featured applications.

~~~
klodolph
> You could argue for an alternative to html/DOM - some kind of rendering
> format that is meant specifically for full-featured applications.

Well, there are three ways to do that. You can use a 2D canvas, you can use a
WebGL canvas, or you can use a bitmap canvas. This is roughly equivalent to
what you get when you’re programming a desktop application anyway. This is a
cornucopia of alternatives here! I’m having a hard time understanding what is
missing.

These “use the DOM” in the same sense that desktop applications use the window
manager. You’re just drawing into an element in some compositing system. This
is fine, there’s no real benefit to bypassing the DOM—like window managers,
you can bypass the compositor when possible and go through the compositor when
unavoidable. This is transparent to the application programmer.

~~~
drfuchs
What is missing is a way for one's wasm code to make WebGL or 2D canvas calls
(or even write directly into a bitmap canvas), without writing a bunch of
Javascript trampoline / thunk / whatever code. If I'm mistaken, a pointer to
some C / C++ / Rust code that compiles down to wasm that actually touches a
canvas that's being displayed in the browser would be most appreciated.

~~~
klodolph
I think this will happen eventually… but there’s a lot of work to be done
before it happens.

------
kemonocode
It's really uncanny how Gary Bernhardt predicted it all [0] a few years ago.

[0] [https://www.destroyallsoftware.com/talks/the-birth-and-
death...](https://www.destroyallsoftware.com/talks/the-birth-and-death-of-
javascript)

~~~
chubot
Repeating what I wrote here [1], Fabrice Bellard wrote JSLinux in 2011, which
is a CPU emulator written in JavaScript that runs the Linux kernel (using
typed arrays and relying on fast JITs).

That's just a way of saying that "the best way to predict the future is to
invent it" (and do so before people who were "predicting" it).

If you knew about asm.js and Google's (now abandoned) Nacl and PNacl, there's
nothing surprising about the development of wasm. It's been 10+ years in the
making.

And 20+ years ago Microsoft's browser had ActiveX plugins (which didn't use a
VM and were really unsafe and unportable). Making a portable, sandboxed
bytecode solves an obvious problem with that.

Also the JVM ran in the browser, etc.

[1]
[https://news.ycombinator.com/item?id=21618323](https://news.ycombinator.com/item?id=21618323)

~~~
dwohnitmok
I think that's underselling the talk. Apart from the very enjoyable
presentation, it makes valuable insights.

The talk isn't trying to sell itself as 100% original. It makes reference to
asm.js and a game demo that already existed at the time of the talk as well as
repl.it.

Despite that, I do think it makes a unique insight that even though JavaScript
is ubiquitous, it will NOT be the language that future languages compile to,
but rather a bytecode perhaps inspired by JavaScript that will be the language
of the future. Also, importantly this bytecode will _win_ ; that is most
languages will the ability to directly compile to or have a VM in this
bytecode.

Moreover this bytecode has the potential to entirely supplant native code and
can do so with equal or better performance.

At least to me, neither of those were obvious insights even though I knew of
these plugins and JSLinux.

First off, those plugins died. Silverlight, ActiveX, Java on the web, Flash,
all of these died out and were replaced by JavaScript before wasm really took
off. It might've looked like the end state would be a version of JavaScript
"winning."

Second, things like PNacl, Emscripten, etc. still seemed like curiosities (as
the talk refers to when showing Repl.it). It wasn't clear that they or the
ideas they championed would get widespread adoption.

These days it is looking more and more likely that wasm is going to become a
target for all sorts of different compilers. The fact that it's a major
compilation target of Rust, a language that's about as far away from what I
would've thought of as a language for the web as possible, is striking.

And though we're still a long ways away from running everything on
WebAssembly, it no longer seems as exotic an idea as it once did to me.

And because of that, as well as the fantastic presentation, I still return to
this talk every so often awed at how much closer we are to realizing Metal.

There's still a lot of room for the talk to go very wrong, but it's not as
far-fetched as when I first watched it.

EDIT: Put another way; the talk is interesting to me because it emphasizes the
birth and _death_ of JavaScript. It talks about a world where the same forces
that propelled JavaScript to towering heights of popularity ultimately cast it
aside and create a world not possible without JavaScript, but in which
JavaScript itself essentially no longer exists.

~~~
cbhl
> Moreover this bytecode has the potential to entirely supplant native code
> and can do so with equal or better performance.

I interpreted that part of the talk as hyperbole and sarcasm. It was saying
that programmers will be so far removed from how computers work that they'll
happily program against a model that has five layers of abstraction that
simply serve to provide the original interface of the bottom layer.

Bytecode, by its nature, has to be translated into native code -- the way for
it to be 'faster' than native code is to be native code. In software, you can
do this with static or JIT compilation. The hardware people do this by
changing their CPUs to make the things that people do in the bytecode faster.
(Apple introduced _new floating point CPU instructions_ in their iPhones just
to make JavaScript faster.)

~~~
mntmoss
There's also a lot of sticky points at the bottom of the stack that lead
towards native solutions, starting with memory management and basic I/O
functionality. Nobody wants to code directly against the hardware for very
long, so you end up with a driver, and then driver and resource management,
and then an operating system of some kind. Even on the early microcomputers it
was the case that you have a boot ROM of some sort and would code against that
for most tasks.

With WASM you have the same kind of thing but the added wrinkle of the
browser-based I/O being a different set of "basic abstractions" from what you
get in libc, and every solution that bridges the gap being a bit of a hack.
Being bytecode doesn't really change the fact that you still have to deal with
the resulting dependencies at some level.

------
LessDmesg
Now if only we get a good web-oriented Python with a WASM backend, we'll
finally be able to throw Javascript where it belongs: into the dustbin of
history.

~~~
janpot
Honest question, in what sense is python a so much better choice for web
development?

syntax? subjective, and it would also mean all C-likes belong in the dustbin.

performance? Why would python, as a language, be significantly more
performant? It's just as dynamic.

ecosystem? JS community is huge, JS package managers are huge (even though not
flawless, but nothing their python counterparts do better)

I mean I can surely imagine there's better alternatives for JS, as a language.
But python...?

~~~
LessDmesg
For one thing, not being broken. Python doesn't have ("1"+1) and similar
design flaws, Python doesn't need a new ECMAscript standard every year, Python
has figured out modules and classes much earlier, and frankly, Python is what
Javascript is only becoming after years of improvement. Really, I don't
understand why we and the browser maintainers have to put up with a broken,
insane language when there is a similar but much more mature and "done right"
one. And as far as ecosystem, Python can kick Javascript's ass if not in
quantity (though it's close) then in quality of its userbase for sure. And
Python has been used onе the backend much more than JS, so it makes much more
sense to unify the language and just use Python for the front-end.

~~~
strbean
I feel like almost every one of those points is highly debatable.

\- New ECMA standard every year VS. new PEPs every year

\- Modules and classes: cyclic dependency hell, obscure multi-import issues,
__init__.py ugliness, imperative class declaration. Python only figured these
things out much earlier to the extent that it has actually figured these
things out.

...

------
gdxhyrd
Good to hear it is making progress, but last time I looked, the docs were all
over the place and many were outdated...

~~~
todd3834
I expect standardization to help with that.

------
pteredactyl
Such hate for JavaScript. To say JS needs to lose for you to win says more
about you than it does JS. Just a thought. I see a world where there are many
winners and one where WASM and JS and whatever you want can fulfill their need
where needed.

~~~
weberc2
This seems like a straw man; I’ve seen relatively little JS hate in this
thread. Unless you’re considering WASM’s progress (or existence) to be an
attack on JS? I personally don’t see what is wrong with having other choices
for web development.

~~~
pteredactyl
Yea maybe I see this because I feel threatened in some way. Not desirable!

------
Endy
Well, I was already pretty much ignoring the W3C already since HTML5. Now I
can really let go, which will put me back to HTML 3.0 with no CSS nonsense.

------
BoumTAC
Why does the testimonial contains only Chinese company?

I think it's really great but it would be better to have company from all
around the world

~~~
zmzrr
Would I be reading this if it was only American companies?

~~~
efdee
America is not China.

~~~
zmzrr
Are you sure?

For instance, they are two countries, whose names end with the letter "A"...
dare I continue?

~~~
dang
Can you please cut out the lower/boring segment of trolling? (like this and
[https://news.ycombinator.com/item?id=21804133](https://news.ycombinator.com/item?id=21804133))

------
penetrarthur
B-B-B-B-Blazor.

------
somurzakov
i wonder what are the security implications. how many new vulnerabilities will
be uncovered, machines infected, and viruses implemented in wasm.

the concept of wasm doesn't really fly with zero-trust internet

~~~
weberc2
Can you elaborate? I would think the sandbox nature of wasm would be a better
fit than other models, and presumably no worse than JavaScript?

~~~
somurzakov
i am not convinced that wasm interpreter will be bug/vulnerability free. as it
was the case for every new piece of software there will be ton of
vulnerabilties in the VM itself that will be exploited

------
eb0la
Another nail in the Java coffin? I hope if doensn't refuse to die (again)

~~~
spullara
Don't you mean JavaScript? This will have 0 effect on Java at this point since
it isn't used in the browser anymore.

~~~
lmkg
WASM is angling to break out of the web and become a cross-platform runtime.
Its main competition for this space is Java.

~~~
somurzakov
some of the compute workload still needs to be on a backend because of
security concerns. if you offload too much stuff on a client-side, then any
hacker can mess with it and break your system.

for example you can get angular debugger extension for chrome and mess with
any online shop that uses this system to "adjust prices" for your cart during
checkout

~~~
woodrowbarlow
the backend could compile to wasm as well.

~~~
somurzakov
and what is the profit in compiling C/C++/Rust into wasm, instead of native
binary code?

~~~
yazaddaruvala
Better hosting/deploying/debugging/etc because WASM can be hot-loaded and
easily embeddable.

e.g. [https://www.cloudflare.com/products/cloudflare-
workers/](https://www.cloudflare.com/products/cloudflare-workers/)

------
jokoon
Not to complain about WASM because it's great, but it certainly needs more
compilers and toolchains, and it should be possible to make webgl calls
directly.

Toolchains like clang and g++ should be able to generate WASM directly, I
don't understand why you need so many things like bynaryen to make a WASM
file. Having tools is essential if you want a technology to progress towards
adoption.

EDIT: actually clang can now generate WASM. I'm not curious how feasible it
would be to package python with WASM

