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

Я был бы очень признателен, если бы здесь написал свое мнение главный разработчик

Очень сомневаюсь, что Fuze станет отвечать мимо проходящему, которому вдруг захотелось высказать свое безответственное "ФЕ"

Да и в чем "изголение"?
Человек сам создал свою тему, задал тон и направление, а мы пишем свои мнения...

А самому лень удаляться?

letsgo к этому вопросу подошел с пониманием:

Быстро сдали нервы. Первые вопросы зачем и почему и вы уже просите удалить вас. А зачем вас удалять, пройдёт чуть время отойдете от дискуссии такой "тяжелой" и собственно может захотите остаться

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

Всё перечисленное вами — модно, классно и современно. Вот только не будем забывать о такой вещи, как порог вхождения. Целевая аудитория InstantCMS — это не фронтендеры с десятилетним стажем, а различные энтузиасты — мелкие предприниматели, городские активисты, просто люди, которым быстро нужен хороший сайт на своем сервере. Знаешь HTML и базовые основы PHP? Ты уже способен построить на InstantCMS именно тот сайт, который тебе нужен. В этом весь смысл.

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

Когда-то друг попросил меня помочь ему с шаблоном на сайте с установленным InstantCMS

У меня вопрос, как нижеизложенные 100500 букв вам помешали помочь другу с шаблоном?

если нужен только новостник, без сообществ/пользователей/блогов

А вот это вообще интересная конечно претензия.
И кстати до сих пор не могу понять, почему многие так упорно стараются делать на инстанте все подряд: от личного блога до лендинга.
Имхо, решать задачу нужно наименее затратным путем, поэтому если нужен новостной сайт — то зачем брать инстант и выключать в нем 95% функционала?
Есть куча cms для создания интернет-магазинов — почему бы не взять их и не поотключать там весь магазинный функционал, оставив только скаченный отдельно модуль блога?
Да и кстати, все нормально убирается. Группы, фотоальбомы, блоги и т.д. отключаются.

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

webpack, как вы правильно заметили, бандлер — задача которого собрать воедино ваш проект. Каким чудом конечный пользователь будет собирать или пересобирать систему после очередной установки какого либо дополнения?
Для разработки у себя на локалке использовать webpack или любую тулзу вам вроде ничего не мешает.

Использовать .pug шаблонизатор

я лично не сторонник его, мне боьше Zen Coding нравится. Т.е. делаем как удобно вам или оставим более традиционное решение?

Разумеется, только БЭМ и ничего другого.

Полный стек БЭМ технологии предлагаете юзать или только классы называть в соответствии с нотацией? А как же препроцессоры?
И вообще, зачем вам БЭМ-костыль если есть веб-компоненты и shadow-dom?

Использовать rem-единицы

Зачем вы себя так ограничиваете? Есть еще %, em, vw, vh, vmin, vmax и самые обычные пиксели также часто нужны ;)

Привязка к DOM-у на основе либо через js- префиксы, либо через атрибуты data-js

Это вы про 2019? У нас тут про привязку не задумываются)) или двусторонний биндинг или односторонняя привязка с событиями наверх...

Грамотный tree-shaking, прямо уже из коробки, приятно удивит конечным размером бандла

Осталось чтобы вендоры допилили свои либы для грамотного tree-shaking'а. Пока плачевно все.

Перейти полностью на иконочные шрифты, которые собирать динамически из svg

Снова вспомним как шел 2019й год, Мир увидел расцвет фронт-разработки как никогда ранее…
Иконочные шрифты? Серьезно? Прогрессивный мир SVG спрайты юзает

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

Тоже немного заглядывал под капот первой ветки и связанность там мне показалась намного сильнее. И это сказывалось на сложности поддержки допонений и их обратной совместимости.

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

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

Резюмируя… Вы предлагаете сдеать из ЦМС — фреймворк. Но уже есть Symfony, Laravel, Yii и др. Стек технологий на котором работаете вы, не всегда будет удобен другим разработчикам, да и фреймворки стараются не диктовать каким инструментом пользоваться девелоперу.

Соглашусь что менять можно много чего! Сам неоднократно размышлял что и как лучше переделать)) Но от таких переделок на выходе получается уже какая нибудь InstantCMS 3+ (с потерей обратной совместимости по дополнениям). Пилить все в одиночку уйдет море времени, по завершении которого уже пора будет начинать InstantCMS 4 =)

Всегда поражали люди раздающие советы разработчику, о том как ему правильно разрабатывать тот или иной проект, каждый волен делать так, как считает правильным. Усложнение кода, повысив его актуальность в пространстве новых технологий, верно замечено, приведет к оттоку пользователей от проекта, в сторону более дружелюбных CMS. Да система не совершенна, да еще есть куда расти как движку, так и компонентам, да много плохого кода (сам его пложу иногда), но в этом и есть instantCMS2. Применив вышеизложенные советы, да, это будет уже другая CMSрешающая другие задачи и совершенно для иного сегмента.
ЗЫ. Спасибо проекту instantCMS, который привел меня в веб из десктоп =)

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

"Не следует устанавливать свои правила… там, где они уже давно сформулированы." © Дед
Вообще тема интересная, только ничего не понятно…
Мне инстантсмс нравится, в любом случае!