【Node 连载 6/9】探索面向未来标准的 Node.js Web 框架
第 64 届早早聊大会将于 2023 年 5 月 7 日（周日）举办 - 团队管理｜选用育留 人事双修，5 位讲师下午直播，关键词：小团队/管人管钱/管优先级/团队建设/女性领导力。跟早早聊一起，学习团队管理，上车链接：www.zaozao.run/conf/c64
本文是 2021 年 12 月 26 日，第三十五届 - 前端早早聊【前端搞 Node.js】专场，来自阿里集团 淘系技术部 - Node.js 架构组 —— 繁易的分享。感谢 AI 的发展，借助 GPT 的能力，最近我们终于可以非常高效地将各位讲师的精彩分享文本化后，分享给大家。（完整版含演示请看录播视频和 PPT）：www.zaozao.run/video/c35
正文如下
大家好，我是来自大淘宝技术 Node.js 架构组的繁易。今天我要给大家分享的主题是《探索面向未来标准的Node.js Web框架》。
我目前在阿里巴巴技术的大淘宝前端技术部门的 Node.js 架构组担任前端技术专家一职。工作主要集中在 Node.js 、Serverless 和 Web 框架等三个领域。下面这三个 logo 分别代表了我最近的一些工作以及我在开源社区上的贡献。作为阿里巴巴 Midway 团队的核心成员，我主要负责 Midway.js 框架的开发、维护和设计。同时，在社区中，我还是 Node.js 的核心创作者，主要负责 Node.js 相关 pr 的审查、issue 的修复和 bug 修复等工作。最近，我还加入了 TC39，并负责一些阿里巴巴的提案，以上就是我的个人简介。
众所周知，Node.js 自 2009 年发布以来，已经有十多年的时间了。在这期间，各种 Web 框架层出不穷。在我们淘宝技术团队中，我们早早就开始了前后端以及 Node.js 框架等一系列相关的探索和工作。在这里，我想与大家分享一下我们最近一段时间的思考和进展。
今天我将分为以下三个部分来进行分享。
选用育留，人事双修。欢迎报名第 64 届早早聊大会，跟早早聊一起，学习团队管理，上车戳：www.zaozao.run/conf/c64
Node.js & Web 框架简述
由于 Node.js 的出现，前端工程师首次有了跳出浏览器、用 JavaScript 做更多事情。
目前，Node.js 可以用于很多不同的任务，包括编写 CLI、处理数据、编写 Restful API、页面渲染等等一系列工作。可以说，Node.js 的出现使得前端工程师的领域发生了拓展，越来越广泛，也催生了大前端的概念。
Web 框架
在 Node.js 中，一个常常不可或缺的概念就是 Web 框架。现代 Web 开发离不开 Web 框架，因为在现代 Web 开发场景中，无论你使用 Java、PHP、JavaScript 还是其他任何语言，基本上都无法避免使用 Web 框架。
Web 框架可以帮助你高效地开发整个应用，包括 Restful API、数据库的 CRUD 操作、页面渲染以及身份验证等等功能。如果你要从头开始手动实现这些功能，将会非常繁琐，而 Web 框架则可以将这些功能内置或者通过生态系统提供，从而帮助你快速开发应用。
需要注意的是，Web 框架存在于特定的适用场景和规则约束中，它并不是万能的。每个框架都有自己适用的场景和规则约束，这也是为什么现在已经有了诸如 Java 企业级框架和 PHP 框架，而后来又出现了 JavaScript 框架的原因。
Web 框架的三个阶段
正是由于这个原因，在过去的 10 年里，Node.js Web 框架一直在不断地变革和进化，我个人自己对 Node.js 框架的进步区分了三个阶段。
起步阶段
我将第一个阶段称为起步期。因为从 2009 年 Node.js 发布至今，当时就已经存在了两个非常经典的框架，分别是 Express 和 Koa，分别在 2010 年和 2013 年发布。
这个阶段的特点是，Node.js 刚刚起步，很少有人会将其用于特别大规模的生产环境，更多的是用于验证 Node.js在 Web 场景中的可行性。这个阶段的框架主打轻量和极简。
以 Express 和 Koa 为例，可以看到这两个框架都有一个简单的演示示例。
关于这个演示示例，大家可以很容易地理解，只需引入一个模块，然后写几行代码，就可以启动一个服务器。因此，这些框架非常简洁且易于学习。
另外，由于它们是 Node.js Web 框架生态系统中的底层框架，它们具有丰富的周边生态，因此也很容易集成到其他上层框架中，而不是重新编写一个 Node.js 框架。例如在 Nest 和 Webpack 中，选择了 Express 作为底层框架；在 Egg 和 Midway 中，可能选择了 Koa 作为底层框架。这实际上是一种明智的做法。
当然，如果你要直接使用这些框架，它们也存在一些缺陷。这些框架专注于提供一个小而简洁、小而清晰的框架，也被称为裸框架。因此，它们并不适用于团队协作或者提供规范和最佳实践等大规模开发场景。
同时，Express 框架实际上已经停滞不前很长一段时间了，最新版本停留在 4.17.1，已经有两三年没有更新了。因此，尽管 Express 在起步期具有显著的优势，但也存在明显的缺陷。
企业 & 架构阶段
随着前端技术的发展，从 2014 年到 2017 年左右，可以看作是一个企业级和架构级的阶段。
在这个阶段，发布的主要是一些企业级的框架，例如 Midway、Egg 和 Nest，它们都注重企业级的功能。在这个阶段，经过前几年的尝试和实践，包括 Node.js 内部版本的稳定等多种原因，Node.js 终于开始在企业内部进行规模化的应用落地工作。
在这个阶段，一些专业的 Node.js 工程师也出现了，他们主要致力于将 Node.js 应用部署到生产环境中，可能会面临传统后端应用和各种问题，因此提出了企业级框架的概念，并包括了一些架构上的规约，其主要目标是使Node.js 的 Web 应用能够实现规模化、团队协作，并能够在企业级生产环境中运行。
这个阶段的企业级框架非常有趣，因为像 Nest、Egg 和 Midway 这些框架的基础都是建立在其他相关的基础框架如 Express、Koa 等之上，而不是从零开始构建新的底层框架。这样做一方面可以获得性能上的优势，另一方面也可以获得生态稳定性等方面的优势。这些企业级框架有很多自己的优点，例如它们可能是大而全的，规范明确，并且社区生态也非常活跃。
但是企业级框架的优点也同时伴随着缺点，即虽然它们大而全，但也可能过于复杂。在日常工作中，我们会发现很多工作并不是专业级别的 API 等，而是一些页面接口的聚合、页面渲染等工作。因此，过于庞大的企业级框架反而可能导致上手成本较高，并限制了扩展性。由于采用了企业级框架，并在其中固定了一套范式之后，导致任何不符合该范式的方案都很难被接纳。
面向前端阶段
进入第三个阶段，这个阶段我简单地称之为面向前端。
实际上，在 2016 年之后，我们会发现近年来涌现了许多全栈的前端框架，或者一些支持 API 的前端框架，包括Next.js、React、Remix 等。在这个阶段，企业会发现 Node.js 在整个企业内部已经趋于成熟和完善，因为 Node.js 在过去的多年里取得了很大的发展，许多相关功能也已经相对稳定。
近年来，由于整个行业的繁荣，包括互联网的发展，前端工程师的数量也急剧增加。因此现在很多时候，如果我们想要开发一个项目，不再需要编写非常专业的 API 接口，可能只需要渲染一个页面，需要做 SSR，或者从数据库中获取一些数据，这时面向前端的框架就应运而生，包括主打简洁和轻量。
以全栈框架为例，我举了两个最经典的例子，NEXT 基于 React 框架的，而 NUXT 是基于 VUE 框架的。这两个框架都面向前端的全端开发，并且非常简单易用。
可以看到，这些框架通过请求和响应来传递数据，前端可以直接读取到返回的数据。同时，由于这些框架的结构简单，部署到多个环境，包括支持 Serverless 部署等一系列功能也非常容易。
当然，这种简单的设计也存在一些缺陷。例如，在功能较为简单的情况下，后端功能相对较弱。例如，在 Nest.js 这样的框架中，处理用户身份校验、后台任务、队列等复杂功能会比较困难，并且在社区中可能存在许多问题和限制。此外，自定义拓展也较为困难，因为这些框架与前端框架强耦合，意味着要实现一些拓展功能需要前端框架的支持，并且还需要依赖于平台的支持。
总体而言，虽然这些小而轻的框架在某些方面简化了开发流程，但也存在一些限制和困难。但从总体趋势来看，我们认为这种小而轻的框架可能代表了未来一段时间 Node.js 框架的发展方向。
Web 框架满意度调研
关于这一点，我们可以参考一份来自于 2020 年 JavaScript 状态报告的调查数据。
该报告评估了 Node.js Web 框架的用户满意度。从整个框架的满意度排行榜可以看出，排名第一的是 Next.js，排名第二的是 Express。这意味着在 2020 年，也就是刚刚过去的一年中，用户对于 Node.js 的满意度最高的并不是企业级框架，而可能是一些小而轻的框架。
这也反映了当前的趋势，即在现今的视角下，可能并不是所有的前端开发人员都需要使用企业级框架来交付复杂的应用。更多的情况下，开发人员可能只需要使用简单的 API 来交付一个简单的应用。因此，我们认为小而轻的框架可能会成为未来的一个趋势。
总结
在经过前面三个阶段的描述后，我们可以简单总结一下 Node.js Web 框架的演变与前端行业的发展密切相关。这包括了 Node.js 自身的成熟度、前端从业人数、用户需求以及全端框架的发展等方面，都在一个紧密相关的过程中发展着。
同时，时至今日的 2021 年，前端应用场景实际上远远超过了纯粹的 Node.js 后端应用场景，这一点应该不难理解。因为作为全端工程师，日常工作主要是开发前端应用，而在一个公司中，全员从事 Node.js 后端应用的情况实际上非常罕见。
其次，我们可以观察到面向前端设计的全栈框架正在兴起，而 Node.js 的用法也在回归简洁和轻量。无论是从之前的 Next.js，还是近期的 Remix、React Server Components 等一些相关功能，我们都可以看到这种全栈框架在不断地推陈出新。
女性领导力不可小觑！欢迎报名第 64 届早早聊大会 - 前端搞管理，一起学习团队管理，上车戳：www.zaozao.run/conf/c64
Midway - 面向前端的框架演进之路
接下来介绍第二部分，在这一部分中，我将着重介绍 Midway 框架是什么以及我们内部对于框架的设计和开发方向。
Midway 框架起源于 2014 年，并且是阿里内部官方的一个 Node.js 框架。至今 Midway 框架已经发布了 7 个大版本，并在 2018 年正式对外开源发布。在 2018 年对外发布时，主打的也是企业级应用场景。
企业级起步
当时，我们推出了三个主要的特性，第一个是 TypeScript，第二个是 IoC，第三个是 Egg。
第一个特性是 TypeScript，这部分比较容易理解，它是一种静态类型语言，适合多人协作开发。在我们发布 Midway 框架之前，阿里内部很多后端工作，或者说绝大部分 Node.js 后端工作都是使用 JavaScript 语言进行的。因此，我们决定改变这种情况，开始在内部的框架中强制推行 TypeScript，一方面通过静态类型减少错误，一方面也希望可以降低多人协作的成本。
第二个特性是 IoC，这实际上是一个在业界非常成熟的架构解决方案，也叫做面向接口编程、依赖控制、反转等相关概念。具体的用法类似于右边这样的类，你可以将其提供为一个服务供外部使用，也可以在其他地方注入这个服务，并且还可以使用装饰器来简化很多的工作。
第三个特性是 Egg。在 2016 年，阿里内部达成共识，以 Egg 作为基础框架进行开发，演进了我们自己的框架 Midway。目的是不希望制造不必要的轮子，也不希望不必要地分裂。我们希望能直接复用 Egg 的生态系统，从而减少大家的上手成本和开发成本，不必刻意地去搞一些分裂相关的工作。因此，在2018年，我们按照 TypeScript 加入 Egg 的思路，将我们的 Midway 框架开源。
统计
2019 年我们对阿里的 Node.js 应用进行了统计。
阿里集团总共有 1600 个 Node.js 应用，但它们的 CPU 利用率非常低，很多应用的 CPU 利用率甚至小于 10%，甚至小于 5%。我还见过一些应用，上了生产环境后，做页面渲染服务，CPU 利用率常年低于 1%，这非常夸张。在整个过程中，前端维护面临一个问题，因为我们内部要部署一个 Node.js 应用，实际上需要掌握很多关于 Docker 的知识，需要学会使用 Docker 相关的工具，需要学会构建镜像，需要了解我们的发布平台，了解进程限流、日志、跨语言调用、RPC 等各种知识。
这导致了两个问题，一方面前端很难上手，或者上手后觉得很难维护；另一方面集团中存在很多应用，但整个应用占用大量计算资源，却看不到明显的成果。因此，我们得出的结论是，传统应用的缺点限制了 Node.js 在阿里的进一步发展。
当时，我们正在制定一个关于大中台和小前台的战略，而后端正在处理很多大后台的事情。与此同时，前端同事希望能够像外部的一些全栈框架一样，快速地将中台服务组装成各种接口，并快速响应业务需求的变化，而不是每天维护前端和各种复杂的东西。
Serverless
随后的故事大家也都知道了，在 2019 年，阿里经济体的全量委员会提出了四大技术方向之一就是 Serverless，这个概念在当时首次提出，并且我们已经坚持了两三年。简单来说，我们希望通过 Serverless 来解决前端难以维护的问题，要注意，不是解决开发是否好的问题。
在这个基础上，我们面临了新的一些挑战。如果我们能够解决维护的问题，那么我们希望框架要做出什么改变？是不是应该更加轻量化，更符合时代的潮流，更能够被广泛使用？
三个挑战
当时我们面临了以下三个挑战：
挑战1：用户群体的割裂。
这一点非常明显，因为在阿里内部，我们有几千名前端工程师和专门负责 Node.js 的工程师，形成了两个派别。前端工程师偶尔会写接口，当然希望能够简单易上手，通过 Serverless 来减少维护的工作负担。
而负责 Node.js 的工程师专注于全职进行 Node.js 开发，为众多用户提供服务。在这种情况下，我们遇到的问题是如何在一个框架下同时为两种类型的用户提供良好的服务。作为一个Node.js 架构团队，我们希望我们的框架不仅可以帮助复杂应用的 Node.js 工程师解决他们的架构问题，同时也希望全体工程师可以使用一些简单易上手的小工具。
挑战2：使用场景不同。
例如，在我做一个 Node.js 应用时，起初可能是一个简单的场景，只是一个 CRUD 接口聚合的中台服务。但是随着用户增加、需求增加、代码变更和人员变更，我可能会演变成一个复杂的场景。简单来说，我之前可能只需写 1000 行代码就完成了，但现在可能有 10 个人、20 个人，我可能需要写几万行代码，这就是一个企业级场景。在这种场景下，我更注重项目的可维护性、依赖注入、整洁架构、单元测试覆盖率等各种问题。
对于我们整个框架的设计者来说，我们需要考虑这两种情况，即如何支持简单场景和复杂场景的需求。我们需要思考如何将简单场景演化为复杂场景。
挑战3：前端范式的变更。
因为大家可能已经注意到，在 18 年到 19 年的过程中，前端框架都在朝着将函数和 Hooks 相结合的编程范式发展，这实际上给我们带来了另一个挑战。
因为我们可以看到，在 2018 年时我们编写的 demo 实际上是基于 OOP 的开发范式。但是在前端，我使用的是纯函数加 Hooks 的编程范式。在这种情况下，同一个开发者在前后端的思维方式是不同的，这实际上是一件非常痛苦的事情，因为开发者都是同一个人，但我们在前端和后端的思维方式不同，这会导致非常大的割裂，我需要来回切换，需要适应是前端还是后端？
这种情况下会给我们带来一个新的问题，那就是框架是否可能支持函数式开发并与 OOP 并存？这实际上是我们认为需要思考的另一个问题。
解法
基于这个问题，我们的团队在 2019 年开始进行了探索，实际上探索了整整一年多的时间，我们提出了一个全新的关于框架的架构，也是我们的一个设计，我们称之为渐进式设计。
在渐进式设计中，我们将整个 Midway 框架拆分成了以下几层。第一层是 Midway 核心，这一层可以看作是做一些基础服务以及一些相关的工具。然后第二部分是我们的编码范式，在原来的 Decreator 这一层范式下，我们新增了一个范式叫 Hooks，面向函数式编程。然后再往上，我们的工作其实主要集中在生态系统方面，包括与相关组件如任务、缓存、Mongo、Logger、ORM、Swagger 等进行集成，以及支持多平台的工具链和第三方模板。
我们还提供了一些定制的解决方案，针对不同场景的需求，比如面向 API 接口、定时任务、消息队列、WebSocket 等。在这些基础之上，我们提出了一个现代 Web 的概念，即 Midway 的一体化应用。这个一体化应用是基于我们的 Hooks 编程范式进行开发的。
接下来，我将向大家介绍我们是如何通过 Hooks 来解决之前所面临的三个挑战的。
函数即接口
首先，我们提倡的是函数式接口，这与传统的 IoC 和装饰器方式有所不同。
在这一点上，我们倡导的是一种统一且无协议的 JavaScript 函数即接口的概念。就像左侧这段代码一样，这被视为我们所认可的接口概念。我可以向大家展示如何将这个函数转变成接口信息。
简单来说，JavaScript 中的函数元信息其实是非常丰富的，包括函数名和函数参数等，这些信息可以用于描述接口。例如，在编译时，我们可以知道函数的文件地址和函数名，这种情况下我们可以将函数名用于拼接 API 路径。同时，函数可能有参数，我们可以根据参数的长度来决定是 GET 还是 POST 方法，并且参数的结构也可以参考 RPC 框架的设计。
同时，函数还有一个返回类型，例如这里的类型是 User，可以理解为可以通过测试查询来推断出这个类型。通过这些元信息，我会发现可以基于函数元信息来生成接口，而且这些生成的信息足够完整。你可以将这个框架生成的信息用于生成 HTTP 接口，也可以生成 RPC 接口，因为你有函数名，可以生成各种不同的调用方式。总之，基于函数元信息生成接口是完全足够的。
获取请求上下文
关于函数式编程的创新，我们引入了第二点，叫做 Hooks。这部分是展示如何获取用户上下文的一种方法。
在这里，我们参考了 React Hooks 的语法，从中获得了灵感。与其他框架不同的是，我们的 CTS 参数不再通过参数传递，而是通过一个 useContext 的 API 进行传递。例如，在这里你可以看到，我通过 useContext 获取了当前的请求上下文，包括请求查询参数，也可以通过自定义的 Hooks 获取 request、request 头 以及 context 下的 URL 等信息。通过这种方式，我们的函数式编程不仅写法更像函数，而且与 React 保持一致。另外，这种方式还可以让你无需手动传递参数，与前端的写法保持一致。
面向全栈应用设计
同时，整个 Hooks 的应用设计并不像传统的 Node.js 应用一样，它更面向 API 接口设计，我们在新的方案中完全面向全栈应用进行设计。
在我们的代码目录中，包括前端和后端的代码都放在了 src 目录下，只是我们有一个名为 cloud 的目录，这可能是一些服务端的代码，然后有一个 function 目录，这是一个接口目录，其中可能包含了一些页面和资源，这些都可以作为完整应用的入口。
此外，整个依赖和配置也是统一的。因为在之前，我们倡导的 BFF 全栈应用中，要么是分为两个不相关的仓库，要么是在同一个仓库中，但是两者的依赖和配置都是分开的。但在我们的 Hooks 中，我们面向全端应用提供了一种新的模式，希望能够统一这些依赖和工程配置。同时，因为它们都在 src下面，这意味着我们可以共享它们的 src/代码/类型，这为 Hooks 带来了更多的想象空间。
简化接口调用
简化接口调用与传统的 API 调用方式不同，传统的 API 调用在开发应用时需要知道接口的地址、入参、参数类型以及返回值等相关信息。而在这里，我们实现了整个过程的简化，将其称为 “零” API 调用。
在这种方式下，调用接口可以分为两步。
- 第一步，从后端的一个目录中导入一个后端函数。
- 第二步，通过调用这个函数并使用其返回值来获取整个接口的返回值。
可以看到，我们抹平了之前后端接口调用过程中的中间层。这种做法有很多优点。首先，之前使用纯函数的开发方式实现了这种可能性，因为不需要传递非用户的参数，并且全栈架构保证了可以统一依赖，共享 src。简化接口调用可以节约大量的工作量。因此，这是我们提出的一种新的编程范式，称之为 Hooks。其目标是让您以函数式的方式、贴近前端的方式来开发接口，同时又能节约整个开发过程中的工作量。
渐进式
关于渐进式，我们提出了一个自己的设想，像搭积木一样逐步演进。
在这个方案中，我们将整个 Midway 框架的功能能力进行了拆分，将其分成了独立的部分。例如，项目类型、开发方式、拓展组件、触发器和部署平台等功能都可以单独使用，或者组合在一起使用，以应对不同的项目需求。
举个例子，如果我要开发一个前端一体化的应用，我可能会采用函数式的开发方式，使用一个拓展组件，并将其发布成 HTTP 触发器，然后部署在 Serverless 上。这种情况下，我可以为前端工程师提供一个专门为前端服务的应用，他们可以快速开发，同时无需关心与运维相关的工作。这是第一种场景。
第二种情况可能是我要开发一个复杂的后端应用，这是一个纯接口项目。在这种情况下，我会采用传统的「IoC + 装饰器」的开发方式，同时使用多个拓展组件，可能还会使用像 gRPC 这样的微服务技术，然后将应用部署在自己的服务器上。这是涉及到企业级复杂应用所需要的一些功能能力。
第三种情况是随着时间的推移，一个应用的复杂度可能会增加。一开始可能是一个简单的一体化应用，部署在FaaS 上。但后来可能会引入一些「IoC + 装饰器」等功能，也可能引入 WebSocket 等技术，这种情况下可能会将应用部署在自己的 Web 服务器上，用于实现保活或异地多活的机制，以确保项目的稳定性。有时候通过这种架构的组合，可以解决不同场景下不断增加的复杂度应用需求。
这是我们整个项目落地的情况，因为我们的 Hooks 方案在去年的 4 月份已经发布，并且目前已经有超过 2500 个应用在内部使用，也是阿里目前前端开发的主流模式之一。
落地情况
包括阿里内部中后台应用开发，不再倡导传统的纯页面类型应用，而是倡导开发纯前端的 Serverless 应用，因为这样做有很多优势。当你不需要后端能力时，应用可以像普通应用一样只部署在 CDN 上。但如果你需要增加一些API 相关的工作，包括简单的 CRUD 操作，你只需要在我们的目录中添加几个文件，编写一些 API，并进行接口调用，就能实现一个包含前端和后端的一体化应用发布，这是一种渐进式架构的升级。这也是为什么目前很多开发者喜欢使用这种模式来开发他们自己的应用的原因。
总结
- 框架设计时需要考虑简单场景和复杂场景，以满足各种需求。Node.js Web 框架应该注重开发者体验，以前端为导向进行设计。
- 开发者体验很重要，因为随着 Serverless 的普及，后续运维工作会变得越来越轻。
- 未来的主流研发模式将是云 + 端的模式，通过使用这些能力，你的应用可以成为一个一体化的应用，可以部署到平台上，并提供 API。
欢迎报名第 64 届早早聊大会 - 前端搞管理，与早早聊一起学习小团队管理新思路，上车戳：www.zaozao.run/conf/c64
未来 - 面向标准 & 规划
接下来的第三部分，我将详细介绍我们未来的规划和我们在面向标准方面的一些工作。
类型安全
其中一个关键点是我们未来规划中的一个重要功能，即类型安全。
其实就涉及到了 Prisma 的使用。Prisma 实际上是一个专注于数据工作的库或框架。通过编写一段 schema，我们可以生成一个 TypeScript 的客户端。由于这个客户端是通过 TypeScript 自动生成的，它拥有完整的 TypeScript 信息，并且可以实时同步 schema，以确保客户端始终是最新的。
这样做的好处有很多，因为在之前，我们通常将前端和后端放在同一个项目中，将前后端连接在一起。在这种情况下，实际上相当于将后端和数据库连接在一起，从而实现了类型安全的方案。所谓类型安全，简而言之，就是当数据库字段或后端字段发生变更时，由于前后端都是通过类型连接在一起的，因此在 TypeScript 编译层面上就能知道所有的错误。
例如，如果数据库字段发生变更，后端会知道有问题，前端在某些操作中，如对数字进行加减操作时可能会出现问题，这种情况下错误可能会直接被检测到。这就是我们未来可能会倡导的一种方向，即实现从前端到后端再到数据库的全链路类型安全化。
云端融合
云端融合，这是目前 TC39 正在推动的一个提案，叫做 JS module Blocks，右边是它的衍生提案，叫做 JS Module Fragments。
两边提案实际上相似，简单来说就是可以在同一个文件中编写多个小模块，并通过动态引入或静态引入的方式进行导入。对于像右边这种动态引入方式，我认为目前很多框架需要这种功能，例如像 Next.js、React Server Components 这些前端后端写在一起的框架，或者需要前后端一起编写或者有相关导出约定的框架，这种范式非常适用。基于这一点，我们也提出了自己的想法，即向右边这种方式，这是我们可能在未来要实施的方向。简单来说，我可以导出多个模块，这些模块可能有不同的命名，包括可能叫做 server，表示用于服务端的接口，或者可以叫做 client，表示专门用于客户端使用的接口。
整个方案的方向，我们目前正在与前端委员会的标准化小组推进 TC39 提案，我也在他们的仓库中提了一个 issue，提供了我们自己的反馈，目前正在与他们的同事进行对接。这个目前还不是最终方案，只是我们在过程中的设想，未来可能会有变更，我们也欢迎大家踊跃参与。
欢迎报名第 64 届早早聊大会 - 前端搞管理，学习小团队管理，上车戳：www.zaozao.run/conf/c64
最后
接下来是最后一部分，我要推荐一本书。这本书其实是我个人会推荐的，叫做《Just for Fun》。它是 Linux 之父林纳斯的一部自传。
大家可能都知道林纳斯开发了很多 Linux 系统，开发了 Git，以及其他许多著名的软件。我当时看这本自传也是因为对他很崇拜，所以去读了这本书。在这本书中，你会发现他的一些想法还挺有趣的。他说他编程只是为了好玩，只是为了开发一个让自己满意的工具。为了让这个工具变得更协作，他开发了 Git，开发了 Linux，还开发了一些相关的内核，合作了很多工作。这本书其实没有太多道理，但我觉得大家可以有兴趣的话可以看看他的经历，了解他的想法。反正我觉得编程是一件挺有意思的事情，所以我和他的想法一样，只是为了好玩，就足够了。
接下来这句话其实是我个人的座右铭 - 就是让 Node.js Web开发变得更简单和有趣。这也是我在做企业级应用、企业级框架时的一个选择方向。因为在企业级应用中有很多不同的方向和方式，但我刚才希望把它简化，让初级工程师更容易上手，更好地使用，并且更专注于用户体验的优化。
对于工作 3 ~ 8 年的开发者，大概率都会走上管理。如果你感觉编程如鱼得水，管理举步维艰，欢迎报名第 64 届早早聊大会 - 团队管理，跟早早聊一起，了解真实的团队管理中可能遇到选用育留和管人理事的问题，以及破局之法。
- 举办时间：2023 年 5 月 7 日 13:00 ~ 18:00
- 截至时间：2023 年 5 月 7 日 19:00
- 举办方式：微信群 PPT 推送 + 线上视频实时直播 + 会后资料推送
- 报名方式：www.zaozao.run/conf/c64
- 大会主办方：前端早早聊
