Postcss-modules как лучшая альтернатива bem?

Question

[Islam Ibakaev]

В поисках интересных postcss пакетов набрёл на postcss-modules
В общем, такая же тема что и css modules в reactjs(но то только в reactjs), а этот можно использовать везде, например, делая лендинг на вордпресс.
Просто обычно использую bem для имитации локальности кода, но bem просто набор правил, которым нужно следовать, а тут прямо bullet-proof решение. В reactjs если ты включил поддержку css модулей(в webpack), то следовать bem нет нужды. Выходит и с этим пакетом, если подтянуть в проект, то можно не париться с bem. Или я что-то упускаю?
p.s. Используете ли вы эту зависимость в разработке сайтов на вордпресс, как альтернативу методологии bem?

Comments

[sim3x]

Чем и что данный модуль упростит?

Пока что я вижу, что после него нельзя будет глазами понять, какой класс где лежит и по названию класса понять чем он занимается и даже не обфусцирует/сократит названия классов в собранном документе

[Islam Ibakaev]

sim3x, не совсем понял в чём проблема? ну кинули класс в mobile-menu.scss, к примеру, значит класс стилизует что-то в мобильном меню.

[sim3x]

Islam Ibakaev, те без мапы непонять даже куда примерно относится класс
Супер
Хороший модуль

[Юрий]

sim3x, я думаю так: если у вас несколько страниц - ничего этот модуль не упростит. А вот если страниц куча и классы могут уже "пересекаться" (что конечно не есть хорошо), то тут и приходит на помощь CSS modules. Задача его: помочь front-end программисту не парится над тем, что некий класс будет где-то ещё использован. Он будет использован только в рамках определённого модуля (в масштабах уже CSS).

[sim3x]

Юрий, если фронтенд настолько не парится - ему нужно пересматривать зп или выгонять

Теперь по теме.
Когда страниц много - нужно унифицировать его блоки, потому у верстальщика на нормальном большом проекте никогда не возникает проблема с именованием - все или придумано за него, или есть стайлгайд по именованию

И дело ведь не в именовании, а в том, что такой модуль поощряет говнокод и не дает никаких плюсов взамен

Answer 1

[Игорь Воротнёв]

Во-первых, при чем здесь WordPress?
Во-вторых, если уж речь за WordPress, то он в некоторых местах свои собственные классы добавляет. Это надо учитывать.
В третьих, я бы за такие классы, которые данный пакет генерит, руки открывал.
В четвертых, а какой профит, особенно для лендинга где по умолчанию все классы будут использованы на одной и той же странице?
В пятых, с bem можно вообще не париться, это всего лишь одна из методологий / naming conventions.

Comments

[Islam Ibakaev]

Во-первых, при чем здесь WordPress?

ни при чём, просто в данный момент работаю с ним, вот и упомянул

Во-вторых, если уж речь за WordPress, то он в некоторых местах свои собственные классы добавляет. Это надо учитывать.

Ни совсем понял при чём здесь сей факт

В третьих, я бы за такие классы, которые данный пакет генерит, руки открывал.

а в чём собственно проблема с "такими классами"?

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

Тоже не понятно к чему это?

В пятых, с bem можно вообще не париться, это всего лишь одна из методологий / naming conventions.

Не пойму, а почему бы не попариться с bem, организация стилей не такая уж и плохая затея

[Игорь Воротнёв]

Islam Ibakaev,

Ни совсем понял при чём здесь сей факт

При том, что его стандартные классы не будутсоответствовать этому сгенерированному трешу. А их вам надо будет добавлять так или иначе.

а в чём собственно проблема с "такими классами"?

Они не human-readable. Не maintainable. Машинная ерунда.

Тоже не понятно к чему это?

Вопрос в том, к чему эти танцы с компонентами вообще? Особенно для лендингов. В чем профит такого подхода, что вы выиграете?

Не пойму, а почему бы не попариться с bem, организация стилей не такая уж и плохая затея

Я не говорю, что организация стилей плохая идея. Я говорю, что бэм - не единственная (и даже не самая популярная) методология. Методов организации стилей много, не бэмом единым живет мир фронтенда.