我理解的架構:關鍵詞不是「高精尖」,而是「合適」javascript
全文html
Kissy5.0前端
NEJjava
要驗證的組件node
1. treejquery
2. datagridwebpack
3. combo/autocompletegit
要驗證的方面github
1. API(特性)支持程度web
2. 樣式分離難易程度
3. 性能
4. 兼容性
5. 使用普遍程度
相關材料
目前,通行的Javascript模塊規範共有兩種:CommonJS和AMD。我主要介紹AMD,可是要先從CommonJS講起。
var math = require('math'); math.add(2, 3);
node.js的模塊系統,就是參照CommonJS規範實現的。
AMD Asynchronous Module Definition 規範:https://github.com/amdjs/amdjs-api/blob/master/AMD.md
require(['math'], function (math) { math.add(2, 3); });
目前,主要有兩個Javascript庫實現了AMD規範:require.js和curl.js。
require:https://github.com/amdjs/amdjs-api/wiki/require
RequireJS: http://www.requirejs.org/
含有相對路徑的模塊搜尋
Relative module ID resolution examples: if module "a/b/c" asks for "../d", that resolves to "a/d" if module "a/b/c" asks for "./e", that resolves to "a/b/e"
AMD與CMD標準的區別是什麼呢?這裏引用玉柏本身的回答,具體可參考:http://www.zhihu.com/question/20351507/answer/14859415
- 對於依賴的模塊,AMD 是提早執行,CMD 是延遲執行。不過 RequireJS 從 2.0 開始,也改爲能夠延遲執行(根據寫法不一樣,處理方式不一樣)。CMD 推崇 as lazy as possible.
- CMD 推崇依賴就近,AMD 推崇依賴前置。
- AMD 的 API 默認是一個當多個用,CMD 的 API 嚴格區分,推崇職責單一。好比 AMD 裏,require 分全局 require 和局部 require,都叫 require。CMD 裏,沒有全局 require,而是根據模塊系統的完備性,提供 seajs.use 來實現模塊系統的加載啓動。CMD 裏,每一個 API 都簡單純粹。
- 還有一些細節差別,具體看這個規範的定義就好,就很少說了。
Javascript開發 - 那些構建/自動化/*** 的工具
現在比較流行的單元測試框架有:QUnit,Jasmine,Mocha,項目地址:
webpack: http://webpack.github.io/docs/
但Node.js畢竟是用於服務端的,爲了將模塊化技術用於瀏覽器,人們又造出了一大堆工具:RequireJS、Browserify、LABjs、Sea.js、Duo等。同時,因爲Javascript的標準沒有對模塊的規範進行定義,人們又定義了一系列不一樣的模塊定義:CommonJS、AMD、CMD、UMD等。這真是一件使人悲傷的事情,但願ES6 Module的出現能停止這種分裂的狀態。
Webpack同時支持CommonJS和AMD形式的模塊,對於不支持的模塊格式,還支持對模塊進行shimming。舉個簡單的例子:
React
而虛擬DOM幹了什麼?它直接用JavaScript實現了DOM樹(大體上)。組件的HTML結構並不會直接生成DOM,而是映射生成虛擬的JavaScript DOM結構,React又經過在這個虛擬DOM上實現了一個 diff 算法找出最小變動
就Javascript項目而言,開源社區比較流行持續集成服務就是 Travis CI ,它支持不少種語言,配合單元測試工具。API文檔:http://docs.travis-ci.com/user/languages/javascript-with-nodejs/。
infoq上關於前端的一些材料
小之美好 -- 前端工程產品實踐 http://www.infoq.com/cn/presentations/front-end-engineering-product-practice 講稿
與產品緊密 前端工程師的成與責 http://www.infoq.com/cn/presentations/success-and-responsibility-of-front-engineer 講稿