8 ms·
Is Rust Ready for the Web Yet? (2020)
- jph 4y agoYes Rust is ready for the web. Here's a brief intro about how to use Rust for the web with Axum, Tower, Hyper, Tokio, and Serde. https://github.com/joelparkerhenderson/demo-rust-axum https://github.com/joelparkerhenderson/demo-rust-axum
- bryanlarsen 4y agoRust is pretty much the only language that runs well on all of front-end, back-end, iOS, Android, Windows & MacOS, with decent UI bindings. Javascript is the only real competition, but the needed shims are lossy at times. C++ is the closest, but Dioxus and Cacao are nicer than anything in the C++ ecosystem AFAICT. It's perhaps not the ideal language for any of those, but there's substantial benefit to having your whole team in the same ecosystem.
- andsoitis 4y agoRuns well in a browser, with ergonomic integration with HTML, CSS, and other browser APIs?
- bryanlarsen 4y agoYes, check out Dioxus, which is essentially React for Rust, and is faster than react at many tasks.
- marcosdumay 4y agoYes. It's new enough that you will find a bug or two, but it's about as closely integrated as Javascript.
- qsort 4y agoQT is still far ahead. This isn't a dig on Rust, but wherever Rust runs, so does C++. There are a lot of dimensions where Rust is better, but definitely not "runs everywhere" and "ecosystem".
- warning26 4y agoMy main gripe with QT is that apps created with it are, as a rule, ugly and non-native feeling. My suspicion is that this is because QT widgets sort of look like native widgets but aren’t quite there, causing it to fall into some kind of “uncanny valley” analogue.
- jeroenhd 4y agoFrom my experience, the same is true for most Rust frameworks. In fact, I don't think there's a single stable Rust GUI library that tries to accommodate system controls. You can use the win32 API on Windows and Gtk on GNOME, but for KDE and all else you'll need to use some kind of Qt wrapper that has the problems you encounter.
- bryanlarsen 4y agoIME your rust apps should use native frameworks. Cacao for iOS, Dioxus for web, etc.
- bryanlarsen 4y agoCompare this demo: https://www.qt.io/web-assembly-example-pizza-shop?hsCtaTracking=e97265b8-ec7f-4652-b052-d26b8875166d%7Ce09e2ec9-4b23-4528-8d66-448a523b7e64 https://www.qt.io/web-assembly-example-pizza-shop?hsCtaTrack... with this demo: https://github.com/DioxusLabs/example-projects/tree/master/ecommerce-site https://github.com/DioxusLabs/example-projects/tree/master/e... QT is unusably slow. Dioxus is indistinguishable from a Javascript app.
- marcosdumay 4y agoC++ does not run as well on the browser. Yes, QT on the desktop is very good. There are bindings for Rust too, as there are for most languages, but the most integrated one is C++. (I'd say the close integration is just not worth it.) Anyway, I don't know why people want so badly a single language to run on every context. They are forfeiting a lot of value for that.
- rascul 4y agoHow does rust run on the front-end? Or is this the compile to wasm thing?
- vbezhenar 4y agoJava?
- bryanlarsen 4y agoDo Java applets even work on the modern web?
- vbezhenar 4y agoI don't think so, but there're solutions for Java to JS transpiling.
- thsowers 4y agoAlso see: https://www.arewewebyet.org/ https://www.arewewebyet.org/
- fouronnes3 4y agoIs there a meta website for all the "are we X yet" about rust?
- jherdman 4y agoIt sounds like you've found your weekend project ;)
- SantalBlush 4y agoI believe you mean, "Are we meta website yet?"
- jjice 4y agoOn Mozilla's wiki: https://wiki.mozilla.org/Areweyet https://wiki.mozilla.org/Areweyet
- Chatter9220 4y agoThere's a http://arewemetayet.com http://arewemetayet.com
- code-blooded 4y agoIt looks like this article requires sign up to read.
- mattrighetti 4y agoNon paywalled version here https://scribe.rip/is-rust-ready-for-the-web-yet-9ec38c01dcaf?gi=cb0c2433e2a7 https://scribe.rip/is-rust-ready-for-the-web-yet-9ec38c01dca...
- revskill 4y agoHaving fun porting my Typescript/NodeJS/ReactJS stack into Rust and Yew. Same productivity, more safety.
- abiro 4y agoYes, it's ready. Read Zero To Production In Rust by Luca Palmieri for best practices: https://www.zero2prod.com/ https://www.zero2prod.com/
- deleted 4y ago[deleted]
- jakearmitage 4y agoMaybe not with Actix, but certainly with axum: https://github.com/tokio-rs/axum https://github.com/tokio-rs/axum Salvo is also great: https://salvo.rs https://salvo.rs
- boredumb 4y agoYes! I was delighted just a few weeks ago to go from nothing to a rest server, redis connection, database connection and templating out dynamic html with rust after a few hours of tinkering.
- the__alchemist 4y agoI won't use it to build a website until we get something like Django, or at least something like Flask's ecosystem. I want automatic (or at least easy and without DRY problems) DB migrations. I want an auto-generated admin page; auth; email. I will continue using Rust for embedded, 3D graphics, and desktop PC programs, but won't touch it for websites until this is solved.
- jeroenhd 4y agoIn terms of database and framework design there are several Rust libraries that come close. Diesel for database and migrations and something like Rocket for the backend itself should be enough for a quick JSON API or Thymeleaf based page renderer. Auto generated admin stuff is pretty rare in anything outside Django I think, though I don't see why one couldn't make those for Rust. I suppose most devs would probably want their CRUD APIs to function on their own and use those for management if performance is critical enough that you'd prefer Rust over something like dotnet or Java.
- develatio 4y ago> Auto generated admin stuff is pretty rare in anything outside Django I think Just wanted to say that anywhere from Ruby on Rails, to Laravel, to Yii, to... Pretty much every major web framework in the most common language used for web dev (php, python, ruby) has a builtin admin (among tons of other stuff). Edit: > Diesel Diesel doesn't come close to where the ORMs of Django or RoR stand. Not by chance. Having to write by hand SQL (according to Diesel's docs) is something that modern web frameworks solved years ago. And I'm not even talking about automatic mapping of models to tables, automatic migrations, etc... Diesel is simply not anywhere near what a web dev would expect. Not saying that Diesel is bad, just that it's not in the same category where current ORMs stand.
- mijamo 4y agoRust database and migration story is really not that nice yet. SQLx is nice for pure SQL but doesn't have a good query builder story yet. Diesel is very clunky in comparison to Django ORM as soon as you get to anything beyond basic. Migrations are even less polished. And in my experience going from Django to anything in Rust will be at least 10 times the boilerplate and some things will be very very annoying to handle, especially things like sharing parts of model, automating things like creation / update metadata for all models, and even sharing authentication mechanism for most routes can be annoying depending on the way you have to do authentication (in my case Firebase auth so authenticating sometimes does require making async calls... And that's a trouble).
- sergiotapia 4y agoWith all due respect does anyone else find Rust's syntax just horrible? #[get("/")] #[actix_web::main] std::io::Result<()> HttpResponse::Ok().body("Hello world!") I mean, blegh! Anyway, just making conversation please don't take offense, some people think Ruby looks like ass.
- maxbond 4y agoRust's syntax took me a long time to get used to, and was sort of dazzling and difficult to read at first. Lifetimes and generics were especially difficult, it just looked like a jumbled mess to me. There's (at least) three things going on in the snippet you posted. One is that actix, like most (all?) Rust frameworks, is macro based; that code would look pretty similar if it were written in Flask, but with different syntax. Another is that the strict type system can lead to some heavy verbosity, eg having to populate the generic in `std::io::Result<()>` with unit (`()`) just to say you're not returning anything. Regarding `HttpResponse::Ok().body("Hello world!")`, the builder pattern is also pretty verbose and some people don't like it, but it's friendly to the type system and you can use it to provide really cool guarantees (like not being able to call `build()` until you've fully populated the builder). Generally I'm of the mind that computers should conform to the needs of people and not the other way around, but programming language are a place where I'm willing to make many concessions, since as a rule humans are smarter than compilers.
- sph 4y agoRust syntax is fine. Actix with its pervasive use of macros, ain't.
- cytzol 4y agoAs a sidenote to your sidenote: I've noticed that the term "syntax" seems to have two different meanings nowadays. There's the technical meaning, namely "the rules that govern how characters are parsed into abstract syntax tree nodes", which in your example, would cover whether Rust shoud use `.` or `::` as a namespace separator, whether to use `[]` or `<>` for generics, that sort of thing. (Both of which have trade-offs in constraining how other parts of the language can be designed.) But I think sometimes, people use "syntax" in a blanket "how the language looks" way — that is, whether it's symbol-heavy, whether it's word-based, whether it's information-light or information-dense, and so on. This makes it more a function of which features of expressivity the language chooses to expose, than the individual syntactic choices that determine which characters we use and for what. Again in Rust's case, it has attributes, it has namespace separators, it has the zero-tuple, it has generics, and it has lifetimes, all of which need some way to be expressed. Don't get me wrong, you're allowed to not use a language if you don't like the way it looks visually. Or maybe it makes good use of a certain character that's hard to type on your particular keyboard layout. That's fine. I also can't decree that either of these uses of the term "syntax" are wrong. But when we're talking about language syntax, it's important to remember when you're talking about syntax, and when you're instead talking about language features. If you don't like the way lifetimes look, that's one thing; if you don't like the way lifetimes make you change the way you write code, that's another. So I have to ask: of those four code snippets, how would you prefer to write them? What would you change? And can you get away with making those changes without breaking anything else?
- ianpurton 4y agoI've built 2 production sites so far in rust and documented it here https://rust-on-nails.com/ https://rust-on-nails.com/
- lewantmontreal 4y agoWow, that looks really extensive. Great work!
- jmt_ 4y agoI've built all my web backends in either Flask or Django - what are the selling points/advantages of using Rust vs. Python in this context? Certainly not arguing against it but am very curious and unfamiliar with Rust. If anyone has moved from Python to Rust for this kind of work, can you speak on your experiences with doing so?
- dehrmann 4y agoIt's written in Rust. Rust is at the state of its life where people will try to do anything and everything with it because they can. Some will stick, while some is just silly. If I interviewed somewhere that used Rust for web apis, I'd be very hesitant because this isn't really what Rust is good at (yet?), and someone chose it because they wanted to try it more than use the right tool for the job.
- drogus 4y agoI have a very limited experience with Python (3 months of production experience), but vast Ruby experience and I think a lot of the things apply to both. For me these are reasons why I would choose Rust over Python or Ruby in most cases: * it's relatively easy to write code that will pretty much never crash. yes, Rust will not prevent all of the bugs, but it will prevent almost all of the things that end up as a runtime exception in dynamic languages. So ou will not end up with an error tracker full of errors * refactoring is so much easier in Rust - I can enter a new project, change a bunch of stuff and after I fix compile errors and tests my confidence that I didn't break anything is like 10 times higher than in Ruby or Python * while most of the time speed is not a major concern for backend development, it sometimes is a huge bonus. There were cases in the past when I had to spend a lot of time to optimise Ruby code, because it was just too slow (imagine rendering a lot of HTML, doing computation that is hard to do on the DB side etc) * handling JSON with serde is just on another level * Rust is very versatile. When a company starts using a language, they will naturally try to fit as much stuff into the language as possible, after all if you have mostly Python devs, you will prefer Python. A lot of people say "just use the right tool for the job", but even if there was something like "the right tool for the job", in practice it's more like: if the downsides of using our primary tech are huge, let's consider introducing a new language, otherwise let's stick with what we have. I've seen it numerous times in the past. I feel like with Rust the downsides of using it for most of the stuff are much smaller than for example for most of the other languages
- maxbond 4y agoRecently I wrote a simple forest fire simulation to test out using egui in WASM. I was impressed by how simple it was to get up and running. https://maxbondabe.github.io/forest-fire https://maxbondabe.github.io/forest-fire
- hunterb123 4y agomissing the most important part. the underbrush.
- maxbond 4y agoYeah for sure, the goal was to learn egui and validate it's portability. The logic is largely lifted from the NetLogo model library (https://ccl.northwestern.edu/netlogo/models/Fire https://ccl.northwestern.edu/netlogo/models/Fire) and represents only the relationship with density and how far a fire is able to spread. I added a couple variations for fun (like using Perlin noise).
- Thaxll 4y agoThis is not backend related though, WASM is just a binary that can be executed by the browser.
- sgt 4y agoIs Rust ready for server rendering and templating? API's are one thing but regular SSR is often useful.
- fiedzia 4y agoIf you mean old style html templates, it's been ready for many years. If you mean React style ssr, it's new but at least some frameworks have it too.
- sph 4y agoEh, HTTP with Rust is as fun as HTTP with C++. In both cases, there's people that swear they're very productive with it. I'm building an app powered by Rust, and I love it, but I'd rather use Elixir for the Web facing part. Perhaps when the whole async thing is more ergonomic I'll reconsider, but there is no chance any Rust framework can be as nice as any language running on the BEAM (or PHP, or Python, or Ruby, or Go, or Lisp), especially not as nice as Elixir can be as a website backend. Use the right tool for the job.
- lewantmontreal 4y agoLunatic runtime for Rust to avoid the async parts might become quite nice in the future: https://github.com/lunatic-solutions/submillisecond https://github.com/lunatic-solutions/submillisecond Not sure what it might take for someone to write database connectors for it but it does look promising.
- sph 4y agoLooks nice. But I'm not sure why the router needs to be a macro. What's wrong with router.get("/foo", |req, res| -> Response { ... });
- lewantmontreal 4y agoSorry, a better link would have been https://lunatic.solutions/blog/rust-without-the-async-hard-part/ https://lunatic.solutions/blog/rust-without-the-async-hard-p... Just wanted to comment on the async part that interesting solutions are being developed.
- drogus 4y agoI'm curious, are there any specific parts of the stack that make backend dev harder for you? My experience with async Rust on the backend is that it doesn't really slow me down too much, cause most of the problems are not really relevant there. Functions handling requests are usually of a form: get request data, fetch sth from the database, return a response. In this context you don't really need to care too much about async, lifetimes, ownership etc.
- IceHegel 4y agoHow much faster is this stack than the equivalent node/express setup?
- Sytten 4y agoThis is just a bad article. Yes it is ready and it's been for at least 2 years, we are building Caido (https://caido.io https://caido.io) entirely on rust from our proxy to the cloud backend and it is great. We use actix-web, diesel(proxy) / sea-orm(cloud), async-graphql. I don't want to go back to dynamically typed languages and no it's not like C++. It's a "Flask" level if you want a comparison but I absolutely hate Django (all frameworks really) so it is fine by me.
- cardanome 4y agoAre there really that many use cases in web development where you absolutely can not live with just using a language with automatic garbage collection? I can see maybe using Rust for some performance critical parts but for the daily CRUD or API? I don't get how you could justify using it. (In a professional context that is, if it's just for fun, go ahead, of course.) There are so many amazing backend-languages with huge ecosystems be it Elixir, PHP, Golang, Node or whatever you favorite poison may be. You would miss out on so much productivity. Rust is amazing but it solves a very specific problem while most of the software world is better off using garbage collected languages.
- Havoc 4y agoMy larger concern is whether it is time efficient. Rust seems quite low level. It's no coincidence that web is full of bloated frameworks - because the emphasis is on cranking out yet another generic page not optimising things to within an inch of its life.
- lza 4y agoYes! Backend: https://rocket.rs/ https://rocket.rs/ Frontend: https://github.com/yewstack/yew https://github.com/yewstack/yew I personally use lit on the frontend to talk to rocket backend.