Echo JS 0.11.0

"A great question to ask is, 'Will I need to access this variable more than once?' If so, than probably globally is the best choice."

... You're kidding right? Global is rarely the best choice, and I say that because never say never. 9999999 out of 10000000, global is not the right choice, just the easiest. You should consider learning how to leverage closures (or the modern import syntax) to better use variables in a scoped way.

Spam

The "Rule of 1" for rules ... Give at least one reason people should follow something so arbitrary and contrived.

I did not claim that JSX would survive the next big thing (I've been doing this too long to think anything will last more than a few years), you took my point out of context. Rather, the idea is that neither thing will stand the test of time, so imho it is a little safer to go with the thing that sticks closer to the native language. But trust me, only a little safer, it's mainly a comfort level thing.

And the HTML orientation is less about JSX as it is about how you approach building interfaces. Template languages make the DOM the focus, supersetting the features there and making it the focal point for triggers, updates, etc. Thinking DOM-first in engineering style leans itself to this approach. JSX makes the data itself the focus, and the DOM is a pure reflection of the data. Thinking data-first leans itself to this approach. Again ... A comfort level thing, no right or wrong, because both methods solve the problems we face.

Depends on the "us" you refer to. If "us" refers to JavaScript engineers, JSX feels very natural. If "us" refers to more HTML / CSS oriented engineers, any template syntax will likely feel more natural. In each scenario they basically operate as supersets of the knowledge base you already have.

The most important point made about the templates is that with JSX, if you know JavaScript and HTML you're 95% there without ever writing a line of it. As a JS engineer, this was a natural extension of my skills. For example, the "tricks" you describe are not JSX tricks ... those are standard operators used in ternaries and short circuits all the time. It's all about personal comfort level.

The only thing I'll say outside of that is with any DSL, there is a learning curve (big or small, still present) of something that will not translate when the inevitable porting to the new hotness comes around, since it is specific to the framework. Having performed several of those "rewire everything because the old frameworks property syntax does not align at all with the new", this greater degree of longevity is valuable to me.

Forthcoming... I wanted​ to get the core functionality out there before I started building out. The project is still super young, and my next two agenda items are math functions and benchmarks.

The name alone makes this package worth it.

I feel like this is an upgrade if replaced by just a link to the MDN documentation.

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/typeof

Is this literally just to avoid using setState in favor of seeing it directly? Cuz that kind of main will make the asynchronous setState API even less transparent to people that use this.

Based on your use of isNil, you consider null to be an invalid value, not just undefined? Is there a reason you differ from the spec?