Porting a JavaScript App to WebAssembly with Rust (Part 1)

https://slowtec.de/posts/2019-12-20-porting-javascript-to-rust-part-1.html

by alex_hirner • 7 years ago

116 45 7 years ago

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• 7 years ago

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

austincheney2• 7 years ago

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.

tiborsaas• 7 years ago

I think he might have referred to costly in business sense, because more bugs lead to more developer hours spent.

fnord77• 7 years ago

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.

sammorrowdrums• 7 years ago

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

arusahni• 7 years ago

https://slowtec.de/feed.rss

bobajeff• 7 years ago

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.

Rotten194• 7 years ago

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

Eikon2• 7 years ago

Unfortunately it is, you may want to have a look at: https://krausest.github.io/js-framework-benchmark/current.ht...

Filter for wasm frameworks like “Yew”.

McWobbleston• 7 years ago

There's wasm benchmarks that don't trail much behind vanilla JS, though.

steveklabnik2• 7 years ago

There’s a lot of variance here. See https://ivanceras.github.io/sauron-perf/ too.

New versions of libraries, new optimizations in browsers... the numbers are changing all the time.

stefano• 7 years ago

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• 7 years ago

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

batmansmk2• 7 years ago

Your general approach is correct. Glimmer uses a similar approach, where it compiles templates to bytecode. https://github.com/glimmerjs/glimmer-vm/blob/master/guides/0...

NB: You need to update strings in the DOM outside of the limited context of wasm-forth, so there is still serialization and deserialization involved, or at least string buffer views.

pythux• 7 years ago

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• 7 years ago

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.

e12e• 7 years ago

If they're already on react, and consider moving to rust.. Sounds like reasonml would make more sense?

cerved• 7 years ago

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.

amenod2• 7 years ago

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.

gedy3• 7 years ago

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

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

jorblumesea• 7 years ago

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.

Tade0• 7 years ago

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.

gedy3• 7 years ago

While really cool, this is my big concern about web assembly (in a 'real company' doing boring stuff) - devs using in browser for UI/app stuff and fragmenting simple use cases across their favorite languages.

Love your idea of frameworks leveraging for core parts like vdom though.

maxyme• 7 years ago

I've ported a template compiler to Rust before. The reality is you still end up with something slower than native JS because of the overhead serializing and parsing the JSON in WASM memory. This is something that will be helped by the interface types proposal[0] if it is implemented but I was surprised that this use case didn't work as well as I thought it would.

[0] https://github.com/WebAssembly/interface-types/blob/master/p...

shpongled• 7 years ago

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• 7 years ago

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

batmansmk2• 7 years ago

Both virtual dom and template compilers exist in Rust: Yew for instance uses both to provide a React-like experience: https://github.com/yewstack/yew JSX is easy to implement in Rust due to the fact that macros are first class citizen in Rust.

perceptronas• 7 years ago

I would say that a well designed application is exactly that: multiple libraries working together

pkolaczk2• 7 years ago

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• 7 years ago

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

pkolaczk2• 7 years ago

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.

vmind• 7 years ago

I've found Rust is great for doing heavy lifting (parsing/compiling/graph analysis, etc) on the frontend, as long as you can define the boundary between wasm/JS reasonably cleanly. And in that code I don't think there's a productivity hit as you can benefit a lot from the stricter types (ADT pattern matching, etc) and more reliable performance.

For more straightforward UI code, I'd agree that TypeScript strikes a much better balance right now, especially for (almost) seamlessly working with the wider ecosystem. I moved away from Scala.js because defining the boundary transition was quite error prone, but maybe I was missing something.

crtlaltdel• 7 years ago

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• 7 years ago

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.

Porting a JavaScript App to WebAssembly with Rust (Part 1)

Related Stories