最近關於前端開發效率的想法

Web Components

最近開發階段當中狀態挺糟的, 包括空餘時間也很沒精神去改我的項目
算是進展的是 Google IO 關於 Polymer 的幾個視頻, 週末總算看完了
我雖然很討厭其語法設計, 但不得不認可將來幾年 Polymer 影響巨大
Backbone, Angular, 相對來講小打小鬧, 我多半是誇張, 反正就是想說很重要

我寫 Backbone, 可是別人寫的模塊我不會拿過來直接用, 公司代碼庫也比較謹慎
而 Angular 代碼我接觸少, 可是從 Vue 推測, 我也不認爲 MVVM 有多合適共用
React 裏模塊的觀念已經很接近 Component 了, 可實際編碼中代碼依然不常複用
(固然, 我作前端實際工做一年半, 我也沒深刻 Angular, 細節過後要商榷)
而 Polymer 目標就是爲 Web Components 提供兼容現有瀏覽器的實現
Web Components 核心是自定義標籤, 爲元素的複用夯實基礎

從這裏能夠看 Web Components 規範, 細節和 Polymer 估計有出入
https://w3c.github.io/webcomponents/explainer/
http://www.polymer-project.org/docs/start/creatingelements.html
缺少足夠的經驗, 我不能確認這對於完成複雜的大量交互的應用是否足夠
可是從已經演示過的 Polymer desinger tool 看來真的很強大
http://www.tudou.com/programs/view/aTCnSgdgXa4/

我不想描述 Polymer 細節如何如何有用, 只想說 Web 缺這個功能過久了
回到編程語言, 核心的功能是什麼? 是組合數據類型, 組合函數調用的能力
經過這兩個功能, 複雜的結構, 複雜過程, 都能經過代碼複合來達成
而後咱們經過 import 語法鏈接文件, 經過包管理器共享代碼, 造成生態
界面組件你們都注重複用, 每每都要造輪子, 各個流行框架本身都有一套
我不知道 Web Components 算不算最終的答案, 但咱們等到了一個好的選項

顏色和佈局

Chrome 給設計調整界面帶來了巨大的方便, 但項目當中未必都能用上
並且也不多人能同時具有項目的決策, 設計, 編碼各方面的角色, 未必隨便用
Google 新的 UI 因此能在各類平同通用搭配, 在於他們事先作的大量設計
適應不一樣尺寸的 Roboto, 適應各類尺寸屏幕的而統一的界面風格,
經過 hero image, FAB 等等元素構建起來的統一視覺等等
這麼大的架構, 單純做爲個前端我表示無從下手

很多顏色跟佈局的細節, 是設計圖或者方案中不能面面俱到的
我目前不清楚細節怎樣作到的, 大體的思路是:
* 顏色要有配色表, 從設計圖出發能根據配色表延伸出去搭配
* 佈局的種類限定, 界面當中普通的佈局經過約定的佈局快速完成

固然顏色不那麼簡單, 除了固定的配色, 還會有半透明的元素要考慮
還有邊框跟陰影, 在 Material Design 中還會對應 z-index 而不一樣
對於顏色我能認識到的, 大部分仍是從感受出發進行的調整, 至少不嚴謹
至於到 Google 那樣級別的統一配色, 我如今還不敢想

局部問題離開了 Flexbox 我就不敢想了, 可重用的佈局基本作不到
常見的前端 UI 框架會提供表格佈局, 可是精細程度徹底不過對付 App
兼容性部分的大量 absolute 代碼須要手動維護, 我以爲是逃不開了

組件和業務分離

這是是週末和朋友聊的時候說到的, 我回來一想發現又被他說對了
沒有長時間的組件積累, 業務當中的 UI 常常是隨着開發直接在代碼當中作的
不只難以經過時間保證質量, 就連 UI 組件模塊化單獨維護都很很難作到
這個問題也關聯設計語言, 沒有穩定的設計語言, UI 組件功能也很難穩定下來
沒有穩定的組件, 把組件做爲業務的一部分快速編碼反而是最後的選擇

我眼裏好的開發方式, 在 Polymer designer tool 裏太明顯了
全部組件都是定製好的, 業務的開發就從這些拖拽開始, 經過綁定結束
相似的方式也許在 Noflo 那些交錯的線條當中也有體現出來
通過這樣的模塊化以後, 開發的職責確實很是清晰, 模塊重用也得以提升

自動的視圖渲染

界面自動更新是難以免的事情, 甚至其中還會伴隨一些動畫
對於還不會手寫 Diff 的我來講這類問題實在是紮紮實實的難題
而且在業務代碼當中對 DOM 坐 Diff 也必然是消磨時間的作法
在 Polymer 當中, 這個功能又經過數據綁定完成了

Polymer 和 React 的不一樣

這個不一樣設置讓我有點困惑, 就是如何講數據分發到不一樣級別的 View 當中
React 對應的是 Flux 的模型, 有着近乎全局的 Store 存放數據
, 而後每一個 View 或者從父元素傳入屬性, 或者更多從 Store 中直接獲取數據
而 Polymer 中, 數據被直接嵌入到 View 當中去了, 用另外一種方式保證了數據一致性

在學 React 時, 我模仿的是服務端渲染頁面的思路, 數據庫, 路由, 控制器
, 每一個頁面劃分爲局部, 這些部分用字符串拼接的方式輕鬆組合到一塊兒
React 中是函數調用的嵌套, 很是輕鬆地也將界面拆分爲 Component 再一塊兒組合
這個組合的過程當中, 可能有不少數據的查詢和轉化, 這在後端渲染已經成熟了

而 Polymer 是經過 HTML 屬性中形似 Angular 的語法來達成這個步驟的
同時 Component 良好的封裝意味着不會存在 Flux 當中的全局 Store 能夠查詢
, 結果是智能經過外層 Component 綁定的數據來對 View 進行更新
固然良好的封裝首先帶來好處, 可我想不明白這同時做爲限制會帶來什麼影響

無論怎樣, Model 和 View 二者的數據一致性在兩個方案裏都解決掉了
或許細節上的差別能夠簡單經過某些巧妙的 trick 解決, 等社區推舉方案了

前端的數據

基於 Flux Store 我想到, 從 View 的角度, 若數據都在前端, 開發能夠大幅簡化
那樣的開發方式就像是有個數據庫, 每次渲染頁面查詢數據庫就行了
這樣就和咱們目前設計的架構類似, 數據的生命週期定爲:
* 瀏覽器打開, 同步全部用戶數據, 還有當前時段的列表形式的數據
* 本地 View 的操做, 更新本地 Store, 向服務器發起同步, 更新回本地
* 其餘客戶端數據更新, 自動同步到本地的 Store
* 每次 Store 更新都出發事件, View 是綁定 Store 的, 所以自動更新

我印象裏 Meteor 和 Derby 設計中就在解決這樣的問題, 強大的數據同步
在那樣一個視野中, 前端 View 和 Model 數據自動同步, 前端和後端數據自動同步
因而, 單頁面開發就不像如今這樣, 先後端糾結一次, 多個 View 和 Model 還要糾結
甚至於, 通過這一步解耦, Store 同步服務器的邏輯也給抽象出來
好比 Derby 的同步引擎 Racer, 抽象以後客戶端 Todo 同步服務器數據極爲簡單
https://github.com/codeparty/racer
https://github.com/codeparty/racer-examples/blob/master/todos/client.coffee

Racer 背後的技術用了 ShareJS, 算法源於 Google Wave 的 OT.. http://sharejs.org/
看到 Wave 的名號我每次都肅然起敬... 想來算法也不會簡單

---

整體上, 我認爲影響效率的幾個問題:
* 服務器, 前端內存, View, 這三組數據如何保持一致?
* 渲染界面時, 怎樣快速重用已有的顏色和佈局, 也就是怎樣複用組件?
* 另外大概還有怎樣避免掉前端開發的坑.. 只能憑經驗?

---

返回博客列表 http://blog.tiye.me