Facebook React与Web Components（聚合物）的优缺点

#1 楼

更新：这个答案似乎很受欢迎，所以我花了一些时间清理它，添加一些新信息并澄清一些我认为不够清楚的事情。如果您认为还有其他需要澄清或更新的地方，请发表评论。

您的大多数顾虑实际上都是意见和个人偏爱问题，但我会尽可能客观地回答：

本机与已编译



用普通JavaScript编写JavaScript，用CSS编写CSS，用HTML编写HTML
。


早在一天前，人们就应该手动编写本机汇编还是使用C之类的高级语言来使编译器为您生成汇编代码而展开激烈的辩论。甚至在此之前，人们就不信任汇编程序，而是更喜欢手工编写本机代码（我不是在开玩笑）。

同时，今天有很多人用Haml或Jade编写HTML。 ，Sass或更少的CSS以及CoffeeScript或TypeScript的JavaScript。在那。有用。有些人喜欢它，有些人则不喜欢。

要点是，不使用普通JavaScript编写JavaScript，不使用CSS编写CSS和不使用HTML编写HTML根本没有什么错误。这实际上是一个优先选择的问题。

内部与外部DSLs


Â使用Shadow DOM进行样式封装
。在JavaScript中。不漂亮。


漂亮与否，肯定可以表达。 JavaScript是一种非常强大的语言，比CSS（甚至包括任何CSS预处理器）要强大得多。这取决于您是喜欢内部DSL还是外部DSL。再次，是一个优先事项。

（注意：我所谈论的是在原始问题中引用的React中的内联样式。）

DSL的类型-说明

更新：写完一段时间后阅读我的答案，我想我需要在这里解释我的意思。 DSL是一种特定于域的语言，它可以是内部的（使用JavaScript之类的宿主语言语法-例如不使用JSX的React或上述React中的内联样式），也可以是外部的（使用其他语法）而不是宿主语言-就像本例中那样，是内联JavaScript（JavaScript内嵌外部DSL））。

这可能会造成混淆，因为某些文献使用不同于``内部''和``外部''的术语来描述那种DSL。有时使用“嵌入式”代替“内部”，但是“嵌入式”一词可能具有不同的含义-例如，Lua被描述为“ Lua：一种可扩展的嵌入式语言”，其中嵌入式与嵌入式（内部）DSL没有任何关系（在在某种意义上说，这是完全相反的-外部DSL），但它意味着它以与SQLite是嵌入式数据库相同的意义被嵌入。甚至在eLua中，“ e”在第三种意义上代表“嵌入式”-这是针对嵌入式系统的！这就是为什么我不喜欢使用“嵌入式DSL”一词的原因，因为诸如eLua之类的东西可以是从两种不同意义上“嵌入式”的“ DSL”，而根本不是“嵌入式DSL”！

使情况更糟的是，某些项目甚至给组合带来了更多混乱。例如。熨斗模板被描述为“无DSL”，而实际上它只是内部DSL的完美示例，其语法如下：map.where('href').is('/').insert('newurl');

我写过“ JavaScript是一个非常强大的功能”。这种语言比CSS（甚至包括任何CSS预处理器）要强大得多。它的种类取决于您是选择内部DSL还是外部DSL。这又是一个优先事项。”我正在谈论这两种情况：

一个：

/** @jsx React.DOM */
var colored = {
  color: myColor
};
React.renderComponent(<div style={colored}>Hello World!</div>, mountNode);

两个：

// SASS:
.colored {
  color: $my-color;
}
// HTML:
<div class="colored">Hello World!</div>

第一个示例使用问题中描述的内容：“用JavaScript编写CSS。不漂亮。”第二个示例使用Sass。虽然我同意使用JavaScript编写CSS可能不是很漂亮（对于一些``漂亮''的定义），但是这样做有一个好处。

我可以在Sass中拥有变量和函数，但是它们是词汇范围还是动态范围？它们是静态类型还是动态类型？强还是弱？那数字类型呢？类型强制？哪些价值观是真实的，哪些价值观是虚假的？我可以拥有高阶函数吗？递归？尾声？词汇闭包？是按正常顺序还是适用顺序对它们进行评估？是否有懒惰或渴望的评估？函数的参数是通过值还是通过引用传递？他们易变吗？一成不变？坚持不懈？那对象呢？上课吗原型？继承？

那些不是琐碎的问题，但是如果我想了解Sass或Less代码，我必须知道它们的答案。我已经知道了JavaScript的那些答案，因此这意味着我已经在这些级别上了解了每个内部DSL（例如React中的内联样式），因此如果我使用React，那么我只知道对这些答案的一套（以及许多类似的答案） ）问题，而当我使用例如然后，Sass和Handlebars我必须知道三组答案并理解其含义。

并不是说一种或另一种总是更好，但是每次您将另一种语言引入组合时，您乍看之下付出的代价可能并不那么明显，而且这个代价太复杂了。

我希望我澄清一下我最初的意思。

数据绑定


双向绑定


这是一个非常有趣的话题，实际上也是一个优先事项。双向并不总是比单向更好。这是一个有关如何在应用程序中建模可变状态的问题。我一直认为双向绑定是一种有点违背函数式编程原理的想法，但是函数式编程并不是唯一可行的范例，有些人喜欢这种行为，并且两种方法在实践中似乎都很好用。如果您对与React中的状态建模相关的设计决策的细节感兴趣，请观看Pete Hunt的演讲（与问题链接）以及Tom Occhino和Jordan Walke的演讲，他们在本书中对此做了很好的解释我的看法。

更新：另请参见Pete Hunt的另一篇演讲：可预测，不正确：功能DOM编程。

更新2：值得注意的是，许多开发人员在争论针对双向数据流或双向绑定，有人甚至称其为反模式。以Flux应用程序体系结构为例，该体系结构明确避免使用MVC模型（事实证明，该模型很难扩展到大型Facebook和Instagram应用程序），而是采用严格的单向数据流（请参阅Hacker Way：在Facebook上重新思考Web App开发） Tom Occhino，Jing Chen和Pete Hunt作了很好的介绍）。另外，对AngularJS（基于MVC模型的最流行的Web框架，以双向数据绑定闻名）的很多批评都包含针对该双向数据流的参数，请参见： br />
我希望我能告诉我有关Angular.js的事情

Danny Tuppeny破坏了HTML

AngularJS：Lars的不良部分Eidnes

Jeff Whelpley的Angular.js有什么问题（“双向数据绑定是一种反模式。”）

为什么不应该使用Egor Koshelko的Angular.js （“双向数据绑定原则上不是处理事件的方法。”）

更新3：另一篇有趣的文章很好地解释了上面讨论的一些问题是解构ReactJS的Flux-由RefluxJS的作者Mikael Brassman撰写的《不将MVC与ReactJS一起使用》（Flux启发的单向数据流应用程序架构的简单库）。 >
更新4：Ember.js目前正在脱离双向数据绑定，在将来的版本中，默认情况下将变为单向数据绑定。请参阅：2014年11月15日在多伦多Embergarten研讨会上的Stefan Penner的Stefan Penner发言。

更新5：另请参阅：Ember 2.0 RFC之路-在请求中的有趣讨论Tom Dale：

“当我们设计原始的模板层时，我们发现使所有数据绑定都采用双向方式并不是很有害：如果您不设置双向绑定，那是一个事实上，单向绑定！

我们意识到（在React的朋友的帮助下），组件希望能够将数据分发给他们的孩子，而不必警惕

此外，组件之间的通信通常最自然地表示为事件或回调。在Ember中是可能的，但是双向数据绑定的主导地位常常使人们走上使用两个对象的道路。双向绑定作为通信渠道。经验丰富的Ember开发人员通常不会犯此错误，但这很容易犯。 [添加了重点]

本机vs.VM


本机浏览器支持（请阅读“保证更快”）


现在终于有了一些无关紧要的事情了。

实际上，这里的情况恰恰相反。当然“本机”代码可以用C ++编写，但是您认为JavaScript引擎是用什么编写的？

事实上，JavaScript引擎在当今使用的优化中确实令人惊叹-这些天不仅是V8，而且SpiderMonkey甚至Chakra都闪闪发光。并且请记住，使用JIT编译器，代码不仅会尽可能地原生，而且还存在运行时优化的机会，而这在任何静态编译的代码中都是根本无法实现的。

认为JavaScript速度很慢，通常表示访问DOM的JavaScript。 DOM很慢。它是本地的，用C ++编写，但是由于它必须实现复杂性，因此它实在太慢了。

打开控制台并编写：

console.dir(document.createElement('div'));

，查看甚至没有附加到DOM的空div元素必须实现多少个属性。这些仅是属于“自身属性”的第一级属性。不是从原型链继承的：


对齐，等待，onvolumechange，ontimeupdate，onsuspend，onsubmit，安装，onshow，onselect，onseeking，onseeked，onscroll，onresize，onreset，onratechange，onprogress，onplaying，onplay，onpause，onmousewheel，onmouseup，onmouseover，onmouseout，onmous onmouseenter，onmousedown，onloadstart，onloadedmetadata，onloadeddata，onload，onkeyup，onkeypress，onkeydown，oninvalid，oninput，onfocus，onerror，onded，onemptyed，ondurationchange，ondrop，ondragstart，ondragover，ondragleave，ondragenter，ondrague oncontextmenu，onclose，onclick，onchange，oncanplaythrough，oncanplay，oncancel，onblur，onabort，拼写检查，isContentEditable，contentEditable，outerText，innerText，accessKey，隐藏，webkitdropzone，draggable，tabIndex，dir，translate，lang，title，childElementCount，lastElementChild， firstElementChild，孩子，nextElementSibling，previousElementSibling，onwheel，onwebkitfullscreenerror，onwebkitfullscreenchange，onsele ctstart，onsearch，onpaste，oncut，oncopy，onbeforepaste，onbeforecut，onbeforecopy，webkitShadowRoot，数据集，classList，className，outerHTML，innerHTML，scrollHeight，scrollWidth，scrollTop，scrollLeft，clientHeight，clientWidth，clientWidth，clientTop，clientLeft，offsetParent，offsetHeight，offsetWidth， offsetTop，offsetLeft，localName，前缀，namespaceURI，id，样式，属性，tagName，parentElement，textContent，baseURI，ownerDocument，nextSibling，previousSibling，lastChild，firstChild，childNodes，parentNode，nodeType，nodeValue，nodeName


其中许多实际上是嵌套对象-要在浏览器中查看空的本机div的第二级（自有）属性，请参阅此提琴。

我是说认真的，每个div节点上的onvolumechange属性是什么？错了吗不，这只是事件处理程序之一的旧式DOM Level 0传统事件模型版本，“必须受所有HTML元素支持，内容属性和IDL属性都应支持” [强调] HTML规范第6.1.6.2节同时，这是React中伪DOM div的第一级属性：


道具，_owner，_lifeCycleState ，_pendingProps，_pendingCallbacks，_pendingOwner


完全不同，不是吗？实际上，这是整个对象序列化为JSON（LIVE DEMO）的原因，因为您实际上可以将其序列化为JSON，因为它不包含任何循环引用-在本机DOM领域中这是不可想象的（它只会抛出异常） ）：

{
  "props": {},
  "_owner": null,
  "_lifeCycleState": "UNMOUNTED",
  "_pendingProps": null,
  "_pendingCallbacks": null,
  "_pendingOwner": null
}

这几乎是React可以比本机浏览器DOM更快的主要原因-因为它不必实现这种混乱。 />
请参阅Steven Luscher的演示文稿，以了解更快的方法：用C ++编写的本机DOM或完全用JavaScript编写的伪DOM。这是一个非常公平和有趣的演示。

更新：未来版本中的Ember.js将使用受React极大启发的虚拟DOM来提高性能。请参阅：2014年11月15日在多伦多Embergarten研讨会上的Stefan Penner的Stefan Penner演讲。

总结：Web组件的功能，例如模板，数据绑定或自定义元素将具有与React相比，它有很多优点，但是直到文档对象模型本身被大大简化为止，性能才不是其中之一。我发布此答案两个月后，这里有一些相关新闻。正如我刚刚在Twitter上所写的那样，即使是根据Wikipedia的说法，“ GitHub所编写的Atom文本编辑器的最新版本也使用Facebook的React来获得更好的性能”，尽管“ Atom基于Chromium并以C ++编写”，因此它对原生C ++ DOM实现（请参阅《原子核》），并保证支持Web组件，因为它附带了自己的Web浏览器。这只是一个现实世界项目的最新示例，该项目可以使用Web应用程序通常无法使用的任何其他类型的优化，但是即使Atom仍选择使用本身用JavaScript编写的React来实现最佳性能。最初不是使用React构建的，所以这并不是一件小事。

更新2

Todd Parker进行了有趣的比较，使用WebPagetest比较了用Angular，Backbone，Ember，Polymer，CanJS，YUI，Knockout，React和Shoestring编写的TodoMVC示例。这是我到目前为止看到的最客观的比较。这里重要的是，所有相应示例均由所有这些框架的专家编写，它们都可以在GitHub上获得，并且可以认为认为某些代码可以进行优化以提高运行速度的人可以对其进行改进。 >
更新3

未来版本中的Ember.js将包含许多React的功能，此处将进行讨论（包括虚拟DOM和单向数据绑定，仅举几例），这意味着源自React的想法已经迁移到其他框架中。请参阅：通往Ember 2.0的RFC之路-Tom Dale（开始日期：2014-12-03）的拉取请求中的有趣讨论：“在Ember 2.0中，我们将采用“虚拟DOM”和数据流模型，其中包括来自React的最佳创意，并简化了组件之间的通信。“

同样，Angular.js 2.0也实现了此处讨论的许多概念。

更新4

我必须详细说明几个问题才能回答Igwe Kalu的评论：


“当React最终简化为纯JavaScript时，将React（JSX或编译输出）与纯JavaScript进行比较是不明智的。 。]
无论React用于DOM插入的策略如何，都可以不使用React来应用。也就是说，考虑方便性以外的其他功能不会带来任何特殊的好处。 “
（在此处有完整评论）


如果不清楚，在我的部分回答中，我正在比较直接在本机DOM上操作的性能（已实现作为浏览器中的宿主对象）与React的假/虚拟DOM（在JavaScript中实现）。我试图说明的一点是，用JavaScript实现的虚拟DOM可以胜过用C ++实现的真实DOM，而不是React不能胜过JavaScript（显然，因为它是用JavaScript编写的，所以没有多大意义）。我的观点是，并不总是保证“本机” C ++代码比“非本机” JavaScript更快。使用React来说明这一点只是一个例子。

但是，此评论触及了一个有趣的问题。从某种意义上说，您确实出于任何原因（例如性能，可移植性，功能）均不需要任何框架（React，Angular或jQuery），因为您始终可以重新创建框架为您所做的工作并重新发明轮子-如果您可以证明成本是合理的。

但是-正如Dave Smith很好地指出的那样，在比较Web框架性能时如何错失要点：“在比较两个Web框架时，问题是app与Framework X兼容。问题是我的app与Framework X兼容。“

在我2011年的回答中：不使用jQuery的一些经验性技术原因是什么？我解释了一个类似的问题，即没有jQuery之类的库就不可能编写可移植的DOM操作代码，但是人们很少这样做。 >
使用编程语言，库或框架时，人们倾向于使用最方便或惯用的做事方式，而不是完美但不便的方式。好的框架的真正价值在于使原本很难做到的事情变得容易-秘诀就是使正确的事情变得方便。结果仍然具有与最简单的lambda演算形式或最原始的Turing机器一样完全相同的功能，但是某些概念的相对表现力意味着这些概念往往更容易或根本不易于表达。正确的解决方案不仅可行，而且已得到广泛实施。

更新5

反应+性能=？保罗·刘易斯（Paul Lewis）在2015年7月发表的一篇文章中展示了一个示例，其中针对无限数量的Flickr图片列表，React比手工编写的香草JavaScript慢，这在移动设备上尤为重要。此示例表明，每个人都应该始终针对特定用例以及特定目标平台和设备测试性能。

感谢Kevin Lozandier引起我的注意。

#2 楼

聚合物很棒。 React很棒。
它们不是一回事。

Polymer是一个用于构建向后兼容的Web组件的库。

React是MVC中的V。这是View，仅此而已。至少不是一个人。

React不是框架。

React + Flux + Node +（Gulp或Grunt）与框架更具有可比性，但是其中3个不属于框架完全可以做出反应。

有很多技术，模式和体系结构样式可以使开发人员响应，但响应本身不是框架。是时候说最简单的事情了，不要将它们进行比较。它们有一些重叠，但是它们却有不同之处。

它们都允许您以不同的方式定义Web组件。除此之外，它们是非常不同的工具。

#3 楼

React专家对React和Web组件之间的比较有一个很好的解释：解决不同的问题。 WebComponents为可重用的组件提供了强大的封装，而React提供了一个声明式库，使DOM与您的数据保持同步。这两个目标是相辅相成的。工程师可以混合和匹配这些技术。作为开发人员，您可以自由地在WebComponents中使用React，或在React中使用WebComponents，或两者都使用。

#4 楼

具体来说，还有一个答案：


用普通JavaScript编写JavaScript，用CSS编写CSS，用HTML编写HTML
。


没有什么可以阻止您使用CoffeeScript，TypeScript，ClojureScript或其他任何语言编写Javascript。纯粹是优先考虑的事情。

HTML是用于静态HTML文档的最佳DSL。但是它没有为动态HTML提供任何东西。在浏览器中，使HTML动态化的最佳语言是Javascript，而不是具有特定Javascript DOM操作的纯HTML或不是甚至一半语言的模板语言（如Handlebars）。对于CSS，如果您CSS是静态的，您照常编写。如果需要基于某些运行时值进行动态处理，则它与HTML的故事相同：Javascript是使其动态化的最佳方法。

#5 楼

我认为，React的最大缺点是它不是基于Web标准的。目前，React是一个非常强大的工具，但是由于它会尽可能绕开浏览器提供的功能，因此随着浏览器内置功能的不断发展，现在看来有意义的决定可能在几年后就不再有意义。提高。因此，我想谈一谈它以及它如何影响Web应用程序的几个不同方面。
性能
人们喜欢说React的优势是它完全重新发明了整个DOM和事件模型，并且现有的标准DOM繁琐，昂贵且不算什么，但是最终，我还没有发现React的性能要比编写良好的Backbone或Polymer应用程序所能提供的更好。实际上，根据我的大多数专业经验，React的性能实际上要差一些。这并不是说React的速度很慢...这并不是我们都认为这是在我们获得它之前最前沿的性能选择。比本地DOM div轻得多，这是正确的。但是，为了使React有用，该“虚拟” div必须在某个时候最终成为真正的div。因此，在我的世界视野中，这不是React div与本机div的问题。这是一个React div +一个本机div与一个本机div。 React版本的DOM的开销是不平凡的，并且如果标准曾经丢弃了一些不需要的属性并允许本机DOM节点更轻巧，那么开销似乎真的很昂贵。
在我以前的工作场所之一，我们在Polymer中有一些应用程序，在React中有一些应用程序。最终，一个早期的Polymer应用程序之一最终被用React重写，因为这是该公司的标准，并且基于测量，我得出了同一应用程序的React版本比使用Polymer版本多了30％的内存。 ，尽管差异很小，但是Polymer版本的渲染时间也更少。这里要考虑的一件事是，我们谈论的是人们编写的应用程序，而人们并不完美，因此该应用程序的React实现有可能没有充分利用React的能力。但是我认为，至少其中一部分原因与React具有自己的DOM版本所产生的开销有关。
React使用自己的模型重新创建了整个DOM，然后将其用于主要的性能优化。视图被渲染到虚拟DOM中，并且被投影到真实DOM中。当发生更改并且必须更新视图时，视图将再次重新重新渲染到虚拟DOM中，并且该树与前一棵树进行了比较，以确定必须在实际DOM中更改哪些节点才能反映此更改。在视图中。尽管这是进行有效DOM更新的非常聪明的方法，但是维护所有这些虚拟DOM树并进行比较以确定实际DOM中的更改是有开销的。目前，这种性能开销已大大抵消了这些开销，但是随着本机DOM随着时间的推移而得到改进，规模将朝另一个方向转移。我担心React应用程序可能会老化，如果在3年后，它们将比直接处理DOM的速度慢得多。这种虚拟DOM方法有点像大锤子，其他类似Polymer的库也已经能够以非常微妙的方式实现非常有效的方法来处理DOM。
但是，一旦您开始使用这些组件并在React之外使用它们，事情就会变得更加混乱。由于将React组件制作为标签的方式完全不符合Web标准提供的内容，因此，除了React之外，没有其他人知道如何为您提供声明式方式来使用这些组件。如果我想将React组件放入使用Handlebars模板的现有Backbone视图中，则必须在模板中使用可以用作句柄的类或ID渲染虚拟div，然后编写命令式JavaScript来查找该虚拟div并进行安装您的组件。获得了使用服务器端模板的Express.js应用程序？嗯，就是同样的歌舞。一个JSP页面？你笑了，但是仍然有大量的应用程序在使用它们。除非您是没有现有代码的启动公司，否则您将不得不编写一些管道以便在许多应用程序中重用React组件。同时，Polymer通过Web组件标准实现组件，并且通过使用“自定义元素”规范，Polymer能够创作浏览器本机知道如何使用的组件。我甚至可以在React组件内部将Polymer组件放入JSP页面，Express.js模板，ASP.NET视图，Backbone视图中。在任何可以使用HTML的地方，都可以使用Polymer组件。进行重用工程的人们正在寻求Web标准，因为标准是使彼此容易兼容的契约。 YouTube不断在Polymer中创作越来越多的东西（来源：http：//react-etc.net/entry/youtube-is-being-rebuilt-on-web-components-and-polymer），我只能想象这些标准基于聚合物的方面是为什么。性能更新：
我前一段时间偶然发现的一个库，我认为管理DOM更新的工作更好。它是Google的增量Dom库，我认为它可以与dom就地一起使用并且不必创建“虚拟副本”，这是一种更干净的方法，具有更少的内存开销。
查看更多此处：http://google.github.io/incremental-dom/#about
声明性组件与命令性组件
谈论组件化应用程序时，您经常听到的一件事就是声明性组件的好处。在React的世界观中，一切都很好并且具有声明性。您编写了返回标记的JavaScript，React为您将所有标记粘合在一起。如果您要处理一个仅使用React而不使用其他任何东西的全新应用程序，那就太好了。您可以编写一些组件，只要您在React拥有的DOM片段中，就很简单，只需将该标签放在页面上即可使用您的组件。
摘要
我可以看到那里现在肯定是React的一些吸引人的方面。如果您使用的只是React，则可以构建一些小部件和某些组件，并声明式地在各处重复使用它们。但是我认为，如果React使用某些Web组件标准来实现其功能，而不是关闭并在浏览器中构建浏览器以及使所有内容保持同步的复杂机制，它的状况将会好得多。 br />

#6 楼

我没有使用过Web组件，但看起来它们需要您向事件处理程序中添加手动编码的变异逻辑。

Polymer示例中的代码片段：
React的全部目的是通过消除变异逻辑来降低复杂性。相反，您天真地重新生成了一个虚拟DOM，然后让React的diff算法找出实际DOM中需要更改的内容。