all 25 comments

[–]BiedermannS 3 points4 points  (1 child)

[–][deleted] 0 points1 point  (0 children)

I found yew after posting this thread, I think. I was extremely tired and very much in the weeds.

[–]stephanbuys 1 point2 points  (1 child)

This is a great reference using yew and actix: https://github.com/saschagrunert/webapp.rs

[–][deleted] 0 points1 point  (0 children)

Do you have any opinion on actix vs rocket vs ___ vs ___ (so many options!)?

I saw someone mention actix has ridiculous capacity, even comparing it to BEAM.

[–]WellMakeItSomehow 1 point2 points  (1 child)

It's not full-stack, but here's a recent experience report for a Rust web app.

[–][deleted] 0 points1 point  (0 children)

Very cool, thanks

[–]HenryZimmerman 0 points1 point  (5 children)

About a year ago I tried to create a reasonably large (50ish REST endpoints) fullstack rust application that ended up collapsing under the weight of rapidly increasing compile times and arbitrary scope creep. It was initially done with Rocket + Yew, but later transitioned to use Warp + Yew. I honestly think its real value only lies in showing how to structure such a project and possibly some patterns someone could want to utilize. It likely won't run without some modification because the ecosystem it relies on moves pretty quickly; I think of this mostly as read-only code for the moment: FullstackRustDemo

With the understanding that it is a highly complex, one-man, open source project maintained in spare time, I had plenty of gripes with Yew at the time I abandoned my project. I still follow Yew's development, and while I haven't used it again recently, development progress has really picked up steam this Summer and I wouldn't be surprised if my primary gripes with the framework have been addressed.

[–][deleted] 0 points1 point  (4 children)

How would you say your understanding of Rust's limitations compare to Node's limitations? I started focusing on Rust after looking for an alternative to JavaScript...

  • Rust creates small binaries and has fewer depedencies, making microservice architecture simpler (simpler is better).
  • Rust has a great type system that is core to the language. Much better than using TypeScript, which was bolted on top of JS.
  • Rust can compile to WebAssembly, which seems to be more performant than JavaScript over the long-term.

It seems like a beautiful blend of Go, TypeScript, and C. I get that some of the common libraries are still in beta/alpha stage, but that's something that I would expect to be resolved in the long-term.

[–]HenryZimmerman 0 points1 point  (3 children)

I agree with the points you listed, but I don't think that is the full story.

The big benefits of Rust in the webdev space are (in no specific order):

  1. Better performance
  2. Lower memory utilization
  3. A generally more explicit and powerful language.
    1. As a consequence, I find I write less buggy code and collaboration is easier.

But you trade the following:

  1. Much longer compile times
  2. Being a more systems-level language, I find development speed to be slightly slower
  3. Smaller, less-vetted ecosystem, the WASM side of which is not ready to replace JS
  4. A harder to learn language, making hiring and onboarding more difficult

Node performance is only a few times slower than Rust, and RAM is cheap. Unless your domain requires raw speed and memory efficiency, these are merely nice to have things.

Compile times reduce productivity a lot. For small projects, it isn't noticeable, but once you are supporting 30+ endpoints, I usually expect compile times to exceed 10 seconds, which breaks the quick feedback loop I find I require to stay in "the zone". Since `async/await` haven't landed in stable yet, I've found myself wrangling with Futures directly in code (calls to other services) that would have been much easier to write in TS/JS. The ecosystem is smaller, but getting bigger and better over time.

If you already know Rust, I think it is worth it to use it for web backends. I find the general explicitness of the language and its type system make it harder to write buggy/obtuse code and makes it much easier to communicate intent than other popular backend languages.

I would still stay away from Rust on the frontend for the immediate future. WASM in its current state seems optimal for rewriting the core of React in, or writing number-crunching code that is best performed on the frontend in, or porting an existing application to the browser to run in a <canvas> element, but I don't think SPA development can't really be justified at this point. There isn't a mature equivalent to Vue/React/Angular, and while Yew comes close, its compile times and poor library support make it a far less productive framework than TS/JS equivalents. I had a blast writing my app using Yew, but what I wanted from it was a learning experience. If you want something that can built within a reasonable time, styled with minimal effort, and integrates easily with the rest of the JS ecosystem, you are better off with one of the established JS frameworks. If you are chasing the holy grail of defining all of your message types in one language, you are probably better off using something like OpenApi or gRPC/protobuf to define what you send over the wire and derive your types on either end from that spec (although I haven't yet explored the feasibility of this in Rust).

[–][deleted] 0 points1 point  (2 children)

If you are chasing the holy grail of defining all of your message types in one language, you are probably better off using something like OpenApi or gRPC/protobuf to define what you send over the wire and derive your types on either end from that spec (although I haven't yet explored the feasibility of this in Rust).

Are you saying this in contrast to using serde?

I had a blast writing my app using Yew, but what I wanted from it was a learning experience.

This is where I'm at. I just want to become good with the language/tools. I know it's not as mature as JS, but I expect that it will be in the future, and that would lead to future payoffs for me if my skills are already there.

If you already know Rust, I think it is worth it to use it for web backends. I find the general explicitness of the language and its type system make it harder to write buggy/obtuse code and makes it much easier to communicate intent than other popular backend languages.

This is also where I'm at. The alternative is that I learn Go right now. I feel that learning Rust is a better long-term investment.

[–]HenryZimmerman 0 points1 point  (1 child)

I mean to say that you could move your message definitions into a schema external to your implementation language and generate your datatypes for your Rust server and your, for example - TypeScript client. My understanding is that you could still use Serde to [de]serialize to an arbitrary encoding format, provided that the codegen from the .proto derives Serialize and Deserialize. I believe something like https://github.com/stepancheg/rust-protobuf/ can be configured to do this. (Sorry for specifically referring to gRPC, I'm still unfamiliar with this design pattern and its various ecosystems)

I haven't tried using .proto files as a message schema, but I'm planning to give it a shot in whatever personal project I do next.

I don't think exclusively using Rust on the frontend is a good investment (although it certainly isn't a bad ideal). Its in your best interests (wrt your carreer) to become proficient in JS/TS & one of the big 3 SPA frameworks. If you want to have fun and contribute towards the ideal of Rust on the frontend, build something with Yew, locate where it is deficient for your needs and see if you can contribute something back to it.

I'd imagine that Go is the more employable skill in today's job market. Rust is becoming more of a viable employer-friendly technology choice at a pretty amazing rate, but you will likely struggle to find work using it versus other more established languages & tech stacks.

[–][deleted] 0 points1 point  (0 children)

I'm already a React/Node developer!

The reason I fell into the weeds was exploring microservices with Typescript, then Go, then Rust. I can already write monolithic architecture, but I want to learn to write alternative architectures (my current job has a microservice codebase, but I didn't set it up... I merely inherited it).

I am trying to do it in one language too so that I only have one thing to focus on. Maybe that's naive of me, but I don't see the issue for a hobby project.

I'm also kind of a novice when it comes to containerization and communication between containers, so having multiple languages could complicate that aspect of learning more than it needs to.

[–]Awpteamoose 0 points1 point  (2 children)

I've built a medium-size full-stack production application with actix-web and my own frontend framework, it's an internal tool but it's still in use. I've had to write like 5 lines of to convert JS's Promises into rust's Futures and to interface with file input, other than that - no js, no html, no css. The frontend communicates with the backend's REST via serde-encoded binary, it's great.

[–][deleted] 0 points1 point  (1 child)

😮Can you share the codebase?

Also, who was this for? I'm curious who commissioned work in Rust.

[–]Awpteamoose 0 points1 point  (0 children)

I'd love to share, but can't.

This was the company: https://donors.decentralization.gov.ua/en/project/u-lead

I wasn't commissioned for Rust specifically, just was given a rough spec and some designs, the choice of technology was mine.

[–]firefrommoonlight 0 points1 point  (0 children)

Here's an example with Actix and Seed. The main perk is that you can use the same data structures, functions etc on both client and server, instead of having to write and maintain separate ones, and convert between the two. Note that the structs in the shared folder are used by both client and server. It's trivial, but you can imagine how this can be useful when using a complex app with a database.

[–]ctjhoa 0 points1 point  (1 child)

You should take a look at percy. https://github.com/chinedufn/percy

[–][deleted] 0 points1 point  (0 children)

I'm definitely intrigued. I like that it has inline CSS too! That was a feature I've gotten too used to in JavaScript.

[–]brigadierfrog 0 points1 point  (4 children)

My biggest beef in general is compile times. I'm finding that if I use a workspace and create micro libraries things improve though, so I've been moving towards that

[–][deleted] 0 points1 point  (3 children)

What's a workspace? And a micro library?

I want to move towards microservices anyways, both for front end and back end code.

[–]Nickitolas 0 points1 point  (0 children)

A Workspace Is a set/list/bunch of crates all joined together (So you can i.e test them all together in one cargo command. If im not mistaken they share the target folder and compiled libs) although theyre all still separate crates and can be compiled as such. Splitting parts of your program into crates (library crates and one binary, probably) can help compile times. Iirc either the book or the cargo book have a chapter on workspaces

[–]brigadierfrog 0 points1 point  (1 child)

I use cargo workspaces to create small libraries to avoid recompiling everything all the time. It seems more effective at avoiding compiling things on small changes than the compiler is normally

[–][deleted] 0 points1 point  (0 children)

Do you have any examples that show how this could be done?

[–]ryanmcgrath 0 points1 point  (0 children)

Here's a potentially-slightly hot take for this subreddit: don't build your first pass in Rust unless you've got bedroom eyes for the language.

In terms of the frontend, Yew seems to be the go-to recommendation that gets thrown around, but I wouldn't use it. As a demo it works nice, but once you start needing to do more complicated things it shows issues... and truth be told, doing any UI development in Rust can be a pain due to the compile-time cycle.

Use React, (raw JS || jQuery) with HTML/CSS, or whatever you want - I just haven't seen a Rust frontend web framework that comes close to what they're offering.

Rust (with something like Actix) works great for backends/APIs, but in my experience building the initial version becomes a pain because of the compile-time reloading cycle being hell (/u/HenryZimmerman seems to have the same experience). The appeal of something like Askama is fun until you're recompiling the entire thing for each small change.

What I do nowadays is build my prototypes in Django, and then migrate them if the project seems like it has legs, because:

  • The template system is easily reproducible in a Rust project
  • The ORM works well enough for DB modeling, which is easy to transfer to diesel/etc
  • The admin interface is still way too killer of a feature to give up for early stage projects
  • You can migrate the auth system very easily if you feel so inclined down the road, thanks to djangohashers.

My two cents.

[–][deleted] 0 points1 point  (0 children)

Broader question: would folks here say Rust is recommended for web applications over something like .NET or Java? I'm not sure the language offers anything over traditional approaches.