Język szablonów dla renderowania po stronie klienta i serwera

Badam szablony JavaScript jako sposób na renderowanie naszych widoków. Celem jest możliwość renderowania po stronie klienta dla użytkowników, którzy mają włączoną obsługę JavaScript, aby renderować te same szablony / dane po stronie serwera dla tych użytkowników (i robotów indeksujących), którzy tego nie robią.

Wymagania

1. renderowanie po stronie klienta.
2. renderowanie po stronie serwera (JVM obsługuje nice-to-have).
3. rozsądne wsparcie dla pętli, warunkowych, manipulacji tekstem, częściowych, makr i rozszerzenia / wtyczki.
4. dość duża / aktywna społeczność użytkowników.

Dotychczas znalezione niezadowalające rozwiązania

1. Mustache: obsługuje renderowanie po stronie serwera i klienta, dużą / aktywną społeczność, ale szablony "bez logiki" wydają się bardzo restrykcyjne i bolesne.
2. węzeł.js plus podkreślenie : szablony JS, takie jak podkreślenie, zapewniają całą elastyczność szablonu, której potrzebuję, ale renderują je po stronie serwera za pomocą węzła.js jest bardzo kruche. węzeł.js jest nowy i dość niestabilny, a jego zarządzanie pakietami (eksport...) wymaga wielu hacków, aby wszystko działało prawidłowo.
3. Szablony zamknięcia Google : te kompilują się do JS i Javy i mają wiele funkcji, których chcę. Niestety, przeglądanie Google groups wygląda na to, że brakuje wielu podstawowych funkcji (takich jak możliwość pętli nad tablicami asocjacyjnymi ), a dokumentacja do tworzenia własnych wtyczek jest bardzo rzadka i bolesne spojrzenie. Co więcej, nie mogę powiedzieć, kto w społeczności internetowej go używa, Google nie akceptuje wkładów open source i nie ma przepustowości, aby udostępniać nowe funkcje.
4. isotope: zapisywanie szablonów w JS i używanie Johnson, wrappera Ruby dla środowiska wykonawczego Mozilla SpiderMonkey JS, do renderowania tych szablonów po stronie serwera. Wydaje się obiecujące, ale projekt nie miał zobowiązań od ponad 6 miesięcy.
5. płyn z ciecz.js: płynny język szablonów wygląda wspaniale, ale płyn.js project wydaje się być nietestowany (brak testów w IE!), nie posiada dokumentacji, nie jest jasne, czy ktoś z niej korzysta, a od jakiegoś czasu nie był aktualizowany.