Re: Для каких целей использовать JavaScript, а для каких PHP? PHP vs SPA vs статические сайты

@Maks

В современном вебе оба везде используются, так что оба необходимы, не надо выбирать :grinning:

Есть Single Page App’ы типа Инстаграма и этого форума, где много JS, но это не значит, что мало серверной части, ей тоже постоянно шлются запросы.
И сделано это не из-за слабости сервера, а по другим причинам типа удобства пользователя.

Из плюсов связанных с производительностью в SPA: быстрая загрузка, может быть (при долгом использовании) пользователь потратит меньше трафика потому что в запросах в основном возвращается только сам контент в JSON, а не вся HTML страница с кучей повторов в каждом запросе.

Основной минус SPA: сложнее разрабатывать и тестировать. Ну и возможны проблемы с SEO, ссылками и фичами браузера типа истории, “Назад” и т.п., но это решаемо.

С классическим сайтом всё просто — получил запрос, проверил, достал данные из БД, сгенерировал и вернул HTML. Об остальном позаботится браузер. А с SPA надо думать еще о куче других вещей, безопасности (что можно и что нельзя делать на клиенте), разбираться с фреймворками типа React/Vue/Angular, думать как писать автоматические тесты для клиентской части.

Поэтому лучше не делать это, если нет необходимости )

Начинайте с обычных сайтов с классической серверной частью и немного JS на клиенте для удобства, например, валидация данных форм (но на сервере она тоже нужна!), перезагрузка чего-нибудь (комменты к блогопосту, …) без обновления всей страницы.

если для слабых серверов - то JS, для оптимизации на стороне клиента - PHP

Скорее не “слабых”, а “без PHP”.
Есть хостинги для статических сайтов типа GitHub Pages, Netlify.
Для сайтов-визиток, блогов неплохо и бесплатно/дешево. (для не статики вроде бы практически нет нормальных бесплатных хостингов, разве что бесплатный план Heroku, если мало посетителей, например, учебные проекты, демо)

Например, многие используют Jekyll для генерации блогов.


Если нужны комменты к постам — сервисы типа Disqus, JustComments, комменты из issue гитхаба.
Ну то есть по сути использование чужой серверной части с PHP и т.п. Совсем без нее никак, потому что нужно где-то хранить комменты (и сразу динамически добавлять при отправке новых), юзеров, нужна аутентификация/авторизация, валидация (чтоб не было уязвимостей типа XSS), анти-спам и т.д.

Вот еще статья про некоторые сервисы и идеи, которые могут помочь обойтись без своей серверной части:

4 лайка

Спасибо за отличное объяснение, Алексей. Давно таких ответов не было. :slight_smile:
У меня теперь возник другой вопрос: PHP или Node JS? PHP как то родней.

Ну это холиварный вопрос, на него сложно дать четкий ответ. Можно еще Ruby и Django (Python) добавить :partyparrot:

Все давно используются и нормально работают. Для каких-то ситуаций есть какие-то преимущества, но в целом везде всё можно. Например, Node.js вроде лучше/удобнее когда много асинхронного взаимодействия, вебсокеты и т.д. А в Руби хорошая экосистема (подходы, библиотеки, фреймворки) и все оттуда тащат идеи (например, Laravel в PHP).

РНР самый популярный, но большинство проектов основаны на CMS типа Вордпресса (плагины, темы к нему, настройка/администрирование), что не всегда интересно и может замедлить развитие.

Один из минусов PHP: там много плохого наследия типа изначальной заточенности под пихание кода и HTML в один файл, “супер-глобальные” переменные и т.д. Так что надо не сидеть на всем этом долго, а брать всякие современные штуки и учиться хорошему. Composer (менеджер зависимостей), PhpCodeSniffer (линтер), Docker, фреймворк типа Laravel (там хорошая оф. документация + Laracasts).

2 лайка

Алексей, а можно JS и PHP использовать по отдельности? Например PHP. Не будет ли что то страдать, например скорость загрузки страницы?

Непонятный вопрос. Они ж и так по отдельности. О чем именно речь?

Я ж выше написал для чего используется клиентский JS и для чего PHP (или другие серверные варианты: Node.JS, Ruby, …).

Классический пример использования клиентского JS на простом сайте: проверять корректность введенного поля формы сразу при вводе, чтобы не заставлять человека нажимать кнопку “Отправить”, ждать перезагрузки страницы. При этом на сервере всё равно должна быть аналогичная или более полная проверка, иначе можно просто отключить JS в браузере или отправить HTTP запрос не через браузер.
Тут дело больше в удобстве пользователя, а не только в скорости перезагрузки страницы, она обычно и так достаточно быстрая (разве что сильно плохое качество соединения), но пользователь узнает об ошибках не сразу при вводе.

Или всякие другие мелочи типа кнопки “Цитата” на многих форумах, которая вставляет выделенный текст в форму ответа. Это на сервере никак не сделать, потому что сервер не может знать о выделении текста в данный момент и т.д.


ЗЫ не все Алексы являются Алексеями :smiley:

2 лайка

Алекс он и есть Алекс. :slight_smile:
К вышесказаному добавлю, клиенткий JS очень удобен для красивой визуализации каких нибудь эффектов.
Например сравнение товаров в магазине. Наводишь указатель например на изображение бутылочки, а она оп и шевельнулась. Как будто приглашает к диалогу. :slight_smile:
Один из подобных примеров: Шаблон сравнения товаров

Нельзя. На клиенте в браузере только JS. На Вашем сервере - на Ваш выбор. Без динамики на клиенте только простенькие сайты, выдающие постоянное содержимое, иначе производительность сервера будет сильно страдать. Плюс задержка при передаче данных по сети.

А чего серверу? Ему и клиентский JS постоянно запросы шлет на многих сайтах.
Основная причина все-таки невозможность сделать на сервере многое + неудобство пользователя, в т.ч. и из-за задержки.
Если бы только в производительности сервера дело было, то просто бы покупали сервера мощнее, придумали бы как кэшировать и т.д. Это проще, чем клиента программировать.

Так клиентов обычно много. Одно дело получить данные, другое - куча обработки, та же графика быстро сожрет все мощности. Серьезное кеширование все равно потребует полноценного ЯП на стороне клиента, тут разницы в сложности никакой нет.

Так графику там и не сделать )
Разве что как видео/сервисы для “облачного гейминга”, но там и с задержкой проблемы, особенно если соединение не идеальное.