作者：前端你怎么看
一晃眼已过大半，年初信誓旦旦要学习新技能的小伙伴们立的flag都完成的怎样了？对于大前端技术领域而言变化不算太大，目前三大技术框架日趋成熟，短期内不大可能出现颠覆性的前端框架(内心OS：出了也学不动了)。
本文结合个人和团队经历对上半年做个技术总结，将各类技术框架/语言/工具分作两个维度：
技术采用生命周期
创新者（Innovators）：技术的冒险者，第一时间尝试新技术
早期采用者（Early Adopters）：技术早期采用者，具备一定探索精神，某个领域的意见领袖
早期大众（early majority）：技术早期大众使用者，深思熟虑者，往往采用相对成熟的技术
晚期大众（late majority）：技术的平民老百姓，跟随趋势采用当前主流的技术
落后者（laggards）：技术的落后者，长时间不更新技术栈，存在大量技术债
技术方向
按照大前端技术架构图进行分层，大体分为：状态管理、UI组件、小程序、跨平台、框架层、编程语言、工程化、监控、测试和服务端。
大前端技术总结如下：
状态管理
随着React、Vue这类前端框架的流行，组件化开发成为主流，然而随着页面复杂度越来越高，在一个组件文件中，要做UI渲染、事件处理、状态管理等等事情，于是一个文件变的越来越复杂。同时，页面组件层级变的复杂后，跨组件间的数据通信也变的很繁琐，需要将数据上提到父节点，通过property传输数据、回调方法更新父节点状态等等。
Facebook首先提出Flux框架，引入单向数据流的编程模式，把Action和Store从View中解耦出去，极大的优化了原有状态管理的架构。
Redux=Flux+Reducer，由于Store的唯一性加上Reducer纯函数，使得数据状态具有可预测性，于是配套出现了很多基于TimeMachine机制的调试工具，极大的提升了研发调试效率。不过由于Reducer的纯函数性质，对于一些异步请求的副作用又要引入中间件，导致了一定的复杂度。
Vuex作为Vue框架的状态管理的不二选择，核心思想和Flux/Redux一脉相承，弱化了Reducer的概念而改用Mutations，使得整套框架更易于理解了。
Mobx是一个非常轻量级的状态管理框架，引入了observable state、computed value，极大的简化了状态修改的方式，相对于Redux减少了不少模板代码，上手迅速使用友好，不过由于缺乏Redux这类的强制规范，需要在使用中进行必要约束。
dva是蚂蚁金服出品的数据状态管理框架，dva=React+Redux+Saga，通过约定大大简化了编程体验，值得持续关注。
状态管理不是每个前端应用都必须使用的，要结合自身业务复杂度来决定，只有业务逻辑有一定复杂度需要做到各个模块解耦才考虑采用，如果一个Todo都用上Redux，我怀疑你是在炫技~
UI组件
在前端三大框架还未一统江湖的时候，组件库百花争鸣有Dojo、Bootstrap、Extjs等等。自从React横空出世，组件化变成了前端开发的标准模式，同时也应运而生了两大UI组件库：基于React的Ant Design和基于Vue的ElementUI。
作为两大成熟UI组件库，如果你的系统是属于中后台业务，对于UI定制化要求不那么严格，那么这两个一定是不二选择，两者功能上没有太大区别，基础UI控件、多语言、主题配置等等要啥有啥，唯一的风险就是圣诞节给你来个下雪的彩蛋（政府网站高危预警）。
UI组件库可以持续关注Web Components，毕竟是Chrome浏览器亲生的，背后有Google这个老爹撑腰，而且现在React/Vue不也变的越来越像Web Components了吗？
另外前端数据可视化、3D化也是一个很好方向，一些酷炫的前端库小伙伴们可以撸起来了~
小程序
小程序百花齐放，各大超级App都推出了自己的小程序应用，前端同学们要支持众多小程序，摸摸头发又稀疏了不少吧（em...离资深研发又迈出了坚实的一步）。小程序的实现有多种方式，需要结合自身的业务场景来做选择。
选择一，小程序原生开发方式，以微信为主开发小程序，再通过少量修改移植到其他平台（工作量多少没有做过不好估计，但既然当初支付宝小程序demo都抄微信的，感觉应该不大吧~）
选择二，H5内嵌开发方式，天然多平台跨端，但会有些许性能损失，也会有些功能限制，例如微信里面的消息通知不能通过H5来推送
选择三，mpvue这类基于某种框架的开发方式，mpvue就是基于vue框架来开发小程序，对于熟悉vue的同学学习曲线很低，同时也可以实现代码逻辑的复用
选择四，Taro跨多端的实现方式，支持用 React 的开发方式编写一次代码，生成能运行在微信/百度/支付宝/字节跳动/ QQ 小程序、快应用、H5、React Native 等的应用。对于功能需要同时满足多个小程序应用的场景比较适合。
跨平台
锦涛在Qcon分享 - 美团移动端动态化实践中总结了业界和美团在移动端跨平台&动态化的实践，可以看到公司在跨平台&动态化方面进行了多维度的研究和投入，这样可以适用于不同的业务形态。
自从移动端有了iOS、Android两大平台，在加上原有的H5 Web端，跨平台就成了这几年大前端最热闹的地方，毕竟一个功能实现三套换谁都不乐意干，于是在用户体验和研发体验中的一场拉锯战就开始了，各大厂商各显神通。
最早出现的是Phonegap这类基于WebView的实现方式，由于WebView天然跨平台能力很好的解决了展示层的问题，然后通过jsBridge打通WebView和Native之间通信，使得浏览器中的H5代码也能有原生能力。这种方式研发体验最好，但是用户体验最差。
然后就是React Native、Weex、Picasso，它们基于Virtual Dom或者模板语言，通过js代码编写UI，然后渲染成原生组件，完美了实现了用户体验和研发体验的平衡。但要用好这些框架还是需要对性能优化、差异性抹平、工程化有比较高的要求，小团队小公司慎用，否则入坑容易出坑难。
今年大热是Flutter，可以持续关注，技术架构很优秀，野心很庞大，大有一统江湖的气势。
跨平台热热闹闹多年，我个人认为当前的解决方案都是折中方案，随着手机性能逐步优化、浏览器原生能力的增强，也许大家都会回归本源，走上H5这条道路。
框架层
上半年框架层没有太大变化，依旧三大前端框架把持：React，Vue，Angular。从团队使用情况来看，React、Vue依旧是主流，Angular似乎慢慢不那么受待见，也许太难学了吧(手动捂脸)
React 16.x上半年发布，推出了不少新特性，例如hooks、lazy、suspense等等，如果是React技术栈的同学鼓励第一时间进行尝试。hooks还需要再多多实践，整体实现理念和原有class方式有很大不同，习惯了原有的生命周期的写法的同学还需要适应。
Vue 3.x难产至今，根据路线图3.0会有大量的更新，比如virtual dom的重写、框架会更小更快、全面拥抱TypeScript、使用Proxy来实现检测机制等等。呼唤尤大大赶紧更新，vue的同学恨的牙痒痒的，下半年的KPI就指望这个啦~
Angular近期没有太多关注，不过Angular是一个真正意义的MVVM框架，不比React或者Vue其实都是View框架，所以这是一个大而全的框架。但是团队方面期望技术栈进行收敛，所以这方面就没有太多的投入了。
在框架层，可以持续关注PWA和WebAssembly，PWA对于弱网环境的用户体验提升很有帮助，而且还可以作为桌面应用的技术框架。WebAssembly可以让前端在高密度计算性能上得到很大提升，不过应用场景有限。
上面介绍了大前端关于状态管理、UI组件、小程序、跨平台和框架层的内容。下面会继续介绍编程语言、工程化、监控、测试和服务端，同时也会对下半年大前端可以关注的部分进行展望。
结合个人和团队经历对上半年做个技术总结，将各类技术框架/语言/工具分作两个维度：
技术采用生命周期
技术方向
在 stateofcss也有关于CSS特性使用情况的统计，每个特性的外圈代表听过过的数量，内圈表示真正使用过的数量。
其实CSS特性的使用覆盖面很大因素取决于浏览器的支持程度，浏览器支持越好越容易获得更高的使用率。可以看到几个高使用率的CSS特性在浏览器支持方面都非常好，除去Opera Mini和少量IE11，其他主流浏览器都能完美支持。
一个有趣的现象是在布局方面Flexbox使用率要高于Grid，可能的原因在于在低版本浏览器的支持方面Flexbox要更好，但其实在当前主流浏览器的支持度上已经没有区别。另一个因素可能是React Native也是推荐使用Flexbox来做布局，具有较大的群众基础吧。
CSS in JS 的理念应该来自React Native，最开始接触的时候相当颠覆，在JS文件中直接写相应的CSS定义，使得组件内聚化达到极致，解决了css全局污染的问题。在web前端，css in js有很多的实现方式，但目前来看还是比较早期，传统的Less、Sass的这类css预处理框架已经能够比较好的解决一些问题，从编程习惯上也一脉相承，因此css in js理念不错，但要得到推广还需要时间。
CSS Houdini 提出了一个前无古人的的设想：开放 CSS 的 API 给开发者，开发者可以通过这套接口自行扩展 CSS，并提供相应的工具允许开发者介入浏览器渲染引擎的样式和布局流程中。简单的说houdini可以让大家去写css 的polyfill从而极大的改善css新特性引入的速度。不过讽刺的是，它本身也需要浏览器支持，w3c标准还处于working draft，大多数浏览器都还没很好支持，大家可以期待一下～
工程化
提到工程化先拿腾讯直播团队分享过的一张图来镇楼，很多小伙伴会狭隘的认为工程化就是webpack或者gulp打包而已，其实这个应该涵盖从项目创建、开发、编译、打包、测试、发布、监控全流程。
项目初始化
项目脚手架目前已经非常普遍，例如create-react-app或者vue-cli都是官方标准的脚手架工具。对于一些稍大的公司都建议自己包装一套自己的脚手架，这样可以沉淀很多最佳实践，例如工程目录结构、lint配置、监控配置、打点配置等等，因此脚手架是落地前端架构标准化不可或缺的一环。
本地开发
lint 的规范一定要在项目初期就落地，可以直接拿airbnb的规范或者再定制化一下。lint可以极大的提升代码质量，至少从代码风格来看可以保证统一。
Sonar 的引入可以进一步提升代码质量，帮助分析出潜在的问题，同时分析代码的重复率，过长的高数等等，这些都是所谓的代码bad smell，如果任其发展下去，项目维护成本会直线上升。
Mock
工具的必要性在前后端联调时就能充分提现，很多时候由于前后端接口定义不清晰导致联调过程就是一个扯皮过程，如果缺乏mock工具，前端也会沦为后端接口调试的触发器，前端页面点一下，后端调试大半天，前端小伙伴们伤不起啊。Mock工具至少要有接口定义和本地mock的能力，能够极大提升大家研发体验。
打包
前端工程打包工具强烈推荐
webpack 4
，强大的插件能力能够让你做几乎任何事情。webpack4中引入了更为强大智能的code split能力，能够极大缩减包大小，经过实践通常减小幅度都在30%-50%，而且在打包速度上也有很大改进，通常也有30%的提升。
监控
当老板给你发一个线上问题的截屏，你本地又无法重现，又没有足够的日志，这时候是不是郁闷，和老板信任的小船说翻就翻了。
监控从能力来看分为几个阶段：
第一阶段：硬件运维能力，例如服务器运行情况，CPU、内存、磁盘、网络等等，在拓机情况下能够快速响应。
第二阶段：应用服务的监控，例如服务可用性、异常流量监控、页面接口的响应时间、App crash等等。
第三阶段：核心业务指标监控，例如业务核心链路数据同比环比的对比等等。
第四阶段：全链路的数据监控，从客户端、前端到服务层，到数据层，能够通过唯一id串联起来，可以方便回溯用户操作，重现问题现场。
很显然要做到监控这四个阶段需要做大量的基础设施，往往大厂都有一套完备的轮子。对于小团队而言，采用开源方案能够快速补全能力。
Cat 是美团开源的业界良心监控方案，对于前后端都有不错的监控能力，数据收集也很完备，能够提供实时的性能指标、健康状况、实时告警等数据，在多家互联网公司也得到实践，实属拯救码农头发的必备工具，你值得拥有～
umeng 作为移动端行为分析工具已经有非常广泛的使用，不过对于大厂而言用户数据非常关键，如果有能力还是建议自研，毕竟用户的行为数据是核心资产，将来可以基于这些数据做推荐、分析等等有价值的事情。
lighthouse/perf curve/perf budget 这些都是作为性能监控的工具，不仅仅可以得到线上环境真实数据，还能在开发阶段提前预警性能问题、落地性能优化的最佳实践，也是小伙伴们不可或缺的好伴侣～
测试
这里通常指的是自动化测试而非手工测试，从测试覆盖范围可以分为单元测试、UI测试、接口测试和功能自动化测试。我所经历的公司或团队，几乎没有能把自动化测试能够做好的，时间和需求频繁变更往往是最大的借口，不过程序员内心都不愿意写测试用例的吧（手动捂脸）。
从落地难易程度来看，接口测试和单元测试最好落地，接口不说了难度不高收益还不错，主要需要对数据准备有些要求。单元测试首推 Jest ，同时还能统计出覆盖率，但是单元测试要明确好可以测试的范围，一般业务逻辑和底层通用方法比较适合。所以业务逻辑代码从UI层代码抽离非常重要，这时候redux这类状态管理框架就有了天然优势了，里面reducer、action部分就可以单测覆盖。
UI的测试一般对于组件库有点帮助，简单的做法就是通过snapshot进行dom对比，简单粗暴。功能自动化很少能够落地，appium或者selenium都是其中翘楚，需要看业务情况，如果有频繁页面改动，一开始功能自动化写的爽，后续维护成本大的惊人，而且由于功能覆盖时间差，还是需要大量手动测试的。
服务端
自从出现Node之后，前端技术正式进入服务端开发，从而让前端的小伙伴们可以进行全栈的开发，技术栈的范畴变的更大，对于业务的把控能力也变强了。
Node可以带来几个明显的 好处
第一，可以作为BFF(Backend for Frontend)层，解决前后端接口频繁变更的问题，通过BFF层可以实现更加灵活的接口，接口字段的过滤，接口的聚合等等
第二，可以用做SSR(Server Side Render)，通过Node层同构直出，可以将前端渲染代码放在服务端，实现首屏的服务端渲染，提升首屏渲染时间
第三，基于“只要能用JS实现，最终都会用JS实现”定律，Node让前端同学可以用JS撸后端代码，这个掌控一切的感觉太爽了~
Node也存在一些 缺点
第一，需要额外的服务器，很多场景下Node层仅仅做接口透传的工作，对于服务器是一种浪费，而且作为一个核心节点如果一旦挂掉整个应用都不可用
第二，需要对Node服务有一整套的打包、部署、监控等能力，这个对于前端同学来说提出了较高的运维能力的要求，这些事情往往让前端同学苦不堪言
服务端最近可以持续关注GraphQL/Serverless，这两项技术对于前后端的架构设计都会带来深远的影响。
下半年展望
中后台的重塑
针对中后台业务特点，缺乏详尽的交互设计，缺乏足够的前端资源，页面样式相对统一，业界提出通过少量代码或者无代码方式搭建中后台前端系统。目前有的一些最佳实践：Fusion Design，飞冰，Ant Design Pro。大家都是从几个方向去实现中后台前端系统的无代码化，Ant Design Pro基于Ant Design提供了一整套中后台的网站框架和页面模板，对于快速搭建很有帮助。Fusion Design和飞冰是通过打通设计和编码环节，直接从sketch文档导出相应的页面代码，也是极大的释放了前端同学码页面的工作量。
Flutter跨平台解决方案
Flutter作为一个跨多端(iOS，Android，PC，Embedded)，具有
美观、快速、高效、开放
的特点，目前在闲鱼、贝壳、阿里等公司都有落地场景，作为下一代跨平台解决方案我们可以持续关注，它具有一个非常宏大的野心，背靠Google大厂，能够从系统底层开始抹平各端差异，具有一个强大的技术架构来支持，长期来看还是挺值得期待的。
阿里前端委员会四大技术方向
以下内容摘抄自圆心的分享文稿
搭建服务 ： 可以看到整个搭建服务无论是在中后台还是整个无线端，以及 PC 端都有大量场景，这样大量场景需要把整个框架标准化，希望把里面的元件、组件以及模块标准化，还希望把这样的服务能够服务于今天所有无论是中后台也好，C 端页面也好，希望有这样的体系——服务化标准化的方式服务，打通整个体系，这就是为什么把搭建服务认为是面向未来最重要的方向。
Serverless ： 可以让前端更加贴近业务，可以让更多能力下沉。 前端转到 Node 体系有一个很大的挑战，但是到了 Serverless 我们可以不用关注部署，不用关注运维，不需要关注所有的 DevOps，也不需要关注底层数据库的状态，他会让我们前后端整个的体系像前后端分层一样又往前迈一步。
智能化 ： 因为在 AI 来临的时候，我们能否从一个 Design 变成一个 Code？ 今天每个公司的前端都有大量的设计、大量原代码，我们通过大量设计稿和原代码进行机器学习，让中间的布局可学习，让中间的元件可学习，我相信未来 D2C 一定能够解决前端生产力瓶颈，让前端从今天大量低端开发、手工工作中解放出来，将精力转移到很多领域深度的参与、深度的突破。
IDE ： 今天阿里的前端我们做了叫工程中台，工程中台做到了前端代码从提交到发布的管控，当然包括中间提交之后整个代码的编译、构建、检测以及发布。 但是在前台的部分，每个团队都有一个工具，而这个工具在各团队之间割裂的，无法复用。 因为工程不仅仅是提交到发布，前端工程化应该从编码开始到发布，应该是一个完整的链路、完整的格局
前端技术栈标准化
前端发展到现在，整个技术栈依旧处于百花齐放的阶段，但是对于公司或者团队而言，需要逐步从草莽时代走向正规军时代，这就需要在技术栈标准化上做一些事情。例如对于一个10人左右的前端团队而言，如果还是三大前端框架并存，那么技术沉淀、代码复用都无从谈起。所以对于一个前端团队而言，标准化的技术栈是非常重要的，需要统一的脚手架、lint配置、mock工具、编程语言、框架、监控等等。
写在最后
大前端的技术非常繁杂，由于个人和团队精力有限，总是有不少遗漏还需要各位小伙伴们补充。对于各个技术所处的采用生命周期也限于个人的体验，总是难免有些争议，我只能尽可能做到相对合理。
将各个技术放在不同的生命周期中，本意不是去贬低某项技术，其实恰恰相反，能够出现在Laggards周期往往说明这个技术得到岁月的洗礼，经过长时间的验证。只是一个时代总是有一个时代主流的技术，这个总结期望大家能够不断自省审视当前的技术栈，保持在业界主流对于未来项目维护、吸引人才都是很有帮助的。
无论什么样的技术总会有过时的那一天，身为码农还是要持续不断学习，不要仅仅修炼术的方面停留在各种技术的使用之上，还要多多修炼道的方面，能够拨开技术的表面，看清它背后的原理以及解决问题的本质。
【End】
如果觉得《过半 前端所有流行必学技能总结》对你有帮助，请点赞、收藏，并留下你的观点哦！
