大家好，本期我们来聊一聊所谓的不用就会落伍的前端技术，如vue-cli、react-cli、element-ui、ant、npm、nodejs等。
前面讲前端架构需要解决的问题时候，有不少小伙伴觉得现在还聊JavaScritpt、规整化、单页应用等话题就是过时，再加上我们调研了一下网上的视频教程，都一边倒地鼓吹vue-cli、react-cli、typescript、ant、element-ui等前端技术，搞得好像不会这些技术就是落伍，保持原生前端网页开发就是过时一样。我们认为再流行的技术也只不过是个工具，是解决问题的手段。
所以，我们还是来聊一聊这些所谓的流行技术，以下说的都是真实项目会遇到的问题下面，我们分别讨论一下这三个最核心的问题：
原生开发还是用脚手架？
组件工具箱真的这么好用？
代码写得越少，真的意味着项目越快完成吗？
1、原生开发还是脚手架开发？
原生开发指的是直接使用Html+JavaScript+Css开发脚手架开发指的是使用vue-cli、react-cli、angular等脚手架工具开发。
首先，原生开发并不是不能使用框架，如vue.js、react.js就是纯原生网页开发的框架所以在基本的开发效率上，如数据双向绑定、指令等。无论是原生开发还是使用脚手架，都是差不多的。
原生开发和脚手架开发的最大区别在于组件上，脚手架有个看起来很好的优点，就是无限级嵌套组件（原生开发是不能的）也就是说，你甚至可以把一个按钮封装成一个组件，然后被其他组件引用，这样，代码量理论上可以降到最低。也就是说，任何前端元素，在最理想的情况下，不会写两份代码。
脚手架的这个优点确实击中了很多人的痛点，代码少了，不就是可以早点下班了吗加上官方组件库的加持，要写的代码就更少了。但是，实际情况真的是这样吗？
举个例子，一个页面由很多组件组成其中组件又嵌套了很多组件，组件和组件间又有互相调用的部分，如果其中一个组件需要改动的话（如需求变更、Bug修正等），根本分不清楚关联关系（究竟影响了哪个页面），如果是大型项目，一个前端子项目甚至会出现几百个组件，那就更分不清楚了。
这时候，很多小机灵鬼就会这样做，把需要改动的页面中的组件单独复制一份出来，这样，就不会影响到别的页面了。这样的话，看似问题是解决了，但是如果需要再改动呢而且你新复制的组件又被其他人引用呢？那么，难道还要再新复制一份？最后前端项目的代码终将会面目全非，全是补丁，一两年后项目就得重构。
所以，脚手架开发前端网页，也就是开始的时候比较快，一旦进入bug测试、优化阶段，就会严重慢下来，最后跟原生开发一对比，真的没多少效率可言。
上次我们说前端规整化问题的时候，举了javascript文件乱引用的问题？很多小伙伴不以为然，但其实你用什么框架都有混乱问题（而且人越多越混乱），我们推荐的是，如果使用脚手架开发的话，应该限制组件的调用层级，只需要留一层组件就可以了，并且规定组件间不能直接关联。
这样做的话，用脚手架开发的效率仍然在原生开发的效率之上，因为，脚手架的组件概念，即使仅使用单层组件仍然可以降低代码量。
那么，使用脚手架还是原生开发呢？在处理好规整化的基础上，如果项目规模较小、团队都熟悉这个技术，那么我们推荐使用脚手架开发，如果项目规模较大，那么我们推荐使用原生网页开发，当然，我们也推荐使用轻量级的vue.js、react.js框架。
因为项目规模较大的话，则需要处理性能问题，我们曾经试过将个页面做成一个脚手架工程，结果是打开时候很慢，性能差一点的机器直接崩溃，项目规模大的话，每个页面的性能要求也高，而使用脚手架这种重度封装的架构，则会对性能调优造成阻碍。
另外，很多人也不见得真正熟悉脚手架等技术，那还不如原生开发，毕竟原生开发更简单。
当然，最好的一种框架应该是在原生开发的基础上，加入组件的概念（组件可单独调试）。这样，既可以保持前端开发的简单性和高性能，又可增加开发效率，我们做了这样的框架，等前端架构部分结束后我们会介绍一下我们的自研架构。
2、组件工具箱真的那么好用吗？
如果项目规模不大，或者项目规格不高的话组件工具箱确实很好用，毕竟拿过来就可以用了。
但是项目规模较大，或者项目规格较高的话，那么组件工具箱就不那么好用了，因为这些项目在UI样式上一定是十分严格的，而组件工具箱的风格改起来是特别麻烦的，如element-ui，由于它是与vue强绑定的，所以要深度改它的样式的话，真的很痛苦。
所以，关于组件工具箱的选用，我们是推荐选用与UI风格相似的组件工具箱。当然，我们也比较推荐BootStrap，虽然上手比较难一些，但这个组件工具箱是轻量的工具箱（不依赖框架），可塑性较强一些（修改样式难度较低）。
3、代码写得越少，真的意味着项目越快完成吗？
我们的答案是否定的。
很多人都在鼓吹使用vue-cli、react-cli、Elment-ui等工具，其最基本原因是代码写得少，感觉拼接一下，一个网页就出来了。
但是，这种场景也只适合于一个人的项目，如果是具备一定规模的项目，这种快速开发的工具反而会成为累赘。因为你的代码写少了，就意味着别人帮你写的代码是多的，也就是代码盲区就比较大。一旦出现UI改版、性能调优等场景时工作量会变得完全不可控。
毕竟，一个项目，永远不是完成功能就可以的，还必须考虑需求改动、安全、性能调优、运维、后续升级等一系列更为重要的事情。我们也使用过很多重型框架或技术但最后的效果都不太好，起初开发时，确实能较快完成业务功能，但是到性能调优，或者遇到一些框架本身的问题时工作量就很多，甚至有些问题根本没办法解决（因为是别人写的代码）。
聊到这，应该会有人会说过一两年重构不就好了吗？到时会出现更好的技术，平台也赚钱了，再重构一次就好了，淘宝不是都重构好几次嘛。
这个观点也不能说错，但是应该没有平台愿意花多次钱做相同的东西（几年重构一次）。而且如果总抱有这种想法做软件的话，可能永远做不好。
最后，我们希望大家理解一个道理，所有技术都只不过是工具，如果认清不了问题是什么，那么工具也就发挥不了它本来的作用，所谓的流行性，并不是选择的第一要诀。