Domain State vs. UI State

When my company was a lot younger with a less mature team, I remember having the best time with Meteor because I could write Isomorphic code and everything just worked. I didn’t think about performance, nor was I concerned about clean code, I was trying to build features as quickly as possible. It wasn’t until we hired some really experienced people, from companies that have scaled applications to millions, that we started to evaluate the complexity of isomorphic code. There is so much state that exists in modern applications these days. As our designs and UX ambitions increase, the state of our client side applications increase. As data and analytics become more important, the state from our domain/database/server increases. As full-stack developers, how do we manage this complexity? I think there exists a fine line between the Client and Server. After some horror stories with client/server performance in isomorphic states, our solution was to separate these states and provide clean public APIs to manage both of them independently.

But what is STATE?

Engineers throw the word “State” around like everybody understands exactly what you’re talking about. With the proliferation of JavaScript for rich client side applications this word gets muddled. State is a description of the attributes, configurations, or quantitative features of your application at the current…