简单还是一致(再续) #146

Open
lifesinger opened this Issue · 9 comments

4 participants

lifesinger 刘奇峰 lijing00333 flicat
lifesinger

421b88b85ccd5b23b2f611c1915f2ba8a82970e0744a-3rCEIQ_fw580

拔赤发完「简单还是一致(续)」一文后,一直想回复一篇,今天得空,回下。

抛错时机

seajs.use('a', function(A) {
  A.doSth();
  console.log('a');
});

// some logic...

seajs.use('b', function(B) {
  B.doSth();
  console.log('b');
});

上面这段代码,在正常使用情况下,当 a 的 callback 里发生了错误,不会影响 b 的 callback 执行。因为正常情况下,a.js 和 b.js 并不会提前同步加载好,seajs.use 依旧是异步行为。和拔赤的预期是一样的。

假设出于某种考虑,提前加载了 a.js 和 b.js,比如:

<script src="a.js"></script>
<script src="b.js"></script>
<script>
seajs.use('a', function(A) {
  A.doSth();
  console.log('a');
});

// some logic...

seajs.use('b', function(B) {
  B.doSth();
  console.log('b');
});
</script>

上面这种情况下,seajs.use 的 callback 才是同步执行的,这时 a 的 callback 倘若出错,会影响 b 的 callback 执行。

但实际上,拔赤提到的那种分模块开发,绝大部分情况下是:

<script>
seajs.use('a', function(A) {
  A.doSth();
  console.log('a');
});
// some logic...
</script>

</script>
seajs.use('b', function(B) {
  B.doSth();
  console.log('b');
});
</script>

上面这种使用方式下,即便是同步执行,a 的 callback 执行错误,也不会影响 b 的 callback 执行。

也就是说,拔赤的担心,反而是一种理论派的担心,实际开发过程中,根本不用管 seajs.use 的 callback 执行是同步还是异步,使用者本就不应该关注这个内部机制。

这就和 Sub-Pub 事件机制一样,最朴实简单的事件机制是,天女散花式,可以理解为所有订阅者同时并发收到消息,而不要去理会是先进先出,还是先进后出。一个事件机制里,订阅者应该互相隔离,不依赖顺序,不依赖内部机制。

即便是同步执行情况,又把多个 use 写在了同一个 script 标签里,这时抛错个人觉得也是合理的。同一个 script 下,可以认为是同一段业务逻辑,当前面已经出错了,再执行后面已经意义不大,停下来不执行,抛出错误,反而简单,更容易发现和定位问题。特别是对稳定性要求很高的产品来说,及早抛错往往是更明智的选择。

顺序

seajs.use(['a', 'b', 'c'], callback)

这个,拔赤理解错了哦。use 多个模块,是并发下载的,全部下载完成后,才执行 callback 函数。

a、b、c 之间如果有依赖,在模块定义里自己去指定就好,不需要 loader 层关心。

拔赤提到的 sequential 等参数设计,是把简单的问题搞得复杂了。loader 应该关注什么,什么应该交给 module 自身确定,职责的边界等等,这些问题,越明显越简单越好。

以上是顺带提下,下面说说今天最想说的。

懂业务的框架

拔赤这段话:

这时,seajs就和旧有的类库有所不同,seajs提供“方法”和“思路”,而jquery、yui、mootools等则提供“工具”。两种思路直接决定了类库所面向的“问题集合”。因此,seajs需要“学习”,而jquery更多的则是需要“查阅”。

seajs 其实是提供工具,是剪刀、锤子一样的工具,职责非常单一,能做什么,不做什么,很明确。这跟 jquery 是一样的。

对于具体的场景来说,“一致”的约定难免单薄,相比之下,“工具”则更易于被大众接受。理论最终是要和业务结合,这也是为什么一个“懂”业务的框架看起来不美的原因。“懂业务”带来的复杂性和“强约定”带来的优雅的编程体验,两者之间,你会选择哪个?

真正懂业务的框架是美的。看起来不美的业务框架,往往是因为抽象层次还不够,还未能真正抓住问题的本质,未能真正把业务中的各种纠缠梳理清楚。比如 Backbone 挺美的,AngularJS 也挺优雅,他们的背后,都是繁复的业务,各种各种业务,但是合理的抽象,不断的重构前行,让这些直接从业务中诞生的框架,依旧保持了优雅美丽。

最后,吐个槽。前端界的大部分讨论,都会比较肤浅的停留在表层。比如拔赤的文章,其实我很高兴看到这么一篇对 seajs 带点批判的文章,真的很高兴很高兴,我相信我当初给 OzJS 提交一些建议时,豆瓣的哥们虽然忙,但内心也是感激我的。可是,这种本来就非常少的交流背后,可以看出,拔赤对 seajs 基本还处于不了解状态,我对 ozjs 的了解,也还远远不够。在这种状态下,很多分析,都相当乏力,能给彼此带来的促进很有限。

一样的,也能看到不少对 jQuery、对 Backbone、对 xxx 的吐槽。在国内,我经常看见的情况是,这些吐槽的背后,并没有真的深入过,比如只看过 Backbone 的源码,跑过几个 demo 后,就开始吐槽了,说 Backbone 这不好那不好。这种吐槽,真心无力。个人觉得真正的吐槽,应该是在深入使用过之后,才有发言权。

就说这些吧。周末快乐。

(完)文 / 玉伯


欢迎订阅 WTP(Web 技术与产品交流)微信公众帐号。WTP 关注技术、产品、自由梦,在每个工作日(偶尔休息日)会定期推送一篇原创文字。欢迎扫描二维码订阅: