• 技术采用生命周期
• 技术方向

在2019 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，这两项技术对于前后端的架构设计都会带来深远的影响。

2019年下半年展望

中后台的重塑针对中后台业务特点，缺乏详尽的交互设计，缺乏足够的前端资源，页面样式相对统一，业界提出通过少量代码或者无代码方式搭建中后台前端系统。目前有的一些最佳实践：Fusion Design，飞冰，Ant Design Pro。大家都是从几个方向去实现中后台前端系统的无代码化，Ant Design Pro基于Ant Design提供了一整套中后台的网站框架和页面模板，对于快速搭建很有帮助。Fusion Design和飞冰是通过打通设计和编码环节，直接从sketch文档导出相应的页面代码，也是极大的释放了前端同学码页面的工作量。

Flutter跨平台解决方案
Flutter作为一个跨多端(iOS，Android，PC，Embedded)，具有美观、快速、高效、开放的特点，目前在闲鱼、贝壳、阿里等公司都有落地场景，作为下一代跨平台解决方案我们可以持续关注，它具有一个非常宏大的野心，背靠Google大厂，能够从系统底层开始抹平各端差异，具有一个强大的技术架构来支持，长期来看还是挺值得期待的。

阿里前端委员会四大技术方向
以下内容摘抄自圆心的分享文稿

1. 搭建服务：可以看到整个搭建服务无论是在中后台还是整个无线端，以及 PC 端都有大量场景，这样大量场景需要把整个框架标准化，希望把里面的元件、组件以及模块标准化，还希望把这样的服务能够服务于今天所有无论是中后台也好，C 端页面也好，希望有这样的体系——服务化标准化的方式服务，打通整个体系，这就是为什么把搭建服务认为是面向未来最重要的方向。
2. Serverless：可以让前端更加贴近业务，可以让更多能力下沉。前端转到 Node 体系有一个很大的挑战，但是到了 Serverless 我们可以不用关注部署，不用关注运维，不需要关注所有的 DevOps，也不需要关注底层数据库的状态，他会让我们前后端整个的体系像前后端分层一样又往前迈一步。
3. 智能化：因为在 AI 来临的时候，我们能否从一个 Design 变成一个 Code？今天每个公司的前端都有大量的设计、大量原代码，我们通过大量设计稿和原代码进行机器学习，让中间的布局可学习，让中间的元件可学习，我相信未来 D2C 一定能够解决前端生产力瓶颈，让前端从今天大量低端开发、手工工作中解放出来，将精力转移到很多领域深度的参与、深度的突破。
4. IDE：今天阿里的前端我们做了叫工程中台，工程中台做到了前端代码从提交到发布的管控，当然包括中间提交之后整个代码的编译、构建、检测以及发布。但是在前台的部分，每个团队都有一个工具，而这个工具在各团队之间割裂的，无法复用。因为工程不仅仅是提交到发布，前端工程化应该从编码开始到发布，应该是一个完整的链路、完整的格局

前端技术栈标准化
前端发展到现在，整个技术栈依旧处于百花齐放的阶段，但是对于公司或者团队而言，需要逐步从草莽时代走向正规军时代，这就需要在技术栈标准化上做一些事情。例如对于一个10人左右的前端团队而言，如果还是三大前端框架并存，那么技术沉淀、代码复用都无从谈起。所以对于一个前端团队而言，标准化的技术栈是非常重要的，需要统一的脚手架、lint配置、mock工具、编程语言、框架、监控等等。

写在最后

大前端的技术非常繁杂，由于个人和团队精力有限，总是有不少遗漏还需要各位小伙伴们补充。对于各个技术所处的采用生命周期也限于个人的体验，总是难免有些争议，我只能尽可能做到相对合理。将各个技术放在不同的生命周期中，本意不是去贬低某项技术，其实恰恰相反，能够出现在Laggards周期往往说明这个技术得到岁月的洗礼，经过长时间的验证。只是一个时代总是有一个时代主流的技术，这个总结期望大家能够不断自省审视当前的技术栈，保持在业界主流对于未来项目维护、吸引人才都是很有帮助的。无论什么样的技术总会有过时的那一天，身为码农还是要持续不断学习，不要仅仅修炼术的方面停留在各种技术的使用之上，还要多多修炼道的方面，能够拨开技术的表面，看清它背后的原理以及解决问题的本质。