Хорошая ли практика половину странички отрисовывать на PHP, а остальное уже рисовать с помощью шаблонов JS?

Question

[Степан]

Например боковое меню я хочу сделать как вложенный layout и не заморачиваться с его отрисовкой на JS.
А вот центральные кусочки рисовать уже с помощью JS'а, так как для разных пользователей они могут быть разные.
Ну и соответсвенно переключив на новую вкладку, отрисовать снова через PHP боковое меню и внешний layuout.
А все остальное через js в центральном блоке (причина: много расчетов небольших, анимация и галерей)
Изменения сохраняются в БД по сабмиту Ajax

Стоит ли вообще заморачиваться или все делать на PHP или же на JS

Answer 1

[Mariik]

В принципе нормально, но только для динамических участков страницы.

Answer 2

[hime2]

Асинхронная загрузка, это называется. Да нормально)

Answer 3

[Алексей Лебедев]

Плохая практика.
Нормальная:
- отрисовать все что видит пользователь на PHP.
- потом навесить все события.

Между PHP и JS пропасть по времени.

Comments

[YemSalat]

Кхм, что?.. Ответ из прошлого десятилетия?

[Степан]

YemSalat вы хотите сказать что нормальной практикой будет делать SPA? Без PHP
Вопрос в том, что layout внешний хотелось бы оставить как есть. А уже в нем сделать все на JS. Хрен с ней, в том числе и личный кабинет

[YemSalat]

xoma2: Меня в основном смутила вот эта фраза: "Между PHP и JS пропасть по времени."

Что касается спа, если у вас и так уже контент JS'ом рисуется - то почему сразу на нем все не сделать? Зачем себя самого запутывать двумя раными языками, которые делают о сути одно и то же?

[Алексей Лебедев]

YemSalat: я про отображение.
С момента дом дерева и отображения PHP и моментом выполнения JS и отображения.

[YemSalat]

Алексей Лебедев: какое это имеет отношение к вопросу?

[Алексей Лебедев]

YemSalat: прямое. После большинства советчиков этого вопроса мы получаем куча тормознутых проектов, которые кому-то удобно делать.

[YemSalat]

Алексей Лебедев: я говорю про то что лучше не смешивать.
А про то что будет быстрее работать - зависит исключительно от самого приложения. В большинстве случаев "быстрее" получается как раз таки на клиенте, потому что сервер постоянно напрягать не надо и трафика меньше расходуется (это для обоих сторон хорошо).

[IsaevDev]

Таки если у меня подгружаются товары в каталоге динамически, где их верстать предлагаете? Дергать через ajax готовые макеты? Тут товарищ из другого ответа предлагает json пересылать

[YemSalat]

IsaevDev: правильно делает.

Answer 4

[Александр Вульф]

Если по сабжу, то: такая практика достаточно популярна. Можете ее смело использовать.

В сторону: попробуйте meteor ;) И подобных вопросов не будет. Он отлично подходит для динамического отзывчивого сайта.

Answer 5

[Елизавета Борисова]

Вы можете делать как угодно, нет никаких ограничений, в рамках рабочих вариантов. Понятно, что при таком раскладе приложение не SPA в строгом смысле.

Answer 6

[IsaevDev]

Можно все готовые layout отдавать из php как переменные js. И уже js будет их выводить на экран. Мне кажется это даст бо'льшую гибкость клиентской части

Comments

[YemSalat]

IsaevDev: Зачем? Не проще сами данные отдавать, вместо готовых макетов? В чем гибкость то?

[Павел Волынцев]

Данные нужно же в какие-то макеты подставлять. Не JSON ведь пользователю показывать :( Знаю, что некоторые практикуют передавать по AJAX целые куски готового HTML.

[Алексей]

Павел Волынцев: Это боль. Зачем тогда вообще JSON использовать? Вам его всё-равно в таком случае парсить придётся перед выводом и в размере передаваемых данных только проиграете.

[IsaevDev]

YemSalat: нет, я не совсем это имел в виду. Я имел в виду, что отдельно храним в js все макеты, отдельно данные. Таким макаром можно переверстать всю страницу, вообще не обращаясь к серверу. Добавлять модули, заполнять данными и навешивать события, как товарищ из другого ответа рекомендует. Но тут мы подходим к вопросам другого порядка, так сказать. На хабре писали про дублирование логики. Надо выбрать все-таки, где макет собирать. Либо все на сервере, либо все на клиенте. Вообще от задач сильно зависит это все