separation of concerns is a bunch of bull
A couple days ago I was booking myself some air travel. I finished filling out all the forms and submitted my payment info and finally it dropped me on the confirmation page. The confirmation itself was tiny, and the rest of the page was taken up by hotel offers, several of which were stupid expensive for non-business travel. Most were in the $100s, but one was $239. The full header text on the hotel module read, “only $239 more per night” and that 1) seemed like a fucking nonsense way to describe $239, and 2) got me thinking about templates.
I don’t know how the travel site does their templates. Probably on the server, since that’s the way most sites still do them. It doesn’t really matter, though, whether it’s client-side or server-side. There’s an opportunity to not say “only $239″ and instead say “on sale for $239″ or “a hell of a deal for $239″ or something that sounds slightly less ridiculous and emphasizes that the hotel’s best feature is not its price but like the twice-daily full-body massage and salt scrub you better get for $239. However, to do something like that would mean introducing extra logic. Not logic about data, like is this price part of a sale that will expire halfway through the user’s stay, or is this hotel also right by a convention center, but logic about how the data is displayed. So I can kind of sympathize with whoever did not put something like that into the template for the hotel module, because that particular grey area gives me fits.
As part of trying to push client-side templates down everyone’s throat at my last job, I started relying heavily on the concept of a view model – an additional layer between the template and its data that prepares all that data to be rendered. And I loathed the sort of things I was creating properties for in the view model, things like the plural form of words or what text to display if some array of objects was empty. Mostly, I loathed the fact that no matter how many fucking view model properties you create, at some point, if you want to keep your HTML in your HTML, you’re going to have to put logic in there and that’s just that. I loathed the feeling that trying to do a sincere and thorough job of “separating concerns” was tantamount to pushing a big damn boulder up a steep hill.
I have been doing this computer science shit for a long-ass time. I studied it in school for four years. I cannot think of any real world system I’ve seen in that time that achieves perfect separation of concerns. I posit that the reason for that is that separation of concerns is bullshit.
Hundreds of years ago, our superstitious ancestors would tell their willful offspring stories about monsters and demons to try and trick them into behaving in a way that an admonishment to be careful alone would not. Separation of concerns, I think, serves much the same role for developers. As a concept, it keeps us in line and without that principle our code, collectively, would without question be much more fucked. For the most part, we stick as close as we can to the protection separation of concerns offers us from the giant scary “these concerns are not separate” boogeyman who lives in the forest. But, y’all, there is no concerns-not-separate boogeyman. There is only trying hard to write nice code, or not.
Back to templates. If you count all the client-side templating engines you know of, I bet you run out of fingers. Most of them do the same thing, so why are there so goddamned many? I blame the separation of concerns mythology. Everybody wants a damn logicless templating system and as far as I can tell, no one has managed to invent one or will ever manage to invent one. The ones that describe themselves as logicless continue to have basic operators that perform logical tasks. The ones that do nothing but plug in properties or the output of functions merely necessitate the offloading of all the logic to an additional view model, and since they can’t function without that piece of the equation, I’d say they still fail to be logicless. HTML is your logicless templating engine. As soon as you begin adding dynamic information, you can kiss logicless goodbye, because logic is where dynamic pieces of a display come from.
I’m not saying that you can’t abstract every piece of display logic out into a view model. You absolutely can, and I will totally come bring you flowers in the nuthouse when you get all done with that. But you don’t change anything in doing so. One argument people like to make is that removing logic makes it possible for non-developer designers to work with the HTML, which is – sorry guys – horseshit. If your designer understands the best practices of good HTML, if he or she can do the necessary pattern matching and visualization, he or she can grasp what is template syntax and what is not and move those bits around and not break them, etc. If he or she does not, you’re going to be adding the dynamic data after they put their HTML together in Dreamweaver anyway.
There are a few template solutions that try to get around this problem by avoiding template syntax altogether and just using existing attributes of HTML. As far as I’m concerned, that’s the same damn thing, just as fragile and problematic, only with the additional penalty of having all the template infrastructure continue to exist in the final rendered product. If your designer can fuck up a template tag, they can fuck up a CSS class or data attribute.
So here’s the thing. The concerns that we work so hard to separate are intrinsically linked. It’s not impossible to abstract them away from each other, but they still maintain some awareness of each other. The view – the HTML – cannot be separated from the data in contains. It’s not an empty vessel that can be filled with anything, it’s marked up to have semantic meaning and an appearance that increases the utility of the data displayed. You show me a completely dumb view and I will show you an interface that fucking sucks. There should be logic in HTML, if the HTML isn’t static. It should react to its contents and show different things in different ways. When the changes are big, hell yes, create different templates and let the controller determine which to display. But I firmly believe that, when you get down to things like replacing the word “only” with something that makes more sense, trying to achieve perfect granularity is going to make you crazy and offer very little payoff.
Something that is “only” $239 is not a different type of object than something that is “on sale for” $239. It’s not in a different state. It’s stored in the same table in some database. The same type of object carries it around on the backend adding properties to it. It’s delivered to the client with the same JSON structure. It’s displayed using the same markup and the same styling. The only difference is a couple of words, words that don’t affect the data, that have been pulled out specifically for the purposes of display. Why not let the fucking template handle that? There are plenty of other places that logic could go, but ultimately it’s a view model or the view itself. I’m tired of adding tiny little things like that to view models, or worse, creating view models specifically for them.
Separation of concerns is a fantasy. It’s a very useful fantasy that guides us to produce better code, but like all fantasies it’s still fundamentally bullshit. From now on, when the only reason someone can give me for doing something or not doing something is, “But separation of concerns.. !” I’m going to start calling that what it is.
June 27th, 2011 at 3:09 am
Separation of concerns is not just for a designer not to mess up your logic, it also allows you to keep the output under control. Otherwise, you can not maintain structure in your own application. Some developers will decide that some logic should be in a template but others will try to come up with a view model in a similar scenario. In the end, considering you have hundreds of views and thousands of partials, you will have difficulty understanding how that output is generated and will need to trace the whole stack of files that may have been involved to clearly see how. Yes, there may be (and always are) cases that it would be simply ridiculous to try to avoid using logic inside templates but these cases can be strictly defined by a convention.
June 27th, 2011 at 12:07 pm
@Ege – I agree with you except for that last part. I think those things that straddle the line between obvious candidates for some kind of view model/transformation layer and so negligible and presentation-related as to be clearly most useful in the view itself are edge cases, and if we could create conventions for edge cases they wouldn’t be edge cases. Which is why I say that separation of concerns is a useful guideline and should be treated as such – not a hard and fast rule, and certainly not as a reason to do something absent any other reasons.
June 27th, 2011 at 6:31 pm
[...] better than paralysis. I don’t seem to be alone in this characteristic. Take for example this post that is arguing, albeit in an extremely conflicted way, that the concept of Separation of Concerns [...]
July 4th, 2011 at 7:37 pm
Boy do I hear you on this. Working with hardened double decade vets of programming makes this even worse, where solutions are frankly ruined in favor of dogma. I agree that it’s SUPER helpful as a guideline, but like any art, sometimes the best results come from breaking and bending the rules.
I think a system that was created by those following, to reasonable limits, separation of concerns will actually benefit from deviation when such deviations are convenient, comprehensible, efficient, and most importantly, consistent. I think consistency is of equal concern, if not more, than separation of concerns. Reason being that the only reason standards exist is to enforce/suggest exactly that – consistency.
July 9th, 2011 at 3:26 pm
Well said, but I think your argument isn’t with separation of concerns; it’s with dogma. Backend developers suffer from the same thing with respect to the sacred cow that is design patterns. Developers often obsess over designing architectures according to these patterns which, as you hinted at, is backwards.
Patterns are meant to give us a common language to talk about architectures, not a rulebook to follow when creating them. Great developers don’t focus on patterns, they focus on designing great architectures. Patterns emerge as a logical consequence. If you’re constantly fighting against your paradigm or architecture in order to get something done (provided you’re competent), then said paradigm / architecture is ill-suited to the task, no matter what best practices others may preach.
That said, I don’t know if I’m willing to throw the baby out with the bath water just yet. Maybe there’s another way to look at it.
I think of there being tiers within tiers (within tears?
). In the context of the overarching application architecture (i.e. MVC), yes, HTML is the *view* layer. However, if you separate out the front end, you have 3 things: HTML, CSS and JavaScript. Maybe I’m comparing apples to oranges here, but think about it: you have CSS, which is obviously the view layer. By design, it is impossible for CSS to contain any logic whatsoever. Even with something like Sass, it’s minimal at best. Of the two remaining tiers, I think HTML matches up most closely to the model layer: it provides data and structure to your document. This leaves JavaScript as the controller, managing user interaction.
Since the model layer has the most important (and consequently the most complex) job in the stack, it only stands to reason that HTML, its analog, would be in the same position.
As with most abstractions, this one has its leaks, but I dunno, seems like a starting point. A complex, nuanced content model is still one of the hardest problems in web design, and it’s probably not going to go away quickly or without effort.
I think you’re right, though: we *do* need more logic in the templates, not less. In fact, the idea of separation of tiers says nothing about having *no* logic in templates, only that we should keep it to *view* logic. The trouble is, we have neither the mental model nor the grammar express it well. I suspect this is because we’re looking at the whole thing upside-down.
March 3rd, 2012 at 1:51 pm
[...] already said on this blog what I think of rabid focus on separation of concerns, but there are plenty of other opinions, almost all just as strongly held. There’s a belief [...]