Нулевой километр (Хекслет)

Hexlet (00:00.046)
PHP умирал, PHP умирает и PHP продолжает умирать. Саш, поскажи, а ты давно сам смотрел, как изменился Битрикс и что в нём... точно ли в нём всё так, как ты описываешь? Я, честно говоря, мало работал с E, не знаю, как это сделано там, но там Лоравеле, в Info, и уж тем более в Битриксе и даже в ArtProgress, это отдельное тоже сорт извращение. Во что превращается Aspyr магазин за год? Два поддержки?

Ну, тут там перекреститься можно. Если это статика, если это кэш, то нафига нам вообще бэкэн.

Hexlet (00:42.574)
Друзья, всем привет, на связи Хекслет, с вами Александр Усков и в нашей виртуальной студии сегодня Иван Подубный с TTO компании Vopractic и Александр Макаров, один из соавторов фреймворка Yi, он же YII. Сегодня мы будем, собственно, говорить про PHP, про современные CMS решения и про то, какие из них несколько лучше, другие. Друзья, приветствую вас. Всем привет.

Сегодня мы, собственно, хотели что обсудить, что существует у нас две таких больших категории решений. Во-первых, это некие такие относительно готовые решения, типа WordPress для блогов или Drupal для каких-то сайтов с контента. И туда же, пожалуй, стоит отнести достаточно такой холиварный продукт с, на самом деле,

Ну, спорная репутация – это Битрикс. Почему спорный? Почему его репутация спорная, как вы считаете? Репутация спорная, наверное, исторически, потому что Битрикс ему достаточно много уже лет, и в любом проекте вообще есть такое понятие, как технический долг, то есть вещи, которые годами, собственно, копятся, и на них могут быть даже задачи, что это надо там перефакторить, сделать лучше и так далее, но...

есть с другой стороны груз обратной совместимости и соответственно ограниченное время и вот эти вещи они накапливаются и становятся ну не сильно удобно не сильно в ногу со временем то есть решение вроде неплохое но вот этих штуковин достаточно много и когда собственно люди на вот эти вот форт пресс на битрикс начинают

писать код это очень сильно отличается от того что сейчас вот по best practice везде рекомендуется и соответственно там ну очень много штук и через которые очень легко стрелять себе в ногу. Саш, подскажи а ты давно сам смотрел как изменился Btricks и что в нем точно ли в нем все так как ты описываешь? Ну относительно давно то есть где-то в районе года наверное

Hexlet (02:59.438)
То есть я точно помню, что там были глобалсы, и это уже как бы немножечко хватало. Ну плюс API для плагинов и так далее тоже был не в самой лучшей форме. Слушай, я тебе немножко попробую рассказать про... немножко с другой стороны. Первое, насчет глобалсов. Там... Да, нас из исторической...

штуке осталось два глобальных объекта, которые не являются там какими-то корневыми и главными. К ним уже правильно обращаться, на самом деле у них есть интерфейсы через классы, которые по PCR4 подключаются соответственно там для того, чтобы обратиться к этим объектам. То есть где-то для обратной совместимости они их еще оставили, но если ты пишешь новый код, новый проект, тебе не нужно их использовать, не нужно использовать то, что предоставляет...

возможности, которые предоставляет новое ядро, которое там есть. Соответственно, мы разрабатываем в Enterprise сегменте на Bitrex, и вот ты там изначально наживал Bit.x коробочным решением. Тут следует немножечко скорректировать. Да, у Bitrex есть два рынка. Это первый рынок, вот там рынок коробочных решений, это когда тебе нужно взять готовый интернет-магазин какой-то, развернуть и так далее. Ну, там условно ценник до полумиллиона, так примерно, разработки.

Есть рынок заказной разработки, Enterprise, и все большинство наших корпораций в стране, используют Bittrex там по ряду причин. На самом деле, это прям отдельная тема, почему они это используют, почему они это включают в тендерную документацию. И там разработка многомиллионная, используются все best practices, которые есть во всех фреймбиргах для того, чтобы

продукты получались качественно, они жили годами и использовались. К примеру, у нас там команда, нас есть разработка в основном на B3XY и на Ларавелле проекта, именно с точки зрения ПХП, в ПХП-отделе. И там у нас есть, недавно там пришел проект на И. И вот ребята, на самом деле, после того как как бы без практикса какие-то мы на B3XY использовали, когда они полезли в...

Hexlet (05:22.445)
и без практиксов War of Wale, без практиксов Beatrix, и когда они попробовали писать на И, они сказали, что вообще очень тяжело идёт. есть там всё на массивах. Как раз без практиксов в И во многих не хватает. есть диплой через какие-то копирования папок с массивами. Ну и такие вот прочие отзывы от коллег тоже хватало на самом деле. И тоже ведь несёт в себе этих долг, и тоже много есть ещё не лучших без практиксов.

Вы сравнили вещи, которые в целом наводят не совсем сравнимые. Вы сравнили Framework и CMS. Понятно, что Bittrex пользуются разработчиками для того, обеспечить клиенту конечный продукт. Но в целом, ей так нельзя использовать. Ей эта инструмента конкретна для разработчиков. Если абстрагироваться от того, как это выглядит в кишках со стороны разработчика, с точки зрения человека, который хочет получить на выходе рабочий продукт. Интернет-магазин, например, для чего сейчас используется Bittrex.

Почему он должен сделать выбор в пользу чего-либо кроме него, Есть ли вообще хоть что-то на этом рынке, на российском, по крайней мере, что может с ним сравниться по количеству функционала, количеству интеграции, количеству готовых решений, опять же, если абстрагироваться от доработки кастомной? Да, если абстрагироваться вообще от кастомной разработки, то, естественно, что коробочное решение...

даст вам такую фичу, как запуститься там за один вечер или... Ну очень быстро, очень-очень быстро. То есть, ни один фреймворк, естественно, который подходит для кастомных решений, он не даст вам запуститься прямо вот сейчас. Естественно, что это только коробочные какие-то решения. Это нормально. Ну опять же, вы немножко это скорректируете, да? То есть, опять вот...

мы как подходим к нашей разработке. Несколько сразу ты тем затронул. Первое, как мы подходим. У нас пришел клиент, у него есть какой-то функционал. И так как мы и Laravel используем, и Bitrix используем, мы понимаем. Вот к примеру, у клиента есть в его бизнес-логике вещи, которые Bitrix позволит упростить, удешевить и сделать быстрее. То есть мы тогда подключаем Bitrix.

Hexlet (07:47.181)
А бывает там настолько кастомная история, что там от Bittrex ничего не останется. Нет смысла абсолютно. То есть если у Bittrex этот CMS и фреймворк, у него есть достаточно сильный и развиваемый фреймворк. он конечно уступит, наверное, в фичах чистому фреймворку, но при этом он на самом деле даже в фреймворке, некоторые его возможности как фреймворка, они...

лучше, чем у некоторых современных фрейверков, он даже в чем-то с нашей точки зрения лучше, Laravel. Именно как с фрейнверк, например. То есть мы считаем там более сильное ORM, чем у Laravel. Соответственно, есть в Btricks его стоит рассматривать сразу с двух точек зрения. Но опять же, когда, если подходить с точки зрения, какую платформу выбрать, это фрейнверк или Btricks, то нужно исходить, насколько та логика, которая у клиента есть, она подходит под Btricks, насколько она будет под него класса, да, то есть там...

Например, есть какие-то готовые интеграции интересные или там защита по ФЗ, по разным ФЗ, которые есть у Bit.x, они есть из коробки, они довольно-таки удобно имплементированы, позволяет сократить какие-то трудозатраты. Тогда Bit.x подойдет. В другом случае, если оно кастонное настолько, что Bit.x никак не кладется, мы выбираем фреймер. Почему все-таки мы сражаемся с Bit.x? Почему вы используете именно его как CMS-Framer? Почему не Drupal, почему не ModX, почему не...

поставить нужное миллион ПКБшных решений есть для этого всего? Почему все-таки ваша работа была именно на Bitrex? По историческим причинам, да, то есть большин... Есть инерция, там, чем больше решений делается на рынке на одном решении, тем оно популярнее, тем чаще его используют. То есть на самом деле в свое время, там, где-то там лет 12-13 назад, выбирая между Модексом и Bitrex, с точки зрения функциональной возможности, я бы, наверное, выбрал Мод Модекс. Мне он там нравится его концепцией.

Но очень агрессивная политика Битрикса 15 лет назад маркетинговая, там, 15-10 лет назад, позволила ему занять всю нишу CMS, огромное количество, то есть, по крайней мере, в коммерческом секторе, и вытеснить на голову практически все решения. Поэтому, когда мы говорим о каких-то компаниях...

Hexlet (10:04.749)
более-менее крупных, там, до средних. Сейчас они в первую очередь смотрят на битекс. Почему? Потому что большинство разработчиков на битексе. А почему разработчиков больше на битексе? Потому что много заканчиков требует битекс. В общем, такая штука инерционная, которую битекс вовремя завел, и она очень тяжело с рынка ее будет чем-то вытеснить в этом плане.

это если сравнивать с другими CMS. Я правильно ответил на твой вопрос? Ну, не то что правильно, я хотел понять мысль. Мы опять же сравнимся с Framework. Вы, как раз, заводки используете Framework, Bitrex как Framework и, соответственно, Laravel. Но неужели не возникло сценария, в которых выгоднее взять что-то другое? Тот же WordPress. Треть сайтов в интернете работает на нем. Он тоже весьма-весьма прокаченный. Если Bitrex — такая чисто легиональная тема, ну, понятно, что в России у него масса плюсов, в первую очередь с интеграцией собственности DNS, да, то почему не что-то еще?

Неужели какие-то типовые решения, если выбирать между Laravel и Bitrex, и чем-то еще, нет ничего, что в середине оказывается лучше? Или просто практика именно вашей компании? Ну, опять же, если мы сравниваем чисто CMS-ки, у WordPress'а есть свои ниши. Он хорош для блогов. Для всего остального это просто прикручивание чего-то большого, кастомного, сделанное непонятно кем к платформе, которая к этому не предназначена.

То есть WordPress отлично подходит для блогов. Вам нужен блог, возьмите WordPress. Вам не нужен для блога битекс. Если вам нужен интернет-магазин, не надо интернет-магазин на WordPress делать. Если кто-то это делает, я считаю, что он архитектурно неправ. Потому что WordPress для этого не предназначен. К нему просто пристраивается огромный такой вот гараж, такая пристройка, которая написана не всегда качеством, не всегда качественными плагинами. И это лучше выбрать другое решение.

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

Hexlet (12:20.973)
то, насколько я слышал, с перформансом вылезают тут же просто дикие проблемы и чаще всего это заканчивается тем, что от Bitrex остается либо одна админка, а фронт полностью кастомный, чисто ради перформанса, либо вообще Bitrex приходится выкидывать и переписывать на что-то еще. Есть у нас в компании мнение, что...

Современные приложения нужно делать вообще не используя шаблонизатора, который предоставляет PHP. По крайней мере публичную часть, это как минимум. То есть с админками можно поспорить, но публичную часть нужно делать на современных технологиях, которые предоставляет React либо Vue, а backend должен давать исключительно API. Это решает много вопросов, но в первую очередь это требование рынка.

Потому что фронт-энд разработчиков, которые не пишут на React или на Vue, которые бы собирались на ванильном или GQR стэке работать в ближайшие год-два, таких вы практически на рынке сейчас не найдете. Все разработчики хотят работать с современным фронт-эндом. Это React или Vue. И, соответственно, если вы стартуете проект в современном мире на ванильном JS, который будет по дом-дереву бегать и в императивном стиле с этим работать,

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

Ну, здесь достаточно спорное утверждение, потому что в мире фронт-энда все вот эти вот фреймворки, они устаревают очень быстро, то чрезвычайно быстро, если там в PHP это там 5 лет может жить вполне себе фреймворк, даже мажорная версия, то в GS, если год живет фреймворк, уже хорошо, а мажорная версия и того чаще бывает выходит. Поэтому то, что...

Hexlet (14:40.141)
разработчику фронта захочется через там три года работать на каком-нибудь там Vue.js версии 2, когда уже сейчас 5 есть. Но это тоже очень такая спорная штука. У меня возник вот другой вопрос. Иван уже сказал, что они используют SSR для того, чтобы обойти проблемы с SEO с Яндексом. Но возникает такой вопрос, а зачем делать SSR на JS, если его и так делает Bittrex? И плюс к этому добавлю сразу, что ведь опять же если говорим про конечного клиента, кому просто уже этот магазин?

он, скорее всего, поставит себе какой-нибудь шаблон и вообще не будет дуть в усы и какие-то там вещи допрограммировать. Крайне редко там что-то доделывается. Ну, если уже только проект прямо растет, растет. Но в плане там... Есть уже самое As Pro, да, для него там есть миллион шаблонов, которые уже там все из коробки умеют делать, в том числе и Js там куда-то пишется. И там даже местами не jQuery, а просто vanilla.js. Понятно, что с точки зрения поддержания разработкой, да, понятно, что LIAG гораздо популярнее, проще таких разработчиков. Но зачем как бы усложнять, так скажем, множество существ необходимого, если это можно избежать?

В чем ценность в данном случае? Если клиенту нужен быстрый интернет-магазин, то он всегда действительно самая правильная штука проверить гипотезу, взять шаблонное решение и не париться. Если ты хочешь себе большой интернет-магазин, в который ты хочешь вкладываться, тебе нужно вкладывать в те инструменты, которыми ты годами, которые ты можешь годами развивать. Если ты посмотришь, во что превращается Asprer-магазин за год-два поддержки,

Ну, тут там перекреститься можно, то есть там все очень плохо становится. На самом деле там шаг вправо, шаг влево у этих аспр, они очень гибкие, то есть там код изменять крайне сложно. Мы когда-то там лет 5-6 назад попробовали в этот рынок зайти, зашли, спалили просто третье дело, они у нас ушли, плюнули, начали плеваться жестко на этот аспр и все остальное, и мы поняли, нет, больше мы туда идти не хотим, там стресс, там заказчики, которые...

экономят, им важно просто быстро запустить и все прочее. И мы пошли больше все-таки в кастомную интерпрайс-разработку, и интересно, и нам, разработчикам этот рынок. То есть мы просто говорим про разные сегменты, про разные потребности. MVP запустить, аспора, интернет, магазин, без проблем. Если ты хочешь в долгу кастомное решение, которое ты будешь годами развивать, то не нужно использовать шаблоны и лучше вкладываться в тех технологий, которые будут жить годами.

Hexlet (17:04.589)
Очень сильно, не соглашусь с Сашей относительно, что вот этот очень старый, на самом деле, поверье, что у фронтендеров там все меняется. Каждый React, ему уже более 10 лет, он более 5 лет занимает топ-1 фреймберк в мире. И с 2017-го, ну не знаю, хукки там вышли, которые даже не сделали несовместимым какой-то код там обратно совместимым, не сильно сломали.

То есть классовые компоненты до сих пор работают без проблем. Но фрейдвёрк просто не меняется сильно. Причём он настолько не меняется, что реактор-разработчики ожидают каких-то изменений. Мы ждём более-менее радикальные изменения в мире реактов. Первый за последние лет пять — это 18-я версия, которая должна... Она вышла, но она не выпустила все ключевые изменения. И поэтому...

Ну, в общем, там хоть немножечко меняется парадигма, вносится что-то новое. Но на самом деле очень сильно стабилизировался фронтенд за последние годы. Вот эта старая поверье о том, что у фронтендеров там все меняется каждый год, оно уже неактуально. У Vue и у Angular были проблемы, они ломали обратную совместимость, у них были. Но самый главный топовый фреймвёрк, если про всем, по количеству скачей, не по количеству популярности в Google, это React, он годами не менялся практически.

Нормально, да. Этого я не слышал. И у меня на самом деле в опыте исключительно Angular и Vue. Реакт мне ни разу не попадался, наверное, поэтому у меня такое мнение. Я позволю себе заметить, что при этом при всем Jackvary все еще используется примерно на 70 % всех сайтов в интернете, потому что никто не собирался его ломать, переписывать на React, просто бессмысленно. Но новый проект, конечно, нем делать крайне странное развлечение.

Насчет React у меня есть даже предположение, точнее мнение, почему он настолько популярен, почему он, скорее всего, сильно эволюционировать не будет, потому что он реализовал то, о чем мечтали разработчики любых систем управления и framework'ов, начиная с 1998 года, это сделать нормальный журнализатор. JSX он максимально прибежал к HTML. Ничего более удобного, мне кажется, придумать просто невозможно, но только если нужны какие-то там настройки на HTML, всякие эмиты и прочее.

Hexlet (19:20.429)
В хпшной фреймворке, насколько я знаю, к этому до сих пор не пришли, хотя попытки были. Самая близкая, наверное, Smarty, но он тоже страшно ужасный. От Wiggy, всякие пуги, это все на любителя. И он позволяет именно очень быстро верстальщику что-то наконить. В то время как для хпшного фреймворка верстальщику нужно еще освоить какие-то шаблонизаторы, чтобы хоть как-то свои мысли еще правильно порезать все эти файлики, положить их в нужном папочкам, связать друг другом, сделать included, data-p. Я, честно говоря, мало работал с E, я не знаю, как это сделано там.

Но в Laravel и в Symphony, и тем более в BeatleX и даже в Artpress это отдельная тоже сорт извращения. И как вы видите движение с точки зрения именно PHP-шных решений, ну и даже может быть в целом сервенных, неважно, будет это джанг или что-то еще, куда движется там эта шаблонизация становится для нас проще и позволит ли она как-то тоже зафиксировать определенным образом ход мыслей у разных разработчиков решений.

Да проще нет, на самом деле не становится. есть шаблонизаторов новых никто особо не делает. И действительно, популярность у серверных шаблонизаторов, подупала. То действительно есть большой пласт вот этих вот проектов, Rest API или GraphQL API плюс, соответственно, Frontend. Вот, это такая штука спорная, потому что есть прекрасные примеры.

бэкенд генерируемых всяких разных решений. Ну, например, вот недавно email service вышел от создателей Basecamp, который называется Hey и который как бы рендерится вообще за очень-очень маленькое время и сделан целиком на бэкенде без вообще всякого фронта. Вот, то есть так тоже можно и это работает и у меня по опыту еще есть ну как бы большой такой плевок в сторону решения rest плюс frontend.

это то, что если вам не нужно делать сразу и под мобильник, и под десктоп, и вы можете сделать там progressive application, который там скейлится нормально, то в принципе у вас сильно дешевле разработка выйдет. То есть вот время, которое тратится на координацию между back и front, на продовольствия API, время, там...

Hexlet (21:41.261)
Деплой настраивается, чтобы все это как-то синхронизировать, чтобы фронт ждал, пока API будет готов и приступил к своим задачам, где-то раза в два, а то и в три. По моему опыту, выходит, дольше и дороже, чем по старинке взять и чисто на серверсайде все это зафигачить. У меня здесь опыт немножечко другой. Я там...

руковожу отделом разработки веб-студии, более 100 человек. мы тоже, как когда-то, там, до где-то года 16-18, вот просто у нас стабильный был сервис-сайт рендеринг. Какие у нас были проблемы? То есть, как будто бы там не была проблема несогласованности front-end и back-end. Да, постоянно были. Когда back-ender там что-то поправил шаблоню, у front-end'я это все поехало, front-ender полез, а, и еще мне какая обогромная проблема, представляете, да, то есть...

приходит ко мне фронтендер, и я его должен учить вместо современного шаблонизатора, я его должен учить шаблонизатору какого-то бкн-фреймворка. Мы это на самом деле сделали, мы там сделали максимальное онбординг фронтенд-разработчиков, сделали свою документацию, как правильно верстать в битексе, чтобы там битексе не разбираться, максимально простую. Или в лоровеле, мы там тоже это сделали еще более простую, объясняющую, как правильно раскладывать те или иные решения и в лоровеле, вот внутренние.

которое позволяло упростить онбординг. Но это ничто по сравнению с тем, фронтендером все равно больно писать внутри чужой экосистемы. И одна из самых главных проблем, то что вебпак, в принципе, а это ключевую сборщику фронтендеров, которая используется, он в принципе практически его невозможно хорошо и похавельно подружить с любым backend-based рендером.

Я прям очень сильно изучал решения, которые были у Symphony, которые были у Laravel. То есть там в EPCN Core, по-моему, у Symphony, у Laravel Mix. И того решения, к примеру, как у Beatrix, чтобы сделан, и, по-моему, у Epoch, же штука. Заходишь на страницу, и он подключает тебе только те скрипты, которые нужны для этой страницы. Так вот, если вы используете современный подход в GSE, это GSModule, соответственно, и собираете это в EPCN.

Hexlet (24:07.757)
то вам либо нужно ручку мейпить каждую страницу, ну, другого варианта практически нет. И соответственно, у какой-то сайт, там вас большого количества разных страниц с разным набором компонентов, чтобы не грузить лишний код, вам нужно просто очень сильно ухищряться. Вот сейчас, особенно там, с учетом требований Google последних по производительности, которые есть, оптимизировать по производительности сайт на ванильном стейке крайне сложно, потому что там прям очень свои большие вызовы есть.

есть, мой главный тезис, что подружить современный фронт-энд с шаблонизатором на бэк-энде практически невозможно. Точка излома — это веб-пак, который не может понять, какой набор компонентов на каждой странице должен быть рендериться. Если только бэк-энд не на Gs, да? Да, если только бэк-энд не на Gs, да, всё так. Это да. Веб-пак тоже уже отходит в прошлое, насколько я знаю, и на смену пришло что-то ещё.

А чем, Александр, какие у претензии к Webpack? Webpack очень сложный. Он реально очень сложный. есть, транспиляция, Babel, все вот эти вот модули дополнительные и так далее. Если вдруг в проекте вам не дадали какие-то конфиги для Webpack и вам нужно это заново настроить, это можно вешаться на самом деле, потому что это займет несколько дней точно. Ковыряние, проб, ошибок и всего-всего.

Я здесь тобой соглашусь, что WPAC много лет держал такое уверенное лидерство, и на самом деле он до сих пор будет держать, и он еще годами будет держать это лидерство. Но сейчас появились несколько игроков, которые пытаются бросить ему вызов. Один из них, один из самых популярных, это White, если я правильно его произнес, White.js, и он позволяет некоторые вещи делать. Но, тем не менее, это не решает ту проблему, что этот White будет точно так же...

нереально подружить с backend-based рендером? Если только не найдется какой-то энтузиаст, который целенаправленно сделает супер классный плагин. Причина в общем все используют пак, потому что для него много всего готового, а для всех остальных, там, roll-ups и прочего есть, build'ов, нужно где-то что-то находить, далеко не все там есть из того, что часто требуется в крупных приложениях. Я думаю, что просто они поделят какие-то сегменты рынка, и на этом все кончится.

Hexlet (26:30.221)
Нужна очень глубокая обвязка с бэкэнд фреймвёрком. Там проблема в этом. Я вот своё время пытался просто написать свою обвязку в Эпак и Abitrix. То есть мне нужно, чтобы бэкэнд платформа передавала в Эпак в ран тайме, какие компоненты у меня на текущей тренице вызываются.

Соответственно, она должна быть очень глубокая интеграция и проблема скорости бандлинга. Потому что если я это делаю в раундтайме, меня в APAC все равно будет тормозить. В общем, общий тезис, на самом деле, мой, что в backend-ду нет смысла пытаться запрыгивать в выходящий поезд. Некоторый рынок еще для backend-based рендера останется, но по факту поезд уже уходит, и некоторые попытки Ларавелла сделать какую-то свою попытку генерации...

обоюда связанного GS и PHP-логики. Это попытки все запрыгнуть в выходящий поезд. Нет смысла. Тренд уже много лет идет к тому, работали не через res.tap. И кстати, тут чуть раньше был тезис насчет того, что... А почему, сильно дольше? Нет, вот я начал говорить о том, что...

на уровне шаблонов front-end туда погружаться, и там будут точно такие же проблемы, причем эти проблемы сопряжения front-end и back-end будут хуже регламентированы, потому что у нет контракта. Back-ender поменял где-нибудь модель, а эту модель выводит какой-нибудь фронт в каких-нибудь своих шаблонах. Front-ender нужно лезть в шаблоны, у вас нет контракта между front-ender и back-end какого-то регламента, вам это приходится все на руках делать. Когда мы перешли, что у нас между нами рест,

у нас как раз появился контракт и мы можем в самом начале работы между фронтендерами и бэкендерами мы можем их максимально запаралелить мы просто между ними поставили контракт и после этого они могут работать с самого начала запараллельно это на самом деле ускоряет даже разработку когда мы параллелим команду ну в какой-то мере да здесь просто смотрите какая штука мы говорим про уходящий поезд когда у нас пытаются

Hexlet (28:41.389)
скажем так, эти вот богатые приложения с кучей GS, которые действительно приложение. И здесь я полностью согласен, что на самом деле бэкэнд фреймворком туда соваться и не надо было. Вообще, самого начала не надо было туда соваться. Бэкэнд должен заниматься как бы бэкэнда, но он может заниматься и серверной генерацией. Потому что вот я не согласен с тем тезисом, что все приложения...

оправданно делаются single page application. То есть куча этих приложений, самом деле, большинство сейчас проектов, даже которые оформлены как single page, они, ну и смысла нет быть single page application. Там нет ни интерактива, там нет ничего. Они просто, ну, по шаблону рендерятся на клиенте. Это смысла делать нет никакого. Я с тобой отчасти соглашусь, что с точки зрения

логики и начальной экономии средств, некоторые, как минимум часть приложений, которые являются SPA, можно было бы сделать на бэкэнде. То есть если рассматривать именно с позиции, что там логики-то особо нет, там просто простой рендер и все остальное, да, тут все верно, можно было бы сделать это на старом стеке. Ну, старом я веду ванильный GS какой-то и рендер из бэкэн. Но...

Если мы задумаемся с точки зрения того, что если мы собираемся этот проект развивать годами, у нас мы будем упираться в фактор рынка. Рынок ванильных разработчиков очень сильно иссякает. И соответственно все разработчики фронтендера, они хотят писать на современных инструментариях. В том числе тот же React, позволяет не только решать вопросы, связанные с логикой, он сильно упрощает

переиспользование компонентов, то есть ты там эту кнопку можешь как компонентом обернуть и она у тебя максимально везде будет переиспользована. Чего сложнее добиться в старом стеке. И очень много решений, то есть там CSS модули те же самые, которые позволяют тебе отказаться от какого-нибудь БМ, да, то есть который раньше был, тебе уже не нужно думать о том, что тебя может быть конфликт между классов. Это все тоже автоматически решается. А если, то есть...

Hexlet (30:57.261)
Плюс во фронт-энде сейчас появились фреймворки как и вью, так и на реакте. Это Next и его аналог во вью Next, которые позволяют очень быстро, то есть не париться с разворачиванием веб-пака, настройка конфигов. Ты их просто клонируешь, и тебя сразу все готовое. И ты просто берешь и делаешь. Да, то есть boilerplate больше, более правильно сказать. есть boilerplate, который поднимаешь и который тебя максимально готов к разработке.

Вот по сути, как Laravel ты поднял, ты почти сразу готов писать API уже, там тебе не нужно париться с конфигурацией. В общем, порог входа здесь за последние годы улучшился, и с каждым годом он уменьшается. Google выделил целую команду для того, чтобы она развивала вот эти фреймбёрки. Сначала он начал вкладывать уже более двух лет в Next.js, но помимо этого он обещает то, что он будет вкладывать свои ресурсы в развитие Next.js.

Благодаря этому эти решения не только они удобны для фронтендеров, они еще и максимально заточены на производительность. То есть там из коробки позволяет достигать лучших best практиks, которые можно использовать для веб-страниц для того, получать лучшие показатели в Google Page Speed Optimization и как следствие все оранжирования. Окей, ну да, я понял. Хорошо, ну, смотри, то есть...

Вы берете вот тот же самый Btricks и первым делом, что вы берете, вы выкидываете весь его frontend и работаете с RESTом и пишете свой frontend. Я правильно понимаю? Мы делаем так с абсолютным любым backend framework, в том числе и с Btricks. Окей, то есть мы начинаем как бы сравнивать тогда Btricksoid, именно backend framework и custom backend framework, да? То есть...

То есть остается у что-то типа Rest Up'и, да, мы делаем на них. И под Rest Up'и у того же там Yi, у того же там Ларвелла, у симфонии, у всего есть какие-то ну такие достаточно неплохие решения и интеграция там со свагерами и так далее. Вот чем здесь именно Bittrex хорош и чем он здесь-то нам помогает? Кличевое требование, почему мы используем Bittrex для каких-то клиентов.

Hexlet (33:16.749)
это вся та же готовая бизнес-логика. Бизнес-логика, она же заключается не только в шаблончиков. Бизнес-логика – это готовые интернет-магазины, акт заказа, интеграция с… Ну, если в случае с интернет-магазином, это оформление заказа, скидки, интеграция со складами, сложные системы скидок. Вот эта вся бизнес-логика остается. И нам просто нужно на самом деле к этой всей логике есть из коробки неплохой арест.

Но если надо, мы можем расширять, модифицировать и улучшать те точки, которые нам нужны для конкретного бизнес-решения. Ага, слушай, а вот я, правда, не с Bitrix, в плане интернет-магазинов работал, по-моему, было то ли Simplify, то ли еще какой-то магазинчик. Там тоже была как бы готовая логика, и пока она совпадала там, ну...

процентов на 90 с тем, что нам нужно, все было прекрасно. Но как только что-то кастомное нужно было сделать в этой логике, ну допустим у нас в нашей вот этой вот логистике мы часть держим на складе, а часть предзаказаем. У нас есть разные поставщики с разными сроками, нужно прогнозировать и автоматически надзаказывать. То есть уже пошел такой достаточно лютый кастом, да?

И вот в этом самом лютом кастоме, когда мы пытаемся его впилить, готовые решения, они начинают нефигово так сопротивляться. И ты сидишь, тут пытаешься запилить, и находишь, что вместо того, чтобы взять и сделать вот это вот за 6, допустим, часов сесть плотно, ты сидишь и вторую неделю просто ковыряешься, и пытаешься победить тот же там Bittrex или...

какой-нибудь еще фреймворк или еще что-нибудь, что там гвоздями прибито, и ты никак не можешь там, не знаю, какой-нибудь JSONчик вывести или в какой-нибудь модель что-нибудь запихать. Абсолютно хорошее правильное замечание. То есть первое, нужно архитектурно понимать, насколько решение подходит к бизнес-логику. На самом деле, у Beerix много заложено вариантов и запас гибкости в плане интернет-магазинов, он там позволяет очень разные решения интернет-магазинов реализовывать. Но если там прям что-то люто-кастомное...

Hexlet (35:27.213)
мы просто не будем брать Bittrex. То есть мы поймем, что лучше запилить это свое где-то с нуля и сделать. Если мы видим, что мы можем это сделать, зная ограничения платформы, то мы возьмем лучше Bittrex. То есть нужно правильно и ахетиктурно подходить. Да, это все классно, но это же немножко такая, получается, ловушка. То есть в начале...

Естественно, у всех практически бизнесов они не понимают, что им какой-то кастом нужен, они не понимают какие деньги они могут на этом кастоме выиграть и так далее, они, естественно, берут какие-то коробочные, шаблонные решения. И чем больше они на эти решения сядут, чем больше вот это вот решение из коробки предоставляет, тем сложнее потом с него, собственно, слезть. А с Bitrix еще и обидно слезть, мы за него деньги отдали, за интеграцию и так далее, и так далее. Мне кажется, у Виктора Батдонова тоже, просто сразу их позиции.

Если Иван говорит с позиции того, кто реализует решения, то Александр говорит с позиции того, кто их заказывает. И собственно та причина, почему существует CMS, а не только фреймворк, там в пенсионерой SAP. Хотя такие тоже есть, в том же JavaScript есть в Trappy, это так называемый Headless CMS. Там есть админка, но нет фронта. Только опишки соответственной модели. Потому что, я клиент, мне тоже не всегда хочется платить 200 тысяч разработчику в течение года, если я могу сразу платить 200 тысяч.

компании 1s и мне дадут битрик со спротом с кучей плагинов и он будет работать и в принципе до какого-то степени моя задача решит. Ну а дальше проблема, которую ты посвечишь Александру, кажется, напрямую к любым инструментам. У тебя в любом случае любой инструмент закрывает какое-то количество юзкейсов и чем дальше ты от них отходишь, тем больнее тебе становится. И как правильно сказал Иван, нужно просто вовремя понять, насколько твои задачи в кратком среднем срочном перспективе соответствуют тому инструменту, который ты пытаешься к ним прикрутить. Но это не задача заказчика, он это знать не может от него специализация.

Поэтому он обращается к специалистам, к студиям и надеется, что они будут выполнять свою работу исходя из коммунистических соображений, не только из коммерческих. Хотя, разумеется, бывает и по-другому. Ну, я слышал, что именно сама компания 1S и Bitrix, такую техническую поддержку не особо оказывают. То есть, если что-то нужно, то нужно идти именно к вендорам. К сторонним вендорам, и они уже там что-то делают.

Hexlet (37:40.397)
Они могут поковаряться в сайте, но это будет стоить неприлично много. Маленький нюанс. Первое, компания 1S и 1S Bittrex это сильно разные компании. То есть 1S… Ну, 1S это понятно бухгалтерия и так далее, а Bittrex это CMS. 1S… Ну, то есть была веб-студия, которая создала Bittrex. В какой-то момент 1S проинвестировала в эту компанию. То есть 1S является просто инвестором. Но компании, то есть там в плане руководства, управления, это совершенно разные.

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

Залезть проект это подольше, соответственно, может неделю дает. Когда-то мы к такому чаще прибегали. На самом деле последние лет пять у нас достаточная экспертиза такая, что мы не обращаемся с такими вопросами. Просто проще самим залезть в фото и посмотреть, что там не так. Но большое количество, когда не хватает экспертизы внутри, или когда клиент сам пытается что-то там разобраться с какими-то мелкими навыками программиста, это в основном, конечно, в нижнем сегменте.

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

как минимум. Но в течение недели, скорее всего, если они увидят, это, то они могут полезть к вам в код и указывать вам на ваш шоу шип. Но опять же, это не дешево. Ну да, не дешево. У вас получается что? Что кастомы в основном прилетают вам, где уже взяли Bitrix и вам что-то с ним нужно сделать, там доработать и так далее, или есть что сделаете нам с нуля уже такой кастом, который на Bitrix...

Hexlet (39:59.853)
ну, похож, но уже там значительная часть, и вот это вот все. Каких проектов больше? Смотри, я расскажу. есть, смотри, мы работаем, наш сегмент, это в основном какие-то крупные корпорации. Крупные корпорации почти всегда борются с коррупцией порядком тендеров. То есть, и в тендерной документации почти всегда есть Bitrix. Если это новая система, то если это новая система, почти всегда есть Bitrix. Если нет Bitrix, то мы всегда оцениваем, насколько этому клиенту...

этот CMS подойдет. есть в каких-то случаях мы понимаем, что лучше запилить кастомное, чем взять Bittrex. А в каких-то случаях мы понимаем, что это прям офигенно зайдет, офигенно сэкономит средства или нам, или клиенту, и это будет намного сильно удобнее. То есть мы как бы опираемся от бизнес-требований. В целом, на самом деле, огромное количество рынка на развитие уже существующих систем Bittrex.

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

Насчёт дорого, вы недавно сказали, это очень дорого, но, блин, лицензии битекса стоят 60-100 тысяч рублей. Посмотрите на размеры зарплат текущих разработчиков, тех же PHP-разработчиков, это сильно удешевляет. Тут есть одна как бы неркс кредил, некоторое лукавство, потому что наличие битекса не освобождает необходимости иметь разработчиков в штате. Либо ты отсортишь, либо в любом случае потребуется кто-то... Он...

экономит огромную часть количества бизнес-логики, если, опять же, это подходит по твоей бизнес-логике, огромное количество бюджет в тебе экономит. Погоди, а вот эта вот специфичная борьба с Bitrix, она разве не выливается в какие-то дополнительные часы при кастомной разработке? Позвольте, я отвечу. Тут все очень просто. Это просто альтернатив, как бы. тебя в любом случае будет кастомная борьба даже с бесплатным вардпрессом.

Hexlet (41:52.269)
и не факт, она тоже не вылется во что-то, а совсем на коленке все делать, ну как бы это... Ну, с фортпрессом точно будет, но с полностью кастомным фреймворком, ну допустим там на симфоне, на ларвале, на Yi, что-то написано, то... Тогда нужна хорошая экспертиза именно в нем. Тогда нужна именно в нем экспертиза. Понимаешь, любым инструментом... Да нет, здесь экспертиза на самом деле нужна не в фреймворке, потому что фреймворк у тебя, ну, первый там месяц у тебя будет играть, когда ты начинаешь...

а дальше тебя экспертиза просто в разработке там в доменном дизайне в УП и все ну в том числе в том числе да просто когда ты какой-то фреймворк популярный тоже в вопросе для битрикса ты ну чаще всего тебе не нужно лезть очень глубоко в дебри ты именно прикладные какие-то вещи там с формов покопировался так вверху в принципе все довольны то есть не возникает на самом деле уже рабочих кто прям завязает в этих ценностках у них не возникает мотивации лезть глубоко

Поэтому они в целом и дешевле стоят, как следствие. Я как житель региона могу тебе сказать, что здесь практически все работают с Bitrex и с очень слабыми разработчиками. Они как задачи решают, хотя понятно, что может было намного лучше. Но это не про Enterprise, это про малый средний бизнес. Вопрос вот какой. Вообще, насколько вы применяли в практике, еще думайте в тему про уходящие поезда, в новое переосмысление Web2.0.

Я не знаю, как правильно называется, я это называю стриминговый рендеринг. Когда есть приложение, URL обрабатывает на бэкэнде, на клиента отправляет HTML по WebSocket. Ну, то есть там Hotwire это в Ruby, в PHP тоже какой-то Wire есть, не помню, как он называется. В Python есть похожая история, в JSON само собой такого полно. Ну, в смысле, ты выбиваешь адрес и тебе выдаётся HTML пока...

потоки, да, то есть по... Не-не-не, не совсем, не совсем. Когда у тебя как бы серверный рендеринг, но он проявляется на клиент кусками по запросам. Но он серверный, на том же дежке, который работает ротинг. Да, клиент, на самом деле клиентская штука, инициализирует у тебя веб-сокет, то есть держит в соединении открытым, и по нему шлет как бы пакеты. И они рендерятся в реалтайме у тебя на клиенте, соответственно.

Hexlet (44:09.901)
сервера прилетает но это такое странно не редовица там уже хтмл приходит готовый а погоди это разные вещи есть есть что у тебя коннект через веб сокет и у тебя просто данные пакетами и здесь ты же framework просто он берет данные сокет я про то когда сервак хтмл присылает как это было веб 2.0 ипоху если помните ну я так делал работал это это как бы норм

быстро бегает, быстро бегает, то есть у тебя нет перезагрузкой страницы, тебе не нужно заботиться сильно о SSR там на всяких там реактах и так далее, то есть ты рендеришь серваком привычно. Вот, ну для многих проектов вполне себе работает, и эта штука очень легко кстати встраивается в классический вот этот вот HTML рендеринг серверсайдом.

и дает 90 % плюсов того, что вот фронта, от SP и ждут. Ну, исключая, опять же, кадровый вопрос. Как вы думаете, вытеснет современное SP вообще? Конечно же, нет. Это на самом деле тот же старый-старый подход, только в профиль. Ну, то есть это один из способов, на самом деле, старого подхода. То есть, на самом деле, вот когда еще не было, на самом деле, уверенности в современных JS-времерках, мы еще тогда так делали.

Вот, просто это сейчас обвернули в новую упаковку, но по сути это все тоже самое старое. Да, это то же самое. На самом деле так много чего работает из известных проектов, например, же самый GitHub. Я в общем с вами солидарен, я разделяю точку зрения Ивана, что React классно, круто, но как бы я немало слышал и точек зрения, что, ой, да пока там все это настроишь, там все эти 200 мл для NPM, в ваппаки, это все типа только лишний татат денег, тем более фротендеры дорогие, там, берем Hotwire, фига-фига-ка и вперед.

И я согласен, что до какого-то размера проект работает для определенного типа продуктов. Но действительно, что же самое, что и было. Почему, как мне кажется, Frontend стал таким популярным? Потому что стали популярными облака и стало модно переносить кучу кода на клиент, чтобы не платить за инфраструктуру. И это тоже один из больших или плюсов крупных проектов. Если возвращаться в старую идеологию, что мы рендерим HTML на сервере, не говоря там уже про вопрос про линии состояния, про слежение за клиентами, это и то п...

Hexlet (46:31.181)
то по сути это действительно самый старый серверный рендерник ВВ1.0 роста в профиль. Не соглашусь с тем, что... Ну, возможно, изначально, да, действительно, кто-то там думал таким образом экономить, но на самом деле цель перехода на эти приложения не в том, чтобы экономить на сервере, а в том, что приложения были более отзывчивые и более удобные, потому что когда они меньше нужно ходить на сервере, больше что-то у себя делать, как бы...

в браузере, позволяет приложении быть более быстрым, отзывчивым и прочее. сейчас речь вообще ни разу не про экономию, особенно нас в счетом того, что большинство решений по умолчанию сейчас стараются использовать сервисайд рендеринг, потому что это тоже ускоряет, когда готовая HTML-ка сервия приходит, браузер этот быстрее может ее рендерить. И ты гидрируешь это все фреймворком в Vue или React.

позволяя переиспользовать эту логику. То есть на сервер на самом деле нагрузка пошла еще больше, поэтому мы ни разу не сэкономили. У нас теперь работает точно так же и бэкэнд. Тут нет, мне кажется, бы прямо очевидно однозначного ответа, потому что зависит от кучи нюансов. того, насколько у тебя навороченный код на клиенте, насколько он быстро работает, насколько у тебя быстро серва, как тебя настроен кэш, который, как известно, одна из самых сложных проблем в программировании. Тут есть, как бы, да, есть куда подвигаться и влево, и вправо в этом смысле.

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

чтимальной стороне клиента, а пуляемся там джейсоном. То есть разницы прям дикой не будет. Это все равно будут плюс-минус те же запросы к базе, которая приседает гораздо чаще, чем фронты и скеллицы, хуже. Это будут накладные расходы. Ну да. Но там у тебя кэш. Если тебя всем одно и то же отлетает, если это не индивидуальные страницы… Смотри, если это статика, если это кэш, то нафига нам вообще бэкэнд?

Hexlet (48:48.525)
То есть до того как классический HTML сервер рендеринг был, было еще замечательная штука. есть такой достаточно популярный ресурс, называется он Smashing Magazine. Там дизайнерские статьи и вот эти все классные штуки очень клевые. Вот они пишут плюс-минус статичный контент, ну и имбедят там комменты чисто по обсуждению. Ну такой блок, блок не блок не знаю, magazine, журнал.

Вот, и они что делают? Они просто берут и рендерят это дело при деплое в статичный HTML. Естественно, статичный HTML может отдаваться с одного сервака на какие-то миллионы клиентов без какой-либо проблемы. А если мы туда засунем бэкэнд, и да. Ну вот это вот, кстати, гигантская экономия и ресурсов и всего-всего. Ну, мы понимаем же вами, что архитектурно это...

плюс-минус. есть, просто либо ты генеришь этот момент, когда ты создал контент, либо ты его генеришь, когда его запросили, ты идешь в кэш. В конце концов, если тебя количество энтропии в этой системе одинаково. Ну, мы же уже говорили, что инвалидация кэша очень такая злая штука. Тут не поспоришь. Проблема инвалидации кэша, да.

что штучка не проста и все-таки в нашем контексте мы наверное говорим не про статику а про всякие разные динамичные штуки то есть какие там ну интернет магазины те же то есть когда мы начинаем там все это закидывать в корзинку когда мы оформляем заказ где есть какая-то логика и вообще на самом деле как только у нас простой допустим магазин

вырастает во что-то более интересное, ну, взять пример компании там, Ла Мода или еще какое-нибудь, то на бэйк-энде нас вырастает целая куча автоматизации еще и других процессов, то есть колл-центры какие-то, воркфлоу там и так далее и так далее. То есть рядом вырастает еще и... Еще не понравилось там шаблоны рендерить, да? Ну, как бы на самом деле это тоже норм, то есть...

Hexlet (50:54.701)
Ну в какой-то момент да, бывает что эти все штуки тоже перерастают в сингл пейч аппликейшн, но достаточно долго обычно такие вот компании, магазины и так далее они стартуют там с какими-то крутовыми админками, достаточно простыми, то есть это либо ларвелские стандартные какие-нибудь админки, там Yishn, вот такие сгенерированные штуки, либо там от Wordpress админка, либо от Btricks админка.

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

И это норма, это для бизнеса очень даже. Да, на самом деле, то есть я здесь соглашусь, что для админок до сих пор царство PHP просто отличное, в том числе в плане рендера. На самом деле мы ищем, пытаемся найти какое-то решение, чтобы на фронт-энде это было гораздо более экономически целесообразно делать. Потому что в этих админках мы...

Бывает, всё-таки упираемся в то, что их кастомизировать, нужно тебе какую-то закастомить страничку более-менее, и эти админки становятся очень не гибкими, когда ты пытаешься залезть в их фронтенд, который зачастую написан на, опять же, старом очень фронтенде, то есть там реально царство джекверии, вовсю, практически везде. Единственное, по-моему, исключение — это вот Laravel Nova, да, по-моему, она на вьюшке там сделана. Вот. Или с использованием вью, я точно не помню.

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

Hexlet (53:04.013)
есть много других там, там же Ларавелли и на других, на этих. Так, я немножко назад запрыгнул, вы сказали про статичные сайты. Вы же в курсе, да, что это вообще на самом деле последние годы, это новый тренд такой, целая ветка веба ушла, кстати, забрав ее у ПХП, это джемстек. Слышали о таком направлении? Да-да-да-да, но это то же самое, с чего, собственно, начиналось, то есть все оно идет такими ветками. Да, переосмысливается и возвращается, то есть не знаю там.

всякие jrpc это переосмысленные там rpc openop схемы это переосмысленные там vst или так далее и так

А ЦМС теперь называется No-Code. Да-да-да-да. Почти. Кстати, вот насчёт админок. Ты бы на какой админке делал админку? На каком фрейверке, Саш? Сейчас, наверное, я бы делал по-быстрому админку на E2, если мне бы там за PostRap-чёт очень быстро нужно было. Потому что там идеальные, на самом деле, круды, их можно быстро генерить, там есть шаблоны и вот...

То что я говорил там на супер быстрый старт, мы... Ну все равно нам frontend делает там на каком-нибудь там React или Vue или что-нибудь еще, то вот как раз у нас на front отдаст рестовые такие болваночки, которые очень быстро туда отдать, а на back отдаст плюс-минус готовые нагенерированные админки, которые потом можно кастомайзить, они тебе не будут ну палки в колеса вставлять, когда ты начнешь это все дело кастомизировать.

Самый большой плюс это то, что всю доменную модель, всю логику ты можешь писать как, собственно, тебе угодно. Я на самом деле не пробовал делать админки на И, хотя там в отделе есть, но именно я лично просто ручками не касался этого. А там, то есть ты игроб игры, когда ты делаешь какую-то сущность, она к ней же сразу рестапи и к ней же саму админку делается, правильно?

Hexlet (55:08.205)
Да-да-да-да, ну не само делается, G, это генератор, то есть ты ему кормишь модельку и он соответственно делает для нее крутовую страничку в админке плюс рестапе. Ну то есть более-менее декларативно получается все это делается, да? Нет, то есть это не декларативно, это ну как бы обычный код, просто она эту штуку генерит, она генерит код, то есть у нас не конфиг получается. Я понимаю, для меня как бы разработчика.

Для разработчиков не нужно там писать какие-то императивные связи между сущностями или просто писать их схему? Нужно, ну то есть мы пишем как разработчик миграции для базы данных, потом на основе этого мы суём это в генератор, он генерит нам модельку, мы её чуть-чуть там подправляем, суём это в генератор Курда и всё. У меня есть вопрос, а что не стоит писать на Битриксе?

Ты сказал, что вы смотрите, что некоторые проекты точно не подходят. Как вы определяете то, что сходу не стоит? Что стоит на кастомных вещах делать? У Bitrix один из важных тезисов. Мы говорили недавно про отминки, которые старые, как на E или на Bitrix. Они довольно-таки хороши.

И неплохо. У Bitrix она еще даже проще, чем какого-то фреймворка, и она гипче. То есть если у фреймворка там совсем простые крады, то у Bitrix можно с помощью его инфоблоков гораздо быстрее сделать какие-то абстрактные сущности, которыми достаточно удобно управлять. Причем там сразу и версионность, там ролевая модель к этим штукам вся очень сильная.

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

Hexlet (57:16.237)
либо там обычные крады или под даже более необычные сущности, вот как гибкие, как у битэкса с инфоблоками. Если они не подходят и нужно пилить, прям мы понимаем, что там кастома админка, то уже такой большой жирный минус, чтобы битэкс не использовать. Потому что, то есть, если тебе нужно пилить кастомную админку, ты понимаешь, что битэкс в админка к этому не подойдет, скорее всего тебе битэкс не нужен.

Слушай, в кастомной ты имеешь в виду даже один небольшой случай в этой вот кастомности и Bittrex уже это сильная помеха или же много кастома? Много, конечно же. То есть если тебе нужно там к одной сущности написать свою штуку, мы такую делали, там отдельную страничку Bittrex и делаешь, туда в реакцию вставляешь, как бы все хорошо. А когда сильно неудобно управлять контентом с точки зрения Bittrex, то есть ты понимаешь там...

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

то берешь Bitrix, переиспользуешь частично его готовый REST API и дописываешь тот REST API, который тебе нужен. В принципе, оптимально. Да, кстати, такой маленький нюанс. вот там ты упоминал, там Swagger для API, мы написали свой пакет на GitHub, он лежит для Bitrix, Swagger точно так же отлично дружится, Open API, аннотация, все описывается, все хорошо работает. Это классно. Так, ну что?

Что у нас получается в итоге-то? В итоге похоже, что есть место и для Bittrex, и для WordPress, и для Custom, и для Framework. Я так понимаю? И даже для PHP. Ну, для PHP тем более. В тему про уходящие поезда просто, когда я перестал писать на PHP примерно пять лет назад, все как бы во всем интернете кричали, что все PHP, он больше не нужен, он как бы устаревает.

Hexlet (59:32.173)
и чьё-нибудь другое. На самом деле мы видим, когда… ещё когда я начал писать на PHP 15 лет назад, на нём уже работала половина интернета. Вот. тех пор как бы сильность ситуации не изменилась. Поэтому, как мы видим, PHP живее всех живых, решений для него всё больше и больше. На вкусы цвет, и фреймворки, и CMS-ки, и что-то среднее между ними должно присутствовать. PHP умирал, PHP умирает, и PHP продолжает умирать. PHP будет умирать. Друзья, спасибо большое за эту дискуссию.

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