Web软件的未来是WebSockets上的HTML

基于网络的软件架构的未来已经形成，并且这次是服务器渲染（再次）。爸爸有了一个崭新的包：HTML-over-WebSockets并可以随时播放所有内容。

将单页应用程序与API服务结合使用的双重方法使许多开发团队陷入了无休止的JSON争吵和跨两层的状态差异错误的困扰。这会浪费开发时间，放慢发布周期并节省创新带宽。

但是，由WebSockets驱动的新方法吸引了Web开发人员的注意力。它重申了经典服务器渲染框架的承诺：快速原型制作，服务器端状态管理，可靠的渲染性能，快速的功能开发和简单的SEO。一种无需建立两个单独的应用程序即可实现多用户协作和响应式设计的设计。最终结果是一个单仓库应用程序，它对用户的感觉与客户端的所有JavaScript事件一样敏感，但是具有简单的模板和更少的加载微调器，并且没有状态错位，因为状态仅位于一个地方。所有这些都为我们提供了一条相当容易（且更快！）的开发路径。

回收所有花费在解决架构难题上的时间，可以为您提供大量的多余时间，您可以用它们来做一些很棒的事情。花费您的开发预算和公司的薪金预算，自己开心地构建全功能，并在对公司和客户有利的方面进行创新。

而且我认为，没有比Ruby on Rails更好的应用程序框架可用于回收乏味的开发时间。再看一下被低估的刺激。使用ViewComponents在MVC中增强视图。添加CableReady和StimulusReflex库中的Reactive Rails（被称为）新车味，就可以参加比赛了。但是，稍后我们将回到Rails ...

Web框架在2005年左右突然出现，其中出现了很多由自己决定的脚本语言库，这些语言库粘在一起并扔到了手动维护的Apache服务器上。这种新的体系结构为开发人员提供了一种更全面的方法，该方法将所有复杂的内容封装在非接触式约定中，使开发人员可以将精力集中在编程人体工程学，代码可读性和快速上市功能上。开发人员所需要做的就是学习框架的核心语言，了解框架本身及其约定，然后开始制作复杂的Web应用程序，而他们的朋友仍在为所有其他方法编写XML配置文件。

尽管早期的批评总是困扰着新方法，但这些服务器呈现的框架已成为首选的工具，特别是对于快速移动的初创公司（资源匮乏），昨天需要一个有吸引力的，功能丰富的应用程序。

随着Web开发世界更深入地进入2010年代，潮流开始转变，服务器呈现的框架相对于完全内置JavaScript并完全在客户端计算机上运行的Single Page Application有所退步。在许多公司中，“服务器”被降级为仅托管API数据服务，大多数业务逻辑和所有HTML呈现都在客户端上发生，这要归功于访客被迫下载的JavaScript大型'ol'程序包当他们第一次访问该网站时。

快进到2020年，网络并没有得到更快的发展，就像我们向SPA承诺的那样。在iPhone 4的喉咙里塞入数百万的JavaScript并不能带来良好的用户体验。而且，如果您认为构建专业的Web应用程序需要花费大量资源，那么构建Web应用程序和API服务以及它们之间的通信层又如何呢？我们是否真的相信我们每个用户都将拥有一种能够消化100 kB JSON并能够比中级服务器上的服务器端应用程序更快地渲染复杂HTML表的设备？

开发和托管这些可转发JavaScript的应用程序也不会便宜。在许多情况下，我们现在要完成两倍的工作，甚至可能要付两倍的开发人员酬劳，以达到与服务器端应用程序开发相同的结果。

在2005年，应用程序框架通过“在15分钟内构建一个博客应用程序”的视频引起了所有人的关注。十五年后，使用SPA方法做同样的事情可能需要两个代码库，一个JSON序列化层以及遍布各地的数十个微调框，因此我们仍然可以要求使用50ms的First Contentful Paint。同时，用户观看一些空白的灰色框，希望HTML最终从其浏览器正在请求和摘要的所有JSON呈现。

我们是怎么来到这里的？这不是我美丽的房子！为了兑现向用户提供更精美的用户界面的承诺，我们是否聪明地放弃了服务器赋予开发人员的所有幸福感，并加倍了人员和实施时间？

我们不是在为我们构建网络软件。我们正在为他们打造。我们软件的用户对软件的工作方式抱有期望。我们必须在他们所在的地方见他们。我们的用户不再对整页刷新和难看的Rube Goldberg式多表单工作流感到兴奋。 SPA方法是服务器上大量无组织的意粉JavaScript的又一个逻辑上的飞跃。但问题是：这是5％的改善，而不是500％的改善。

从用户的角度来看，使该网络应用程序令人眼花certainly乱的事情肯定会更加精彩。做得好，它可以使应用程序更流畅，更具交互性，并开辟了许多新的非本机交互元素。将这些元素作为组件进行规范化是下一个自然发展。过去的一天，思考如何更改整个HTML文档以给用户一种幻想，使其与页面上的原子小部件进行交互的幻想已经过去了。现在，可以直接实现该小部件，并且我们可以在组件方面考虑UX故障。但是，a，这笔费用几乎立即开始使我们吃不消。

继续，写那光滑的小星级星星组件。添加一些很酷的动画，使鼠标悬停并单击区域感觉良好，并在做出选择时提供一些生成内啡肽的反馈。但是现在呢？在一个真实的应用程序中，我们需要坚持这一改变，对吗？必须更改数据库以反映这种新状态，并且用户眼前的应用程序也必须反映该新现实。

在过去，我们会为用户提供几个星型GIF，每个GIF都以不同的param值链接到相同的服务器端点。在服务器端，我们将所做的更改保存到数据库中，然后发送回整个HTML页面供其浏览器重新呈现；也许我们甚至会幻想并在后台使用AJAX做到这一点，从而无需完整的HTML和渲染。假设前者的成本是开发人员时间和薪水的x倍（而且我们甚至不会谈论为市场推出太晚的功能而损失的机会成本）。在那种情况下，基于AJAX的奇特方法的成本为x + n（您知道，有些“额外的JavaScript撒入”），但是随着我们的应用程序变得越来越多的JavaScript意大利细面条撒得乱七八糟，很多n的成本也随之增加。

在SPA领域中，我们现在在客户端应用程序中编写JavaScript，并使用JSX或Handlebars模板来呈现组件，然后通过代码将更改保留到前端数据存储中，然后对API进行PUT请求，我们还要编写一个API端点来处理请求，一个JSON序列化程序（可能带有其自己的伪模板）将成功的响应打包，然后再编写前端代码以确保我们重新呈现该组件（以及一些分支逻辑，以便在后端发生故障时回滚并重新呈现客户端状态更改）。开发人员的时间和薪水甚至比x + n高得多。而且，如果您将团队划分为“前端”和“后端”人员，那么您不妨继续前进，将需要两个不同人员的许多非琐碎组件的成本（时间和金钱）增加一倍完成实施。当然，SPA缓解了一些不断增长的意大利面条问题，但是要使企业竞相进入市场或为需要它的人提供重要东西，企业付出了什么代价？

我们听到的支持SPA的其他论据之一是网络基础设施成本的降低。好像将托管负担加重到客户端上（在大多数情况下，未经他们的同意，但这是另一个主题），这在某种程度上节省了我们的云计算费用。但这太荒谬了。对于任何非平凡的应用程序，您仍在为服务器托管API以及为数据库托管另一个服务器付费，更不用说负载平衡器，DNS等了。这就是问题：没有哪一个成本能与之媲美软件公司向开发人员付款！认真考虑一下。我还没有从事过任何技术基础设施仅占薪资开销一小部分的业务。优秀的开发人员期望加薪。随着时间的推移，云服务器通常只会变得更便宜。

如果您想利用金钱来提高效率（特别是作为资金短缺的初创企业），则无需在云服务器上便宜一些；您需要从现有的高性能团队中更快地获得更多功能。

在过去的旧时代中，在使用Web框架之前，您需要花六个星期的时间向开发人员支付费用，以便最终揭晓……登录页面。提示悲伤的长号。然后，框架使该登录页面耗时一个小时，总共花了一个小时，而人们却在一夜之间启动了网络创业公司。喇叭声！现在，借助我们的SPA方法，我们又可以完成大量的额外工作。由于我们一次要编写两个应用程序，因此花费了我们更多的钱。那个长号又来了...

但是，如果我们可以从5％的改进中获得最佳的客户端JavaScript想法和库，并将它们与开发人员的人机工程学和单个代码库的薪水节省重新连接起来，该怎么办？如果组件和组织化的JavaScript全部都可以存在于为服务器端渲染优化的坚如磐石的应用程序框架中，该怎么办？如果有通往500％的跳跃之路怎么办？

听起来不可能？它不是。我已经看到了，就像C形光束在Tannhäuser门附近的黑暗中闪闪发光。我在闲暇时就建立了这个500％的应用，让我的孩子像狗一样在我身后四处跑动。向已登录的用户推送广播。客户端DOM的即时更新（以毫秒为单位）。与实时聊天窗口交互的JavaScript驱动的3D动画。所有这些都在一个单一的代码库中，在我用于“经典”服务器渲染的应用程序的相同服务器硬件上运行（也许我什至可以缩小硬件规模，因为我渲染HTML片段的频率要比整页文档高） 。没有单独的前端应用程序。干净的，组件化的JavaScript和服务器端代码，像花生酱和果冻一样完美地结合在一起。是真的，我告诉你！

于2011年最终确定，对现代浏览器中的WebSocket的支持在整个2010年代逐渐增加，现在已在所有现代浏览器中得到完全支持。借助少量的客户端JavaScript，您将在浏览器和服务器之间获得全双工套接字连接。数据可以双向传递，并且可以随时从任一侧推送，无需用户发起请求。

就像游戏行业向基于云的游戏不断发展的趋势一样，Web应用程序的未来将不再是将更大的义务推给用户/客户端，而恰恰相反：让客户端充当瘦终端，提供人类的状态。 WebSockets提供无缝，快速的通信层；从服务器到人的直接射击。

但是，对于许多开发人员来说，一开始并不容易做到这一点。我肯定没有好处也不是很清楚。经过多年（甚至数十年）的努力，所有服务器处理的功能都必须遵循HTTP请求周期，采用这种WebSocket技术层需要大量的工作量。与许多聪明的新技术或协议一样，我们需要一个更高层次的抽象，它提供了真正有效的东西，可以快速地将新功能呈现在用户面前。

希望预先输入与数据库完美同步的超响应数据列表吗？每次击键，都向WebSocket发送一个查询，并精确返回更改后的选项标签集，仅此而已。

客户端验证如何？简单。在每次输入更改时，将表单值四舍五入，然后将它们发送到WebSocket。让您的服务器框架验证并将更改发送回表单的HTML，包括需要呈现的所有错误。无需JSON或复杂的错误对象。

那多用户聊天呢？还是文件协作？在经典框架和SPA中，这些功能由于其难度以及使每个人的州保持一致所需的代码杂技而被我们推迟使用。使用在线HTML，我们只是根据一个用户的更改将HTML的少量内容推送给当前订阅该频道的所有其他用户。他们将看到完全相同的效果，就像他们点击刷新并重新向服务器请求整个HTML页面一样。您可以在30毫秒内将这些位发送给每个用户。

我们也不会放弃对组件的承诺。可以将这种基于WebSockets的方法看作是胖服务器/瘦客户机，我们的组件也是如此。分形，宝贝！使用智能JavaScript使该组件为用户带来令人愉悦的事情，然后只要求服务器提供更新的HTML，并更改DOM。无需客户端数据存储来管理组件的状态，因为它可以使自己呈现出完全像服务器所知道的样子。 HTML来自服务器，因此不需要JSX或Handlebars或“在此处插入其他JavaScript模板库”。服务器始终处于控制之中：渲染初始组件的外观并响应于任何状态更改而对其进行更新，这些过程全部通过套接字进行。

没什么好说的，您必须使用这些套接字通道仅发送HTML。发送一小段文字，然后让客户端执行一些巧妙的操作。将聊天消息从一个用户发送给其他所有用户，并让其各自的客户以他们当前使用的任何应用主题呈现该消息。想象可能性！

没有。著名的开源Web服务器本身就支持它，通常不需要任何额外的配置或设置。许多服务器端框架会自动将JS代码发送给客户端，以在通过套接字进行通信时提供本机支持。例如，在Rails中，设置您的应用程序以使用WebSockets就像配置内置的ActionCable一样容易，然后像往常一样在其他硬件上进行部署。有趣的是，典型的单个Rails服务器进程似乎很高兴能够支持近4,000个活动连接。而且，您无需依赖内置的Ruby WebSocket服务器，就可以轻松地换用出色的AnyCable，从而将每个节点最多增加10,000个以上的连接。同样，这是您首先要在其上运行网络服务器的常规硬件上的。您无需设置任何额外的硬件或增加您的云基础架构。

从Django的Sockpuppet到Phoenix的LiveView等等，这种新方法迅速以各种语言和Web框架的扩展，库或替代配置的形式出现。认真地，为您最喜欢的应用程序框架挖掘基于WebSockets的库，然后采用一种新的方式思考您的应用程序体系结构。像在夜间经过的喷气式战斗机一样，在插座上滑行的华丽HTML片段令人惊叹不已。它不只是一种新的技术方法；这是一种新思维，甚至可能是一系列关键应用功能的新源泉，这些都将推动您的创业成功。

但是，如果我不向读者强调我的最佳框架主角，我将不为所动。当然，任何应用程序框架都可以采用这种方法，但是为了我的钱，有充分的理由证明先锋可以是Ruby on Rails。

因此，距Rails推出已有15年了，我们回到了轨道上。＃section8

使用最新版本的Turbolinks，Stimulus，StimulusReflex，CableReady和GitHub的ViewComponent gem设置Rails 6应用程序，您就可以使用Reactive Rails，同时感觉就像在构建经典的Rails应用程序，就像在构建现代的Rails应用程序一样在单个代码库中将SPA组件化，具有服务器端渲染，HTML片段缓存，简单的SEO，坚如磐石的安全性等所有优点。您会突然发现工具带爆满了简单的工具，可以解决以前的艰巨挑战。

哦，通过Turbolinks，您还将获得包装器，以允许在同一代码库中混合使用本机/ HTML UI。使用诸如Heroku或Hatchbox之类的快速部署解决方案，一个开发人员可以在业余时间构建响应式，反应式，多平台的应用程序。如果您不相信我，请看这个Twitter克隆。

好的，这听起来很令人兴奋，但是为什么要特别使用Rails？它不老又无聊吗？您已经说过，任何框架都可以从这种新的WebSocket DOM变形方法中受益，对吗？

当然。但是，Rails一直闪耀的地方在于它能够快速，快速地制作原型，并拥有深抛光的宝石生态系统。 Rails也没有停止前进的步伐，该框架的最新版本6.1.3拥有大量很酷的功能。

如果您有一支小型的，资源匮乏的团队，Rails（以及框架之外的Ruby）仍然可以充当强大的力量倍增器，使您的体重超标，这可能解释了它帮助推动了920亿美元的收入这些年。借助这种新方法，该功能的重担将大大增加。当您的竞争对手摆弄他们的JSON序列化程序并努力优化所有加载微调器时，您每周或每天都将推出一项新的多用户协作功能。

你赢了。您的其他开发人员将获胜。您的生意赢了。而且，最重要的是，您的用户获胜。

从发布之日起，Rails便向社区做出了承诺。这就是为什么Rails产生了许多其他语言的模仿者的原因，也是为什么它在创业世界中出现了如此爆炸性增长的原因。同样，这种快速的原型制作精神与这种新的HTML-over-the-wire-wired方法相结合，使Rails具有强大的复兴能力。

Basecamp的优秀人才（最初是Rails的创建者）在2020年假期前就放弃了对概念Hotwire的看法，因此，应对这种令人振奋的新技术的选择范围将继续扩大。

不要称其为卷土重来，因为Rails来这里已有多年了。 通过这种新的体系结构方法，伴随着HTML-over-WebSockets和全双工JavaScript交互，Rails变成了新事物，美好事物，需要再次关注的事物。 与StimulusReflex和朋友一起使用的Reactive Rails对于那些精疲力竭的JSON端点或JSX的人来说是必看的，我很高兴看到它启用了新的应用程序。