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

#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之类的工具模拟数据，和后端联调的时候把接口地址换掉就好了

#41

大哥，还在找工作吗？来我怀抱吧。

#42

换公司才能解决，对于顽固派，硬来是不行的。

#43

如果做严格前后端分离，整个公司开发人员都要重组，要分出后端人员和前端人员，这估计更没法实施了！我还是准备跳槽算了！

#44

很显然前端地位太低，如果前端能跳出来说一句：“你们就给我好好写接口就行，页面你们不用管”，那这事还可以做

#45

很多人其实没有习惯这中严格前后端分离的开发模式，或者说现在还有很多项目没有实现api化，还是传统的在view中写js等的开发方式，特别是老员工，他们都是这么过来的，一下子没法改变过来也是正常的！

#46

严格前后端也是扯淡，至少实际执行效率很低，全栈才是王道，哈哈哈哈

#47

实际上并不是每个人都想成为全栈，有些人也确实对前端不感兴趣。:grinning: :sweat: 我觉得全栈也不是很牛逼的事情，大多数的全栈只是说懂的面多一点，实际上也只是懂得多一点，真正能做到很多都很精通的毕竟是少数。

#48

赞成。