一直不能分別前端框架和類庫（我這個前端也是假的吧？），結合各位前輩的思想，整理了一下：
前端框架與前端類庫的區別
使用框架前，我覺得很重要的一點是弄清類庫（諸如jquery）和框架（諸如angularjs)的區別在何處。
簡單而言，類庫，解決的是**或者是模組級別的復用或者對複雜度的封裝問題，例如將乙個解決複雜問題的功能模組封裝成乙個函式，提供乙個簡單的介面。庫它是一種工具，它提供了很多封裝好的方法，用與不用取決於我們自身，即使用了也不會影響我們呢的**結構。
而框架，更多的是對模式級別的復用和對程式組織的規範。這裡的模式是指比如mvc，為了實現m和v的解耦，把複雜的耦合關係由經常變化的業務**轉移到不經常變化的框架內部消化。是面向乙個領域來提供一套解決方案，提高開發效率，如果我們選擇了使用某框架，就應該遵循該框架所規定的規則。
二者最主要的區別是：jquery以dom操作為中心，框架，準確來說是mvc框架，是以模型（model）為中心，而dom操作是附加的。所以，以模型為中心最終達到的目的是帶來一整套工作流程的變更，使得後台工程師可以編寫前端的模型**，把後台與前端打通，互動設計師處理ui跟模型的互動關係，ui設計師可以專注、無障礙的處理html原始碼，把它們以介面模板的形式提交給互動工程師。這一整套協作機制能大大提高開發效率。使用mvc框架使得前端任務更好的被解耦。
前端mvc框架思想
我們知道，傳統的mvc模式將乙個應用劃分為——模型層（model）、檢視層（view）、控制層（controller）。他們在應用系統中擔當不同的角色，完成不同的任務。
view：檢視用來有目的顯示資料，在檢視中一般沒有程式上的邏輯，為了實現檢視上的最新功能，檢視需要訪問它監視的資料模型。
controller：控制器調控模型和檢視的聯絡，它控制應用程式的流程，處理事件並作出響應，事件不僅僅包括使用者的行為還有資料模型上的改變。通過捕獲使用者事件，通知模型層作出相應的更新處理，同時將模型層的更新和改變通知給檢視，使得檢視作出相應改變。因此控制器保證了檢視和模型的一致性。
那麼在前端中的表現。前端mvc中各部分的職責：
我對前端的view的理解是，與頁面上元素直接相關的部分都屬於view。包括html，css和一部分直接控制頁面元素的js。可以從model中得到資料，並將其顯示到頁面上。而關於資料的變更與請求，則統統交給controller處理。
那麼controller呢？作為model和view的粘合劑，controller將view方面的請求**給合適的model，在必要時也會去更新view。而controller本身也可以作為model的觀察者，獲取model的變更。而作為controller本身，就不應該有涉及到頁面元素的**了。
最後談談model，與後端的溝通、ajax請求以及對資料的處理都屬於model的工作。model本身不知道誰是view，誰是controller。它只提供一些方法供view和controller呼叫，並且將變更通知給它的觀察者view或controller。顯然，model與頁面元素之間也解耦了。
雖然基於mvc模型的框架之間也有很多不同之處，但是總體而言，model負責儲存vier需要的資料以及資料處理邏輯，例如讀寫，更新，刪除，驗證，轉換等。view負責接收並顯示model提供的資料以及接收使用者的輸入，並且響應事件，model更新後及時將更新反饋回使用者。controller處理業務邏輯和事件邏輯。
記錄幾個前端必備的庫 框架
underscore.js 擴充了 array 和 object 相關 api moment.js 擴充了 date bluebird.js hax my promise 實現了 promise async.js 模擬了 async 操作符 es5shim 用 es 3 語法部分實現了 es 5 特...
記錄幾個前端必備的庫 框架
underscore.js 擴充了 array 和 object 相關 api moment.js 擴充了 date bluebird.js hax my promise 實現了 promise async.js 模擬了 async 操作符 es5shim 用 es 3 語法部分實現了 es 5 特...
前端開發框架 前端開發框架Angular生死年
這個標題，並不是說前端開發框架angular明年就會火或者會死去，而是說，今年將會決定它接下來死活的趨勢。舉例乙個跡象 twitter在2019年轉向react，netflix也有同樣的意向。而這兩家公司，之前都是用ember。ember框架，和angular非常近似。基本上，就是填了一些坑的另乙個...