00:00:00我们迎来了一个新的 JavaScript 框架,
00:00:04一个全栈框架。但先别急着退出,
00:00:07听我说完。它其实相当有趣,
00:00:09因为它是由 Remix 团队开发的,
00:00:12也就是构建了 Remix JS 的 Ryan Florence 和 Michael Jackson。不,
00:00:22不是那个迈克尔·杰克逊。他们同时也是 React Router 的原始作者。他们分享了自己的愿景,
00:00:31以及全新 JavaScript 框架的首个原型和演示——Remix 第三版。所以这并不是一个全新的名字,
00:00:40而是沿用了现有的名称,
00:00:42但它确实是一个全新的框架。在这个视频中,
00:00:46我会尽力理清所有这些内容。我会解释它是什么,
00:00:50当然还有我对它的看法——我们是否真的需要另一个 JavaScript 框架,
00:00:57以及我认为它成功或被采用的可能性有多大。尤其是在这个大语言模型默认就能生成 React 应用的时代。但让我们一步步来,
00:01:08Remix 到底是什么?它为什么重要?
00:01:11Remix,
00:01:12如果你错过了这个消息,
00:01:14它本质上是一个 React 元框架,
00:01:17是 Next.js 的替代方案。Remix 在几年前就已经发布了,
00:01:23如果我没记错的话,
00:01:25Remix 第二版是在 2022 年发布的。然后在 2024 年,
00:01:30Remix 第二版基本上与 React Router 合并了。这就是为什么现在使用 React Router 时,
00:01:40你既可以像以前一样将它作为 React 应用中的路由库使用——这依然可行,
00:01:47它仍然是一个出色的库——但你也可以在框架模式下使用它,
00:01:52本质上是搭建一个全栈 React 应用。此时 React Router 不仅仅是一个路由器,
00:02:00它还能帮助处理数据获取、
00:02:02数据加载、
00:02:03数据变更,
00:02:04就像 Remix 一样,
00:02:06因为它就是合并到 React Router 中的 Remix。但这当然带来了一个问题:那么 Remix 这个品牌会怎么样?
00:02:17结果是,
00:02:18Remix 将在第三版中成为一个新框架。它将成为一个新框架,
00:02:23重要的是,
00:02:24它独立于 React。它不是一个 React 元框架,
00:02:29也不是另一个 Next.js 的替代品。相反,
00:02:33它是一个从头开始、
00:02:35从零编写的全新全栈 JavaScript 框架,
00:02:39具备 Ryan Florence 和 Michael Jackson 希望在新 JavaScript 框架中拥有的所有特性和 API。基本上就是解决他们在 JavaScript 生态系统中看到和发现的问题,
00:02:58以及现有库和框架格局中的问题——如果你愿意这么说的话——特别是当然是 React,
00:03:06因为它是我们目前拥有的主要库和框架,
00:03:09取决于你想怎么称呼它。那么,
00:03:12这个新 Remix 到底是关于什么的呢?上周五我们看到了什么?
00:03:18我们得以看到首个演示,
00:03:19首次一瞥这个 API。我会在视频下方链接完整的直播,
00:03:23如果你想完整观看整个发布活动的话。但要注意,
00:03:27那将是大约四个小时不间断的演示和解释。我已经看过了,
00:03:31这样你就不必看了——如果你不想看的话。但如果你想了解更多,
00:03:36绝对值得一看。在这里你会看到这个新框架的主要内容之一,
00:03:40或者说是在 X 平台上引起一些波澜的主要内容:this.update。看起来不太引人注目,
00:03:47对吧?但实际上它暗示了两件事。
00:03:49这个框架的重点是什么,
00:03:51或者说是引起一些关注的主要内容:this.update。看起来不太引人注目,
00:03:58对吧?但实际上它暗示了两件 JavaScript 开发者已经不太习惯的事情。
00:04:04第一,
00:04:05this 关键字的使用。我的意思是,
00:04:08像我这样的老家伙,
00:04:10我们在开始学习 JavaScript 时学会了 this 的所有怪癖和特性。但如今你不会经常使用它了。在 React 中,
00:04:22你可能永远不会写 this。但它是 JavaScript 内置的关键字。他们利用这个 this 关键字向你暴露一些 API。你在哪里能访问这些 API 呢?你仍然编写函数。
00:04:39所以你不用编写类,
00:04:40即使你可能因为 this 关键字而以为要这样做。但在使用 Remix 时,
00:04:47你仍然在构建组件,
00:04:48并且仍然会使用函数来实现。就像你在 React 中了解的那样,
00:04:54但这些组件函数看起来会有些不同。但让我们回到 this.update。我提到过它有两个重要方面,
00:05:03this 是其中之一,
00:05:05update 是另一个。因为在 Remix 第三版中,
00:05:09你必须告诉框架何时应该更新屏幕,
00:05:12何时应该重新渲染。这当然是我们不再习惯的事情。因为在 React,
00:05:18以及 Vue 和 Angular 中,
00:05:22你依赖框架为你确定何时更新。在 React 中,
00:05:26当你调用 setState 时,
00:05:29你是在给你管理的状态分配一个新值,
00:05:32这也会触发 UI 更新。但不一定是立即的,
00:05:36相反 React 会进行一些批处理,
00:05:39可能会收集多个状态更新等等。但最终它会更新 UI。所以通过 setState,
00:05:46你在某种程度上告诉 React 它应该更新 UI,
00:05:50但你主要是在告诉它某个值发生了变化,
00:05:53UI 将被更新、
00:05:55将被重新渲染是这个变化的结果。而 Remix 则不同。在 Remix 第三版中,
00:06:02你会在标准变量中管理你的状态,
00:06:05没有什么特别的。没有 useState hook 或类似的东西,
00:06:10实际上根本没有 hooks。然后你只需在知道 UI 应该更新时调用 this.update。所以你可以改变一堆变量而不调用 this.update,
00:06:24UI 就不会更新。或者你改变一堆变量并调用 this.update,
00:06:30UI 就会更新。这就是它的工作方式。似乎有一些人——你知道互联网的,
00:06:36互联网上的人很可怕——一些人对此有些意见。我想说,
00:06:40让我们看看它是如何工作的。我的意思是,
00:06:44这是一种新方法,
00:06:45而旧方法确实运作良好。我想这也是为什么它被所有这些库和框架使用的原因。但旧方法确实也有可能成为一个陷阱,
00:06:55可能导致不太清楚为什么某些东西会更新或不会更新的情况。在更复杂的应用中,
00:07:01尤其是使用了许多 hooks 等功能的 React 新版本,
00:07:06真正理解发生了什么可能会让人不知所措。这就是为什么他们回归到一个更简单的 API,
00:07:14让你拥有完全的控制权。
00:07:16他们还使用 this 关键字向你暴露了一些其他的 API，但实际上并不多，因为显然这个框架的理念是保持简单和专注，给你良好的开发者体验，让这个框架易于使用。同时，因为他们在今年早些时候分享的一篇博客文章中明确表达的目标是，这个框架应该易于被大型语言模型使用。所以这个想法显然是，你能够将文档文章或示例提供到与大型语言模型的对话历史中，提供一些信息作为上下文，然后让 LLM 和代码助手帮助你生成代码。因为他们当然需要这样做，毕竟这是一个全新的框架。显然，现有的大型语言模型都没有在这个代码库上进行训练，而且在可预见的未来也不会在上面训练，因为似乎 80% 的前端代码示例都是 React，特别是使用 shadcn 的 React。所以他们当然需要找到另一种方式，让开发者能够让大型语言模型了解如何编写 Remix v3 代码。这也是他们保持 API 简单的另一个原因，我想，也是为什么他们想保持它的表达性、
00:08:35易于理解和易于使用，因为不仅人类应该使用它，模型——大型语言模型也应该使用它。所以这显然是他们的一个目标。你可以在他们分享的示例中看到这一点。此外，他们在那次主题演讲、
00:08:52那次演示中多次表达的另一个目标是，他们正在使用 Web 原生特性。他们使用现代浏览器中可用的功能，不仅仅是浏览器，还包括后端，我马上会讲到后端。但他们使用的是浏览器内置的东西。他们严重依赖原生事件和分发自定义事件的内置能力。所以你可以在浏览器中创建自定义事件并分发它们，他们大量依赖这一点。他们依赖 abort signals 来传达组件已卸载的信息，例如，并允许你自动停止事件监听器。所以他们使用浏览器内置的东西，因为我确实觉得我们 Web 开发者并没有跟上现代浏览器能做什么。不仅仅是现代浏览器，某些功能已经存在多年了，我们却不使用它们。如果你真正深入了解 DOM 所提供的、
00:09:49浏览器所提供的、
00:09:51那里有哪些可用的 API，我们甚至可能不知道它们。那里有很多东西可以做，很多地方你可能不需要额外的第三方库，这最终就是他们试图利用的。保持简单，使用这些内置功能，这最终就是他们在这里的方法。现在正如我所说，它仍然是一个框架。你不会使用 createElement 和所有那些 DOM API 来创建 DOM 节点。相反，如前所述，你仍然会通过创建函数并在其中使用 JSX 代码来创建组件。他们展示了所有这些。只是状态管理的工作方式完全不同，总体上更精简，你不会有 hooks 或类似的东西。这也是因为那些组件函数不会像在 React 中那样一次又一次地被调用。相反，你会有两种函数，根据你如何编写它们，它们要么只被调用一次，要么其中的一部分可能会被多次调用。这里有一些信息给那些可能在 2017 年就使用过 React 的人，你可能记得我们有两种类型的组件。我们有基于类的有状态组件，可以管理状态，可以在状态改变时更新；我们还有无状态组件，那时是组件函数。然后我们有了 React hooks，所有组件都最终成为了组件函数，它们可以是有状态的，也可以是无状态的。Remix 版本 3 采用了那种老式的 React 方法，可以这么说，但不是用类或函数，而是始终使用函数，但是不同类型的函数。如果你有一个返回 JSX 的函数，它最终是一个无状态组件。你不能在里面调用 this.update 并期望组件函数再次执行。它不会这样工作。你可以接受 props，如果父组件重新渲染，你的组件函数会再次执行等等。但你不能在里面管理状态。你将组件函数转变为有状态组件函数，可以这么说，不是通过返回 JSX 代码，而是返回一个返回 JSX 代码的函数。所以一个组件函数包含并返回一个函数，然后这个函数返回 JSX 代码，这样就可以成为一个有状态组件。在那里，当你调用 this.update 那个函数时，你返回的函数将再次执行，至少我是这样理解的。所以我们有不同的组件类型，但最终仍然是一个非常简单的 API，一种非常简单的区分有状态或无状态组件函数的方法。然后是后端，因为 Remix 版本 3 不仅仅是一个前端框架，相反，它是一个全栈框架。它旨在成为一个全栈框架。但顺便说一句，他们还将发布一个组件库，使构建复杂的表单组件等变得更简单。我也应该提到这一点。但回到后端。它还将配备一个后端部分。它旨在成为一个前端和后端结合的全栈框架。再次强调，完全没有 React，相反，他们可以说是从头开始重建所有东西。但在后端，你会得到一个路由器，一个非常强大的路由器，因为显然他们在过去 10 年里构建了 React Router，他们对路由了解很多。所以你会得到一个强大的路由器。你可以在路由中返回 JSX 代码和 Remix 组件，并在服务器上混合这些组件。他们提出了自己的替代方案来替代 React 服务器组件，一个更简单的替代方案，允许你返回一个组件，该组件在客户端上提供服务后可以通过重新获取部分 DOM 来进行更新。所以例如，当你删除某些内容时，你可以从客户端向该服务器发送请求，并获取一些可以再次混合的 HTML 代码来更新部分 DOM。所以他们为我们提供了所有这些功能来构建快速的、
00:14:15现代的、
00:14:16类似单页应用的全栈应用程序，就像你可以用 Next.js 或 React Router 框架模式或其他框架如 TanStack Start 那样，但更简单，这是明确的目标——有一种简单的方式来构建这些应用。这就是他们想做的。这个演示中还有更多内容。它很长，但我认为这是最重要的部分。这是我的主要收获。他们想给我们一个强大而简单的全栈框架。他们从头开始编写它。我们有手动更新等等。所以我描述的一切，我们需要吗？
00:14:56这是一个大问题，我想另一个大问题是：它会成功吗？
00:15:02显然这两个问题都很难回答，但我会尽力而为。我们需要吗？
00:15:08嗯，我认为我们已经有很多 JavaScript 框架了，显然会有很多人说我们有太多了，所以答案就是不需要。我一直认为，即使在 2018 年，当时我们每周都有一个新框架，即使那时我也认为，拥有创新和尝试新想法总是好的。我不认为我们需要一个新框架，只是像 React 一样但有一些微小差异的框架。我不认为我们需要那个。但一个全新的方法，带有手动触发更新和所有这些其他小东西。我认为这是一个好主意。绝对值得一试。听起来很有趣。它可能会给我们一个比 React 更简单的替代方案，React 很棒，但多年来已经变得相当复杂了。所以是的，我们可能需要它。它会成功吗？
00:16:04当然，这是另一个问题，尤其是现在在AI和大型语言模型的时代，这些模型通常会默认推荐React。另一方面，不懂编程的人当然不一定是直接的目标受众，至少不是直接的。我稍后会回到这个话题。所以这在那里并不重要。然而，有经验的开发者可能会对使用Remix感兴趣，并借助官方示例等来引导大型语言模型生成Remix代码，仅仅是因为他们想要一个更简单的代码库。因为归根结底，作为开发者，我们仍然会接触我们的代码。我们可能会生成其中的大部分，但我们仍然控制着大型语言模型。我们仍然会调整部分代码。如果我们心中有一个非常具体的功能，而AI似乎就是无法正确实现，我们可能会编写更大部分的代码。所以显然，作为开发者，我们仍然关心技术栈。至少我仍然关心，我相信你们中的一些人也是如此。所以在这方面，尝试其他东西可能会很有趣，只要该框架易于与大型语言模型一起使用，有足够的资源来教大型语言模型如何使用它——这当然是他们似乎关注并优先考虑的事情——对我来说听起来不错。所以这可能确实给了他们一个成功的有效机会。显然这会很困难。但是，我想这种情况总是会存在的。所以我看到了机会，但当然，可以说这是一个拥挤的市场。现在重要的是，Remix属于Shopify。早在2022年，
00:17:52Shopify收购了Remix，可以这么说，Remix团队成为了Shopify的一部分。现在，Shopify显然当然对拥有一个得到积极维护并且至少在Shopify内部被使用的框架感兴趣。我说的不仅仅是在公司内部用于他们的Shopify营销和品牌页面。我指的是Shopify商店，目标很可能是将Remix作为Shopify供应商的一个选项，这些供应商想要在Shopify之上构建自己的商店，并且想要一种简单的方式来调整这些商店并构建构成整个商店的自定义店面或页面。他们当然拥有一个易于使用且易于与大型语言模型一起使用的框架，这可能会产生巨大的影响。当然，这仍然不是保证，但我猜Shopify支持Remix当然价值很大。因此，我对Remix的未来相当乐观，当然也是因为他们可能规模较小但非常热情的社区，据我所知，他们有出色的业绩记录，显然开发了React Router等等。所以是的，我非常兴奋地想看看我们会得到什么。我很兴奋能最终自己使用它，因为现在这还不太可能。这些是我的想法。所以像往常一样，让我知道你的想法，如果你认为我们需要它，如果他们会成功。如果你感兴趣并想了解更多，请观看会议完整的四小时部分。