8 ms·

The promise of Rust is safe and fast low-level development. What is the primary selling point of using rust for webdev? Speed? I can mainly see disadvantages wh

The promise of Rust is safe and fast low-level development. What is the primary selling point of using rust for webdev? Speed? I can mainly see disadvantages when using rust for this scenario.

kolektiv 6y ago
Well, that's definitely a sweet-spot, but as a by-product of that, Rust is still a well-thought through language with a strong and logical type system, some very useful features for expressing domain models, etc. and a model of memory management which maps very well to WASM. So if you already know Rust, this is a short and logical step. If you don't already know Rust, I wouldn't learn it just to write web apps in - but if you do, you now have all the advantages of "same language client/server side" as well as the advantages of safety, good libraries in certain spaces, etc.
- Vinnl 6y ago
  > I wouldn't learn it just to write web apps in I'm going to be looking into the other way around: writing a web app in it to learn it. Seems like a great use case that would make it easier for me to learn, as someone who has experience with web apps and not so much with desktop software.
skocznymroczny 6y ago
Possibility of sharing code between backend and frontend.
- hinkley 6y ago
  Yes. Isomorphic code was always about having to prove the correctness of a smaller body of code. Web assembly will see a whole new round of people trying to do monoglot programming. Which I welcome, because I like JavaScript well enough but I don’t like writing it all day, every day, for years at a time.
danShumway 6y ago
A few advantages: - Rust compiles to WASM, not JS, so you can actually take advantage of its low-level nature in the browser for performance critical tasks within your app. - The Rust code you're writing is still statically compiled, so you still get to take advantage of Rust's typechecking and IDE features. - Some people just like writing Rust code more than Javascript. Part of the reason Javascript took off so quickly on the server was because there's a huge productivity boost from using one language everywhere. Similarly, if you love Rust but think that Javascript paradigms around prototypes, closures, or `this` are weird, you get to ignore that and take advantage of one of the best app distribution platforms in the world without learning a new language. I pretty solidly hold to the position that increasing language diversity on the web is a good thing. Particularly with Rust, since they've put in the work to have proper, accessible support that's still separating app logic from DOM layout and CSS styling. I'm really happy with how their community has approached building out Rust as a first-class language on the web rather than just as native language that happens to have a web compile target.
- muglug 6y ago
  > you can actually take advantage of its low-level nature in the browser for performance critical tasks within your app. Yeah, but the problem is that 99.9% of front-end work is only performance-critical for DOM rendering (the 0.1% is stuff like video encoding & decoding) and WASM can't help with that.
  - cogman10 6y ago
    > the 0.1% is stuff like video encoding & decoding In which case, rust still isn't a good fit for a front end library (Unless you are patching in support for a new codec into old browser). Frankly, the browser will have a faster version of the codec that can also take advantage of other hardware that you wouldn't want to expose to WASM.
  - brundolf 6y ago
    > 99.9% of front-end work is only performance-critical for DOM rendering There are two meanings of "DOM rendering" in the context of UI-as-a-function-of-state libraries: 1) generating the virtual DOM from data, and 2) modifying the real DOM to match it. Arguably there's even a 3) browser reflow as a result of those DOM changes. You're right that 2 and 3 can't really be helped by WASM. But 1 can, and while it's not usually the bottleneck, it certainly can be. At my last company it was not terribly uncommon that fixing UI jank came down to eliminating unnecessary React render function calls because the sum total of them all - running the actual JavaScript logic - was taking too long. Assuming yew computes the virtual DOM in WASM (I don't see how it could be otherwise), the performance increase could definitely be beneficial for certain highly-complex apps.
gavinray 6y ago
> Speed? As surprising as it might sound -- not really. There's a small-but-non-trivial amount of overhead involved in calls between WASM code and the DOM API's, plus (de)serialization. It's more of a familiarity/existing tooling thing. Same as Blazor in C# writing web apps in that. If your entire team only knows C# and you have all your existing tooling there then it could seem an appealing option. But there's also the argument for more stringent safety with Rust compared to IE, Typescript.
- danShumway 6y ago
  > There's a small-but-non-trivial amount of overhead involved in calls between WASM code and the DOM API's, plus (de)serialization My understanding is that this is going to get a lot better in the future though -- last I checked the plan was for WASM to eventually have direct bindings to DOM APIs, at which point you won't need to interact with JS at all.
  - gavinray 6y ago
    That's true, if the Interface Types proposal gets accepted that overhead should be significantly less. At that point it'll get really interesting what the potential performance looks like for DOM-interaction heavy apps. https://github.com/WebAssembly/interface-types/blob/master/proposals/interface-types/Explainer.md https://github.com/WebAssembly/interface-types/blob/master/p... I wouldn't think it's far behind. The Multi-Value proposal, which had huge ramifications, was recently accepted in April so WASM is clipping along at a fair pace still. https://hacks.mozilla.org/2019/11/multi-value-all-the-wasm/ https://hacks.mozilla.org/2019/11/multi-value-all-the-wasm/
    - markdog12 6y ago
      Firefox Nightly and Chrome Canary both recently landed multi-value and reference types: https://webassembly.org/roadmap/ https://webassembly.org/roadmap/
- dom96 6y ago
  I was very surprised to find this. I have done some WASM experiments and found that JS is very often incredibly well optimised, often running faster than WASM. Do not underestimate the years of JIT optimisations that went into V8 and other JS engines.
paulgb 6y ago
Although Rust is most known for bringing safety to low-level development, it also happens to be a nice, modern programming language with things like match statements and sum types. I find myself using it frequently for things I used to do in Python, with greater productivity once a program reaches the point that I can't keep it all in my head.
the_gipsy 6y ago
A fast webapp is a selling point on it's own. Of course, maybe just because it uses WASM it doesn't automatically have to be faster - but this looks promising.
stmw 6y ago
I don't think Rust is just for low-level development anymore, for example at Commure we have been using it very successfully for "enterprise app". So if you're already using Rust for the app backend, I think the interest is more about using the same language in the back and in the front. Since nowadays one usually wants a typed Javascript (e.g. Typescript) anyway, it is far shorter of a leap to Rust.
nilkn 6y ago
It's the reverse of what happened with JavaScript. In other words, JavaScript started on the front-end and then spread to the back-end because it was advantageous to have one language for both. One of those advantages is that folks who were experts in JavaScript were suddenly able to use their language of choice for back-end work too. Rust started on the back-end but is fairly likely to spread to the front-end in the future for the same reason. One of the advantages will again be that folks who are experts in Rust will be able to use their language of choice for front-end work too. Beyond this, I would argue that Rust's type system is a significant draw for many folks as well. I dare say it has a lot more potential than Elm, a Haskell-like language designed just for web development.
k__ 6y ago
Predictability? As far as I know, Rust's WASM performance is much more uniform than JS'.
pmarcelll 6y ago
I haven't seen it mentioned, but memory usage might also be better, and I have a good real-world example to show why it still matters in 2020: we use Jira to manage our software projects and our team's project manager uses a newish MacBook Air with 8GB of RAM. Jira is written in React and a single page for a ticket can easily eat 150+ MB of memory (it's even more for Jira boards). Our PM regularly complains about the slowness of his machine and I think Jira is a big contributing factor. I don't think much of the memory is used for presentation (so it might not be React's fault), but rather for business logic processing a large amount of data. And IIRC calling a simple `filter()` on a JS array creates a new array for the operation while Rust uses iterators.
- akiselev 6y ago
  I regularly slow to a crawl on a 32gb Mac Book Pro requiring a reboot because it starts swapping thanks to Chrome tabs, electron apps/VSCode, and webpack/cargo/whatever to the point that running cat on a file takes 5-10 seconds. All it takes is a little memory exhaustion for the kernel to pick a process for swap (iterm and its children? why, thank you kernel!) and drive it into the ground. With Chrome it might swap just a single tab process or it might swap the rendering process I don't know why it seems React apps are some of the worst offenders, but I think it has to do with hooks injecting context components everywhere (at least that's what it looked like last time I popped open React dev tools). I'm guessing that out of tree state tracking is particularly memory intensive.
jillesvangurp 6y ago
Type safety is the key selling point here. Rock solid behavior for asynchronous and concurrent behavior is another one. Both could be considered weaknesses for Javascript. I agree it's a bit too far out for a lot of javascript/typescript developers. But then the Rust community has a lot of former full stack refugees joining it. My observation is that "full stack development" using javascript is a phase developers go through before upgrading to some other language. You see similar patterns in the Go community. Both communities have lots of people who used to do lots of web and node.js development. My money is more on languages like Kotlin, C#, and Swift crossing over to the browser. Both already have wasm compilers that are still need a lot of work. This work only kicked off for Kotlin fairly recently. Kotlin also has a decent javascript transpiler that you can use right now. Both Swift and Kotlin are very popular for mobile UI development. C# has been used extensieley for Desktop and web server development. Obviously these languages come with lots of features that make them very suitable and popular for exactly the kind of stuff people use Javascript (and Typescript) for. I haven't done much with Swift and C# but Kotlin is great for this. Most of my experience with that language is server side but I have done a few things with kotlin-js as well as some Android stuff. As of a few months ago, the kotlin-js tooling is getting to the point where it's a very solid choice. It builds, it eliminated dead code, it runs webpack for you, etc. The upcoming version (1.4.0) is currently available as a release candidate and includes something called Dukat. Dukat generates kotlin type headers from typescript type headers for npm dependencies. So that means you can integrate a lot of existing npms if you have to. Also the build tools integrate with webpack and you can target both the node.js ecosystem and the browser ecosystem. Most of the bottlnecks for adopting either transpilers or wasm compilers in this space is the relative immaturity (or lack off) mature alternatives to popular javascript frameworks. You can do react apps in a bunch of languages now but it just feels wrong to do it. The pattern you see in other language communities is that they pretty much start rolling their own alternative frameworks. In any case, the amount of third party code making it to a browser is typically not that much for most webapps. For all it's popularity, the react run-time code is not that large. A few hundred KB is considered a lot.

The promise of Rust is safe and fast low-level development. What is the primary selling point of using rust for webdev? Speed? I can mainly see disadvantages when using rust for this scenario.

kolektiv 6y ago

Well, that's definitely a sweet-spot, but as a by-product of that, Rust is still a well-thought through language with a strong and logical type system, some very useful features for expressing domain models, etc. and a model of memory management which maps very well to WASM. So if you already know Rust, this is a short and logical step. If you don't already know Rust, I wouldn't learn it just to write web apps in - but if you do, you now have all the advantages of "same language client/server side" as well as the advantages of safety, good libraries in certain spaces, etc.

Vinnl 6y ago
> I wouldn't learn it just to write web apps in I'm going to be looking into the other way around: writing a web app in it to learn it. Seems like a great use case that would make it easier for me to learn, as someone who has experience with web apps and not so much with desktop software.

skocznymroczny 6y ago

Possibility of sharing code between backend and frontend.

hinkley 6y ago
Yes. Isomorphic code was always about having to prove the correctness of a smaller body of code. Web assembly will see a whole new round of people trying to do monoglot programming. Which I welcome, because I like JavaScript well enough but I don’t like writing it all day, every day, for years at a time.

danShumway 6y ago

A few advantages: - Rust compiles to WASM, not JS, so you can actually take advantage of its low-level nature in the browser for performance critical tasks within your app. - The Rust code you're writing is still statically compiled, so you still get to take advantage of Rust's typechecking and IDE features. - Some people just like writing Rust code more than Javascript. Part of the reason Javascript took off so quickly on the server was because there's a huge productivity boost from using one language everywhere. Similarly, if you love Rust but think that Javascript paradigms around prototypes, closures, or `this` are weird, you get to ignore that and take advantage of one of the best app distribution platforms in the world without learning a new language. I pretty solidly hold to the position that increasing language diversity on the web is a good thing. Particularly with Rust, since they've put in the work to have proper, accessible support that's still separating app logic from DOM layout and CSS styling. I'm really happy with how their community has approached building out Rust as a first-class language on the web rather than just as native language that happens to have a web compile target.

muglug 6y ago
> you can actually take advantage of its low-level nature in the browser for performance critical tasks within your app. Yeah, but the problem is that 99.9% of front-end work is only performance-critical for DOM rendering (the 0.1% is stuff like video encoding & decoding) and WASM can't help with that.
- cogman10 6y ago
  > the 0.1% is stuff like video encoding & decoding In which case, rust still isn't a good fit for a front end library (Unless you are patching in support for a new codec into old browser). Frankly, the browser will have a faster version of the codec that can also take advantage of other hardware that you wouldn't want to expose to WASM.
- brundolf 6y ago
  > 99.9% of front-end work is only performance-critical for DOM rendering There are two meanings of "DOM rendering" in the context of UI-as-a-function-of-state libraries: 1) generating the virtual DOM from data, and 2) modifying the real DOM to match it. Arguably there's even a 3) browser reflow as a result of those DOM changes. You're right that 2 and 3 can't really be helped by WASM. But 1 can, and while it's not usually the bottleneck, it certainly can be. At my last company it was not terribly uncommon that fixing UI jank came down to eliminating unnecessary React render function calls because the sum total of them all - running the actual JavaScript logic - was taking too long. Assuming yew computes the virtual DOM in WASM (I don't see how it could be otherwise), the performance increase could definitely be beneficial for certain highly-complex apps.

gavinray 6y ago

> Speed? As surprising as it might sound -- not really. There's a small-but-non-trivial amount of overhead involved in calls between WASM code and the DOM API's, plus (de)serialization. It's more of a familiarity/existing tooling thing. Same as Blazor in C# writing web apps in that. If your entire team only knows C# and you have all your existing tooling there then it could seem an appealing option. But there's also the argument for more stringent safety with Rust compared to IE, Typescript.

danShumway 6y ago
> There's a small-but-non-trivial amount of overhead involved in calls between WASM code and the DOM API's, plus (de)serialization My understanding is that this is going to get a lot better in the future though -- last I checked the plan was for WASM to eventually have direct bindings to DOM APIs, at which point you won't need to interact with JS at all.
- gavinray 6y ago
  That's true, if the Interface Types proposal gets accepted that overhead should be significantly less. At that point it'll get really interesting what the potential performance looks like for DOM-interaction heavy apps. https://github.com/WebAssembly/interface-types/blob/master/proposals/interface-types/Explainer.md https://github.com/WebAssembly/interface-types/blob/master/p... I wouldn't think it's far behind. The Multi-Value proposal, which had huge ramifications, was recently accepted in April so WASM is clipping along at a fair pace still. https://hacks.mozilla.org/2019/11/multi-value-all-the-wasm/ https://hacks.mozilla.org/2019/11/multi-value-all-the-wasm/
  - markdog12 6y ago
    Firefox Nightly and Chrome Canary both recently landed multi-value and reference types: https://webassembly.org/roadmap/ https://webassembly.org/roadmap/
dom96 6y ago
I was very surprised to find this. I have done some WASM experiments and found that JS is very often incredibly well optimised, often running faster than WASM. Do not underestimate the years of JIT optimisations that went into V8 and other JS engines.

paulgb 6y ago

Although Rust is most known for bringing safety to low-level development, it also happens to be a nice, modern programming language with things like match statements and sum types. I find myself using it frequently for things I used to do in Python, with greater productivity once a program reaches the point that I can't keep it all in my head.

the_gipsy 6y ago

A fast webapp is a selling point on it's own. Of course, maybe just because it uses WASM it doesn't automatically have to be faster - but this looks promising.

stmw 6y ago

I don't think Rust is just for low-level development anymore, for example at Commure we have been using it very successfully for "enterprise app". So if you're already using Rust for the app backend, I think the interest is more about using the same language in the back and in the front. Since nowadays one usually wants a typed Javascript (e.g. Typescript) anyway, it is far shorter of a leap to Rust.

nilkn 6y ago

It's the reverse of what happened with JavaScript. In other words, JavaScript started on the front-end and then spread to the back-end because it was advantageous to have one language for both. One of those advantages is that folks who were experts in JavaScript were suddenly able to use their language of choice for back-end work too. Rust started on the back-end but is fairly likely to spread to the front-end in the future for the same reason. One of the advantages will again be that folks who are experts in Rust will be able to use their language of choice for front-end work too. Beyond this, I would argue that Rust's type system is a significant draw for many folks as well. I dare say it has a lot more potential than Elm, a Haskell-like language designed just for web development.

k__ 6y ago

Predictability? As far as I know, Rust's WASM performance is much more uniform than JS'.

pmarcelll 6y ago

I haven't seen it mentioned, but memory usage might also be better, and I have a good real-world example to show why it still matters in 2020: we use Jira to manage our software projects and our team's project manager uses a newish MacBook Air with 8GB of RAM. Jira is written in React and a single page for a ticket can easily eat 150+ MB of memory (it's even more for Jira boards). Our PM regularly complains about the slowness of his machine and I think Jira is a big contributing factor. I don't think much of the memory is used for presentation (so it might not be React's fault), but rather for business logic processing a large amount of data. And IIRC calling a simple `filter()` on a JS array creates a new array for the operation while Rust uses iterators.

akiselev 6y ago
I regularly slow to a crawl on a 32gb Mac Book Pro requiring a reboot because it starts swapping thanks to Chrome tabs, electron apps/VSCode, and webpack/cargo/whatever to the point that running cat on a file takes 5-10 seconds. All it takes is a little memory exhaustion for the kernel to pick a process for swap (iterm and its children? why, thank you kernel!) and drive it into the ground. With Chrome it might swap just a single tab process or it might swap the rendering process I don't know why it seems React apps are some of the worst offenders, but I think it has to do with hooks injecting context components everywhere (at least that's what it looked like last time I popped open React dev tools). I'm guessing that out of tree state tracking is particularly memory intensive.

jillesvangurp 6y ago

Type safety is the key selling point here. Rock solid behavior for asynchronous and concurrent behavior is another one. Both could be considered weaknesses for Javascript. I agree it's a bit too far out for a lot of javascript/typescript developers. But then the Rust community has a lot of former full stack refugees joining it. My observation is that "full stack development" using javascript is a phase developers go through before upgrading to some other language. You see similar patterns in the Go community. Both communities have lots of people who used to do lots of web and node.js development. My money is more on languages like Kotlin, C#, and Swift crossing over to the browser. Both already have wasm compilers that are still need a lot of work. This work only kicked off for Kotlin fairly recently. Kotlin also has a decent javascript transpiler that you can use right now. Both Swift and Kotlin are very popular for mobile UI development. C# has been used extensieley for Desktop and web server development. Obviously these languages come with lots of features that make them very suitable and popular for exactly the kind of stuff people use Javascript (and Typescript) for. I haven't done much with Swift and C# but Kotlin is great for this. Most of my experience with that language is server side but I have done a few things with kotlin-js as well as some Android stuff. As of a few months ago, the kotlin-js tooling is getting to the point where it's a very solid choice. It builds, it eliminated dead code, it runs webpack for you, etc. The upcoming version (1.4.0) is currently available as a release candidate and includes something called Dukat. Dukat generates kotlin type headers from typescript type headers for npm dependencies. So that means you can integrate a lot of existing npms if you have to. Also the build tools integrate with webpack and you can target both the node.js ecosystem and the browser ecosystem. Most of the bottlnecks for adopting either transpilers or wasm compilers in this space is the relative immaturity (or lack off) mature alternatives to popular javascript frameworks. You can do react apps in a bunch of languages now but it just feels wrong to do it. The pattern you see in other language communities is that they pretty much start rolling their own alternative frameworks. In any case, the amount of third party code making it to a browser is typically not that much for most webapps. For all it's popularity, the react run-time code is not that large. A few hundred KB is considered a lot.