http://www.ractivejs.org/ (also currently on the front page) uses a pattern that reduces friction while keeping responsibilities where they belong, i.e. HTML for markup and JS for interactivity.
I can't see any way that writing a verbose json format that is just pseudo-html is a solution instead of being another layer of problem on top of the original. Also the argument against selectors is nonsensical unless we're suggesting that xpath is wrong. The only reason selectors are for styling is because that is the approach taken by browsers and so you are tunnel visioned into believing that is the case. They are not "for" styling, they are selectors use "by" styling. I similarly don't see what drawing parallels to C has anything to do with it.
I'd also like to point out that in a good portion of JS projects HTML and JS have a symbiotic relationship so the notion that you have to scrub out all the HTML as "best practice" is entirely incorrect in my eyes, thus the failing/winning example makes no sense without context. Is that HTML pre-baked into the page by the server? Then it makes complete sense to be that way. Are you hand generating it from strings? Not ideal, but there are tons of far more elegant ways to solve that already and they don't require you to still be writing HTML in your JS (even if it looks like JSON it still has a single purpose and is wedged directly into your code).
At least existing templating solutions call out to external templates in locations where the HTML "should be".
Sad to say but it doesn't add much value and it makes certain tasks harder even. For instance it makes it very hard (or almost impossible) to use that same html templates on the backend and on the frontend side of things.
when everyone is trying to do the opposite (remove js from your html so that both are mean, see angularjs and similar), this one is extraordinary. I believe it has a fundamental flaw though. If someone is comfortable with this level of js, then she wouldn't bother probably having them inter-mixed. On the other hand for those who don't like a high doze js in their lives, this looks even scarier. So I think, it is not a niche but a deserting island market segment to aim for.
Still, who am i to judge, all the luck to the maintainers
I don't think that's quite how it works. I took a quick look at the code and it doesn't contain any DOM selectors at all. It uses closures and getters and setters.
We don't have the same problem then. Personally what I hate when I include HTML in my JS is that if I want to include/exlude an attribute/node/text based on a condition/variable, it become a big huge and ugly. This make it a little bit prettier.
No. It's obfuscating HTML with a JS wrapper.
http://www.ractivejs.org/ (also currently on the front page) uses a pattern that reduces friction while keeping responsibilities where they belong, i.e. HTML for markup and JS for interactivity.