О да, на PHP - JSON'овские API, на каком нибудь там React'е - фронтенд. По мне так ужас, но с достаточно сложными и сильно посещаемыми сайтами - единственный нормальный выход.
объясните мне, зачем нужны реакты, вебиксы и прочие ангуляры, когда есть jQuery? вебморду к железяке с использованием этих вот написать дольше, чем руками на js
Смотря насколько сложная веб-морда. Я за весь свой опыт разработки (почти 10 лет) ни разу не видел кода на jQuery в состоянии, пригодном для поддержки. Потому что когда ставится задача «хочу после сабмита формы, чтобы попап-окно оставалось все равно открытым, сохранялись фильтры таблицы, сортировка, а,да, и вот этот переключатель должен быть включенным, а еще покажи мне индикатор загрузки», то ВСЕГДА код с jQuery-лапшой превращается в кал, который сопровождать невозможно. Да, логично при сабмите формы делать аякс-запрос, тогда, казалось бы, проблема решится, но нет, потому таких форм может быть много, а часть их полей тоже подгружается аяксом. Код сайтов на jQuery всегда оставляет желать лучшего. Особенно, когда на сайте много кнопок, формочек, окошек, фильтров и прочих интерактивных элементов.
Также если твой сайт на jQuery, то отдать фронтенд-разрабам весь фронтенд в работу очень запарно, потому что так или иначе им все равно придется возиться с кодом бэкенда, прописывать data-атрибуты и т.п. html-элементам - это неудобно. А если ты пилишь сайта на Angular/React/Vue, то у тебя фронтенд связан с бэкендом только интерфейсом API - и все.
А CRM на jQuery пробовал сделать? Если нет, то попробуй. А потом попробуй на Angular/React/Vue - поймешь разницу.
Кодится в два счета что? Говнобложик из пары страниц - возможно. Тестами такое покрыть сможешь? Замокать запросы к базе и т.п.? А так фреймворки очень сильно сокращают количество кода и сил, затраченных на разработку. Многие из разрабов них не знают и не используют шаблоны проектирования, и их код потом невозможно поддерживать или хотя бы тестами покрывать. Фреймворк им дает каркас, в рамках которого они могут писать более-менее структурированный код на любимом пэхапэ. Лучше будут пусть загнаны в рамки фреймворка, чем будут писать код, от которого из глаз будет потом кровь идти.
P.s. Тем более, что если микрофреймворки типа php slim, которые тебя ни в какие рамки не загоняют.
на php и так все в два счета кодится, нахрена загонять себя в рамки фреймворка?
Потому что там уже есть шаблонизатор и структура, продуманная опытными разработчиками. Не единственно возможная, но для начинающего ОП возможно это самый полезный совет.
MVC — не торговая марка имхо. Тот подход, что разделяет друг от друга модель, представление, контроллер — и есть MVC, по сути своей, как бы это ни было задекларировано.
А, я понял, что ему надо! Движки шаблонов, типа, Smarty (теплый, старый, ламповый) или Twig (как бы стандарт в наше время). Вот примеры - https://www.smarty.net/crash_course и http://zetcode.com/php/twig/ А мы тут ему про JS driven technologies толкуем... :D
В моём фреймворке при сборке шаблон компилируется в функцию. Из шаблона "foo <%= @user %>", например, получается функция с примерно таким телом (псевдокод):
В преимущества помимо скорости рендеринга (у тебя, например, для каждой подстановки str_replace проходит целиком весь текст шаблона) входит поддержка выражений, управляющих структур (условий/циклов), также данное решение не подвержено XSS.
Только Гугл, и то такие сайты он индексирует хуже обычных. Поэтому SSR лучше юзать. К тому же без этого, скорее всего, всякие шарилки в соцсети не будут нормально работать (но это уже не точно).
А как же не переусложнение тогда? Отдавать html с сервера средствами laravel/django, а на фронте разводить jquery-лапшу? Не сказал бы, что это чем-то лучше. Тем более, что ssr для React-сайта прикручивается подключением NextJS и запуском одного js-файла - это ж просто.
В моём фреймворке при сборке шаблон компилируется в функцию
в твоем — это который ты используешь или который ты написал?
В преимущества помимо скорости рендеринга (у тебя, например, для каждой подстановки str_replace проходит целиком весь текст шаблона) входит поддержка выражений, управляющих структур (условий/циклов)
я не имел в виду что нужно делать как у меня написано, я хотел показать что можно выполняя код на php сформировать html-код для отдачи клиенту на основании данных шаблонов, фазы луны, данных из БД. PHP затем и придумали. Не обязательно делать сто раз str_replace, я просто показал самый простой и очевидный способ разделить представление и модель. Вы так буквально поняли, как маленькие.
то что ты показал — вариация на тему, что я и пытался доказать (по-другому ты не сделаешь), а именно берем данные шаблона и БД и формируем код. Имхо, изобретать на шаблонизаторе html шаблонизатор html в то время как и первый хорошо шаблонизирует html — неверно.
// другой вариант действительно есть — это вот эти вот ваши реакты и на сервере оставить только json-api. но тут, имхо, и ПХП не нужен
также данное решение не подвержено XSS.
даже то, которое я предложил, не подвержено если
1) не позволять попадать в заменяющие переменные данным пользователя (в ряде случаев — более чем)
2) в пыхе были какие-то функции (но я уж позабыл их имена) через которые строго рекомендуется пропускать пользовательские данные перед выводом в выхлоп специально от этого вот. Учат этому на первом курсе ПэХаПэ-шного училища
правильны путь — это не пользоваться фреймворками, которые не только не позволяют стрелять по ногам, но и работать (алсо, утежеляя и усложняя все в сто раз), а научить людей писать прогаммы, вместо допуска гуманитариев к программированию.
ЛОР вон на фреймверке написан или где? щас проверим атаку: <script>alert('LOR — шерето!')</script> гляди-ка — не работает...
Отдавать html с сервера средствами laravel/django, а на фронте разводить jquery-лапшу
а тебе какая разница разводить jquery-лапшу или react-лапшу? нешто на реакте можно сдалать короче? что может быть короче, чем $('#buttonId').click(function(){ $('#panelId').hide(); }); ?
А вот и не привет. Темплейт закачался с харда — вредоностного кода там нет (темплейт писал автор сайта), вместо маркера подставляется захардкоженный текст — там тоже, как видишь, нет эксплойта
Для пользовательского — есть функции экранирования. Опять же, можно подумать, в этих ваших фреймворках не так.