​虽然接触推荐算法是2009年，第一次组建人工智能团队却在2014年底。在经历了应用发行、广告、信息流和浏览器等业务，看到人工智能给业务带来的巨大价值，因参与其中而被彻底征服。那时起我就坚定认为，人工智能是继计算机以来最强大的力量，将会从每个角落彻底改变世界。 从32k猫和网页三剑客开始，一直热爱着前端，看着人工智能时代到来，萌发了帮助前端进入人工智能领域的愿望。2018年4月在前端委员会的共创会上，提出“前端智能化”方向。设计和规划直到推动这个方向落地，已经一年多。我在实践中发现，对前端智能化不理解、不会做，是阻碍前端工程师参与其中的最大障碍。 不理解主要是因为缺乏前端智能化的定义，大家不懂我在说什么、做什么，很多听过我分享的朋友都强烈要求我给大家提供一些学习建议和资料。曾尝试写过一些文档，但总觉得无法简单把前端智能化讲清楚，有必要把自己的实践经验和思考总结都梳理一下，供大家参考。

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

    Rax 天生就是一个跨容器的解决方案，这让我们不必单独了解 iOS 和 安卓背后做了什么，让我们的开发变得很省心。但真实情况是我们的业务往往同时跑在 web 和 native 两端，web 我们轻车熟路是前端天生的优势，native 对很多人来说就会有些陌生，native 上出现的各种问题用 web 的路子去解释往往会解释不通。据 2017 年底粗略统计 Rax 的用户 70% 是前端同学，本文面向前端，简单介绍一下 Rax 背后的 native 端在做的一些事情。本文吸取了大量前人的经验，对于过深的 native 概念进行了剔除，以求前端同学更好理解，如果想更深入了解的同学可以参考下面附件内容。

    引子上一次社区中谈论起 Web Components 已经可以追溯到三四年前了，彼时 Web Components 仍处于不稳定的草案阶段，Polymer 的出世使大家似乎看到了新一代的前端技术，但直到今天，在今年五月 Google I/O 发布 Polymer 3 之后， Web Components 的规模化应用才看似成为了可能。 过去一段时间，我一直在使用 Web Components 构建淘宝小程序的 基础组件 Atag。MDN 上对 Web Components 这个名词的解释是：Web Components是一套不同的技术，允许您创建可重用的定制元素（它们的功能封装在您的代码之外）并且在您的web应用中使用它们。 我们从中提取几个关键字：可重用 定制元素 封装 这些特性刚好能满足可复用组件的需求，更重要的是，这是由 W3C 标准提供的。

    说到 Node.js 的进程模型，脑子里第一个闪现的可能是 Cluster 模块，亦或是 Master / Worker 进程模型，在长期的使用过程中，我们逐渐发现，这样在应用的开发早晚会有局限性，除了不够优雅之外，每次增减进程或者自定义进程都会产生不可预知的问题。 在一些特定的场景下，我们甚至在 Master 下面加入了一个 Agent 进程用来运行一些中间件 SDK 。在这些修修补补的过程中，传统的进程间通信，数据交换都变的困难，甚至 Worker 到 Agent 之间通信都无法很优雅的进行。 除了一些内存共享的通信场景， 也出现了 Worker 进程跑一些定时任务占用时间过长，导致 Web 接口超时等问题（或者系统容量降低）。更有甚者，把定时任务放到 Agent 中去执行，直接拖挂了基础的中间件服务，导致应用全盘崩溃。

    Rax 提供的长列表标签有很多，在什么场景下使用什么列表组件，怎样选择列表组件性能会更好，这些问题可能会给刚接触 Rax 的同学带来困扰。本文结合 Rax 0.5 发布版本对列表能力进行一次详细的梳理。 如何让页面滚动在开始正题之前先说说为什么要有长列表的概念，以及如何让页面可以滚动。 传统的 Web 页面天生在浏览器里就是可以滚动的，我们额外引入一个滚动容器的概念好像比较多余。但当我们做跨容器开发时，这一层概念就变的有意义。native 的页面天生不可滚动，需要借助滚动容器的滚动能力，比如 iOS 中的 UITableView、Android 中的 RecyclerView，通过组件的方式让页面的部分内容可以滚动。