2020年末：浅谈阿里前端的多样化

本文主要是介绍2020年末：浅谈阿里前端的多样化，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

2007年，Jeff Atwood 提出了一个著名的观点, 戏谑又似认真地称其为 Atwood's Law（https://blog.codinghorror.com/the-principle-of-least-power/）：any application that can be written in JavaScript, will eventually be written in JavaScript.

时间快速穿行13年到今天，仿佛在印证戏言成真：在互联网软件工业的疆域上，以ECMAScript 为圆点朝各个方向射出一箭，凡目力所及的范围内，皆似洒落上了这一箭之威。

而在阿里，也像在诠释着这些上述断言，前端技术如初生牛犊般从蛮荒时代的PC Web 踏入到多个领域，在许多重要战场中发挥着重要作用。

本文，简单分享几个前端领域在阿里的应用场景，附带一些我对前端技术领域的一些思考，期待能够和众多的行业同仁们有交流互动的机会。

从 Web 互动到媒体互动

在早期，Web上的互动是为提升页面氛围作为附庸而存在的，为此有一个专用词“网页特效”作为代称。

曾经很长一段时间，互联网上存在大量的特效代码库、特效网站专门服务于开发者。而这些特效的基础原理就是通过 Javascript来变换样式和操作DOM实现的。

随着标准组织和浏览器厂商的不断努力，现代化互动的基础开始成型。除了硬件性能提升外，HTML5/CSS3，Canvas、WebGL让互动的开发显得更为标准、更高效可行，而非各种原理古怪、性能堪忧的Hack技巧。这也让在Web上实现大型互动成为可能性 - 可是要知道，曾几何时，Flash几乎是“双十一狂欢城” 唯一的选择。

今天，互动产品及对应的互动前端技术早已成为各大互联网公司的标配：

在技术上：继承了Web的优势，能够调整迭代，无需发版，天生跨端的同时还能兼具不错的性能。
在商业形态上：更游戏化的互动包括不限于“蚂蚁森林”、“淘宝人生”、“天猫农场”等类社交游戏产品使“人与人”、“人与平台”之间的互动具备了更好的可玩性、用户黏性，从而具备了更高的商业价值。

2020年，互动技术也成为阿里经济体前端技术的重点发力方向。

以淘系互动技术为例，它构建在一个大型、完备的前端基座上：一体化的工程、构建、容器、框架、发布系统、渲染引擎。
互动前端技术的核心简单地大概分为三部份：

（互动）框架：基于游戏领域的通用构架，自底到顶的分层实现-Render/Render OBJ/Design Pattern/Utils，具备加载器、ECS、场景、插件化扩展等基础能力。
（互动）素材中心：接收并处理互动展示层所需要的资源并输出成型的互动素材，并通过SaaS化服务进行管理。
（互动）研发平台：面向互动生产者的工作平台，它具备包括不限于编码、拼装、编排在内的构建能力。

基于这套互动技术体系，冷冰冰的商业化产品开始具备了越来越多的趣味性和创意体验。

当互联网基础设施不断完善，硬件与带宽成本持续降低，直播/短视频逐渐形成获取用户时间的主流产品形态，也成为人&人、人&机互动的新场景。

传统的解决方案是在视频媒体上“遮盖”一层Web页面，内嵌在页面中的互动（如领取红包）和视频内容没有事实上的关联，而是通过预置的逻辑进行触发，“伪装”成视频与互动同步的用户体感。这种方式成本低廉，但代价则是牺牲了创意和灵活性，缺少想像空间，没有未来。

而媒体智能互动则是更合理的解决方案：通过智能化手段进行手势、表情等识别，互动素材与效果均与视频内容强关联，并在视频流上完成素材渲染。

从实时渲染角度来看，核心技术环节在：图像采集、数据处理、算法识别、渲染计算、端渲染展示

从研发生产角度来看，关键流程在：玩法生产、应用管理、玩法使用、端渲染展示

上述每个节点都涉及到各个关联技术及工具/产品，正是这些能力组成了媒体智能的技术体系。

从长远来看，无论在互动的自身形态、输入方式、承载媒介还是玩法创意，都必将有长足地发展，对于前端体系的从业人员，只要持续关注用户&终端、熟悉业务、不断学习必定会获得长足的技术竞争力和创造力！

搭建，不止于提效

过去几年，我在负责面向消费者端的搭建体系：把形形色色、千奇百怪的页面都看作组件们的集合，然后用极致简单的搭积木方式将它进行可视化组装。

如果拿冰山举例，我们尽量让用户们（运营、开发者）只看到露出海面的那一段，把概念和实操尽一切可能地简化，而被屏蔽在冰山下面的东西，包括了一系列的交付

高度被抽象的界面+数据描述标准，我们称之为模块；

兼顾性能和灵活性的客户端+服务端渲染架构；

离线的、简洁的零代码可视化平台；

提供线上服务的页面渲染引擎 + 数据网关;

有了这些交付物（以及基于它构建的大型生态），前端、设计师、后端（多数时候甚至不需要）围绕着高度可被复用的产品模块即可进行页面组装，将业务发布上线。这个方案简单又高效。以至于在很长时间，这套构架最终产生成了数以百万计的各种页面，其中包括不限于双十一，我们在阿里系各种App看到的很多页面都是基于这样的方案出来的。

然而这并不是终点。

其实道理也很简单：当效率上达到一定临界点后（通常是边际效应开始递减），对应的技术方案都越界碰触到另一个领域。

搭建技术也一样 - 一个业务的运行通常不是搭建一个页面就完成了 - 它涉及到整个业务的执行周期。好比一个线下商场要做一场年货活动，上架商品这个任务只是工作中的一部份，其他包括不限于选商家、选货品、制造氛围、顾客动线都是必须得完成的工作。

而线上业务的运行亦如此，除了“搭建页面” 这个看似简单的动作外，还有各种上下游环节，包括不限于 - 数据哪来（选品）、以什么规则展示（算法千人千面）、抵达什么用户（人群规则）、界面是怎样的（新式交互）、在哪儿展示（跨端渲染）、浏览体验是否又快又好（性能&质量）、业务效果如何（数据看板）等等，每个环节都或多或少地关联着前端相关技术。

基于此，我们根据业务的实际需要拓展了系统的功能边界。慢慢地，原本的面向效率、被高度抽象化的工具系统成为了一个解决具象业务的产品。

在这个转变过程中，原本核心工作是完成前台页面的前端程序员，逐渐成为了一个面向业务的技术工程师，而其工作职责从原来的高效交付扩大到了方方面面，技术视野、技术能力都得到了很大的提升。这时，我们也很难单纯用技术栈来界定这位程序员是前端抑或是后端工程师。

相信在未来，这样的前端工程师会越来越多，也会成为前端发展的一个方向。

技术栈从来不是技术人的桎梏！

Serverless，孕育新的生产关系

还是得谈谈这个话题，如果说越发完善的研发工程体系在提升交付整备质量、周全的性能故障监控系统在改进交付效果，那么 Serverless 就是在尝试着在最合适的环节来优化生产关系。

想必很多初入 CRUD 阶段的前端同学都尝试写过一个形如 Todo、blog-like等应用，基于广受各类教程推荐的 Express/Koa+MongoDB+ReactJS/VueJS 套件方案实现。

然而写完应用后的踌躇满志在遇到技术面试/业务应用时则一片茫然：怎么和预想的不一样？ - 性能调试、高可用、容量规划、多应用调用、数据库优化、跨栈中间件等等都是未曾太多考虑的问题，但若稍加深入思考，无需很久就进入新一阶段的灵魂拷问：为什么我要使用Node而不是其他工业化程度更高的语言技术栈？

而云原生下的Serverless 让多数前端们开始解除束缚：