!Magic

The view layer in web app frameworks is broken. Every framework has a template language, and every template language has the same flaw: views contain both structure and logic. This flaw annoys me as a developer, and here's why.

Let me start by making the distinction between structure and logic. Structure defines what makes up the view. Logic defines how data goes into the view. Break the view down and it consists of nothing more than some arbitrary structure populated with data. Remove the data and you're left with an empty structure.

In most cases the data to be presented is dynamic. So, instead of hardcoding data in the view, logic is added to describe how the structure will be populated with data. In today's template languages, this view logic is mixed in with the view structure itself.

For example, in Rails, an ERB template contains an HTML structure along with Ruby code that is responsible for adding data to the structure. The result is a view that, prior to rendering, contains both structure and logic. Structure and logic are closely related, but they also serve two very different purposes. Putting them in the same place leads to some real problems.

First, this causes development roles to become unclear. View structure is a design concern and view logic is a programming concern. When they're combined, the roles of designer and programmer become fuzzy. The front-end designer's responsibility is to create the view structure, since structure is very much tied to the look and feel of an app. On the other hand, view logic is the responsibility of the back-end programmer. A designer shouldn't have to understand or even think about view logic when creating the view; it's a separate concern. Yet when placed together in the view, structure and logic can't be thought of as independent things.

This is an issue even in a team without clearly defined designer/programmer roles. And really it's for the same reason. Combining two separate concerns in the view muddies the water no matter how large or small a team is.

Once logic is added to structure, one can't take a step back to see the unadulterated version of the view. Structure essentially becomes lost. This means the designer really has nothing to own, creating a process that isn't very designer-friendly. Problems also come up when it comes to changing existing views.

Without the ability to separate logic from structure it's impossible to refactor either one in isolation. They are so intertwined that when a change must be made, there is no other option than to change both at the same time. This makes the refactoring process much more complicated and error prone than it needs to be. Separating concerns is an important part of the refactoring process and it simply isn't possible with a view layer that consists of both structure and logic.

How is any of this a good idea?

Solving these problems is possible, and is actually pretty simple ¹. It requires separating concerns by removing view logic from view structure, allowing a view to remain purely structural. View logic becomes a separate layer that acts on the view structure from outside of it. This is the approach taken in designing the Pakyow web framework, and separating structure and logic has enabled us to solve all of the problems discussed here. In addition, Pakyow developers are at least 42% less likely to be annoyed. It'll change your life.

This is simply an introduction to the concept of separating view logic and view structure. The implementation details will be the topic of a future post. If you have any comments or would like to discuss this post feel free to send me an email or find me on Twitter.