话说最近看到的关于Seajs的坑，真不少；说什么seajs.use的相对路径解析有坑、依赖模块的缓存问题、自动化的压缩合并问题、es6来了，seajs过时啦！；是的，这些个问题确实不是不常见！那么，兵来将挡，水来土掩，选择了出击，咱就得迎难而上啊!
seajs.use的相对路径解析的问题，纯属个人写法的问题；无论是页面上seajs.use还是在合并在config里的seajs.use都是没问题的，seajs.use的相对路径是指向调用页面的，但是有静态资源站，所以用绝对路径肯定不会指错的；我个人发现个问题是由seajs的模块合并引发的，因为最终与我的需求冲突了：我要的是页面上只src两个文件，一个seajs，一个mainjs，因为现实的原因，页面后端输出，项目已成型，所以我能做的是尽力把改动压到前端，后端做最小的改动，因此往页面上加其他文件还有seajs.use(‘/path/*.js‘)是基本上要避免的，要不然到时得全站更新；当然，如果是项目刚开始的话，这些就不是问题了；OK，我分解模块，定义模块，弄个mainjs做config并分发页面主模块；至此，一切都是那么顺当，seajs,beautiful！
可是当我要自动化压缩合并模块时，坑就来了，很容易想简单的一个地方在于：一般的想法可能都是，合并文件，就是把几个文件打包到一起，然后压缩，然而在seajs里这样就大错特错了；seajs里一个文件即是一个模块，合并多个文件后在一个文件里会出现多个define，当然，这些多个define可以定义模块的独立ID，然后你之前的seajs.use路径要对应着改，因为你之前use的是一个模块，而现在那个文件里却包含的是一堆模块，你怎么use的到呢？而且这个合并的文件要不放在页面，而是用mainjs去代理的话，我得绕一大圈才行，我么多步骤、这么绕的自动化我只能呵呵了，原谅我的懒惰。。。往下看，自有替代方案。
前面也说了，这是个人写法的问题以及现实需求的原因，seajs本身还是很人性化的；分享一下，关于seajs的合并方式：gulp-seajs-combo；
1 var gulp = require(‘gulp‘),
2 seajsCombo = require(‘gulp-seajs-combo‘);
3
4 gulp.task(‘seajs‘, function(){
5
6 (function (urls,dest) {
7 for(var i=0;i<urls.length;i++){
8 (function (iurl) {
9 return gulp.src(iurl)
10 .pipe(seajsCombo())
11 .pipe(gulp.dest(dest));
12 })(urls[i]);
13 }
14 })([
15 ‘./public/javascripts/index1.js‘
16 ],‘./public/javascripts/dist‘);
17 // array > 页面主模块
18 // dest
19
20 });
合并压缩后对应着慢慢改配置吧！
至于依赖模块的缓存问题，这个做法就很多了，在require里加时间戳是最不推荐的，在config里的alias上加时间戳，可以考虑；常见的是config的map来实现：‘map‘: [ /^(.*\.(?:css|js))(.*)$/i, ‘$1?1314521‘ ]，这个问题在于，我本想去一个模块的缓存，结果把所有模块的缓存都去了；那么这样是不是就可以了呢？
1 map: [
2 function(url) {
3 if(...){...//}
4 }
5 ]
其实这里并没什么问题，只是要提醒自己，某个时候，依赖模块也是要去缓存的；
既然标题叫做《好好的Seajs，说不用就不用了》，说明我最终放弃了Seajs，原谅我！
我的错，是我懒，不想改来改去，才出此下策；挥别Seajs，擦干泪，迎接Browserify吧！
说到模块化，Nodejs那家伙做的老好了，正儿八经的Nodejs里一切皆模块；话说Seajs的模块化机制有参考Nodejs呢；现在好了，使用Browserify，咱也能在javascript里像写Nodejs一样来组织前端模块了；那些看似多余的前奏可以参考：[回首来时走过的-模块化之路，Browserify让你的Javascript游走于前后端]，我的个人小站是个我业余的实验厂，基本上有什么想法，插件啥的，如果不能立马用到工作的项目里，我便会首先想法用到这个小站上，最初是用的Seajs组织的一些杂七杂八的模块，现在全改为Browserify了，目前感觉挺好的！好吧，其实这是个广告！我只是个初入前端的小前端，大侠绕过这段吧；
用上了Browserify：
- 前端的模块化，说好的Seajs、Requirejs呢？丢掉，丢掉
- define那个wrapper，丢掉
- 安静的定义模块(不用define了)，require模块吧
- 不用改来改去，一键gulp到指定目录
现在，前端开发环境可以改为Nodejs了，像写Nodejs一样写JavaScript，去require模块，单个模块不用define，甚至都不用module.exports，依然可以require；唉，这些一个人时乐一下就行了，还是安静的做个美男子吧！上代码了。
1 var browserify = require("browserify");
2 var source = require("vinyl-source-stream");
3 var streamify=require(‘gulp-streamify‘);
4 var uglify=require(‘gulp-uglify‘);
5 var buffer=require(‘vinyl-buffer‘);
6 var watch=require(‘gulp-watch‘);;
7
8 gulp.task(‘go‘,function() {
9 return browserify(‘./public/javascripts/index1.js‘)
10 .bundle()
11 .pipe(source(‘index1.js‘))
12 .pipe(buffer())//.pipe(streamify(uglify())) //压缩耗时间 上线处理
13 .pipe(gulp.dest(‘./public/javascripts/dist‘))
14 });
有个小问题，开发时F5按的比较频繁，每次保存后，还得gulp一下，是不是有点多余，听说gulp有个gulp-livereload，不过需要浏览器的插件支持；还有个更好的browser-sync，多端同步刷新，自行github吧；其实gulp-watch也不错；
1 gulp.task(‘watch‘,function(){
2 gulp.watch(‘./public/javascripts/index1.js‘,[‘go‘]);
3 });
当然，这只是初级的结构，问题肯定也少不了，一切从实际出发，具体问题具体分析吧；反正我是爱上了这种搞法；
那么，ES6来了，Seajs过时了吗？我一个小前端没有发言权，不管怎样Seajs的历史作用是毋庸置疑的，再说了，PC端特别是IE那堆历史遗留问题，ES6就算babel到ES5兼容到IE9+问题不大，全面用还是尚需时日的；不过正因为此，前端有了更多的可能性，咱也看到了前端更美好的未来；