在 Vue 3 中，我们通过将大部分的全局 API 和内部帮助器转移到 ES 模块导出中来实现了这一点。这使得现代捆绑器能够静态分析模块的依赖性，并丢弃与未使用的导出相关的代码。模板编译器还生成了树状的友好代码，只有在模板中实际使用某个功能的时候才会导入帮助器。
框架中的一些部分永远不能被树形动摇，因为它们对于任何类型的 app 都是必不可少的。我们把这些必不可少的部分的衡量标准称为基线大小。Vue 3 的基线大小约为 10KB 左右，尽管增加了许多新功能，但它的基线大小还不到 Vue 2 的一半。
解决规模化的需求我们还希望提高 Vue 的处理大规模应用的能力。我们最初的 Vue 设计的重点是低准入门槛和温和的学习曲线。但随着 Vue 的应用越来越广泛，我们更多的了解到了包含数百个模块的项目的需求，并且由几十个开发人员长期维护的项目。对于这些类型的项目来说，像 TypeScript 这样的类型系统和干净利落地组织可重用代码的能力是至关重要的，而 Vue 2 在这些方面的支持并不理想。
在设计 Vue 3 的早期阶段，我们试图通过提供对使用类编写组件的内置支持来改进 TypeScript 的集成。我们所面临的挑战是，我们需要的许多语言特性，如类字段和装饰符等，在正式成为 JavaScript 的一部分之前，仍然是建议--而且可能会发生变化。所涉及的复杂性和不确定性让我们怀疑增加类 API 是否真的合理，因为它除了稍微好一点的 TypeScript 集成之外，并没有提供其他任何东西。
我们决定研究其他方式来攻击缩放问题。受 React Hooks 的启发，我们想到了暴露出底层的反应性和组件生命周期 API，以实现一种更自由的方式来编写组件逻辑，称为 Composition API。与其通过指定一长串选项来定义一个组件，Composition API 允许用户像写函数一样自由地表达、编译和重用有状态的组件逻辑，同时提供了出色的 TypeScript 支持。
我们对这个想法非常兴奋。虽然 Composition API 是为了解决特定类别的问题而设计的，但在技术上，只有在编写组件时才可以使用它。在提案的第一稿中，我们有点超前了，并暗示我们可能会在未来的版本中用 Composition API 替换现有的 Options API。这导致了社区成员的巨大反击，这给我们上了宝贵的一课，让我们明白了如何清晰地传达长期计划和意图，以及了解用户的需求。在听取了社区成员的反馈后，我们对提案进行了彻底的修改，明确了 Composition API 将是对 Options API 的补充和补充。修改后的提案得到了更多的好评，并收到了很多建设性的建议。
寻求平衡开发者简介的多样性与用例的多样性相对应。
在 Vue 的用户群中，超过 100 万的开发者中，有只懂 HTML/CSS 的初学者，也有从 jQuery 迁移过来的专业人士，有从其他框架迁移过来的老手，有寻找前端解决方案的后端工程师，也有处理规模化软件的软件架构师。开发者配置文件的多样性与用例的多样性相对应。一些开发人员可能希望在传统的应用程序上洒上交互性，而另一些开发人员可能是一次性的项目，周转速度快，但维护问题有限；架构师可能需要处理大型的、多年期的项目，并且在项目的生命周期内，开发人员的团队起伏不定。
Vue 的设计一直在不断地塑造和了解这些需求，在各种权衡中寻求平衡。Vue 的口号是 "渐进式框架"，这句话概括了这个过程中产生的分层 API 设计。初学者可以通过 CDN 脚本、基于 HTML 的模板和直观的 Options API 享受平稳的学习曲线，而专家可以通过全功能的 CLI、渲染函数和 Composition API 来处理雄心勃勃的用例。
为了实现我们的愿景，还有很多工作要做--最重要的是，更新支持库、文档和工具以确保顺利迁移。我们将在未来的几个月里努力工作，我们迫不及待地想看看社区将用 Vue 3 创造出什么。