从推荐算法到前端委员会，一位深耕技术多年的实践者，在2018年提出了“前端智能化”方向。这篇讲的是作者对这一概念的系统性思考，旨在为困惑的同行厘清概念、指明路径。 文章的核心观点很明确：前端智能并非要求前端工程师成为算法专家，而是要用工程化思维，在前端技术生态内高效地落地和整合成熟的AI能力。它旨在降低AI的应用成本，让最懂用户和交互的前端开发者，能真正驱动业务智能化升级。 作者首先厘清了概念，指出前端智能关注的是“问题定义-模型选择-工程集成-业务验证”的闭环。随后，他将前端智能化比作Node.js之后技术土壤上长出的“新物种”——它不仅拓展了前端的应用边界，更从根本上变革了“用户-端-服务”的技术链路：模型将直接在端侧参与理解用户与场景。 文章也直面了当前的挑战：移动端极度复杂的时空场景、人脸/手势等新型交互带来的技术栈不兼容，以及追求极致个性化与研发成本之间的矛盾。这些分析指明了前端技术下一步升级必须解决的核心问题，为从业者描绘了一幅清晰的演进路线图。
这篇讲的是阿里前端团队如何跳出传统 Web 开发的范畴，在互动体验、业务搭建乃至 Serverless 等多个领域发挥关键作用。作者从有趣的 Atwood 定律（所有应用最终都会用 JavaScript 编写）出发，结合阿里内部的实践，展示了前端技术的边界如何被不断拓宽。 文章以“双十一”等大型活动为例，详细介绍了前端如何驱动从“网页特效”到大型游戏化互动产品的演变，并构建了一套集框架、素材中心和研发平台于一体的互动技术体系。同样，在低代码搭建领域，前端工作也从单纯页面交付，演变为贯穿选品、算法、跨端渲染等完整业务链条的产品工程。 更深入的变革来自 Serverless。它让前端工程师得以摆脱运维和底层架构的束缚，有机会转型为离业务更近的“产品工程师”，从而重新定义前后端的协作边界。作者认为，这种角色演变正是前端多样化发展的必然方向。文章最后借 Reg Braithwaite 的箴言提醒我们：技术的强大在于无所不能，而挑战在于如何明智地选择与运用。
这篇文章面向前端开发者，讲清楚了 Rax 在 native 端到底是什么，以及它和 React Native、Weex 这两个常见框架的核心区别。作者从“Rax = RN 语法 + Weex 能力”这个公式切入，指出 Rax 吸收了 React Native “一次学习”的开发体验，同时依托 Weex 实现了“一次编写，多端运行”的跨端目标。 文章重点拆解了 Weex 这个“幕后工作者”的运作机制。它详细解释了 Weex 从 DSL 代码到原生渲染的流程，包括 JS Framework 如何作为 JS 与 Native 通信的桥梁，以及 Weex 的 virtual-DOM 如何在简化传统 DOM 后高效控制原生视图。这些讲解剥离了复杂的客户端概念，专为前端同学理解而设计。 对于想上手的开发者，文章特别点明了 Weex 与 Web 的“天生不同”：布局上只有 Flexbox，样式不支持继承和许多 CSS 特效，单位处理也存在差异。这些细节直接关系到日常编码的取舍，比如为什么不能随意用 float 或 absolute 定位。 总之，这篇文章帮前端同学快速扫清了 Rax 背后的 native 知识盲区，理解框架的设计权衡，能更顺畅地处理跨端开发中遇到的差异问题。
这篇讲的是作者基于在淘宝小程序基础组件 Atag 中的实践，总结了 Web Components 的开发经验与避坑指南。文章从 Web Components 的核心优势切入——它由 W3C 标准驱动，具备可重用、封装性好且无框架“传染性”的特点，因此非常适合用于开发底层基础组件。 作者详细分享了几个关键的实战要点。在基础设施方面，强调了 polyfill 库 `webcomponentsjs` 和 Polymer 3 的选型与使用建议。在构建配置上，他点出了一个经典陷阱：Babel 将 ES6 class 转译为 ES5 时会导致自定义元素注册失败，并提供了解决方案。兼容性分析显示，在移动端通过 polyfill 可覆盖绝大多数用户。 文章还提供了直接的性能对比数据。在渲染 1 万个组件的场景下，原生 Web Components 的表现显著优于 React，而 Polymer 在注册阶段虽略有开销，但其开发便利性带来的整体收益依然很高。这些基于具体数据和踩坑经验的总结，对于考虑使用 Web Components 构建可复用组件的开发者来说，有很强的参考价值。
这篇讲的是 Node.js 进程管理长期存在的痛点，以及团队如何通过开发 Pandora.js 来提供一个更优雅的解决方案。 文章从传统 Cluster 或 Master/Worker 模型在实际应用中的局限性说起：增减进程困难、进程间通信复杂、定时任务可能拖垮主服务，更深层的问题是进程模型与框架绑定过深，限制了 Node.js 应用的扩展性（比如难以同时处理 Web 和 RPC 服务）。为了解决这些“修修补补”带来的窘境，团队推出了 Pandora.js。 其核心思路是引入一个名为 `procfile.js` 的进程结构定义文件，通过简单的代码（如 `pandora.fork('processA', './app.js')`）来声明进程，而将底层的创建、通信和伸缩交由框架自动处理。例如，通过 `scale(5)` 这样的属性就能自动完成 Cluster 模式的进程扩展，开发者无需关心具体实现。除了管理进程，Pandora.js 还提供了守护、日志切割、监控指标采集等一整套能力，为构建更健壮、可观测的 Node.js 应用打下了基础。 文章最后提到，这只是介绍 Pandora.js 的开始，后续还将分享其在监控、追踪和可视化 Dashboard 等方面的实践。
这篇讲的是Rax框架下长列表组件的选型与实战指南。面对scrollview、recyclerview、listview、waterfall等多个列表组件，新手往往不知如何选择。作者结合Rax 0.5版本，对这些组件的特性、适用场景与性能差异进行了清晰梳理：例如水平滚动推荐scrollview，但要注意内容过多时的性能瓶颈；追求高性能的垂直长列表则应首选recyclerview。 文章不止于理论对比，更深入讲解了关键组件的实用技巧。比如，针对recyclerview中因列表数据更新导致onEndReached失效的问题，提供了使用`resetScroll`方法重置状态的解决方案。同时，它也剖析了下拉刷新（RefreshControl的放置位置）、appear事件（在滚动容器内绑定并注意性能影响）以及onScroll动画（推荐使用BindingX降低通信成本）等基础能力的实现要点。 最后，文章展示了多种典型的页面组织模式——从简单的全屏滚动、部分固定区域布局，到复杂的模块吸顶和横滑切换多页面，均给出了具体的代码结构参考。对于需要在Web与Native端实现一致滚动体验的开发者而言，这篇教程提供了从组件选择到场景落地的系统性思路。
