I was thinking today about how most modern web frameworks go to great lengths to shield the framework user from SQL and database-specifics and then don't apply the same logic to the presentation layer. "SQL strings embedded in my code are ugly" they say, but then turn around and embed code in HTML (or vice versa), which is equally ugly.

Here's my take: if you use a DSL to write SQL, then you should use a DSL to write HTML, for all the same reasons. If you write raw HTML with programming code embedded in it, then you ought to write raw SQL.

"My designer won't understand a DSL" you argue. Maybe. I'll also bet that your DBA won't understand your HLL database expressions either. Worse I'll bet that unless you use a toy database like MySQL or SQLite you are giving up a ton of speed and power in favor of an abstraction that you then throw away on the other end (the presentation layer).

I guess I don't think that one approach is the Right Thing, but I do think that mixing them and then trying to defend one position or the other is wildly inconsistent and demonstrates that maybe you haven't thought it through too thoroughly (I'm guilty here as well, using a DSL on the presentation layer then preferring raw SQL on the backend).