Designing Around Client Logic & Patterns of Web Applications

Designing around client logic

As a web application begins to act more like a desktop application, the application needs to maintain a lot of state and logic that only pertains to the user interface (UI). It doesn’t always make sense to manage the client-only information and logic on the server, so JavaScript applications in the browser became more and more complex.

JavaScript manages the interactions a user has access to, which may be harder to model as CRUD resources and actions. Single-page application JavaScript frameworks often have a different set of actions. As a result, these frameworks have structured themselves quite differently from server-side Rails applications. For example, a primary concern of JavaScript application frameworks is to manage the state of the client’s objects and data that is interacted with, such as which items are active, and the frameworks often favor having many relatively small constructs that manage the data and logic for a small part of the page.

Therefore, a problem for many client-side app frameworks is sharing common state information among otherwise unrelated small components across the page or the app.

On the server side, sharing a common state is not a concern in the same way. A server-side Rails app stores a global state in the database. It generally doesn’t worry about the mutability of individual ...