Как стать автором
Обновить

Комментарии 23

Inertia давно должна была помереть, но вместо этого она рожает ЭТО...

Если честно, статья вызывает гораздо больше вопросов, чем ответов)

Выглядит как очередная попытка изобрести велосипед. При этом излишне сложная. Вместо того чтобы упростить взаимодействие между фронтендом и бэкендом, мы получаем ещё один слой абстракции. И я просто не понимаю для чего?))

Ну как же!

  • сначала был Перл, где приходилось колупаться с шаблонами, чтобы вывести простенький HTML

  • тут появился ПХП, который позволил встраивать серверный код прямо в HTML

  • потом оказалось, что из этого получается говнокод, и надо использовать шаблонизатор

  • потом придумали на пхп делать только АПИ, а интерфейс рендерить яваскриптом
    - (правда, потом оказалось что на клиенте рендерить медленно, и надо сначала отправить яваскрипт на другой сервер, чтобы он там сначала отрендерился)

  • тут появился Fusion, которые позволяет встраивать серверный код прямо Javascript <-- вы находитесь здесь

  • потом окажется, что из этого получается говнокод, и надо использовать шаблонизатор для яваскрипта...

потом окажется, что из этого получается говнокод, и надо использовать шаблонизатор для яваскрипта...

Так ведь там уже шаблонизатор есть?

Что только не придуиают, лишь бы не изучать React.

А зачем его изучать, как будто до реакта веба и в помине не было?!

Ммм, ну тогда можно улучшать CGI технологии, говорят, прорывная штука (была в своё время).

А при чем здесь react? У него те же самые проблемы.

Век бы его не видел, наряду с golang

Php должен быть в вебе, но только в back end, а Vue прекрасный инструмент контроля state даже без абстракции в виде fusion

Единственный вопрос который меня коробит, а что делать с api получается что он плавно перешёл в монолит клиент сервер. Или все таки этот вопрос прорабатывается также на уровне самодокументации

а что делать с api получается что он плавно перешёл в монолит клиент сервер

Такое часто оправдано, если продукт пилит одна небольшая команда. Ну и, например, для всяких круд-админок это может применяться, когда фронт фиче-неотделим от бэка.

Наличие api - не самоцель.

Наличие api - не самоцель.

Не сочтите за дремучесть но чем плохо на стороне сервера рендерить данные к примеру в php скрипте

<?= " let name=$name" ?>

И ее уже использовать хоть в ванили, хоть в jquery , да хоть в чем ?

Php сам по себе при использовании mvc шаблонизиатор отличный , зачем нужны вот эти тики прокладки типа twig или того что предлагается в статье ?

Кроме геморроя и оверхеда нет ни одного вменяемого плюса. А рендерить фронт на отдельном сервере в который отправлять js и backed json вообще дичь.

Вот того кто последнее придумал, когда помрёт , нужно вокруг гроба обернуть. Имхо

<?= " let name=$name" ?>

Конкретно это (тут еще и ошибка синтаксиса JS) - засоряет глобальные переменные.

Подсветка кода будет тут тю-тю.

Еще сейчас многие пишут на TypeScript с типизацией, тут с этим у вас туго.

Ну и еще можно много придумать, например, про необходимость экранировки. В общем больше проблем себе (а скорее другим) создаете, чем пользы.

Прежде всего эти <?= …?> визуально слишком шумные. Исторически первые шаблонизаторы появились именно по этой причине.

Дальше есть проблема с экранированием: постоянные вызовы функций экранирования ещё более шумные чем <?= …?>. Вменяемые шаблонизаторы делают экранирование автоматически.

Инерция неплохое решение, но вот это перебор явный, я даже не могу представить где мне такое может понадобиться

Всё идет к монолитности. Пусть и не гладко

twig 2.0. Наглядно.
Прикол конечно, но в 2025 году вроде как самое оптимальное это рендерить фронт как отдельное приложение, со своим сервером, а все необходимые данные тянуть по апи.
Я как понимаю это просто новая прослойка абстракции для шаблона на пхп?

На разработку api уходит слишком много усилий чтобы считать этот подход самым оптимальным.

Отдельное API требуется в случае использования сторонних клиентов или мобильных приложений. Однако, в современных реалиях со сторонними клиентами аще борются чем поощряют, а мобильные приложения - тот ещё камень на шее.

Выгдядит так же страшно, как в старые бородатые годы, когда мы html-код включали в php-скрипты. Теперь нам предлагают в одном файле писать и php и js и html и css?

Логичное развитие идей vue и svelte с их однофайловыми компонентами.

Если js, html и css уже собраны в один файл - почему бы туда и php не добавить для полноты?

Надо понимать, что в отличии от "старых бородатых лет" это именно компонент, а не страница целиком, да и все 4 части хоть и находятся в одном файле- но разложены по разделам.

Если это тупо генерация контроллеров + маршрутов к ним - для простых крудов пойдет. Если так, то у меня остался вопрос с политиками, которые можно можно было удобно применить на круд контроллер через authorizeResource. Да и вообще, насколько то, что в блоке <php> является стандартными контроллерами, какие доп плюшки есть.

О, xajax, привет. Давно не виделись.

Зарегистрируйтесь на Хабре, чтобы оставить комментарий