Early UI frameworks

In 2012 I built a client-side framework for an administrative standards compliance application. Web-based applications were becoming ever more complex and encountering problems at scale when using traditional development patterns. Template-driven PHP could become a maintenance problem, the UX was difficult to change, and style and state management were less than ideal.

The current architecture of the app consisted of a RESful API that returned HTML. Request a summary page, and you get the markup for a summary page. Changing it required changing the API. The style needed knowing what the HTML was before you got it, then writing endless CSS, or Less, or whatever. To improve, several things first happened.

The API was refactored to return JSON data. No more HTML in an HTTP response. With that, we could now consider state management, global and consistent style, and improved UX. Client-side frameworks were becoming a viable pattern, but they weren't there yet. AngularJS existed, but it wasn't suitable for the project. The specific needs and desire for simplicity led to choosing Backbone and underscore (in the form of lodash) as the basis for the UI.

React hadn't been invented yet, so we had to figure it out ourselves. Backbone is a great platform, but it isn't a usable framework by itself. It was, however, a tool for building frameworks. While Marionette did exist, it posed the same problems as AngularJS, i.e., 2-way data flow, heavy-handed data binding, dependency injection, and an event system that could quickly get out of hand.

The goal became a better way of handling data flow and a callback pattern similar to jQuery instead of event listeners. This is personal preference. At the time, I favored callbacks, promises were not a thing, and events required an event broker to keep them understandable and maintainable.

The entire framework came together surprisingly quickly and worked well at scale. An unintended benefit was testing. Separating markup and data on the back end simplified testing on the front end. However, it was proprietary code, and when React came along, it looked so much like what was happening with the Backbone-based system that I deprecated it and turned to React.