谈谈这几天使用SeaJS 的感受

[Linchaojin]

前几天，没事了解了一下四种模块化规范，其他三种规范都玩过，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的规范，代码写的很简单，也很巧妙，可以用于模块粒度小的项目，如果模块不多，也不需要依赖太多复杂的车轮，可以省很多<script>标签，使用简单的模块化开发，采用基本的html和css渲染网页的话，是个不错的选择，相比传统写法，把所有的function往一个js文件了怼，Sea.js这种写法简直不要太舒服。如果使用Vue.js或者需要比较大规模的模块开发，涉及到n个请求接口的编写，n种组件，各种框架，监听机制，采集机制，定时任务，css等静态资源管理的话，还是用ES6 + webpack比较舒服，毕竟不用自己造车轮，兼容问题使用babel转码的话，也是简简单单。

[afc163]

Try https://github.com/systemjs/systemjs

[Linchaojin]

我最近有学习了下Webpack，虽然没有CMD的打包选项，看了官方文档后，我发现是有可以集成的可能性，但是需要自己写个插件，也就是说，可以使用 Webpack 将一些J非CMD规范的JS组件转成CMD规范的然后在Sea.js项目中使用，不过打包貌似还是个问题。

[masx200]

CommonJS模块转换成cmd模块其实也比较简单

前面加上
define(function(require,exports,module){

后面加上
return exports})

就可以了

[UmbraCi]

前几天，没事了解了一下四种模块化规范，其他三种规范都玩过，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的规范，代码写的很简单，也很巧妙，可以用于模块粒度小的项目，如果模块不多，也不需要依赖太多复杂的车轮，可以省很多<script>标签，使用简单的模块化开发，采用基本的html和css渲染网页的话，是个不错的选择，相比传统写法，把所有的function往一个js文件了怼，Sea.js这种写法简直不要太舒服。如果使用Vue.js或者需要比较大规模的模块开发，涉及到n个请求接口的编写，n种组件，各种框架，监听机制，采集机制，定时任务，css等静态资源管理的话，还是用ES6 + webpack比较舒服，毕竟不用自己造车轮，兼容问题使用babel转码的话，也是简简单单。

层主你好，公司有一些老项目使用的是seajs二次封装的框架，尝试着用VUE渐进式开发，script标签引入element前端框架以及VUE.js，搭配httpVueLoader.js进行vue单文件的加载，我大概看了下框架的原理，是hack了标签的跳转功能进行局部html文件的替换，然后加载局部html文件的同名js脚本，实现类似spa的功能，目前我用自己探索出的这套渐进式的方式已完成部分新功能的开发，可因为seajs不熟悉，而且经验不足，总担心在每个局部页面实例化的vue对象或者里面的一些对象没有及时销毁导致内存泄漏，不知层主可否指点一二。非常感谢