为什么Theo错了？以及我们将如何为JavaScript开发Laravel框架？
由 Mux 主办的 DEV 全球展示挑战赛：展示你的项目！
JavaScript 对全栈框架的需求
“为什么我们没有一个类似 Laravel 的 JavaScript 框架？”这是Theo 在他最新视频中提出的问题。
如果您不熟悉Laravel和Ruby on Rails等工具，它们是具有明确规范的全栈框架（分别适用于 PHP 和 Ruby），内置了许多遵循既定约定的功能，使开发人员能够编写更少的样板代码和更多的业务逻辑，同时将行业最佳实践融入到他们的应用程序中。
他认为，JavaScript不需要这样的框架，因为最好是选择自己想要的工具，自己构建所需的解决方案。
这听起来很棒——如果你是一位经验丰富的开发者，这也可以算是一个不错的炫耀——但我感觉他并没有很好地支持这个说法，所以我在这里告诉你我认为他错在哪里。
我认为更应该问的问题是：为什么我们还没有适用于 JavaScript 的 Laravel ？答案是：我们仍在开发中。
在他对可与 Laravel 或 Rails 相媲美的 JavaScript 全栈框架进行总结时，他忽略了一些重要方面：
- 人们真的很想要一个类似 Laravel/Rails 的 JavaScript 框架。如果不是这样，就不会有这么多人尝试开发，他也不会专门制作一个视频来回应“为什么 JavaScript 没有自己的 Laravel 框架！？ ”这个迫切的呼声。
- 他忽略了JS生态系统底层工具的成熟度和发展时机。或许并非不需要一个适用于JavaScript的Laravel框架，而是由于生态系统本身存在一些重大差异，例如发展历程和创新主要发生在哪里，导致目前还没有这样的框架。
- 他也忽略了这些解决方案适合哪些用户。当然，并非所有开发者的目标都相同，因此有些人可能会选择可组合的方法，而另一些人则更倾向于使用框架。
那么，让我们来看看我们是如何走到今天这一步的，以及我们如何才能将 Laravel 或 Rails 这样的全栈框架引入 JavaScript 的世界。
把事情做好
在视频中，Theo 指出“现在 React 界流传着这样一句谚语：‘如果你不用框架，你就得自己做一个’”。尽管这句话带有批评的意味，但 Theo 认为大多数 JavaScript 开发者都误解了它的含义，构建“自己的框架”实际上是一种优势。
他认为 JavaScript 生态系统的模块化特性是一个巨大的优势，但这听起来似乎给普通开发者带来了很大的压力，让他们做出不必要的判断并管理大量的样板代码。
当然，有些团队需要创新，以满足特殊用例的需求。这些团队会优先考虑模块化设计。他们会不断调整、改进，尽可能提升开发者体验 (DX) 和性能，以确保他们独特的工作顺利完成。
但另一方面，也有许多团队的主要目标是创造价值并专注于产品本身的创新，而不是开发工具。这些开发者更倾向于使用能够让他们专注于业务逻辑的框架。这为他们提供了一种稳定的方式来构建符合最佳实践的产品，从而能够轻松地从一个项目过渡到另一个项目。此外，还有那些精简高效的独立开发者，他们也在寻找能够帮助他们快速迭代并把创意推向市场的框架！
这有点像Mac和Linux的区别。Mac的统一操作系统开箱即用，因此许多专业人士更青睐它的高效性；而Linux则非常适合追求灵活性，并且有时间和知识根据自身需求进行定制的用户。两者都是有效的解决方案，可以共存以满足不同的需求。
这种对效率的重视正是 Rails 当年如此强大的原因，也是 Laravel 目前如此受人喜爱的原因。而众多尝试为 JavaScript 创建类似框架的案例也足以证明，很大一部分 JavaScript 开发者同样需要这样的解决方案。
但或许，此类框架至今尚未出现的原因并非开发者是否需要，而是因为构建此类框架所需的关键因素尚未完全到位。要使此类框架得到广泛应用，首先需要足够稳定的底层技术作为支撑。之后，它本身也需要时间以及多次迭代才能成熟，从而让开发者能够安心地使用它。
在 JavaScript 领域，这些因素是否已经汇聚到一起，从而催生出像 PHP 和 Ruby 那样的框架呢？或许还没有完全达到，但它们似乎正在慢慢融合。
生态系统比较
Theo 的主要观点之一是，JavaScript 语言具有 Ruby 和 PHP 等语言所不具备的模块化和可组合性，这就是为什么 Ruby 和 PHP 生态系统需要全栈框架来很好地服务，而 JavaScript 则不需要，因为你可以自己组合各种东西。
JavaScript 是一种很特别的语言，它既支持函数式编程范式又支持命令式编程范式，并且具有动态特性，但它也存在很多缺陷（尽管最近已经有了很大的改进），所以你通常不会听到它像 Theo 在这里所做的那样受到赞扬。事实上，你可能更常听到人们对 Ruby 及其模块化和灵活特性的赞扬。
如果 JavaScript 语言本身的一些独特属性不是它成为 Web 开发之王的原因，那又是什么呢？
答案很简单：JavaScript 是浏览器的语言。
很久以前，当大部分 Web 开发工作都在服务器端进行时，PHP、Java、Ruby 和其他语言占据了主导地位。在那个时代，开发人员只会用 JavaScript 编写一些小的功能模块，因为大部分工作都在服务器端完成。
但随着 Web 开发的发展，我们开始构建功能更丰富、更具动态性、响应式和实时性的应用程序，大量代码从服务器端转移到了客户端的 JavaScript，因为 JavaScript（基本上）是唯一支持这些功能的语言。因此，开发工作不再主要使用 PHP 或 Ruby，并辅以少量 JavaScript，而是将应用程序拆分为客户端大量的 JavaScript 代码和服务器端的 Ruby 或 PHP 代码。
JavaScript 的最终崛起源于 NodeJS 的出现以及服务器端开发能力的提升，这巩固了其作为 Web 开发语言之王的地位。如今，开发者可以（而且确实）用 JavaScript 编写整个应用程序。这意味着开发者无需掌握多种语言，同时还能在前端和后端之间共享代码。这为前端和后端之间的更好集成开辟了道路，并最终发展成为我们今天所熟知的生态系统。
因此，使 JavaScript 成为 Web 开发主导生态系统的，与其说是 JavaScript 语言本身的独特属性，不如说是它作为唯一一种既可以用于编写客户端代码，又可以用于服务器端的语言所拥有的独特垄断地位。
正如Theo所说，JavaScript生态系统中“有无数开发者在创造出色的解决方案”。没错。正是这些数量庞大的开发者为JavaScript创造了灵活性和模块化解决方案，而不是这种编程语言本身固有的特性。
而且由于 JavaScript 生态系统仍然是最热门的，它拥有最多的开发者，并且每天都在持续吸引新的开发者。这意味着我们拥有一个庞大而多元化的社区，他们主要从事两项工作：
- 创新
- 建筑
创新者（和意见领袖）往往声音最大，因此舆论大多偏向他们。但实际上，建设性的应用或“正常”的使用也在持续进行！只不过创新者倾向于代表建设者发声。
鉴于 JavaScript 生态系统中正在发生的一切，正如 Theo 所建议的那样，尝试为 JavaScript 开发人员构建一个持久的框架是否毫无意义？或者，无论创新者们如何声称，我们都在朝着实现这一目标的方向前进？
让我看看你正在用什么工具
Theo 还列举了一系列当前的 JavaScript 框架，这些框架要么未能成功，要么在成为全面的全栈解决方案方面“似乎总是做不好”。
他说的确实有道理。到目前为止，像Blitz、Redwood、Adonis或T3这样的解决方案，在各自的生态系统中还没有像 Rails 或 Laravel 那样获得广泛的认可。
但这些都需要时间。
请看上面的图表。Laravel 和 Rails 已经存在了 13 到 15 年！相比之下，其他 JavaScript 框架才刚刚起步，其中一些框架，例如Wasp和Redwood，其发展阶段与 Laravel 和 Rails 最初几年的发展阶段类似。
正如你所看到的，好的解决方案需要时间才能成熟。即使其中一些框架开始停滞不前，但它们最初的高速增长也证明了市场对这些工具的需求确实存在！
这些工具面临的主要问题是 JavaScript 生态系统发展迅速，因此，像这样的解决方案要想长期生存下去，不仅需要足够坚定，还需要足够模块化，以跟上生态系统的变化。
框架难以达到理想状态的一个因素是与错误的技术绑定过紧。例如，NextJS 与 BlitzJS 绑定过紧，GraphQL 与 Redwood 绑定过紧，Blaze 与 MeteorJS 绑定过紧。另一个因素是框架的规模不够大，因为在 JavaScript 生态系统中，这似乎是一项艰巨的任务。JavaScript 生态系统发展迅速，每个人都“害怕发表意见”，因为他们可能会遭到业内最强势者的批评。
换句话说，那些避免自身规模扩大，避免像 Ruby on Rails 和 Laravel 那样真正实现全栈开发的框架，错失了解决困扰 JavaScript 开发人员的最常见痛点的机会。
但是，JavaScript 生态系统正在走向成熟和稳定，我们正在从过去的尝试中吸取教训，将来会出现一个足够大胆的全栈框架，能够全力以赴，把足够多的事情做好，并坚持足够长的时间以确保自己的地位。
向黄蜂问好
在对当今市场上的 JavaScript 框架进行比较时，Theo 也没有提到我们目前正在开发的 React 和 NodeJS 全栈框架Wasp。
我们一直在努力将Wasp打造成真正的全栈框架，以满足 Web 开发人员的需求，填补 JavaScript 生态系统中的空白，成为他们喜欢使用的框架。
我们决定在 Wasp 框架上走一条全面、有主见且真正全栈的道路。换句话说，我们将全力以赴打造这个框架。
这意味着要从根本原理出发，设计一种只有 Wasp 才使用的新方法，例如为我们的配置语言构建我们自己的编译器，真正实现全栈开发，同时还要保持足够的模块化，以便随着生态系统的发展而共同进步。
这意味着我们在初期投入了更多时间尝试不同的方法并打好基础，最终在 2023 年底实现了使用量的显著增长。Wasp 现在发展势头强劲，而且速度非常快！
看到 Wasp 如今被用于交付大量新应用和业务，甚至被一些知名企业和组织内部使用，我们感到非常兴奋（更多相关信息将很快正式发布）！
Wasp 与其他 JavaScript 全栈框架的不同之处在于，它将主要的抽象层分离到自己的配置文件中main.wasp。该配置文件赋予 Wasp 处理大量样板式、以基础设施为中心的代码所需的知识，并使其拥有独特的初始编译时步骤，即在后台生成代码之前（在生成代码时使用该知识）能够推断您的 Web 应用程序。
实际上，这意味着您只需在 Wasp 的配置文件中对您的 Wasp 应用进行概括性的描述，然后使用您熟悉的 React、NodeJS 和 Prisma 等技术来实现其他所有功能。这也意味着 Wasp 具有很高的模块化潜力，我们正在将其构建为未来支持其他前端框架，例如 Vue、Solid 或 Svelte，甚至支持其他后端语言，例如 Python、Go 或 Rust。
如果你是那种希望 JavaScript 也能拥有 Rails 或 Laravel 的开发者，那么你应该试试 Wasp（然后加入我们的 Discord，告诉我们你的想法）！
我们将走向何方？
我们坚信，未来一定会有像 PHP 的 Laravel 和 Ruby 的 Ruby on Rails 那样的全栈 JavaScript 框架。
目前看来，我们似乎仍在朝着这个目标努力。鉴于 NextJS 和 T3 等当前元框架和技术栈的流行程度，我们很可能很快就能实现这个目标。
但这需要时间和耐心。
此外，你必须有足够的勇气去尝试新事物，因为你知道自己的作品会受到生态系统中一些最有影响力的人的批评。
这就是我们为此所做的准备，也是我们全力投入Wasp 项目的原因。
到时见！
