Как клиенту объяснить отличие SSR от обычного классического сайта html + php?
Сам я прекрасно понимаю в чем разница SSR приложений и о бычных сайтов где сервер генерирует html страницу посредством php и шаблонизатором. Но как объяснить эту разницу?
Первая ситуация: Обычная html верстка и на бэкэнде какая-нибудь cms либо php фреймворк.
Вторая ситуация: Есть backend. Есть фронтэнд написанный с помощью vuejs или react на основе той же верстки + nuxt либо next для SSR и с бэкэндом уже обмен происходит посредством api.
По итогу и в том случае генерация на стороне сервера и в другом случае. Но как объяснить в чем отличие и почему второй вариант стоит дороже?
Лично мне показалось что второй вариант пошустрее работает.
Но как объяснить в чем отличие и почему второй вариант стоит дороже?
Покупателю лучше объяснять не техническими характеристиками, а тем, как это влияет на него и его бизнес.
Иначе будет "если нет разницы, то зачем платить больше".
Например можно охарактеризовать это так:
1. Такой сайт легче поддерживать, по тому любые доработки будут внедряться быстрее (а значит дешевле, при почасовой оплате + меньше time to market)
2. У такого сайта лучше UX, а это значит лучше конверсия (тут стоит дать ссылку на какое-нибудь исследование)
Обязательно учитывайте специфику бизнеса клиента. Иногда плохой UX наоборот лучше, чем хороший.
Дмитрий, это если не использовать ssr. если использовать голый реакт или vue то url останется без изменений. а если использовать роуктинг то все нормально будет с url.
Василий Банников, у реакта UX лучше? Чем? Мой код на чистом JS быстрее любой реализации React'а в 10 раз минимум. Переплюнуть в рядовых задачах нормальный "PHP код + хорошую верстку + VanillaJS" будет просто не возможно. А преимущества React'а таковы:
Проще расширяется, так как проще ориентироваться, хоть React и не фреймворк
Легко допиливается другим React / Node разрабом
Скорость расширения фронта из-за реюзабельных компонентов, но спорно, так как я в чистом JS делаю похожий на React структурный подход
Все остальные плюсы надуманы, ибо нормальный JS код будет в 100-1000000 раз легче/чище и быстрей. А PHP вообще заточен под шаблонизацию HTML, так что тут вообще все хорошо, особенно без тяжелых фреймворков. Я молчу про простоту хостинга этого всего. Любой мамкин прогер поставит из одного места в другое такую APP-ку. Если проект делается для посещений до 10000/день без особо сложной логики, то в Node на бэк не оправдан. Если проект делается для SEO, то React не подходит или не идеально подходит при условии прямых рук Front-end Developer'а
да. если через апи то весомый довод в ту сторону что можно без вмешатеьство в основной проект поменят шкуру до неузнаваемости. в тз только дать список api и описание работы блоков. и можно иметь один бэкэнд но тиражироваьт продукт за счет изменения фронтэнда.
DevMan, а бэкэнд то может не отдаваться клиенту. а быть размещенным на сервере владельца продукта и выдаваться за определенную плату по подписке. а шкуру предоставлять клиенту и размещать на их сервере.
DevMan, фильтруй базар. деточку у себя между ног увидешь когда будешь ее поливать ряженкой чтоб вырасла. Зачем оскорблять то? И формулируй правильно вопросы. Какой еще штат? что именно смутило в моем вопросе и ради чего ты в него полез если не можешь врубиться в грамотно составленное сообщение направленное на сайт с целью получить мнение хороших специалистов, готовых делиться опытом.
Слава, мало того, в качестве морды, когда через API делается, может быть и веб-приложение (сайт) и мобильное приложение. Здесь уже начинается прямая экономия, если клиент ориентирован на создание и того и другого. Тоже довод.
