It might be better to have runtime system load code dynamically when necessary, without programmer to care about this, e.g. on first invocation, maybe pre-loading it based on call statistics from previous app runs. People implement this already (I tried this too - https://github.com/avodonosov/pocl)
I've never quite understood Flux, partly due to all the cruft & boilerplate involved around Actions & Action Creators.
I've found a Command Bus pattern (a la CQRS) works much nicer, and cleaner.
1. Something happens in View (e.g. todo item is checked)
2. View passes a "CompleteTodoItemCommand" object to the Command Bus
3. Command Bus dispatches the Command to a registered Handler
4. Handler communicates with server, store etc. to handle the command; handing TodoItem to the store
5. Store triggers change event
6. View hears change event, renders self
That said, I've only built a few smaller projects in React, so perhaps I'm missing something important which Flux solves and I'm missing?
That's exactly how we build our Flux apps. We follow, roughly, the Flux naming patterns -- your "bus" is the dispatcher, "handler" is the store's dispatch handler, everything else is the same -- but we left out the action creator thingies and instead direct actions directly to stores and let them do the data state management.
We're also using Prince, love it. We've previously used PdfCrowd and wkthml2pdf, but our customers were demanding more control of their reports (detailed footers, repeating headers, table of contents).
