如果不是水疗中心,那是什么?

2020-10-29 10:33:40

几个月前,我写了一篇关于SPA模式如何未能简化Web开发的文章。我试图定义的SPA模式(Single-Page Apps)是关于Reaction模型的,该模型在很大程度上还涵盖了Vue、ANGLE和其他前端框架的模型。

就像任何批评一样,它乞求开处方,而我没有开处方,只是指着像Rails和Django这样的服务器端框架。但我认为有一些趋势开始形成。我已经排了一些时间来真正深入研究这些框架,但像在公园里散步这样的事情已经被优先考虑了,所以这里只是一次盛大的参观。

我主要谈论的是Remix、Redwood JS和Blitz.js,不过我确信在无反应领域也有类似的努力。Js几乎属于这一类,但据我所知,它对数据层仍然没有意见,大多数使用Next.js的站点仍将使用单独的API堆栈。但这可能会改变,因为所有这些都在快速发展。

有趣的是,Remix、Redwood和NeXT都得到了公司或基金会的支持,而闪电战的目标是很早就成为赞助商资助的项目。我认为,这些项目试图避开早先开放源码的“公地悲剧”失败,即超负荷工作和无报酬的维护人员为大量用户提供服务,最终耗尽并放弃该项目。

以Remix为例,它将数据加载与路由重新捆绑在一起,然后给出了一个相当惊人的承诺,即在默认情况下不提取客户端数据。这些框架在状态代码和缓存策略上也是固执己见的。Redwood JS使用GraphQL和Prisma自动创建一个类似ORM的界面。

作为背景,Remix得到了Reaction培训人员的支持,他们也是Reaction Router的成员,这是您在没有加入Facebook团队的情况下所能获得的最多的Reaction血统。Redwood由普雷斯顿-沃纳风险投资公司(Preston-Werner Ventures)运营,其创始人汤姆·普雷斯顿-沃纳(Tom Preston-Werner)是GitHub的创始人。Next.js是由Vercel,NeéZeit赞助和大力推广的。

值得一提的是Turbolinks。我直到今年才使用它,显然之前它有问题,但Turbolinks 5的重点是:在没有任何应用程序合作的情况下,你至少需要做什么才能获得SPA体验?

因此,它是一个很小的JavaScript库,它位于现有的服务器呈现的应用程序之上,并用类似于SPA的部分页面加载替换完整的页面加载。不是从头开始加载页面,而是使用Ajax加载页面,替换页面内容,并且客户端导航更新您的URL。基本上,它可以防止实际页面过渡的“眨眼”,并节省完全加载新页面的所有其他成本。Turbolinks是从Ruby on rails项目衍生出来的,在Rails上工作得很好,但并不需要它。

就用户体验改进的重量比而言,Turbolinks是一个佼佼者:它几乎没有增加复杂性,而且对用户体验的大幅改善只产生了很小的影响。

这些是最辣的新解决方案。主要竞争者是Laravel Livewire(PHP版)、Sumulus Reflex(Ruby on rails版)和Phoenix LiveView(凤凰网上的Elixir版)。

这里的重点是:如果您不需要编写任何JavaScript会怎么样?它有点像是在“为什么”的art&;&;code Talk中对JavaScript的批评,即Web开发是通常必须用三种(或更多)语言编写的唯一一种语言。这些语言还保留了大部分“客户端”逻辑,将其全部放在服务器端。

他们是怎么做到这一点的?嗯,有很多WebSocket,比如Reflex和LiveView,以及非常紧密耦合的服务器交互。正如您在LiveView演示(我强烈推荐)中看到的那样,这些框架的操作有点像前端的反应式DOM库-在其中,框架计算出从一种状态转换到另一种状态的最小步骤-只是这些步骤是在服务器端计算的,然后通常在客户端应用。他们还在服务器端进行了更多的数据存储和状态管理,因为许多原本不会持久保存到服务器上的交互现在至少已经与服务器进行了通信。

这些框架令人兴奋,而且非常逆向,因为它们与“前端加不可知的API层”模式截然相反,而且它们还全心全意地接受每个人都试图避免的事情:服务器上的可变状态。

这些通常是对上述功能的“补充”,但它们确实值得大声疾呼,因为我认为大量的前端编程问题实际上只需要少量的JavaScript提示即可。但是主要的注意事项是,他们假设您了解JavaScript和DOM,这两个不一定是通用技能。许多在REACTION上长大的开发人员在原生浏览器API上获得了一个真正的盲点。

我看过的主要有SIMPLICAL(出自Ruby on rails阵营)、Alpine和htmlx。它们都很小,在现有页面上工作得很好。我认为--火焰来了--Web组件也适合这个渐进式增强的领域!如果你只使用好的Web组件--只有GitHub编写的组件才是一个很好的经验法则--那么它们就能胜任改善现有静态UI的任务。这就是您开始使用Web组件作为成熟前端框架的替代产品的地方,而这似乎是事情变得危险的地方。

这些框架拥有在深度改进的Web堆栈上运行的奢侈,该堆栈具有FETCH()和MutationWatch等基本组件。这些东西以前是渐进式增强框架实用程序的核心,现在它们可以仅仅是这些框架构建的实用程序。

我敢肯定,外面还有其他的模式!但这些潮流现在看起来都很强大,看到一些真正不同的、富有冒险精神和常识的方法开始涌现,这是一件令人着迷的事情。