Cx adds declarative data-binding, controllers and router on top of React and includes composable widgets and charts. It looks for a sweet spot between development speed and freedom to do whatever you want. Here's a quick example https://cx.codaxy.com/fiddle/?f=42vDn4I1.
Disclaimer: I'm the author of Cx.
What I need time to get around to is the concept of controllers and how it works when we want to compose things together. For example, how to write a multi-select widget that exposes a clear API to the rest of the world (onChange), and encapsulates all other details within. Cx does deserve a deeper look, and I'll definitely give it a whirl some time. Also kudos for the extensive documentation you've so far written!
Here's an example of a complex lookup field in practice. https://github.com/codaxy/cx-starter-kit/blob/master/app/rou...
It's perfectly fine to add multiple bindings between lookup options and field's data. That works for multivalue fields too.
If you have any other questions I'm happy to answer in this thread https://news.ycombinator.com/item?id=12495728
> Angular and Ember allows state and logic inside HTML.
State updates do not occur in Ember templates. Templates specify the follow data from one component to another, as well as callbacks which are names of actions defined in a javascript portion of a component, or a parent component.
But it does not allow you to specify how state is updated within the template. In terms of Logic, there's just if statements & loops which is pretty conservative imo.
edit: rephrasing words
But by logic I meant all sorts of control structures, which though looks light-weight at first, needs a large number of language elements to function. To name a few: variables, expressions (which in turn need operator precedence rules), scoping, and even composition if we count partials/templates with it. Loops on the other hand requires not just simple array iteration syntax, but also over hashes, and it also needs other constructs like filtering (`todo in todos | filter:search`).
This is my biggest complaint with adding logic to text templates; behind the apparent simplicity there is always an entire language.
All good, I'm probably tired (Australian time).
Maybe it's my inherit bias as an Ember user, but I'd argue Ember's templating language is alot simpler than you're suggesting
> But by logic I meant all sorts of control structures, which though looks light-weight at first, needs a large number of language elements to function. To name a few: variables, expressions (which in turn need operator precedence rules), scoping, and even composition if we count partials/templates with it.
Admittedly partials are a little weird, while I don't see them very often, it's still a fair point, however Ember templates don't deal with operator precedence as it doesn't have binary operators (entirely polish notation).
> Loops on the other hand requires not just simple array iteration syntax
Iteration doesn't have a blessed syntax, but instead utilises syntax that can be utilised by other components, and a better way to think of it is, the block inside the component is actually a function being passed to the component, which the component calls with every item of the collection.
> but also over hashes, and it also needs other constructs like filtering (`todo in todos | filter:search`)
It doesn't have pipes/filters, as that's easily expressed as a computed property in the js portion of a component. And I personally think scoping is pretty predictable imo.
Maybe you're just making a general remark about templates in general & i've read too far into it, then fair enough but in the case of Ember some of those don't apply, imo.
> behind the apparent simplicity there is always an entire language
Technically this is true, but I'm not sure why this matters, especially if it's trivial to learn? Because flip side of the argument, technically JSX is a different language to JS & HTML with even more complex semantics than a templating language because it carries the semantics of JS on top of it. You could make the same argument in favour of css over SASS/LESS, so I don't really see this as a big deal
SASS and LESS both add language semantics over CSS and suffer from the same problem. So does for example Jekyll's templating language. But in case of CSS, the language additions are a practical necessity - it lacks even basic abstractions, which the pre-processors provide.
So there - trade-offs.
I've written in more detail about this topic at http://www.jasimabasheer.com/posts/evolution-of-view-templat..., if you are interested.
But to contrast all three, I'll pick the area I'm most interested in - templating. The purpose of a framework is to render a dynamic view without the programmer having to wire up every state transition with a corresponding view transition. This is done by templating content with state, mediated by the framework. And how this is done affects the entire design of the framework and apps written on them.
Angular and Ember allows state and logic inside HTML. They figure out which state variables and corresponding templates go together and re-renders them automatically. The pro is that writing a modified version of HTML without too much code lets us have a dynamic app running in no time. The con is that there is a new language to study - with its own parser, control structures, scoping, and quirks.
React on the other hand lets us specify templates as Javascript functions which are run whenever the state changes. The pro is that there is no new language abstraction to learn; it re-uses Javascript. External DSLs especially are in an uncanny valley - they're not full-blown languages but have enough quirks to be bothersome. Language abstractions forces a virtual machine (the language parser/interpreter) to evaluate the code, and it is an opaquely magical layer that makes it hard to see the entire stack of abstractions during day-to-day programming. It also forces a separation between our view (written in the templating language) with the rest of our code.
The con of this approach is simply more code to write; the programmer has to anticipate and inform the framework of any state changes. With setState this isn't as bad a trade-off as we'd imagine. And MobX meanwhile brings an Angular like state abstraction to React - it watches over observables and automatically fires re-render.
The other big difference is that React is not opinionated. It is a very much a framework alright, but it for example doesn't ship with a router, nor does it prescribe a framework for organizing the code. Ember has so far done a great job here - I often wish I could combine the Ember ethos of backwards compatibility, great documentation, and a fanatic love for the existing users of the framework, with the way React approaches templating and composing components. I haven't had the chance to look at Angular 2, but for me, Angular 1 started the front-end revolution happen, and I'm curious what they have done this time.