Cargo-Cult types notwithstanding, I think developers were mostly smart enough to interpret "separate the view from the code" to mean "separate the application logic from the presentation logic".

The problem that this project is trying to solve isn't that style and structure are too loosely coupled, but rather that declaring style in a DRY, high-level manner typically uses one language (e.g. LESS) and declaring structure in a dynamic manner often uses at least two more (HTML, JavaScript). Otherwise sane people have been known to use HTML, JavaScript, PHP, SQL, and a templating engine (and maybe another language or three for cron jobs and shell scripts).

If there's a weakness here it's that it's explicitly avoiding the concept of DSLs, which may or may not be a wise move.

We all know how to keep our model code separated from our view and controller code even though it's all written in the same language. I think maybe people are worried a bit too much about the language here.

The final HTML is just a serialization of the DOM tree structure that is built up in memory. We can build that tree by parsing chunks of HTML source and looping or substituting in values when we see special non-html tags. On the other hand, we can also build our tree using any other programming language we want.

The trick Jed is pulling here is to make the html builder code a DSL that looks a lot like HTML to make it more approachable and predictable for people.

I'm not saying that it's a bad idea. But for the longest time web designers refused learning to code. They wanted to edit their html in dreamwaver, and it was up to the coder to make that possible. When you look at modern web apps, they are very code-centric. Good luck editing that page in dreamweaver. I never found the separation of html and code very useful and welcome this movement. But it feels like we wasted so much time just because the frontenders where afraid of anything resembling code.