I was writing web applications back in 1999. If I needed to write a web page or a proper “app” (whatever that means) today, why would I use Rust and Web Assembly? Don’t mean to sound arrogant, but is starting with the highest level of complexity a good idea?
> The goal of our application is simple: It's a portal where the victim will enter their credentials (thinking that it's a legitimate form), the credentials are going to be saved in an SQLite database, and then we redirect the victims to an error page to let them think that the service is temporarily unavailable and they should try again later.
Again, why do we need Rust for this?
And the code example puts mark up directly inside Rust files… why?
There are people who will write webassembly apps in Rust because it’s not JS.
Given the crates community, there are surely some special purpose apps that are easier to write in rust than JS. Heck for fun I even got pola-rs to run in the browser!
One thing about wasm I’m trying to understand: isn’t the bottleneck accessing DOM, WebGL, etc through JS? You’d have to have a workload that stayed away from those operations as much as possible to truly matter performance wise, no?
A couple of years ago now, Mozilla had a blog post where they demonstrated that they could stream the DOM to a WASM blob and they could parse the stream, perform the diffs and updates to the DOM and stream it back, faster than the same operations could be completed in the JS runtime.
Interesting, but round trip is that still the case (i.e. performing the diffs and then applying them on the JS/DOM side)? Either way unlocking access to Web APIs from wasm will be transformational if it ever happens.
Figma uses rust heavily for their web apps utilizing web assembly. Can’t link to the exact posts but they’ve written about this on their dev blog before.
The use-cases are all very niche stuff... some examples:
> https://avocode.com/ much like Figma (which was written in C++) it's a heavy duty web app which involved a desktop-app like experience for working with graphical files
> Google Earth (obvious CPU-heavy non-traditional web stuff)
> various game engines and game-related stuff
> 1password uses it to "speed up their browser extension"
> PDFTron... PDF annotation app, so another Figma-like usecase
> some in-browser IDEs
So mostly it's just a) C++ type developers who don't want to learn JS for their hobby project b) it doesn't make sense for them to migrate their existing software to JS so they 'emulate' it c) it's some heavy-duty non-web-typical use-case.
I highly doubt it will ever serve a purpose beyond these niches. Which is fine... it's cool having the option but it's obviously not the first choice for any professional team targeting the web
As someone who uses Rust as my main language, part of the appeal of Rust+yew is “no webpack”. Rust’s build system isn’t necessarily less complex, but it doesn’t drive me batty the way JS compilation does.
I don't know what either of those things are and I don't know why you'd use them instead of plain HTML and CGI (maybe FastCGI or mod_php if you really want to get fancy).
I think what GP is asking is: for those of us who don't follow the latest web development trends, what's the inherent value to this? it isn't clear to an outsider what distinguishes this from just the latest fad?
EDIT: I see that webpack is a tool to simplify bundling of JS modules and dependencies in large scale JS projects
- Transpilers: sometimes you need to support old browser versions but want to use newer features
- Typescript: one but lesson we’ve learnt over the years is that vanilla JS sucks and when your codebase grows into the >10k loc range it becomes a nightmare without engineering and tools like the typescript compiler
- minification: minify your JS, HTML, and CSS
- state synchronisation: a big problem with the jquery days was desync, modern web frameworks make it very easy for state and ui to stay in sync
- one codebase for web, electron (desktop), mobile (react native). Whether this is a good or bad thing is left as an exercise to the reader
- lots more I’m forgetting. For better or for worse, that’s the modern JS toolchain, plain HTML with some JS sprinkled on top just doesn’t cut it for modern webapps anymore
I don't follow. Which older browsers? If they're new enough to support WASM, but this development method is so brittle that they already need transpiling to support them, that's a red flag. On the other hand, if you're talking about pre-WASM browsers, I don't understand how Rust + WASM is going to help support them.
Sorry, I was just responding to your question on JS compilation and webpack.
This post is obviously overengineering things, it’s literally submitting a html form and obviously we can do that with plain old html. The point, however, is that it’s a small scale demonstration of how to run rust on the web, not that you should make phishing websites out of rust and wasm.
Are there actual use cases for wasm? Yes, particularly for performance critical applications. Games, ML, etc, there’s already a lot of wasm deployed today. Since wasm is here to stay, the natural follow-up question is can we compile to it so I can use <insert favourite language> on the web, and that’s the motivation behind stuff like rust/wasm.
NodeJS made it possible to run JS on both front and backend, but nobody actually wants to write JS. So now people are trying to run <favourite nonJS language> on both instead. It’s still in its infancy, so really not recommended for anything other than prototyping and fun exploration, but there’s potential here.
I know a lot about web development (for a non-professional). I know very little about modern trends. This approach has served me very well in the past, where I avoided wasting absurd amounts of time and money on things like ActiveX and ColdFusion.
Instead of making personal attacks, which are against site guidelines, why don't you actually try articulating the value proposition that several posters are asking about? This is a place for substantive discussion.
Webpack is roughly 10 years old. While you may choose not to use it (like you avoided ActiveX) you should be aware of it if you call yourself a web developer.
Why Rust? Why not Rust? WASM finally gives you the option to use the language you like. Once WASM gets GC support GC languages(i.e Go) will become viable too.
It's a nice little tutorial for getting a couple of basic pieces in place using these technologies. It saves a little legwork for someone who wants to do something that makes better use of the value prop.
I was a security researcher since 1992. I don't mean to sound arrogant, but why continue to use languages that lead to security holes when we now have a language that it strongly resistant to most of those failings? Rust isn't just type safe or memory safe - eliminating foot-guns was a guiding principle throughout. People hate the borrow checker, but that concept of ownership eliminated broad classes of concurrency bugs. Rust was a godsend for computer security.
Security is just one aspect of web application development. Writing in rust doesn’t guarantee an application free of security issues like how writing in another language doesn’t necessarily guarantee an app full of security issues.
The odds of correct operation are higher with Rust, and for some people that matters a lot to them.
There are plenty of good reasons not to use rust. If your use case doesn't care about security, fine use whatever. Or if time-to-market is critical, use go or whatever. Or if your organization can't handle the risk that when you leave they can't find another good rust developer, then don't use it.
Memory safety is the main thing though, and people were not normally practicing web development in C.
For concurrency safety, there are a number of approaches from functional programming/immutability, to the actor model, to even PHP's shared-nothing architecture.
And then there's the whole area of type safety, fancy type systems, dependent types, etc.
Rust doesn't seem to be a particular standout for web application correctness in the same way that it is for systems code (where memory safety issues are indeed a huge deal), although you could certainly do worse.
I think the original question here was asking about frontend since this post is about using Rust with web assembly as an alternative to JavaScript. There's no need to use web assembly to use Rust on the backend, nor is there any reason why you couldn't use JavaScript on the frontend if you were using Rust on the backend. As much as I love Rust and prefer to avoid writing JavaScript, I think the arguments for using Rust on the frontend are a lot less clear right now given the hoops you'd need to jump through. If wasm ends up getting proper access to the DOM, that might change, but I'm out of the loop and have no idea if there's any planned timeline for that at all, let alone when that might be.
> Rust isn't just type safe or memory safe - eliminating foot-guns was a guiding principle throughout. People hate the borrow checker, but that concept of ownership eliminated broad classes of concurrency bugs. Rust was a godsend for computer security.
How often are folks writing server side code where they need to pass objects across thread boundaries?
Back end logic is usually straightforward. Each request uses a single thread. Maybe there’s some client library that has a thread pool, for things like reusing connections. But that’s about it.
Is Rust a security silver bullet? Are the other languages obsolete? Is there nothing simpler than Rust, because the borrow checker saves you from doing things you can do in C++, and that’s what we should all optimize for?
Again… why do I need Rust and WASM for serving web pages? It sounds like you’re saying security is the number one non functional requirement and is the only requirement, which I don’t think is accurate. Even then, entire companies are running on JVM.
If I have a C++ use case, I can maybe see using Rust benefits in some areas, although the learning curve is very steep.
Backend logic is not necessarily straightforward, that depends completely on your domain.
Each request uses a single thread? In the stuff I'm working on we often orchestrate asynchronous operations across many different systems, that alone would involve a lot of parallelism and concurrency. We lean heavily into functional code with immutable data, but we're not writing a systems level program.
If you're doing much beyond simple crud, I imagine you're going to want a lot of what you're describing fairly quickly.
> If you're doing much beyond simple crud, I imagine you're going to want a lot of what you're describing fairly quickly.
There are different models for asynchronous execution across different systems. Even then, Rust isn’t a silver bullet.
A request can be scoped to a single thread, and then messages can passed across systems (queues, pubsub, etc), stored to a database, etc etc.
Not having concurrency within a single process doesn’t mean someone is doing simple CRUD, unless you’ve mistaken Facebook.com, Twitter, and Amazon retail website to all be simple CRUD applications.
Rust seems like a solution for your very specific use case, or it’s better suited for C++ and systems programming scenarios.
The borrow checker is a pain in the ass to use. Presenting Rust as silver bullet and ignoring its cost is misguided and near sighted at best. It’s not just Rust but saying <X> is the perfect solution is generally wrong. Every thing has a cost.
I'm not advocating for Rust (not the OP), and I would say Rust is never a silver bullet any time. It might make sense in context for a given problem and team, but there's a lot to go into such a decision.
I'm saying that once you go beyond simple needs, you're going to want to orchestrate async in a fairly sophisticated fashion. That might be in a Node-style architecture, old-school Java with real threads (probably pooled), new-school Java (ie: project Loom), Go, etc.
"How often are folks writing server side code where they need to pass objects across thread boundaries"
- In the JVM land this is very common. Also true in many other environments as well (Erlang, Go, etc). The fact that it isn't true in your tooling of choice doesn't make it universal.
"Back end logic is usually straightforward. Each request uses a single thread"
- Again, both of those statements don't ring true to me. Yes, they do in some environments, but certainly not all. Especially the last statement hasn't been true in the stacks I use for over a decade now.
Keep in mind I was also talking about parallelism here, some folks want to do some compute in addition to gluing together API calls.
"Not having concurrency within a single process doesn’t mean someone is doing simple CRUD, unless you’ve mistaken Facebook.com, Twitter, and Amazon retail website to all be simple CRUD applications.".
- You're suggesting that none of those systems support orchestration of concurrent calls? Please explain in detail.
"Rust seems like a solution for your very specific use case" - It doesn't actually. Our problems are not system level issues (as I mentioned), and doing manual memory management is an overhead we'd gladly let a GC handle, same with the borrow checker. We don't use Rust, I didn't advocate using Rust. I was responding to your comment about backend code being single threaded and straightforward.
"Presenting Rust as silver bullet and ignoring its cost"
- Who did that exactly?
- And who said "<X> is the perfect solution"?
Your tendency to create strawman arguments is a bit much.
[Edited for elaboration on not using Rust, not proposing to use Rust]
Rust only appears safe when compared to C. Many languages have even better support for writing correct programs (thanks to garbage collection, arbitrary-precision arithmetic, message-passing concurrency, contracts, etc.)
I generally agree with this. I think the rust community is one of the first to wholly embrace wasm as a compile target, hence what you are seeing. But Wasm does for sure go beyond rust and has some very interesting implications for for future of development IMO
I wrote a medium-sized Rust web component with Yew, https://github.com/finos/perspective . I chose Rust/Yew for circumstances unique to my use case (a core data engine already in WASM/C++), and with some prior experience in both web and Rust. It's more complex than Typescript/React development for sure, but I also found it surprisingly capable/comprehensive once you've learned Rust itself, there's very little consolation in the Yew web app development experience outside of the complexity of Rust, and the application model is quite similar to React (wrt to markup in Rust source). It's also quite helpful (in my case) that contributors can work on data-engine and user experience features in the same language,
If traditional JavaScript web app development fits your needs, I don't think Rust/Yew makes a compelling case - but in the presence of other performance-abusive requirements, it's a viable web app platform as well.
Why not? It's a fast, general purpose programming language with a solid type system. The article is a programming tutorial, it's not trying to persuade you to rewrite your employer's web stack in rust.
> but is starting with the highest level of complexity a good idea
Complexity is in the mind of the beholder, if you work with rust often, this is a couple steps above a "hello world" in terms of complexity. Besides, anything that goes beyond string templates and jquery is too complex according to the zeitgeist.
> And the code example puts mark up directly inside Rust files… why
This is a pretty common approach to "component" style web development, there are quite a few motivations for this but the primary advantage is that it causes markup elements to become first-class entities within your code, allowing your view composition to be checked by the compiler as well as allowing you to design your own reusable markup elements that fold up application level concerns. It's also nice when your views have lexical access to your application state variables so you don't have to pre-render a big string template and interlace it with an explicit map of serialized parameters - it's very nice when the compiler lets you know a view simply cannot display the type of data you're trying to shove into it rather than rendering a broken looking page.
In short: I think Rust / Wasm is great for certain categories of web apps that can benefit from Wasm's portability and performance consistency. But for more traditional web apps and pages there's little advantage.
Yeah I agree. There's no reason why a front end using TypeScript + React can't use WASM for it's backend connections, but building the entire thing in rust with Yew just seems like a hammer in search of a nail. GopherJS exists but nobody uses it for a reason.
Rust wasm frameworks are red herrings. Wasm-bindgen is the real deal here when used in an immediate-ish way, ie render your page and leave handlers hooked up only for what you need and clear whatever div affected before updating them.
I really expected WASM to support higher level languages like Java, Python or even Visual Basic by now. I dont like JS front ends but Rust/C++ seems worse for front end work.
WASM is still really not appropriate for frontend work. It’s for backend work that happens to run on a client. All the traditional browser stuff is still done on the js side.
That was never the intention for WASM—frontend WASM, at least—since all of those languages have heavy runtimes that would need to be shipped, quite apart from the difficulty of arranging their garbage collection techniques. It’s all stuff that can be done (and has been done), but it’s very inefficient by comparison. The situations may improve somewhat in the future with lighter, more WASM-attuned runtimes for the languages in question (especially as WASM gets some degree of GC integration), but they’ll never be as suitable as straight JavaScript or the likes of Rust via WASM.
For rudimentary GUIs I like rust, specifically the immediate mode lib called egui.
It won't be super fancy but you can do enough with it, it feels responsive, and I can show my basic controls without too much effort. Mind you, what I use it for is not sexy at all, really just something one might use a spreadsheet for.
Very cool to see things like this. It reminds me of the early web when people were experimenting more. Wasm seems to have the potential to open it back up to more possibilities than the moribund JS situation we have now.
If you're gonna do web stuff, a GC is usually worth it... With Nim you can have the same codebase on frontend (compiles to js) and backend, and have it be type checked, and have a potentially very well performing backend.
Are there any libraries to do real-time collaborative editing (multiplayer mode) in a text form?
Implemented via CRDT or transform operations, either or.
64 comments
[ 2.7 ms ] story [ 124 ms ] thread> The goal of our application is simple: It's a portal where the victim will enter their credentials (thinking that it's a legitimate form), the credentials are going to be saved in an SQLite database, and then we redirect the victims to an error page to let them think that the service is temporarily unavailable and they should try again later.
Again, why do we need Rust for this?
And the code example puts mark up directly inside Rust files… why?
Because you can.
To see what the limitations are.
To see how it compares to other methods of writing web apps.
To learn Rust.
To learn web assembly.
Etc.
Not everything needs to be immediately useful or monetizable to be interesting or worth doing.
Given the crates community, there are surely some special purpose apps that are easier to write in rust than JS. Heck for fun I even got pola-rs to run in the browser!
Is anyone using it in production for anything substantial?
We have a couple of uses of it but I'm still not convinced it was worth the trade offs and felt mor like someone was having fun with a hammer.
Another good example I learned about recently is StackBlitz, which uses it to run Node in the browser for localhost-less dev environments.
I believe it’s mostly for video processing iirc.
https://madewithwebassembly.com/
The use-cases are all very niche stuff... some examples:
> https://avocode.com/ much like Figma (which was written in C++) it's a heavy duty web app which involved a desktop-app like experience for working with graphical files
> Google Earth (obvious CPU-heavy non-traditional web stuff)
> various game engines and game-related stuff
> 1password uses it to "speed up their browser extension"
> PDFTron... PDF annotation app, so another Figma-like usecase
> some in-browser IDEs
So mostly it's just a) C++ type developers who don't want to learn JS for their hobby project b) it doesn't make sense for them to migrate their existing software to JS so they 'emulate' it c) it's some heavy-duty non-web-typical use-case.
I highly doubt it will ever serve a purpose beyond these niches. Which is fine... it's cool having the option but it's obviously not the first choice for any professional team targeting the web
I don't know what either of those things are and I don't know why you'd use them instead of plain HTML and CGI (maybe FastCGI or mod_php if you really want to get fancy).
I think what GP is asking is: for those of us who don't follow the latest web development trends, what's the inherent value to this? it isn't clear to an outsider what distinguishes this from just the latest fad?
EDIT: I see that webpack is a tool to simplify bundling of JS modules and dependencies in large scale JS projects
- Typescript: one but lesson we’ve learnt over the years is that vanilla JS sucks and when your codebase grows into the >10k loc range it becomes a nightmare without engineering and tools like the typescript compiler
- minification: minify your JS, HTML, and CSS
- state synchronisation: a big problem with the jquery days was desync, modern web frameworks make it very easy for state and ui to stay in sync
- one codebase for web, electron (desktop), mobile (react native). Whether this is a good or bad thing is left as an exercise to the reader
- lots more I’m forgetting. For better or for worse, that’s the modern JS toolchain, plain HTML with some JS sprinkled on top just doesn’t cut it for modern webapps anymore
This post is obviously overengineering things, it’s literally submitting a html form and obviously we can do that with plain old html. The point, however, is that it’s a small scale demonstration of how to run rust on the web, not that you should make phishing websites out of rust and wasm.
Are there actual use cases for wasm? Yes, particularly for performance critical applications. Games, ML, etc, there’s already a lot of wasm deployed today. Since wasm is here to stay, the natural follow-up question is can we compile to it so I can use <insert favourite language> on the web, and that’s the motivation behind stuff like rust/wasm.
NodeJS made it possible to run JS on both front and backend, but nobody actually wants to write JS. So now people are trying to run <favourite nonJS language> on both instead. It’s still in its infancy, so really not recommended for anything other than prototyping and fun exploration, but there’s potential here.
Instead of making personal attacks, which are against site guidelines, why don't you actually try articulating the value proposition that several posters are asking about? This is a place for substantive discussion.
There are plenty of good reasons not to use rust. If your use case doesn't care about security, fine use whatever. Or if time-to-market is critical, use go or whatever. Or if your organization can't handle the risk that when you leave they can't find another good rust developer, then don't use it.
For concurrency safety, there are a number of approaches from functional programming/immutability, to the actor model, to even PHP's shared-nothing architecture.
And then there's the whole area of type safety, fancy type systems, dependent types, etc.
Rust doesn't seem to be a particular standout for web application correctness in the same way that it is for systems code (where memory safety issues are indeed a huge deal), although you could certainly do worse.
Most of the webs applications were written in C/C++ pre PHP days.
How often are folks writing server side code where they need to pass objects across thread boundaries?
Back end logic is usually straightforward. Each request uses a single thread. Maybe there’s some client library that has a thread pool, for things like reusing connections. But that’s about it.
Is Rust a security silver bullet? Are the other languages obsolete? Is there nothing simpler than Rust, because the borrow checker saves you from doing things you can do in C++, and that’s what we should all optimize for?
Again… why do I need Rust and WASM for serving web pages? It sounds like you’re saying security is the number one non functional requirement and is the only requirement, which I don’t think is accurate. Even then, entire companies are running on JVM.
If I have a C++ use case, I can maybe see using Rust benefits in some areas, although the learning curve is very steep.
Each request uses a single thread? In the stuff I'm working on we often orchestrate asynchronous operations across many different systems, that alone would involve a lot of parallelism and concurrency. We lean heavily into functional code with immutable data, but we're not writing a systems level program.
If you're doing much beyond simple crud, I imagine you're going to want a lot of what you're describing fairly quickly.
There are different models for asynchronous execution across different systems. Even then, Rust isn’t a silver bullet.
A request can be scoped to a single thread, and then messages can passed across systems (queues, pubsub, etc), stored to a database, etc etc.
Not having concurrency within a single process doesn’t mean someone is doing simple CRUD, unless you’ve mistaken Facebook.com, Twitter, and Amazon retail website to all be simple CRUD applications.
Rust seems like a solution for your very specific use case, or it’s better suited for C++ and systems programming scenarios.
The borrow checker is a pain in the ass to use. Presenting Rust as silver bullet and ignoring its cost is misguided and near sighted at best. It’s not just Rust but saying <X> is the perfect solution is generally wrong. Every thing has a cost.
I'm saying that once you go beyond simple needs, you're going to want to orchestrate async in a fairly sophisticated fashion. That might be in a Node-style architecture, old-school Java with real threads (probably pooled), new-school Java (ie: project Loom), Go, etc.
"How often are folks writing server side code where they need to pass objects across thread boundaries" - In the JVM land this is very common. Also true in many other environments as well (Erlang, Go, etc). The fact that it isn't true in your tooling of choice doesn't make it universal.
"Back end logic is usually straightforward. Each request uses a single thread" - Again, both of those statements don't ring true to me. Yes, they do in some environments, but certainly not all. Especially the last statement hasn't been true in the stacks I use for over a decade now.
Keep in mind I was also talking about parallelism here, some folks want to do some compute in addition to gluing together API calls.
"Not having concurrency within a single process doesn’t mean someone is doing simple CRUD, unless you’ve mistaken Facebook.com, Twitter, and Amazon retail website to all be simple CRUD applications.". - You're suggesting that none of those systems support orchestration of concurrent calls? Please explain in detail.
"Rust seems like a solution for your very specific use case" - It doesn't actually. Our problems are not system level issues (as I mentioned), and doing manual memory management is an overhead we'd gladly let a GC handle, same with the borrow checker. We don't use Rust, I didn't advocate using Rust. I was responding to your comment about backend code being single threaded and straightforward.
"Presenting Rust as silver bullet and ignoring its cost" - Who did that exactly? - And who said "<X> is the perfect solution"?
Your tendency to create strawman arguments is a bit much.
[Edited for elaboration on not using Rust, not proposing to use Rust]
Rust only appears safe when compared to C. Many languages have even better support for writing correct programs (thanks to garbage collection, arbitrary-precision arithmetic, message-passing concurrency, contracts, etc.)
If traditional JavaScript web app development fits your needs, I don't think Rust/Yew makes a compelling case - but in the presence of other performance-abusive requirements, it's a viable web app platform as well.
Why not? It's a fast, general purpose programming language with a solid type system. The article is a programming tutorial, it's not trying to persuade you to rewrite your employer's web stack in rust.
> but is starting with the highest level of complexity a good idea
Complexity is in the mind of the beholder, if you work with rust often, this is a couple steps above a "hello world" in terms of complexity. Besides, anything that goes beyond string templates and jquery is too complex according to the zeitgeist.
> And the code example puts mark up directly inside Rust files… why
This is a pretty common approach to "component" style web development, there are quite a few motivations for this but the primary advantage is that it causes markup elements to become first-class entities within your code, allowing your view composition to be checked by the compiler as well as allowing you to design your own reusable markup elements that fold up application level concerns. It's also nice when your views have lexical access to your application state variables so you don't have to pre-render a big string template and interlace it with an explicit map of serialized parameters - it's very nice when the compiler lets you know a view simply cannot display the type of data you're trying to shove into it rather than rendering a broken looking page.
In short: I think Rust / Wasm is great for certain categories of web apps that can benefit from Wasm's portability and performance consistency. But for more traditional web apps and pages there's little advantage.
It won't be super fancy but you can do enough with it, it feels responsive, and I can show my basic controls without too much effort. Mind you, what I use it for is not sexy at all, really just something one might use a spreadsheet for.