WebAssembly/Rust - and now?


#1

Hi there!
First off: please excuse my english!

I am a frontend-student - with a background in (and a failed career within) the humanities :slight_smile: - and I have just picked up beginners Rust (I love it). As it is now frontend seem not to be as ‘technical’ as backend and other areas of programming… But, when WebAssembly ‘hits off’ won’t that change? HOW will this impact on the frontend scene? Many off us certainly have read that WebAssembly will be a game-changer due the speed of Rust/C++ BUT, HOW? It is easy to see speed the relevance of speed in Online games and ‘heavy’ apps, but otherwise?

I have btw. tried webstd/Rust and find it REALLY cool. REALLY cool.

Greeting,
Claes-Magnus Bernson
cmbernson.se (in swedish)


#2

Webassembly is like 20% faster than Javascript (in some cases even slower + the startup time) and development speed is not very good in Rust. I think Rust should focus on what it was originally intended for and not on web technologies.


#3

I am very ignorent, please excuse… :slight_smile: But I’m confused here. Is it not true that the difference in speed is like from 10

to 800%? I am not sure. If though the original intention was something else, may nog WAsm be a Good thing? This is NOT intended as a rethorical question.

So… Even though you may be right: is not this a Big deal? If not, Why? I lack the knowledge to evaluTe this. Therefore I ask others… :slight_smile:


#4

From my passing familiarity, WebAssembly isn’t that much of a game changer if you’re developing a conventional web application. Some people are pushing to make Rust/C++ first-class citizens by giving them access to DOM manipulation and other web platform features, but in my opinion this is more about language preference or portability than performance, though it is easy to write unperformant JavaScript and the nature of Rust and C++ make it more difficult to write inefficient code accidentally.

The key benefit of WebAssembly will be to enable new experiences that weren’t possible on the web before. WebAssembly is necessary for applications that:

  • Need predictable performance
  • Want to tightly control their memory usage and layout
  • Really need the extra performance you get from a typical “systems” language
  • Need to tap into existing code written in C/C++/etc.

So games, VR, scientific computing, etc. It can also be useful to offload more computationally intensive algorithms in your existing web application (e.g. https://hacks.mozilla.org/2018/01/oxidizing-source-maps-with-rust-and-webassembly/), once you’ve identified those bottlenecks.


#5

Hi Andrew!

Big thanks for this answer, you sharing insights and this link - thank you!

For me, WebAssembly/Rust is never the less very exciting - especially from a motivering perspective: I love JS and the web but I also find Rust interesting. With webstd you can achieve an interface you are familiar with… If you like me is a beginner and ’spoiled’ with the blessings of the web this helps out :wink: But I get your point! :slight_smile:

Thank you, as well as the previous author.

Greetings, Claes-Magnus


#6

For me, WebASM means no more JavaScript. I know I’m not alone when I say it’s not my favorite language to work with. Currently, I use Elm compiled to JS. It’s nice, but I still need to deal with JS tooling like NPM. I imagine WebASM would help alleviate the dependency web frontend has on JavaScript’s tooling.

There’s a reason so many transpile-to-js languages exist: it’s because JavaScript is treated like bytecode even when it’s illogical/inefficient to do so. WebASM is just filling the gap that modern web devs found.

To be completely honest, I predict one of the top use cases for WebASM isn’t speed, but because devs wish to use something other than JavaScript.

I think Rust should focus on what it was originally intended for

I disagree. Rust is an incredibly powerful language with great resources. How is web different than terminal applications or desktop GUI apps? Why not take full advantage of available backends? There’s certainly a big enough community to maintain it.


#7

When you execute code in the web browser you are in a sandboxed environment which renders Rusts memory safety guarantees irrelevant and leaves you with an overcomplicated language for this purpose.

When your code runs on bare metal, passing pointers around, using ugly things like conversion to network byte order and sockets Rusts safe interfaces are FUCKING GOLD.


#8

One selling point: Ever wanted to export some data as a zip file from a web app? Import a zip compressor compiled to WASM and you can. It’s technically possible to write stuff like this in JS (and people have), but it’s easier in a language like Rust.

Rust was originally intended to write a browser. Does that count as web technology?


#9

Perfect, almost scientific approach. Take one word out of several posts ignoring the actual content and then drop a totally irrelevant line about that word combined with a rhetorical question.

The only thing the rust lang start page says is that it is a safer system programming language. This concept is orthogonal to anything that should run in a web browser because the precise defintion of a system programming language is that it is a language which should be used to provide the required infrastructure and platform for other programs to execute on (e.g. a web browser engine). The problems that are tackled by the rust language are totally irrelevant in the context of webasm. You might as well compile Fortran code to webasm, it doesn’t make difference. On the other hand there is no way to execute some SYSTEM calls in idiomatic rust with a SAFE interface, which could be considered a pressing issue for a language which claims to be a SAFE SYSTEM programming language. Given the fact that this language and its infrastructure are not excessively funded by multi billion dollar companies it would be a good idea to focus on the core.


#10

Sorry, didn’t mean to offend you or discredit what you wrote with a tongue-in-cheek comment. You seem very invested in this, and I appreciate that.

This is not a zero sum game, though: Great support for WASM requires similar optimizations than great support for embedded platforms, for example. And the people interested in working on WASM are probably not the same people who would otherwise write abstractions for handling specific system calls. You don’t necessarily have to choose one area over the other, and I actually believe we are in a position where we can improve the status quo in a whole bunch of areas.


#11

While Rust is great when it comes to memory safety, it’s not the sole reason I use it. I use Rust because I like the overall design of the language. It’s fair game to call it overcomplicated, but let’s also remember not everyone feels the same way. I often find programs I create in “simpler” languages more complex because of hacks, quirks, and poor design choices.


#12

True, languages like C are so simple that the lack of proper abstraction can become very painful. But for the purpose of web development rust certainly is too complicated. There is a reason why languages like python are so successful in many different disciplines of science and haskell is only being taught in computer science classes :smiley: In their daily life people think in terms of procedures and temporal causality and not in abstract mappings.


#13

I agree with @doomy. What I’m most looking forward to is to no longer use Javascript. Javascript’s lack of static typing makes it difficult to use the right abstractions and necessitates a lot defensive coding. I think type safety is a huge deal.

However, type safety is an even greater deal when you can write both your front and back-ends in Rust. If your back-end exposed a type Fn(userId) -> Future<User>, that type could be re-used on the front-end, and a function could be auto-generated via macro for use on the front-end that made that request. That’s two classes of bugs that we’ve eliminated right there (404s and malformed responses).

Add in an abundant use of macros, and I think full stack Rust web dev can be faster, easier and safer than web dev in any other language.


#14

Sounds very painful. Again, there is a reason why even companies like Facebook use PHP (optimized but still more or less normal PHP with type annotations) instead of low level languages.


#15

Heh, yup, the learning curve is real. But a broken website where everyone is scrambling to figure out what went wrong is also painful :slight_smile: It all depends on your priorities!


#16

It’s not only the learning curve. Putting together some pieces of logic in a PHP script and optimizing it later is usually much faster (in terms of dev speed) and serves the purpose. It’s just like saying it would be great to do text manipulation in Rust instead of doing it in Perl. If you have a startup and you use Rust to serve simple webcontent you are most certainly going to be out of the market, wasting the momentum you could use to become relevant. Obviously all this stuff has to be done because Mozilla has different priorities, but trying to convince people that doing stuff in wasm and serving the equivalent of 7000 lines of runtime in a compressed form to print “Hello World” is just ridiculous.


#17

Those interested in a taste of what Rust can do via Wasm should check out the unrust game engine.


#18

Is there a plan to integrate stdweb and yew with wasm-bindgen or will these be separate efforts?


#19

Regarding JS speed, I just want to highlight some points:

  • Most apps on the web don’t need the performance afforded by modern JavaScript engines, let alone WASM.
  • Years of effort on V8 and SpiderMonkey and friends means that JavaScript is pretty damn fast.
  • Rust has a runtime, and it can’t leverage JS builtins. Rust’s runtime is small, but the need to bring your own strings, hash tables, vectors, etc. can quickly lead to tons of “bloat” compared to JavaScript, because all that stuff is already in the browser.
  • At the moment you still have to talk to JavaScript to manipulate the DOM, and that bridge is really slow.

And also some points in favor of using Rust + WASM:

  • ADTs and traits make Rust much more pleasant to work with than current web languages (Elm and Reason still don’t have ad-hoc polymorphism, which is frustrating.)
  • Rust would let you avoid the hellscape that is NPM - Cargo is just better in every way.
  • You’d get to leverage existing C libraries for lots of functionality.

#20

I suppose this has kind of been covered by doomy’s answer, but one major benefit of WebAssembly in general (but also for Rust) is that it gives people the choice to write in languages other than JavaScript. I don’t think that’s something that needs to be defended with use cases - programmers should be able to use the languages they want to.

I think most people would agree that the web, arguably the biggest software platform that exists, should not be restricted to one language. It makes a lot of sense to provide something efficient and low-level to build on.