
W3C recommends WebAssembly - lottamus
https://www.w3.org/blog/news/archives/8123
======
6gvONxR4sf7o
Whatever you think about javascript, I love the historic separation between
content and interactivity. I dislike that so many static pages won't load
without JS and that we're moving further in that direction. I hope the
evolution towards "browser as OS" doesn't hurt the content vs interactivity
separation. Could we ever lose the HTML centered model?

That could mean we lose hackability and the ability to write extensions or
even scrape the web without a BigCo webcrawler's level of infra investment. Is
everything going to turn into an opaque single page app? Technically,
webassembly is really cool, but I worry about where the browser is headed.

~~~
simias
If you look at the history of the web it's clear that the tendency has always
been towards "shinier things". This "historic separation" was the result of
technical limitations, see how popular Flash used to be for instance.

HTML and CSS standards were always at least 10 years too late. If you wanted
something that looked modern you've always had to use browser-specific
extensions, plugins or, at best, "beta" features.

Seriously, I know that nowadays many devs have started straight with web
technologies and don't have a lot of experience besides that but if that's
your case do yourself a favor and give a quick look at a proper UI toolkit
like Qt. Would it blow your mind if I told you that you can create a complex
treeview without having to use third-party libraries or reinventing half the
wheel yourself? Crazy, I know.

If anything this "historic separation" and people who still hold onto it might
be one of the reasons the modern web is such a messy patchwork of
technologies, if web engineers had accepted that an open source Flash was
actually the endgame and not a problem we might have saved us some time and
some trouble.

To be clear I'm not saying that it's a bad idea per-se, I personally believe
that the web is way too complicated as it is, I just feel like it's similar to
arguing that "literally" shouldn't be used to mean "extremely" in modern
English. Sure, I get your point, but I don't think it's a battle you can win.

~~~
danShumway
> Would it blow your mind if I told you that you can create a complex treeview
> without having to use third-party libraries

No, not any more than C#'s giant standard library blows my mind.

Keeping the web small is a strategic decision -- it may look like chaos, but
it's really just that we realized that embracing 3rd-party libraries is a
better architectural decision than polluting the core spec with features that
will be outdated in a few years.

QT doesn't have these problems because QT doesn't have to be infinitely
backwards-compatible. If QT makes a mistake, it can fix it in the next
version. The web can't do that, so we have to be more careful. If anything, my
biggest criticism of the web is that we move too quickly and stick too many
"modern" features in. I would have been happy to drop Classes and Arrow
Functions from the JS spec, and I would have been happy to drop `sticky` from
the CSS spec. As an engineer, I absolutely don't want a hamburger menu as a
core HTML component.

I've had people argue to me that HTML needs more 2-way data binding and
element types -- they want the ability to tie a list to a JSON object or
something, instead of needing to render out separate `<li>` elements. These
people are missing the point.

HTML is your user-presented state. We have a few elements that break this
convention, but for the most part we want your final HTML to be static and
human-readable. It's not for you, it's for your users. And 2-way data bindings
would get in the way of that.

For laying things out and creating complicated lists, we have third-party
libraries/frameworks -- and honestly, they work fine. If you think the web is
overcomplicated or has too many frameworks right now, just wait until we start
stuffing a new first-party component into it every time any design trend
becomes popular.

And even if we did add all of that nonsense, people would just ignore those
components anyway. No manager I've ever worked with has ever said to me, "you
know, pure HTML select inputs look great and I don't mind them rendering
differently in different browsers." I would be reimplementing them in JS
anyway just to get the styling consistent between IE and Firefox. The good
HTML components I can actually use are the low-level ones like simple input
fields -- because they're small and simple enough that they can be styled and
incorporated into larger custom-built solutions.

Heck, I've had managers complain to me about _scroll-bar_ styling before. But
sure, they'd totally be happy with a giant, pre-built, monolithic tree-view
component that's using mid-2000s styling.

~~~
simias
I'd argue that the problem isn't so much backward compatibility than being
opinionated vs not. Qt knows what it's doing, knows what it isn't doing and
then from there defines the perimeter of its APIs.

For better or worse the web never did that work, HTML+CSS+JS is meant to be
both a way to make static websites, but also interactive e-shops, but also
mail clients, but also videogames, but also ultra-heavy single-page apps like
Discord etc...

And that's the greatest power of the web, but I can't see how this state of
affair won't lead, one way or the other, towards a more monolithic
architecture. Keeping HTML and CSS cleanly separated and JS only for the fancy
stuff (but always optional!) is noble but it's a pipe dream when the use cases
are so diverse. WebAssembly, or something like it, seems to be clearly the
path forward.

Overall I think we should be happy too, at least it's not a closed source
blob. Remember how long it took us to get rid of bloody Flash? Actually if
Steve Jobs hadn't decided to drop it from iPhones I wouldn't be surprised if
it had survived in common use to this day.

~~~
BlueTemplar
The fancy stuff can go live in apps, it has nothing to do in a browser
designed for webpages first. I mean, just compare the GUIs of VLC and YouTube!

~~~
shadowgovt
But with the strong advantages of access to the Internet that a website brings
(which is itself a whole bag of hard problems to solve), the appeal of
building things accessible via browser user-agent (regardless of what the
thing is) is huge.

It shouldn't be necessary to toss out the cookie jar, the HTTP connection
handler, the XSS protection just because one wants to do something a bit
different with the final rendering stage.

~~~
BlueTemplar
What prevents access to the Internet from a non-website ? Why use the
HyperTEXT Transfer Protocol for things completely unrelated to text - it's not
like other, more appropriate protocols are not available, or cannot be
designed ! (Or that URLs are limited to HTTP...)

~~~
shadowgovt
At this point, HTTP has enough tooling around it to do enough significant
application-layer things that the opportunity cost of rolling new protocols is
_extremely_ high.

It's not just text transfer... HTTP also goes hand-in-glove with HTTPS, which
is a technology few people want to build an alternative for (and fewer people
should be trusted to do correctly).

~~~
BlueTemplar
Trying to force everything over HTTP is a bad practice that is slowly killing
the Internet.

~~~
shadowgovt
[citation needed]. Traffic, usage, diversity of usage, investment, all of
these are higher than they've ever been and still trending upwards. What
definitions are we using by which we can look at these numbers and claim the
internet is being "killed?"

~~~
BlueTemplar
[https://news.ycombinator.com/item?id=20841059](https://news.ycombinator.com/item?id=20841059)

~~~
shadowgovt
If that's the definition by which people think the internet is dying, I find
the definition suspect. And I find the solution suspect, because the notion of
building protocols instead of platforms doesn't address the question of how to
route those protocols over a network that has evolved to address the problems
associated with laissez-faire protocol management in the past.

There's a very good reason that so many systems block everything except port
80. Does the idea of protocols instead of platforms address that reason?
Because most people don't want to make themselves vulnerable to attacks along
threat vectors they aren't even aware exist.

~~~
mtrower
> There's a very good reason that so many systems block everything except port
> 80.

Elaborate? Rather than using different ports for different protocols and
filtering what you don't want/need, you instead tunnel everything through port
80 and effectively don't filter at all?

~~~
shadowgovt
Remember when Windows installs didn't have firewalls on by default and it was
pretty trivial to attack people's installations via insufficiently-secure
protocols running on open ports? It was a bad time.

HTTP has both elaborate tooling for deep packet analysis and a battle-hardened
secured protocol, which we don't get with new protocols.

~~~
BlueTemplar
Well, yes, we used to not care about security as much.

These days, don't you think that consumer routers sold without firewalls
should be about as illegal as selling cars with only motor braking ?

------
nojvek
The design goals of WebAssembly are the following:

Fast, safe, and portable semantics:

* Fast: executes with near native code performance, taking advantage of capabilities common to all contemporary hardware.

* Safe: code is validated and executes in a memory-safe [2], sandboxed environment preventing data corruption or security breaches.

* Well-defined: fully and precisely defines valid programs and their behavior in a way that is easy to reason about informally and formally.

* Hardware-independent: can be compiled on all modern architectures, desktop or mobile devices and embedded systems alike.

* Language-independent: does not privilege any particular language, programming model, or object model.

* Platform-independent: can be embedded in browsers, run as a stand-alone VM, or integrated in other environments.

* Open: programs can interoperate with their environment in a simple and universal manner.

Efficient and portable representation:

* Compact: has a binary format that is fast to transmit by being smaller than typical text or native code formats.

* Modular: programs can be split up in smaller parts that can be transmitted, cached, and consumed separately.

* Efficient: can be decoded, validated, and compiled in a fast single pass, equally with either just-in-time (JIT) or ahead-of-time (AOT) compilation.

* Streamable: allows decoding, validation, and compilation to begin as soon as possible, before all data has been seen.

* Parallelizable: allows decoding, validation, and compilation to be split into many independent parallel tasks.

* Portable: makes no architectural assumptions that are not broadly supported across modern hardware.

If webassembly is truly able to meet this goals, together with good debugging
and tools, it will become the the universal way to represent computation
across devices and platforms.

Really cool.

~~~
skunkworker
Two of the most exciting applications I've come across so far are allowing for
in-browser audio encoding with a provided encoder and distributing WASM
binaries to run on edge servers.

About 5 years ago I tried to use an optimized javascript file to encode some
audio in browser before uploading, it was painfully slow and very hardware
intensive. But using wasm in the vmsg [1], it distributes the LAME encoder
allowing for in-browser MP3 encoding.

And secondly cloudflare allows for their workers to be written in WASM,
allowing for more processor intensive apps (like resizing an image) to be
completely on the edge.

I see it as eventually fulfilling the portability goals that java applets in
the browsers use to have, but instead of one you have many companies agreeing
on the implementation.

[1] [https://github.com/Kagami/vmsg](https://github.com/Kagami/vmsg)

[2] [https://blog.cloudflare.com/webassembly-on-cloudflare-
worker...](https://blog.cloudflare.com/webassembly-on-cloudflare-workers/)

~~~
robocat
> like resizing an image

For image uploading, resizing is best done in the browser, so you are not
sending large files over a limited mobile connection. The code is ugly (it
also needs to fix image rotation by reading EXIF information because browsers
are broken, and if supporting IE11 then there is some other voodoo).

~~~
zzo38computer
The problem is that the browser does not let me enter a shell command where a
filename is expected (Heirloom-mailx does allow it, and is something I often
use when dealing with attachments).

------
duxup
Does anyone have any good intro resources for WebAssembly for noobs?

I've read articles here and there seen some in person demos, and honestly
struggle to understand what it is / how it would / works relative to the
current state of JavaScript frameworks.

Often I'm approaching it from a JavaScript framework (React/Vue/Angular)
approach as I'm a bit of a noob to the industry and that's generally my day
job working on web applications.... and while I read about WebAssembly I
wonder about state management and someone tells me "oh you still need to
something to do that" and I'm a bit lost on ... how that would work / why I
would or wouldn't use one of those frameworks anyway, etc. So many examples
I've seen are one off simplified (and for good reason I like those for demos)
widgets but ... I'm not sure I've seen them as an application / understand how
that would work.

Obviously I'm missing a lot here and feel like on HN I'm often talking to
folks who aren't so much front end web devs who are excited about the
efficiencies and such but ... not sure how this plays out in a practical sense
/ relative to the state of web applications as they are now.

~~~
mdszy
When was the last time you were able to unminify a javascript file that you
wanted to investigate and were able to make sense out of it?

~~~
reificator
Within the last month or two, certainly.

You have to be willing to edit it, start renaming variables to describe what
they hold, rename them again if they get something unexpected assigned, rename
functions once you have a good idea of what they're trying to do, and repeat
until everything has a name.

~~~
mdszy
So it sounds like you're having to reverse engineer it, similar to any "binary
blob".

Sounds very "open" to me.

~~~
reificator
I'm not arguing openness. Merely that minified js can be understood with some
effort.

------
dmvinson
This feels like another step away from the free and open web many people are
clamoring for. Distributing opaque binaries with websites instead of
Javascript is a step past even the obfuscated minified javascript files meant
to be confusing. At least those can still be debugged, stepped through, and
explored freely by the end user if they want to learn or reverse engineer. Is
there any tool or standard being worked on to make .wasm files coherent for
users who have to run the code to view websites? This feels like a step
backwards in so many ways, even if it is a technological marvel.

~~~
maeln
Please, can we stop having this argument every time there is an article about
webassembly ? WASM not any more obfuscated than any minified JS. Being a
bytecode doesn't make you "unfree". You have access to the same tool to debug
JS and WASM. And the WASM specification is open. There is literally no
difference between running JS or running WASM.

~~~
strictnein
A binary format is no more obfuscated than minified JS? What now?

Going to need some clarification on how that's the case.

~~~
jandrese
I guess he's saying that an unminifier tool is effectively no different than a
decompiler, and both are basically unreadable without it.

That said, I don't know of any webassembly decompilers, although I guess they
must exist by this point. But also historically decompilers have been
imperfect as some of the structure of the code is lost in the compilation
process and has to be inferred, sometimes incorrectly, by the decompiler.
Compare to a minifier where all you lose is the variable names, comments, and
possibly helpful whitespace. All of the structure of the code is still there
and there are no heuristics necessary to recreate something that resembles the
original source.

~~~
cjbprime
There are certainly wasm decompilers -- wasm2c, wasm2js, etc. You also have
access to the browser's JS debugger for breakpoints, line by line execution
control, dumping wasm's linear memory.

I haven't written any productive WebAssembly but I play Capture The Flag
competitions, and it's become frequent for a wasm reverse engineering
challenge to be thrown in. The tools are good enough to make that tractable,
even for non-experts in wasm like me.

It helps a little that it's a stack-based rather than register-based VM.
Usually more of the intent of code is preserved that way. It's like reversing
a JVM class, rather than like reversing a native binary.

~~~
throwaway40324
What are these Capture The Flag competitions? Do you mind posting a link?

~~~
cjbprime
Sure. My favorite explanation's a short video:

[https://youtu.be/8ev9ZX9J45A](https://youtu.be/8ev9ZX9J45A)

------
Unit-336
For those who are asking themselves what WASM does differently than Java, .NET
or other native extensions like ActiveX or NaCl, here's the best rationale doc
I found on this topic:
[https://github.com/WebAssembly/spec/blob/master/papers/pldi2...](https://github.com/WebAssembly/spec/blob/master/papers/pldi2017.pdf)

~~~
miohtama
Thank you. This is the most exhaust ive article on WebAssembly design goals I
have read.

------
magsnus
I really hope this can become a viable alternative to the JS-frameworks we
have today for webapps and that more apps can be served via the web.

~~~
tiborsaas
In what way viable alternative? JS performance is pretty good if you think of
an admin interface or any business dashboard UI full of charts and stuff.

React for example shifting towards functional programming makes FE apps
simpler and predictable.

If you dislike the HTML/CSS UI layer then WA is indeed an alternative. However
you need to reimplement everything, like text selection, right click, focus,
accessibility, dropdowns, etc, because all you have is a <canvas> to draw on.

But! WA will eventually have DOM access, that will definitely open up the
landscape to create new frontend frameworks.

------
smattiso
Good. Javascript needs to die. It was far simpler to build performant multi-
device UIs 15 years ago than it is today. Building UIs natively on iOS and
Android is so much simpler than building for the web.

Technical question: 1.) What is the speed of WebAssembly on iOS WebKit and
Android WebView? 2.) Is it feasible to write an entire app UI in something
like Qt and target WebAssembly? 3.) Android, iOS, Windows versions of the app
are Qt apps natively or possibly through the device's WebKit.

Is this possible today? Is there a better UI library than Qt for this?

~~~
MuffinFlavored
> Building UIs natively on iOS and Android is so much simpler than building
> for the web.

I can get lit-element with no build process going to prototype something in a
single .html file in probably 30 seconds. I don't think XCode/iOS developers
can compete with the simplicity. Define initial state, alter it through
events, pull data through fetch(), write HTML. I know for a fact iOS
development isn't that simple.

~~~
saagarjha
Swift Playgrounds, when they work, can compete with that somewhat.

------
arghwhat
W3C endorsing it has nothing at all to do with whether or not it is here to
stay.

------
Crontab
This sounds interesting, but personally, I am worried that this will just turn
into yet another browser technology that will be used to abuse and track
users. I really hope I am wrong.

------
cylon13
What's the debugging situation like for developing WASM apps? I'm doing a lot
of TypeScript+WebGL work right now, and though TS is fairly nice, my use case
requires being aware of not allocating too many new objects frequently, and
that kind of control would be easier in something like C++ or Rust. I've been
thinking of hacking together a small test project with WASM+WebGL to see what
it's like, but I get the sense it might still be more hassle than it's worth
to use in production. Currently I can easily set breakpoints in my TS code, I
can see how much memory is allocated by which functions, how much time is
spent in each function, etc. very easily. If there's a way to do these kinds
of things with WASM in another language, that would be fantastic.

~~~
echeese
The tools are still being worked on but the Chrome team made a pretty big step
by adding DWARF support to the debugger:
[https://twitter.com/ChromeDevTools/status/119280381802471014...](https://twitter.com/ChromeDevTools/status/1192803818024710145)

EDIT: Here's an article from yesterday about this:
[https://developers.google.com/web/updates/2019/12/webassembl...](https://developers.google.com/web/updates/2019/12/webassembly)

------
dmitriid
Ok. It's here to stay. What's the progress on the two dozen post-MVP features?

The "arrival" of WebAsm to w3c only means that w3c had finally woken up from
eternal slumber and realized that everyone has already implemented The listed
features.

------
bogwog
Hopefully this also means that Javascript is going away for good

~~~
k__
I think people starting to pump giant binaries to the browser will lead to
JavaScript leveraging its strengths and getting even better.

~~~
bogwog
> I think people starting to pump giant binaries to the browser

As if that's not already happening today with obfuscated and minified
javascript

~~~
krapp
Those aren't technically binaries, as much as people want to cling to the
metaphor of javascript as "bytecode" and pretend no distinction exists between
the two.

~~~
bogwog
> and pretend no distinction exists between the two.

What's the distinction then? That obfuscated javascript can be looked at by
people who don't know how to use a hex editor?

~~~
krapp
Javascript-as-bytecode is a _metaphor,_ not a technical description.
Javascript is not actually bytecode in the same way that a .java file is not
java bytecode.

~~~
bogwog
Okay. Thanks for that.

------
chx
How's the DOM manipulation coming along?

------
postit
It amuses me we're circle backing to have applets all over again.

~~~
tiborsaas
This time we did it better, cheers.

~~~
erokar
That remains to be determined.

------
utf985
I'm interested in how will WebAssembly affect the functionality of browser
addons such as ad and script blockers?

------
mrandish
Does WebAssembly threaten app store business models by allowing devs to
distribute apps directly via browser (thereby saving the app store 'tax')?

For example, if Adobe delivers its new mobile Photoshop directly via iPad
Safari will Apple have a way of 'nerfing' WebAssembly to stop them?

------
markstos
This is bad for frontend JavaScript being "open" for review, right?

Companies will ask their developers to deliver WASM resources in the name of
performance. As a notable side-effect, it will become harder to review how
websites work.

Yes, I'm sure there will be reverse-compilation tools for WASM, but still.

~~~
eeZah7Ux
The advertisement industry is huge and it's the driving force behind Google
and many other companies.

webassembly is encouraging websites to dump megabytes of binary code in
browsers.

Obfuscated, analysis-resistant code to ensure that people cannot disable ads
and tracking.

It's appalling that we are accepting this.

~~~
linuxftw
And thanks to ubiquitous HTTPS, there's no way to analyze what information is
leaving your device (especially on a mobile device).

------
cryptozeus
Why are people saying with wasm coming JavaScript will have tough time ? Think
about it as flash vs JavaScript. They can happily co exist or u can choose one
of the other. Don’t assume that wasm is the hammer for every nail.

------
apatheticonion
<script type="module" src="app.wasm"></script>

Please

------
tmountain
What's the horizon for WebAssembly capable browsers gaining enough marketshare
that it becomes a viable compilation target?

~~~
oefrha
[https://caniuse.com/#feat=wasm](https://caniuse.com/#feat=wasm)

Pretty much all relevant browsers support wasm (and I suspect data for the few
non-compliant Chinese browsers may be outdated, they’re definitely not last
released in 2016 or 2017). Do you have some other idea of wasm-capable?

~~~
pastage
Our buisness instances are 30% IE, luckily not even that is enough to get
anyone to care about IE around here.

~~~
oefrha
At least you can rest assured it’ll never get wasm support.

------
shiado
Does anybody know the state of the art for wasm tooling? I have used
emscripten but are there any excellent 'higher level' tools? The worst part
was writing the interface between the wasm and JS.

------
dm33tri
What I'm thrilled to see is an optimization of binary sizes in compilers and
libraries. Maybe <1MB native apps will become common (or few MB of code for
single webpage will become standard)

------
dm33tri
Write once, run everywhere.

I bet in few years we will run wasm natively on processor.

~~~
goto11
This was also attempted for Java bytecode but didn't really pan out. I think
the benefit just wasn't there compared to JIT compiling for a regular
processor.

The processes would have to translate the wasm into some form of register-
based operations anyway, and a JIT compiler might be able to do this more
efficiently since it can see a bigger picture than the processor.

~~~
int_19h
JVM bytecode is very high-level though (it deals with objects, and has opcodes
for method calls etc).

Wasm is in this interesting spot where it's relatively low-level, but high-
level enough to allow proper sandboxing. It strikes me that the arrangements
to accommodate that, like call indirection via tables, could be optimized on
CPU level. Not necessarily in a sense of a CPU that directly runs wasm, but
rather a CPU architecture which is optimized to be a target for JIT or AOT
compilers from wasm.

~~~
marcthe12
I wonder it's small enough to have the interpreter in kernel space

------
dang
The submitted title was "It's official, WebAssembly is here to stay". That
broke the site guidelines by editorializing. Please don't do that.

------
batterystd
So what was webassemnly until now?

