Wholeheartedly agreed! The design of the fetch API has some really retarded points, such as 4xx, 5xx errors returning as Resolved promises, how JSON parsing is handled, etc. Axios and Superagent are much better choices by comparison.

The charts are awesome. Thanks for sharing!

Nice work! The animations are neat too.

Oh Mother of God... We just started using Redux!!! LOL #FML

It depends on the critical nature of the action being performed. It is a balance between UX vs. need for accuracy. "non-critical" recommend => Instant UI Update: Completely Optimistic Likes, shares, feed actions, etc are examples of instances where the UI can be optimistically updated. In the event of a failure the user can be notified and the UI can be updated (if the user is still in the app...) to reflect the state of the backend system. In a few instances the updates might fail, and the user may or may not see the follow-up notification, but it's generally okay because the action being performed wasn't really that important. A few misses in a million transaction is acceptable. "critical systems" recommended => Updating: Partially pessimistic Cash transfers, submitting taxes, checking for an airline flight , are a few examples of places where an optimistic update is generally a terrible idea because a false positive can be very consequential to the user. Even if only a few users are exposed to inaccurate successful confirmations in a high volume system, the negative impact to those users are potentially very significant . As an example, a customer misses a flight because the airline website UI said they were checked-in, when they really weren't, - the UI updated optimistically, but the backend transaction failed. In that instance, they would have a right to be really unhappy, and report a poor user experience. What if you correct the 'optimistic' UI update with the real system status seconds later? There is no guarantee that a user will still be using the app or webpage in the event the UI is subsequently updated with a failure notification after the actually response is processed, so a chance will always exist that the optimistic and possibly inaccurate response is all the user sees. So the safe choice here would be to display an "Updating" indicator to the user, and then change the UI to "confirm" the change when a response is received from the backend indicating that the action the requested was actually carried out (successfully or otherwise). The user is happy and trust in the system is maintained.

MVC is easier to write initially. However, Redux/Flux is easier to reason-about, debug, maintain, and enhance. Programmers less of ( 1 ), and more of ( 2 ).

Yep!

I'd say "no". Why? Premature optimization ( http://c2.com/cgi/wiki?PrematureOptimization ). Consider fictional a application called Amazoon , where the "database" was the slowest piece of the app , e.g. registering a new user or searching inventory was taking ~2 mins per query. Changing the "View" layer from HTML to Angular, React, or <insert latest view-engine here> will have a minimal impact at best simply because the bottleneck is elsewhere... Your shiny new "rectified" Amazoon app will go from 2 mins and 20 secs per query (old app), to 2 mins and 15 secs (v2.0 <- still lame, boo!). Bad approach, bad results. Alternatively, If Bill was really smart, he would first benchmark his application and application components (app layer, view-layer, db-layer, caching, etc). Identify "what" part of the system was the slowest. And then fix "that" piece. Repeat starting with Step 1! Ps. I love "React" so Bill still gets points for his fix. ;-)