Our great sponsors
-
django-debug-toolbar
A configurable set of panels that display various debug information about the current request/response.
-
WorkOS
The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.
-
-
Bootstrap
The most popular HTML, CSS, and JavaScript framework for developing responsive, mobile first projects on the web.
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
Django Debug Toolbar provides something akin to the browsers Developer Tools but for Django's server-side stuff. It makes it easy to check and fine-tune what Django ORM is generating.
I wrote a good number of macros though, both macro_rules! and various proc_macros. The latest iteration of overflower has both, for example. mutagen is a mutation testing tool built as a proc macro, and it's helper library has a bunch of macros, too. compact_arena uses macros to tie unique lifetime tags to arenas.
That's why I use Sailfish for server-side templating in my Rust web projects. It's ridiculously fast.
I think we're going to have to agree to disagree on that. To me, for a site that's not a full-blown web application, "an appropriate web framework" means something like Twitter Bootstrap.
I'm probably in the minority on this one, but I really hate writing verbose, repetitive code, so I freaking love macros. I will frequently use a one-off macro just to make something like a dispatcher function easier to read by cutting down on all the pomp and circumstance. I'm also working on a small crate that makes heavy use of proc macros, which I've already gotten a ton of mileage out of since it allows me to spin up a serviceable lexer with just a few lines of code. A lot of people really dislike macros because the source is hard to read and they're onerous to debug. They're not wrong on either of those points.
Using a single file per module does seem to be the most popular way to organize things in the ecosystem for whatever reason, but I personally do like to keep my files pretty short, so yeah, I usually split up non-trivial modules into a folder with submodules. You can take a look at this project for kind of an extreme example.
Is that extreme example of splitting? To me it works fine. From couple years I'm working with Vue, Nodejs, Typescript, Ruby on Rails and there this file setup you showed me are totally normal and gives good readability if made properly. I.e. look at this repo. It's kinda extreme to me. Not only about file splitting but also tests for any html component etc. Here are example graphlql api structure I've written for my projects in NodeJS + Fastify + Mercurius (GraphQL server). And you'll probably understand basic purpose of it and what should be found where. That's why I'd like to do same in Rust.