谈谈这几天使用SeaJS 的感受

前几天，没事了解了一下四种模块化规范，其他三种规范都玩过，ES6规范搭配webpack使用，非常舒服，文档，插件样样俱全，不过呢，需要编译，有点麻烦。 Sea.js这种可以直接在浏览器端运行的，很让我感兴趣，看了下源码，加载模块机制什么的大致了解了，不是根据项目目录，而是根据sea.js的位置，或者相对window.location查找的。但有个很坑的地方，貌似很多库的支持都需要改源码，像Vue.js，Jquery.js，Vue还支持了AMD。文档有，但很入门，也没有什么深入的地方，基本defined一个模块后，就是按照普通js去写了。 这个框架给我的感觉就像是原生JS到ES6一个中间过渡，在没有ES6之前，Sea.js 和RequireJS都是很不错的JS模块化选择。但ES6，甚至ES7的出现，在加上各类编译打包工具，转码工具，npm上各种开源模块支持，使得ES6成为模块化编程成为首选，有很多人给你造好了车轮，你需要上npm找一个，然后require或者import，然后打包编译，甚至能兼容IE9。 相较之下，Sea.js完全是孤军奋战，模块要自己敲，不想造车轮的话，就要上npm找，如果有浏览器版本的就改一下源码，没有的话还要自己手动用browserify弄，弄完后还要粘贴到项目里，用sea.config配置别名。这些都没有现成的，都得自己弄，为什么，CMD很小众，没有人去了解，去支持，去维护。Sea.js太简单，正如我之前所说defined然后按普通js敲，然后export作为模块，没有语法糖，没有新特性，Generator，decorator，只支持js文件，其他类型像.vue，.less等之类的加载器基本没有，实现的话，可以，但需要通过编译实现，我就试着实现了一个.vue文件的加载器，把一个.vue文件转成sea.js模块。 为此，Sea.js想要发展，它就不能孤军奋战，它需要一个专属于它的打包编译工具，能够将那些不支持Sea.js的模块，转为CMD规范的模块，要有加载器，能够将其他非js文件，也编译为CMD模块，这也就意味着要学习Webpack，要依赖Nodejs，要有人帮忙造车轮，而且是一个重复的车轮，因为说到底，Sea.js只不过是CMD的一种规范实现罢了，只是一种写法而已，Webpack和Browserify都可以自己通过配置，编译出实现这类规范的浏览器端js。因此，这个打包工具的开发将显得没有任何意义，因为它让将所有模块都依赖了Sea.js，离不开defined，而webpack之类的打包工具，则是根据模块间的依赖，将其编译为符合AMD，CMD的JS文件。 所以一旦在模块化开发中，引入了Sea.js或者RequireJS，就意味着你和npm上大部分车轮没关系，如果他们不提供浏览器版本，不支持Sea.js，你都需要改源码，这将会极大地降低开发效率。这几天我都是，上npm，上gitbug，下源码，找到dist，找到浏览器版，找到源码版，看源码，改源码，放到项目中，sea.config给他设置个别名，遇到没有浏览器版的，你甚至还要browserify，然后，当然编译后的代码根本没法改，你只能简单的require作为全局变量用。现在的情况是，车轮是不用造了，但是要老子频繁地改车轮。这里我建议，写个工具，将ES6规范转成Sea.js的CMD规范，要来的简单好多了，最起码一劳永逸啊，造福群众。 我看了网上许多文章，都是关于四个规范的特点，差别来讨论，看了看去都一样，给我一种Sea,js很牛逼的感觉，等到实操过后，是很牛逼，但是老是说，造车轮很痛苦，改车轮也很痛苦。 总而言之，Sea,js作为一种CMD的规范，代码写的很简单，也很巧妙，可以用于模块粒度小的项目，如果模块不多，也不需要依赖太多复杂的车轮，可以省很多