Echo JS 0.11.0

<~>

planttheidea comments

planttheidea 396 days ago. link 1 point
The "Rule of 1" for rules ... Give at least one reason people should follow something so arbitrary and contrived.
planttheidea 399 days ago. link 1 point
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.
planttheidea 399 days ago. link 1 point
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.
planttheidea 413 days ago. link 1 point
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.
planttheidea 419 days ago. link 2 points
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.
planttheidea 428 days ago. link 1 point
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?
planttheidea 429 days ago. link 3 points
Why? Other than self righteous claims that it is better, there is no actual comparison. Add to that the return to object-oriented, internal-state-driven data management, the implicit magic, plus the indignation of the author, and we have at best a new Backbone. Which the community has moved on from.

You're right, I'm not getting the point, because you're not making one. You may have made a cool thing, but everyone will dismiss it if you immediately make claims of it's impending dominance.
[more]