性能更是重中之重这里Wayfair,因为更高的性能意味着更好的客户体验。一个显著一块网络性能是它需要渲染,或生成,页面标记的时间。在过去的几个月里,我们努力改进我们面向客户的网站的渲染性能,并确保这是对我们的工程师写的代码更容易的结果页面进行性能优化渲染。

我们在Wayfair上使用Backbone.js和Mustache模板作为JavaScript模块已经有一段时间了,但是去年我们意识到我们的前端性能需要升级。我们确定了两个需要改进的方面:客户端DOM更新的效率,以及将DOM操作抽象出来,使其远离工程师。

第一个问题是标准渲染实现在主干中的结果。默认情况下,主干呈现实现不做任何事情。要由开发人员根据自己的需要来实现render函数。这个(和)的一个常见实现在骨干文档给出的例子)看起来像这样:

{this.$el.html(this.template(this.model.attributes));}

这个实现的问题是双重的:首先,整个观点是不必要的重新与jQuery的美元(). html()每当呈现,其次,渲染方法总是操纵DOM无论数据改变,所以工程师必须显式的调用渲染时避免不必要的昂贵的DOM更新。这两个问题的解决方案是混合时才调用渲染工程师需要重新确定整个视图,然后编写低级的DOM操作代码时只需要更新的部分视图,或更新需要更精确的(例如,改变一个类视图)的一个元素。所有这些都意味着工程师必须时刻注意DOM的状态,并且必须注意任何DOM操作的性能后果。这使得视图模块难以推理,并且包含低级DOM操作代码。

为了解决这两个问题,我们研究了前端框架,这些框架将从开发人员那里提取DOM,同时提供高性能更新。我们看的主要库是React.js,一个UI库开源被Facebook利用单向虚拟DOM渲染数据流支持高性能的客户端DOM更新。我们真的很喜欢React.js,却遇到了一个大问题:缺乏支持,这使高性能服务器端呈现模板。

在现代web站点和应用程序的HTML呈现发生在两个点:在页面加载时从HTML DOM构建从服务器传递,又多次(0)当JavaScript更新DOM在页面加载之后,通常由于用户与页面交互。最初的渲染是在服务器上进行的,比如像Wayfair这样的多页面站点,我们做了很多工作来确保它尽可能快。HTML标记是在Mustache模板中编写的,并通过实现为an的c++ Mustache渲染器呈现扩展库。这给我们的速度服务器端渲染速度甚至比本地的PHP的看法。

由于服务器端渲染是我们网站的一个重要组成部分,我们很高兴的是React.js带有此功能的开箱。不幸的是,而服务器端渲染可提供React.js,它比我们现有的C ++小胡子设置显著慢。除了性能,在服务器上渲染React.js将需要Node.js的服务器,以补充我们的PHP服务器。对于UI渲染这一新规定将相继推出的复杂性,以及新的单点故障的进入我们的服务器堆栈。由于这些原因,以及我们已经完成了现有的小胡子模板,我们希望重用的事实,我们决定React.js不是一个不错的选择。

我们将何去何从?我们喜欢reaction .js介绍给我们的许多概念,比如响应性数据驱动视图和虚拟DOM渲染,但是我们不希望选择前端框架来决定服务器端技术,也不希望通过c++和PHP代替Mustache渲染。所以,在调查了一些其他可用的东西之后,我们决定从response .js中提取我们喜欢的概念,并自己用对我们的技术栈有意义的特性来实现它们。

今年早些时候,我们写道Tungsten.js,模块化的Web UI框架,利用共享胡子的模板,使服务器和客户机上的高性能渲染。几个星期前,我们宣布我们是开源Tungsten.js今天我们很激动地宣布,钨。js的主要开发将是“GitHub first”,框架的所有新更新都可以在我们的GitHub repo中找到:https://github.com/wayfair/tungstenjs

Tungsten.js是我们小胡子模板,虚拟-DOM和Backbone.js的间建成的桥梁。它使用Ractive编译器的预编译胡子模板返回虚拟DOM对象的功能。它使用虚拟DOMdiff/patch库来对DOM进行智能更新。它使用Backbone.js视图、模型和集合作为面向开发人员的API。至少,它为我们在Wayfair使用了所有这些图书馆。js把模块化放在首位。js中的任何一层都可以替换为一个类似的库,并配以适配器。主干可以替换为&号。可以将虚拟dom换出另一个实现。胡子可以换成把手,甚至JSX。所以,更一般地,Tungsten.js是一个UI更新机构,用于开发一视图层的标记符号(模板)的任意组合之间的桥,和。

我们不指望Tungsten.js成为大家最合适的,但我们认为它符合一组通用的应用情况非常好。我们一直在使用它在生产面向客户的网页一会儿在这里Wayfair,到目前为止,我们已经非常满意。我们的全栈的工程师经常告诉我们,他们远远喜欢用钨香草Backbone.js的+ jQuery的,而我们现在已经改善客户端性能是DOM操作是由开发人员抽象出来。虽然我们并不想成为“最快”前端框架周围,事实证明,当我们重新实现从React.js CONF瑞安弗洛朗斯的DBMonster演示Tungsten.js,浏览器的帧速率结束是,给予或采取,在相同的水平都反应恩伯,线

在Wayfair,我们有句话叫“我们永远不会结束”。这当然是钨的情况。js,我们在不断改进。在接下来的几个月里,我们有很多关于钨。js的想法,所以请关注回购的更新。当然,我们欢迎投稿!