The javascript ecosystem is anything but consistent. Lately it seems like it churns out a “next big thing” library every couple months. Alright, so maybe that’s an exaggeration, but it definitely feels that way sometimes.

Stepping back and taking a look at it, the reason behind so many iterations probably indicates that we have yet to “solve” the Single Page App (SPA) architecture. In my opinion, that’s something to be excited about! We get to watch the evolution of big part of our industry evolve as it takes important steps towards an ideal architecture. It’s also the perfect time to be a part of something big! No wonder so many new libraries are popping up.

A bold prediction

I’m going to level with you. I’m not the type of person to make definitive statements about the evolution of software architecture. Frankly, I just don’t think I’m qualified. I am, however, comfortable making a prediction:

Backbone is here to stay!

Just kidding.

Flux is here to stay!

Just like Object-Relational Mapping (ORM) is the standard for integrating models in MVC, I think the Flux pattern is going to be the standard for integrating state management in SPA architecture. I’m sure there will be many versions of it. Some with improvements, some with opinions baked into it, I’m looking at you Redux. Ultimately, I think the underlying principles are here to stay and you’ll continue to see it used with new Javascript libraries.

So let’s talk about some of the principles behind the Flux pattern and why they are valuable.

One-Way Data Binding

I remember first learning the concept of two way data binding and think it was so obviously the best idea to come out in a long time. If the data changes from the back, load the new data for the user. If the user changes the data in the interface, send it back to the store. This was one of those theory vs practical application predicaments. The theory behind two way data binding was great, but the application of it left something to be desired. This was further realized when Angular 2 appeared on the scene and moved to one-way binding.

For anyone that used AngularJS to develop a bigger application, it became very evident that maintaining the state of data was, for lack of a better term, a shit show. Abstracting to services worked, sort of, but overall the state of state management (pun intended) was lacking a consistent standard.

Clones are unethical!

Just like our data has one source in our database (excluding replication) it’s important to maintain one record of data on the front-end. Making changes to data that exists in more than one location can create undesirable outcomes. Which one is accurate? Perhap both? Perhaps neither? This is particularly true in an asynchronous environment.

Actions are events and more!

Actions allow us to create reusable application logic that can be tied to both browser events and other pieces of application logic. A user clicks the logout button? Dispatch the logout action. An API returns a response you weren’t predicting? Dispatch the same logout action and be guaranteed the same results. It’s clean, effective, and DRY.

Reducers are reliable, events aren’t

Reducers create predictable and reliable data outcomes for unpredictable events. UIs are crazy! You never know what to expect. Directly tying events from the UI to our data is just irresponsible. With reducers, you can always expect the same outcome for a dispatched action.

Testing (Wah Wah Waaaah)

To some this won’t matter but with Flux, unit testing is easy. If you’ve ever attempted unit testing in Angular, you’ll know why this is valuable. Making unit tests easy to write is key to getting people to actually write unit tests. Better test coverage gives us better software.

Adoption

A key factor in the potential success of Flux is the fact that it is framework agnostic. It’s not tied to React, or Vue, or any other libraries. So as we move through the inevitable iterations of javascript framework libraries, Flux can still be used. We’ve already seen the adoption of Flux in the two latest frameworks React and Vue. I’m predicting that the next generation of SPA frameworks will continue to either integrate their own iteration of Flux or provide bindings for existing iterations, such as Redux.

Conclusion

Do I think Flux is the precipice of state management for SPAs? Likely not. It does, however, provide us with solutions to many of the primary problems we’ve uncovered through the trial and error development of SPA architecture.

Of course, the comment section for this post will remain open so that anyone reading this may feel free to come back a year from now and drop a big fat WRONG in the comments. Upon which time I’ll make another bold prediction about the future of the web stack.

Javascript will be replaced with Python! Just kidding … sort of.

Thanks for reading!