关于前端产品技术选型问题的若干思考

0. 引言

一个好的前端产品，必然是用户体验优秀. 使用流畅. 数据准确. 界面友好的产品。要想达到这个目标，一开始的技术选型就需要非常慎重，不能图一时之快而导致后期维护升级成本指数级上涨，也不能忽视团队的技术沿革和老板对产品定位的要求。

PS. 技术选型仁者见仁，本文只谈经验，提供一个选型的思路，而不是给你具体的方案

选型的目的

顾名思义，就是为了实现收益最大化，是产品要求和技术成本之间的一个权衡。

1. 从企业的角度考虑选型

企业的存活宗旨是用最少的人力成本创造出尽可能多的企业效益，从这个出发点就可以得出企业对一个产品选型的要求。

保证产品质量是基础

产品质量要过基本关。不要求能有很惊艳的效果，但是一定要满足客户的要求，网页不能长时间白屏，要不错位不卡死，操作正常，数据精准。更进阶一点的，可能还会要求一定的交互和视觉体验，还有可能会加入无障碍效果。

如果要加入兼容阿拉伯语网站排版的话，已有的架构可能完全不能用，需要单独增加一倍的工作量再写一套 -_-

降低成本是必要条件

成本包括前期开发投入的人力和后期维护投入的人力。前提投入人力越多，开发的周期可能会短，但是与之对应的是团队协作的管理成本会高起来；前期人投入的少，可能技术选型会有漏洞或者可扩展性不足，后期换人来维护的话可能会举步维艰，不得不重构。

2. 从产品技术形态上来考虑选型

产品的技术形态指的是其技术模式，分为纯前端开发. 前后端分离和后端驱动的开发。

纯前端页面

纯前端的一般是一些静态页面，比如个人博客. 一些活动页面. 宣传网站等。一般来说一个人足以，此时你就不需要考虑什么架构了，使用你最擅长的技术栈和成熟的生成工具，能够快速堆砌起来页面就好。

前后端分离

这种产品形态应该是目前市面上大多数产品的开发模式，比如大型的ToB项目. 成熟的APP网页客户端. 网页购物等。这种的产品，页面渲染基本上是前端的工作，后端只需要提供API文档即可。

这样的产品，推荐做成Web端渲染框架开发的单页应用，或者使用node.js做成直出模板渲染式的。如果项目业务比较多，可以考虑部署前端微服务。

后端主导开发

后端主导的产品团队，一般上不会有单独的前端开发组，都是一个团队配一到两个前端来配合后端开发。此时作为前端，你就不需要有太多自己的想法，一切从简即可。比如使用前端预处理器Sass时，可能就需要慎重一些。同时也不要标新立异，使用这个团队没有用过的前端框架，跟随原来的技术栈走即可。

这时候你可能就会比较痛苦，一方面要维护前任写的乱七八糟的代码，一方面又不能用自己擅长的技术。作者就“有幸”做过这样的产品。当时后端的要求是API接口映射名称不能写死到代码里，前端要做成可配置式的；后端不愿意修改返回的JSON，我不得不一层层来解析像无底洞一样深的JSON数据。这种情况下，与团队积极沟通是一方面，另一方面是找准自己的定位来使用技术。这样才是一个好的程序员的基本修养，毕竟这个程序你不可能自己一个人拿出去卖不是。

3. 从面向用户群来考虑选型

前端产品面向的用户群体不同，展现的形式会有差异，现代互联网开发对于同一个用户群又分为PC端和移动端产品两种。主要分类有如下几种：外部用户PC端. 外部用户移动端. 内部用户PC端. 内部用户移动端；同时国内外用户的使用习惯也会有细微的差别。

外部用户PC端

对于外部用户，视觉体验是第一位的，PC端上SSR也是很有必要的。你可能需要一个比较完善的框架，支持SSR配置和UI动画库，而且要调研清楚是否要支持IE用户（甚至是IE8），JQuery(或Zepto.js) 有时也是比较管用的。

外部用户移动端

1. 移动端访问的页面

即用手机浏览器访问Web页面。页面切换还都是传统链接跳转，属于传统Web页面，前后端分离开发，页面直出渲染，与PC端的架构基本一致，只是要做一些适配工作。

2. 移动端Native应用

这部分产品目前来说对于前端开发用的技术栈比较多的是React Native，作者就曾经做过APP里的广告页和活动详情页面。如果你的产品有Native化的要求，那么整个产品技术栈首选React，毕竟要和React Native兼容。

内部系统用户

1. PC访问的页面

内部用户使用的管理系统。诸如OA. 项目管理系统等。这些需求比较通用，可以使用快速开发的架构，你甚至都不需要使用公司内部的组件库，开源的框架 + UI库 + 图表库完全可以满足要求。

2. 移动端访问的页面

企业内部使用的移动端产品，大多依附于企业微信等APP。就拿企业微信举例，工作台开放有API，支持二次开发。这样的内嵌H5页面也多为单页应用，单独部署并配置微信相关验证即可。

海外用户

针对海外用户，配置PWA或者AMP应该会成为架构选择的一个必选项。目前三大框架也都普遍支持PWA。

4. 从产品预期的效果来考虑选型

短生命周期

短生命周期的产品通常要求快速起步：门槛低. 书写自由. 不强制遵循任何最佳实践，使用过后就废弃。这时候就需要使用简单的. 不过度封装的架构，不使用eslint和Typescript。甚至不需要安排code review，因为不考虑后期维护。

长期产品

对于长期产品，后期维护是比较重要的。要选择具有完整生态的架构，能够平稳升级，采用模块化封装业务组件，不用硬编码，控制单文件代码行数等。同一个产品线上的产品过多，比如阿里云的架构，上微服务也是必要的。

探索性产品

探索型产品往往也是短周期产品，是需要比较激进的探索新的前沿技术。如果成功了，可能会过渡到长周期产品上去。这中间需要架构师做好可移植的能力。

5. 比较通用的建议

框架选择

React OR Vue OR Angular ?

简单介绍：

Vue上手难度最低，学好了不容易，2.0往3.0迁移也不是无创的，逐渐开始对TS支持，但不是天然支持，需要你在配置一下下。
React性能很好，但同时也比较难学，版本更新的很快，新版本的Hooks很多人不能适应。与复杂对应的是他的灵活性，生态也做得很好，同时也支持TS。
Angular天然支持TS，内置Rxjs，可嵌入. 注入和自带单元测试。使用过Java的同学应该会比较容易接受。目前在国内使用率比较低。

作者的建议是，用你团队常用的！这是最主要的，我之前的公司是从最早的前端MVC架构演进来的，保留了大量Angular 1.x的项目，那升级自然是往 2.x 迁移（虽然完全是两个框架，但并不完全是! 🐶；此外，你的团队对于之前使用的框架有着大量的技术积淀，封装了大量的工具库. 图表库来支持这个框架，贸然切换架构可能需要重复造轮子，增加学习成本，除非你的客户指明要你用！

依赖升级的平滑度

项目在框架升级的时候，你的package.json里的依赖应能够平滑升级，你在引用依赖之前，要先看其主页上描述的支持的框架版本，并且要清楚其将来会不会支持新版本的框架。对于一些工具型的依赖都还好说，但是有些依赖，比如moment.js哪一天说其不支持React18了（开个玩笑），你的重构成本就会很高。

作者给的建议是，小型项目用成熟的开源UI库和工具库没有关系，将来重构的成本还能接受，况且将来也不太会涉及到主版本的频繁更新。如果是长期维护的重要项目，建议主要的依赖，比如UI库等最好使用公司内部的，这样在框架升级的时候，UI可以同步跟着升级就好，而不用看第三方库的脸色了。

TS or JS

团队没用过TS，就不要贸然用，一直用TS的话就一定要用。快速项目用JS，大型项目用TS。

UI/图表库选择

有能力就团队自己开发，差一点的就对开源库，比如UI库像antd. elementUI. MaterialUI等，图表库如D3.js. Apache ECharts. g2plot进行二次封装后使用。

作者常用的技术栈

下面是作者常用的技术栈，经过公司反复打磨过的，有一定的参考价值，但也不要盲目相信。

Angular9+ + ng-zorro (或者自建组件库) + lodash-es + echarts + jsplumb.
React17+ + antd/Material UI（或者自建组件库） + 自建API Service库 + 公司自建微服务架构 + moment.js + Typescript + webpack，状态管理使用mobx.
Vue2 + Vuex + elementUI + echarts + axios.
类库使用 rollup

6. 结论

没有最好的架构选择，只有适合自己的。也不要盲目相信别人的经验，还是要基于自己的产品和团队进行调研后，按照实事来制定策略。

欢迎评论交流！如果发现有不足的地方，希望各位大神不吝赐教！