Алексей Николаев

Постареть и понять пока хипстеры дрочат на говнокод , старые задроты выкатывают прототип и получают финанирование.

На самом деле всё проще, достаточно использовать модификаторы:

<!-- Первый слайдер -->
<div class="slider slider_promo">
    <div class="slider__track">
        <div class="slider__slide"></div>
    </div>
    <div class="slider__arrows"></div>
</div>

<!-- Второй слайдер -->
<div class="slider slider_grid">
    <div class="slider__meta">
        <div class="slider__description"></div>
    </div> 
    <div class="slider__track">
        <div class="slider__slide"></div>
    </div>
    <div class="slider__arrows"></div>
</div>

- Можно ли присваивать уникальным для каждого конкретного блока элементам только класс этого самого конкретного блока? Как в коде выше, я не присвоил элементу .slider-grid__meta класс .slider__meta.

Ну вообще-то предполагается, что составных блоков не будет. Вообще. Иначе они становятся зависимыми друг от друга, а с точки зрения БЭМ, это неправильно.

- Можно ли красивее? Остается такое чувство, будто наделал костылей. Как реализовали бы схожую задачу вы?

Как вариант:

<div class="slider slider--promo">
    <div class="slider__track">
        <div class="slider__slide"></div>
        <div class="slider__slide"></div>
        <div class="slider__slide"></div>
    </div>

    <div class="slider__arrows"></div>
</div>

<!-- Второй слайдер -->
<div class="slider slider--grid">

    <!-- Набор уникальных для второго слайдера элементов -->
    <!-- ВАЖНО: теперь они не уникальны, но в первом случае мы их просто не используем, можно сказать это "опциональные" элементы -->
    <div class="slider__meta">
        <div class="slider__description"></div>
    </div> 

    <div class="slider__track">
        <div class="slider__slide"></div>
        <div class="slider__slide"></div>
        <div class="slider__slide"></div>
    </div>

    <div class="slider__arrows"></div>
</div>

Плюсы

• -2 лишних БЭМ-сущности
  
• Не нарушается принцип независимости сущностей
  
• Меньше классов в HTML (такое себе, но да)
  

Минусы

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

Сначала память, потом ссд
теперь поясню. Хоть я и ярый сторонник ссд взамен хдд и рассматриваю хдд только как неторопливые хранилища данных (кино, архивы, бэкапы), практика показывает что малое количество памяти вызывает излишние обращения к файлу подкачки, что по сути порождает лишние операции, сказывающиеся на производительности. Когда достаточно памяти - система не дергает хдд для подкачки и общее впечаление от работы хорошее. Не сомневаюсь что можно поставить ссд и файл подкачки на нем будет работать быстрее, но я считаю, что если есть возможность не выполнять какую то работу, то лучше ее не выполянть, чем искать варианты как ее выполнить быстрее\менее затратно.
В общем ставьте память, а потом ради комфорта докупаете ссд, как будет возможность

Не путайте: мог бы сделать все сразу
и должен был сделать все сразу.

Хороший случай заработать бабло подвернулся - систему же вы знаете лучше кого либо.
Я бы не стеснялся в цене.

То что вы снесняетесь и считаете что все это обязаны делать бесплатно, то:

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

Как правило для большинства заказчиков вечная гарантия неподъемна по цене.
Им проще доплатить за доработки отдельно.

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

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

Сайт n лет выполнял задачу и устраивал заказчика. В чем проблема-то вообще?

Новые требования - новый заказ.

Работают бесплатно только индусы или школьники. Если вы к таким себя относите, тогда вперёд. А если нет выставляйте ценник.

Потому что элемент позиционируется относительно той стороны которую вы указываете.

Если left: 0; то элемент позиционируется слева, если left: -50%, то он позиционируется на 50% левее левой границы родительского блока, при этом margin-left отодвигает его на 300px правее, когда ставите left: 50%, то левая сторона элемента позиционируется по середине, а margin-left: -300px сдвигает его влево на 300px.
но вообще лучше использовать просто left: calc(50% - 300px); без margin-left.

Оперативы до 8 добавить и хватит

Думаете, 10 бесполезных ответов лучше, чем один бесполезный вопрос?

К тому же, тут и без новичков достаточно таких ответов, а с такими правилами тостер вообще в помойку может превратиться

переходи на авторизацию по ключам. причем тут какой-то диспетчер учетных данных?!

пароли в package.json - это как в рукав сморкаться: вроде бы, и ничего страшного, но...