前段時間，我有過一次非常有趣的談話。有個同事站出來支持Angular，他說Angular加快了Web開發的速度。我已經開發複雜的web服務超過10年了，曾經在Microsoft工作，也曾在Cyprus為Spotware工作。目前，我為矽谷的一個初創公司編寫應用程式。總的來說，我會順應潮流。但我感覺自
前段時間，我有過一次非常有趣的談話。有個同事站出來支持Angular，他說Angular加快了Web開發的速度。我已經開發複雜的web服務超過10年了，曾經在Microsoft工作，也曾在Cyprus為Spotware工作。目前，我為矽谷的一個初創公司編寫應用程式。總的來說，我會順應潮流。但我感覺自己像只恐龍，因為在我看來使用前端框架沒有什麼意義，但它被證明是主流。在2014年，我投入到Angular、Knockout和Backbone的世界中。如果你想弄清楚我從中得到了什麼，為什麼停止使用它們並且推薦你們也這樣做，那麼歡迎繼續往下看。
我們都知道Angular有很多問題，調試是其中一個主要的問題。當發生一個沒有文檔化的錯誤時，只有stackoverflow能夠救我們。但是我們也應該找出發生了什麼，以及最重要的找到哪裡發生的。Backbone和Knockout也有缺點。然而，很多人在使用它們，因為它們的優點更加重要。說實話，他們沒有看到別的選擇。但是，我們是有選擇的，只是我們忘記它了。
每個模塊都應該只執行一個功能，還記得這條古老的原則嗎？如果一個模塊執行了兩個或者更多的功能，我們應該將其拆分為不同的部分。我們可以找到大量的理由來說明為什麼這麼做以及為什麼我們應該堅持這樣做。無論如何，所有已有的框架都違背了這條原則。而且，“框架”這種方法本身就違背了這條原則。框架給我們帶來一定限制，它讓我們遵循最佳實踐。最佳實踐也在不斷發展，對於一個小規模的開發人員團隊來說，他們可能不會知道哪些實踐更適合一個小頁面，一個包含了數據管理的複雜邏輯的管理面板，或者具有高性能需求的多媒體網站。只有當你是一個新手程式員的時候，使用框架可以約束和規範你的代碼。我的建議是使用最佳實踐，但是不要使用框架。讓我來解釋為什麼是這樣。
框架看起來像是一些非常大並且很難重現的東西。但是它只是一些標準模式的集合。例如，Backbone模型中使用了觀察者模式，同樣在Angular和Knockout數據綁定中也使用了它，這帶來了非常好的效果。但觀察者模式只是一個很著名的模式，我們可以用30行JavaScript代碼來實現它，或者從成千上萬的現成的實現中下載一個（順便說一下，它們除了方法名字，其它都是一樣的，因為模式的原則是相同的）。框架的其它組建也是通過類似的方式實現的。在理解這些原則之後，我們在很多時候可以不用寫任何代碼。例如，當我們在一個小組件中實現MVP時，我們可以在頭腦里將這些方法分為控制器，將屬性分為模型等等。
從實踐中得到的一個示例：我參加一個西班牙公司的工作面試，在那裡我必須通過線上編碼的形式，在一個小時以內完成一個測試。這個任務是針對文檔創建一個單頁面應用程式。我使用JavaScript來完成這個任務，其中只使用了libraries模塊。我甚至有時間去寫一些測試。他們不能理解我是怎麼在不使用框架的情況下實現路由的，以及複雜的交互元素和其它很多事情。他們都是在這個行業中混跡了10年以上的資深人士，但是他們只是學習了特定的解決方案，而非原則。
學習框架，你不得不重新學習，學習那些不斷出現的新的解決方案，而且你的部分經驗會最終變得毫無價值。但是當你學習原則——原則是不會變的。為了創建類，我使用一個五年前編寫的類庫，觀察者模式的實現一直沒有變化。每一個類庫都只執行一個功能，並且執行的很好。我從來沒有想過像框架那樣，將一個組件替換成另外一個。因為觀察者就是觀察者，它是一個模式，而不是代碼。我們可能會根據任務來組合不同的模式，但模式不會改變。另外一個原則是我們可以擴展代碼，但不能修改代碼。我們可以在網上，或者“四人幫”的書中找到對應的根據。在這個原則下，如果你哥框架或者類庫有第二個，第三個或者第十個版本，一些功能會被刪除，其它功能會被修改，這會造成一些產品bug。對於修改代碼來說，唯一的好原因就是適配新的瀏覽器，但是公開方法無論在任何情況下都不應該被修改。
編程成為了市場的受害者。它們為我們提供一個“魔法”按鈕，承諾可以解決我們所有的問題。但是結果呢，我們逐漸習慣去使用它，但並不能分解複雜的問題，將小麥從麥殼中分離出來。我會去使用框架嗎？只有當編寫一個將來無需維護的產品時，我才會用框架。但如果要在一個會持續至少一兩年的服務中使用框架的話，則完全是一種自殺行為。在此期間，你將會編寫更多的代碼，比整個框架的代碼還要多，並且不止一次面對框架帶來的各種限制。你花費在編寫各種變通方法的時間，可能會比不使用框架而去實現大量必要組件的時間更多。
你不是在發明輪子。實際上，你確實是在使用類庫，但是你是根據真實的場景而非預定義的方式來組合它們。有人可能會說，框架也可以進行擴展。但是如果我想要根據我的API來獲取Backbone模型，或者根本不獲取它們，會怎樣呢？或者我想從本地存儲中獲取它們？如果我們有複雜的更新邏輯，它依賴時間和標記，而我們應該在獲取之後向另外一個伺服器發送同一個模型池，又會怎樣呢？你永遠不會知道。我們應該在這種情況下使用Backbone嗎？我們只會使用它的5%的功能，其餘的都是各種變通方法和自定義邏輯。與此同時，在理解架構原則後，我們去創建一個解決方案來適應每一個任務，並讓它可以應對需求變更，並不是一件很難的事情。
眾所周知，程式員在大部分時間並沒有在打字，而是在思考，在設計模式方面進行思考有助於提高效率。當我尋找一些有趣的架構解決方案時，我經常會閱讀一些新的類庫的公開方法。如果它的實現不是很清楚，我會查看代碼，但是這裡有一條原則，想法是最重要的。例如，我們可以在10分鐘之內完成promises，但是它的效果如何，那就是我告訴你不要學習框架而要學習架構的確切的原因。
P.S.:這篇文章就是希望能引起爭論。當然，框架有一定的優勢，但是它會讓人變成“傻瓜”。如果不使用框架，你不能解決問題，並且因此耽擱數天甚至數周，這就是一件很丟人的事情。事實上，如果我們集中註意力在正確的事情上，在架構解決方案上，就會變得非常簡單。這就是我試著告訴你的事情。希望這篇文章能給新手帶來幫助，也希望這裡描述的方法能夠讓他們將來變成非常酷的程式員。
你曾經在大型的B2C項目中使用過框架嗎？
- 是的，我使用過。這些框架的限制要比它的能力更多。
- 是的，我使用過。這些框架的能力要高於它的限制。
- 取決於項目。
- 沒有，我沒有使用過。
From : http://blog.jobbole.com/97897/#comment-155631
