
Our Vision for Rust and WebAssembly - JoshTriplett
https://rustwasm.github.io/2018/06/25/vision-for-rust-and-wasm.html
======
rl3
> _So we are writing The Rust and WebAssembly Book._

Awesome! What's there already is looking good. I wonder if it'll turn into an
actual paper book some day like the second edition of TRPL did. [0]

On that note, my copy just shipped today (or at least received a tracking
number), so get yours now! __*

Alternatively TRPL is also free[1] of course, and there's a somewhat outdated
PDF version[2] available. If you're motivated, you can just use that person's
scripts to generate an updated copy probably. The advantage of those is that
the online and unofficial PDF versions have colorized syntax; the _no starch
press_ edition does not last I checked. However, there's no reason not to buy
it anyways if you're able. Personally nothing beats paper.

[0] [https://nostarch.com/Rust](https://nostarch.com/Rust)

[1] [https://doc.rust-lang.org/book/](https://doc.rust-lang.org/book/)

[2] [https://github.com/lise-henry/books](https://github.com/lise-henry/books)

 __* = No conflict of interest exists here, Steve is just really nice to me on
HN and I love Rust. :)

~~~
steveklabnik
> my copy just shipped today

Hooray! I got to actually hold one last week, it was... wonderful. I am biased
though :p

~~~
ranit
The linked nostarch page shows only 13 of 20 chapters as (AVAILABLE NOW). How
is the printed book finished already?

~~~
steveklabnik
They just didn’t do the final upload; the text was finalized like six weeks
ago. The idea was to do it at the same time the physical books shipped. If
it’s not already fixed, should be done very soon. I’ve had the PDF in my inbox
for a few weeks.

------
jillesvangurp
IMHO things like WASM, web vr, and LLVM are all converging this year after
years of cool demos, prototypes and gradual progress. Having Rust out there as
a first class citizen is awesome. This year we should see the beginning of a
minor revolution in front end development, where essentially anything
targeting LLVM will be able to compile to WASM, be bundled as an NPM, and be
usable in the context of web application for essentially anything done in
javascript until now whether it is performance critical algorithms,
manipulating the dom, writing to canvas, driving IO via web sockets, dealing
with web gl and web vr, audio, etc.

Breaking the monopoly Javascript has had on this space for close to 25 years
is a good thing. Perhaps people will continue to use it but it will have to be
on merits rather than just merely being the only game in town. In any case
looking forward to having more choice in this space.

IMHO, modern JS based frontend development is a combination of tedious, error
prone, and backwards. If this honestly is the state of the art, then WTF.
happened in the past 20 years.

~~~
grey-area
There is one huge change here (as compared to things like the golang wasm
port) which makes this more likely to be adopted IMO:

 _Rust compiled to WebAssembly doesn’t have a runtime. This results in small
.wasm binary sizes that are proportional to the amount of Rust code that is
being compiled to WebAssembly. Binary size is of huge importance since the
.wasm must be downloaded over the network. The proportionality means you only
pay (in code size) for what you use. In turn, that means it is feasible for
existing JavaScript code bases to incrementally and partially adopt Rust._

Great to hear they're taking this approach. I do think it'd be nice to have
DOM access too though, as then you won't need JS at all - I do think _long
term_ the attraction of this is to replace JS as a front-end language, not
just augment it, but it's nice they're taking an incremental approach.

~~~
steveklabnik
wasm-bindgen is forward compatible with the host bindings proposal, so once
that lands, the DOM stuff will Just Work.

~~~
crudbug
Waiting for this !

------
anderspitman
> _In the most performance-sensitive contexts, JavaScript hinders rather than
> helps. Its dynamic type system and non-deterministic garbage collection
> pauses get in the way. Seemingly small code changes can result in drastic
> performance regressions if you accidentally wander off the JIT’s happy
> path._

I'm seeing this repeated more and more as a compelling case for using WASM.
I've even repeated it myself. Does anyone know of examples of JS optimized for
one VM not performing well in others, leading to a significant cost? I ask
this as a Rust/WASM fanboy. Not doubting; just curious. I feel like I've
already read a couple anecdotes but can't remember.

~~~
littlestymaar
I haven't done any performance-critical JavaScript for two years now and I
know a lot a things have change with Turbofan, but I had been hitting slow
paths of V8 so many times … The easiest to avoid were also the most painful
when it comes to code organization : exception handling was so slow it was
unusable. And it was affecting our ability to use modern JS, because the
polyfil for `for of` or `async/await` had to use exception to comply with the
spec. As a result we were stuck using ES5.1 for a really long time (because we
needed to support mobile browsers, which are (or were at this point, at least)
a new kind of IE6.

------
kalessin
I would love to do frontend web development but the current high-churn
Javascript ecosystem makes me dizzy; this is probably a naive question but
will it be possible to do web-development without integrating in the
Javascript ecosystem using WebAssembly and Rust someday?

~~~
stupidcar
Eventually there will be direct binding between WebAssembly and web APIs like
that the DOM that will allow you to write performant web apps that circumvent
JS entirely. There are already tools that
[https://webassembly.studio/](https://webassembly.studio/) that making writing
wasm-based apps a reality, albeit still with a binding layer that goes through
JS.

However, such applications will still have the same constraints that drive the
current JS ecosystem. As such, there's little reason to believe that
frameworks like React, Angular, Vue.js, etc. won't have their wasm-based
equivalents. And, if anything, I except _more_ churn for quite a few years, as
people use the freedom provided by wasm to build a new generation of
frameworks in completely different languages. We may look back on the current
era of web development as a relatively stable one compared to what's to come.

So if the current churn is what turns you off web development, I wouldn't bet
on wasm being a salve.

~~~
tenaciousDaniel
Oh wow, I didn't realize that wasm did _not_ currently have any direct
bindings to the DOM. How does it interact with the page then? I saw a demo
where they ported UE4 - how does something like that work without DOM access?

~~~
steveklabnik
It calls to JavaScript which manipulates the DOM for it.

------
majewsky
> publish Rust code compiled to WASM on NPM

leftpad-rs.js? :)

~~~
fleetfox
Assuming you get better performance and less size something like lodash-rs
would have been nice.

