[轉載]JavaScript 的輕框架開發

http://www.open-open.com/news/view/1d64fed

爲何咱們不用 Angular, Ember 或者 Backbone！

Muut 是一個特殊的論壇平臺，它也有着巨大的夢想！ 當後端的性能已經極大優化的同時，前端也有着本身的目標：簡單API，小體積，快速迭代。寫代碼就像在紙上先起個草稿，而後寫入到許多文件中便可（猜 譯）。任何一個前端框架，好比，Angular 或者 Ember 都沒問題！

下面是咱們本身實現，而不用它們的緣由。

首先是 API 方面的因素

開發 Muut 客戶端時，咱們基本的要求是簡單的 API。它必須易用，沒有額外的屬性方法，不該該提供新的編程習慣（即不要製造另類的代碼語法）。它應該易上手。不只最終用戶用它，並且我的也要用它，由於全部的網頁界面都創建在它之上。

開始設計API以前，一般要先打好草稿。一個乾淨的桌子、一支筆、一張紙。我開始站在使用者角度構思API。從沒有一切框架開始。

API 在 MVC 中是一個模塊，要用 POJO（Plain Old JavaScript Object） 的形式。由於框架提倡API的設計必須"single source of truth「。API不只能跑在瀏覽器上，也能在後端（node.js）執行。它必須徹底獨立且易單元測試。

我不喜歡交差相關的方法及屬性把API搞雜亂。Backbone.Model.extend 和 Em.Object.extend 都添加了大量的方法，給用戶使用增長了複雜度。違背簡單的目標，它不被咱們接受！

 

小體積

更小的文件會更快加載，節省帶寬。這是看得見的利益。更大的優點就是代碼維護。小代碼更容易把握，更快學會，更少的條條框框。

目前 Muut 客戶端壓縮後是 89kb，gzipped壓縮後是 32kb。這比其它的論壇平臺要小10 倍。體積明顯很重要，當一半的網絡訪問來自於移動設備，開發人員就會尋找小工具來完成他們的工做。

下面的表會讓你知道，咱們使用的具備獨立功能的工具應該是多大的體積。下面列的是我也在使用的，我正好作一下對比，如下均是minified後的大小：

模版、綁定、表單驗證	Backbone.js	33.9kb
語法加亮，支持20+語言	Rainbowjs	28kb
提示，遮罩層，下拉框、標籤切換等	Misc. tools	20kb
WebSocket communication	socket.io	40kb
Markdown 分析器	markdown-js	23kb

在實際的項目開始以前，這些大概就已經有150kb了。

當前，Muut的包含界面視圖、控制器（api與視圖之間的結合代碼）等合併後再minified，僅40kb。一個框架應該是多大呢？框架的 目標是更小的工做量去達到目標，因此它應該很小。40 kb是容易管理並繼續在之上進行開發。在事情複雜化以前，我還能夠增長大量功能。

全面掌控

Muut 使用原生的 pushState 方法來控制URLs,John Resig's "微模版" (6) 來顯示視圖，內部的模型與視圖的交互使用自定義事件。而不使用路由及自動數據綁定的功能。

每一個事情都徹底按照咱們預期的執行，出現bug也容易找到。這裏沒有不可知的，不明道理的代碼。這裏沒有祕密，而且調用堆棧也很淺。咱們能夠針對特殊須要而去組織代碼，而這裏沒有固定的框架來控制必須如何作。

不混合編程樣式

沒有外部包更新

沒有這依賴hell

每週都能愉快發佈新版本！

特殊需求

Muut客戶端只是一個包含所有HTML代碼的JavaScript文件。當文件加載後它會在一個單獨的anchor(A)標籤中渲染本身。項目的打包與啓動與傳統的單頁面程序有很大不一樣。

Muut服務端必須可以隨時通知客戶端。客戶端與服務端以一種點對點的雙向模式進行通訊。

咱們經過WebSocket發送JSON-RPC消息，而不會考濾使用REST：像Muut這種實時程序不能構建在REST之上，由於REST所採用的是一種請求-響應模式而且它不能理解push事件等東西。

如今的框架，例如ember數據，是面向REST的，而且它們的示例和文檔也是基於REST的。WebSocket示例有遺漏，或只是試驗性的。Muut所面臨的挑戰是很獨特的。

技術鎖定

若是你查看了任何編程語言的框架史你會發現它也是一部失敗史。框架來了又走了。今天的JavaScript框架都很年輕。Backbone, Angular和Ember如今可能很流行，但幾年後就不必定了。

咱們來看下Angular (藍), Backbone (黃) 和 Ember (紅)的Goole Trends（谷歌公司的一項搜索產品） (2):

JavaScript是世界上最流行的編程語言，而且提供了多種編程風格。但事物也在以一種難以想象的速度變化着。所以使憤怒的框架社區不斷推翻曾經最好的應用構建方式。

沒有最好的方式.

有許多不一樣的替代方式,目前Angular正處於巨大的增加之中. "AngularJS容許你的應用程序拓展HTML." 這是最好的方式嗎? Backbone和Ember是否正處於危險的境地?2012年在X框架中有所投入的公司,可能立刻會意識到,他們的開發團隊已經在談論下一個新技術了. 做爲使用這些框架其中之一的開發者,我擔憂他們的生命週期.

另外一方面,讓咱們來比較一下jQuery和Angular (3):

上面的圖告訴了你jQuery的普及程度.它正在全世界57.2%的網站中使用,其中92.7%的網站的JavaScript庫是公開的. (4) 這裏沒有技術限制.可是做爲一個嵌入式應用程序,咱們不能指望人們,在已經使用jQuery的網站中,加載其餘的框架.

Muut使用了jQuery的所有內容,在設計API的時候,我甚至偷師jQuery.它很簡潔好用.我(依舊)喜歡這點.

爲何不用 Angular？

Angular 看起來是頗有前途的。表面上，我能夠用原生的js寫個人模型，讓Angular去渲染到視圖上，且不須要任何膠水代碼，這看起來很是棒！但有一系列緣由讓我不喜歡這個框架。

首先，它和Muut同樣的大小（91kb).但我只想要雙向數據綁定而已，我被迫加載整個框架。它爲我提供過多東西。我但願他們單獨作一個數據綁定的模塊，讓它更簡單便可。人們也不須要關心內在的實現機制，好比$watch, $apply 及$digest。

儘管它標榜本身是很簡單，但它的API是很是大的。目前它們的文檔中邊欄竟有147節內容。那須要麻煩的理解認識過程。我只須要一張空桌子來構建個人工做。

另外，我真的不喜歡把這麼多的邏輯放到視圖中或把個人代碼包裝後，放到"directives" or "filters"中去.Muut的邏輯只有適當的複雜度，最好用原生的JavaScript就能表達。

爲何不用 Ember.js?

Ember 是龐大的，恩，就是很是大！minified後的庫大小也是240kb.不用說，它們的API也是龐大的。我從它們的文檔的第一節（Modules > Ember）看，只這一節便有80個二級節點。

我最不能接受的是，我必須把我寫的對象用Ember.Object來包裝才能引入API中的方法。

一個大框架使用大量的特有語法是一個冒險的選擇，想一想 Enterprise Java Beans吧！

爲何不用 Backbone.js?

Backbone 在三個中，最小最簡單的框架，minified後大小是33.9kb。它必須依賴 underscore.js庫，這樣它就大於Muut一半的大小了。

我用Backbone的問題是：我不喜歡Backbone組織代碼的方式。它有太多的樣版，但我喜歡更喜歡寫出簡潔緊湊的代碼。我徹底認同它把API代碼與UI代碼分離的觀點，但 Kim Joar Bekkelund的關於把jQuery代碼轉到Backbone的文章對我毫無心義。對我而言，很難去用它的代碼。

與Ember同樣，Backbone不能用POJO's，因此你必須用Backbone.Model.extend來包裝你的對象，引入也沒必要要的框架定義的方法。

在以上面個框架中，Backbone最最保守選擇，它不給你作什麼看不見的工做（Magic），甚至即便它中止開發，你還能夠用本身的代碼去打補丁或替換掉它的代碼。

最後，做爲一個RESTful的框架，它並不能完美地適於於實時通信的地方。

但jQuery正在變成意大利麪,是嗎?

一般的論題是,在應用程序中堆疊了成千上萬行代碼後,jQuery地獄將會爆發.這個應用程序沒有結構,代碼也是一團糟.這並不正確.當API徹底從其餘代碼中剝離出來的時候,利用jQuery很容易構建控制器.

一般,個人控制器代碼像下面這樣:

01	// controller for a Topic model

02	function drawTopic(topic) {

03

04	// generate new element with micro templating

05	var root = tmpl("<div>some html</div>

06	", topic);

07

08	// topic elements

09	var seed_post = $(".seed", root),

10	replies = $(".replies", root);

11

12

13	// listen to events on model

14	topic.expand(function() {

15	// do something with the elements

16

17	}).collapse(function() {

18	// do something else

19

20	}).remove(function(post) {

21

// etc

22

23	}).reply(function(post) {

24

25

})...

26

27

}

這就是我我的組織代碼的方式.Web應用程序的目標不該該必須限定在DOM,或者面向對象的實踐,或者純MVC模式.一個成功的應用程序應該保持簡單,而不要陷入學術化的怪圈.

總結

正是咱們結合了完美主義和極簡主義， Muut是一個極輕量，易管理，和獨立的Web應用集合。 與「從頭構建」的方式一致，它適用於咱們的服務器側代碼和UX，若是不是在幾年前，能力高超的團隊和許多的人有相同的想法，你就不會看到相似討論平臺的出現。

下一個博客條目: Riot.js – the "1kb MVP library" Muut客戶端的背後.

相關連接

[1] Mobile usage vs PC usage

[2] Google trends for Angular, Ember and Backbone

[3] Google trends for Angular and jQuery

[4] 57.2% of all websites use jQuery

[5] Step by step from jQuery to Backbone

[6] Micro Templating

本文地址：http://www.oschina.net/translate/frameworkless-javascript

原文地址：https://muut.com/blog/technology/frameworkless-javascript.html