Забыл отметить конкретно про node.js. Стоит отметить, что приложение node.js не завершается, пока есть какие-то сервисы, подписанные на события (т.е. listeners). Это могут быть как события сети (открытые сервера с ожиданием подключений и данных), так и события диска, и внутренние тоже (process.nextTick в т.ч.). Технология достаточно молодая и выработанных решений не так много, и следить за ними лучше головой разработчика.
Кроме того, процесс может слушать сигналы, которые придут из оси, и у ноды есть для этого средства из коробки `process.on('SIGINT', cb)`. По аналогии с nginx, apache, и другим стандартным ПО можно подписаться на всякие SIGHUP, SIGUSR1/2, и другие сигналы, чтобы перезагружать конфиги приложения, рестартовать его, и т.п.
@Zoxon мы уже свой написали, нет документации, сложно объяснять, потому что всех возможностей, полной цветовой палитры бэма в своем велосипеде добиться сложно. Но работает, и стало намного легче. Это в любом случае лучше, чем вообще без него.
@bezymenka Препроцессоры (Styl еще) — это другое. Но часто препроцессоры только сбивают с толку, потому что бэм отчасти решает похожие задачи, которые им поставлены, правда совсем другим путем.
@daMage но не только, на самом деле. Оно еще и рассказывает про более сложные конструкции, и правила, которые избавляют от многих проблем в html/css/js в долгосрочных проектах. Цена — небольшой оверхед по времени. Но при соответствующих навыках — оверхед часто превращается в экономию.
@daMage бэм говорит, если не вы хотите того, то делайте так, если не хотите этого — то делайте так. Фактически это руководство молодого бойца с описанием всех подводных камней, которые любят совершать начинающие, поскольку безоговорочно верят в CSS/HTML или по иным причинам.
При чем, материалами и примерами по каждому пункту интернет изобилует, нужно только захотеть их поискать и сделать это ;-).
@arvitaly @minkv Это тоже самое, что говорить: "Машины плохие", или "Отвертки не очень". Во-первых, бэм это методология, а не технология. Это набор рекомендаций, следование которым заметно облегчает долгосрочную поддержку проекта за счет небольшого оверхеда по времени. Но оно того стоит. Во-вторых, вы действительно не ответили на вопрос, а хотелось бы слышать контретику. Если вы считаете, что она плохая — стоит говорить про конкретные отрицательные стороны, или отрицательный опыт.
А отрицательные стороны действительно есть: будь-то достаточно высокий порог входа в фул стек, потому что использовать длинные имена угнетает, и баги, недодумки, однобокость в реализациях инструментов (bem-tools, enb), и непринятие большинством декларативного подхода после неудачного опыта с xml+xslt, практически все проблемы которого решены в xjst, и разные другие. Но даже при этих минусах, о которых вы, вероятно, не думали, БЭМ стоит использовать, плюсов в разы больше.
@safright .active удобнее только тем, что писать короче. Но хочешь быть хорошим разработчиком — думай о коде, а не о том, как его набирать. И если проект не сделал и забыл — то лучше использовать полные названия состояний, т.е. .menu__item_active или _state_active, потому что вернувшись к проекту через какое-то время вы просто можете забыть о той куче этих состояний, которые в проекте есть. Грабли проверены временем, слушать совет или нет — дело каждого, у нас свобода, никто никого не заставляет ;-)
По (2) это у вас одно и то же, только первое конфликтовать не будет. Сравнение некорректно.
Нужно так: .menu__item_state_active или (.menu__item_active) vs .menu__item.active, — т.е. разница 1 класс против 2, или _ вместо точки.
Но бонусом вы получаете уникальность класса состояния active для каждого элемента любого блока. Т.е. ничего нигде не поедет по недосмотру.
@Steely Возьмем по максимуму — минимум картинок, все в css3. Средний сайт, 5 разных кнопок с закруглениями в нескольких цветовых темах и нескольких размерах. 5х3х3 = 15 штук. Градиенты, шмадиенты, прочее — ну еще штук 15.
Скажем, -30 запросов с куста, +графика из n килобайт превращается в ~2n сотен байт, или меньше. Всякие спрайты в css base64 и в gzip. По объему никак не должны проиграть.
В идеале у нас останется 3 запроса к серверу, html, css, js. Скорость отрисовки в целом сайта уменьшится, но увеличится скорость отдачи и первый цикл рендера будет много раньше.
Как бы вы не крутили веб-сервера и keep-alive в браузере — каждое подключение все равно будет занимать весомую часть времени запроса, в общем, тут не должно быть споров. И миллисекунд очень много выиграется.
Если все в совокупности сложить, должно быть до 50-70% сокращения времени на загрузку. Но немного вырастет время на отрисовку.
Даже если в итоге получится 20-30%, это 200мс→150мс. Весомо.
Есть такое свойство transform, оно позволяет делать skewY: codepen.io/agelber/pen/tyfku
Подробнее, например, тут: htmlbook.ru/css/transform