From an architectural point of view, the main difference is that Facebook’s Flux implementation provides one central dispatcher, while nanoflux supports also multiple dispatchers (if needed). Given that flexibility, it is possible to link multiple stores and multiple dispatchers, but IMHO this would only be a preferable scenario for really large applications. Additionally, it is also possible (as a built in feature) to link stores easily, so they can notify each other on changes (chaining).
For more comfort, nanoflux supports a ‘fluxy’ way, which means, that a dispatcher provides actions directly without the need of a dedicated ActionProvider. This can be quite handy in less complex applications and reduces much of boilerplate code. Of course, nanoflux supports the original concept with separated ActionProvider.
The verbosity may be one of the ‘weakest’ aspects of Facebook’s Flux: this is due to the fact, that Facebook provides the Dispatcher only, where the mapping has to be established entirely through the implementer, which turns in verbose code. Facebook Flux does not offer any Store and/or an ActionProvider helpers, which turns the implementation in a very lightweight one, too; even smaller than nanoflux. One of the nanoflux features is it’s convention based automapping for actions and store functions. In this point nanoflux offers slightly less flexibility with its a pure functional approach only - at least regarding the action-dispatcher-store-binding - but is much more comfortable. On the other hand, the developer gains with Facebook Flux more liberty on implementation decisions. For example, it is left to the developer how stores and actions may interoperate, p.e. common approaches base on event emitters.
nanoflux is a really tiny and also fast implementation, as the following chart depicts. Obviously, the reference implementation from Facebook is slightly superior, but as mentioned above it offers much less comfort than nanoflux.
Currently, all performance measuring is done server side using nodejs. I think it is slightly slower than Facebooks implementation,
as nanoflux uses a comfortable auto-binding, without verbose switch-case-statements like the Facebook version. Nevertheless, it should be fast enough :)
Note: Nanoflux Fusion maintains immutable states, therefore it’s runtime performance is implicitely worse than any implementation dealing with mutable states.