前几天跟同事聊天的时候回头看过当时在学校开发的电台
现在可能是无人维护, 而且 API 在外网估计屏蔽了, 所以还是当时的样子
我最近关于 FRP 的图形编程比较多, 偶然回想到当时很多错误的认识
我觉得挺有意思, 所以想写一篇文章感慨一下,
文章的重点是, 当时对事物好多的理解, 随着深入领域已经改变甚至固化
Feel Radio
Feel 电台我记得当时因为新老交接, 社团的前端出现了空白
我当时参加的是服务器部, 但后来一直学做交互界面, 就补上去了
电台断断续续可能有好几个月, 好像是大四开始时接的, 记不清了
页面上主要是加载 DJ 和节目, 然后调用播放器, 另外控制下主题
我前端决定用 Ajax 加载所有数据, 做 DOM 操作控制播放的
后来后端开发没跟上, 临上线决定大家帮忙开始批量转 JSON
用静态的 Nignx 服务器匆忙上线了, 解决了问题, 但是 bug 不少
后来才有加上 PHP 后台管理, 后台用了框架, 界面显得比前端还成熟
这对我来说是一次实践的很好的机会, 因为我马上了解到了其中那么多问题
比如说当时有人文学院合作, 但是两位同学很少碰面, 只是给了一稿设计
电台的同学我去问了需求, 我厚了时间才弄明白做 DJ, 可是他们对网站界面没想法
界面有视觉传达部门的同学, 但是主要是海报设计, 网页限制她们不了解
前端只有我, 而且我经常因为技术难以实现考虑对设计进行更改
后端负责的同学实习去了, 而且没投入多少时间, 后来还换人等等
更致命的是没有人能做协调, 而我和 zarzen 前前后后拉人商量意见都对不上
后来无奈了找大家一起在我屏幕上看初稿, 结果快有十个人秩序都乱了
因为主要的工作是在前端, 所以结尾赶进度时候界面细节几乎都在我临时决定了
后期的维护因为我开始实习也没怎么跟上, 后边不知道是谁接手
代码质量考虑到是我第一个实际项目, 对维护的考虑也很欠缺, 不过页面很简单
我后来 xuld 商量到这个事情, 他说精弘就是缺产品经理的
包括跟在实习的公司做对比, 也完全是缺少那么能主导整个项目的人
我挺遗憾的是呆在精弘这段经历没有人领路, 第一个项目的经历非常低效
而且我至今都没接触过外包, 外界对于网页有什么样的需求我并不清楚
我也缺少接触实际当中非技术的人们对网页有什么期待
呆在精弘的时间里我经常翘课, 大把的时间自己去接触大量的网站
而且有时间和资源我能反复重装 Linux, 不断在网上刷新闻追踪最新技术
精弘的技术氛围也是我对技术社区最初的印象, 就是一堆能随口扯 Linux 的人
服务器部分的会议和分享给了我基础的维护服务器的经验, 只是我没走那条路
TickTick
最开始同学跟我聊工作我还是有压力的, 只是仗着社区活跃给自己留点退路
不过因为第一家面试的公司就是做的单页面应用, 我没怎么抗拒就去了
第一家公司的印象, 站立会议, 密集的任务管理, 不成功但一直不停尝试的分享等等
当时的感想已经有文章追述, 下面只是说技术方面我的接受程度
我只是了解过但没真实用过 Backbone, 而 TickTick 是一个非常大的 Backbone 项目
最初工作都是修复其中的 Bug, 靠着对 Chrome DevTools 的熟悉程度勉强跟上了
我从前接触的都是 jQuery, 而且也没有理解 Backbone MVP 那种模块化开发的思想
View 部分其实挺简单, 然而 Model 与 Server 之间关系让我费了不少力气
另外麻烦的地方是复杂的 View 的开发, 我遇到第一个技术上难点是 RRule 控件的开发
其实我觉得老板对界面效果要求过高, 甚至超出了 Backbone 控制状态的能力
当然直接的问题是我的技术和经验, 我在做复杂的状态切换的模块上花了非常多的时间
而这也让我直接将注意力转到了 Angular 上边, 关心 MVVM 方面的方案
另外是多个 View 对单一的 Model 的监听和操作问题, 也让我体会到 Backbone 的弱点
另外大的大概还有整个项目切换了 Browserify 又切换到 RequireJS 才稳定下来
以及 CDN 通过 md5 部署的问题, 即便在后面的经历当中也是难点
此外在 TickTick 遇到的大量是业务逻辑上的问题, 大型的前端 MVC 恐怕避免不掉
我因此对于 Chrome JavaScript 调试的便利性极为赞赏, 至今不习惯 Firefox 调试
不过对整体架构我依然感到非常无力, 主界面的性能优化我也无力解决
另一方面由于工作压力, 我原本差劲的交流能力, 还有做事的条理性改善很多
我还参与过不少前端面试, 当时觉得有单页面经验的人太少很不理想
现在看来我对于他人技能增长的速度是毫无经验, 很多预判也都是肤浅的
但是有一点我依然坚持, 单页面不是成熟的技术方案, 缺少明确的 MVC 经验是不行的
而且公司当时项目推进非常有力, 没那么多时间做各种试验
Today
是我到 Teambition 时跟着寸志做的, 数据层没有之前 TickTick 那么重的 Java 架构的味道
而且对 Backbone 的使用也娴熟不少, 我对于 Collection 的理解慢慢清晰起来
因为项目是用 CoffeeScript, 对我来说轻松不少, 因为我个人项目用的都是 CoffeeScript
中间另外比较明显的是 Teambition 的开发习惯花了一些时间拾起来
这边就想不杭州那么忙了, 加上 Vue 是在这个时候出现的, 于是开始用 Vue
在 Vue 之间我用的模块是 Ractive.js, 而 Vue 才是完整的 MVC 层面考虑的框架
我 Vue 写了一些小的应用, 才开始感到有点写应用的感觉
而这也弥补了我没能学会 Angular 的遗憾, 太多稀奇古怪的东西了
Backbone 面向对象式的臃肿的封装其实让我挺难适应的, 个人也用不起来
虽然后来我已经熟悉了用构建 Collection 构建 View, 可是思路还是不通
Vue 对我来说像是在开发思路上做了廓清, 定义数据, 定义模版, 定义操作, OK
特别是 Backbone 当中事件造成的架构的繁复也瞬间被条理化了
当然这中间很多还是 Angular 的功劳, 双向绑定我已经关注了半年多
Talk
后面不久就是参与 Talk 的前端, 因为是 Backbone, 我各种不以为然
因为中间有次重构, 所以这算我第一个从头写的大的应用, 用的是 Backbone
对 Backbone 完整的认识也是在中间开始的, 当然 Backbone 是非常简洁的框架
也还好我有时间研究, 当时我整纠结 Vue 怎样模块化, 正好遇到了 React
React 极为灵活的模块化方案, 以及极为清晰的 Flux 架构马上打动了我
在确认 CoffeeScript 的语法支持以后, 我很快丢掉了 Vue
React 几乎是个崭新的世界, 虽然开发上很多还是和 MVVM 相似的
但我理解 MVVM 依然是对 DOM 做各种优化方便在 DOM 当中开发应用
而从 React 开始, DOM 就是个虚拟机, 而 jQuery 就成了汇编, MVVM 勉强对应 C
React 对 DOM 进行了抽象之后, MVC 架构的思想非常直白
随之发生的事情是瞬间能够管理的 DOM 的数量提升了一个数量级
考虑到未来 React 模块丰富, 这种遍历性将会继续提升
今年另外关于的 Polymer 也发布了更新, 模块化设计非常出色
只是因为迷信 React, 我后来也没怎么花时间到上边去了
我认为, Polymer 不如 React 的应用的抽象能力更好, 或者说更灵活
React 当中的 MVC 在 Polymer 当中并不清晰, 那可都是模块啊而不是业务逻辑
具体到应用开发我认为 Web Components 依然大步向前.. React 依然从中获取好处
随着对 React 的熟悉以及信心的提升, 我开始在项目当中引入 React
原来 Backbone 渲染复杂的消息列表的性能问题默认就解决掉了
另外是 React 允许了更多的 DOM 和更多的状态和交互的管理能力
这也是后边 Talk 搜索部分交互骤增我还能正常推进项目的技术保证
当然现在也存在 Backbone React 混合使用一些麻烦
不知道后边是否在数据层还会遇到问题, 但这确实值得花时间深入的
超出 DOM 的 MVC
另外两个把 DOM 当作虚拟机的优秀项目一个是 Elm, 一个是 Famo.us
Elm 带来的是 FPR 多年研究成果在 HTML 当中的实现
从架构图看, React 算是深受 FPR 影响, 不过也许只是因为都是 MVC 吧
Elm 遵循 Haskell 的不可变数据, 纯函数, 强类型, 整个很特殊.. 不多说
Famo.us 带来的则是 3D 游戏开发开发领域对精致的交互界面的理解
Famo.us 对 DOM 结构重新做了思考, 为精致高性能的动画铺平了道路
不过考虑项目缺少 React 方式的抽象, 我也只是密切关注而已
从最初 jQuery 按照交互的过程一步步渲染模版绑定事件到现在
我对于编程的理解一步步被颠覆掉了, 呈现出更多函数式的理解
之前我虽然花很多力气想学 Haskell, 可是不能写界面, 我也就很少练手的机会
实际上我没用 Haskell 写过像样的程序, 甚至认为仅限研究而已
可是从 React 开始, 我发现以前的理解慢慢被颠覆了, 就是过程式的代码
这样的代码慢慢会被声明式或者函数式的代码替代掉
举个例子, Teambition 的编译工具, 以前是用 CoffeeScript 加 Shell 脚本
后边前端修改之后, 用的是主流的工具 Grunt 和 Gulp
Grunt 基本上是声明式语法, 而 Gulp 则是函数式编程里数据流的方案
并不是脚本功能差, 而是用这些办法能更专注业务逻辑,
而且非常实用主义地, 这些方案更容易把复杂的工具性代码转嫁给社区
最终工具暴露的是函数式的一些接口, 虽然深奥, 但是效果不错
类似地对于界面, React 带来的是一种更好的对 MVC 的抽象
我渐渐认为开发更需要的不是一门好的语言, 而是对应用更好的抽象
对于单页面来说, 主要需要关心的是, 网络和浏览器环境的 IO, MVC 和业务逻辑
前边的 IO 有各种类库, 不讨论, 业务逻辑躲不掉, 不深入. 于是剩下 MVC
我认为对于框架作者的普通开发者来说, 基本都是按着 MVC 填业务逻辑而已
那么当有更好的 MVC 的选择, 意味着更好的实现应用的工具
要赶紧睡觉… 仓促结尾.. 当然我想说的在这一小节前面的段落说完了
上个月和 xuld 在外滩交流的时候他说我看别人代码太少.. 还说服我了
后来我在 GitHub 翻一些代码, 甚至自己代码, 感到的确, 太多东西其实不了解
而且我也不知道其他人的 MVC 应用是怎么做的, 我只是说架构上…
按这个想前边几年对编程的理解, 在一年当中渐渐被推翻了确实情理之中..
