"Go" Facebook React and Web components (polymer) comparative advantages and disadvantages

Translated from: http://segmentfault.com/blog/nightire/1190000000753400

Translator Preface

This is a question and answer from StackOverflow, asking people to think React compared to webcomponents
There are some "congenital deficiencies", listed below:

• Native browser support
• Native syntax support (meaning not to mix style and structure in JS)
• Using the Shadow DOM package style
• Bidirectional binding of data

All of these are indeed true. But he still wants to hear what people think, so he has this wonderful answer.

It is to be explained that this answer does not discuss too much technical details, but it is widely and comprehensively talked about many
Conceptual stuff, and supplemented with many advanced reading materials. Can say "gold" general but "letter
"Very large, especially to help many advanced people to broaden their horizons, to increase knowledge, to transform ideas."

In addition, the answer to the citation of a few speech videos are very exciting! Unfortunately, access is limited--you know.
However, I always feel that this year will not be "scientific internet", do not engage in development, so this is still strongly
I recommend you look good.

I think it would be helpful to some people, especially when it comes to questions that never come up with a friend (laughter), special
This translation is then recorded in the following:

Title: Pros and Cons of Facebook ' s React vs. Web components
(polymer)

Update:this answer seems to being pretty popular so I took some time to
Clean it up a little bit, add some new info and clarify some things that
I thought was is not clear enough.

update : It seems that my answer is very popular, so I took a little time to do a little tidying up, add a new inside
Further explanations of what had not been said before.

Most of your concerns is really a matter of opinion and personal
Preference but I'll try to answer as objectively as I can:

Much of what you have mentioned is actually a personal preference, but I still do my best to objectively answer the following:

Native vs. Compiled

Write JavaScript in vanilla JavaScript, write css in CSS, write HTML
In HTML.

Native language vs. precompiled language

Use plain JavaScript to write JavaScript, css to write CSS, html to write HTML.

There were hot debates whether one should write native
Assembly by hand or use a higher level language like C to make the
Compiler generate Assembly code for you. Even before that people refused
To trust assemblers and preferred to write native machine code by hand
(and I ' m not joking).

Looking back at the past, people have argued whether it's a direct handwritten assembly or a high-level language like C to take advantage of compiling
To generate assembly code. Even earlier, people refused to trust the assembler, preferring to write the original life by hand.
Code (I'm not kidding).

Meanwhile, today there is a lot of people who write HTML in Haml or
Jade, CSS in Sass or less and JavaScript in Coffeescript or TypeScript.
It ' s there. It works. Some people prefer it, Some don ' t.

Today, many people use Haml or Jade to write HTML, and to write CSS in Sass or less
, write JavaScript with Coffeescript or TypeScript. Existence is the truth, can catch the mouse
is a good cat. Some people love, of course, some people hate.

The point is this there is nothing fundamentally wrong in not writing
JavaScript in vanilla JavaScript, CSS in CSS and HTML in HTML. It ' s
Really a matter of preference.

The point is that there is nothing wrong with using the precompiled language in nature. This is purely a matter of preference.

Internal vs. External DSLs

Style encapsulation using Shadow DOM React instead have this, which
Requires writing CSS in JavaScript. Not pretty.

Internal vs. external DSLs

Use the Shadow DOM package style, while React uses this solution
, you need to write the CSS into JavaScript. Not elegant.

Pretty or not, it is certainly expressive. JavaScript is a very powerful
Language, much more powerful than CSS (even including any of CSS
preprocessors). It kind of depends on whether you prefer internal or
External DSLs for those sorts of things. Again, a matter of preference.

Elegance or not, it does make sense. JavaScript is a very powerful language, much more than CSS (counting
The same is true for any kind of CSS preprocessing language). This question depends on whether you like internal or external DSLs
。 Yes, it's a matter of preference.

(Note:i was talking about the inline-styles in React.
Referenced in the original question.)

(Note: I'm referring to the inline style in React that is referenced in the original topic.) ）

Types of Dsls-explanation

Update:reading My answer some time after writing it I think that I need
To explain what I mean here. DSL is a domain-specific language and it
Can is either internal (using syntax of the host language like
Javascript-like For example React without JSX, or like the inline
Styles in React mentioned above) or it can external (using
A different syntax than the host language
-like in this example would is inlining CSS (an external DLS) inside
JavaScript).

Types of DSLs-explanations

update : After the answer and reread my answer, I think it is necessary to explain further. Dsl
Refers to a domain-specific language , which can be internal (using the syntax of the host language, like
JavaScript-to React that do not use JSX, or inline styles in React, as mentioned earlier
can also be external (using a different syntax from the host language-for example, in the
Inline CSS written inside JavaScript (belongs to the external DSLs).

The author's answer seems paradoxical here, because in React the inline CSS is written and the
It should be one thing to write inline CSS in JavaScript (both of which use external DSLs), after all
React itself is using the host language (that is, JavaScript-this is an internal DSLs) to
It's written.

It can be confusing because some literature uses different terms than
"internal" and "external" to describe those Ki NDS of DLSS. Sometimes
"embedded" is used instead of "internal" but the word "embedded" can
mean different things-for example L UA is described as "Lua:an
Extensible Embedded Language" where embedded have nothing to does with
embedded (internal) DSL (in which sense it's quite the Opposite-an
external DSL) but it means that it's embedded in the same sense
T Hat, say, SQLite is an embedded database. There is even Elua where ' e '
stands for ' embedded ' in a third sense-that it's meant for embedded
systems! That's why I don't like using the term "embedded DSL" because
things like Elua can is "DSLs" that is "embedded" in both Different
senses while not being a "embedded DSL" at all!

It is often confusing that some materials use different terms to describe the DSLs types described above. Sometimes
"Embedded" will be used to refer to "internal" but "embedded" can also be other meaning--for example, Lua can
Described as "Lua: an extensible Embedded language" where "embedded" and "internal DSLs" are
There is no relationship between the gross money (and, more exactly, the opposite, embedded is an external DSL), it says and
"SQLite is an embedded database" one meaning. There is even a Elua, its "e" generation
Table another "embedded"-Embedded system! That's why I don't like to use the term "embedded DSL"
The reason, like Elua can be a two "embedded" meaning of the DSLs, but and "embedded DSLs"
There is no association.

To make things worse some projects introduce even more confusion to the
Mix. Eg. Flatiron templates is describes as "dsl-free" while in fact it
Is just a perfect example of the internal DSL with syntax like:
Map.where (' href '). is ('/'). Insert (' Newurl ');

What's worse is that some of the concepts introduced in the project have made the pond muddy. Example: Flatiron template claiming to be
"No DSL" is actually a perfect example of an internal DSL with the following syntax:

Map. where (' href ').  Is ('/'). Insert (' Newurl ');    

That had been said, when I wrote ' JavaScript is a very powerful
Language, much more powerful than CSS (even including any of CSS
preprocessors). It kind of depends on whether you prefer internal or
External DSLs for those sorts of things. Again, a matter of preference. "
I was talking about those II scenarios:

As I said before, when I wrote "JavaScript is a very powerful language, far more than CSS (counting
The same is true for any kind of CSS preprocessing language). This question depends on whether you like internal or external DSLs
。 Yes, it's a matter of preference. "I am referring to the following two scenarios:

One:

/** @jsx react.dom */var colored = {Color:mycolor}; React.rendercomponent (<style={Colored}>hello world!  </Div>, mountnode);    

Two:

sass:.colored {  color: $my-color;}  class="colored" >hello world!  </div>   

The first example uses what is
Described in the question as: "Writing CSS in JavaScript. Not pretty. "
The second example uses Sass. While I agree this using JavaScript to
Write CSS May is pretty (for some definitions of "pretty") but there
is one advantage of doing it.

The first example is as described in the original question: "Write CSS in JavaScript." Not elegant. "The second example is a
Use Sass. Although I also agree that using JavaScript to write CSS may be less elegant (in some sense
"Elegant") However, there is a merit in doing so.

I can have variables and functions in Sass but is they lexically scoped
or dynamically scoped? is they statically or dynamically typed?
Strongly or weakly? What's the numeric types? Type coersion? which
Values are truthy and which is Falsy? Can I have Higher-order
Functions? Recursion? Tail calls? Lexical closures? is they evaluated
In normal order or applicative order? Is there lazy or eager exaluation?
is arguments to functions passed by value or by reference? is they
mutable? Immutable? Persistent? What's about objects? Classes? Prototypes?
Inheritance?

I can use variables and functions in Sass, can they be lexical scopes or dynamic scopes exist?
？ Are they static or dynamic types? What is the number type? What about type casting? which are straight
What are false values? Can I use higher-order functions? What about recursion? Tail call? Lexical closures? The evaluation is in order or
Is it by application? Can I use lazy evaluation or active evaluation? Whether the function is to pass parameters by value or by reference
？ Are they mutable? Immutable? Persistent? What about the other objects? What about the class? What about prototypes? What about inheritance?

Those is not trivial questions and yet I has to know answers to them
If I want to understand Sass or less code. I already know those
Answers for JavaScript so it means that I already understand every
Internal DSL (like the inline-styles in React) on those very levels so
If I use React then I has to know only one set of answers to those
(and many similar) questions, while if I use for eg. Sass and
Handlebars then I had to know three sets of those answers and
Understand their implications.

These are not itching problems, and if I want to understand the code of Sass or less, I have to know the above
The answer to the question. I already know the answers to these questions (and many similar questions) in JavaScript
, it means that I have understood every kind of internal DSLs, but when I use for example Sass
And handlebars then I learned that three sets of answers (including JS) also have to understand their implementation.

It's not to say that one-to-one or the other-is-always-better but every
time you introduce another language to the mix then your pay some price
That may isn't being as obvious at a first glance
Complexity.

This is not to say that one way is sure to be better, but every time you introduce another language you have to spend
Price (to learn and understand it), the price may not be as obvious and complex at first.

I hope I clarified what I originally meant a little bit.

I hope I have explained the meaning of my intention more clearly.

Data binding

Two-way binding

Data binding

Two-way binding

This was a really interesting subject and in fact also a matter of
preference. Two-way is isn't always better than one-way. It's a question
of how does you want to model mutable state in your application. I always
viewed two-way bindings as a idea somewhat contrary to the principles
of functional programming but FUNCTI Onal programming is isn't the only
paradigm it works, some people prefer this kind of behavior and both
approaches s Eem to work pretty well in practice. If you ' re interested in
the details of the design decisions related to the modeling of the state
in React then watch The talk by Pete Hunt (linked-in the question)
and the talk by Tom Occhino and Jordan Walke who explain it very wel L
In my opinion.

This is a very interesting topic and is actually a matter of preference. Two-way binding is not always better than one-way binding. This
Depends on how you want to model your application's mutable state (that is, how to describe mutable states through objects)
, or modeling for mutable states). I've been thinking of two-way binding as a form of functional programming
, but functional programming is not the only paradigm that is available, and some people like this way and in practice
Able to work very well. If you are interested in understanding the design decisions behind the state modelling in React
section, it is recommended that you watch Pete Hunt's Speech and Tom
Occhina and Jordan Walke's speech, they both explained my point of view very fine
Color.

Update:see also another talk by Pete Hunt:be predictable, not correct:
Functional DOM Programming.

Update : Also look at Pete Hunt's other speech: being predictable, not
Correct:functional DOM programming.

Native vs. VMs

Native browser support (read "Guaranteed to be faster")

Native Duel VM (virtual machine)

Browser-native support (implied "ensure faster")

Now finally something, that's not a matter of opinion.

Finally, it's not part of the preference problem.

Actually here it's exactly the other around. Of course "native"
Code can is written in C + + What does think the JavaScript engines
is written in?

Well there is a similar idea, "native" code can be written in C + +, but you think
What is the JavaScript engine written in?

This paragraph is not a good translation. The author's intention is that the native support of the browser can be done in C + +, but the virtual
(JavaScript interpreters, such as V8) are also written in C + +), so you cannot
The part of the machine that is not part of the browser's native support is that it does not natively support "fast".

As a matter of fact the JavaScript engines is truly amazing in the
Optimizations that they use Today-and not only V8 any more, also
SpiderMonkey and even Chakra shines these days. And keep in mind that
With JIT compilers the code was not a native as it can possibly be
But there is also run time optimization opportunities that is simply
Impossible to does in any statically compiled code.

In fact, the performance optimizations of today's JavaScript engines are doing exceptionally well--and not just V8,
It also includes SpiderMonkey or even Chakra. To understand that with the JIT compiler, the code (execution) is not only
is a run-time optimization that is infinitely close to native and has no static compiled code.

When people think. JavaScript is slow, they usually mean JavaScript
That accesses the DOM. The DOM is slow. It is native, written in C + + and
Yet it is slow as hell because of the complexity that it have to
Implement.

What people are talking about is "JavaScript is slow," which actually refers to the DOM when it comes to accessing the DOM.
Is the truth. Even if it's native, written in C + +, it's still a slow and outrageous one because it
is very complex to implement.

Open your console and write:

Open the console (in the Browser developer tool) and execute:

Console.dir (document.createelement (' div ')); 

And see how many properties a empty div element that's not even
Attached to the DOM have to implement. These is only the first level
Properties that is "own properties" ie. Not inherited from the
Prototype chain:

Look at an empty div element (and not yet inserted into the DOM) how many properties to implement. This also
Only the first layer is the "own attribute", which does not include the inheritance from the prototype chain.

Align, onwaiting, Onvolumechange, Ontimeupdate, Onsuspend, onsubmit,onstalled, OnShow, Onselect, onseeking, onseeked, Onscroll, Onresize,onreset, Onratechange, OnProgress, onplaying, Onplay, Onpause,onmousewheel, onmouseup, onmouseover, onmouseout, Onmousemove,onmouseleave, Onmouseenter, onmousedown, Onloadstart,onloadedmetadata, Onloadeddata, onload, OnKeyUp, Onkeypress,onkeydown, Oninvalid, Oninput, onfocus, OnError, onended, Onemptied,ondurationchange, OnDrop, Ondragstart, OnDragOver, Ondragleave,ondragenter, Ondragend, Ondrag, ondblclick, Oncuechange,oncontextmenu, OnClose, OnClick, onchange, Oncanplaythrough,oncanplay, OnCancel, onblur, Onabort, spellcheck, Iscontenteditable, Contenteditable, Outertext, InnerText, AccessKey, Hidden,webkitdropzone, draggable, TabIndex, dir, translate, Lang, Title,childelementcount, Lastelementchild, Firstelementchild, children,nextelementsibling, previousElementSibling, Onwheel,onwebkitfullscreenerror, Onwebkitfullscreenchange, Onselectstart,onsearcH, Onpaste, Oncut, Oncopy, Onbeforepaste, Onbeforecut,onbeforecopy, Webkitshadowroot, DataSet, Classlist, ClassName, outerHTML, InnerHTML, ScrollHeight, ScrollWidth, Scrolltop,scrollleft, ClientHeight, ClientWidth, ClientTop,  Clientleft,offsetparent, Offsetheight, offsetwidth, OffsetTop, offsetleft,localname, prefix, NamespaceURI,ID, style, attributes, Tagname,parentelement, Textcontent, BaseURI, Ownerdocument, nextsibling,previoussibling, LastChild, FirstChild, ChildNodes, Parentnode,nodetype, NodeValue, NodeName

Many of them is actually nested objects-to see Second level (OWN)
Properties of an empty native div in your browser, see this fiddle.

Many of them are actually cascading objects--to see an empty native in the browser div
Second level (self) attribute, see this fiddle click Preview .

I mean seriously, Onvolumechange property on every single div node? Is
It a mistake? Nope, it ' s just a legacy DOM Level 0 traditional event
Model version of the event handlers "that must is supported by
All HTML elements, as both content attributes and IDL attributes "
[emphasis added] in sections 6.1.6.2 of the HTML spec by w3c-no
Around it.

Seriously, is it necessary to have each div node include onvolumechange attributes? It's a mistake.
Miss? No, it's just old. An event callback in the traditional event model in DOM level 0
, it "must be supported for all HTML elements, both as content properties and as IDL attributes" (Heavy
Section 6.1.6.2 defined in the HTML specification of the site, without
Avoid.

Meanwhile, these is the first level properties of a fake-dom div in
React:

Correspondingly, the following is a list of the first-level attributes of the pseudo DOM div element in React:

Props, _owner, _lifecyclestate, _pendingprops, _pendingcallbacks,_pendingowner

Quite a difference, isn ' t it? In fact the entire object
Serialized to JSON (LIVE DEMO), because hey actually can serialize
It to JSON as it doesn ' t contain any circular references-something
Unthinkable in the world of Native DOM (where it would just throw an
Exception):

Very different, isn't it? This is actually an entire object that is serialized as JSON (demo
click Preview ), So you can simply serialize it to JSON because it doesn't contain circular references,
which is unthinkable in the native DOM world (that throws an exception click Preview ).

{  "{},  " null, ""  unmounted ","null, "null," null}   

This is pretty much the main reason what React can be faster
than the native browser dom-because it doesn ' t has to implement
This mess.

This is the main reason why React is faster than native browser DOM--it doesn't have to implement
。

See this presentation by Steven Luscher to see what's faster:native
Dom written in C + + or a fake dom written entirely in JavaScript. It ' s
A very fair and entertaining presentation.

Look at this Steven Luscher speech and see which one is faster: in C + +
The native Dom written is also a pseudo-dom written in JavaScript. This is a very fair and joyful
Speech.

To sum it up:features from Web templates, data binding
Or custom elements'll has a lot of advantages over React but until
The Document object model itself gets significantly simplified then
Performance won't be one of them.

Concluding remarks: Webcomponenets features such as templates, data binding or custom elements will eventually have many wins.
The advantages of React, but performance is not the first unless the Document object model can be significantly simplified.

"Go" Facebook React and Web components (polymer) comparative advantages and disadvantages