Hacker News Reader

This works for small projects that only you touch. However, if you are building a product for a company and plan on having teams make changes to the code base, frameworks are the way to go.

It's even easier when hiring because a big portion of your training is already done before the person is hired and they are knowledgeable in said framework.

View on HN

I've found that the bigger problems are:

- Confusing design patterns with frameworks

- Using frameworks incorrectly

- Using a framework when a library is more appropriate

For example, Dependency Injection should start as a design pattern, and then a framework brought in based on the project's requirements. A couple of screens of "new" statements have very little learning overhead. No framework can define the way an application's modules relate with each other.

That a person is familiar with a framework doesn't guarantee they'll require significantly less learning for a company's particular project. In fact I'd argue that if one's use of a framework makes the learning curve so small, the project is probably not that complicated in the first place.

Reply on news.ycombinator.com