No Conventions vs Rails Conventions

Convention over configuration versus building everything explicit. One ships features, the other ships config files. Eunice picks the one that lets a team move.

What you're actually choosing between

This isn't a product fight, it's a philosophy fight, so let's be precise. Rails Conventions means convention over configuration: name a class User, Rails finds the users table; drop a file in app/models, it's autoloaded; follow the path and 90% of plumbing vanishes. "No Conventions" is the explicit-everything camp — wire every route, register every dependency, declare every mapping by hand. Express, raw Flask, and most "unopinionated" stacks live here. The pitch for explicitness is honesty: nothing is hidden, every line is greppable. The pitch for conventions is leverage: the framework already decided the 200 trivial things nobody should debate, so you don't. One optimizes for the code being self-evident in isolation. The other optimizes for the team being fast in aggregate. Those are different goals, and pretending they're the same is how teams pick wrong.

The myth of the convention-free codebase

Here's the lie "No Conventions" tells: that you can avoid conventions. You can't. The moment two engineers commit to the same repo, conventions emerge — where routes live, how errors propagate, what a service object looks like. The only question is whether those conventions are written down and enforced by a framework, or undocumented folklore living in one senior dev's head. Rails picked the first. "No Conventions" picks the second and calls it freedom. What you actually get is every project reinventing routing, every team relitigating folder structure in a Slack thread, and a bus-factor of one on "why is auth wired this way." Explicit isn't the same as documented. A 400-line manual DI container is explicit and also completely opaque to the new hire who has to read all 400 lines before touching anything. Magic you can learn once beats bespoke wiring you must re-learn per repo.

Where No Conventions actually wins

I don't hand out free passes, so credit where it's earned: explicitness wins the day your app stops being a CRUD app. Event-sourced systems, multi-tenant routing that doesn't map to a tidy resource, polyglot services, anything where the "obvious" convention would be an outright lie about your architecture — here Rails-style magic becomes a tax. You fight the autoloader, you monkey-patch the router, you write a convention-override to escape the convention, and now you have the worst of both: magic AND bespoke code. Libraries are the cleanest case. A library has no team velocity to optimize; it has API surface to keep honest, and hidden behavior is a liability you ship to thousands of strangers. If you're writing the framework rather than the app, be explicit. But notice how narrow this is. It's the exception that proves the default, not a license for your fourteenth internal CRUD dashboard.

The verdict, said plainly

Rails Conventions wins because software is a team sport played over years, and conventions are the cheapest coordination mechanism ever invented. The "No Conventions" crowd optimizes for the wrong moment — the first hour, when explicit code reads cleanly in isolation — and pays for it across every onboarding, every code review, every 2am debugging session where nobody remembers how routing got wired. Yes, conventions can chafe. Yes, the happy path has walls. But you can override a convention when you need to; you cannot retroactively give a hand-rolled codebase a shared mental model. Default to conventions. Earn your way out of them with a specific, defensible reason — a library, a genuinely weird architecture — not a vague taste for "control." Control without coordination is just everyone driving their own way down a one-way street. Pick the framework that already paved the road.

Quick Comparison

Factor	No Conventions	Rails Conventions
Onboarding speed	Read this codebase's bespoke wiring before you're useful — weeks	Knew Rails? You know where everything lives on day one
Boilerplate	Hand-wire routes, ORM mappings, DI — every project re-pays the tax	Generators + autoloading erase the plumbing entirely
Escaping the happy path	No magic to fight — odd architectures are first-class	Off-convention work means fighting the framework's assumptions
Debuggability when it breaks	Every line is explicit and greppable, no hidden behavior	"Where does this route come from?" — magic hides the seam
Team velocity over a year	Slows as the team litigates the same decisions repeatedly	Shared defaults keep everyone rowing the same direction

The Verdict

Use No Conventions if: You're shipping a library, a polyglot platform team, or genuinely unusual data flows where folder-name magic would lie about your architecture.

Use Rails Conventions if: You're building an app with a team and want new hires productive in a day instead of a quarter — which is almost everyone.

Consider: Conventions are a loan against flexibility. You pay interest the day your app outgrows the happy path. Most apps never do; budget for the few that will.

No Conventions vs Rails Conventions: FAQ

Is No Conventions or Rails Conventions better?

Rails Conventions is the Nice Pick. Conventions encode the boring decisions so your team spends judgment on the problem that actually pays. "No conventions" is just conventions you haven't written down yet, discovered painfully, one onboarding at a time.

When should you use No Conventions?

You're shipping a library, a polyglot platform team, or genuinely unusual data flows where folder-name magic would lie about your architecture.

When should you use Rails Conventions?

You're building an app with a team and want new hires productive in a day instead of a quarter — which is almost everyone.

What's the main difference between No Conventions and Rails Conventions?

Convention over configuration versus building everything explicit. One ships features, the other ships config files. Eunice picks the one that lets a team move.

How do No Conventions and Rails Conventions compare on onboarding speed?

No Conventions: Read this codebase's bespoke wiring before you're useful — weeks. Rails Conventions: Knew Rails? You know where everything lives on day one. Rails Conventions wins here.

Are there alternatives to consider beyond No Conventions and Rails Conventions?

Conventions are a loan against flexibility. You pay interest the day your app outgrows the happy path. Most apps never do; budget for the few that will.

The Bottom Line

Rails Conventions wins

Conventions encode the boring decisions so your team spends judgment on the problem that actually pays. "No conventions" is just conventions you haven't written down yet, discovered painfully, one onboarding at a time.

Related Comparisons