Building any non-trivial app, one of the toughest decisions to make is which development framework to base your work on. And there’s no way around this decision once you realize there’s no such thing as “not using a framework.”
Even if you’re just binding together 3rd party components, a framework will be born out of any development work, and it will have its own tradeoffs to consider.
- Will it be documented?
- Will it be tested?
- Will it have a community of people working on/within it?
- Will it have a plugin architecture encouraging code reuse?
- Will you have access to plugins written by people outside your team?
- Will configuration be easy/reusable?
- Will it address code/UX scenarios you hadn’t considered?
- Will you get free bug fixes/features from outside developers?
- Will it securely handle password and protection against XSS, CSRF, etc.?
- Will other developers be able to jump into the project?
Developers, plugins, sub-frameworks, tools, and shops all form an ecosystem around a framework that tends to build value as it grows. A strong ecosystem can make up for product weaknesses; a trip through the Drupal and WordPress codebases will have some seasoned developers shuddering at some architectural choices made (long ago), yet that code runs great due to the work of tons of people over time. And, thanks to the wealth of plugins available, and to the continual transfer of knowledge from one developer to the next, devs who are experienced on those platforms can build impressive systems quickly.
On the flip side, there are properties of mature frameworks that are important to consider:
- They can be slow to change, which may mean maintaining a separate git branch with your own fixes.
- They rarely bend to support the use cases of individual sites.
- They tend to have older code that may be harder to integrate with the latest practices.
- They can be large; any framework that solves a lot of problems out-of-the-box will be. Microframeworks can be a great choice, but their value tends to be limited to plumbing.
Thankfully the ideal framework needn’t be chosen first. You may be better off prototyping something as quickly as possible—by any means—then rebuilding after the requirements are clearer. The danger is the temptation to ship prototypes as production systems, where they grow to become liabilities over time.