
Ask HN: Is WebAssembly the next big thing? Is it worth investing in learning? - elamje
I know very little about WebAssembly and I trust the opinions of most on HN.<p>Do you think WebAssembly is the next major internet development disruptor? Why or why not?<p>Do you personally see asymmetric gains for investing in learning it while its young?
======
cimmanom
It probably depends on what you’re interested in working on.

My guess is that there will be a 5-year period of explosion in a) compilers
for existing languages; b) frameworks for working with the DOM and other web
APIs in said languages; and c) a few new languages built on top of it. Then
there will be a few more years of transition where the winners and losers
among all these new tools gradually sort out.

And then we’ll all go back to developing in higher level languages and
compiling down - you’ll just have more options besides JavaScript, typescript,
and coffeescript, basically. A few jobs will remain that involve tuning
compilation.

------
darpa_escapee
I always saw it as a compile target for higher level languages.

As in, unless you're interested in working on compilers or web applications
that need low-level optimizations on the client-side despite existing
WebAssembly compilers, you won't need to "learn" WebAssembly.

~~~
elamje
I gotcha. Thanks

------
raboukhalil
WebAssembly is an awesome technology and I'm super excited about it, but IMHO
it's probably best to assume you don't need it unless you can convince
yourself otherwise.

That said, here are a few examples of where it shines (warning: shameless
plugs incoming):

\- In data analysis apps, you can replace slow JavaScript calculations with
WebAssembly and see significant speedups--I wrote this case study on my
experience with that: [https://www.smashingmagazine.com/2019/04/webassembly-
speed-w...](https://www.smashingmagazine.com/2019/04/webassembly-speed-web-
app/)

\- It's super helpful in porting games from languages like C/C++ to the web
without having to rewrite the game from scratch. Here's a post I wrote about
how to port a game like Asteroids to the web:
[https://medium.com/@robaboukhalil/porting-games-to-the-
web-w...](https://medium.com/@robaboukhalil/porting-games-to-the-web-with-
webassembly-70d598e1a3ec?source=friends_link&sk=20c835664031227eae5690b8a12514f0)

\- WebAssembly is really good for building playgrounds out of command line
tools. Here's how I built one for the jq CLI:
[https://opensource.com/article/19/4/command-line-
playgrounds...](https://opensource.com/article/19/4/command-line-playgrounds-
webassembly), the benefit being more secure than hosting it on the backend +
much faster runtime

\- I'm also excited to see how WebAssembly will impact work outside the
browser: [https://hacks.mozilla.org/2019/03/standardizing-wasi-a-
webas...](https://hacks.mozilla.org/2019/03/standardizing-wasi-a-webassembly-
system-interface/), especially with Function-as-a-service offerings that
support Wasm like Cloudflare/Fastly workers, where the benefit is that I can
write my function in any language + the time to initialize the function could
be much faster

Another shameless plug: if you want a practical intro to WebAssembly, I self-
published a book about it recently:
[http://levelupwasm.com/](http://levelupwasm.com/)!

------
nostrademons
Next big thing? Probably not. Next big things are usually innovations that
open up areas to computerization that had previously been resistant to
computerization. The GUI opened up all the users who couldn't memorize
hundreds of command-line commands; the Internet opened up distribution and let
software publishers bypass the retail distribution chain entirely, and also
SaaS billing & delivery that creates markets where transaction costs would
previously have made them impractical; mobile opened up situations where users
couldn't physically have a laptop or desktop computer with them; blockchain
opens up trust & exchange of value; neural nets open up classification,
extraction, and generation tasks of unstructured speech or video data. The
reason these are so highly valued is because they open up whole new markets to
computing, ones that could support potentially billion-dollar businesses.

It's like a decent technological investment, though, one that could support a
long-term career if you're interested in compilers or language tools. The
trend long-term is away from Javascript as the sole language of the web, and
WebAssembly is also finding its way into other platforms (eg. EOS) in the
crypto & SaaS spaces.

~~~
elamje
Oh okay, that’s really informative. So is the idea that you send compiled
binaries to the client to run in xlangs runtime?

~~~
nostrademons
Yeah, it's useful for any platform that wants to run third-party code in a
remote sandbox. That includes cryptocurrency platforms that run arbitrary code
as part of the mining process; PaaS or FaaS ("serverless") offerings that
handle the scalability aspects of running your code while letting you supply
the business logic; or other runtimes yet to be developed. It's handy for
these platforms because it lets users write their code in any language with a
WebAssembly backend without being locked into a specific language.

------
justinclift
Been following along with WebAssembly (wasm) for a while, mainly from a Go
perspective.

WebAssembly looks like it'll be a major thing, but from the Go side it's still
not really ready for production usage:

1\. Generated binaries (by mainline Go) are still too large.

There's no good dead code elimination (my wording, it's actually a bit more
than that) in generated Wasm, so the binaries are still MB instead of kB. :/

eg "Hello world" in Go is about 2MB, as it embeds pretty much the entire Go
runtime instead of stripping it down to just the println() equivalent code.

These large binaries do compress ok (eg 2MB -> to 500kB), but still, that's
pretty big.

2\. There is an alternative Go compiler (TinyGo:
[http://tinygo.org](http://tinygo.org)) that generates much smaller binaries
(eg 2kB), but it doesn't yet support all of the Go spec. When it's coverage is
wide enough to generate Real World useful webasssembly, that should see a
large increase in Gophers creating Wasm things. :)

3\. Wasm doesn't yet have a good debugging story. eg no support yet for being
able to breakpoint a wasm binary, step through it in an IDE, etc.

There's an official "WebAssembly Debugging" Subgroup putting time into adding
the needed support to the spec:

[https://github.com/WebAssembly/debugging](https://github.com/WebAssembly/debugging)

Yury Delendik seems to be the main person doing the work:

[https://yurydelendik.github.io/webassembly-
dwarf/](https://yurydelendik.github.io/webassembly-dwarf/)

\--

If there are Go people around interested in WebAssembly, the #webassembly and
#tinygo channels on the Go Slack are fairly active, with lots of development
co-ordinated there. :)

[https://gophers.slack.com](https://gophers.slack.com)

\--

The WebAssembly page on the Go wiki has useful info too: :)

[https://github.com/golang/go/wiki/WebAssembly](https://github.com/golang/go/wiki/WebAssembly)

------
tracker1
If you're interested in Rust or Go, learn rust and go... if you want to use
them with WASM in browser (for now) or out of browser with an existing
runtime, then there's room to learn that too. All the same, best to just learn
a language that already has decent WASM support first, and go from there.

~~~
elamje
Yes I’m definitely interested in Rust! How is rust binary sent to an arbitrary
computer and executed? I thought rust binaries are platform specific and would
require compiling on the clients OS.

~~~
tracker1
Wasm is a compile Target... You run wasm in browser or if it's for a server,
there are wasm runtimes out of browser.

If you start with some Google Foo, you should be able to get your feet wet.

------
cracauer
No threads. no deal. There are also concerns about the ability to unwind the
stack for non-local exits in manners that satisfy some languages'
specification.

Our compiler is ready to target WebAssembly, but we can't run anything useful
on it without those two.

