DOI:10.1145/2669482
Article development led by queue.acm.org
Conditional dependency resolution.
BY ALEX LIU
JavaScript and the Netflix User Interface
IN THE TWO decades since its introduction, JavaScript has become the de facto official language of the Web. JavaScript trumps every other language when it comes to the number of runtime environments in the wild.
Nearly every consumer hardware device on the market today supports the language in some way. While this
is done most commonly through the integration of a Web browser appli- cation, many devices now also sup- port Web views natively as part of the operating system user interface (UI). Across most platforms (phones, tab- lets, TVs, game consoles), the Netflix UI, for example, is written almost en- tirely in JavaScript.
Despite its humble beginnings as a language intended to be Javarsquo;s “silly little brother,”4 JavaScript eventually became a key component in enabling the Web 2.0 evolution. Via the intro- duction of Ajax, this evolution added an element of dynamism to the Web, creating the concept of a living and so- cial Web that is now taken for granted. Today the languagersquo;s influence contin- ues to grow as it makes its way into the server landscape via Node.js. For all of its shortcomings, arguably JavaScript has more than successfully achieved the “write once, run anywhere” motto
that Sun Microsystems often used to tout as one of the benefits of Java.
With increasingly more applica- tion logic being shifted to the browser, developers have begun to push the boundaries of what JavaScript was originally intended for. Entire desktop applications are now being rebuilt en- tirely in JavaScript—the Google Docs office suite is one example. Such large applications require creative solutions to manage the complexity of loading the required JavaScript files and their dependencies. The problem can be compounded when introducing mul- tivariate A/B testing, a concept that is at the core of the Netflix DNA. Multi- variate testing introduces a number of problems that JavaScript cannot handle using native constructs, one of which is the focus of this article: man- aging conditional dependencies. De- spite this, engineering ingenuity has enabled Netflix to build highly com-
plex and engaging UIs in a rapid and maintainable fashion.
A/B Testing Netflix.Com
Netflix is steeped in a culture of A/B testing. All elements of the service, from movie personalization algorithms to video encoding, all the way down to the UI, are potential targets for an A/B test. It is not unusual to find the typical Netflix subscriber allocated into 30 to 50 different A/B tests simultaneously. Running the tests at this scale provides the flexibility to try radically new ap- proaches and multiple evolutionary ap- proaches at the same time. Nowhere is this more apparent than in the UI.
While many of the A/B tests are launched in synchrony across multiple platforms and devices, they can also target specific devices (phones or tab- lets). The tests allow experimentation with radically different UI experiences
Table 1. The search-box test.
Experience Desired Behavior Requirements
Search Box Test Cell 0 (Control) Search Results Page Must be a U.S. subscriber Search Box Test Cell 0 (Control) Search Results Page Type 2 Not a U.S. subscriber
Search Box Test Cell 1 Autocomplete Subscriber allocated to Cell 1 Search Box Test Cell 2 Instant Search Subscriber allocated to Cell 2
from subscriber to subscriber, and the active lifetime of these tests can range from one day to six months or more. The goal is to understand how the fun- damental differences in the core phi- losophy behind each of these designs can enable Netflix to deliver a better user experience.
A/B testing on the Netflix website tends to add new features or alter ex- isting features to enhance the con- trol experience. Many of the website tests are designed from the outset to be cross-allocation friendly—in other words, stackable with other A/B tests. This ensures newly introduced func- tionality can coexist with other tests. Thus, while one Netflix subscriberrsquo;s homepage can look similar on the sur- face to another subscriberrsquo;s homep- age, various bits and pieces of function- ality are added or modified throughout the page to make the end product feel
different. It should be noted the test- ing encompasses all pieces of the Net- flix UI (HTML, CSS, JavaScript), but the focus here is on using JavaScript to re- duce the scope of the problem.
Facets to Features to Modules
The HTTP Archive estimates the aver- age website in 2014 includes approxi- mately 290KB of JavaScript across 18 different files.2 By comparison, the Netflix homepage today delivers, on average, a 150KB payload in a single JavaScript file. This file actually con- sists of 30 to 50 different files concat- enated together, with their inclusion in the payload being dictated by one or many of the hundreds of personal- ization facets generated by Netflixrsquo;s recommendation algorithms. These facets can be commonly derived via a subscriberrsquo;s A/B test allocations, coun- try of signup, viewing tastes, and shar- ing preferences (Facebook integra- tion), but can be conceivably backed by any piece of arbitrary logic. These fac- ets act as switches, a method by which the UI can be efficiently pivoted and tweaked. This has driven the website into a distinctly unique predicament: how to manage packaging and delivery of many different UIs in a maintain- able and performant manner.
It is useful first to draw a clear line connecting the personalization facets and their impact on the UI. A simple example can help illustrate this rela- tionship. Letrsquo;s imagine that today we want to A/B test a search bo
剩余内容已隐藏，支付完成后下载完整资料
JavaScript和Netflix用户界面
ALEX LIU
事实上，自推出以来的两年间，JavaScript已成为Web的官方语言。当谈到野外运行时环境的数量时，JavaScript胜过其他任何语言。
目前市场上几乎所有的消费类硬件设备都以某种方式支持该语言。虽然这通常是通过集成Web浏览器应用程序完成的，但许多设备现在也可以本地支持Web视图，作为操作系统用户界面（UI）的一部分。在大多数平台（手机，标签，电视，游戏机）中，例如Netflix用户界面几乎都是用JavaScript编写的。
尽管它以Java语言的小兄弟的身份为开端，但JavaScript最终成为实现Web 2.0演进的关键组件。通过引入Ajax，这一演变为Web增添了活力元素，创造了一种现在被认为是理所当然的生活和社会网络的概念。今天，随着JavaScript通过Node.js进入服务器环境，JavaScript的影响力不断增长。对于它的所有缺点，可以说JavaScript已经成功地实现了Sun Microsystems经常用来宣扬Java的好处之一的“一次编写，随处运行”的座右铭。
随着越来越多的应用程序逻辑转移到浏览器，开发人员已经开始推动JavaScript最初的目标。整个桌面应用程序现在正在使用JavaScript完全重建——Google Docs办公套件就是一个例子。这种大型应用程序需要创造性的解决方案来管理加载所需JavaScript文件及其依赖关系的复杂性。 当引入多变量A/B测试时，这个问题可能会更加复杂，这个概念是Netflix DNA的核心。多变量测试引入了许多JavaScript无法使用本地构造处理的问题，其中之一是本文的重点：管理条件依赖关系。尽管如此，工程创意使Netflix能够以快速和可维护的方式构建高度复杂且引人入胜的用户界面。
1 A/B 测试 Netflix.Com
Netflix充满了A/B测试的文化。从电影个性化算法到视频编码的所有服务元素一直到用户界面，都是A/B测试的潜在目标。将典型的Netflix用户同时分配到30到50个不同的A / B测试中并不罕见。以这种规模运行测试可以灵活地同时尝试全新的方法和多种进化方法。没有比UI更明显的了。
虽然许多A/B测试跨多个平台和设备同步启动，但它们也可以定位特定设备（电话或选项卡）。这些测试允许实验从用户到用户的完全不同的UI体验，这些测试的活跃生命周期可以从一天到六个月或更长。我们的目标是了解这些设计背后的核心理念之间的巨大差异如何使Netflix能够提供更好的用户体验。
Netflix网站上的A/B测试往往会增加新功能或改变现有功能以增强控制体验。 许多网站测试从一开始就被设计为交叉分配友好——换言之，可以与其他A / B测试进行堆叠。这确保新引入的功能可以与其他测试共存。因此，虽然一个Netflix用户的主页在外观上可能与另一个用户的主页类似，但在整个页面中添加或修改了各种功能，以使最终产品不同。应该指出的是，测试包含了所有的Netflix UI（HTML，CSS，JavaScript），但这里的重点是使用JavaScript来缩小问题的范围。
2 面向特征到模块
据HTTP Archive估计，2014年平均网站在18个不同文件中包含大约290KB的JavaScript。2相比之下，Netflix主页平均在单个JavaScript文件中提供150KB有效载荷。这个文件实际上由30到50个不同的文件连接在一起，它们包含在有效负载中由Netflix推荐算法生成的数百个个性化方面中的一个或多个指定。这些方面通常可以通过用户的A/B测试分配，注册国家，观看口味和分享偏好（Facebook集成）来获得，但可以用任意逻辑来支持。这些功能充当开关，一种可以有效地调整和调整UI的方法。这导致网站陷入了一个非常独特的困境：如何以可维护和高性能的方式管理许多不同UI的打包和交付。
首先要明确界定个性化方面及其对用户界面的影响。一个简单的例子可以帮助说明这种关系。让我们想象一下，今天我们想要A/B测试一个搜索框。对于此测试，我们可能有一个控制单元，这是将用户送到搜索结果页面的传统体验。为了满足区域用户体验差异的需求，我们还根据用户是否位于美国境内对该控制小区进行了细微的变化。第一个测试小区提供了自动完成功能，并且可用于分配给1区的所有用户。在这种情况下的分配意味着用户被随机选择参加这个测试。第二个测试单元通过显示用户输入的结果，在当前页面上提供搜索结果。我们称之为即时搜索，并且它可用于2区中分配的所有用户。这些是三种不同的体验或“特性”，每种体验都由一组非常具体的个性化设施进行把控。因此，当用户被分配到测试中并且他们的特征满足测试的要求时（见表1），用户只能看到其中的一种搜索体验。页面的其他部分（如页眉或页脚）可以以类似的方式进行测试，而不会影响搜索框测试。
表1 搜索框测试
在这个测试策略下，将网站的每个功能部分分离成离散的沙盒文件（称为模块）是有缺陷的。在JavaScript中，模块已经成为一种常见的最佳实践，作为在离散和内聚单元中安全地对相关特征进行沙箱和分组的方式。由于各种各样的技术原因，这是可取的：它减少了隐含的全局变量的影响;它可以使用私人/公共方法和特性;它允许存在真正的进口/出口系统。进口/出口也为适当的依赖管理打开了大门。
在这种情况下，模块背后还有另一个驱动力。它们实现了从一页到下一页的无缝功能的便携。应该将网页划分成越来越小的部分，直到可以使用现有模块组合新的有效载荷为止。如果功能必须从之前的模块中分离出来才能实现，那么这个模块可能就是一个可能的指标，因为这个模块有太多的责任。单位越小，维护、测试和部署就越容易。
最后，使用模块来封装功能，可以在A/B测试门户的个性化构面之上构建抽象层。由于测试资格可以映射到特定功能，并且可以将某个功能映射到模块，因此只需确定用户是否符合当前每个活动测试的条件，就可以有效解决给定用户的JavaScript负载问题。
在这个测试策略下，将网站的每个功能部分分离成离散的沙盒文件（称为模块）是有缺陷的。在JavaScript中，模块已经成为一种常见的最佳实践，作为在离散和内聚单元中安全地对相关特征进行沙箱和分组的方式。由于各种各样的技术原因，这是可取的：它减少了隐含的全局变量的影响;它可以使用私人/公共方法和特性;它允许存在真正的进口/出口系统。进口/出口也为适当的依赖管理打开了大门。
在这种情况下，模块背后还有另一个驱动力。它们允许从一页到下一页的无缝功能便携性。应该将网页划分成越来越小的部分，直到可以使用现有模块组合新的有效载荷为止。如果功能必须从之前的模块中分离出来才能实现，那么这个模块可能就是一个可能的指标，因为这个模块有太多的责任。单位越小，维护，测试和部署就越容易。
最后，使用模块来封装功能，可以在A/B测试门户的个性化构面之上构建抽象层。由于测试资格可以映射到特定功能，并且可以将某个功能映射到模块，因此只需确定用户是否符合当前每个活动测试的条件，就可以有效解决给定用户的JavaScript负载问题。在这个测试策略下，将网站的每个功能部分分离成离散的沙盒文件（称为模块）是有缺陷的。在JavaScript中，模块已经成为一种常见的最佳实践，作为在离散和内聚单元中安全地对相关特征进行沙箱和分组的方式。由于各种各样的技术原因，这是可取的：它减少了隐含的全局变量的影响;它可以使用私人/公共方法和特性;它允许存在真正的进口/出口系统。进口/出口也为适当的依赖管理打开了大门。
在这种情况下，模块背后还有另一个驱动力。它们允许从一页到下一页的无缝功能便携性。应该将网页划分成越来越小的部分，直到可以使用现有模块组合新的有效载荷为止。如果功能必须从之前的模块中分离出来才能实现，那么这个模块可能就是一个可能的指标，因为这个模块有太多的责任。单位越小，维护，测试和部署就越容易。
最后，使用模块来封装功能，可以在A/B测试门户的个性化构面之上构建抽象层。由于测试资格可以映射到特定功能，并且可以将某个功能映射到模块，因此只需确定用户是否符合当前每个活动测试的条件，就可以有效解决给定用户的JavaScript负载问题。
3 依赖管理
模块还允许更先进的技术发挥作用，其中之一对于复杂的应用程序非常重要：依赖管理。在许多语言中，可以同步导入依赖关系，因为运行时环境与所请求的依赖关系在同一台机器上共同驻留。然而，管理浏览器端JavaScript依赖关系的复杂性在于运行时环境（浏览器）与其源（服务器）之间的延迟时间不确定。网络延迟可能是当今Web应用程序性能最显着的瓶颈1，因此，面临的挑战是如何为给定的一系列不确定性约束条件找到带宽和延迟之间的平衡点，每个请求。
多年来，Web社区设计了多种方法来处理这种复杂性，并取得了不同程度的成功。早期的解决方案简单地包括页面上的所有依赖关系，而不管模块是否被使用。尽管简单且一致，但这会对用户造成不利影响，带宽限制往往会加重已经很长的加载时间。后来的解决方案依赖浏览器将多个异步请求返回给服务器，因为它确实可以减少某些依赖。这也有其缺点，因为它惩罚了深度依赖树。在这个实现中，深度为N节点的有依赖树的负载可能会在所有依赖加载之前占用N-1个串行请求。
最近，引入异步模块定义（AMD）库（如RequireJS）允许用户创建模块，然后通过静态分析依赖关系树以每页为基础预先生成有效负载。该解决方案通过生成仅包含页面所需内容的特定有效负载并避免基于依赖关系树深度的不必要的惩罚，将前两种解决方案中的最佳解决方案结合起来。更有意思的是，用户也可以完全退出静态分析步骤并回退异步取回依赖关系，也可以采用两者的组合。在图1中，一个名为foo的模块有三个依赖关系。因为depC是异步获取的，所以在页面准备好之前（其中N = 2，N是树的深度）需要N-1个附加请求。应用程序的依赖关系树可以使用静态分析工具构建。
图1 AMD module popularized by libraries such as RequireJS.
4 有条件的依赖关系
AMD和类似解决方案的问题是他们对静态依赖树的假设。在有效负载大小的情况下，从而增加页面加载所花费的时间。
即时提取依赖关系的第二种选择是可能的，但可能会在UI的响应性方面引入任意延迟（见图3）。在这个选项中，只有需要的模块被加载，代价是额外的异步请求。如果任何搜索模块具有附加的依赖关系，那么在搜索被初始化之前还会有另一个请求等。
这两种选择都是不受欢迎的，并且已被证明对用户体验有显着的负面影响。3他们也没有考虑到某些个性化方面仅在服务器上可用的可能性，并且出于安全原因不能考虑JavaScript层。
图2 A header module that loads all three search features but uses only one of them.
图2 A header module that loads only the modules needed.
5 大数字改变一切
Netflix网站存储库计数超过600个独特的JavaScript文件和超过500个独特的Cascading Style Sheets（CSS）文件。A/B测试占绝大多数这些文件。可以使用独特组合的公式来估计网站处理的不同JavaScript负载的数量：n!/r!(n-r)! 假设总共包含600个模块，并且估算平均JavaScript有效负载包括约40个模块，那么您将得到以下可能的组合数量：
600!/40!(560!) = 433518929550349486086117218185493567650720611537099964754232870
这个数字很引人注目，尽管并不完全诚实。在600个不同的模块中，大多数不是独立可选的。其中许多模块取决于其他常见平台模块，这些平台模块依赖于第三方模块。而且，即使是最大的A/B测试，通常影响的用户也不到300万。这似乎是一个需要测试的大量人口，但实际上它仍然是总计50多万用户群中的一小部分。这些信息导致了一些早期的结论：首先，测试的分配不够大，无法在整个Netflix用户基础上均匀分配； 其次，可独立选择的文件数量非常少。这些都将有助于显着减少独特组合的数量。
与其试图调整公式，不如试图分享一些经验数据。该网站每周都会部署一个新版本。对于每个构建周期，网站都会大致生成250万个JavaScript和CSS有效载荷的独特组合。
鉴于这个庞大的数量，它打算让浏览器以树型结构来解析这些依赖。此解决方案适用于小型代码库，因为附加的序列请求可能相对不重要。如前所述，然而，由于A/B测试的规模，网站上的典型有效载荷包含30到50个不同的模块。即使可以利用浏览器的并行资源获取来获得最大效率，在潜在的30多个请求中累积的延迟也足以产生次优的体验。在图4中，即使只有一个深度仅为5个节点的简单示例，页面也会在页面准备好之前发出四个异步请求。真正的制作页面可能容易拥有15多个深度。
由于异步加载的依赖关系已经不适合这种特殊情况，A/B测试的规模决定了提供单一JavaScript有效载荷的选择。如果单个有效载荷是解决方案，这可能会给人以印象，这些250万个独特的有效载荷提前生成。这将需要分析每个部署周期的所有个性化方面，以便为每个可能的测试组合构建正确的有效负载。然而，如果用户和A/B测试增长持续正确的轨迹，那么抢先生成的有效负载将变得站不住脚。独特的有效载荷数量今天可能达到250万个，但明天将达到500万个。对Netflix的需求来说，这不是正确的长期解决方案。
图4 Letting the browser fetc
剩余内容已隐藏，支付完成后下载完整资料
资料编号：[23106]，资料为PDF文档或Word文档，PDF文档可免费转换为Word
课题毕业论文、外文翻译、任务书、文献综述、开题报告、程序设计、图纸设计等资料可联系客服协助查找。
