前端技术如何选择

在如今前端技术海洋里，如何为项目选择合适的前端相关技术让人眼花缭乱。特别是大型项目，技术的选型显得尤为重要。一旦选错，将会为此付出巨大代价，轻则新旧兼容，增加维护成本。重则推翻重来，增加了开发成本。我们不应盲目的追求新的技术，也不应盲目坚守固有的技术，适合团队及项目的才是最好的。

项目的需求是技术选择的首要条件。兼容性、内容、交付时间、UI交互等决定着我们技术选型的大方向。

1、兼容性

兼容性是前端发展的产物，也是前端运用新技术的绊脚石。我们排斥鄙视它，却又不得不面对它。兼容性有端的兼容，如PC端还是移动端。移动端的性能要求比较高，框架及插件都要尽量小，如移动端喜欢用zepto.js而不用jquery，屏幕的适配则使用轻量级的lib-flexible、Enquir.js而不是比较重的bootstrap。除了端的兼容还有浏览器种类及版本的兼容。像公司有些PC端项目就要兼容到ie6及其他浏览器，有些则要兼容到chrome11这个特定的版本。可供选择的主流也就所剩无几，如jquery、KnockOut、国内的一些比较冷门的库如ligerui、BSIE、avalon、EXT等，更别提新的前端技术Angularjs、react、vue等。

2、同类如何选择

在相似功能的框架中，我们如何选择呢？得看他的功能是否丰富以满足我们项目的绝大部分需求；社区是否活跃，让我们有问题可以得到解答，同时也能间接反应出他的用户量有多大；更新是否及时、文档是否齐全、上手难易程度等这些都是选择的要点。

3、项目内容

项目的内容也是技术选型的一大要素，比如页面内容都是门户、新闻等建站类的，页面的交互非常简单，主要是页面布局和一些页面效果，那我们主要就选一下css预编译工具， js方面选一些基础类库jquery这样的就好，来提高编码效率。另一种则是类似CRM后台管理的界面，频繁的对数据进行增删改查，并且数据交互和业务逻辑都异常复杂，这类项目维护升级的时间往往会很长，技术选型及ui框架的选择都需要长远考虑，比项目要长寿这是最好不过了。

4、交付时间及UI交互需求

项目的交付时间同样也影响着技术的选型。因为开发的效率很大程度决定了上线时间。对于用几周或者几个月的时间来做一个项目，选择一个现有的框架就好，UI交互也往相关框架上靠拢。对于用几年的时间来做一个项目，则我们需要根据团队的情况选好技术类型，再看看最优UI交互需求来决定是否需要造一些轮子（UI组件）。

我个人不太推崇动不动就造轮子，除非主流的框架无法满足交互需求，且这个项目有几年的密集开发周期，或者大量小型项目都可以用到。记得2012年，刚毕业1年多，我去了一家公司，做的就是造前端轮子的事情，扩展、改造EXT，弄成HTML语义化标签，让只会静态页面的人员只需要通过标签配置及简单的JS 就可以实现所有前端功能。只知道这个山寨版的HTML5在北京总部运用到了好几个项目上，得到了表彰。然而不到两年，HTML5的出现，使得这个笨重的基于EXT的组件库被上层否掉，不再维护。于是我们领导又要求我们折腾出另外一套轮子，当时我们选择的是模仿淘宝的kissy，弄了一套轻量级的按需加载的组件库。然而据我了解就用到了一个淘宝的项目上，拿到了政府补贴后，就没了下文，组件库和项目都不再维护了。当时负责组件主力的我们，常常自我调侃，北京总部尽情折腾吧，刚好给我们练手，提高技术。对于大型的公司，这样的人力消耗无所谓，然而对于一个中小企业，还是挺奢侈的。

5、团队

除了项目的需求外，项目的前端团队成员也影响着前端的技术选型。应根据自己的人员的配置来挑选框架。有些项目前端就那么两三人，还不是专业的，最好就直接用现有大家比较熟悉的或者大家都想用的一个技术框架且至少有一个人深入了解过。不建议造轮子。我们要遵循不求最好，但求最合适。有些框架在牛逼人手里非常牛逼，在其他人手里就是乱麻。在一般的企业里，项目作战的很多都是刚毕业没多久的学生。对于他们来说易上手，相关中文文档齐全、大家比较感兴趣的框架优先考虑。在技术选型上我们还要防止锤子定律。对于长期用一种框架的人，不管什么项目，他会觉得都可以用这个框架。而突然引入一种新的框架，往往会非常的排斥。为了防止这种现象，团队需要开拓视野，通过文章分享、培训等让成员了解新的技术，尽量找合适的项目让大家实战一下。

6、案例

公司HIS5项目，在开发了快1年之际，出了一套基于vue的组件库，架构上zoeUI和vue并存。为什么会在这个时候才换了组件库及技术呢？

项目之初，我们对项目需求及UI需求了解得非常的肤浅，只知道：

• 是浏览器核程序，只需要兼容到chrome50+；

• 很多操作需要快捷键；

• 后端人员不会前端；

• UI组件需要定制；

而当时的项目前端团队成员只有3人，他们最熟悉的就是公司zoeUI组件库。开发迫在眉睫 ，因此根据需求及成员技术储备情况选择了jquery+SCSS+zoeUI+nodejs。而当时的这个决定，导致为了满足UI需求大量的性能损耗以及开发效率的低下，zoeUI自身的性能也不是最优的。这与后续从客户那要求的快是相违背的(今年3月相关人员去了医院看了他们实际his4的操作)。因此决定重新选择前端技术，以免后续无法满足性能要求。 最终确定了jquery+SCSS+vue+HIS5vue组件+webpack构建+nodejs的新方案。这个选型满足了以下条件：

• 满足兼容性要求；

• 文档齐全，上手容易，用户群里多；

• 组件为his5量身定做，提高性能；

• 成员都有一定的接触和了解，有人还有实战经验，大家也比较喜欢；

• 相比以前，代码量有所减少，开发效率逐步提升；

• vue自身性能方面也是很不错的；

架构上面兼容了旧页面，对于用户来说zoe、vue总体上没有什么差别。这样的方式也把项目的风险降低到最低，同时也为我们重构页面带来了时间。

7、结语

无论我们选择什么框架或者自己造轮子。都勿忘初心，技术必须让我们工作更加的轻松愉快，选择我们能驾驭的框架，虽然我们不能保证其一年之后是否落伍，但至少不会变成绊脚石。合适的才是最好的。