大型单页，一后端大牛让我从webpack转RequireJS

#21

SystemJS + ES6（Babel） + React 已完工：

2 Likes
SystemJS + ES6（Babel） + React 示例
#22

增加在线示例：
http://luqin.github.io/systemjs-es6-react-demo/

#23

不是大牛。这两个都在用着，但没有大项目经验。照着 ant design 有的组件，自己玩了把，做了点基本组件 http://imiao.in

#24

@jerryshew 不错嘛，要不要跳槽 :joy:

#25

你提的什么修改即可见到效果等webpack都可以实现啊，而且很简单。另外为什么不接受整体构建？？？如果不能接受是否可做代码分割？这些事件为什么后端说了算，这样的公司好怪异，什么年代了

#26

为什么后端需要启动webpack？前后端都分离了，他们为什么要关心前端用什么技术

#27

我指的是，直接修改AMD的文件，不需要webpack编译。另外，后端架构师有整体架构权利。

#28

这是后端不合理的要求。

#29

前后端分离应该定义好 json-api接口参数为界,然后剩下各负责各的,爱用什么就用什么

#30

已经前后端分离，不管是AMD/CommonJS/ES6 Modules 还是其他方案，都可以实现解耦开发，选择适合不折腾的就好。

#31

:joy: 你这样敬业，你们老板知道么？ ps：写后台管理感觉还是 emberjs 要容易点。

#32

既然已经前后端分离，而且“后端大牛”又不修改前端代码，那么你完全可以在你的开发环境下使用 webpack，然后提交的代码是打包后的代码。对于“后端大牛”，webpack 的角色可以是透明的。

另外你可以尝试跟“后端大牛”沟通，他可能不了解 webpack 到底有多先进。如果他仅仅因为 “希望像RequireJS那样修改文件即可查看效果” 而选择 RequireJS，那就只能呵呵了。

#33

我已经无力吐槽了。。。即使需要babel/webpack编译完，再配置requirejs，这么麻烦他们也不知道怎么想的，反正就是咬定要这样。。。而且他们也反正不写前端。

#34

在研究SystemJS，增加 echarts 和 webgl 3D 示例：
http://luqin.github.io/systemjs-es6-demos
http://luqin.github.io/systemjs-es6-demos/dist/index.html#/three.js/webgl-buffergeometry-drawcalls
http://luqin.github.io/systemjs-es6-demos/dist/index.html#/three.js/hello-world

1 Like
在研究SystemJS + Babel，增加 echarts 和 webgl 3D 示例
#35

项目很大的时候，AMD很容易引起一些模块不同版本的冲突，比如B引用了A的1.1版本，C又引用了A的1.2版本，这种维护的时候特别容易有坑。
CMD整个npm社区都是你的武器库，缺什么直接拿来就用。

#36

如果你用 gulp 编译 babel，也已经违背了 “希望像RequireJS那样修改文件即可查看效果” 这个原则啊

#37

是的，前端进行整体构建已是必不可少了，何况还是单页，合并请求/压缩/md5……

#38

我想问下，前后端都已经分离了，怎么会存在所谓的后端启用webpack的情况，发布的版本都是前端打包好的生产环境代码，跟后端没啥关系吧，唯一有关系的就是接口的数据前后端一致性

#39

我们公司也遇到了这样的问题！
我们公司的情况是整个开发没有做很规范的前后端分离，前端只负责做出静态html和js动效，再交由后端人员完成动态填充数据，此时就要再对js进行修改。这种情况，如果是用requirejs，那么后端人员只需要改改js就能看到效果，如果是用webpack则每次修改后都需要构建一次，这种情况他们肯定是不能接受的。还有就是你要让每个参与项目的人都装一个webpack的运行环境，则是难上加难。
看到这么多支持webpack的声音，也想了解一下，大家是怎么解决这各问题的？

#40

先和后端约定好接口规范，前端开发的时候，用mockjs之类的工具模拟数据，和后端联调的时候把接口地址换掉就好了