PHP：Laravel，Ruby：Rails，JavaScript：？

最近，JavaScript开发者与Laravel和Rails开发者在Twitter上展开了一场激烈的讨论。这场讨论始于Laravel作者Taylor Otwell发布的一条长推文：

简而言之，他认为整个 JavaScript 生态系统缺乏像 Laravel 或 Rails 那样真正的“全栈”框架，而这样的框架可以让单个开发者构建下一个 GitHub、Airbnb 或 Shopify。

我对此深有同感，因为我在构建基于 Prisma ORM 的 TypeScript 工具包ZenStack时，也秉持着同样的理念。事实上，我经常听到社区成员表达类似的看法：

即使在非JS用户群体中，也无法否认JS生态系统的流行度和快速增长。那么，这是为什么呢？

历史原因

人们创造自己的历史，但他们并非随心所欲地创造历史；他们并非在自己选择的条件下创造历史，而是在既定的、从过去传承下来的条件下创造历史——卡尔·马克思

PHP 和 Ruby 从一开始就被设计成服务器端语言。PHP 创建于 1994 年，用于构建动态网页，而 Ruby 出现于 20 世纪 90 年代中期，则被设计为通用编程语言。

鉴于 PHP 和 Ruby 的服务器端起源，它们天然适合构建能够处理 Web 开发各个方面的综合框架，从路由和控制器到数据库交互和模板引擎。这促成了 Laravel 和 Rails 等框架的诞生，为构建 Web 应用提供了一种完整且规范化的方法。

与此相反，JavaScript 最初是作为一种客户端脚本语言，用于网页浏览器。直到 2009 年 Node.js 的出现，它才开始涉足后端开发。如果你听说过 Netscape Navigator 和 Internet Explorer 之间的“浏览器大战”，你很可能了解前端领域持续不断的混乱局面，这种混乱至今仍在困扰着前端开发人员，而这一切都是为了实现浏览器兼容性。因此，早期的 Web 开发就是将各种不同的技术拼凑在一起。也正因如此，JavaScript 开发人员逐渐习惯了模块化，从而能够灵活地组合各种库和工具以求生存。这就是为什么与 Node.js 一同诞生的 NPM 发展迅猛，迅速成为世界上最大的软件注册中心。

这些不同的情况造就了不同的开发者文化：

• PHP/Ruby 开发者：  “给我一个开箱即用的框架。我想要规范的开发流程、稳定性以及清晰的发布路径。”
• JS开发者：  “别限制我！我想要灵活性、最新的工具以及按照自己的方式构建的自由，即使这意味着前期需要投入更多的工作。”

因此，即使扩展到后端领域，单一的、“一刀切”的方法在 JavaScript 生态系统中也很难行得通。

当代努力

一方面，这种文化推动了持续发展，使整个生态系统保持活力和创新。然而，它也导致决策疲劳加剧，新人的学习曲线也更加陡峭。

“哪里有泥泞，哪里就有金矿。”一些人踏上了一段充满冒险的旅程，致力于构建一个类似 Rails 的、内置电池的框架，以挑战现状。以下是一些热门示例：

• RedwoodJS

  这是一个集成了 React、GraphQL 和 Prisma 的全栈 JavaScript 框架。它通过统一的设置和自动代码生成简化了开发过程，非常适合可扩展的应用程序。

• Biltz.js

  Blitz.js 将 Next.js 扩展为一个全栈框架，它具有零 API 数据层和用于数据库访问的 Prisma。其目标是通过允许前端直接调用服务器端代码来简化开发。

• AdonisJS

  AdonisJS 是一个以 TypeScript 为核心的 Web 框架，用于构建 Web 应用和 API 服务器。它提供了一系列开箱即用的丰富功能，包括 ORM、身份验证和强大的 CLI，使其成为寻求全面且结构化开发环境的开发人员的理想选择。

它们会成为 JavaScript 界的 Laravel 或 Rails 吗？现在下结论可能还为时过早，但至少 RedwoodJS 展现出了强劲的发展势头：

还有一些人试图通过提供包含预设功能和预置工具包的“入门套件”来解决这个问题。其中最受欢迎的是Create-T3-App，它结合了 Next.js、tRPC、Tailwind CSS 和其他强大的工具，为构建类型安全的 Web 应用程序奠定了坚实的基础。

有趣的是，T3 的创建者 Theo 似乎对 JavaScript 世界的整个发展前景持悲观态度：

乐观的未来

任何可以用 JavaScript 编写的应用程序，最终都会用 JavaScript 编写。——杰夫·阿特伍德

虽然我并不完全认同阿特伍德定律，但我确实认为JavaScript在Web开发领域拥有光明的前景。原因很简单：

这是历史上第一次使用一种编程语言开发出整个网络应用程序。

这对新手开发者来说尤其有利。得益于 TypeScript 出色的类型推断系统，我们不仅能够做到这一点，而且也乐于这样做。

Laravel 或 Rails 用户经常批评这些框架缺乏一种常规的方法来对系统中不同实体之间的关系进行建模，例如：

虽然它可能还没有达到 Laravel 或 Rails 的水平，但目前 JavaScript 领域的努力已经意识到了这个问题。如果你查看上面提到的解决方案工具包，你会发现一个共同的名字：Prisma。

如果你还没听说过 Prisma，它是一款现代化的、以 TypeScript 为先的 ORM，能够让你轻松管理数据库模式，灵活地进行查询和修改，并确保出色的类型安全。这使得 JavaScript 开发者能够获得类似 Laravel 和 Rails 那样强大的数据处理能力和关系建模的便捷性，与 Laravel 的 Eloquent ORM 非常相似。

我基于 Prisma 构建的ZenStack工具包旨在进一步缩小后端与前端之间的差距。它在 schema 之上添加了一个授权层，并自动生成 API 和前端钩子。简而言之，完成 schema 后，后端就基本完成了。之后，您可以选择任何前端框架，例如 React、Vue 或 Svelte，来完成 UI 开发。

以终为始

JavaScript 会迎来像 Laravel/Rails 那样的“黄金时代”吗？我个人认为（或者至少希望），标准化的规范能够带来整个生态系统的全局优化。然而，考虑到 JavaScript 的历史和文化，实现这一点可能需要相当长的时间。人工智能究竟会加速这一进程，还是会彻底颠覆它，目前还不得而知。

所以，看来我们只能拭目以待了。不过，正如李·罗宾逊所说，我们不要迷失在这场争论中而忘记了最初的目的：

最后，我将引用W3C Web平台设计原则中的一段话：

用户需求优先于网页作者的需求，网页作者的需求优先于用户代理实现者的需求，用户代理实现者的需求优先于规范编写者的需求，规范编写者的需求优先于理论的纯粹性。