先摘錄並翻譯一段 wiki：
In computer programming, a software framework is an abstraction in which software providing generic functionality can be selectively changed by additional user-written code, thus providing application-specific software. A software framework provides a standard way to build and deploy applications. A software framework is a universal, reusable software environment that provides particular functionality as part of a larger software platform to facilitate development of software applications, products and solutions. Software frameworks may include support programs, compilers, code libraries, tool sets, and application programming interfaces (APIs) that bring together all the different components to enable development of a project or system.
在程式設計領域，軟體框架是指一種抽象形式，它提供了一個具有通用功能的軟體，這些功能可以由使用者編寫程式碼來有選擇的進行更改，從而提供服務於特定應用的軟體。軟體框架提供了一種標準的方式來構建並部署應用。 軟體框架是一種通用的、可複用的軟體環境，它提供特定的功能，作為一個更大的軟體平臺的一部分，用以促進軟體應用、產品和解決方案的開發工作。軟體框架可能會包含支撐程式、編譯器、程式碼、庫、工具集以及 API，它把所有這些部件彙集在一起，以支援專案或系統的開發。
Frameworks have key distinguishing features that separate them from normal libraries:
框架和普通的庫在特性上具有一些關鍵性的區別：
-
inversion of control: In a framework, unlike in libraries or in standard user applications, the overall program's flow of control is not dictated by the caller, but by the framework.[1]
控制反轉：與庫或普通的應用不同，在框架中，應用的巨集觀控制流程不是由呼叫者決定的，而是由框架本身。
-
extensibility: A user can extend the framework - usually by selective overriding; or programmers can add specialized user code to provide specific functionality.
可擴充套件性：使用者可以擴充套件該框架 —— 通常是有選擇的進行改寫（Override）或者由程式設計師新增專門的使用者程式碼來提供特定的功能。
-
non-modifiable framework code: The framework code, in general, is not supposed to be modified, while accepting user-implemented extensions. In other words, users can extend the framework, but should not modify its code.
不可修改框架程式碼：通常，框架程式碼都不打算讓你修改，而是接受由使用者自己實現的某些擴充套件。換句話說，使用者可以擴充套件該框架，但是不應該修改它的程式碼。
形象點比喻（但不夠嚴謹），框架就是條生產線，這條生產線上有很多工人（程式碼）在工作。生產線的管理者（程式設計師）負責管理這條生產線，比如說有的工序是空的，那麼你就可以安排自己的工人進去，讓他去達成你的目標。有些工序上的工人乾的工作和你預期的不同，你也可以安排自己的工人把他替換掉。
但是無論如何，你的工人除了執行你的意志之外，還要遵守那個工序的強制性要求，他想磨洋工或粗製濫造是不行的，因為這個流水線上的下一個工序可能有超時檢查或質量檢查，出了錯直接就把這個流水線給你停掉，甚至對於一些強制性檢查，你作為管理者都無權忽略它。
可以想見，一條好的生產線的價值有多大。生產線絕不僅僅是一組機器而已，它是很多年的管理經驗的結晶，這些才是最值錢的，否則光靠那些機器能值幾個錢？有了生產線，對工人（程式碼）的要求大大降低了，甚至對管理者（程式設計師）的要求也大大降低了。當然，如果你只想生產個“能穿”的鞋子，那麼這條生產線幾乎沒有附加價值，甚至會提高你的成本。但是如果你想生產一個“高質量”的鞋子，那麼這條生產線是別人的鞋子賣10塊而你的鞋子能賣到1000塊的根本保障。
總體來說，建立生產線的目標就是制定規矩，保障品質，讓高品質可以用較低的代價進行復制。框架也是如此。
從程式碼結構上看，框架在巨集觀層面使用的都是註冊、回撥機制。這種機制有一個形象的名稱，叫做好萊塢法則，為什麼叫好萊塢法則呢？因為好萊塢想要成名的演員太多了，都想去找導演，這樣下去導演的工作效率勢必會受到嚴重的影響。於是導演就立下了“規矩”，不要打給我們(Don't call us)，等我們打給你（We'll call you!）。由於這個 call 和程式呼叫的 call 是同一個詞，於是程式設計界就把這句話搬過來，變成了回撥（callback）的形象代言人。
比如在 Java 的 Spring 框架中，你只要給一個類加上 @Service 註解，它就會自動被 Spring 作為服務管理起來，當 Spring 認為需要的時候，就會建立這個類並且把它的例項傳給需求方。在 Angular 中也是一樣，你只要給一個類加上 @Component 註解（裝飾器），它就會自動被 Angular 當做元件管理起來，當 Angular 認為需要的時候，就會建立這個類，並且把它的例項傳給需求方（比如路由器）。 這些註解中還可以帶一些額外資訊，被稱為後設資料。所謂“後設資料”就是 metadata，指的是關於資料的資料，這不是 Angular 自創的名詞，其它程式設計領域已經使用了幾十年了。當 Angular 準備建立一個元件的時候，它就會找到這些後設資料，從中找出這個元件的模板（因為元件本身是純類，沒有攜帶任何模板資訊），然後據此對 DOM 進行操縱。
而你寫的這些元件類和模板，其實就是“由程式設計師新增專門的使用者程式碼來提供特定的功能”，因為框架是不會關心你的元件的外觀和邏輯的，它唯一關心的就是你必須遵循它的規範來工作，否則它就會給你報錯（比如，“連模板都沒有還敢說自己是 Angular 元件？”）。
而庫則跟框架相反，巨集觀上說，它是等著你呼叫的，你要什麼功能它就給你什麼函式，然後你呼叫這個函式，把所需的引數傳進去就行了，而不是讓你遵守它的那麼多規矩。所以你很自由，但是你也要自己為整件事負責。你要自己建立元件、建立服務等，自己來驅動整個流程，自己做必要的檢查，當然也可以不做，反正對十塊錢的鞋子別人可能只希望能穿一個月就行了。
那麼，問題來了，框架一定會比庫高階嗎？顯然不是，甚至連框架的功能都不一定比庫多。它們只是定位不同、設計理念不同而已。對於 Angular 來說，它會更希望你遵守一些規矩，這樣當系統需要長期維護、甚至要經歷很多人員更迭的時候，才不至於腐化。它希望每個開發人員都不必瞭解應用的全貌就能很好地完成工作（因為有當前工序的操作手冊和檢查點）。當然，它也不會干涉那些它不需要關心的事情，比如元件模板中你放 h1 還是放 div 它是不在乎的。這些目標用庫也能達到，不過對人員的架構觀和做事的自律性會有相應的要求，畢竟沒人管了，那你自己就不能放任自流。
然而，在現實中，很多應用的整個生命週期可能都不會超過一年，甚至還有很多生命週期幾天的活動頁，那麼，這些應用和頁面的可維護性其實並不重要，甚至連是否能讓不同的人協作都無所謂。那麼點功能，能出什麼 bug？一次性的需求，管什麼可擴充套件性？這時候，學習成本就會成為一個很重要的參考因素。
學習 Angular 最難的就是遵守並理解規矩。然而大部分人天生是不願遵守規矩的，特別是有些規矩可能他都無法理解為什麼（雖然這可能是前人根據血的教訓總結出來的）。可是，一旦遵守並理解了這些規矩，那麼一扇新的大門就對你敞開了，你會發現跨上這個臺階之後，無論前端技術還是後端技術還是移動端技術，都遵循著很多相同的理念，即使出現了新的挑戰，你也可以套用這些理念去解決。
規矩即自由。孔子把“從心所欲，不逾矩”當做自己的最佳狀態，其實很多事都是這樣。一旦深刻理解了設計和使用框架的思維模式，你將迎來一個實質性的提升。
在我工作的前五年，程式設計時很“聰明”，用技巧解決了很多問題，但之後的十五年（恰好在那一年我知道了框架的概念），我愛上了規矩，不但自己給自己（根據血淚教訓）立各種規矩，而且從別人那裡借鑑了很多規矩，無論是巨集觀的還是微觀的。可以說，規矩就是固化的好習慣，雖然有時候也會成為阻礙，但是如果你想在程式設計領域工作到退休，那麼這些規矩就是你表面上最大的資產，而對這些規矩的來龍去脈的理解和領悟，則是你深層次中最大的資產。