re: State of Rust Web Frameworks (Server, DB) VIEW POST


Great overview, and very concise. I've appreciated Warp's ease of use so far. Never needed an ORM, but I have used Sled with Serde. It's also worthwhile to mention a view layer. Percy and Warp are a great combo for SSR + HTML content, in addition to a more React-friendly syntax. I also appreciate Iced's approach, since it leaves HTML + CSS behind, in favor of a more graphics-native approach, providing draw call abstractions to Vulkan, Metal, and WebGPU APIs. This allows it to support desktop applications like Electron, in addition to a lightning fast web interface, without all the bloat.


Thanks for adding to this. I didn't get into DB implementations in Rust because I thought it might get into the weeds a bit (I didn't even plan to do DB interfacing either).

It sounds like you don't always need a DB for your projects. If that is so, what attracted you to a Rust solution (Sled with Serde) rather than a standard DB solution (PG, MySQL, etc)? Can you speak to the pros and cons of it, and would you recommend Sled or another DB impl.?

I would be scared to do my DB in something without tons of documentation and support. I would think a lot of people would have concerns about LTS and portability.


I mentioned a few of these points in the other comment, and as for LTS and long-term viability, I'm really speaking a lot more to the future than anything. I'm quite practical when it comes to work I do for my employers, but a large part of the value I usually bring to anyone I might be working for is my breadth and depth of knowledge, especially of things that might be years and years away. I like to have a big toolchest, so I can pick the right tool for the job, or push back if something proposed that sounds like a poor fit. It's a lot easier to do research spikes when you're always doing mini-spikes of your own!

I missed this post originally, but feel free to keep the database discussion here, if you like. :)


I'm very unfamiliar with the graphics bit, so I appreciate you bringing up Iced. I didn't know people used other methods of representation in web apps. Is it more performative? It would surprise me to hear that it is more ideal for most web apps, but for gaming apps or graphics/animation heavy apps I see the merit.

Would you use it over other solutions? Why?

PS Iced and Percy are more "another post" material, so I will leave anything not related to servers or DBs off the main discussion thread. But definitely thanks for bringing more tools to the fore. cheers


For sure! Iced is quite novel in that you can use the same codebase to cross-compile entire complete apps across multiple targets. So far web and WASM (with low-level WebGPU, as opposed to WebGL) binaries and desktop targets are officially supported. It uses native Metal (on MacOS) and Vulkan (on Linux and Windows) graphics APIs directly. Additionally, an iOS example does exist, where Rust is compiled to arm64-ios.

The advantage of this is many-fold. The first obvious one is that you don't have to have, for example, different codebases for responsive web, Electron, and mobile. It's just the one, and Rust has a similar feature to the C preprocessor (but not the same) that lets you disable the inclusion of certain code paths in the final product, while still keeping the code in the same file and context. Builds can be so much more optimized-- A static linker can do fine-grained dead code removal optimizations, and removal of debug code in production, in ways that JavaScript could never hope to do. Dependency tree-shaking doesn't even come close. You can't do AST tree-shaking JS reliably because you can redefine methods at runtime, as well as a number of other nonsense things that are possible in JS that, although are edge-cases, would preclude more traditional optimizations that happen all the time in traditional software development since, well, the late 1970s. And since most modern JS projects still have an incredible amount of code, even in the final production binary, it's easy to see why the edge cases matter. Even with TypeScript, the big problem with dead code removal in JS, and there are some experimental projects that attempt this, careful analysis and testing of the entire bundle, including the dependencies, would be necessary to ensure safety of that kind.

And since Rust doesn't require the inclusion of a traditional GC, it's a perfect fit for WASM. WebAssembly doesn't support a GC OOTB, it's still in the proposal phase. Go and Blazor still have to include a GC.

Ironically, Rust dev build artifacts (the target directory) wind up taking up a lot more space on disk than node_modules and dist or build. I'm assuming rustc is just doing a heck of a lot more when it's doing the mostly comprehensive ADT type-checking Rust is famous for. But the web release binary is usually comparable to a React app, if not samller. Additionally, the native build is usually around 10-100x smaller than an Electron app. If you're feeling real adventurous, you can even compile without support for CPUs made 10 years ago, or even try recompiling the Rust stdlib in a similar fashion, but that's also a lot harder to do, admittedly.

There's a lot more to say on this topic, and it goes real deep, but needless to say, I think Rust and WASM has a real shot at a future where it could replace Electron, React, and React-Native. In addition to, you know, the promise projects like Lucet and WASI have towards entirely outmoding Docker and Kubernetes for deployments. And projects like Sled and TiKV have real promise for high-performance KV stores. More scalable (and cheaper) than Redis, while faster than LevelDB, which, to a degree, helps lessen the need for fiddly fine-grained tuning like what is commonly done in RocksDB. Remember, pretty much all databases are essentially key-value stores because of their indexing strategies. They just have different query frontends and other implementation details here and there. But they usually all have WAL or AOIL or whatever, and there'll be background optimization processes, and oh hey, now you have something resembling a B-Tree or LSM tree.

But, as you mentioned, all that is a discussion to be had in a different post entirely. One I'd love to have, though, and perhaps we could compile it into a separate dev.to post.

code of conduct - report abuse