
Porting a JavaScript App to WebAssembly with Rust (Part 1) - alex_hirner
https://slowtec.de/posts/2019-12-20-porting-javascript-to-rust-part-1.html
======
cerved
While it's just part one, I feel like whether the end result successfully
overcomes the problems mentioned is missing. I wonder if in fact it does.

Personally I wouldn't refactor an entire application from scratch unless it
was fairly simple. Instead I prefer incremental refactoring and I've found
that typescript can be helpful in that regard.

~~~
amenod
Also, while Rust does bring additional guarantees to the table, I wonder if
they are really the ones that matter (much) in web dev.

Having a strongly typed language is a bonus, but a) there is TypeScript and b)
the maintainability nightmares I have encountered had nothing to do with the
language itself, but more with core programming principles like separation of
concerns, state management (well, I'll admit that existance of MobX doesn't
help there...) and similar.

So I don't buy the motivation, but it's still interesting to see what can be
done in Rust.

~~~
gedy
> well, I'll admit that existance of MobX doesn't help there...

'Doesn't' or 'does'? We've found MobX to really help.

~~~
amenod
Doesn't, imho of course. MobX makes creating and using global variables way
too easy. One of the more nightmarish legacy projects included hunting down
the culprit that sometimes changed some variable in mobx store. Abysmall
tooling (compared to Redux) doesn't help either.

Currently my go-to store is Redux Toolkit [0]. Explicit store management, but
much less verbose than regular Redux. Also, initial state, actions and
reducers are all defined in one place (slice).

[0] [https://redux-toolkit.js.org/](https://redux-toolkit.js.org/)

~~~
gedy
Thanks, enabling strict mode (requires observable change through an @action
only) helps imo.

------
pythux
Interesting take, but there is no indication that the new Rust-based stack
will be « less expensive » to maintain than the current one. I am curious to
see the next posts in the series. I would also like to know if they considered
other alternatives; they mention Elm, what about TypeScript. The issues they
mention seem to also have to do with the specific choice of frameworks or
tools: React, Webpack, etc. Not so much with JavaScript itself?

~~~
baron816
Could be less expensive if the devs expected to work on it were highly
experienced in Rust, but not experienced with JS, which sounds more like the
case.

------
Tade0
While I love Rust, I don't think this here is a good use case for it -
TypeScript nowadays works really well with JSX and can be introduced
incrementally.

Rust's guarantees work best in a highly concurrent setting - a web app isn't
really one.

Rust shines not on the application level, but on the framework/library level,
where things like memory usage and performance are critical.

A framework with virtual DOM written entirely in Rust would go a long way.
Same with a template compiler.

~~~
shpongled
I use Rust all the time, where 90% of what I write is on the application
level, and 5% is concurrent. I just like the language.

~~~
eggsmediumrare
Enjoying the language you're using is as important as pretty much anything
else.

------
Rotten194
I thought DOM manipulation from WASM was pretty expensive because it needs to
be bridged through JS -- is that still true?

~~~
stefano
You still need to go call into Javascript to do any kind of DOM manipulation.
The solution I used for wasm-forth (a forth implementation targeting wasm), is
to have a js "interpreter", implemented as a single function, that executes a
sequence of DOM manipulation instructions, represented as an array of
integers. On the forth side, the instructions are generated by a virtual DOM
library: as the virtual DOMs are diffed, instead of manipulating the DOM
directly it generates a sequence of opcodes to send in one go to the
Javascript interpreter.

The cost of the Javascript bridge is minimal: it's a single function call to
render or update a whole page, and there is no serialization/deserialization
involved since both languages can understand arrays of integers natively.

~~~
lytedev
This is a really neat idea! Was there an inspiration for this? I think
something like this could be very useful!

~~~
ec109685
That’s basically what ReactNative does.

------
fnord77
> In the next series we'll see how to translate the legacy JavaScript code to
> working Rust code.

this is the part I came to see.

------
crtlaltdel
[https://www.youtube.com/watch?v=kY-
pUxKQMUE](https://www.youtube.com/watch?v=kY-pUxKQMUE)

seriously though, i’ve been very interested to see how webassembly adoption
goes. does anyone have examples of new projects implemented in webassembly?
i’ve seen lots of examples of ports, but am more curious about its use in
product development.

------
mattlondon
Sounds like typescript and angular would be a better fit here.

Angular is "batteries included" compared to react, so you generally won't hit
the same dependency hell since angular comes with pretty much everything you
need (although not redux pattern support (yet)). Typescript is a strictly-
typed JavaScript.

Reprogramming a web front end in rust sounds like a way to lead to huge
maintenance issues in the future (i.e. you need to find developers who know
rust AND how frontends and things like redux actually work - you'll probably
get someone who is good at one, and half-assed at the other). I am also
uncertain how you'd debug things in the browser for wasm - e.g. would the
redux Dev tools work?

Where I see wasm as useful is if you are doing any heavy-lifting in the
browser - so all the examples they give on the various web sites about games
and cryptography etc, but probably also parsing/serialisation of binary data
from the server for example. I don't feel like basic SPA stuff is a good fit.

------
bobajeff
This is cool. I'll be paying attention to this. If for no other reason than to
see what it's like porting from one language to another.

------
pkolaczk
While Rust is a very cool technology, I don't think it is the best tool for
web development. Manual memory management and constant thinking about
ownership and memory sharing is additional productivity overhead, and you
don't gain anything from it because the final code is running in a GCed
runtime anyways.

I'd use TypeScript or Scala.js.

~~~
djur
WebAssembly code has to do its own memory management anyway. You don't get the
benefits of the JavaScript GC.

~~~
pkolaczk
I didn't say you got benefits of JS GC nor lack of JS GC. And that's the
point: you don't get benefits, but you pay the price in lower productivity.
Rust is a pleasant language to write in, but it is nowhere as expressive and
fast to develop in as TypeScript, Scala or even Kotlin.

------
sammorrowdrums
Did anyone find a subscribe link? I'm curious to see how this progresses.

~~~
arusahni
[https://slowtec.de/feed.rss](https://slowtec.de/feed.rss)

------
jorblumesea
This seems like a solution looking for a problem but cool to see. A far more
practical suggestion would be to just use typescript and incrementally
rewrite.

------
austincheney
> Maintaining Software that is written in a dynamically typed language like
> JavaScript is costly. Maintaining a JavaScript frontend that is build with
> React, NPM, WebPack and Babel is even more expensive.

Not exactly. In modern browsers JavaScript executes in a VM. If the JavaScript
instance is written in a strongly typed way it executes quickly by receiving
the full benefits of a compiled language. Aside from arithmetic it executes
almost as fast as Java. That is one of the strengths of TypeScript.

I do completely agree about NPM, dependency overkill, and framework insanity.

In short, don’t blame the language for being slow. Blame marketing and bad
developers. That being said I have little faith that WASM will be fast once it
meets the reality of bad developers and marketing teams.

~~~
jlelse
I think that quote isn't about JS performance but maintaining software written
in JS.

~~~
austincheney
Again, that goes to the quality of product/people in a given instance. I have
done this long enough to fully appreciate that when it comes to fucking up
software on the web people will find a way whether it’s for some poorly
conceived developer motivation or media/marketing motivation.

~~~
bsaul
i think the original post just mentionned « costly ». It didn’t say it was
impossible to mess things up even with rust. Just that it removes the cost of
checking types are still matching after a refactoring or a dependency update.

~~~
rienbdj
This a true, but the advantage is probably more than offset by the relative
cost of JS vs Rust developers. You can also add Flow types.

A single threaded environment does not yield the usual advantages of the Rust
borrow checker.

~~~
zozbot234
> the relative cost of JS vs Rust developers

I.e. pay peanuts, get code monkeys?

> A single threaded environment does not yield the usual advantages of the
> Rust borrow checker.

This is quite wrong - reference invalidation and async code that's being
scheduled within a single thread are two common examples where it matters a
lot.

~~~
Eikon
Lots of boilerplate and error-prone code can also be avoided by implementing
`drop` on relevant types, this can yield to pretty interesting APIs in the web
space.

