With a system like this you choose where to decouple rather than having the boundary arbitrarily forced on you.

I've found the HTML/CSS boundary very stifling at times. I use a framework[1] that let's me define my HTML in a very DRY (don't repeat yourself) fashion. Components can be nicely defined in a single small tag, and it would be very appropriate to define some (but not all) of the styling & event handlers in the same place. Sometimes I do via style= and onclick= attributes, but those are very much second class citizens in the modern world.

In other words, I've got a much more powerful mechanism for decoupling & abstraction, so the HTML/CSS/Javascript boundaries are more harmful than helpful.

[1] http://hobocentral.net

This is what I thought. CSS for example grew so large that it often doesn't feel like the right tool anymore. That's why preprocessors like Sass, Less and Stylus are so popular. Trying to combine everything into one language is a really hard problem and I'm not sure it can be solved.

Hey there (author here), can you explain what you mean by decoupling? I'm not sure how this is any less decoupled; you can still keep everything modular in separate files/systems. You can use this to compile your CSS and still LINK it as a separate file, for example.

I agree. It's a good project to experiment but the intended goal is not practical.

The stated goal is: markup [html], style, and code in one language. However, I still have to deal with the syntax of the 3 languages, just that they are wrapped in the Javascript library calls. It doesn't help in lessen the effort in working with 3 languages. In fact, it adds complexity. Now I have to worry about how the code generated with respect to each language, another indirection. Just more trouble than it's worth.