In SC there has been a long standing habit of referring to true or false as YES and NO. While it might seem to be a "simple" issue, in my mind having YES and NO doesn't really add anything, also not in readability.
Moreover, replacing with true or false might be a way to increase the performance a (very little) bit.
In a simple node.js test, I found that a million comparisons of true === true, is about 3 ms faster than YES === YES.
I cannot really estimate the amount of comparisons done in a typical SC app, whether the effect in real life is larger or smaller, or whether this effect is optimized away by the JS engines, but I would expect that having to look up the variable will always add a tiny bit of time.
Edit: small clarifications
Run a test on file size after compression both ways.
Speed is probably not the key factor in this discussion, he observed dryly.
If it takes 300,000 runs in order to gain a thousandth of a second, then this change won't contribute significantly or meaningfully or in any way at all to the speed of the platform. YES or NO will have to be invoked 300 million times for each second that we've cumulatively spent discussing this in order to break even.
I'd like to see size numbers, but I suspect that the difference there will be inconsequentially in the YES/NO direction. (Happy to be proven wrong of course!)
Benchmarks are great but the numbers we're talking about here are a little silly.
Assuming that speed and size are inconsequentially affected (and in opposite directions) by this change, then I would say that style, personality and ease-of-adoption become the important considerations. Do we love YES/NO? (I'm a fan, but not a huge one.) Is it a notably SC "thing"? (I think it helps stylistically to emphasize that SC requires serious programming, not quick and dirty web page scripting.) Is it a barrier to adoption for new developers? Ya probably.
I'm going to close this one, but for your information I'm going to move away from using YES/NO, at least publicly. @dcporter made the comment "Is it a barrier to adoption for new developers?" and even if the answer to that question is only slightly "yes", I'd still rather not risk it since there is no hard benefit to YES/NO.
Rhetorical question: if we were really concerned about the file size difference, wouldn't we define 'Y' & 'N' instead?
Fixes documentation of SC.FOCUS_ALL_CONTROLS and removes long depreca…