
Rust and WebAssembly in 2019 - crunchiebones
http://fitzgeraldnick.com/2018/12/14/rust-and-webassembly-in-2019.html
======
danShumway
I'm really excited and happy about the direction Rust has gone with WASM; and
this is coming from someone who has never used Rust before.

I like JS, a _lot_ , but my hope with WASM was still pretty much literally
what they're talking about here -- that languages would start to do first-
class replacements for Javascript. I didn't want people to create massive
binary blobs that were primarily just native code that rendered everything out
to Canvas as an afterthought. In contrast, Rust is building out better host
bindings, web-first tools, looking into fallbacks for older browsers like
IE11...

Nearly every time I read an article about Rust and WASM I feel happy and
hopeful. I think the work Rust has done here has been ridiculously valuable
for setting a tone and a standard for what WASM-targetting languages should
be.

As a result, Rust is pretty high up on my list of languages that I'm
interested in learning in the future, because I feel like any community that
is getting this much right on the web has probably also gotten other things
right with the core language. The fact that it's increasingly looking likely
that Rust on the web will probably be one of the best supported, most
thoughtful alternatives to Javascript out there makes it even more attractive.

------
losvedir
It didn't click until just now that rust is very naturally suited to
WebAssembly due to its lack of garbage collection. As I understand it, there's
no current plans for WebAssembly to include a garbage collector, so higher
level languages that want to compile to it will need to bundle their own,
increasing the size of the download quite a bit.

~~~
azangru
> As I understand it, there's no current plans for WebAssembly to include a
> garbage collector

There are plans to add a garbage collector. See
[https://hacks.mozilla.org/2018/10/webassemblys-post-mvp-
futu...](https://hacks.mozilla.org/2018/10/webassemblys-post-mvp-future/). But
meanwhile, Webassembly is mainly just for C and Rust.

~~~
hu3
> Webassembly is mainly just for C and Rust

That's absolutely incorrect. Go and .NET can target WASM for quite a while
now.

Microsoft's Blazor is specially interesting. Their FlightFinder demo written
in pure C# renders a beautiful app:
[https://i.imgur.com/HHFkB1E.png](https://i.imgur.com/HHFkB1E.png)

Code here:
[https://github.com/aspnet/samples/tree/master/samples/aspnet...](https://github.com/aspnet/samples/tree/master/samples/aspnetcore/blazor/FlightFinder)

~~~
steveklabnik
This is literally true, but last I checked, Go’s minimum size was about a
megabyte, Blazor’s was 300k, and Rust’s is ~100 bytes. That’s what your parent
means.

~~~
bayesian_horse
That's only a problem for more traditional websites. For applications 1MB is
just not an issue.

I imagine there will be some kind of CDN/cache to distribute runtimes. Maybe
even a WASM package management system for browsers?

~~~
steveklabnik
As I said above, this is true for an app, but you wouldn’t want it for every
library. That adds up very quick.

A CDN may happen; there’s some details that make it tough. We’ll see.

npm is already that package manager :)

~~~
bayesian_horse
No need to replace the millions of packages in npm. I predict there will never
be a shortage of new javascript frameworks...

No, npm is not THAT package manager. What I am talking about is a way for a
user's Browser to download for example a Python 3.7.1 runtime (and similar
packages) once, and use it on different sites and applications.

In the simplest form Google or Python.org could serve these files on a CDN. In
a more complicated form you could run an application on a range of Python
versions, and only download updates when you want and need them.

~~~
steveklabnik
Ah, yeah. We’ll see if it happens.

------
xvilka
Until there is direct DOM access within WebAssembly, the overhead of calling
back and forth to JS will prevent wider adoption and ditching JS for Web
development.

~~~
swsieber
That overhead has been greatly reduced in Firefox recently.

~~~
snek
Same with V8, since they added the liftoff compiler back in august

~~~
swsieber
At least on my android phone, Firefox is still an order of magnitude faster in
some benchmarks.

------
dakom
I decided that Rust is the natural next step for my personal side project
stuff, which I want to be more on the browser-based gamedev side of things.

The learning curve is enormous - since coming from like Unity and Flash, so
much is done for you... I mean, one _can_ write their own shader code and
physics and things, but it's not at all required in order to make impressive
content. Even in JS, Three.JS and friends typically take care of the heavy
lifting and deciding to get closer to the metal on both fronts (CPU and GPU)-
and in a new language (for me), is a bit daunting.

Anyway - I figured a good way to push myself to learn more productively is to
livestream while I'm coding and figuring stuff out. Forces some accountability
and might help others too.

So far I've only done two sessions and about to do my third. The goal is to
build a WebGL renderer from scratch with nothing but Rust (I had a Typescript
project that was after the same goal - so there's going to be a fair amount of
straight conversion, but it was never totally finished and some things can be
improved even if they would theoretically translate 1:1)

Live Stream URL:
[https://www.youtube.com/channel/UCGKhwtFOUlzj4VILDU0efkQ/liv...](https://www.youtube.com/channel/UCGKhwtFOUlzj4VILDU0efkQ/live)

Playlist URL:
[https://www.youtube.com/playlist?list=PLkzdeKCVtKYshqmgngLSq...](https://www.youtube.com/playlist?list=PLkzdeKCVtKYshqmgngLSqRV4UVt4QjaZ5)

If you join, please remember - the whole point is that I don't know what I'm
doing (yet) and I actually _want_ to struggle in order to learn, rather than
have solutions spoon-fed to me.

I think there will ultimately be at the very least some general functions here
which can be useful abstractions over web_sys/js_sys/etc. At least I hope so!

Lastly - schedule is irregular, so best way to know when it's live is to
subscribe and rely on youtube notifications ;)

~~~
k__
Really nice!

The Flash devs I met went all downhill with Flash, because they never learned
how to code and suddendly needed to do it.

~~~
ZeikJT
Doesn't sound like they were devs at all. Flash's AS3 (and to a lesser extent
AS2) were pretty good languages and after learning them it should be pretty
easy to transition to JS. AS3 was, imho, a better ECMAScript implementation
than JS was, especially because it was typed. As someone who worked in both
AS3 and JS I still miss it a bit but it wasn't that much of a leap to work in
other environments.

~~~
dakom
Yeah I agree... especially with stuff like Starling Flash/AS3 was (and I
suppose is) an amazing dev environment with robust capabilities.

I think one of the reasons "flash devs" get a bad rap is because a huge amount
of the paid work for an epoch was all about making like preloaders and banners
and things that were 95% timeline transitions and animations with just a
sprinkling of code.

It's like taking a JS developer from the 90's and putting them in the same
league of modern web app developers.

Same language (essentially, ish) but no comparison.

Especially with the last hurrah of flash which tied into native extensions for
standalone builds and things - Adobe really dropped the ball with something
great :\

------
sametmax
I wish something similar was officially worked on by the python core dev.
Ouputting wasm and being able to interpret it is going yo be necessary for the
language to stay relevant in 10 years.

But it not a priority at all atm.

~~~
lachlan-sneff
Python is extremely dynamic and compiling it into wasm would likely be
impossible or would generate extremely low-performing code.

~~~
baq
You ‘just’ wasm-compile the whole interpreter. It could even be feasible with
a cdn.

~~~
rthy
An example of compiling the CPython interpreter to WebAssembly can be found in
Pyodide ([https://github.com/iodide-
project/pyodide/](https://github.com/iodide-project/pyodide/)).

------
jillesvangurp
Rust and wasm is looking pretty interesting. I've recently started playing
with kotlin-js. Kotlin also has a wasm compiler but their javascript
transpiler has been around longer and garbage collection is short term an
issue for their wasm compiler. Also there are a ton of kotlin-js libraries out
there already which makes using this straightforward. This is exactly the kind
of stuff the rust people are targeting as well. Basically, both ecosystems are
creating all the tools and libraries they need to make pure rust or kotlin web
applications. Rust is ahead but Kotlin and other languages are not far behind.

IMHO, the next two years there is going to be a massive adoption of wasm as
the library ecosystem for different languages matures and as browsers
gradually improve their wasm support. Contrary to the popular belief with
javascript people, it will not be limited to just the performance critical
parts: everything people do with javascript today is in scope. Absolutely no
exceptions. I fully expect to see a lot of projects where the goal is to be
100% javascript free and I don't see any fundamental blocking issues to get
there.

If you are doing a greenfield project today, that is already a feasible goal
to set but you may have to reinvent a few wheels along the way or be dealing
with not so mature frameworks and tools. However, once you start doing rust or
kotlin, it will just feel wrong to have to revert to back to javascript or
pull in an npm and wrap that with some facade. That's like admitting defeat.
Basically, Rust people already concluded that they can do it all and are now
in the process of doing it.

~~~
jamil7
Personally I can't wait, javascript is miles ahead of where it was 5 years ago
but it's still pretty painful to use on large, longer running projects with
bigger teams. I once enjoyed it enough and now dread starting a project in it.
Typescript is a massive improvement but maybe the ship has sailed. If we don't
_have_ to use it anymore why bother?.

~~~
jillesvangurp
With you there. I've spent some 'quality time' with javascript recently (as a
backend developer). It doesn't suck as hard as it did a mere two years ago
when I last did this and it is massively better than 20 years ago (netscape,
shudder). But it's not quite awesome just yet.

Basically, I'm planning to ditch javascript pretty soon. I consider typescript
to be a stop gap solution. I'd prefer to use something like Kotlin or indeed
Rust. IMHO Kotlin is a great fit because it already is used for frontend work
in Android. Also the transition from javascript to Kotlin is pretty smooth
once you get over the stockholm syndrome that most javascript developers seem
to suffer from (they don't seem to know better). I've seen a few people adapt
to Kotlin and liking it. In my experience, these things tend to be driven by
people voting with their feet. There's lots of early signals on Github that
this is starting to happen.

I'd also prefer to opt out most of the npm ecosystem. IMHO, most of the stuff
there is inherently javascript centric and not a great fit in a type safe
environment that has things like generics, polymorphism, and other stuff that
makes frameworks look and feel a bit differently. Even with type annotations
like in typescript you get lots of leaky abstractions and you are still
dealing with javascript when it inevitably blows up. Better to make a clean
break with this and create a new ecosystem from scratch. And frankly, most
npms are not that hard to replicate in another language.

------
bayesian_horse
I'm not quite into Rust yet, but it is a very candidate for useful webassembly
frameworks/projects. It doesn't need a big run time, but is more expressive
than C/C++.

The big drawback is that, unlike Javascript or Python, there is just no way
I'm going to be able to teach Rust to previously non-technical people. The
learning curve is just too damn hard.

~~~
zozbot123
> The big drawback is that, unlike Javascript or Python, there is just no way
> I'm going to be able to teach Rust to previously non-technical people.

Plenty of "non-technical people" learn to write simple (buggy) programs in C
in a matter of months. And once you know the basics of the C machine model, it
is quite feasible to work up to Rust.

The thing about learning Rust though is that it's not really a mature language
just yet - it's a hell of a moving target! Even Rust+NLL is a very different
animal from Rust w/o NLL, and this goes for so many other features.

~~~
bayesian_horse
You can learn to write buggy Python or Javascript programs in a few days at
most. You can learn to write a web application in Django in a few days or very
few weeks.

Rust has interesting features and an enthusiastic community (though the
extreme down voting of any mild criticisms of Rust here is disappointing). But
again, the learning curve is very flat, meaning you have to learn a whole lot
just to achieve the simplest things. I have taught programming to highly
intelligent non-programmers before. I know the difficulties. They don't have
either the time or the frustration tolerance to argue with the rust compiler.

------
throwawaylolx
Is there any work done towards enabling Rust + WASM without any JS/npm?

~~~
steveklabnik
Wasm requires JS to be loaded by your browser, so it can never fully go away.

Outside the browser it’s a different story, of course.

~~~
fabrice_d
We could add support for <script src="something.wasm"></script> and not need
JS to load it. Once the host bindings are implemented that would be a good
fit.

~~~
steveklabnik
Maybe! There’s not really much demand for such a thing. Web platform people
don’t have the disdain for JS that many internet commenters do.

~~~
josephg
I think this sort of thing is always a bigger deal than it seems. I think most
people are actually really averse to learning new platforms, and things that
enable people to make stuff without having to learn a different platform are
way more popular than I would expect.

Examples: phonegap, electron, unity, love2d, reactnative, and nodejs itself.
(Node = I know web but not native, can you help me write server code without
learning C/python).

Most of this stuff solves the problem of “I want to program on platform X, but
I’m most comfortable in Y. Can someone prevent me from needing to learn X’s
paradigms?”. Arguably that’s one of the biggest draws of wasm itself, and why
the communities around a lot of languages are excited about it. (Eg rust,
blazer). (“Ugh don’t make me learn JavaScript. I already know C# and I like
it. Can I just do that instead?”)

To your point, I think it seems like there’s not much demand for such a thing
because the people it would help aren’t involved enough yet to file issues. If
they’re invested enough in the community and the problem, they’re probably
invested enough to learn enough JS to bridge the languages themself anyway.

Which is all to say, I think making a wasm script tag after host bindings are
in is a good idea and will make a lot more people happy than it would seem if
you just surveyed the existing community.

~~~
steveklabnik
Eh, I think that the few lines of JS it takes to instaniate a wasm module
isn’t a problem even for people who aren’t great at JS. I’m one of those
people, and it’s only a few lines, really. It can even be generated by tools.
It’s just not that big a deal.

~~~
tokyodude
the big deal is not knowing the platform and therefore reproducing it in wasm.
a simple example is most games compling in libjpg, libpng, zlib when the
browser already has that stuff built in.

------
shmerl
Can WebAssembly be used without any JavaScript? Or JavaScript is always
required in some combination with it?

~~~
archgoon
It cannot be used without javascript because it currently has no interface to
the DOM.

Without DOM access, you're simply running a virtual machine isolated from
everything else, and that would serve no purpose aside from burning clock
cycles :).

It is currently felt that Webassembly shouldn't be given access to the DOM
until after a garbage collection interface is created. Until that happens, any
object given to the WASM runtime cannot be safely destroyed, as the browser
doesn't know, and WASM has no way of indicating, that something, such as a
reference to a div element, is still needed.

Currently, the simplest[1] and most secure way of working out how a given
runtime should interface with the browser is to build that compatibility layer
in javascript, and expose callbacks to the WASM runtime(which is defined).
This lets developers write their own DOM-interface shim, allowing them to
explore the possibility space, and not accidentally restrict which languages
can be implemented in WASM.

[1] From the point of view of browser vendors and standards bodies.

~~~
shmerl
Thanks for clarifying the reason behind it!

------
nmca
I used this to write a game playing engine recently, was quite fun. However
the ecosystem is not that developed on the JS side - ran into bundling issues
with both parcel and webpack that were totally mystifying.

[https://github.com/N-McA/parcel-
yavalath/blob/master/README....](https://github.com/N-McA/parcel-
yavalath/blob/master/README.md)

------
InGodsName
Figma uses WASM and some claim that it's even faster than natively implemented
Sketch.

I am surprised that now it's possible to make a web app as fast as native app.

Is Visual Studio Code using WASM?

~~~
solarkraft
> faster than natively implemented

It still depends on your implementation. The same code will take about 1.2x as
long to execute in wasm (of course this means that a slightly faster
implementation can be faster over all).

> Is Visual Studio Code using WASM?

I have read on HN that they use Rust for some internals, but so far I haven't
been able to confirm it. It would make sense for things like intellisense to
be compiled, but don't forget that with Electron you can still access the
platform with all iits capabilities, so you wouldn't need wasm.

~~~
gpm
> I have read on HN that they use Rust for some internals

I know the multi-file search is done via ripgrep, which is written in rust.
But it's not compiled to wasm.

------
OpenBSD-empire
Wouldn't SPARK (and Ada) be better suited for WebAssembly than rust? Because
SPARK is built to be formally provable and Ada being pretty damn safe?

~~~
steveklabnik
I haven’t heard of any implementation. It can’t be better if it doesn’t exist.

------
revskill
The ideal programming language won't let you specify type, the compiler will
detect for you. Why ? Because it's unnesessary for human to waste keystrokes
for something like typing. So, a statically typed language, but act like a
dynamic language is ideal.

