Yes, it's like with JavaScript itself, it had some issues in the past, all the big issues were resolved but the stigma is still there.

I can't see any fundamental reason why generating the DOM with React would be faster than generating the DOM with Web Components - They're doing the same thing; it's a matter of time before they even out (if they haven't already).

I think that Web Components would end up faster ultimately due to native browser support (more room to optimise).

> JavaScript itself, it had some issues in the past, all the big issues were resolved

What about automatic semicolon insertion (ASI)? This makes it impossible to internalize how the JS implementation will interpret your code without memorizing a bunch of special cases, and makes "newline" semantically significant even if you only intend it for formatting your code.

It's never going to be fixed because of backwards compatibility. I can put up with a lot of language peculiarities, but I don't like wondering if some random "return" statement in my code is going to misbehave because of extra whitespace.

This is enough reason for me to keep looking for an ideal language.

Possibly embrace the fact that semicolons are noise, and treat JS like you would Ruby or other line oriented languages??? (ignoring the fact that JS will "look ahead" past an otherwise complete line - e.g. - return [nothing] followed by open curly brace - but Ruby for example won't)

Remember the bad old days of BASIC? You only needed that extra delimiter (colon, rather than semi) when you were going to put multiple statements on one line :-)

Yeah, minifiers are often too dumb to accept valid input text :-(

> Possibly embrace the fact that semicolons are noise, and treat JS like you would Ruby or other line oriented languages???

I'd be happy to treat JS as "statements end with a newline, not semicolon", if that were consistently true.

The paradox of Javascript: Do statements end in a semicolon, or newline? If you answer either way, you're sometimes wrong. As far as I can tell this is the only misfeature of JS that is really unfixable.

The React documentation says it so it has to be true. DOM slow, VDOM fast. Facebook is out there buying developer mindshare.

We don't claim that in React documentation. React can't be faster than the same DOM mutations written by hand because by definition it has to do more work.

We do think it helps to create maintainable apps though, and it is fast enough for practical use cases despite its immutable design. That's why we use it at Facebook.

I just haven't been able to figure out what, exactly, it is about manual DOM mutations that makes an app unmaintainable. As long as your code is organized and modular, it's always been easy enough for me to navigate through and maintain a non-React codebase.

I found these things hard:

* Inconsistencies or duplicated code between initial render and updates.

* Having to write code for N^2 transitions between N valid states instead of N valid states themselves.

* Harder to ensure DOM operation order across different parts of the codebase doesn’t produce jank.

Sure, this is all possible to solve, but in my experience I just ended up with a crappy version of React.

Seconded on all counts. We also ended up independently implementing a really simplistic and in many ways broken version of React for these reasons and many others.

Probably finding the right place of the dom to change and keeping track of what to change. React basically says "make it like this" and takes care of a lot of things.

jQuery code is well known to be hard to maintain when it changes things based on element-types, classes and id's nested in each other.

It's quite simple to handle that situation with jQuery and modules. If many parts of you code need to make a change to the DOM in the same place, you wrap the DOM changing in a module.

  var widget = require('./widget');
  widget.foo('bar');

And the widget handles the jQuery'ing for you.

  module.exports = {
    foo: function(s) { $('.widget').text(s) }
  }

Only:

- it breaks immediately if there is more than one '.widget' on the page

- your app will get out-of-sync DOM updates because different parts will flush changes to the DOM at different times (React is DOM = f(state, time), so if multiple changes happen in f, they all be flushed to DOM in one go)

In my experience it's the needed complexity added by bookkeeping and the coupling that requires to do rendering/updates and data binding using manual DOM manipulations in a performant way, especially in larger scale apps. You can easily write maintainable and simple applications that manipulate the DOM directly if you don't care about performance, or in some cases correctness, and you'll quickly do worse than React would, from what I've seen.

> Yes, it's like with JavaScript itself, it had some issues in the past, all the big issues were resolved but the stigma is still there.

Honest question, because I use Javascript just infrequently enough to have to look this up every time (and it's possible the reported solutions are old), is there a good concise universal way (or two, at most) to determine the type of the variable I may have? It seems it's always a tossup between typeof, instanceof, == null and == undefined, and to my eyes that's way too many.

As far as I know, `typeof` works on everything, but for Objects will only yield "object". You then should use `instanceof` to determine the type of object, if necessary. Typically, once I know it's an object I just use it, so that people can provide "non-traditional" but otherwise valid implementations. Only exception is if I'm specifically looking for a Date or DOM Node or other built-in type.

EDIT: Of course, I forget that arrays also have `typeof` "object"... Again, probably best to just start using length and indexing and hope for the best.

A somewhat more succinct option could be to coerce to Object and then use instanceof: 'Object(x) instanceof String'. Or you could use Object.getPrototypeOf, which coerces to Object automatically these days. But null and undefined are special: calling Object on them returns {}, and calling Object.getPrototypeOf on them throws.

If the type you're testing for is not one of the builtin literal types, you can just use instanceof.

"Object(foo) instanceof Class" does seem to be the most definitive, but unfortunately seems to require specific testing against a literal that must exist or it throws, and doesn't work for null/undefined. That at least brings the things I need to know to check the type of something down to three, two of which are singular special cases (if somewhat common ones), so that's better and possibly adequate, if not what I would consider good. Then again, I'm not sure I'm capable of thinking it could achieve good while there exists both an undefined and null in the language. It still boggles my mind that it has both.

To clarify, by "literal that must exist or it throws" you mean that you don't know whether the class you're testing for exists? Testing against an invalid class would be an error in most languages…

I guess an alternative is foo.constructor and foo.constructor.name, which will give you a string if you want that.

Since many different js libraries may be loaded from many different sources, I could envision a situation where some utility functions may want to support different inputs depending on what's passed in, and what's passed in might depend on what's loaded, and what's loaded can change at runtime.

That's why many dynamic languages allow access to the type through a string representation.

Not really. Also, typeof doesn't work at all on object literals.

Best just to see if it quacks, or barks :-)

(i.e. - does the object define a given function/"method")

except it still doesn't have support for modules in 2017.

Also, for whatever it's worth, the js could be written more concisely as

  ['Hello', 'world'].forEach( text => MyComponent
      .appendChild(document.createElement('p'))
      .appendChild(document.createElement('span'))
      .textContent = text
  )

This doesn't really help you with updates at all, only with initial mounting. In React, elements describe the current tree, and React figures out how to apply changes between the trees.

Argh. I should learn to read/comment at once, and not split replies into multiple chunks :)

> it's either careless or dishonest to compare the two without acknowledging the possibility of using a helper function or two to simplify the second one, as JavaScript developers have been doing routinely for multiple decades.

To quote from the article:

--- start quote ---

DOM APIs are horrible, cumbersome, awkward and clunky. Polymer and others are bravely trying to use DOM APIs only, but even they resort to innerHTML anywhere they don’t have to put on a show (tests, for example). When Web Components take root, the web will be flooded with less performant innerHTMLs and possibly re-implementations of snabbdoms and virtual-doms (obviously incompatible)

--- end quote ---

Again, why is the scary second half of that sentence an absolute certainty or bad? There's no law requiring use of innerHTML, and it's been easy to beat React on raw performance in many cases (to their credit, that's been getting harder but that's always a challenge for a general purpose library) — and in most cases none of that matters because you're not triggering updates fast enough to care. Ease of use and all of the other concerns are far more important for most people.

Similarly, if people are building reusable components it's not clear why using different virtualdom libraries or not using one at all is a problem. Doesn't sound software engineering practice recommend a well-defined public interface rather than deeply interconnecting them like that? Besides, this is the web: what are the odds that you wouldn't quickly hit a problem where component X depends on v1.2.3 but component Y requires v2.3.4?

> Every time I've done a test, React is significantly slower than using standard JavaScript + DOM

I'd be interested in seeing those tests.

I also curious to see how web components will be faster than simple javascript objects :)

React apps are usually built with many layers of components that returns another components. And with standard Web API, there will be significantly more DOM nodes because each component is a DOM node.

Try beating a loop where e.g. every time you get a change you do something like getElementById() + .textContent = newValue. There's no way for React to be faster than that because it has to eventually do the same work but there are many ways for it to be less code, more correct (e.g. by not forgetting to call the update in some cases), or otherwise easier to get to the point where your app can ship.

Someone has tried beating the loop. And more than a loop, but rather a more real-life-like test rendering multiple components and component trees, sets attributes etc. etc. and you can run it on your own computer in the browser

You can check it out yourself: https://localvoid.github.io/uibench/

I highly recommend the author's article about it: https://medium.com/@localvoid/how-to-win-in-web-framework-be...

Also, it seems that many people are defending WCs with an argument about interoperability. But in reality, if we start adding components that are using different frameworks, there will be problems with layout thrashing, etc, because there is no standard scheduling APIs, and each framework implements its own scheduler to batch reads and writes https://github.com/ampproject/amphtml/blob/8a76ee942f329179d...

Yes. If you're already checking for changes yourself then you've basically rewritten React.

Look at the tests for inferno, it is close to js + dom for some things and inside 2x factor for bascially everything if I remember correctly. The main thing is development speed anyway, fast enough while still easy to write and maintain code.

This example shows how cumbersome the DOM APIs and their limitations are. Also, React is not _just_ DOM diff-ing. It also provides a host of other benefits... some of which are both shown here and covered immediately in the next set of examples with Polymer's kinda-templating-language.

You cannot buy into Web Components without buying into at least Polymer to supply you with data binding.

If you don't like React's size, there are slimmer options: Inferno, Preact etc.

> You cannot buy into Web Components without buying into at least Polymer to supply you with data binding.

Why? You can use Polymer and not its data binding. In fact you can use its polyfills and deal with mostly the standard based APIs. X-Tags and many others also use Polymer's polyfills.

DOM APIs are awkward as hell. But you can create Web Components and handle the data binding yourself. It's actually pretty easy to roll your own data binding. Now whether you should is another matter.

They're not even "its polyfills", the polyfills are a completely standalone project that Polymer depends on.

If you look at the commits / maintainers to the Polymer repos and the WebComponents polyfills, you'll see that it's the same people.

Depending on your use-case you can use a variety of options for data-binding including 1) No data-binding at all (small components), or 2) An HTML-inspired data-binding solution like what Polymer provides or 3) A virtual-dom library like Preact or gasp even React

You don't have to use the DOM API for everything as in your example. JSX is very much virtualized template tags which are HTML standard.

> This gets progressively worse as your components grow in complexity. Imagine adding a span around the text in p?

In this case you simply type in the span inside the template tag similar to what you have in the React JSX and then just importNode the contents into your webcomponent.

> JSX is very much virtualized template tags which are HTML standard

Nope, it's not. It's a thin XML-like DSL which translated into Javascript calls: http://bit.ly/2nC6fdu

> You cannot buy into Web Components without buying into at least Polymer to supply you with data binding.

This is completely and utterly false. What are you basing your assertion on?

As an example, you can't even build a simple ToDo List without Polymer's weird data-binding syntax: https://github.com/PolymerLabs/todo-list/blob/master/app/ind...

So you link to the Polymer TodoMVC example to show that it uses Polymer's data-binding, and this is supposed to show... what exactly?

SkateJS's TodoMVC uses JSX[1]. Does that also imply that all Web Components need to use JSX? I don't see any logic in your claims.

[1]: https://github.com/skatejs/todomvc/blob/skatejs/examples/ska...

I don't follow this logic. Because a Polymer example shows it using Polymer's data binding therefore you "cant even build a simple ToDo list without" it? That just isn't true at all. In fact you never have to be declarative.