Still early days for Flux, but the principles are sound and I hope it offers a viable alternative to all these framework that rely mainly on variants of the MVC pattern.
For another overview, see this article:
http://blog.andrewray.me/reactjs-for-stupid-people/
Please don't take offence at the title, I didn't write it :D
There are some frameworks using some form of the Flux spec like Fluxxor and Reflux, but they're not opinionated or complete enough to hit the ground running.
The author of Fluxxor, for example, is himself working out where to put very basic functionality like network service calls.
In the react-router project, there's not an obvious way to either render from server or refetch data on route changes.
This is all very basic functionality for a medium to large project. It will feel like you're in the weeds after a couple of days of development.
We need a Flux++ framework with some stronger opinions, closer to Ember or Angular in scope.
About Mithril, HTML generation with JavaScript is an odd design choice. Obviously it's much better from a technical point of view, but nested or complex HTML must get ugly fast, and I really don't want to deal with template code written by non-developers. Having said that, for a certain class of apps with high performance requirements and comprehensive browser support, Mithril is a very appealing option.
That's the problem JSX solves - nesting tags and attributes is less syntactically onerous than managing a tree of function calls or nested object structures, with their attendant braces and commas.
Here's the Mithril getting started example [1] done using JSX [2], for comparison (some of the other code has changed since I did this, but the rendering part looks the same)
[1] http://lhorie.github.io/mithril/getting-started.html#summary [2] https://github.com/insin/msx/blob/master/test/jsx/example.js...
The verbose parts have nothing to do with the data-binding. The dependency injection is there for testability (https://docs.angularjs.org/guide/unit-testing), you have to use array notation because JS changes variable names upon minification. The rest is just objects being used to set up options.
Fix the minifiers.
Most minifiers have a switch for that. E.g. UglifyJS2's is "-m"/"--mangle". YUI Compressor's is "--nomunge".
By the way, this stuff looks a lot nicer with AngularDart or Angular 2.x.
(disclaimer: I come from Backbone, where we did all data and event binding by hand)
Stuff like ng-model-options="{ updateOn: 'blur' }" is far from straightforward. I guess you could do ng-model-options="model.modelOptions" and define the behavior in the controller, but then your controller would be handling far more than it should. By the way, wouldn't a separate directive be more appropriate for this? ng-update-on="blur" is more palatable.
And in my experience with Angular, it's never just "assign a value to a scope and done", except for the most trivial situations. When you leave these behind, you have to think about scope hierarchies. You have to watch your watchers. When you use something like angular-translate, you have to carefully consider synchronicity issues and the performance drawbacks of each way to bind your models. And so on. I love the power and flexibility that Angular gives you, but I wish there was a simpler way for it to do its magic.
Yes, a prerequisite to using a JavaScript framework is understanding prototypical inheritance
>You have to watch your watchers
What?
>I wish there was a simpler way for it to do its magic.
To date I haven't seen a coherent argument against Angular; complaints seem focused around having to learn framework specific syntax (present in any large MVC framework) or the perceived "heaviness" of the framework (suggesting the apps you're building aren't complex enough to justify something like Angular)
Obviously, but you shouldn't have to care about prototypical inheritance for simple databinding. The way view-models work in Angular leads to some complicated scenarios which, in my opinion, shouldn't exist in the first place (http://toddmotto.com/all-about-angulars-emit-broadcast-on-pu...).
> What?
See https://medium.com/@kentcdodds/counting-angularjs-watchers-1... for an explanation.
> To date I haven't seen a coherent argument against Angular; complaints seem focused around having to learn framework specific syntax (present in any large MVC framework) or the perceived "heaviness" of the framework (suggesting the apps you're building aren't complex enough to justify something like Angular)
I have no problem with learning framework specific syntax and Angular is actually lightweight, both from an architecture and from a code weight point of view. What I do find problematic in Angular are some design decisions which often lead to complicated, and non-beautiful, code. Angular is no doubt incredibly useful, even for smaller apps, and I'm grateful for its existence. It is a step in the right direction. But I do think it has room for improvement.