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

re: 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 a...

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