SeaJS与RequireJS最大的区别

U_U U_U 2013-06-20 16:21:12
Cent
2013-06-21 09:03:35 Cent

兄台是真不懂还是装不懂啊?还不习惯异步的编程和思考方式?太片面太误导了。这种无良的方式推SeaJS其实会害了它

U_U
2013-06-21 09:18:16 U_U (好读书, 读好书(F2E))
兄台是真不懂还是装不懂啊?还不习惯异步的编程和思考方式?太片面太误导了。这种无良的方式推Se 兄台是真不懂还是装不懂啊?还不习惯异步的编程和思考方式?太片面太误导了。这种无良的方式推SeaJS其实会害了它 ... Cent

只是自己的小小观点, 没有任何其他意图
另外我想说的是代码说明一切, 其他尽在不言中
如果 @Cent 有更深入的研究, 请长篇反驳之, 不甚感激

旡止休
2013-06-21 09:52:55 旡止休 (像偏执狂一样不畏艰辛)
兄台是真不懂还是装不懂啊?还不习惯异步的编程和思考方式?太片面太误导了。这种无良的方式推Se 兄台是真不懂还是装不懂啊?还不习惯异步的编程和思考方式?太片面太误导了。这种无良的方式推SeaJS其实会害了它 ... Cent

这种评论也太让人无语了。

单纯说楼主不对,又不说理由。流氓啊。

U_U
2013-06-21 11:40:07 U_U (好读书, 读好书(F2E))
这种评论也太让人无语了。 单纯说楼主不对,又不说理由。流氓啊。 这种评论也太让人无语了。 单纯说楼主不对,又不说理由。流氓啊。 旡止休

我也是这么认为的, 有意见总是好的, 但光提意见, 不说理由那不等于白说吗?

Cent
2013-06-21 12:43:55 Cent

你的requirejs的用法不对,错误的用法没法产生正确的结果。另外你可能更喜欢顺序执行的代码,但是这必须导致require时的阻塞加载(这很多时候其实是可以接受的),而同时满足非阻塞和顺序执行就需要需要对代码进行一些预处理,这样的源代码就不能做到“下载即可用”的效果。

U_U
2013-06-21 15:22:29 U_U (好读书, 读好书(F2E))
你的requirejs的用法不对,错误的用法没法产生正确的结果。另外你可能更喜欢顺序执行的代码,但 你的requirejs的用法不对,错误的用法没法产生正确的结果。另外你可能更喜欢顺序执行的代码,但是这必须导致require时的阻塞加载(这很多时候其实是可以接受的),而同时满足非阻塞和顺序执行就需要需要对代码进行一些预处理,这样的源代码就不能做到“下载即可用”的效果。 ... Cent

非常感谢 @Cent, 我已经在 后记 中通过特例指明了他们的区别

kevin_开心
2013-07-18 16:34:21 kevin_开心 (男男不授受)

我是来看配图的,楼主好脾气

C
2013-08-16 10:19:13 C (What's my want)

楼主解决了我的困惑,证明了我的猜想,非常感谢

U_U
2013-08-16 13:27:41 U_U (好读书, 读好书(F2E))
楼主解决了我的困惑,证明了我的猜想,非常感谢 楼主解决了我的困惑,证明了我的猜想,非常感谢 C

同是遇到问题论证下罢了, 没什么的, 非常高兴对你有用

bengxia
2013-09-05 13:52:55 bengxia

你拿sea.js的写法去玩RequireJs,她当然也会玩弄你了。

bengxia
2013-09-05 13:53:58 bengxia

不过,我已经从RequireJs转向sea.js,跟支持国货无关,纯属sea.js看起来更直观。

jason
2013-09-12 18:08:12 jason

请教一下,最后一段指的“停顿”是什么意思?

U_U
2013-09-13 21:39:01 U_U (好读书, 读好书(F2E))
请教一下,最后一段指的“停顿”是什么意思? 请教一下,最后一段指的“停顿”是什么意思? jason

就是由于待加载的JS文件巨大, 因此程序的运行需要等待依赖加载完成, 所以"停顿"了

蓝瓜
2013-10-21 17:54:57 蓝瓜

因為使用非同步的載入方式,所以用 require 載入套件時,是有可能會造成相依性上的問題。 所幸 RequireJS 提供了一個 order plugin ,讓我們可以依序載入正確的套件。这是两种场景的问题,我觉得RequireJS的方式更合理,当你本身需要依赖于运行环境时,首先是要将环境准备好,然后才自我构建,而不是相反,试想如果你的环境载入出错了,你怎么处理?你要反过来回退自已所有已产生的行为。。。

蓝瓜
2013-10-21 17:56:55 蓝瓜

多数编程语言中的,import都不能在运行时中动态执行。。。。

蓝瓜
2013-10-21 18:11:29 蓝瓜

AMD 里面有写。dependencies表示该模块依赖的其他所有模块标识,模块依赖必须在真正执行具体的factory方法前解决

U_U
2013-10-22 09:10:44 U_U (好读书, 读好书(F2E))
AMD 里面有写。dependencies表示该模块依赖的其他所有模块标识,模块依赖必须在真正执行具体的fa AMD 里面有写。dependencies表示该模块依赖的其他所有模块标识,模块依赖必须在真正执行具体的factory方法前解决 ... 蓝瓜

非常感谢如此高质量的回复, 我心中理想的模块管理是按需加载, 运行时解析, 因此感觉SeaJS更加符合我的使用习惯, 不过其实require时才解析确实会对性能有影响.

而且回过头来想一想, 反正是要加载这个模块了, require肯定会在代码的某一行执行, 这样算下来, 其实先将环境准备好也是非常简单直白的方案

jockchou
2013-11-13 13:34:13 jockchou (爆炒毛毛虫)

我个人感觉requirejs更科学,所有依赖的模块要先执行好。如果A模块依赖B。当执行A中的某个操doSomething()后,再去依赖执行B模块require('B');如果B模块出错了,doSomething的操作如何回滚?
很多语言中的import, include, useing都是先将导入的类或者模块执行好。如果被导入的模块都有问题,有错误,执行当前模块有何意义?
总之载入的所有模块,都是当前要使用的,为什么要动态的去执行?这个问题可以总结为模块的载入执行是静态还是动态。如果是动态执行的话,那页面的程序执行过程会受到当前模块执行的影响。而正如楼主所言,动态执行总体时间上是比静态一次执行要慢的。
楼主说requirejs是坑,是因为你还不太理解AMD“异步模块”的定义,被依赖的模块必须先于当前模块执行,而没有依赖关系的模块,可以没有先后。在楼主的例子中,假设mod1和mod2某天发生了依赖的话,比如在某个版本,mod1依赖了mod2(这是完全有可能的),这个时候seajs的懒执行会不会有问题?而requirejs是不会有问题,也不需要修改当前模块。
在javascript这个天生异步的语言中,却把模块懒执行,这让人很不理解。想像一下factory是个模块工厂吧,而依赖dependencies是工厂的原材料,在工厂进行生产的时候,是先把原材料一次性都在它自己的工厂里加工好,还是把原材料的工厂搬到当前的factory来什么时候需要,什么时候加工,哪个整体时间效率更高?显然是requirejs,requirejs是加载即可用的。为了响应用户的某个操作,当前工厂正在进行生产,当发现需要某种原材料的时候,突然要停止生产,去启动原材料加工,这不是让当前工厂非常焦燥吗?
暂且不去理会这个吧,等ECMA规范中加入了模块化的定义后,再看谁更合理吧。

U_U
2013-11-14 22:56:07 U_U (好读书, 读好书(F2E))
我个人感觉requirejs更科学,所有依赖的模块要先执行好。如果A模块依赖B。当执行A中的某个操doSo 我个人感觉requirejs更科学,所有依赖的模块要先执行好。如果A模块依赖B。当执行A中的某个操doSomething()后,再去依赖执行B模块require('B');如果B模块出错了,doSomething的操作如何回滚? 很多语言中的import, include, useing都是先将导入的类或者模块执行好。如果被导入的模块都有问题,有错误,执行当前模块有何意义? 总之载入的所有模块,都是当前要使用的,为什么要动态的去执行?这个问题可以总结为模块的载入执行是静态还是动态。如果是动态执行的话,那页面的程序执行过程会受到当前模块执行的影响。而正如楼主所言,动态执行总体时间上是比静态一次执行要慢的。 楼主说requirejs是坑,是因为你还不太理解AMD“异步模块”的定义,被依赖的模块必须先于当前模块执行,而没有依赖关系的模块,可以没有先后。在楼主的例子中,假设mod1和mod2某天发生了依赖的话,比如在某个版本,mod1依赖了mod2(这是完全有可能的),这个时候seajs的懒执行会不会有问题?而requirejs是不会有问题,也不需要修改当前模块。 在javascript这个天生异步的语言中,却把模块懒执行,这让人很不理解。想像一下factory是个模块工厂吧,而依赖dependencies是工厂的原材料,在工厂进行生产的时候,是先把原材料一次性都在它自己的工厂里加工好,还是把原材料的工厂搬到当前的factory来什么时候需要,什么时候加工,哪个整体时间效率更高?显然是requirejs,requirejs是加载即可用的。为了响应用户的某个操作,当前工厂正在进行生产,当发现需要某种原材料的时候,突然要停止生产,去启动原材料加工,这不是让当前工厂非常焦燥吗? 暂且不去理会这个吧,等ECMA规范中加入了模块化的定义后,再看谁更合理吧。 ... jockchou

@jockchou 说的太对了, 例子又生动活泼, 在讨论问题的过程中, 我觉得大家会更加深入地了解到问题的本质.
如果就代码顺序执行的直观印象而已, 可能SeaJS更符合我的预期, 但就解决问题的方式上来说, RequireJS也没什么不好的.
因此大家最关键的是从中了解到2者的区别, 没有对错之分, 优缺点都是有的, 选择适合自己场景的就好了

dodeep
2013-11-22 13:36:21 dodeep

我是js新手,冒犯地问各位大神一个问题,javascript作为脚本语言,代码肯定是顺序执行的,requirejs在没有解释到require的代码块时,它是如何知道需要预加载的所有js文件呢?又如何做到异步加载呢?

U_U
2013-11-25 23:12:31 U_U (好读书, 读好书(F2E))
我是js新手,冒犯地问各位大神一个问题,javascript作为脚本语言,代码肯定是顺序执行的,requir 我是js新手,冒犯地问各位大神一个问题,javascript作为脚本语言,代码肯定是顺序执行的,requirejs在没有解释到require的代码块时,它是如何知道需要预加载的所有js文件呢?又如何做到异步加载呢? ... dodeep

这个问题比较深入原理了, 更会涉及到其他问题.
例如模块是如何注册的? 需要了解define()到底做了什么
RequireJS是如何知道模块的依赖? 这就需要了解RequireJS是如何通过解析模块来发现require"关键字"进而管理依赖
再有就是RequireJS是如何动态的将script标签加入到HTML中, 做到异步加载

问题很多, 希望 @dodeep 可以多多参考RequireJS的官方文档以及AMD模块标准

Jerry Qu
2013-12-08 21:20:14 Jerry Qu

了解到 AMD 的本质之后,这个就不能称之为 BUG 了。不过我非常不赞成 RequireJS 支持的 Simplified CommonJS wrapper 写法,这个是给楼主带来困惑的根源。上次为了给组内小伙伴解释这个问题,专门写了一篇博客,传送门:https://www.imququ.com/post/amd-simplified-commonjs-wrapping.html

U_U
2013-12-09 09:32:54 U_U (好读书, 读好书(F2E))
了解到 AMD 的本质之后,这个就不能称之为 BUG 了。不过我非常不赞成 RequireJS 支持的 Simplifi 了解到 AMD 的本质之后,这个就不能称之为 BUG 了。不过我非常不赞成 RequireJS 支持的 Simplified CommonJS wrapper 写法,这个是给楼主带来困惑的根源。上次为了给组内小伙伴解释这个问题,专门写了一篇博客,传送门:https://www.imququ.com/post/amd-simplified-commonjs-wrapping.html ... Jerry Qu

向 @Jerry Qu 致谢, 已经把问题分析的非常全面了
总结的非常好, AMD规范了"依赖提前加载提前执行"的根本, 尽管提供了CommonJS wrapping的语法, 但其本质肯定不会变了, 因此造成了如上困惑的问题.

而SeaJS所遵循的是CMD规范, 是按需执行模块的.

"其实只要把 require 看做是语法关键字 就好啦", 而我个人还是喜欢CommonJS wrapping的写法, 想想define后面跟着一长串的依赖感觉就像一场噩梦.
但为了不引起困惑, 将所有require全部写在最前面, 看作其他语言(例如Java)中的import就好了.

Jerry Qu
2013-12-09 15:09:17 Jerry Qu
向 @Jerry Qu 致谢, 已经把问题分析的非常全面了 总结的非常好, AMD规范了"依赖提前加载提前执 向 @Jerry Qu 致谢, 已经把问题分析的非常全面了 总结的非常好, AMD规范了"依赖提前加载提前执行"的根本, 尽管提供了CommonJS wrapping的语法, 但其本质肯定不会变了, 因此造成了如上困惑的问题. 而SeaJS所遵循的是CMD规范, 是按需执行模块的. "其实只要把 require 看做是语法关键字 就好啦", 而我个人还是喜欢CommonJS wrapping的写法, 想想define后面跟着一长串的依赖感觉就像一场噩梦. 但为了不引起困惑, 将所有require全部写在最前面, 看作其他语言(例如Java)中的import就好了. ... U_U

嗯,是的。从第一行开始写 require 依赖确实可以避免误解。我不提倡 CommonJS wrapping 书写方式的另外一个原因是并不是所有的 AMD Loader 都支持,而且 toString() 再正则提取依赖也更复杂。

「define 后面跟着一长串的依赖感觉就像一场噩梦」,这个确实是个问题。我暂时的处理办法是通过 Sublime Text 插件来自动管理 AMD 依赖。类似这样:

var x = Cookie.get('xx');

选中这行代码按下快捷键自动在 define 第一个参数添加 Cookie 这个依赖和 callback 的形参(如果已经有了就忽略);选中这行按另外的快捷键,就去掉依赖和形参。

当然这样只是让书写上更便捷,视觉上依赖数组一大坨还是不太美观。

U_U
2013-12-10 17:26:34 U_U (好读书, 读好书(F2E))
嗯,是的。从第一行开始写 require 依赖确实可以避免误解。我不提倡 CommonJS wrapping 书写方式 嗯,是的。从第一行开始写 require 依赖确实可以避免误解。我不提倡 CommonJS wrapping 书写方式的另外一个原因是并不是所有的 AMD Loader 都支持,而且 toString() 再正则提取依赖也更复杂。 「define 后面跟着一长串的依赖感觉就像一场噩梦」,这个确实是个问题。我暂时的处理办法是通过 Sublime Text 插件来自动管理 AMD 依赖。类似这样: var x = Cookie.get('xx'); 选中这行代码按下快捷键自动在 define 第一个参数添加 Cookie 这个依赖和 callback 的形参(如果已经有了就忽略);选中这行按另外的快捷键,就去掉依赖和形参。 当然这样只是让书写上更便捷,视觉上依赖数组一大坨还是不太美观。 ... Jerry Qu

"我不提倡 CommonJS wrapping 书写方式的另外一个原因是并不是所有的 AMD Loader 都支持,而且 toString() 再正则提取依赖也更复杂"
这点也确实, 但我一般最终发布会使用r.js来将RequireJS模块打包, 因此其实最终运行的文件还是使用AMD的推荐写法, 将所有依赖放置在define上, 来达到一个平衡.

对于依赖的噩梦, 不仅仅是美观的问题, 那更多的会是多人协作和维护的噩梦, 因此即使CommonJS wrapping的写法有些弊端, 但我还是小心使用着.

PS: 同时 Sublime Text 控
打造属于自己的前端开发神器
http://www.douban.com/note/276794943/

闲耘™
2013-12-12 14:05:03 闲耘™

写的很棒。
黑我大拼音库,话说不带给黑成 27M 这么大的,哈哈。

TT
2013-12-22 21:17:38 TT
嗯,是的。从第一行开始写 require 依赖确实可以避免误解。我不提倡 CommonJS wrapping 书写方式 嗯,是的。从第一行开始写 require 依赖确实可以避免误解。我不提倡 CommonJS wrapping 书写方式的另外一个原因是并不是所有的 AMD Loader 都支持,而且 toString() 再正则提取依赖也更复杂。 「define 后面跟着一长串的依赖感觉就像一场噩梦」,这个确实是个问题。我暂时的处理办法是通过 Sublime Text 插件来自动管理 AMD 依赖。类似这样: var x = Cookie.get('xx'); 选中这行代码按下快捷键自动在 define 第一个参数添加 Cookie 这个依赖和 callback 的形参(如果已经有了就忽略);选中这行按另外的快捷键,就去掉依赖和形参。 当然这样只是让书写上更便捷,视觉上依赖数组一大坨还是不太美观。 ... Jerry Qu

请问@Jerry Qu,快捷键是啥?还是说你自己写了一个插件?

U_U
2014-01-17 14:08:40 U_U (好读书, 读好书(F2E))
写的很棒。 黑我大拼音库,话说不带给黑成 27M 这么大的,哈哈。 写的很棒。 黑我大拼音库,话说不带给黑成 27M 这么大的,哈哈。 闲耘™

热烈欢迎pingyin库作者前来"砸场子", 冒昧了...

cs02308
2014-01-20 17:24:59 cs02308

Javascript的发展果然是迅猛异常,我是刚刚开始关注js模块化的新手,之前写过的自认为最复杂最新颖的js就是类似于这样的 var com.abc.projectA.common=function (param) {
// 实现代码
};不过看了上面的讨论之后,总感觉js里的AMD规范和CMD规范是各有千秋,有点像枪械里的有托和无托之争,也貌似AK-47和M-16的区别,对于像我这样的对js理解不深的人,其实我更关心的是如果用了requireJS或者seajs,相应的文档和帮助多不多,我使用的这个js框架是不是有很多的活跃的用户,这样一旦出现问题,我就可以从网上借鉴一下解决方法。主要是被之前的一些开源组件给弄怕了,用过一些小众的组件,由于本人水平不高,出了问题很难找到解决方法,那这种组件实在很难让我继续用下去。所以个人感觉,用户数才是王道。呵呵。

U_U
2014-01-22 10:54:24 U_U (好读书, 读好书(F2E))
Javascript的发展果然是迅猛异常,我是刚刚开始关注js模块化的新手,之前写过的自认为最复杂最新 Javascript的发展果然是迅猛异常,我是刚刚开始关注js模块化的新手,之前写过的自认为最复杂最新颖的js就是类似于这样的 var com.abc.projectA.common=function (param) { // 实现代码 };不过看了上面的讨论之后,总感觉js里的AMD规范和CMD规范是各有千秋,有点像枪械里的有托和无托之争,也貌似AK-47和M-16的区别,对于像我这样的对js理解不深的人,其实我更关心的是如果用了requireJS或者seajs,相应的文档和帮助多不多,我使用的这个js框架是不是有很多的活跃的用户,这样一旦出现问题,我就可以从网上借鉴一下解决方法。主要是被之前的一些开源组件给弄怕了,用过一些小众的组件,由于本人水平不高,出了问题很难找到解决方法,那这种组件实在很难让我继续用下去。所以个人感觉,用户数才是王道。呵呵。 ... cs02308

类似这种模块加载器源码量都不多, 一般建议通读理解, 这样出了问题(bug)就能迎刃而解. 不过开源社区也非常重要, 只有依赖一个社区开源项目才能真正成长且长期的生存下去

庞国庆
2014-02-13 16:28:10 庞国庆

这个例子本身是有问题的。既然已经模块化封装了,调用者不应该去关注被调模块内部的具体实现。 换句话说只要保证:
hello mod1
hello mod2
hello main
这个顺序,那就是没有问题的。如果每调用一个模块,都要看查看该模块内部的具体实现,那不就累死了,耦合度也就高了。
也许有人会问,我一定要和sea.js一样的执行效果。那么你应该让写mod1,mod2的作者封装出方法,可以这样:
define(function(require, exports, module) {
function onRequire(){
console.log('require module: main');
}
var mod1 = require('./mod1');
mod1.onRequire();
mod1.hello();
var mod2 = require('./mod2');
mod2.onRequire();
mod2.hello();

return {
hello: function() {
console.log('hello main');
},
onRequire: onRequire
};
});

U_U
2014-02-14 13:21:37 U_U (好读书, 读好书(F2E))
这个例子本身是有问题的。既然已经模块化封装了,调用者不应该去关注被调模块内部的具体实现。 这个例子本身是有问题的。既然已经模块化封装了,调用者不应该去关注被调模块内部的具体实现。 换句话说只要保证: hello mod1 hello mod2 hello main 这个顺序,那就是没有问题的。如果每调用一个模块,都要看查看该模块内部的具体实现,那不就累死了,耦合度也就高了。 也许有人会问,我一定要和sea.js一样的执行效果。那么你应该让写mod1,mod2的作者封装出方法,可以这样: define(function(require, exports, module) { function onRequire(){ console.log('require module: main'); } var mod1 = require('./mod1'); mod1.onRequire(); mod1.hello(); var mod2 = require('./mod2'); mod2.onRequire(); mod2.hello(); return { hello: function() { console.log('hello main'); }, onRequire: onRequire }; }); ... 庞国庆

这个例子是实际应用中基本上不会出现, 也不用过多担心, 这里只是给大家解释下现象, 在大家的探讨中我也学到了更多东西

Mayon
2014-02-14 17:57:12 Mayon (站在天桥傻笑,发呆一下午。)
我个人感觉requirejs更科学,所有依赖的模块要先执行好。如果A模块依赖B。当执行A中的某个操doSo 我个人感觉requirejs更科学,所有依赖的模块要先执行好。如果A模块依赖B。当执行A中的某个操doSomething()后,再去依赖执行B模块require('B');如果B模块出错了,doSomething的操作如何回滚? 很多语言中的import, include, useing都是先将导入的类或者模块执行好。如果被导入的模块都有问题,有错误,执行当前模块有何意义? 总之载入的所有模块,都是当前要使用的,为什么要动态的去执行?这个问题可以总结为模块的载入执行是静态还是动态。如果是动态执行的话,那页面的程序执行过程会受到当前模块执行的影响。而正如楼主所言,动态执行总体时间上是比静态一次执行要慢的。 楼主说requirejs是坑,是因为你还不太理解AMD“异步模块”的定义,被依赖的模块必须先于当前模块执行,而没有依赖关系的模块,可以没有先后。在楼主的例子中,假设mod1和mod2某天发生了依赖的话,比如在某个版本,mod1依赖了mod2(这是完全有可能的),这个时候seajs的懒执行会不会有问题?而requirejs是不会有问题,也不需要修改当前模块。 在javascript这个天生异步的语言中,却把模块懒执行,这让人很不理解。想像一下factory是个模块工厂吧,而依赖dependencies是工厂的原材料,在工厂进行生产的时候,是先把原材料一次性都在它自己的工厂里加工好,还是把原材料的工厂搬到当前的factory来什么时候需要,什么时候加工,哪个整体时间效率更高?显然是requirejs,requirejs是加载即可用的。为了响应用户的某个操作,当前工厂正在进行生产,当发现需要某种原材料的时候,突然要停止生产,去启动原材料加工,这不是让当前工厂非常焦燥吗? 暂且不去理会这个吧,等ECMA规范中加入了模块化的定义后,再看谁更合理吧。 ... jockchou

实践出真知啊。这条评论太赞了。在真实的开发环境中,模块之间肯定有依赖,这是不用争辩的问题。项目中为了保证能正确实行,在被要求使用seajs的情况下,我的外部插件加载,都用的require.async()。

Carter
2014-02-18 14:31:39 Carter
兄台是真不懂还是装不懂啊?还不习惯异步的编程和思考方式?太片面太误导了。这种无良的方式推Se 兄台是真不懂还是装不懂啊?还不习惯异步的编程和思考方式?太片面太误导了。这种无良的方式推SeaJS其实会害了它 ... Cent

说得很好,另外,楼主貌似很谦虚啊

Carter
2014-02-18 14:36:02 Carter
只是自己的小小观点, 没有任何其他意图 另外我想说的是代码说明一切, 其他尽在不言中 如果 @Ce 只是自己的小小观点, 没有任何其他意图 另外我想说的是代码说明一切, 其他尽在不言中 如果 @Cent 有更深入的研究, 请长篇反驳之, 不甚感激 ... U_U

代码确实说明了一切,sea.js这不符合js异步编程的表现
明明是异步编程的js,明明是回调,非得搞得跟其他的同步语言一样的效果,只能说觉得sea.js这点好的你们还真心不够习惯js和了解js

Carter
2014-02-18 14:42:03 Carter

“RequireJS你坑的我一滚啊”这哪里是什么坑啊!这不是异步编程(javascript)最最基础的现象么!这绝对不是sea.js优于require.js的证据哈,这倒是require.js更遵从js异步编程方式的体现。

U_U
2014-02-19 12:27:40 U_U (好读书, 读好书(F2E))
“RequireJS你坑的我一滚啊”这哪里是什么坑啊!这不是异步编程(javascript)最最基础的现象么 “RequireJS你坑的我一滚啊”这哪里是什么坑啊!这不是异步编程(javascript)最最基础的现象么!这绝对不是sea.js优于require.js的证据哈,这倒是require.js更遵从js异步编程方式的体现。 ... Carter

非常感谢各个的热情回复, 可能文章中有些用词不合时宜, 例如 “RequireJS你坑的我一滚啊” 这句, 只是表示我当时想当然的想法而已, 因为我本身也是从Java这样的语言过来的, 会想当然的以为代码上的顺序和执行上的顺序应该会一致.

正因为这样我才深入想了解下背后的事情, 感觉在与大家的交流中收获了更多.

希望大家在看此篇的时候, 更多的带入理解的思维, 不要包含对比框架好坏的情绪, 他们各有所长, 我们只有了解了背后的原理才能在正确的场景下选择使用.

最后我要说的是: 我既不是require.js的黑粉, 也不是sea.js的托, 其实在我自己项目中有使用require.js也有使用sea.js的, 这并不代表什么, 仅仅是个人的选择

JIGI
2014-03-18 02:04:36 JIGI

我印象当中require里就算是cmd写法最后还是转化成amd加载了,所以不是bug,很正常的结果,先加载,再使用。

U_U
2014-03-18 09:27:06 U_U (好读书, 读好书(F2E))
我印象当中require里就算是cmd写法最后还是转化成amd加载了,所以不是bug,很正常的结果,先加载 我印象当中require里就算是cmd写法最后还是转化成amd加载了,所以不是bug,很正常的结果,先加载,再使用。 ... JIGI

不管什么写法, 最终都会变成 require(['a', 'b'], function(a, b) {}) 这样的模式, 因此有些不太清楚背后由来的朋友可能需要好好理解下

奈米摩尔
2014-04-08 11:21:23 奈米摩尔
这种评论也太让人无语了。 单纯说楼主不对,又不说理由。流氓啊。 这种评论也太让人无语了。 单纯说楼主不对,又不说理由。流氓啊。 旡止休

我这人看帖基本不回,看到1楼的评论忍不住了。lz写的很好,请负责认的评论

庚午月圆人
2014-06-06 15:29:01 庚午月圆人

写的挺好的,配图也挺有意思

Wintree
2014-06-22 19:24:10 Wintree (什么样 的才会喜欢)

涨姿势了

爷乐了
2014-06-23 14:27:23 爷乐了 (笑,人人陪笑)
兄台是真不懂还是装不懂啊?还不习惯异步的编程和思考方式?太片面太误导了。这种无良的方式推Se 兄台是真不懂还是装不懂啊?还不习惯异步的编程和思考方式?太片面太误导了。这种无良的方式推SeaJS其实会害了它 ... Cent

太赞同了!

预流
2014-07-03 16:59:55 预流 (一蓑烟雨任平生)

写得不错

123236Zll
2014-07-27 21:13:54 123236Zll
AMD 里面有写。dependencies表示该模块依赖的其他所有模块标识,模块依赖必须在真正执行具体的fa AMD 里面有写。dependencies表示该模块依赖的其他所有模块标识,模块依赖必须在真正执行具体的factory方法前解决 ... 蓝瓜

说得对!

我是只小小鸟
2014-07-29 22:51:19 我是只小小鸟
说得对! 说得对! 123236Zll

楼主,我碰到过这样的情况
require ('a');
require('a_01');

结果是偶尔会出现a_01先加载完,而a_01是要依赖a,so报错 ,我不知道是我的理解或者说用法有问题,还是。。。

我是只小小鸟
2014-07-29 22:57:26 我是只小小鸟
楼主,我碰到过这样的情况 require ('a'); require('a_01'); 结果是偶尔会出现a_01先加载完 楼主,我碰到过这样的情况 require ('a'); require('a_01'); 结果是偶尔会出现a_01先加载完,而a_01是要依赖a,so报错 ,我不知道是我的理解或者说用法有问题,还是。。。 ... 我是只小小鸟

seajs,本来想贴个图的,但这里好像贴不了

U_U
2014-07-30 08:59:33 U_U (好读书, 读好书(F2E))
楼主,我碰到过这样的情况 require ('a'); require('a_01'); 结果是偶尔会出现a_01先加载完 楼主,我碰到过这样的情况 require ('a'); require('a_01'); 结果是偶尔会出现a_01先加载完,而a_01是要依赖a,so报错 ,我不知道是我的理解或者说用法有问题,还是。。。 ... 我是只小小鸟

你所说的这种情况是指seajs中碰到的?

模块最终优化(打包)后应该都是依赖声明提前的, 依赖的加载也都差不多原理(不管是RequireJS或SeaJS)
例如
define('moduleA', ['a', 'a1'], function(a, a1) {
// a, a1 依赖会先加载, 并搜寻相关的依赖
});

我是只小小鸟
2014-09-24 17:22:37 我是只小小鸟
你所说的这种情况是指seajs中碰到的? 模块最终优化(打包)后应该都是依赖声明提前的, 依赖的加 你所说的这种情况是指seajs中碰到的? 模块最终优化(打包)后应该都是依赖声明提前的, 依赖的加载也都差不多原理(不管是RequireJS或SeaJS) 例如 define('moduleA', ['a', 'a1'], function(a, a1) { // a, a1 依赖会先加载, 并搜寻相关的依赖 }); ... U_U

恩,说的是seajs,你说的也是其中的一种解决依赖的方式,但是我的理解require也可以解决依赖呀,比如:

define(function(require,exports,module){
require ('a');
require('a_01'); //其中a_01.js依赖a.js
//问题:极少数情况下,a_01.js先加载完成,导致js错误
//思考:其中a_01.js和a.js都没有包装成CMD标准,就是jquery库,这里可能就是个坑,第二个坑,是否自己对seajs实现原理理解错误的原因,require根本就不能解决依赖?
});

U_U
2014-09-25 09:00:29 U_U (好读书, 读好书(F2E))
恩,说的是seajs,你说的也是其中的一种解决依赖的方式,但是我的理解require也可以解决依赖呀, 恩,说的是seajs,你说的也是其中的一种解决依赖的方式,但是我的理解require也可以解决依赖呀,比如: define(function(require,exports,module){ require ('a'); require('a_01'); //其中a_01.js依赖a.js //问题:极少数情况下,a_01.js先加载完成,导致js错误 //思考:其中a_01.js和a.js都没有包装成CMD标准,就是jquery库,这里可能就是个坑,第二个坑,是否自己对seajs实现原理理解错误的原因,require根本就不能解决依赖? }); ... 我是只小小鸟

模块化, require在以后的JS标准中会标准化, 现在想想模块的依赖问题真的很纠结.
按照其他语言的先例, 都是先找出依赖, 加载/执行这些依赖, 这样的思路也非常清晰.

对于你的例子, requirejs是会先找出依赖关系, 而不会理会require语句的摆放位置, 按照依赖关系来加载/执行a.js, a_01.js.

很认同 @jockchou 所说, 希望对你有所帮助.

无名
2014-10-15 13:18:38 无名

一、AMD 的标准写法 define(["a", "b"], function(a, b) { ... })
二、seajs最后需要通过构建工具转换为 Modules/Transport 格式再进一步压缩、合并。
define("id", ["dep-1", "dep-2"], function(require, exports, module) {...})
三、那么问题就来了,用过seajs是不是感叹打包好难?
四、正如玉伯所说:RequireJS 和 Sea.js 都是模块加载器,倡导模块化开发理念,核心价值是让 JavaScript 的模块化开发变得简单自然。
五、根据我大量的阅读文档,在遵循一定的写法,感觉这两个都能实现一样的功能。只是作者在推广其思想要如何如何。
我在用:https://github.com/ecomfe/esl

结论:根据自己喜爱和团队约定使用,没有谁优谁劣之分。

U_U
2014-10-16 14:11:00 U_U (好读书, 读好书(F2E))
一、AMD 的标准写法 define(["a", "b"], function(a, b) { ... }) 二、seajs最后需要通过构建工 一、AMD 的标准写法 define(["a", "b"], function(a, b) { ... }) 二、seajs最后需要通过构建工具转换为 Modules/Transport 格式再进一步压缩、合并。 define("id", ["dep-1", "dep-2"], function(require, exports, module) {...}) 三、那么问题就来了,用过seajs是不是感叹打包好难? 四、正如玉伯所说:RequireJS 和 Sea.js 都是模块加载器,倡导模块化开发理念,核心价值是让 JavaScript 的模块化开发变得简单自然。 五、根据我大量的阅读文档,在遵循一定的写法,感觉这两个都能实现一样的功能。只是作者在推广其思想要如何如何。 我在用:https://github.com/ecomfe/esl 结论:根据自己喜爱和团队约定使用,没有谁优谁劣之分。 ... 无名

一切都是工具, 不需要去攀比, 最好的结果就是运用好工具, 如果发现工具不适合时立马能够改进它, 这样才不会被动的使用工具

Cent
2014-11-11 14:56:48 Cent

wow,一年多不来,居然这么多评论,沙发没白抢:)

U_U
2014-11-17 09:27:48 U_U (好读书, 读好书(F2E))
wow,一年多不来,居然这么多评论,沙发没白抢:) wow,一年多不来,居然这么多评论,沙发没白抢:) Cent

感谢这么多评论, 这种讨论的方式, 让我学到了更多

leemrop
2014-12-09 15:51:31 leemrop

I love javascript.

颜海镜
2014-12-22 18:17:17 颜海镜 (less is more)

nodejs的顺序和seajs一样哈

bibodeng
2015-01-05 21:44:19 bibodeng (python lover)
你的requirejs的用法不对,错误的用法没法产生正确的结果。另外你可能更喜欢顺序执行的代码,但 你的requirejs的用法不对,错误的用法没法产生正确的结果。另外你可能更喜欢顺序执行的代码,但是这必须导致require时的阻塞加载(这很多时候其实是可以接受的),而同时满足非阻塞和顺序执行就需要需要对代码进行一些预处理,这样的源代码就不能做到“下载即可用”的效果。 ... Cent

我也感觉第一次运行的时候的例子有所不妥,应为requireJs它本身就是先加载后执行,也不能说它的执行结果不对,而是它按它的方式来而已。

U_U
2015-01-06 08:59:51 U_U (好读书, 读好书(F2E))
我也感觉第一次运行的时候的例子有所不妥,应为requireJs它本身就是先加载后执行,也不能说它的 我也感觉第一次运行的时候的例子有所不妥,应为requireJs它本身就是先加载后执行,也不能说它的执行结果不对,而是它按它的方式来而已。 ... bibodeng

应该是自己内心总是感觉代码顺序执行造成的, 因此忘记了requirejs先加载的模式

飞行的小弟
2015-03-10 19:55:55 飞行的小弟

还是实践才能出真知啊,解决了心中的疑惑

永远的梦魇
2015-03-25 17:37:14 永远的梦魇

楼主RequireJS的用法不对。

CrimX
2015-03-26 21:50:42 CrimX

楼主你加了后记还不够啊,前面的内容注释一下自己的错误吧。

1、你使用的是 AMD 的兼容方式,不是标准的 AMD 定义方式,没有突出 AMD 与 CMD 的不同。

2、这种方式造成了对 AMD 的不理解,于是对结果抱有错误的期望。就像抱怨盐为什么不是甜的一样。

3、后记中说的执行时机应该再详细说明。比如 main 依赖了 ["a", "b"],a 与 b 模块执行的时机本来就应该是随意的,因为你没有定义 a 和 b 之间的依赖。至于 main 模块中对 a、b 的调用则必然是按照 main 代码的顺序执行的。

这篇文章可以作为两者不同的探讨,但不能用错误的比较和坑爹的语气来说 RequireJS 有 bug 坑人啊。毕竟是你在拿摩托当单车骑(摩托单车仅作比喻)。既然玉伯链接了你的文章,应该会有很多后来人在看的,误人子弟就不好。

U_U
2015-03-30 16:53:42 U_U (好读书, 读好书(F2E))
楼主你加了后记还不够啊,前面的内容注释一下自己的错误吧。 1、你使用的是 AMD 的兼容方式, 楼主你加了后记还不够啊,前面的内容注释一下自己的错误吧。 1、你使用的是 AMD 的兼容方式,不是标准的 AMD 定义方式,没有突出 AMD 与 CMD 的不同。 2、这种方式造成了对 AMD 的不理解,于是对结果抱有错误的期望。就像抱怨盐为什么不是甜的一样。 3、后记中说的执行时机应该再详细说明。比如 main 依赖了 ["a", "b"],a 与 b 模块执行的时机本来就应该是随意的,因为你没有定义 a 和 b 之间的依赖。至于 main 模块中对 a、b 的调用则必然是按照 main 代码的顺序执行的。 这篇文章可以作为两者不同的探讨,但不能用错误的比较和坑爹的语气来说 RequireJS 有 bug 坑人啊。毕竟是你在拿摩托当单车骑(摩托单车仅作比喻)。既然玉伯链接了你的文章,应该会有很多后来人在看的,误人子弟就不好。 ... CrimX

非常感谢 Jaward 指出了我的错误, 我已经在文章开始处链接了你的评论.
希望还没有误人子弟, 文章中仅是个人比较喜欢使用 require('mod') 来使用模块, 因此自己碰了壁, 因此记录了自己的分析过程, 希望后来的人不要犯同样的错误.

dami
2015-05-12 15:39:44 dami

两种思路而已,不懂别瞎扯

星晨
2015-06-01 15:37:45 星晨
楼主你加了后记还不够啊,前面的内容注释一下自己的错误吧。 1、你使用的是 AMD 的兼容方式, 楼主你加了后记还不够啊,前面的内容注释一下自己的错误吧。 1、你使用的是 AMD 的兼容方式,不是标准的 AMD 定义方式,没有突出 AMD 与 CMD 的不同。 2、这种方式造成了对 AMD 的不理解,于是对结果抱有错误的期望。就像抱怨盐为什么不是甜的一样。 3、后记中说的执行时机应该再详细说明。比如 main 依赖了 ["a", "b"],a 与 b 模块执行的时机本来就应该是随意的,因为你没有定义 a 和 b 之间的依赖。至于 main 模块中对 a、b 的调用则必然是按照 main 代码的顺序执行的。 这篇文章可以作为两者不同的探讨,但不能用错误的比较和坑爹的语气来说 RequireJS 有 bug 坑人啊。毕竟是你在拿摩托当单车骑(摩托单车仅作比喻)。既然玉伯链接了你的文章,应该会有很多后来人在看的,误人子弟就不好。 ... CrimX

赞同

GuitarX
2015-07-02 08:24:26 GuitarX

兄台。。你真不懂还是假不懂。。
requirejs的依赖关系都没搞清怎么做。。

config文档好好看一下。如果你要b依赖a,请配置一下b对a的依赖。那样在b执行之前,必定执行a。。你没告诉require他们俩有依赖,他怎么做依赖?一行行写script先后执行不是更方便?

关键字: require config shim deps

U_U
2015-07-02 13:30:41 U_U (好读书, 读好书(F2E))
兄台。。你真不懂还是假不懂。。 requirejs的依赖关系都没搞清怎么做。。 config文档好好看 兄台。。你真不懂还是假不懂。。 requirejs的依赖关系都没搞清怎么做。。 config文档好好看一下。如果你要b依赖a,请配置一下b对a的依赖。那样在b执行之前,必定执行a。。你没告诉require他们俩有依赖,他怎么做依赖?一行行写script先后执行不是更方便? 关键字: require config shim deps ... GuitarX

只是个人理解和思考过程, 具体对错是非, 请多看回复

有风塘主
2015-07-03 10:30:32 有风塘主

【强烈建议!!!】
作为开始接触require和seajs的人,差点被楼主误导了
【强烈建议】楼主修改文章开头,更显眼更明确的提示:要看评论,我就没注意到
要不是我看文的时候,正好没啥事,没人打扰,不然我就看不到结尾和评论,然后我就会对require彻底的误解了
过来人都知道:刚接触时,对事物的第一想法,直接影响后来对该事物的大部分感官。。。

U_U
2015-07-04 20:39:16 U_U (好读书, 读好书(F2E))
【强烈建议!!!】 作为开始接触require和seajs的人,差点被楼主误导了 【强烈建议】楼主修改 【强烈建议!!!】 作为开始接触require和seajs的人,差点被楼主误导了 【强烈建议】楼主修改文章开头,更显眼更明确的提示:要看评论,我就没注意到 要不是我看文的时候,正好没啥事,没人打扰,不然我就看不到结尾和评论,然后我就会对require彻底的误解了 过来人都知道:刚接触时,对事物的第一想法,直接影响后来对该事物的大部分感官。。。 ... 有风塘主

请仔细看本文开头,早已注明了,还是感谢大家的留言和各种建议,总之自己的思考才是最重要的,我不是什么权威人士

coder
2015-11-12 14:41:11 coder

没明白seajs的按需加载有什么意义,被依赖的文件不管写在哪都是会被下载下来的,只是晚点执行了而已,有什么性能上的提升吗? 而且使用combo后好像都是变成了跟AMD写法一样了 都是提前写好依赖了

三炮
2015-11-26 00:01:09 三炮 (未至水窮處,怎知雲起時)

这里面不少优质前端狗先收藏了。

ufo_basker
2015-11-26 10:26:30 ufo_basker
我是js新手,冒犯地问各位大神一个问题,javascript作为脚本语言,代码肯定是顺序执行的,requir 我是js新手,冒犯地问各位大神一个问题,javascript作为脚本语言,代码肯定是顺序执行的,requirejs在没有解释到require的代码块时,它是如何知道需要预加载的所有js文件呢?又如何做到异步加载呢? ... dodeep

看requireJS源代码,他会先用正则搜索是否有require之类的文字,然后解析

风烟
2016-02-22 09:44:54 风烟

楼主能在说一下amd和cmd的文章对比着看就更好了

性感小猪猪
2016-09-01 16:57:32 性感小猪猪

评论真精彩,我居然看完了


U_U
U_U (湖南长沙)

weibo: t.qq.com/ufologist slideshare: slideshare.net/ufologist gith...

这篇日记的标签  · · · · · ·

JavaScript module

推荐这篇日记的豆列  · · · · · ·  ( 全部 )