
Web Assembly now supported across all browsers - ternaryoperator
https://www.infoq.com/news/2017/12/webassembly-browser-support
======
starik36
> across all browsers

IE.

Everywhere I've worked, we still have to support it. Unless Microsoft ports
Edge to Windows 7/8 and makes it a default browser, I don't see the situation
changing anytime soon.

~~~
onion2k
_Unless Microsoft ports Edge to Windows 7 /8..._

Support for Windows 8 ends in a month[1]. There's extended support for some
users for a further 5 years, but if you're doing client work rather than
writing bespoke software for a specific user then IE, and Windows versions
less than 10, are effectively dead and gone.

It's perfectly reasonable to use web technologies that aren't supported by IE.
Ideally you should have a bare HTML server-side alternative for those users,
but that's true for _everything_ that a user might not have (or have turned
off, eg JS).

[1] [https://support.microsoft.com/en-gb/help/13853/windows-
lifec...](https://support.microsoft.com/en-gb/help/13853/windows-lifecycle-
fact-sheet)

~~~
Spivak
> Windows versions less than 10, are effectively dead and gone.

Ha! Don't we all wish. Here's the marketshare numbers from this month [1].

\- Windows 7: 43%

\- Windows 10: 30%

\- Windows XP: 6%

\- Windows 8: 5%

And companies are going to be buying extended support for 7 no different than
XP so you'll have to wait out that 5 years.

[1] [https://www.netmarketshare.com/operating-system-market-
share...](https://www.netmarketshare.com/operating-system-market-share.aspx)

~~~
onion2k
My point is that once Microsoft no longer supports any version of Windows that
runs IE as it's default there's a very valid reason to stop supporting it as a
'mainstream browser', and using it to avoid technologies that aren't supported
by it is somewhat dubious reasoning.

If users with IE6 and users with IE11 get a boring HTML-only-but-still-
basically-functional website, and users with Edge 15 get the fancy WASM
enhanced website, then that's fine in my opinion.

~~~
Spivak
> IE as it's default

So even though Windows 10 still ships IE the fact that it's not a _default_ is
enough to not support it? Bad news for Firefox and Chrome then.

> If users with IE6...

Sure, albeit a bit extreme, that's more or less progressive enhancement.

~~~
onion2k
_So even though Windows 10 still ships IE the fact that it 's not a default is
enough to not support it? Bad news for Firefox and Chrome then._

Using Firefox or Chrome is a step sideways to use an alternative browser.
That's great. The more up-to-date browsers people use the better in my
opinion.

Using IE is a step backwards _usually_ to support a specific technology that
isn't supported by other browsers (and IE is often used along side another
browser if that's the case), or because the user is looking for a particular
experience. I don't see either of those reasons to avoid using WASM on a new
website so long as there's also a fallback to support browsers without it,
even if that's a limited version of the site.

------
inDigiNeous
Any good example projects already using WebAssembly ? Some list with multiple
examples would be nice.

~~~
frik
We should sometimes pause, and think about the disadvantages a new technique
will bring to the web.

I am completely fine with asm.js.

Though WebASM is a like a wet dream for big corp with mass of legacy code in
C++. We will see Office running on WebASM and other closed binary blobs in
near future. It's very contrary to the concept of the open web - do you want
to live in AOL-land again, were everything is closed off? No? Anyway great you
helped them. I fear WebASM has several downsides that will harm young startups
a lot in near future - only unicorns and big corps will benefit, it will be a
win-win, less competition, because of harder entry to market, and they can
ship their decades old C++ blobs as a service. It's time to wake up, and stop
WebASM or severe limit it's functionality. Where is Mozilla foundation? Or is
the new Mozilla just another startup, backed 90% by Google money.

~~~
ankitpati
I am a C coder, and I cannot wait to have my code on the web, decimating
inferior languages like JavaScript. If a startup relies on JavaScript to keep
out competition from C coders, well, too bad. They will be decimated in terms
of performance. The web will be ruled by the best performing apps written in
the language of the Linux kernel.

~~~
whatever_dude
Performance in web apps is not a goalpost for everybody. While there's
certainly web apps that are problematic in terms of performance, you're
unlikely to be running at 100% CPU the whole time, so it's not like using C
will be the right solution.

I can see how C/C++ (and, well, more likely Rust) will become a de-facto
solution for when you need performance or some type of robustness to your apps
(ie probably the right thing for Figma). But the potential performance
improvement might be negligible on most makes, and unlikely to offset the fact
that you'd be working off a completely different stack making things like
debugging and inspecting much harder.

What I think is likely is that using WebAssembly will allow new types of web
apps to become popular. Things like video encoders, image editors, etc. Things
that you just wouldn't do with JS anyway, at least not in the heavy parts.
Thing of a standard web app that uses ffmpeg on the background.

~~~
flavio81
> _Performance in web apps is not a goalpost for everybody._

But in 2017 startup and companies are starting to understand how fast response
times (on a website/web-app) are of critical importance for gaining a good
user base.

~~~
whatever_dude
True, but in my experience bad UI response times are more related to something
goddamned dumb like running a series of super expensive scroll events or
watching DOM changes for some idiotic reason, more than about raw processing
power.

A C solution might make the former faster, but it'd still be a dumb
architecture. A cheaper solution than migrating your whole codebase to a
separate language and build process is knowing how to deal with events and how
to parallelize (or delegate) stuff correctly.

------
borplk
Does anyone know when/if DOM support will come to WASM?

~~~
Bob2018
I am also curious about WebGL and/or canvas approach. This would allow
bypassing the HTML and CSS mess not just JS mess.

~~~
Klathmon
Unless you have a good reason, I urge you to never do that. Even ignoring
accessibility (which is pretty much completely ruined in this situation no
matter what), you'll need to reinvent every single primitive widget you need
yourself and have it work the same as it does on all platforms.

That's a shitload of code shipped to the user before you even write a single
byte of code for your application!

~~~
scottmf
No doubt someone will build that library though

~~~
baq
It's been done, multiple times. See qt, gtk, etc.

Personally this revolution can't come soon enough.

~~~
dbbk
Didn't Firefox also used to be like this? They reinvented every UI widget, and
as a result felt like garbage on Mac.

------
TekMol
I would try it out, if it would be possible to just type web assembly by hand.
Then I would just open an html file or a jsfiddle and play with it.

But as I understand it, it needs a toolchain?

~~~
a_humean
Yes, WebAssembly is bytecode that is a IR compile target for other languages,
which right now is limited to C and C++ via Emscripten, or Rust via its own
normal toolchain or Emscripten as well. It has a plain text assembly output
called WAT, but its not really meant to be handwritten, but rather reviewed as
a build artifact.

You can see an examples in Rust including the readable Wat output here:

[https://www.hellorust.com/demos/add/index.html](https://www.hellorust.com/demos/add/index.html)

~~~
TekMol
If I can't just type it and see the result, I am not much interested. I don't
like to install software. As a child of the web, my feet are firmly planted
into the cloud.

~~~
exDM69
You _can_ do that but why would you want to? The tool you're looking for is
wat2wasm, which converts the human readable WAT source to WASM binary, and
here [0] is an online tool if you want to tinker with it.

Compiler IR's like WASM or LLVM IR are very laborious to type, they're
intended to be produced and consumed by compilers.

You need to write very verbose code with all the type declarations, which
aren't automatically propagaged, ie. `(func $foo (param $0 i32) (result i32)
...)` and `(i32.add ...)`. There's very little point in writing code like this
by hand, apart from testing and debugging the compiler producing or consuming
this code.

It doesn't make much sense to have this "in the cloud" outside of toy tools
like this. In any kind of actual work scenario, you'd be running a compiler
producing WASM on your development machine and deliver the WASM binaries over
HTTP to the client machine. The whole point is to have near-native performance
while reducing the compile time on the client side.

But if you want to tinker with it, knock yourself out. Here's the tool:

[0]
[https://cdn.rawgit.com/WebAssembly/wabt/fb986fbd/demo/wat2wa...](https://cdn.rawgit.com/WebAssembly/wabt/fb986fbd/demo/wat2wasm/)

~~~
BigJono
I like this answer a lot more than the other ones that are just dismissive.

I think there's at least _some_ value in these "toy tools". Would being able
to tinker with WASM not help development of compilers? I place a very high
value on understanding as far down the stack as you can, I don't think
ignorance of every abstraction layer below the one you're working on is a very
noble goal to strive for.

~~~
exDM69
> Would being able to tinker with WASM not help development of compilers?

There are tools, even web based ones, that allow you to tinker with WASM,
compile C, C++ or Rust code to WASM, print out the WAT representation, turn
WAT into WASM, run the WASM blobs through JS, etc.

These tools are probably very useful for the guys developing WASM frontends
and backends. E.g. sharing a piece of WASM code with other developers.

Should the average developer use them? Not really. Maybe spend an hour poking
at things to get the general idea of how it works. You really don't need to
understand the details of LLVM IR, SPIR-V, WASM or GCC's GIMPLE in order to
use those compilers.

Is it a good idea to understand what and how are intermediate representations
used in compilers but actually writing that by hand is not necessary or
productive.

------
jokoon
I tried to use emscripten as a tool chain, it was not the greatest experience.

I really hope better toolchains will appear.

Emscripten seems to be a collection of weird hacks.

------
AnIdiotOnTheNet
All browsers? Including Lynx?

Oh, no, you meant all the official browsers of our corporate masters. Sooner
or later they'll all be one.

~~~
gilrain
We welcome you to switch to Mozilla Firefox!

