I wouldn't choose the same words as the author. Perhaps I would say this instead: "... it’s just that the layering of the three is no longer pre-ordained by the

I wouldn't choose the same words as the author. Perhaps I would say this instead: "... it’s just that the layering of the three is no longer pre-ordained by the framework." Here's my take. Om's "application state" (only data) corresponds to the data part of the model ("M") in most MVC frameworks. In Om, just like ClojureScript or Clojure, you use functions, organized however you like, to work with data. This means that the "action-oriented" part of a traditional MVC model (e.g. methods in OO) are not necessarily grouped with the model data. Perhaps this is what the author is getting at: you can "layer" (organize) your functions into whatever namespaces you like. In in my recent experience building Om apps, I've found that organization matters. As an Om app grows in size, it is natural (and important) to find ways of organizing that help. Om does not impose any particular organization scheme. I personally find ClojureScript namespaces to be very easy to work with; I simply split up a codebase as files become larger and harder to summarize.