Replies: 1 comment
-
I don't think much has changed since the other discussion, just one thing that I don't see mentioned there is If you want a wider community discussion, I think you'll need to open this in some other format like asking on reddit for opinions. I don't think many people will discover this here without some advertising. |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
-
I understand that axum highlights its macro-free API as a key high-level feature in the docs, and there's been discussion in #2743. However, does the macro-free approach fully align with another doc description—ergonomics? This might be open to debate. Additionally, it's worth exploring how the broader web developer community perceives macro vs. macro-free APIs.
My humble opinion is that many axum users have likely worked with frameworks like Rocket, Actix, or non-Rust web frameworks such as Python's Flask/FastAPI or Java's Spring. These frameworks generally use macro-like APIs (e.g., macros, Java annotations, Python decorators) to orchestrate routes. This approach is undeniably efficient because developers can focus on defining route paths, request methods, etc., and use macro-like syntax to create routes directly. Here, the router and handler are tightly coupled, often aligning more with developers' intuitive expectations.
I hope the official team and community members can discuss: Should axum provide an official macro API as an optional feature to enhance ergonomics? :)
Beta Was this translation helpful? Give feedback.
All reactions