Двухсторонний шаблонизатор?

Question

[Кирилл Несмеянов]

Господа хорошие, задам довольно необычный вопрос. Подскажете ли вы, есть ли на свете белом шаблонизатор, который умеет исполняться и на стороне сервера (PHP или Ruby, хотя если что-то подобное есть в других вариациях — тоже будет замечательно) и на стороне клиента? В идеале — с возможностью восстановления исходного варианта после «компиляции» (но это мечты)



Если не понятно зачем, объясняю. Есть у нас шаблон на сервере (все мы знаем — смарти, xsl, blade, haml, slim, jade и прочее), обрабатываем его и отправляем клиенту результат. Клиент получает html код и радуется. А теперь добавим немного аякса. В идеале — мы отловили тег «a» и ссылку «href», сделали запрос на сервер — получили новый шаблон и json данные для его заполнения. Вставили куда надо данные, показали пользователю и подменили url через history api.



Если совместить эти два варианта — можно получить следующую картину: Открываем страницу — получили статику, переходим по страницам — грузим их динамически, добавив сюда кеширование шаблонов (ну например в localStorage\IndexedDb\WebSQl и проч.) — получаем идеальную ситуацию, когда имеем полностью асинхронный ресурс и при этом ни шаблоны, ни контроллеры (сервера) совершенно никак не надо под это дело подстраивать. Вот как-то так, надеюсь доступно объяснил.



По поводу «восстановления после сборки» — небольшой каприз — делать так, что бы уже первая загрузка статичного варианта позволяла JS коду понять шаблон и его закешировать, и при взаимодействии с ним (новый комментарий добавляем, плюсуем рейтинг, переходим по страницам — не важно что) — можем сразу же работать с уже существующими данными.

Answer 1

[Сергей Протько]

Twig имеет реализацию на js

Comments

[Кирилл Несмеянов]

О, великолепно, это уже мне намного больше нравится! Думаю пока именно на этом можно остановиться.

Answer 2

[_ _]

Дело в том, что вы старательно пытаетесь игнорировать тот факт, что в требованиях пришли к single page application на JS. И пробуете найти какой-то подход, который оставит вас в рамках текущей парадигмы разработки.
А решения уже придуманы давно и их очень много, можно выбирать на любой вкус. И все он заключаются в том, что на сервере шаблонизации нет вообще - там только данные.
Все взаимодействие с фронтом через REST API.

Единственное, что может вызвать проблему в этом случае - индексация такого приложения браузером. Но и тут есть решение, требующее минимального вмешательства в код сервера - вы просто делаете снэпшоты страницы, требующих индексации, например с помощью PhantomJS, после чего отдаете их как статику с сервера при запросе от бота.

Comments

[Кирилл Несмеянов]

Я старательно пытаюсь поведать требования, которые исходили из возможности индексации страницы, что я и сообщил в вопросе (может немного иносказательно). То что это ria - очевидно, иначеб и вопроса подобного не возникало. Просто в результате я пришёл к идее, вместо разделения статики (с помощью указанного вами выше PhantomJS, например, или серверного шаблона) и клиентского (Knockout, Angluar, etc...) - просто их совместить в одном движке. А то что данные приходят из JSON ответа от сервера или из контроллера - волновать особо не должно. Данные они и в Африке данные.

Answer 3

[Николай Васильчук]

XSLT можно рендерить и на сервере и на клиенте.
Но в вашем случае проще всё отображать на клиенте, а с сервера присылать только layout страницы и данные в json.

Comments

[Кирилл Несмеянов]

А что будем говорить Яндексу, Бингу, Яху и прочим? Гугл вроде как умеет с js\ajax работать =)

з.ы. кстати да, пока писал про xslt — подумал «а вдруг». Так что да, это может вполне подойти, надо будет посмотреть, спасибо большое.

[Сергей Протько]

гугл так же не умеет работать с js как и все остальные. Гугл совместо с яндексом и бингом просто придумали стандарт, позволяющий реализовать индексацию одностраничных динамических сайтов.

можете ознакомиться. Этот подход используют все крупные поисковые системы на данный момент.

[Кирилл Несмеянов]

м? habrahabr.ru/post/158845/

[Сергей Протько]

собственно то же что я и говорил. Снапшоты всеравно отдает сервер, и этот способ уже поддерживает bing и yandex.

[Сергей Протько]

или вам именно для этих целей и нужно?

[Кирилл Несмеянов]

На ресурсе происходит редзайн, вместе с этим решили переписать фронт-энд. Основная цель всего этого мероприятия, помимо более вменяемого кода — уменьшить траффик, который забивает канал хостинга, проблема пока только в поисковиках и в пользователях без js. По этому ищу наиболее вменяемое и простое решение для этой проблемы.

Answer 4

[Константин Китманов]

mustache имеет реализации на нескольких языках.

Answer 5

[egorinsk]

Шаблоны перенести недостаточно, вам еще придется переносить модели и частично бизнес-логику на клиент (если только у вас не примитивный сайтик на 3 странички). На мой взгляд, избежать двойной работы можно лишь используя технологии вроде node.js: в этом случае можно часть кода с логикой сделать разделяемой для клиента и сервера.

Ну или еще есть вариант, как-то настроить кодогенерацию и генерировать JS-модельки на основе серверного кода.

Comments

[Кирилл Несмеянов]

Ну на счёт моделек и контроллеров — это да. Кодогенерация — плохое решение всегда (если конечно это не специально заточенный DSL). Только контроллеры в любом случае будут отличаться — всё же логика разная — одно — просто передача данных и обработка гет\пост событий — другое — обработка пользовательских событий, анимашки всякие, финтифлюшки и прочее, общее — только указание аргументов шаблону. Чисто теоретически — от клиентских моделей при таком подходе — тоже можно отказаться — передавать данные сразу в контроллер, пусть это и повышение объёма загружаемых json данных за счёт дублирования повторяющихся данных, да и сам подход, прямо скажем — не очень, но уменьшение объёма работ и гарантированная актуализация данных. А если заиспользовать вебсокеты, то разницы практически не будет заметно, что 5 килобайт, что 10. В общем это довольно спорный вопрос — единственное что действительно будет дублироваться — это роуты.

Answer 6

[Кирилл Несмеянов]

<deleted> (промахнулся веткой)

Answer 7

[Максим Дьяченко]

Сейчас плотно курим такой подход:
Вьювы с помощью простых классов генерируют простой хтмл через ДОМ.
Этот код не содержит оформления, а только контент, более менее семантично оформленный.
Для оформления используется CSS и JS
Я знаю что все так делают, но я имею ввиду ВСЁ оформление выносить туда.
Примерно вот так:
jsfiddle.net/x8mmC/

На выходе имеем стройный хтмл, который является очень даже семантичным, достаточно красиво выглядит и без оформления, понимается поисковиками, и заметно меньше по размеру.
Со стороны вьюва мы имеем обычный ооп код, который можно так или иначе наследовать, расширять, инкапсулировать и т.п.
Если интерфейс достаточно продуман, то верстальщику вполне достаточно будет не трогать хтмл а обходиться жс. (см пример).

Всё вышеописаное в принципе у нас работает, хоть и не до конца отлажено.
Но вот что еще хочется сделать — по аяксу отдавать не новую страницу, а ее разницу в сравнении с текущей.
т.е. некий DOMdiff или в виде jquery (как стиль в примере) или в более сжатом виде — не важно.
НО пока до этого не доходят руки. Надо для начала формализовать первую часть, переписать все классы на чистовик и т.п.

Comments

[Кирилл Несмеянов]

Но вот что еще хочется сделать — по аяксу отдавать не новую страницу, а ее разницу в сравнении с текущей.

Слышал о таком вот ru.cloudflare.com/railgun правда технология немного не для того заточена

[Сергей Протько]

По поводу передачи diff-ов страниц, как по мне это лишнее. Проще с сервера отдавать только данные и рендрить на клиенте.

[_ _]

А какая цель преследуется применением такого.. кхм.. подхода?

Answer 8

[Антон]

Лично не пробовал, но недавно видел ссылку на статью, где, судя по описанию, решают вашу проблему:
www.phpied.com/server-side-react-with-php/
www.phpied.com/server-side-react-with-php-part-2/
Правда, насколько я понял, там идет обертка в php для JS-движка.

Comments

[Вячеслав Слинько]

Это не универсальный ответ — там только про реакт.
А так-то да, реакт шикарен.

Answer 9

[Максим Барулин]

у себя пользую smarty + jsrender.