前端小总结一下
最近前后端都在写，而且相对来说前端写的多一些，因为领导说了，咱们这条产线实行前后端分离策略，但是团队里不再招专业前端，那xxx你先上，你不是常说你是一块砖吗，哪里需要哪里搬。是的，xxx就是我，所以朋友们在公司切记谨言慎行。当然主要还是我觉得了解下前端还是可以的（但是打死不写css）。
所以我就从一个后端干到了前端，当然团队里肯定是有专业得前端的，不过因为咱们事业部有几条产线，所以资源稍有紧张，给到咱们产线就两个前端，有一个只会css，css肯定得有得，不然你想想啊，就算领导放心让你写css，你也肝颤啊。so，我就从产品mvp开始到正式产品立项，就主要精力在前端。
一入前端深似海啊
前段的东西太多，而且层出不穷。抵御诱惑的最好办法是什么？我觉得是先仔细想想需不需它，当不确定时，先放着不着急做决定，只要坚定自己所要的东西，什么诱惑对你都是过眼云烟。
脚手架的选择就出现了两派，一派以我为首，崇尚拿来即用避免重复造轮子，一派以专业前端同学为首，崇尚自己搭一套脚手架。具体就不细说，反正双方谁也说服不了谁。最终领导说了，谁是主要负责人谁说了算，当然专业前端是主要负责人，所以最终就决定自己搭建脚手架。当然这个过程是很痛苦的，时间也很长…曾今一度放弃这个方案，但是想着已经花了那么多精力了，就咬咬牙继续整了。最终大概前前后后花了3-4个月时间才算稳定了，当然这个过程编码还是断断继续在进行的。
所以这块主要说下webpack，现在的前端打包工具我估计没谁说不用webpack吧，webpack教程我就不恬不知耻的讲了，网上一堆。不过我还是觉得大家尽量系统的看教程，别东一块西一块凑。
脚手架
对于webpack打包工具，涉及到性能，我认为的三个关注点：
包大小
主要是从压缩、去重（注意依赖公共部分单独打包）方面考虑，能从现有的配置解决的就不要引入新的插件，用了插件需要在官方了解每个数的意义。
项目中：js压缩用的UglifyJsPlugin，第三方库处理我们用的是CommonsChunkPlugin（有人说DllPlugin更好用），后面会抽时间试下。
包拆分
打包时，注意包的拆分，按模块按页面，可以分得细一些，让页面按需加载…，别都打到一个包里，一开始我们就遇到这个问题，打开一个页面光渲染所需的内容就要下载半天。
打包速度
能用缓存的用缓存，不需要转译的就别转译，Happypack能多进程执行打包，会快点
有两个很漂亮的可视化插件，*JARVIS、webpack-bundle-analyzer ，对于优化打包很有用。*
小结
前端选型一定要适合团队和自己业务发展的。其它人觉得好用，你得看看其它人的场景和公司的体量。
没有特别与众不同的要求或者很多的个性化，避免重复造轮子。
当资源有限的时候，先保证功能性，再保证性能，但是性能优化一定是一个长期的非功能需求。
技术栈
没什么好说的……，都是主流的