代码通常可以采用两种粗俗的形式：库或框架。
库是一组构建块，它们可以共享一个共同的主题或可以很好地协同工作，但是在很大程度上是独立的。
框架是包含编写代码的上下文。可以是采取控制反转，特定于领域的语言的形式，也可以只是一种很自以为是且内部耦合的库。
两者之间没有界限。判断是否为框架或库的一种方法是问自己：“我可以将其与其他类似框架结合使用吗？或者它是否建立了与其他方式可以互斥的方式？”
框架的主要特征是它们对程序员施加了限制。他们没有提供程序员可以做的一系列新事情，而是在程序员可以做的事情上建立了界限。为了换取灵活性，他们通常消除样板，为在其之上构建新库建立试金石，并允许程序员的技能成为更具可移植性的项目。实际上，有时限制本身是可取的！毕竟，类型系统不过是对代码施加限制的一种方式。局限性并不是本质上的坏处。
然而。当您编写一个期望其他人用来构建真实项目的框架（即，它不仅仅是一个玩具）时，您承担的责任要比库更大。
通常，框架必须提前预测其用户可能需要在其内部进行的各种操作。它必须承担起相应的责任。它需要提供一个正常完成各种操作的方式，否则，为什么要使用它？
这也转化为开发人员的经验。您的框架是否引入了超出基本语言的基于约定的行为？您最好彻底记录下来，否则用户将无可救药地迷路。您是否引入特定领域的语言？您现在负责构建链的一部分，并负责编辑器集成。
现在，如果有一个主要组织来支持该框架，那么计算就可能成功了。Google可以支持Angular，Pivotal可以支持Spring，Epic可以支持Unreal Engine。在这些情况下，可以采用框架方法，因为存在着资源和意愿，可以真正覆盖所有需要覆盖的基础。
因此，我的观点：框架并不总是坏的，但是与库相比，对于创建者和用户而言，框架带来的风险要大得多。如果您的框架可以是一个库而又不会损失很多，那就作为库。如果您不在大型科技公司工作，那么您可能没有时间或精力来提供框架所需的全部精力。库不是万能的，但它们应该是首选。