Home

重写聊天应用的感想

这次代码改了 3 天, 进步是必要的, 但速度相对没有提升

cnodejs.org/topic/502697d0f767cc9a511fd2ed

过程中我基本是悲观的状态, 而且这个界面几乎是考虑了一个多月的

实现了 OAuth 登录, 在线用户列表勉强算成功了的, 其实也不靠谱

折叠列表和标记已读的功能没写, 私密聊天也没有去做, 只是想过一遍

尝试了, 得到的教训比收获的进步要来得多, 睡不着, 梳理下

目前为止我写浏览器应用的手法都是一致的, 边操作边设计代码

就像是灯光城里, 走一步着手写算法渲染新的街景那样, 而不是预先构造好的

我的意思是, 不像 MVC 我独立写每个网页, 然后衔接在一起完成

而是说, 前边编写和测试的内容按步骤形成堆积的数据, 接着增加代码

明显有十足的自由度, 再者, 思路很清晰, 即便写之前我大多没有想好

也因此, 这么多次了我居然弄不出可以减少后来工作量的框架?

每个 socket 的收发我都会手动去写一遍对 DOM 的操作, 最多事后重新抽象

而且我也没弄出来接触过的框架怎样能简化其中的过程, 因为都是很松散的

MVC 是我心里一块阴霾, 我不安于比问题要复杂的工具, 一直拾不起来

或者我的代码依然只有 400 行, 谈不上抽象, 谈不上框架..

有个现实的问题是每个聊天室里的 items 随着 room 的切换会被覆盖的

界面上的表现是消失, 重建. 重建可以来自服务器, 或者运行环境的变量

首先, items 数据对应是不会消失的, 界面上擦除了, 它依然在

因此界面并不代表数据真实的形式, 可以理解 MVC 因此分离了数据和视图

而我期待简单, HTML 应该代表数据本身, display:none 不应该是删除

这里问题不大, 的确行得通, 即便 HTML 像是偶尔才有这样的功能

于是我认为 HTML 应当, 像人能理解的那样, 让代码更容易识别它的状态

jQuery 的 :visible 和 :contains 正是我想要的, 关于人是否看见

代码应该真真切切作用在元素上边, 不然直接抽象用上层的 API 不好么

mongodb 中用 upsert 一说, 如果 update 对象不存在, 那么插入

coffee 的赋值也有类似, 当前运行环境找不到, 那么当前作用域上新建

更新和创建, 人们理解起来不难, 但是在 DOM 代码上执行就好罗嗦

DOM 不是为了那么的数据而设计的, 或者, 我猜还是为 HTML 太偏重字符串

开发者工具中的 HTML 依然密密麻麻无比繁琐, 一点也不人性

又或者明明是我对 Web 期望过多, 实际上又不允许人跳过其演进的漫长

开始主体之前, 我很多时间用在写脚本保证每次保存都能重载整个系统

fs.watchFile() 既然设置了周期参数, 大概是通过 atime 去实现的

从前我还以为保存会触发一个事件, 像 JS 那样调用参数来触发的

不懂看 C++ 源码, 不知道是否还有更多不能如愿的惊奇

不断重载代码(小的脚本)大概会成为趋势, 一边写, 一边看结果

也就是不用脑子去推断, 只是换不同的代码, 看怎样结果才不会出错

事实上我全程的 coffee 代码都是不断忙着写代码, 印数据看怎么出错

就像运动时不断调整力道去适应那样, 经常很难计算到细节会是怎样

既然代码运行是计算的过程, 那么为什么不让代码先运行出结果来呢

总归是怕复杂的人, 我把代码都拆成了短短的函数, 分隔开来写

之前就有 if/else 成堆的代码, 因为我有意把具体的操作用函数独立出来了

得益于 jQuery, 函数一般都很短, 大概更多函数名可以让代码有更多语义

不过函数很烦的一点是不容易把作用域一起带着传走, 从而可能带去好多参数

我不大清楚, 带着作用域乱跑大概会带来危险, 毕竟缺少保护

不过我还是想有一天能弄出这么一门语言出来, scope 带着乱跑

学过解释器, 作用域是用 JSON 存的, 想要读取并不是没办法

JS 语言里常用事件, 常用函数, 颇有些关于 OO 的 messaging 的意思

长久以来我也弄不清楚 OO 扑朔迷离的概念之后是什么

只是知道, 当我看到远离背后似乎有统一的理念, 我就会想去找

只有在统一的规则下, 才不容易出错, 才能减少概念造成的繁琐和隔阂

coffee 总归都是一门很取巧的语言, 替我排除了不少的幻觉

comments powered by Disqus