Rust needs a web framework for lazy developers
The author advocates for a simplified Rust web framework, "newt," to ease development for non-commercial projects, addressing current complexities and promoting a more integrated ecosystem with essential features.
Read original articleThe author discusses the need for a web framework in Rust that caters to developers looking for a simpler, less labor-intensive approach to web development. Currently, Rust's web development landscape is characterized by minimalist frameworks that require extensive setup and integration of various components, making it cumbersome for developers who want to create non-commercial or "silly" projects. The author outlines essential features that such a framework should include, such as routing, templating, static file serving, user authentication, permissions, database interfaces, and more. They express frustration with the existing ecosystem, which consists of numerous libraries that do not integrate well, leading to a steep learning curve and maintenance challenges. The author envisions a comprehensive toolkit, named "newt," that would streamline the process of building web applications in Rust, allowing developers to focus on their projects rather than the setup. They hope to inspire others to create similar frameworks to enhance the Rust web development ecosystem.
- There is a demand for a Rust web framework that simplifies development for non-commercial projects.
- Current Rust frameworks require extensive setup and integration, making them less accessible.
- Essential features for a new framework include routing, templating, user authentication, and database interfaces.
- The author is developing a toolkit called "newt" to address these challenges.
- A healthy ecosystem would benefit from multiple such toolkits to support diverse development needs.
Related
Show HN: Plain Vanilla – a tutorial website for vanilla web development
The article discusses web development using only HTML, CSS, and JavaScript, emphasizing Web Components and modern CSS. It encourages experienced developers to explore this simpler, standards-based approach for building applications.
Going Buildless
The article explores "buildless" web development, highlighting advancements in HTML, CSS, and JavaScript that simplify workflows. It suggests this approach is ideal for smaller projects, enhancing the developer experience.
Building the Same App Using Various Web Frameworks
The author compares web frameworks FastAPI, FastHTML, Next.js, and SvelteKit by building the same application, noting their unique features and complexities, while expressing interest in TypeScript and learning resources.
Master Hexagonal Architecture in Rust
The guide on hexagonal architecture in Rust promotes scalable applications by emphasizing separation of concerns, introducing the repository pattern, and providing practical examples for effective implementation and incremental learning.
Web Components Are Not the Future – They're the Present
Web Components are currently relevant, enhancing interoperability across frameworks. The article advocates for collaboration among developers to improve web standards and emphasizes the need for frameworks to adapt to these standards.
- Many commenters question the suitability of Rust for "lazy" development, suggesting that its complexity may not align with the goal of minimal effort in web projects.
- Several existing frameworks like Rocket, Actix, and Axum are mentioned as alternatives, with some users expressing satisfaction with their capabilities.
- There is a call for a more integrated, "batteries-included" framework in Rust, akin to frameworks in other languages like Django or Rails.
- Some commenters argue that Rust's strengths lie in systems programming rather than web development, advocating for using other languages for web applications.
- Concerns about the learning curve and documentation for Rust web frameworks are prevalent, with suggestions for better resources to aid developers.
The author mentions flask but looking at the "What we need section", I don't think flask covers those. I hate Djago with a passion but if those are the requirements, I think Django is the one that closely resembles what the author is describing. So Poem is not a good candidate either in that regard. Poem is all in all, something that closely resembles FastAPI, which is actually a complement. I've tried half a dozen rust web frameworks and they all come with a ton of boilerplate fiddling with the initial setup. Which is a problem if you want to get things done fast. In that regard, poem nails it. Yes, actix has a considerably better performance but unless you are aiming for sub-30 millisecond responses, then actix is not what you should be looking at to begin with. Also if you crave a Pydantic, there is a crate that sort of does that for you: https://crates.io/crates/poem-openapi
Rocket is maybe the closest? But it's not as batteries included as any of the frameworks I've mentioned.
Sure, some people like choices and tinkering, but in many settings it’s much more productive to have the choices curated for you.
“But what if you want a different X instead? It might be Y% better!” is the typical comment, which ignores that the integration itself provides enormous value. Discrete libraries may be best of breed individually, but may be a heap of garbage if they don’t fit together smoothly.
I love programming in ASP.NET 8 specifically because I never have to think about whether a templating system will play nice with authentication, injection, routing, or anything else.
What sets these projects apart from frameworks like leptos is that there's a CLI guiding you. That's what I love about Symfony, and what I consider the 'lazy' part.
You don't need a router when you have pattern matching (just split the url and match on static and dynamic vars however you need)
Auth is typically DIY in any language, or SaaS like Firebase/Auth0. It's not a language or framework problem, necessarily
CSS/JS tooling makes no sense for many frontend Rust frameworks like Dominator, which is in Rust (not JS) and has its own approach to styling that works for it (e.g. attaching styles to signals, so they change on the fly)
I get what the author is saying - in fact I've been around the block a couple times solving all the different points in the article and it is painful. For example, see https://github.com/dakom/dominator-workers-fluent-auth which does a lot of the stuff here on the Cloudflare workers framework (also adds another wishlist item - localization with Fluent)
A "batteries included" full framework that does _everything_ is nice to have, but many real-world projects will want to replace those opinionated decisions and go the DIY route anyway. Rust is more than mature enough, even on the frontend web, to tackle all of that - if you know where to look (wasm-bindgen, etc.)
A systems language with a high cognitive barrier to entry, compile times and less than a decade of wide adoption can’t reasonably be expected to compete with something like Rails in terms of approachability
I'm switching to Flutter for my UX needs. There's flutter-rust-bridge that binds Rust code concurrently without any headaches in the client, and I can deploy to the web, android, Linux, etc. with ease. Looks p. good out of the box. Got GRPC working quickly, am happy.
Using Rust in the client is nice because I have a single workspace that contains all of my business logic. Backend changes will cause errors in the client code if changes are necessary. The codebase is easy to refactor and trust. Dart ain't half bad.
I stayed away from Flutter at first because it doesn't respect the DOM etc but at this point I'm willing to sell my soul to the devil for how easy it is to make a great UX that deploys anywhere.
I don't love relying on something Google made, though. Feels a little like building a foundation on sand.
There is no one web framework that will satisfy all criteria and all layers of what a web framework needs. Every so often we have to migrate as technology catches up and changes the ecosystem, like wasm did with Blazor.
I’d rather have a language that programming is a joy in. The laziness is a nice side benefit. I can adapt such a language to changing landscape any day. I know Ruby is such a language, and hence Rails adopts it’s joyful mentality. But is Rust a joy to program for? That I can’t say for sure.
Don’t fear, Rust can be as simple and clever as any other language. And the Rust core OSS developer community has spent at least the last ten minor versions improving dev ex considerably.
Yeah, it’s called loco https://loco.rs/
FWIW I prefer the pile of libraries. Big frameworks are good for scrappy startups trying to push their product out asap, but in most of situations, I’d like a lower abstraction system to build on.
"Do I need zero cost abstractions because I'm writing a computationally expensive very serious project?" If the answer is no use a garbage collected, runtime managed language.
I think a good part of the devs community has been burned by some framework at some point and doesn't feel the need for web frameworks, hence why nobody bothered to make Rails for rust. In a professional setting, all the services I interact with, have been implemented on top of express (node.js) or fast-api (python). I know people working in ecommerce who rely heavily on django or woocommerce, but rust usage among them is pretty low.
Rust is also one language where there are very little junior people, so you'll see wire-it-yourself library more than frameworks. Eg. sqlx is imho the best compromise in the ORM vs query builder vs plain sql debate: you get typechecked plain sql.
I think axum is very well architected and type checked routes offer a great DX (except for the tower::Service compatibility - sure, it's nice to have compatibility but the resulting code is quite clunky), and I'd rather have smaller components I understand over a huge black box.
I look at Rust for serving web-traffic and I see: dreadful concurrency model (I will never voluntarily go back to async/await after working in Golang), weak client library stories (if I'm writing a service layer for a db, etc.), high barrier to entry, thin overlap with the core Rust value proposition (correctness around memory access, performance).
That's not even addressing the "what happens when my entry-level dev has to write something that interops with a web framework written in Rust." My heart can't take those code reviews, I might as well just write that shit myself without a framework for all the pain that's going to cause.
Note: I don't write a ton of Rust, for reasons that are maybe kind of obvious. I reach for it whenever C seems correct, which is rare but not never (for me).
I want to make an app in Rust that hosts Servo in it with my business logic in maybe SciterJS - like electron but hopefully lighter?
Something, just a business software guy who wants something with more control than an webapp and not so heavy like electron.
Laziness isn't necessarily a bad thing, depending on how it's implemented.
Any framework is too much extra work to learn and going to eventually get you shot in the foot.
Jetty, HAProxy, JSTL, commons db connection pooling and Postgres.
Prototype is easy and fast. Scales well to very large user base on a single node. Interactive client side without even writing JS.
I love rust, I really do, I use it for all kind of things. But for web app, the Erlang architecture is so well designed and mature you cannot compete.
Also we use rust and zig from Erlang with native modules for video processing and AI, the elixir/Erlang "skin" gives you immense flexibility and productivity with almost no performance hit.
In my opinion you should for 99% of cases use Golang for your web backend. Any other languages there are tradeoffs you are making.
Go:
- very easy to learn and grok Go code
- static typing
- fast compilation
- single binary (easier deployment)
- strong standard library
- large library ecosystem
- go routines for concurrency
- highly performant
Maybe Java,Kotlin and C# but they are still an order of magnitude more complex and resource heavy than Go.
Rust can fit in that picture, but it doesn’t need to be routing http.
Yeah yeah I know <whatever> Framework is great and good for stability or something, but using a framework makes something that I enjoy (programming) feel more like filing out my taxes, just so I can end up with a mediocre CRUD application that more or less works for the project I am working on.
I have removed myself to from the web and programming almost instantly became more fun for me again.
Learn multiple languages.
The whole "I want to do everything in the language I already know" is why the least interesting--and straight-up pretty terrible albeit very capable--languages are dominating our field.
And development in rust is glacial. It's no one language featurep (not complaining about the borrow checker in particular), but the accumulative overhead of all of them acting in weird ways.
I will say the tooling is absolutely amazing, it's nice to span "app level" and "systems level" concerns in a single language. But it is a lot of language.
Rust already has excellent libraries that are easy to use in many different stacks.
Write one?
I have not seen such a success story for any Rust web framework yet. Although I would love to see one (or more!)
>Routing/handlers
Actix has it.
>Templates
Minijinja or liquid-rust[1]
>Static file serving
actix-files[2]
>Logins
Actix with oidccore is fantastic and easy[3]
>Permissions
Actix FromRequest is literally perfect. We have perm levels (admin, owner) and per-route perms for more fine-grained control.[4]
> Database interface
Diesel with diesel_async for connection pooling has been flawless at scale.
> Admin tooling
We didn't do this, but it would be simple with a bin/load-data.rs file that runs via a docker start command or tmuxp pane.
> Hot reloading
Cargo watch is getting deprecated, but was great. Bacon and and Watchexec are fully qualified successors. CSS watch systems work with the templates already same way as they do for SPAs.
> Background tasks
Make a bin/worker.ts file which defines a single binary and then use redis or another queing sytem to communicate between the worker and core server. We loaded all of HN (40M docs) into a search index with this approach and it was easy.
> Monitoring/observability
There's a decent story here with structured logging. Zero to production in Rust has a good chapter on it (2020) [5]. Lots of progress has been made since and exposing prom metrics endpoint is straightforward [6]. Sentry support is also decent and they sponsor actix.
> Caching
Imo, the story with Redis + actix is fine. We do this with our auth middleware to reduce latency on that operation since it happens with every route and I think it's smooth with FromRequest.
> Emails and other notifications
What's wrong with SMTP? Plus, Keycloak will handle your password reset infra out of the box. SDKs here could be better, but the APIs are fine and not too bad to do with Reqwest yourself.
> Deployment tooling + CSS/JS bundling
Imo, both of these things are the same as with other languages. Rust could use more documentation, but I don't think there's anything making it particularly hard to use.
[1]: https://github.com/devflowinc/hn-search-RAG/blob/main/actix-...
[2]: https://github.com/devflowinc/hn-search-RAG/blob/main/actix-...
[3]: https://github.com/devflowinc/trieve/blob/main/server/src/ha...
[4]: https://github.com/devflowinc/trieve/blob/main/server/src/ha...
[5]: https://www.lpalmieri.com/posts/2020-09-27-zero-to-productio...
[6]: https://romankudryashov.com/blog/2021/11/monitoring-rust-web...
I think this part is perhaps the silliest part of a very silly article. If you really like to put in a minimal effort then why on earth would you use Rust? If you want efficiency, memory management and a compiled modern language just use Go. Then you won’t even need anything but the standard library for what you want to do. Or… use Django as you suggest?
Yes, yes we use Rust in production because we thought it would be easier (well safer) to teach to interpreted language OOP developers than c/c++ but why on earth would you ever use it for the web unless you are a member of the cult?
I'm an incredibly lazy developer and Rust only makes me lazier. I can pretty much turn off the part of my brain that deals with "programming language" stuff and put all that energy towards the part of my brain that deals with "building stuff" whenever I write code in Rust, because I have a high level of confidence that the language itself isn't trying to make me shoot myself in the foot at every turn.
Rust is the only language where I can open something like Notepad without an LSP or highlighting, write code for an hour without testing or compiling, and then run clippy a few times to see and make the suggested fixes. It doesn't get any lazier than that.
On the web framework topic: Rocket is the greatest "lazy developer" web framework I've ever used.
Wait, what, you think we need another web framework?
.....buuuut, if you spend more than 5 second actually reading the article...
> This doesn't exist right now, and I'm not sure if anyone else is working on it. All paths seem to lead me toward "whoops I guess I'm building a web framework." I hope someone else builds one, too, so we can have multiple options.
...
> My toolkit is called nicole's web toolkit, or newt. It's available in a public repository, but it's really not usable (the latest changes aren't even pushed yet). It's not even usable for me yet—this isn't a launch post, more shipping my design doc
ie. -> https://git.sr.ht/~ntietz/newt/tree
Is where you can find the code, for what they're trying to make, to fill this gap.
Sure. Not a web framework. An all in one opinionated good out of the box defaults like rails.
Yes, there's no django/rails for rust.
Or go. Or clojure.
In fact, a lot of people have tried to make all-in-one frameworks, but usually the way the wind blows is that doing something specific is easy, but doing something flexible and generic is hard, a lot of work, and unless you're being paid to do it, it's a loveless job that eventually you get sick of and abandon.
I feel like if you're really going to go and write a rails clone, you need to spend a little bit of time digging into some of the other failed attempts and reasons they failed (eg. 1, 2, 3) first.
The landscape is littered with aborted rails clones.
It's perhaps... fun, but ultimately futile and naive, to think you can be 'the one that makes it' when so many others have failed, if you don't take the time to understand why so very very very VERY many attempts to do this in many languages has failed.
(NB. Not to pick on clojure; I could have picked a bunch of go examples instead, but I guess the clojure failures have been particularly visible to me since I use clojure, and it's a place where, like rust, currently there are a lot of 'bits and pieces you can assemble yourself' and it feels like, surely just slapping them all together in one package can't be that hard...)
[1] - "Clojure needs a Rails" https://news.ycombinator.com/item?id=32288291 [2] - "A Rails like framework for Clojure." https://news.ycombinator.com/item?id=822210 [3] - "Luminus – A Clojure Web Framework" https://news.ycombinator.com/item?id=22852375
When she says lazy, she just means that she'd like a web framework that takes care of the most common and obvious schleps that are needed to create a web framework, like routing and so on. Once you get those schleps out of the way, there's still tons of work that needs to be done. Nothing lazy about that.
How do you convince someone to use an alternative? The knowledge needed to understand why will help you get close enough in Next.js anyway.
I don't see myself doing it any other way these days.
Related
Show HN: Plain Vanilla – a tutorial website for vanilla web development
The article discusses web development using only HTML, CSS, and JavaScript, emphasizing Web Components and modern CSS. It encourages experienced developers to explore this simpler, standards-based approach for building applications.
Going Buildless
The article explores "buildless" web development, highlighting advancements in HTML, CSS, and JavaScript that simplify workflows. It suggests this approach is ideal for smaller projects, enhancing the developer experience.
Building the Same App Using Various Web Frameworks
The author compares web frameworks FastAPI, FastHTML, Next.js, and SvelteKit by building the same application, noting their unique features and complexities, while expressing interest in TypeScript and learning resources.
Master Hexagonal Architecture in Rust
The guide on hexagonal architecture in Rust promotes scalable applications by emphasizing separation of concerns, introducing the repository pattern, and providing practical examples for effective implementation and incremental learning.
Web Components Are Not the Future – They're the Present
Web Components are currently relevant, enhancing interoperability across frameworks. The article advocates for collaboration among developers to improve web standards and emphasizes the need for frameworks to adapt to these standards.