Комментарии 37
Вместо (ИМХО ужасных) так называемых CSS Modules использую инкапсуляцию с помощью кошерных веб-компонентов, стили пишу на SCSS, и не вижу ни малейшего смысла ставить этот PostCSS, потом выбирать, ставить и конфигурировать тучу разнообразных плагинов для того, чтобы просто написать горстку CSS.
И да, изоляция с веб-компонентами получается полная, в отличии от того, что вы предлагаете. А ещё нативно поддерживается в Chrome и в течении года будет в других браузерах, не требует систем сборки и интуитивно понятен.
Именно из-за такого неестественного переусложнения у начинающих мозг закипает. Зачем столько всего делать, если можно ничего из этого не делать совсем?
Карма ушла в минус, что освобождает Хабр от моих открытий. :)
Я не трогал ни статью, ни карму. Мне не понятно зачем люди на столько усложняют себе жизнь, но если кому-то это нравится — то мне до этого нет большого дела пока меня не заставляют делать так же:)
Я бы посоветовал начать с http://webcomponents.org/
Лично мне нравится в качестве более высокоуровневой библиотеки Polymer (он ещё включает полифилы CSS variables и CSS mixins), но в целом можно брать как простой полифил WebComponents.js и писать на низком уровне, так и выбрать другую библиотеку, как то X-Tag или Bosonic (имхо Polymer удобнее и более зрелый проект).
Первый подход использует по сути стандарты, плюс PostCSS позволяет свободно использовать синтаксис «CSS4», который в обозримом будущем также станет стандартом.
CSS модули это стандарт? Веб-компоненты это стандарт, а про CSS модули не слышал, судя по ссылке из статьи это не идея W3C или браузерного вендора, это какой-то костыль чтобы писать CSS в JS O_o.
Вот о CSS4 первый раз тоже слышу, нет такой нумерации и не будет.
А с компонентами не так просто, особенно с библиотеками.
Здесь всё достаточно просто, осложнение было в том, что вендоры никак не могли договорится по поводу изначальной спецификации, так что немного затянулось, в Chrome уже давно есть то, что сейчас называется версией 0. По поводу версии 1 все уже договорились, и до конца года у всех вендоров должна быть как минимум одна версия поддерживающая эту версию спецификации.
Пример из недавней статьи: «Мы писали на Polymer 0.5, и, когда он стал deprecated (с выходом версии 1.0), перед нами встал вопрос — что же выбрать?».
Это потому что Polymer 0.5 и задумывался как эксперимент, он не был официально стабильным и заведомо было известно что в релизе будет не так. За время развития проекта набралось много опыта разработки приложений (в том числе в продакшене, о чём и речь в статье), и как разработчик, хорошо знакомый с обоими версиями (не работаю в Google, но вхожу в top-10 контрибуторов в сам Polymer, ещё не раз отправлял патчи в полифил веб-компонентов), могу сказать что версия 1.0 на голову выше как по скорости работы, так и по устройству и удобству использования.
Какова вероятность такого развития событий?
У нас всё ещё есть библиотеки и фреймворки, которые ничего общего не имеют с веб-компонентами. Как среди них выходят обратно несовместимые версии время от времени, так и в Polymer на каком-то этапе выйдет версия 2.0, ничего такого в этом нет. Сама спецификация достаточно стабилизирована и перешла в фазу реализации в Firefox, Chrome и Safari (в нём даже есть уже предварительная версия TP в которой можно поиграться со слотами), в Edge в приоритете, но ещё не начали разработку.
Вот как-то так если кратко.
Как-то обойдусь без CSS/JS/HTML в одном файле:)
Не работал. Мне очень нравятся идеи неизменяемости и чистых функций, однонаправленного потока данных и всё такое, я смотрел разные выступления по поводу React, особенно интересно было смотреть как Firefox Dev Tools на React переписывают.
Но вот глобальное состояние (в некоторых случаях) и вот эта каша всё в одном файле (всегда) это как раз то, что мы давно пытались искоренить, и что мне очень нравится в подходе с нативными веб-компонентами. А теперь приходят ребята в синих сапогах с маркетологами и такие, типа, типа забудьте всё что вас учили, всё что было плохо это на самом деле хорошо, вот как всё красиво в куче можно лепить. Для совсем простеньких компонентов оно ещё куда не шло (хотя чисто эстетически как-то так себе), но вот что-то более сложное я бы не стал на нём делать.
Само собой на каждый инструмент есть свой пользователь, просто мне он в некоторых аспектах совершенно не нравится.
Бизнес-логика отдельно.
/////Для совсем простеньких компонентов оно ещё куда не шло (хотя чисто эстетически как-то так себе), но вот что-то более сложное я бы не стал на нём делать./////
Вы правы. Но только есть речь о Реакте без его экосистемы (redux, graphQL и тд), которая как раз решает вопросы масштабирования.
////Само собой на каждый инструмент есть свой пользователь, просто мне он в некоторых аспектах совершенно не нравится./////
+100500 :)
как бы отлично
«Как бы», вот именно. Можно прекрасно держать вместе разметку и ее логику, при этом не вводя адский новый синтаксис и не пиша дивы и спаны в JS — чему пример как раз vue-loader.
Я только-только подружился с MDL. И снова надо пересаживаться, теперь на Polymer.
Да ладно, и autoprefixer не нужен? PostCSS все равно присутствует в проекте. Почему бы ему не отдать обработку CSS полностью, если обещает делать тоже самое, что и препроцессоры, но быстрее и с любыми капризами?
1) В статье про autoprefixer ничего не сказано, хотя я бы если и использовал его — то скорее при сборке production варианта (поддерживая IE10+ совсем не много префиксов нужно, так что несколько CSS mixins и вообще ничего не нужно)
2) Если присутствует — ОК, статья же, как мне показалось, предлагает замену SASS:
Прощай БЭМ
Прощай SASS
Хотя веб-компоненты на самом деле решают проблему BEM на корню (потому как BEM это хак, который проблему на самом-то деле совершенно не решает, стили остаются в глобальном пространстве), а не городят очередной костыль.
К тому же по поводу скорости — у меня SCSS компилируется мгновенно, вы же не пересобираете на каждый чих весь проект? А один файл, каким бы он ни был, собрать за несколько миллисекунд совершенно не проблема как мне кажется.
В статье про autoprefixer ничего не сказано, хотя я бы если и использовал его — то скорее при сборке production варианта (поддерживая IE10+ совсем не много префиксов нужно, так что несколько CSS mixins и вообще ничего не нужно)
Ну это очень спорно. Префиксов в моей верстке вагон с тележкой. И про autoprefixer в статье было.
То есть вместо того чтобы взять Stylus, который из коробки работает, как мне надо, я буду брать SugarSS, плагин для переменных, плагин для миксинов, плагин для функций и все это конфигурить под каждый проект?:)
Что такое в разы быстрее? Если проект собирается, скажем, не 2 секунды, а 0.2 — мне без разницы, я эти 2 секунды переключаюсь с IDE на браузер.
А зачем мне покупать автомобиль и обслуживать его, если я могу на лошадях ездить? :)
В контексте Метеора достаточно подключить пакет juliancwirko:postcss (если CSS-Modules — это зло, в чем убедили выше).
А в чем таком меня Stylus ограничивает, скажите пожалуйста? Переменные, миксины, функции и удобный синтаксис есть — что мне еще надо?
Я, как и все, люблю новые технологии и мегаконфигурабельные общие библиотеки всего. Я соскочил на Stylus, как только его увидел, например. Но в данном случае я не вижу профита. Ок, я не супер-верстальщик и многого не понимаю в волшебном мире CSS, я все больше по JS, но если бы мне, как лошадевладельцу, предложили заменить мою лошадь на НЕХ, которая будет точно так же жрать овес, таскать телегу и гадить навозом, но которую надо сначала еще собрать из четырех частей и отдебажить — я бы долго недоумевал. Тут ведь нет такой разницы, как между plain css и препроцессором.
Тот же автопрефиксер начинал свою жизнь как отдельная либа, живущая без PostCSS-экосистемы и никому это не мешало.
Meteor + CSS-Modules + SugarSS