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).
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.
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 :-(
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.
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.
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.
var widget = require('./widget');
widget.foo('bar');
module.exports = {
foo: function(s) { $('.widget').text(s) }
}- 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)
* 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.
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.
If the type you're testing for is not one of the builtin literal types, you can just use instanceof.
I guess an alternative is foo.constructor and foo.constructor.name, which will give you a string if you want that.
That's why many dynamic languages allow access to the type through a string representation.
Best just to see if it quacks, or barks :-)
(i.e. - does the object define a given function/"method")
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.