In regards to templates: yes - there are drastically different ways to do templating. Enlive style templates are plain HTML files and clojure transformation fun

In regards to templates: yes - there are drastically different ways to do templating. Enlive style templates are plain HTML files and clojure transformation functions, hiccup style are clojure data structures that mimic html structure and render to html and there are the placeholder template languages involving intermixing a crippled language and HTML (Django templates, Ruby's ERB, etc). It would be business suicide to demand all your web designers learn clojure edn syntax in order to write out HTML in hiccup. They have work to do and they are experts with their existing tools, including quite complex IDEs. If the html is being generated programmatically by clojure devs then hiccup type formats are extremely efficient. String building techniques suck worse for HTML than they do for SQL. By far the most common types of template languages are the placeholder type. People love them. I hate them, moustache/ctemplate style templates are an excellent attempt to remove logic from them but why not just go all the way towards an enlive style if you recognize this benefit? I'm not the right person to defend them but the general argument is that designers can learn the crippled DSL easily and they can implement the simple parts of the template logic themselves. Moustache style templates are also useful if you are templating something like plain text that doesn't have structure. And yes, I absolutely think that the single library to do HTML escaping with extremely paranoid defaults is the right solution. But a security person is going to be nervous that developers will not use it every place they should and unless I'm remembering incorrectly the request was for this to be integrated into the templating library to remove that error path. I'm not even sure how that could work properly outside of the placeholder paradigm (it has been done well in Haskell using types to track escaped/unescaped segments if memory serves). In regards to frameworks: I think you are right about this position, I just really very much disagree that there "must be some way of unifying this in clojure" outside of an opinionated framework. The problem is the lack of ability to enforce a specific dataflow / data transformations that can be audited for security and generally applied. Enforcing a specific dataflow is the definition of a framework IMHO. I fully agree with his push for more and better web security related libraries (I'm tired of doing these things myself but don't have the security expertise to create general solutions that anyone should trust) but some of it struck me as "if we just limit the expressive power of clojure for web development we can mitigate a large swath of security issues". He's absolutely right, but I have found that tradeoff to be a very poor one to choose outside of the simplest of CRUD apps.