好好的Seajs，说不用就不用了

话说最近看到的关于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；

var gulp = require('gulp'),
    seajsCombo = require('gulp-seajs-combo');

gulp.task('seajs', function(){

    (function  (urls,dest) {
         for(var i=0;i<urls.length;i++){
            (function (iurl) {
                return gulp.src(iurl)
                    .pipe(seajsCombo())
                    .pipe(gulp.dest(dest));
            })(urls[i]);
         }
    })([
        './public/javascripts/index1.js'
    ],'./public/javascripts/dist');
    // array > 页面主模块
    // dest

});

合并压缩后对应着慢慢改配置吧！

至于依赖模块的缓存问题，这个做法就很多了，在require里加时间戳是最不推荐的，在config里的alias上加时间戳，可以考虑；常见的是config的map来实现：'map': [ /^(..(?:css|js))(.)$/i, '$1?1314521' ]，这个问题在于，我本想去一个模块的缓存，结果把所有模块的缓存都去了；那么这样是不是就可以了呢？

map: [
    function(url) {
        if(...){...//}
    }
  ]

其实这里并没什么问题，只是要提醒自己，某个时候，依赖模块也是要去缓存的；

既然标题叫做《好好的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；唉，这些一个人时乐一下就行了，还是安静的做个美男子吧！上代码了。

var browserify = require("browserify");
var source = require("vinyl-source-stream");
var streamify=require('gulp-streamify');
var uglify=require('gulp-uglify');
var buffer=require('vinyl-buffer');
var watch=require('gulp-watch');;

gulp.task('go',function() {
    return browserify('./public/javascripts/index1.js')
        .bundle()
        .pipe(source('index1.js'))
        .pipe(buffer())//.pipe(streamify(uglify()))  //压缩耗时间   上线处理
        .pipe(gulp.dest('./public/javascripts/dist'))
});

有个小问题，开发时F5按的比较频繁，每次保存后，还得gulp一下，是不是有点多余，听说gulp有个gulp-livereload，不过需要浏览器的插件支持；还有个更好的browser-sync，多端同步刷新，自行github吧；其实gulp-watch也不错；

gulp.task('watch',function(){
    gulp.watch('./public/javascripts/index1.js',['go']);    
});

当然，这只是初级的结构，问题肯定也少不了，一切从实际出发，具体问题具体分析吧；反正我是爱上了这种搞法；

那么，ES6来了，Seajs过时了吗？我一个小前端没有发言权，不管怎样Seajs的历史作用是毋庸置疑的，再说了，PC端特别是IE那堆历史遗留问题，ES6就算babel到ES5兼容到IE9+问题不大，全面用还是尚需时日的；不过正因为此，前端有了更多的可能性，咱也看到了前端更美好的未来；