Asana正在全面检查我们的应用程序框架，这似乎是一个很好的时间来分享我们所采取的方法，以及什么是有效的，是什么导致了问题。当体式在2008年末开始时，我们有三个主要的框架目标：通过在数据更改时自动更新UI来减少bug（以及工程师的工作量）。通过在客户机上运行处理程序并用客户机已有的数据尽可能多地更新UI来屏蔽网络延迟（而不是等待服务器提供新的UI）。通过在一次往返中获取客户端需要的所有内容来减少网络延迟。六年多（！）后来，我们仍然认为这些都是正确的目标。让我们看看我们是如何追杀他们的。一种不同的反应性自动反应性允许框架确定当数据更改时客户端需要重新呈现什么。理想情况下，它可以确保如果应用程序能够在状态A和状态B中正确地呈现，那么它就可以在状态之间正确地转换，因为框架管理转换的细节。我们的反应性方法是将调用图分成不同的反应单元。我们通过在rvalue对象中包装一些函数来实现这一点。当一个rvalue执行的代码请求另一个rvalue的值时，我们会自动记录它们之间的依赖关系。大多数rvalue都没有副作用，但是一些特殊的值在计算或重新计算时会更新DOM元素。我们可以通过重新计算所有过时的rvalue来更新DOM。（Quora上有更多关于这个的信息。）rvalue是重新计算的最小单位，也是更新UI的最小单位。也就是说，如果一个rvalue重新计算，那么它所创建的任何DOM元素都将被重新创建。因此，工程师需要使用大量的rvalue来避免在重新计算时破坏动画和丢失滚动位置。然而，更多的rvalue意味着来自rvalues以及它们之间的依赖关系的开销更大。结果是，添加特性通常会降低性能。更糟糕的是，大部分的剩余值都没有被使用。例如，在页面加载过程中，我们创建数千个rvalue，以正确地隔离正在呈现的所有任务的不同部分。不过，大多数情况下，用户不会做出可以从这些rvalue中获益的更改。相反，他们会切换到另一个项目，我们不得不花费更多的时间来破坏这些数据结构。最后，由于代码的执行顺序是由框架控制的，因此很难调试被拆分为许多rvalue的代码。我们仍然相信系统的反应性比在整个应用程序中手工构建要好得多。但是，我们正在切换到React，因为它通过使用较粗的重新计算单元（视图/组件）来达到更好的平衡，同时仍然通过比较视图返回的新旧DOM描述对DOM进行细粒度更新。我们仍然相信系统的反应性比在整个应用程序中手工构建要好得多。然而，我们正转而作出反应，一元云购下载，网站用云服务器，因为它能达到更好的平衡。客户端数据存储和对象复制我们框架的一个关键组件是在客户机上运行的全功能数据存储。这与服务器同步以获取对象和发送更改，并允许应用程序代码加载对象和运行查询，就像在服务器上一样。客户机数据存储还允许应用程序代码在更改结果发送到服务器之前查看更改结果。不过，服务器仍然是权威的，因此一旦客户机听到服务器上应用了更改，它就会放弃更改的版本并使用服务器提供的数据。流星和接力也采用这种方法。我们认为，一个反映本地变化的可写客户端数据存储是现代web应用的一个要求，我们的新框架将继续以这种方式工作。我们认为，一个反映本地变化的可写客户端数据存储是现代web应用的一个要求，我们的新框架将继续以这种方式工作。不过，我们正在做一个改变。Asana的当前版本在客户端和服务器之间共享应用程序代码。这使得客户端很容易在服务器确认更改之前准确地模拟它，但是在我们看来，它会在客户端和服务器之间产生不可接受的耦合，特别是在考虑本机移动客户端时。Asana的未来版本将为客户机（Typescript、ObjectiveC/Swift和Java）和服务器（Scala）提供不同语言的独立代码。这将导致一些重复，但目前我们认为，去耦使这一点变得有价值，并将使支持无法与我们的服务器共享代码的第三方客户端变得更加容易。远离客户端模拟我们已经讨论了很多关于客户端的内容，但是每个web应用程序都需要一个知道客户端需要什么数据的服务器。传统上，这是很多痛苦的根源，因为新特性需要对客户机和服务器进行匹配的更改，通常由不同的团队进行。意外地使服务器加载的数据超过客户端所需的数据，很容易导致性能问题。一种解决方案是让客户机对它想要的数据发出许多小请求。这使客户机处于控制地位，并将其与服务器分离，但它通常需要多次往返，再次导致性能问题。Asana的解决方案是在服务器上模拟应用程序：我们查看应用程序加载的数据并将其发送到客户机。在这种情况下，你很难想象客户机需要什么样的数据，而在这种情况下，你却很难写出正确的数据。这是一种自由的编程方式。但也有很多问题，从偶然性到内在性。性能一段代码很难同时高效地呈现UI、有效地加载数据（包括对数据库和缓存的批处理请求）和可维护性。此外，大数据培训，您通常希望在客户机上预加载数据，以便在用户执行某些常见操作时立即可用，但这需要在多个状态下模拟服务器上的UI，从而进一步降低性能并消耗内存。处理程序在UI中模拟所有的处理程序是不可行的，所以我们不能总是得到它们需要的数据。处理程序崩溃，除非应用程序的某个部分碰巧加载了他们需要的。版本控制为了使模拟工作，客户机和服务器必须运行完全相同的代码版本。我们的web服务器需要我们的代码的多个版本，并运行客户机请求的版本。我们必须取消对旧客户机的支持，因为旧客户机的服务器代码有缺陷，无法继续运行。这对web客户端来说已经够糟糕的了，我们可以在需要时强制重新加载。但是，对于移动客户端来说，这是不可接受的，因为旧版本必须在服务器错误被修复的情况下工作。一个更深层次的问题是，查淘客，模拟鼓励应用程序开发人员关注他们正在构建的UI，而不是他们正在加载的数据，或者他们往返缓存或数据库的次数。在某种程度上，这是模拟的重点，但是加载的数据量和到后端的往返次数对应用程序的性能至关重要。由于很容易更改应用程序以加载更多数据或连续加载数据，而且很难（或不可能）通过静态分析来捕捉这些数据，我们被迫为应用程序的最重要部分编写测试。由于几个原因，在服务器上缓存给定视图所需的数据也是无效的。模拟鼓励开发人员加载他们想要的任何数据，结果是视图的数据通常依赖于会话状态和当前用户。此外，视图加载的数据取决于视图、其子视图以及这些视图使用的所有框架的代码。每次部署代码时，都很难确定新版本仍可以使用哪些缓存项。我们正在转向一种更具声明性的方式，让客户指定他们需要的数据。我们的目标是拥有一个小型、快速的服务器，根据这些描述处理和加载数据。通过保持描述中没有代码，我们将使服务器更容易在客户机、用户和版本之间缓存数据。这与Facebook的接力类似，但有一些重要区别。对于客户机，我们将这些描述编译为TypeScript接口，从而使我们更安全地访问数据。更多信息，请参阅我们关于切换到TypeScript的帖子。我们正在转向一种更具声明性的方式，让客户指定他们需要的数据。摘要公司成立六年来，框架的初始目标似乎仍然合理。我们对反应性的实现使一些平衡错误，但其他人已经证明基本方法是正确的。客户机数据存储正在成为新web框架的标准。模拟的问题比我们预期的要严重，云店，特别是随着本地移动应用的兴起。我们已经学到了很多东西，并且对于使用下一代框架来完成体式任务感到兴奋。正如你所料，这东西工作起来很有趣。你愿意加入我们吗？