每次都是想準備大大的改版，但是幾乎沒有一次把它完整的完成下來，這次也不例外。 所幸這次是能夠訪問的，暫且這樣。

雖然目前的Blog是託管在Github上的靜態頁面，但是我在設計整個“架構”是進行了前後端的分離，所以很具有通用性，也便於以後項目的借鑑和部署。

整體設計模式#

雖然說Github上的Page服務是靜態內容，但是我們可以把她搞得想後臺服務，甚至是REST Api都能夠是看起來像。當然了，指的是GET。

起碼能在請求數據上做到相似。

利用Github渲染出json數據代替通常的html文件，我們的客戶端只需做AJAX請求，這樣能夠完成一個簡單SPA的Blog。

前端微框架#

當然這裏不是必須要使用框架的，原生JS也能夠把代碼量控制在很少的情況下完成我們所需要的功能。

我爲了省懶，當然也是在避免重複造輪子，選用了一個比較新的非常小巧的MVC框架mithril。

目前還沒有正式版本，不過有一直在更新。

她有下面幾個特點：

• 體積超小，壓縮後只有7Kb，想想Rx，Angular等，這簡直就是小米步槍於飛機大炮。
• 當然小不代表弱，她只是保留了最底層的功能，什麼雙向綁定之類的，全部手動去做好了。
• 據作者自己測試說，性能秒Angular好幾十倍，其實這完全是可以的，畢竟這是相當精簡的，去掉了很多使用率不高的代碼。
• MVC這個就不多提，現在沒有MVC，MVVM等設計模式都不好意思叫框架。
• 模板安全
• 虛擬DOM，所有的DOM都是在在內存中完成所有的操作的。
• 自動重繪

總結一句話，小而強的MVC框架，特別是在你需要做對流量加載時間性能等有嚴格要求的微型SPA時，強烈推薦使用。

當然如果比較懶，不想動手寫太多的代碼，而且是完成管理類的SPA時，用Angular就無所謂啦。但是，反過來你還是得花很多的時間去學習她的那一套設計模式。換用React又是重頭開始。

所以，我建議小應用選mithril，大的選Angular，Rx。

模擬後臺#

這個需要瞭解下jekyll的語法，如果熟悉ruby或者Python理解起來不是很困難。

無非最後就是把數據渲染成我們一般後臺返回的json格式數據，然後交給前端去加載到頁面上。

這裏有個坑JavaScript的JSON.parse()函數對請求下來的數據格式要求挺嚴格的，以前沒接觸過不太清楚，真正做了才知道，不少細節：

• '這個在json數據中是不合法的，全部用"；
• 與Object對象不同，json中的key一定要有"；
• 最後一個元素結尾是不能有,。

结尾#

這個Blog本身是沒什麼技術點，這裏我主要扯一扯整個設計， 以便於以後來完善時，有據可依，而不是再次重頭來！