i have absolutely no experience with any web frameworks and i can't even imagine what working with one could be like. therefore, i can't provide any requirements or make use of comparisons from the internet. the only thing i know is that i want my server application, most likely written in rust, to get some data from a database and then send it to a client side powered by javascript. i found out that the most popular rust web frameworks are actix-web and rocket. but as i said earlier, i have never worked with any backend framework, i don't know what to look at and how to choose.
Check out these:
I think that you should definitely go for either actix or rocket, but when it comes to choosing between them, you will probably be fine regardless of what you choose. I also recommend using Rust only for backend for now. The wasm ecosystem is evolving, but isn't quite there yet. Use javascript or typescript for frontend.
If you do choose to use actix and enter the world of async Rust, you should also check out the Tokio tutorial.
3 Likes
I started with Rust a year ago and a few months in wanted to put up a web server. Like you nothing special: serve up some static pages, some database access, and a simple REST API.
I went with Rocket. Mostly because of the presentations I saw on it on YouTube. For example RustConf 2017 - Building Rocket by Sergio Benitez - YouTube and others. Partly because I had never heard of any other Rust web servers except Actix.
I was wary of Actix at the time as it is an "async" framework and the whole async Rust thing did seemed to be in a state of flux. There was also a question mark over the future of Actix when the developer threatened to give up the project and delete the repostiory! Both those situations seem to have been resolved.
I found Rocket's documentation to be good and everything went very easily.
I were making that choice today I'd likely restrict myself to looking at only Actix and Rocket. I'd have a good look at the docs for both and see what looked the easier for me to deal with.
1 Like
Also potentially of interest is that rocket for a long time only compiled on nightly but is now close to compiling on stable.
I expect they'll have an announcement soon when they are able to compile on stable rust. Rocket o.5 the next release will work on stable rust. It's been a while coming 
https://github.com/SergioBenitez/Rocket/issues/19#issuecomment-630650328
1 Like
It's great that Rocket will soon be usable from stable Rust.
Not that it has been any issue for me that it did not, I only use nightly Rust. From what I gather it has only cause very minor problems for others, using it in production, that were fixed very quickly.
By the way, all my client side stuff is still Javascript. I have yet to become brave enough to tackle the complexity of using Rust in the browser (apart from one simple experiment so far but that was just using Rust for compute in a webworker)
1 Like
I hate to be Capt. Bringdown here, but Rust is not close to Node or php or ... in terms of server side web frameworks. Esp. if you're controlling both sides, and one side is JavaScript. I like Rocket. But it is a long way from what you'll find in Node. I would also give Meteor some serious, serious, serious consideration.
My reasons for Rust on the client are that you can deliver an executable object that communicates with your Rust server component. IOW, a single code base. In my 35+ years developing networking software, and my 20+ years developing software for the 'net as you know it, Rust is an astonishing advancement. Save your Rust arrows as noob web developer. Solve the simple crap with well established tools. Build your PoC in pure JavaScript, then decide what parts of it you want to reduce to Rust.
1 Like
I'm curious. I'm no great shakes web developer so it it would be great if you sited some examples to support that claim.
Back in the '00's I was so desperate for work that I took a job with a team developing a web site in PHP. It was such a horrible experience that I promised myself never to go near web development again. I could see then that the web was a horribly ill specified, sloppily slapped together, wobbly mess of insecurity. I did not want to be part of it. Turns out over the years since that I was right!
A few years ago I was faced with the 'web' problem again. Luckily node.js had just arrived and I realized I could do this in a "real" programming language. No wibbly wobbly 'LAMP' stack. I was surprised to find that JS is not just a silly scripting language for handling mouse clicks and wizzy animations in the browser. JS is a pretty sophisticated language that could do wonders server side. I was surprised to find modern JS engines and node.js turned in respectable performance.
That and the fact that the also newly arrived web sockets and webgl meant I could do what I wanted without having to dirty my hands much with all that HTML, CSS, and web junk.
This last year I have bet the farm, our little start up, on Rust. I do all the same kind of things in Rust that I did with node.js. Serve web pages and REST API's , serve live data streams with web sockets, juggle all that with our databases and NATS messaging server. Oh and Rust on the remote embedded devices that feeds all of this.
All of which has gone as well as it would with node.js, with the added reassurance of Rust's correctness and that it does not crash in the night. Which it has not. And of course an order of magnitude better performance and hence cheaper server costs.
The one thing missing in my picture is Rust in the browser. That is all still React, THREE.js/Babylon.js and the like. Perhaps I will be brave enough to tackle that next year.
In short, we are using Rust now for everything we might have used node.js for before.
What am I missing here?
Of course we don't have huge stacks like Wordpress or whatever. I don't care, that is not what we want.
I can sort of agree with that. I have often found myself trying out some new, to me, algorithm in JS. Just to be sure I understand how to make it work before recasting in in C++ or now a days Rust. Small scale stuff though.
2 Likes
I can add nothing more to your original request. I didn't see anything about embedded or NATS in the original post, so I withdraw from the field of battle...
Not to worry, there is no "field of battle". Only a conversation.
There was no mention of embedded or NATS in the OP. I was curious to know what 'frame works" I am missing, and how they might be useful.
This topic was automatically closed 90 days after the last reply. We invite you to open a new topic if you have further questions or comments.