Framework, Micro-Framework or Neither

Frameworks earn their weight

Routing, authentication, database access, validation, templating, background jobs and testing infrastructure are all solved problems. Writing them again is expensive and produces something less secure.

The argument against frameworks is usually about performance, and for typical business applications the difference is irrelevant compared with database and network time.

Match the tool to the job

What matters in the choice

1. How well maintained it is, and its release cadence
2. How easily you can hire people who know it
3. Documentation quality, which affects everything
4. Ecosystem — what already exists for common needs
5. Upgrade path between major versions

Hiring availability matters more than most technical criteria. A framework nobody in your market knows is a maintenance risk regardless of its merits.

Do not fight the framework

Most framework problems come from working against its conventions. If you find yourself repeatedly circumventing it, either the framework is wrong for the job or the approach is.

Following conventions makes the code predictable for the next developer, which is most of what maintainability means.

Keep business logic separate

Whatever framework you choose, the business rules should be in classes that do not depend on it. That makes them testable, portable and comprehensible independent of the web layer.

It also means a future framework change is a rewrite of the edges rather than of the system.

Frequently asked questions