最近关于前端开发效率的想法

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