Javascript – Does react.js make sense for a static content-driven site

First of all; I'd put some question marks on that 1% figure. How did they measure this in the first place? Most usage statistics are collected client-side, using (drum roll) javascript. Disabling javascript completely means you're not counting those users. Furthermore, most of the script-aware users use things like NoScript, which is far more sophisticated than a simple "turn all javascript off"; instead, there's a whitelist, a blacklist, and a per-case decision for the gray area. I use NoScript myself, and more often than not, I only allow those scripts on a site that it needs to function, while Analytics and other tracking sites are tossed on the blacklist. So I probably count as "javascript enabled", even though I default to "javascript off", and serving me something that looks broken until I enable Javascript makes a bad impression - enough to make me close the page within a second unless I know it has what I need.

But let's assume the 1% figure is accurate. The fact that some users browse scriptlessly isn't your biggest concern. You should also consider the following:

• Accessibility. While you can write accessible javascript, it is very hard to get it right, and you need to test on a wide array of user agents and configurations. If, however, your site is written in clear semantic HTML and functions well without Javascript enabled, it is typically easy to get accessibility right.
• SEO. Most search engine spiders don't execute Javascript, and if they do, they don't typically go all the way. So basically all content that you generate or pull in using Javascript is invisible to search engines.
• Integration with third-party tools. One of the great things about HTML is that it is a well-defined, standardized textual data format. Thousands of tools can process it to perform all sorts of tasks, and the ability to transform and accumulate your content adds value to your site. If you rely on javascript to display it, most of these tools will break.
• Security. While Javascript is not inherently insecure, moving application logic to the client has important security consequences, and it's easy to overlook issues.
• Mobile devices. Not all smartphones have the processing power to run your javascript as smoothly as you'd need it; many mobile browsers don't even support the full feature set of a desktop browser's javascript engine; and the very nature of the device (small screen, limited input devices, touch screen rather than a mouse) may break quite a few javascript / DOM features you might take for granted.

I'm going to make an argument for ==

Douglas Crockford which you cited is known for his many and often very useful opinions. While I'm with Crockford in this particular case it's worth mentioning it is not the only opinion. There are others like language creator Brendan Eich who don't see the big problem with ==. The argument goes a little like the following:

JavaScript is a behaviorally* typed language. Things are treated based on what they can do and not their actual type. This is why you can call an array's .map method on a NodeList or on a jQuery selection set. It's also why you can do 3 - "5" and get something meaningful back - because "5" can act like a number.

When you perform a == equality you are comparing the contents of a variable rather than its type. Here are some cases where this is useful:

• Reading a number from the user - read the .value of an input element in the DOM? No problem! You don't have to start casting it or worrying about its type - you can == it right away to numbers and get something meaningful back.
• Need to check for the "existence" of a declared variable? - you can == null it since behaviorally null represents there is nothing there and undefined doesn't have anything there either.
• Need to check if you got meaningful input from a user? - check if the input is false with the == argument, it will treat cases the user has entered nothing or just white-space for you which is probably what you need.

Let's look at Crockford's examples and explain them behaviorally:

'' == '0'           // got input from user vs. didn't get input - so false
0 == ''             // number representing empty and string representing empty - so true
0 == '0'            // these both behave as the number 0 when added to numbers - so true    
false == 'false'    // false vs got input from user which is truthy - so false
false == '0'        // both can substitute for 0 as numbers - so again true

false == undefined  // having nothing is not the same as having a false value - so false
false == null       // having empty is not the same as having a false value - so false
null == undefined   // both don't represent a value - so true

' \t\r\n ' == 0     // didn't get meaningful input from user vs falsey number - true 

Basically, == is designed to work based on how primitives behave in JavaScript, not based on what they are. While I don't personally agree with this point of view there is definitely merit in doing it - especially if you take this paradigm of treating types based on behavior language-wide.

^{* some might prefer the name structural typing which is more common but there is a difference - not really interested in discussing the difference here.}