> 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.