Great work.<p>However: while I feel this cartoon (and other Flux introductions I've seen) capture well the concepts behind Flux, none of them make up for the amount of boilerplate and just over-the-top abstractness (IMO) that goes into actually implementing vanilla Flux.<p>To me that is the biggest problem to make it easier for people to adopt it, not understanding the concept.
This is a real good introduction, but I wouldn't call it a cartoon.<p>It's a big text with many drawings.<p>Everytime I read the title I think "wow super easy panels and stuff" but then I see the wall of text.
There is a following guide to Redux and its differences to Flux at the end of the article[0]. Great explanation!<p>[0] <a href="https://code-cartoons.com/a-cartoon-intro-to-redux-3afb775501a6#.vj6gsyqo5" rel="nofollow">https://code-cartoons.com/a-cartoon-intro-to-redux-3afb77550...</a>
This is probably the best introduction to Flux I have read. I think people (in general) respond better to visual representations of complex processes- and this visual story nails it.
For those who like visual representations, but a bit more technical: <a href="http://danmaz74.me/2015/07/27/flux-architecture-visual-cheatsheet/" rel="nofollow">http://danmaz74.me/2015/07/27/flux-architecture-visual-cheat...</a>
Neat cartoon. It helped me understand Flux a little bit better.<p>In step #4 (Once it’s done changing state, the store lets its subscribed view controllers know), why can't the child views just subscribe directly to the stores and remove the view controller as a middle man?
I really like the way the author anthropomorphizes the pieces of the flux architecture here. I am in the middle of writing a saltstack tutorial and wonder if I should do the same.