Ганин Роман

Есть-то оно есть, а вы пробовали что-то более-менее серьёзное на нём организовать? Мне, например, удобнее на ЛендКрузере ездить, не вижу смысла пересаживаться на Оку.

Минусуя @Pavel Lautsevich вы расписываетесь в собственной никчемности — Павел не критикует и не осуждает MODX, он субъективно советует, что «подсмотреть» у других, чтобы сделать лучше. Если бы MODX «был лутши всех!!!», мы бы тут не собрались. Проще учиться на чужих ошибках и успехах.

Сегодня общался с евангелистом GraphQL, говорит, GraphQL «мёртв»…

Субъективно. Мне тоже привычнее старый-добрый REST, но на четвёртую ночь «красноглазия» с зависимыми выборками понимаешь, что «лучше день потерять, потом за пять минут долететь». Оба решения имеют большое количество недостатков (докладов на эту тему за последние два года — на три сезона), так что тут нельзя оперировать понятием «лучше». если сделаем оба, утрём нос тем, кто «ниасилил».

Я бы склонялся к JSON-API (т. к. это надмножество REST) и GraphQL, потому что есть кейсы, когда его выбор оправдан. Для PHP есть готовые решения: thecodingmachine.io/graphqlite-graphql-in-php-easy, например, выглядят очень воодушевляюще. Спрос к GraphQL будет неизменно расти (маркетинг — такой маркетинг), так что решив эту задачу, мы закроем большой пласт потребностей охипстеревших фронтендеров (да кого я обманываю — я сам такой…).
Я в своих проектах для решения подобной задачи просто использую DSL (Loopback 4), который нивелирует разницу между выбираемой технологией под абстаркцию описания типов (по аналогии, как это делается в MODX, когда описывается схема таблицы в XML). В этом случае мы сможем решить ещё и проблему поддержки нескольких типов БД — MySQL, PostgreSQL, NoSQL.

Речь не про новые плагины для красивых галерей или генераторы формочек. Я о том, что, решая какую-то задачу, разработчик оперирует инструментами, которые оптимизируют его время: можно продолжать писать статичный HTML, вручную расставлять CSS-префиксы, писать jQuery-«простыни», но если бы старых подходов хватало бы для современных требований бизнеса, ни один новый инструмент не появился бы.
Веб-воркеры, сервис-воркеры, сокеты, модули, PWA, работа в оффлайне и т. д. — всё то, что будет иметь каждый конкурентный продукт в ближайшие годы. Конечно, все эти технологии не должны навязываться выбранной CMS/CMF-системой, но ещё хуже, когда они противоречат.
Восстребованной будет та система, которая минимизирует время + ошибки + порог вхождения + тестирование и отладку + кастомизацию и/или расширяемость. Я использовал MODX, когда для этих условий не было аналогов, но это время прошло. Быть разработчиком и не развиваться — значит, быть плохим разработчиком.

Лучше — точно нет, но тут вопрос не «как», а «что» — современные требования к веб-разработке сильно изменились за последние 3-5 лет и оставаться на уровне «личного сайта моего кота» — значит, быть неконкурентноспособным. Но с другой стороны, делая универсальное решение, можно «скатиться» в такой слой абстракций, что увеличит порог вхождения (взгляните на EmberJS — то, что в ближайшие годы будет добавлено в Реакт или Вью, «всё уже было в Симпсонах»). Но это уже меньшее из зол: обучаемость — хороший фильтр, что в своё время спасло MODX от превращения в Джумлу или ВордПресс. Нужны реальные кейсы, реальные проекты, чтобы понимать, к чему мы хотим двигаться, что видеть нового, сто оставить неизменным.

Не проблема, но с англоязычной аудиторией MODX могу общаться только в формате дринкапа — языковой барьер не позволяет. Ну и я определённо не смогу посвящать этому своё основное время — MODX у меня вообще не стоит в планах разработки.

О том и речь — нужно сократить информационный разрыв. Паровоз фронтенда на столько технологически ускакал вперёд, что и привело к подобной ситуации депопуляризации MODX — потребности клиентов растут быстрее, т. к. предложений на рынке веб-дева более чем достаточно. Как я уже сказал, я готов это всё объяснять и популяризировать, если в формате видеоконференций (типа AskMeAnything Ильи Климова) или лайт-толков на живых встречах (если вы из Питера).

На столько не смог оставаться безучастным, что даже восстановил аккаунт (давно покинул ряды активистов MODX, посвятив себя фронтенду, но продолжаю поддерживать старые проекты)…

Я верю в это сообщество, но, думаю, что правильный путь выбрать будет очень непросто. Некоторые решения (REST-расширение, например) вполне очевидны, но вот выбранная архитектура может больно «аукнуться» позже. Трендовые решения (React/Vue/Angular/Ember) дают быстрый старт, но имеют пару фатальных недостатков — они «смертны» (да, Реакт и Вью через 3 года станут жуткими архаизмами или на столько видоизменятся, что будут иметь мало общего с тем, что вы видите сейчас) и однонаправленны — выбирая архитектуру под React, мы практически полностью (ну или в большей степени) делаем её несовместимой с Angular/<ваш любимый фреймворк>.

Я не смею предлагать, но вижу наиболее сильный формат в поиске решений — дебаты. Т. е. должен возникнуть положительный конфликт, когда все заинтересованные стороны (а не один разработчик) принимают решение о векторе (или закладывают точку для ветвления/масштабирования). Своего рода роадмап, но не решений, а обсуждений: RestAPI — на каком языке (может, это вообще микросервис на Go или SaaS-платформа)? Какой API-фреймворк? Работа через API MODX или напрямую с БД? Типизация? Валидация? SDK? Админка — а что на счёт Headless CMS? Может, какой-то DSL для обратной совместимости? React/Vue/Angular/etc? Монорепозиторий (lerna + yarn workspace) или независимые компоненты?. Плюс такого подхода ещё и в том, что параллельно с доводами в пользу своего решения «кандидат» сам будет заинтересован в наибольшей понятности своего предложения. И сразу понятно, какие компоненты системы могут кем курироваться. Стабильно в течение какого-то времени (неделя? месяц?) «комитет» принимает решение (после того, как споры вокруг какой-то темы стабилизировались (утихли или разделилился на несколько лагерей).

Со своей стороны предлагаю опыт в клиентской и серверной шаблонизации, DSL, SSR, сборщиках, компонентном подходе и вёрстке, UX/UI.

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

документация по xpdo мало того что англоязычна, так еще и не полная

Отчасти согласен, документация — «слабое место» многих опен-сорсных продуктов — было бы время код писать, а уж на документацию и вовсе времени нет. Тем более переводить. Но вот по поводу «неполности» точно не согласен. А помните, что конкретно не смогли найти?

у всех minishop тормозит после 20000 товаров

Так это не имеет отношения к MODX. Вон на nevatrip.ru у меня 100k записей, а оптимизацией даже не занимался ещё.

но я до этого еще не дорос(

А вы попробуйте использовать «Битрикс-подход» к этой проблеме — оплатите работу профессионала. Уверен, будет дешевле аналогичного решения от 1С.

У вас какие-то «неправильные пчёлы» — в чём проблема хоть 500k товаров? Тормозит админка? Скройте позиции из «Дерева ресурсов». Медленная БД? Используйте memcached или аналоги, оптимизируйте запросы — у xPDO минимальный оверхед, а больше там ничего и нет. «Проблема» MODX не в том, что Битрикс предлагает лу́чшие решения, а в том, что у первый подразумевает наличие «поля для манёвров» — есть проекты на MODX и на 5 млн. ресурсов, а тормозов ноль.

Bitrix на голову выше.

И на 10 порядков дороже =)))

Потому что админка MODX удобна моим клиентам (серьёзно, некоторые прям чуть ли не посреди ночи звонили со слезами и соплями от радости, как им приятно работать с MODX после ДруМла Прессов на Битриксе)…
Потому что «взять и переписать» звучит для них гораздо страшнее, чем «мы оставим всё, как есть, но теперь ваши странички будут открываться быстрее и без перезагрузки».
Потому что MODX хоть и достаточно монолитный (в сравнении с всякими Phalcon'ами, Laravel'ами и прочими Yii на composer'ах), но значительная часть архитектуры более чем оправданная, особенно учитывая, сколько времени CoreTeam поддерживает обратную совместимость 2.x-поколения.

Конечно, многое зависит от опыта и «базы» — я пришёл в разработку именно благодаря MODX, он (она?) обеспечил планомерный и правильный «вход в профессию» („Привет!“ «разработчикам мышкой» на WordPress). Тем, кому «повезло» больше и имеет за плечами фундаментальные знания паттернов, алгоритмов и других «интегралов», конечно, сподручнее использовать что-то более низкоуровневое, но это не принижает заслуги MODX и сообщества.

Очень надеюсь раскрыть все эти темы на 2017.modxpo.eu/

Парсеры этих шаблонизаторов не работают в рантайме. Я, наверное, сжато выразился, но я говорю про ситуацию, когда нужно менять клиентскую часть (вёрстку), не трогая способ передачи данных. Сейчас, например, я захотел отказаться от Bootstrap в пользу Foundation (их же ещё используют, верно?) — мне придётся править и шаблоны, и чанки, и `@INLINE` сниппетов, т. е. происходит смешение представления и логики. Т. е. я не имел в виду, что серверная шаблонизация — «Фу», и всё нужно рендерить на клиенте. Реакт со своим JSX идут лесом, я вообще считаю этот синтаксис издевательством над разработчиком: «с чем боролись. на то и напоролись», вместо опостылевшего HTML (который за годы опыта писать уже тошно), мне предлагают не менее избыточный JSX, который ещё на сервере рендерить — отдельный геморрой.
Сейчас у меня есть удачный кейс, когда шаблонизатор отделён от данных дополнительным слоем абстракции, где происходит нормализация и весь шаблон на выходе имеет JSON-структуру, на которую применяются чистые функции. Что это даёт (при наличии опыта и понимания):

* отделение логики от представления, возможность фронт-енду и бэк-енду работать параллельно и независимо, использование mock-объектов для данных, если сервер ещё не готов, бэк-енду не нужно думать о том, как «сверстать всё это, чтобы было красиво» — он работает над правильной архитектурой;

* более высокая скорость отдачи страницы на клиент (да, MODX можно ещё ускорить, и от этого аж уши закладывает!), при этом рендер по-прежнему происходит на сервере (привет, SEO), а при правильном выборе шаблонизатора, код может быть изоморфным — получаете SPA-приложение «из коробки» (те самые «реактивные интерфейсы»). Если не ошибаюсь, Николай @real-Fi1osof Ланец неоднократно рассказывал, что шаблонизатор MODX — bottleneck производительности;

* реиспользование. У MODX в этом плане пока слабо, он довольно монолитный, но фронтендовский компонентный подход во всей красе.

Из возможных минусов: наиболее быстрый шаблонизатор сейчас написан на JavaScript, попытки переписать XJST на PHP, Python и даже Go потерпели фиаско. Сейчас JS, де-факто, стандарт в мире фронт-енд-разработки (рубисты больше не фыр-фыр), т. е., конечно, я не предлагаю начинающим разработчикам делать лендинги на таком стеке, но любой более-менее сложный конкурентный (!) проект, который вы планируете поддерживать или цикл разработки которого больше 5-6 месяцев неизбежно будет обрастать легаси-кодом и лишь правильная декомпозиция позволит этого избежать.

Всё, что происходит с плейсхолдерами [[$чанков]], [[сниппетов]], [[*ТВшек]]. Шаблонизатор, работающий на регулярках с кратным обходом по определению медленнее AST. Вопрос в том, есть ли такие шаблонизаторы, кроме XJST? Более быстрого и одновременно удобного шаблонизатора (в составе БЭМ-стека) я пока не встречал.
Т. е., если рассматривать MODX исключительно как админку + RESTFul API-сервер, можно наконец-то забыть об оверхеде переноса и отладки клиентской части сайта/приложения на MODX, потому что MODX будет заниматься только тем, чем и должен заниматься бэкенд — данными, не тратя время на шаблонизацию.

Да, MODX, в принципе, всё равно, как вы его «вертите» — из последнего:
— lavkaschastya.com/
— www.schastye.com/
React, нестандартные наборы товаров, вёрстка любой сложности. Хочу ещё попробовать полностью отказаться от MODX-шаблонизатора, но подходящего проекта пока не было.

И в мыслях не было тыкать, я больше рассчитываю на то, что ссылку заметят другие, кто захочет разобраться. Я в своё время многое подчерпнул из статьи по установке MODX по cli напрямую из Git. Там и про безопасность тоже.