Аргументы против InstantCMS или почему не все так гладко

Вечер добрый.

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

Когда-то друг попросил меня помочь ему с шаблоном на сайте с установленным InstantCMS, осадок остался не самый лучший, ну да и забылся. Но на днях у нас возник спор: он утверждал, что это лучшая CMS. Нет, всерьез так, с фанатизмом! Не прореагировать на такое заявление я не мог, потому распишу список "что не так" публично. Верю, аргументы будут услышаны, и, надеюсь не в меньшей степени, натолкнут на какие-то мысли и/или действия.

% Шаблоны %
Шел 2019й год, Мир увидел расцвет фронт-разработки как никогда ранее, казалось бы, вот теперь-то заживем. Вот-вот поспел es9, так здоровски повышающий качество и скорость написания js-кода, и не менее здоровски компилируемый babel-ом в es5, и этот всем знакомый уже из es6 синтаксический сахар OOP, и модули, и элементы функционального программирования! Бери да делай шедевр на десятилетие вперед… В это же время БЭМ стандарт де-факто, во весь ход идут если не гриды, так флэксбоксы. Кого-то из мира Python вдохновил HTML и вот — шаблонизатор Pug любит и лелеет каждый: ох эта модульность, а mixins, а layouts! Обращение к дом-узлу по классу без префикса js- теперь моветон, а это значит годы набитых шишек не прошли зря.
Но это в совершенно параллельной от InstantCMS реальности, здесь ничего из вышеперечисленного днем с огнем не сыщешь. Наверное, этого стоит бояться: обновление шаблона, в котором изменено чуть больше, чем просто стили, не может не быть болезненным и не плодить г-кода линейно, что, собственно, дополнительных доводов не требует — все на виду.

Критикуешь — предлагай.
1) Выбросить дефолтный шаблон на помойку
2) Создать webpack-проект под новый шаблон:
— Использовать .pug шаблонизатор, вынести виджеты и компоненты каждый в свои темплейты, под текущую структуру. По факту компилировать в php-файлы: читать, создавать готовый к употреблению шаблон при сборке на лету. Разумеется, только БЭМ и ничего другого.
— Файлы css хранить только в папке со стилями, разбить на компоненты: один темплейт, один файл стиля. Использовать rem-единицы и flexbox/grid, css-variables. Webpack, конечно, все склеит, а плагины postcss решат проблемы кроссбраузерности.
— JS переписать также с нуля, ибо текущий вариант ну… сякое… недореализации божественного объекта. Пора модульности взять верх. Привязка к DOM-у на основе либо через js- префиксы, либо через атрибуты data-js, тогда при редактирования темплейтов не будет возникать опасений похерить что-то в JS.
— Вендоры JS и CSS тянуть из npm, разумеется. Грамотный tree-shaking, прямо уже из коробки, приятно удивит конечным размером бандла — кто по pagespeed плачет?
— Перейти полностью на иконочные шрифты, которые собирать динамически из svg. Все изображения прогонять через imagemin.
3) Избавиться от html-разметки в файле-хелпере: ведь ей там не место, правда?

Это даст: удобство разработки, удобство создание новых шаблонов и их обновлений (= по большей мере переписать CSS в контексте БЭМ-а, и этим самым изменить его до неузнаваемости), в общей массе качественных и долгоиграющих.

% PHP %
Тут буду краток: тянуть вендоры через composer куда приятнее, да и обновлять тоже. Разворачивать систему таким образом было бы приятнее не менее.

% Система в общем %
Связанность здесь сильная, отключить компоненты просто и безболезненно нереально — если нужен только новостник, без сообществ/пользователей/блогов, — нога будет прострелена. Скачал ради интереса первую ветку — там этой проблемы вроде как и нет (извините, особо в нее не вникал). Политика второй ветки движка ведь не звучит как "пользуйся всем или уходи"?

% Каталог — дополнений %
Бесплатные обновления тянуть сразу с гита автора, и в принудительном порядке заставлять добавлять их таким и только таким путем. Да, повысит уровень вхождения, да, отнимет пару дней у автора движка сделать связку с API гита — но многие ведь страдают из-за некачественных разработок? Может, кому-то не стоит их выкладывать пока что?


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

Всем спасибо, всем добра.

1) Выбросить дефолтный шаблон на помойку

Согласен, но прежде надо найти замену.

2) Создать webpack-проект под новый шаблон:

Почему webpack, а не gulp, grunt, browserify и прочая нечисть?

Использовать .pug шаблонизатор, вынести виджеты и компоненты каждый в свои темплейты, под текущую структуру. По факту компилировать в php-файлы

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

Файлы css хранить только в папке со стилями, разбить на компоненты

Это дело привычки.

один темплейт, один файл стиля

Тут можно не согласится, так как не на всех страницах нужен код, который используется только в одном виджете на "задворках" сайта. А объединить файлы в один перед выдачей можно в любое время галочкой в настройках сайта.

JS переписать также с нуля

Согласен.

3) Избавиться от html-разметки в файле-хелпере: ведь ей там не место, правда?

Перенесите хелпер в свой шаблон, там ему место.

Тут буду краток: тянуть вендоры через composer куда приятнее, да и обновлять тоже.

Тяните, кто мешает, в коробке это уже заложено.

Бесплатные обновления тянуть сразу с гита автора, и в принудительном порядке заставлять добавлять их таким и только таким путем. Да, повысит уровень вхождения, да, отнимет пару дней у автора движка сделать связку с API гита — но многие ведь страдают из-за некачественных разработок?

Как выкладывание кода на гите, повлияет на качество этой разработки?

Спасибо за отзыв.

Благодарю за ответ. В секции "Критикуешь — предлагай" удобно писать императивно, легче нарваться на спор — в нем же рождается истина?

Почему webpack, а не gulp, grunt, browserify и прочая нечисть?

Таки это бандлер, gulp/grunt — task-менеджеры. Webpack умеет отлично собирать код и имеет самую богатую экосистему, и, кажется, ляжет на дно нескоро (чего не скажешь про Gulp — последний релиз год назад, многие еще пользуются версией 3.9.1, которой подоспело 3 года). Вместо webpack выбрать browserify/parcel/rollup...? — Почему бы и нет, тоже хорошие инструменты (будем надеятся, проживут долго!).

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

Значит, Вам не объяснили или не решили за нужное разобрать. Осмелюсь показать разницу через синтетический пример:

равняется

А теперь представьте масштабы шаблона — что проще поддерживать в дальнесрочной перспективе?

Это дело привычки.

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

Перенесите хелпер в свой шаблон, там ему место.

Хорошее наблюдение, но посыл был не в этом.

Тяните, кто мешает, в коробке это уже заложено.

Вы безусловно правы. Думал в этот момент о подходе BoltCMS, моя ошибка.

Как выкладывание кода на гите, повлияет на качество этой разработки?

Для начала отсеит совсем уже плохие работы — отсылка на уровень вхождения. А в дальнейшем перспектив широкое поле — автоматичкое подтягивания обновлений, таб issues в деталке товара, это навскидку. Работа с git API и фантазия — и качественно, как для разработчика, так и для пользователя, это выход на новый уровень.

По шаблонизатору уточню: подразумеваю шаблонизатор только для шаблона, не для CMS.

Таки это бандлер, gulp/grunt — task-менеджеры. Webpack умеет отлично собирать код и имеет самую богатую экосистему, и, кажется, ляжет на дно нескоро (чего не скажешь про Gulp — последний релиз год назад, многие еще пользуются версией 3.9.1, которой подоспело 3 года). Вместо webpack выбрать browserify/parcel/rollup...? — Почему бы и нет, тоже хорошие инструменты (будем надеятся, проживут долго!).

Это был риторический вопрос. Каждый работает с тем инструментом, в котором разбирается и с которым чувствует себя уверенно. Поэтому многие тащат Gulp ему подобные. Завтра появится "аляСуперWebpaсk" вы не сразу броситесь все проекты переводить на него с Webpack.

По шаблонизатору уточню: подразумеваю шаблонизатор только для шаблона, не для CMS.

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

+foreach($list, $item)
+b.blog-item
+e.image(src='$item.image')
+e.H4.title
+e.icon(src='/icon.svg')
| $item.title

Для начала отсеит совсем уже плохие работы — отсылка на уровень вхождения.

Я бы сказал не отсеит, а задержит появление плохой работы на время регистрации автора на гите. Плюсы от использования API гита есть, но в целом он не решит проблем с качеством разработки. Мне ничто не мешает выложить говнокод на гите.

За день экосистема к новому инструмента не переметнется, очень уж категорично — но, знаете, да, если спустя три года вебпак умрёт (тьфу-тьфу), то перенесу на новый инструмент, если от этого качество приложения станет лучше.

По гиту и так, и нет. Не гарантия, но и как "капча" сойдёт, имхо.

равняется

Вы взяли кусок кода. По нему проще читать и поддерживать 70% начинающим вебмастерам именно второй вариант с html кодом.

Я бы лишь старался вывести вывод в отдельные файлы, которые не мешали бы общей структуре при обновлении движка и соответственно работало бы на многих версиях.

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

Выбросить дефолтный шаблон на помойку

Чем он Вам помешал?

Связанность здесь сильная, отключить компоненты просто и безболезненно нереально — если нужен только новостник, без сообществ/пользователей/блогов

Цитата с главной "Создайте сайт любой сложности — от визитки, до соцсети
В комплекте есть всё для создания любых веб-сайтов"
Т.е. как бы сразу соцсеть. На то и сделан упор.

@dulu:
Выбросить дефолтный шаблон на помойку
Чем он Вам помешал?

demo.hostcms. ru для примера

Связанность здесь сильная, отключить компоненты просто и безболезненно нереально — если нужен только новостник, без сообществ/пользователей/блогов

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

Выбросить дефолтный шаблон на помойку

Ну на холяву и уксус сладкий! А так если по человечески доработать то вполне сойдет на первое время и стоит понимать что так или иначе для каждого проекта нужен индивидуальный шаблон и стандартный не для всех подходит проектов.

В дефолтном фон на белый сменить и тд — все правильно. Зачем дорабатывать если на других cms не нужно дорабатывать ?
ov.instantcms.com.ua есть сложность сделать примерно такой без анимации? Сейчас встречают по одежде и провожают по одежке.

demo.hostcms. ru для примера

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

Если вы пойдете в Энтерпрайз, там вообще третье решение будет. Это как машину обслуживать, самому у дядяи Васи или у другого дяди Вани или купить новую =)

Значит, Вам не объяснили или не решили за нужное разобрать. Осмелюсь показать разницу через синтетический пример:

Напишу как НЕ профи (но пользователь системы) коротко...
Многое из того что вы предложили выше, понимаю Ваш посыл идти в ногу со временем.

НО:
Как ни странно, это не вдохнет новую жизнь и развитие, а скорее убьет систему развитие и сообщество.
Да, это повысит уровень вхождения, но скорее всего на столько, что входить станет практически не кому...

А к этому еще наложится не возможность мне (читайте большинству) как простому пользователю быстро (без обращения к спецу) сделать мелкие правки при необходимости. А значит проще найти систему понятную для использования и уйти...

Итог — люди просто начнут уходить. ИМХО вот это и называется, "хотели как лучше, получилось, как всегда".
Инстант тем и хорош, что в нем сбалансировано (может быть не совсем) доступность понимания и использования большинству, уходить от этого — убивать систему.

ЗЫ: И да… можно конечно аргументировать, конкурентоспособностью с другими, что новое это прогресс, а старое — застой.
Но ИМХО у каждого должна быть своя ниша, и Инстант занял свою и за это ого выбрали его пользователи.

Добавлю еще показательный пример перехода с 1-й на 2-ю ветку...далеко не все решили переходить… некоторых даже такие перемены не устроили…

kirkr почему не может быть современный и красивый (для этого сменить фон и убрать синие блоки) шаблон для блога, визитки, новостного сайта или доски объявлений ?
demo.instantcms.ru/board почему на демо нет больше полей для фильтра? Почему в каталоге нет Поля join ?

kirkr чем шаблон новостного сайта, доски отличается от шаблона интернет-магазина ?

Я против goodmade ничего не имею. Почему instantcms2. ru с таким содержанием?

Почему в каталоге нет Поля join ?

В каталоге, много чего нет, видимо порог вхождения не прошел ))).

видимо порог вхождения не прошел

а я два года думал как сделать по-человечески фильтрацию по записям.