Вы не правы. Можно сколько угодно защищать свои вредные привычки, лень и невежество такими некорректными и якобы красноречивыми-убедительными примерами, но, на самом деле, все это перепевы одной и той же очень старой песни: "Зачем мне препроцессор, если есть поиск в текстовом редакторе?". И со становлением компонентности и CSS-in-JS для нее в качестве мейнстрима данный избитый шлягер становиться снова популярным, топовым. Но, по сути, это риторика уровня: "Зачем мне автомобиль, если уже есть велосипед — он и для здоровья, геморроя, извините,) полезнее?", или "Зачем мне мобильный телефон, я все равно из дома очень редко выхожу?" — ну, то есть, некоторый солипсизм в восприятии, если утрировать. Крайне субъективно. Действительно — если кажется что не сильно нужно, не возникает мощного запроса, нет задач которые это требуют — не надо и использовать, конечно! Это важный принцип — используйте только те инструменты которые вам подходят и необходимы. Я и сам редкий консерватор-ретроград, в каком-то смысле, например, завел смартфон, кажется, только лет 5 назад, когда уже вовсю делал суперадаптивные дизайны для браузера с помощью инспектора — до этого юзал кнопочный.
Конкретно по вашему примеру: вы ошибаетесь. В хороших дизайнах для веба, особенно — интерфейсных, ну просто не может быть "очень много" разных цветов. Вы правда уже много верстали? Хороший гайдлайн обычно содержит — "основной-брендовый", "дополнительный", от силы еще парочку вспомогательных и "набор серых" — все. Ну и по функциональным ролям: цвет текста, светлый текст, цвет бордера, может — плейсхолдеры в контролах… Всякое бывает, встречаются исключения, но в основном это так. И меня как раз обычно дико бесит когда я нахожу в макетах "чуть-чуть другие значения" — особенно с серыми это часто бывает… Нужно мыслить правильно, прежде всего — цветов в хорошем интерфейсе должно быть очень немного и они должны быть точно "одни и те же". Если вы абстрагируете их — вы сможете легко их менять (например — переиспользуя компоненты на новом проекте).
)))) Ну вот такой характер, что поделать — все равно "руки чешутся", ну и если "есть что ответить" — нужно отвечать… Но — правда некогда, надеюсь, вы не мой проджект-менеджер. )))
Ну вы, видимо, не верите что у меня также уже был самый разнообразный опыт, я приходил и уходил, очно и удаленно, и всякого насмотрелся и прямо сейчас продолжаю это делать каждый день. Хотя и не в энтерпрайзе, это факт. Думаю, что очень хорошо даже и полезно для меня самого, что не в нем. В реальности бывает всякое, любой цирк — и даже вот один грамотный человек который "способен следить" часто не в силах переломить ситуацию со "свалкой". Давая "теорию", даже по поводу "практических методов" — мы все равно вынуждены идеализировать.
Цель моей писанины, на самом деле, в этом контексте понятная — дать простое уверенное понимание гибких подходов к препроцессору и препроцессору с популярными фреймворками? Там во вступлении даже уже это все изложено — для кого и зачем?
1) Много-много лет назад, когда я был начинающим веб-дизайнером и только освоил HTML и CSS, начал верстать, брат программист с которым мы делали иногда сайты для друзей и так далее — скинул мне ссылку на простой туториал по LESS — и это, как я сейчас уже окончательно понимаю — просто перевернуло мою жизнь, это захватило меня с головой, стало главным увлечением и, очень скоро — хорошим источником дохода. Как человек крайне упрямый и с детства увлекающийся и техническими и гуманитарными вещами — склонный к творчеству, но не приемлющий мейнстрим — я действовал, мыслил и экспериментировал самостоятельно, никаких "курсов" и "академий" не кончал — и у меня за плечами уже много самых разных проектов. Вероятно, многим начинающим нужен вот такой просто самый минимальный идейный "толчек", интенсивный, системный и структуированный подход, чтобы снять оцепенение которое, вероятно, вызывает разнообразие и сложность современных подходов и технологий — для того что просто "начать писать, творить". И это — самая главная цель текста.
2) Также удобно — начиная проект с уже устоявшимся специалистом — иметь возможно просто сразу показать гайд и предложить его принять как соглашение, предложить "попробовать" вот так. На некоторых проектах это может быть крайне эффективно против любых других подходов. Если человек пишет бесконечную колбасу несвязных стилей или "пишет компоненты-"контейнеры" с CSS Modules" там где достаточно класса с элементом, но при этом, на самом деле — хороший программист — это может хорошо сработать и быть полезно всем. Хорошие программисты, как показала практика — очень быстро оценивают пользу от описанных подходов в определенных адекватных ситуациях.
3) Я встречал, например, опытных дизайнеров которым "все надоело". Профессиональное выгорание — это очень серьезная тяжелая проблема, если вы с этим уже сталкивались. Естественным направлением развития для таки специалистов будет верстка. Уверен, что для дизайнеров — начать верстать с помощью моего пособия будет эффективнее всего, так как я сам так двигался.
Конечно не составит. В коммерческом аутсорсе, например, верстальщикам приходится иногда верстать лэндинги с "шикарным" адаптивным и сложным дизайном, но практически без какой-либо функциональности, и при этом — очень-очень быстро — прямо нереально быстро. И при этом критично сделать так чтобы "через пару дней" все было идеально "внешне" и было именно в срок. Или часто встречаются игры-презентации, где некоторый нетривиальный кастомный функционал-поведение присутствует, но шаблоны все равно будут отдаваться с сервера, верстка нужна для интеграции на бэкенде. Не только TypeScript "будет мешать" — просто фреймворк и компонентность на таких проектах это совершенно неадекватно и вы просто прогорите и не впишетесь в дедлайн если будете усложнять и не будете более гибким. Это очевидные вещи для любого человека который хоть немного действительно "нюхал порох" в настоящей индустрии, побывал в пекле… И это далеко от многих "красивых теорий" и идеализма. Я то как раз пытаюсь дать внятный концепт как в таких жарких ситуациях делать хорошо и красиво, но не усложнять и не наворачивать лишнего.
Ну или более сомнительный пример, но такое тоже случается в реальной практике сплошь и рядом: гибкий "долгостой", возможно, с сомнительным будущим и не очень внятным настоящим, на котором нет дизайнера или они меняются, макет только для десктопа и только на одну страницу), от менеджмента часто приходят прототипы на новые фичи и шаблоны "на коленке"… В этом случае нам также нужна больше нужна максимальные гибкость и скорость, но "в гайде", а вот строгая типизация того, что практике практически точно — очень скоро отправиться "в корзину" — мне непонятно зачем?
Я уже понял что немного ошибся в вас, в том смысле что вы не какой-то "злой тролль", отнюдь, а, скажем так, действительно специалист со своим необычным подходом. В этом смысле — извините. Но вы, вероятно, за это практически фанатично топите, это выглядит болезненно. Ну — ок… Я вот думаю что "пусть цветы цветут", разные инструменты и решения хороши для разных задач и ситуаций.
Да, но "такие статьи уже были" же, это "все понятно"… У вас есть основанная на опыте и смежных знаниях выстраданная позиция, вы хорошо ее аргументируете. Но мне кажется — вы мыслите "как старый программист" (а я больше как "верстающий дизайнер") — очень инертно и традиционно в этом плане...
С эти всем в принципе согласен, конечно. Просто меня есть успешный опыт, реализованные проекты с использованием описанного гибкого подхода именно "когда четкого дизайна" нет — для проектирования дизайна.
Ну вы, кажется, тут несколько придираетесь и вырываете из контекста. В случае модификатора — если мы не поддерживаем осла и не используем CSS-переменные тоже нельзя?.. Но ок — уберу дефисы, или лучше подпишу про осла и переменные чтобы было не придраться)). А вот про суппорт — ок, только, справедливости ради, оно там вообще до кучи и понтов и на суть темы и остального примера не влияет — там дергадация целевая через модификаторы, но поправлю завтра, да. Еще оплошности есть?
Ну вас, думаю, уже не переубедить. К тому же, я и не пытаюсь выдать свой подход за некое прямо универсальное решение для всех случаев, устал повторять, и в самом тексте об этом часто...
"Структурированная свалка css — в конечном счете даже еще хуже, чем неструктурированная (от этой сразу никто ничего не ждет)." — это, конечно, очень "по-программистки"., фатально прям))) По моему опыту — именно такое отношение и преврашает вообще любой подход в "свалку", извините. Может, дело не в подходах, на самом деле?) Нафиг соглашения, тоесть, они все равно не работают? Про линтеры тоже не понял, с препроцессором линтер не работает у вас?
Да,, в энтерпрайзе я не работал и вряд ли уже буду, это правда, и все это по поводу глобального препроцессора образовалось из обширной "в одно рыло" практики "дизайна прямо в браузере", верстки без макетов, быстрого гибкого прототипирования и тд… Но оно работает и для сложных дизайнов или паттерна библиотеки, вполне...
Ну и у меня все еще есть чувство что вы в принципе предвзяты и меня не поняли, не услышали. Я предлагаю контролируемую и ограниченную связность и хорошую внятную организацию этого. И на самом деле — с CSS-in-JS, например, все тоже самое же — вашему джуну нужно также знать в каком компоненте лежит контейнер для контента чтобы он не написал новый, это мало что меняет...
Спасибо! Очень адекватный и лаконичный каммент! ) Ну я не спорю и не скрываю даже что спорно, но иногда "оно работает", если совсем кратко. Да и с одними известными бесспорными паттернами и "бестпрактиками" будет совсем уныло и скучно, нет? Ну и вообще — "что с дизайнера взять?"..))) breackpoint исправил, да...
Во-первых, если у вас нет глобальной типографики — вам вот в таком случае как описан в моей мотивирующей истории придется поправить значение вообще ВО ВСЕХ местах? Ничего не забыть и все протестировать. А если у вас стопитцот компонентов? А если у вас несколько проектов на одной библиотеке (было в реальной практике)?
При моем подходе — как раз нет никакой "другой переменной в другом месте" и быть не может, нет никакого другого способа раздавать типографику — кроме единой стандартной примеси для вообще всех мест и компонентов, или даже — всех проектов использующий одну библу. Оно везде просто, единообразно и полностью контролируемо. И толковому джуну объяснить как при таком подходе, отдать куда-то стандартную типографику по гайдлайну — нужно не больше 5 минут — тем более, что везде в коде оно уже видно что только так, да и пользоваться удобно — копипастой ))) — там объяснять нечего и ошибиться он в дальнейшем нигде и никак не сможет — ни с фонтом, ни с кеглем, ни с высотой строки, ни с межбуквенным разбежкой… А столько вы времени потратите чтобы объяснить джуну про все свои стопятсот компонентов в нескольких проектах с разными решениями и тд? Ну серьезно, по честноку — "типографика должна быть везде одинаковая, но надежнее если в каждом месте это будет отдельно", так чтоле?
У меня нет цели вам что-то доказать и я работал с достаточным количеством программистов-манагеров которые не понимали и принимали моих методов (хоть и использовали меня для своих целей когда это было выгодно ))) ), не любили, не умели и боялись верстать или "вцеплялисьь в компонентность, CSS-in-JS" как в панацею "от всех проблем со стилями"… Я пишу в тексте что существуют ситуации, проекты на которых это будет даже удобнее и надежнее, проще… Но кроме таких случаев — существует намного больше задач на которых вы просто утоните с подобными "изолированными" подходами. Тут спорить не о чем.
Пока что я не услышал от вас ничего кроме дешевых эмоциональных спекуляций и жалких провокаций — ни одного внятного, четкого примера или контрпримера, ни одного "варианта", решения, технологии, которые я, предположим — специально, или же по не знанию — упустил, или даже — будь ваш интерес к этому посту доброкачественным — мне бы было действительно полезно познакомиться… Давайте вы хоть что-то выдавите по теме, хоть минимально правдоподобное и полезное мне, сообществу, вместо того чтобы засорять эфир своим воображаемым таинственным величием и загадочной неординарностью? Если вы прячете от нас какие-то ценные знания, сокровища, козыри — уже пора их демонстрировать, публика давно в нетерпении, фанфары охрипли-заржавели, барабаны лопнули?.. Я буду искренне рад если ошибаюсь о ваших мотивах, и вы, действительно, сейчас покажете мне и всем что-то потрясающее и необычное?
Извините, но вам даже не хочется отвечать, так как вы, вероятно, совсем плохо читали текст, честно. Там даже прямо во вступительном мотивирующем вступлении есть на эту тему история:
Реальный жизненный кейс: будучи начинающим специалистом я работал удаленно в одном приятном стартапе. Когда проект запустили, после презентации многие присутствовавшие на ней высказались о том, что кегль основного текста и полей ввода в интерфейсе — мелковат. Получив задачу в трекере, я потратил всего пару минут, поправив одну переменную своей системы — чтобы поднять кегль на всех нужных полях и контролах, и еще 15 минут чтобы удостовериться что ничего действительно не сломалось ни на одном шаблоне...
Перечитайте еще раз раздел про типографику — там как раз все для того, и о том, чтобы "поравить в одном месте и ничего не сломалось". Кроме того, хочется понять, что это у вас за типографика такая — везде разная чтоле? (((( Типографика — это глобально раздаваемое свойство "гайдлайна" и "стилевой базы", а не частное — "каждого конкретного элемента, вьюхи"… Именно поэтому "нам все это и нужно глобально" — чтобы у вас, упрощая, "все параграфы были с одинаковым шрифтом"...
Ну и мне, так вообще кажется, что все эти мои подходы — это "во многом — БЭМ", только "с еще возможностями" — "расширенный-гибкий", "чуть более свободный" БЭМ, с некоторыми полезными вольностями, которые можно и нужно использовать очень осознанно и аккуратно. Если вам кажется что это не так — значит вы меня не поняли.
Ну это, скорее, ко второй части в моем пособии — как держать "мух отдельно от котлет" — с компонентным фреймворком. Абстракции препроцессора, конечно, вообще всю вьюху, шаблоны, стили — вероятно придется лихо перекромсать при таком раскладе — ну хорошо, в каком-то смысле — работа кипит). Просто если "вы будете к этому готовы" — возможно будет делать это гораздо меньшей кровью, и, скорее всего — каждую такую итерацию — все гораздо меньшей — так как можно прорабатывать, учитывать опыт,, "подкладывать соломки", все больше таких "соломок" в сложных, больных, опасных местах, нет? И в любом случае, имхо, с гибким и легко модифицируемым препроцессором это, вероятно, можно проворачивать намного проще, чем с "дубовым", якобы "супернадежным", полностью несвязным кодом, особенно если речь идет о сложной и разнообразной вьюхе? Ваша ситуация как раз, имхо, говорит о том что вся эта "надежность" — до ближайшей смены маркетологов и дизайнеров, разве нет?
Еще, кажется, что некоторые программисты "дорвавшиеся до полной компонентности", и решившие "что проблем с версткой больше никогда у них не будет" — просто нифига не поняли, и "прячутся" в это, вместо того чтобы наконец разобраться для чего нужен один полезный инструмент и для чего — другой. Как пример, вот прямо сегодня угорел: там где раньше был один простой и точно также, именно — "переиспользуемый" — класс-утилита для разметки — минимальная рамочная абстракция дизайн-макета — "контейнер для контента" — некоторые теперь пишут "целый компонент" (какое отношение "рамочка" ограничивающая контент на экране имеет к функциональности системы?), кладут его — реально!!! — в @/src/containers — "это же контейнер!!!"))), и до кучи еще спускают ему стили через модные CSS Modules (это в совсем крошечном проекте из нескольких простеньких страниц с несколькими элементами) — (((((… Там где раньше был один класс CSS и один HTML-элемент с ним — теперь целая тусовка модных технологий и концепций.))) Новые технологии и концепции — нужно применять по делу и к месту, а не потому-что "так модно", или "Левон в книжке написал", тут я не спорю, как раз "о том и пишу", во многом… Главное — понимать что и зачем делаешь и, еще неплохо — "быть готовым ко всему"...)
Спасибо за интерес к моему тексту и такой пространный комментарий. К сожалению, у меня вот прямо сейчас нет времени на то, чтобы ответить также подробно. Скажу только многие описанные мною подходы на практике хорошо годятся и для того и другого — проверено. Как и для быстрого проектирования и, например, поиска стилевых и интерфейсных решений, вариаций на гибких прототипах, так и для pixel to pixel реализации точных сложных графических макетов. У меня было уже очень много и того и другого разнообразного опыта и это всегда хорошо работало, вполне. Конечно, не бывает универсальной системы пригодной в одном и том же неизменном виде абсолютно во всех случаях. Чтобы добиться успеха, всегда нужно думать, менять, искать, улучшать… Простите, но хочется дать вам простой совет: попробуйте для любой задачи которая кажется вам подходящей просто взять любой мой стартовый шаблон — в тексте есть ссылки, разобраться с ним и двигаться в этом направлении. Я уверен что верстка и интерфейс это глубоко практическая дисциплина, полезно, конечно, читать книжки-статьи, обсуждать подходы, но чтобы начать чувствовать себя действительно уверено — нужно именно делать. Много и по-разному.
Я не огрызаюсь совсем, подробно вам ответил, хотя, правда, некогда совсем. И, видимо — зря. И я не стану сообщать вам о том, как выглядят советы незнакомым людям в интернете о том, как им нужно или не нужно себя вести, навешивание неприятных эпитетов на основе вашей субъективной рефлексии статьи и пары комментариев… Уверен — бесполезно и только раззадорит...) Общение, имхо — должно строиться на уважении к собеседнику, взаимном интересе и прочих приятных плюшках… А если всего этого нет — стоит стараться избегать.
Если вы считаете что, например, "на лыжах летом по асфальту бегать эффективно, и достаточно быстро, удобно", ну или вам "просто это нравится" — пожалуйста — бегайте-резвитесь, развлекайтесь. Можете даже попробовать проповедовать это, только не стоит навязывать — я вот предпочту хотя бы велосипед, смотря, опять же, какие цели и обстоятельства, необходимость… Риторика построенная на банальном передергивании и примитивных манипуляциях — тоже вас не красит в качестве достойного собеседника. Да — одна одежда нужна для зимы, другая для лета. Хотите щеголять в скафандре круглый год — может он у вас с терморегуляцией даже, но вряд ли в нем будет удобно, например — плавать или загорать.) Если у вас есть "универсальное решение" — покажите его, а не передергивайте на пустом месте.
Styled Components были упомянуты в общем контексте в ответ на заданный вами изначально вопрос: "Вы пробовали действительно другие подходы?" — тут вы тоже передергиваете откровенно и троллите, кажется. В контексте предложенного в моей работе основного подхода с "глобальным препроцессором для компонентности" — CSS-in-JS — как раз выглядит альтернативой. И с ней я тоже ответственно экспериментировал. Повторюсь, в моем тексте об этом есть, но вы, видимо, его не прочитали толком, но комментируете.
А вы прочитали мой текст по ссылке в конце статьи здесь на Хабре хотя бы почти до конца первой из двух частей? Там есть ссылки на примеры моих проектов, например, с TypeScript и/или Styled Components, вроде?..
Вы знаете, я вполне внутренне готов к тому, что меня здесь многие будут топить в фекалиях — да пожалуйста — если кому-то делать нечего… К сожалению, у меня вот прямо сейчас, честное слово, нет времени на холивары и прочее бессмысленное самоутверждение, и это не отмазка — нужно срочно выручать свою команду и вносить изменения в чужой проект с современными, но, при этом "несколько другими" подходами, организацией кода, чем я обычно использую… И это тоже по-своему интересно, точно интереснее, чем спорить о том, что неоднозначно, разнообразно и постоянно меняется...
А найти "окончательное решение", подробный точный рецепт — на все времена и все случаи жизни я правда считаю что совершенно невозможно, да и не нужно — фронтенд это невероятно быстро развивающаяся среда, проекты, задачи, системы бывают самые разные — об этом всем упомянуто в моем тексте, и об этом, я считаю, точно бессмысленно дискутировать. Кроме того, мы все разные, у нас разные склонности-привычки, характеры, жизненный опыт, обстоятельства, и так далее — и это замечательно… Если вы считаете иначе — напишите об этом тоже — я с удовольствием ознакомлюсь с вашим мнением.
В любом случае, спасибо за то что читали и даже за критический камментарий. ) А вы считаете можно отыскать какой-то единственно правильный однозначный ответ на этот практически риторический вопрос, универсальное решение пригодное на все времена и случаи жизни? Произведение вроде не ставит такой унылой и порочной цели… Оно обобщает достаточно уже продолжительный опыт, представляет несколько достаточно спорных идей, но рассматривает и альтернативные и подходы — старается возбудить интерес, прежде всего и в конце концов, к тому что происходит по теме в отрасли… Не думаю, что в принципе возможно написать по что-нибудь по данной теме, что уже очень скоро не окажется неактуальным. И да — я сам собираюсь «еще искать дальше», не останавливаться на достигнутом, пробовать что-то новое и так далее… Разве не в этом смысл и кайф?
Вы не правы. Можно сколько угодно защищать свои вредные привычки, лень и невежество такими некорректными и якобы красноречивыми-убедительными примерами, но, на самом деле, все это перепевы одной и той же очень старой песни: "Зачем мне препроцессор, если есть поиск в текстовом редакторе?". И со становлением компонентности и CSS-in-JS для нее в качестве мейнстрима данный избитый шлягер становиться снова популярным, топовым. Но, по сути, это риторика уровня: "Зачем мне автомобиль, если уже есть велосипед — он и для здоровья, геморроя, извините,) полезнее?", или "Зачем мне мобильный телефон, я все равно из дома очень редко выхожу?" — ну, то есть, некоторый солипсизм в восприятии, если утрировать. Крайне субъективно. Действительно — если кажется что не сильно нужно, не возникает мощного запроса, нет задач которые это требуют — не надо и использовать, конечно! Это важный принцип — используйте только те инструменты которые вам подходят и необходимы. Я и сам редкий консерватор-ретроград, в каком-то смысле, например, завел смартфон, кажется, только лет 5 назад, когда уже вовсю делал суперадаптивные дизайны для браузера с помощью инспектора — до этого юзал кнопочный.
Конкретно по вашему примеру: вы ошибаетесь. В хороших дизайнах для веба, особенно — интерфейсных, ну просто не может быть "очень много" разных цветов. Вы правда уже много верстали? Хороший гайдлайн обычно содержит — "основной-брендовый", "дополнительный", от силы еще парочку вспомогательных и "набор серых" — все. Ну и по функциональным ролям: цвет текста, светлый текст, цвет бордера, может — плейсхолдеры в контролах… Всякое бывает, встречаются исключения, но в основном это так. И меня как раз обычно дико бесит когда я нахожу в макетах "чуть-чуть другие значения" — особенно с серыми это часто бывает… Нужно мыслить правильно, прежде всего — цветов в хорошем интерфейсе должно быть очень немного и они должны быть точно "одни и те же". Если вы абстрагируете их — вы сможете легко их менять (например — переиспользуя компоненты на новом проекте).
)))) Ну вот такой характер, что поделать — все равно "руки чешутся", ну и если "есть что ответить" — нужно отвечать… Но — правда некогда, надеюсь, вы не мой проджект-менеджер. )))
Ну вы, видимо, не верите что у меня также уже был самый разнообразный опыт, я приходил и уходил, очно и удаленно, и всякого насмотрелся и прямо сейчас продолжаю это делать каждый день. Хотя и не в энтерпрайзе, это факт. Думаю, что очень хорошо даже и полезно для меня самого, что не в нем. В реальности бывает всякое, любой цирк — и даже вот один грамотный человек который "способен следить" часто не в силах переломить ситуацию со "свалкой". Давая "теорию", даже по поводу "практических методов" — мы все равно вынуждены идеализировать.
Цель моей писанины, на самом деле, в этом контексте понятная — дать простое уверенное понимание гибких подходов к препроцессору и препроцессору с популярными фреймворками? Там во вступлении даже уже это все изложено — для кого и зачем?
1) Много-много лет назад, когда я был начинающим веб-дизайнером и только освоил HTML и CSS, начал верстать, брат программист с которым мы делали иногда сайты для друзей и так далее — скинул мне ссылку на простой туториал по LESS — и это, как я сейчас уже окончательно понимаю — просто перевернуло мою жизнь, это захватило меня с головой, стало главным увлечением и, очень скоро — хорошим источником дохода. Как человек крайне упрямый и с детства увлекающийся и техническими и гуманитарными вещами — склонный к творчеству, но не приемлющий мейнстрим — я действовал, мыслил и экспериментировал самостоятельно, никаких "курсов" и "академий" не кончал — и у меня за плечами уже много самых разных проектов. Вероятно, многим начинающим нужен вот такой просто самый минимальный идейный "толчек", интенсивный, системный и структуированный подход, чтобы снять оцепенение которое, вероятно, вызывает разнообразие и сложность современных подходов и технологий — для того что просто "начать писать, творить". И это — самая главная цель текста.
2) Также удобно — начиная проект с уже устоявшимся специалистом — иметь возможно просто сразу показать гайд и предложить его принять как соглашение, предложить "попробовать" вот так. На некоторых проектах это может быть крайне эффективно против любых других подходов. Если человек пишет бесконечную колбасу несвязных стилей или "пишет компоненты-"контейнеры" с CSS Modules" там где достаточно класса с элементом, но при этом, на самом деле — хороший программист — это может хорошо сработать и быть полезно всем. Хорошие программисты, как показала практика — очень быстро оценивают пользу от описанных подходов в определенных адекватных ситуациях.
3) Я встречал, например, опытных дизайнеров которым "все надоело". Профессиональное выгорание — это очень серьезная тяжелая проблема, если вы с этим уже сталкивались. Естественным направлением развития для таки специалистов будет верстка. Уверен, что для дизайнеров — начать верстать с помощью моего пособия будет эффективнее всего, так как я сам так двигался.
Как-то так.
Конечно не составит. В коммерческом аутсорсе, например, верстальщикам приходится иногда верстать лэндинги с "шикарным" адаптивным и сложным дизайном, но практически без какой-либо функциональности, и при этом — очень-очень быстро — прямо нереально быстро. И при этом критично сделать так чтобы "через пару дней" все было идеально "внешне" и было именно в срок. Или часто встречаются игры-презентации, где некоторый нетривиальный кастомный функционал-поведение присутствует, но шаблоны все равно будут отдаваться с сервера, верстка нужна для интеграции на бэкенде. Не только TypeScript "будет мешать" — просто фреймворк и компонентность на таких проектах это совершенно неадекватно и вы просто прогорите и не впишетесь в дедлайн если будете усложнять и не будете более гибким. Это очевидные вещи для любого человека который хоть немного действительно "нюхал порох" в настоящей индустрии, побывал в пекле… И это далеко от многих "красивых теорий" и идеализма. Я то как раз пытаюсь дать внятный концепт как в таких жарких ситуациях делать хорошо и красиво, но не усложнять и не наворачивать лишнего.
Ну или более сомнительный пример, но такое тоже случается в реальной практике сплошь и рядом: гибкий "долгостой", возможно, с сомнительным будущим и не очень внятным настоящим, на котором нет дизайнера или они меняются, макет только для десктопа и только на одну страницу), от менеджмента часто приходят прототипы на новые фичи и шаблоны "на коленке"… В этом случае нам также нужна больше нужна максимальные гибкость и скорость, но "в гайде", а вот строгая типизация того, что практике практически точно — очень скоро отправиться "в корзину" — мне непонятно зачем?
Я уже понял что немного ошибся в вас, в том смысле что вы не какой-то "злой тролль", отнюдь, а, скажем так, действительно специалист со своим необычным подходом. В этом смысле — извините. Но вы, вероятно, за это практически фанатично топите, это выглядит болезненно. Ну — ок… Я вот думаю что "пусть цветы цветут", разные инструменты и решения хороши для разных задач и ситуаций.
Да, но "такие статьи уже были" же, это "все понятно"… У вас есть основанная на опыте и смежных знаниях выстраданная позиция, вы хорошо ее аргументируете. Но мне кажется — вы мыслите "как старый программист" (а я больше как "верстающий дизайнер") — очень инертно и традиционно в этом плане...
С эти всем в принципе согласен, конечно. Просто меня есть успешный опыт, реализованные проекты с использованием описанного гибкого подхода именно "когда четкого дизайна" нет — для проектирования дизайна.
Спасибо! Но не думаю что это годиться в качестве универсального решения для всех случаев, задач и прочее. Даже отдаленно не напоминает.
Ну где переменные и где классы, но ок, спать хочу, а завтра пахать… Спасибо за интерес к моей работе и критику.
Ну вы, кажется, тут несколько придираетесь и вырываете из контекста. В случае модификатора — если мы не поддерживаем осла и не используем CSS-переменные тоже нельзя?.. Но ок — уберу дефисы, или лучше подпишу про осла и переменные чтобы было не придраться)). А вот про суппорт — ок, только, справедливости ради, оно там вообще до кучи и понтов и на суть темы и остального примера не влияет — там дергадация целевая через модификаторы, но поправлю завтра, да. Еще оплошности есть?
Ну вас, думаю, уже не переубедить. К тому же, я и не пытаюсь выдать свой подход за некое прямо универсальное решение для всех случаев, устал повторять, и в самом тексте об этом часто...
"Структурированная свалка css — в конечном счете даже еще хуже, чем неструктурированная (от этой сразу никто ничего не ждет)." — это, конечно, очень "по-программистки"., фатально прям))) По моему опыту — именно такое отношение и преврашает вообще любой подход в "свалку", извините. Может, дело не в подходах, на самом деле?) Нафиг соглашения, тоесть, они все равно не работают? Про линтеры тоже не понял, с препроцессором линтер не работает у вас?
Да,, в энтерпрайзе я не работал и вряд ли уже буду, это правда, и все это по поводу глобального препроцессора образовалось из обширной "в одно рыло" практики "дизайна прямо в браузере", верстки без макетов, быстрого гибкого прототипирования и тд… Но оно работает и для сложных дизайнов или паттерна библиотеки, вполне...
Ну и у меня все еще есть чувство что вы в принципе предвзяты и меня не поняли, не услышали. Я предлагаю контролируемую и ограниченную связность и хорошую внятную организацию этого. И на самом деле — с CSS-in-JS, например, все тоже самое же — вашему джуну нужно также знать в каком компоненте лежит контейнер для контента чтобы он не написал новый, это мало что меняет...
Спасибо! Очень адекватный и лаконичный каммент! ) Ну я не спорю и не скрываю даже что спорно, но иногда "оно работает", если совсем кратко. Да и с одними известными бесспорными паттернами и "бестпрактиками" будет совсем уныло и скучно, нет? Ну и вообще — "что с дизайнера взять?"..))) breackpoint исправил, да...
Ну понеслась. ))
Во-первых, если у вас нет глобальной типографики — вам вот в таком случае как описан в моей мотивирующей истории придется поправить значение вообще ВО ВСЕХ местах? Ничего не забыть и все протестировать. А если у вас стопитцот компонентов? А если у вас несколько проектов на одной библиотеке (было в реальной практике)?
При моем подходе — как раз нет никакой "другой переменной в другом месте" и быть не может, нет никакого другого способа раздавать типографику — кроме единой стандартной примеси для вообще всех мест и компонентов, или даже — всех проектов использующий одну библу. Оно везде просто, единообразно и полностью контролируемо. И толковому джуну объяснить как при таком подходе, отдать куда-то стандартную типографику по гайдлайну — нужно не больше 5 минут — тем более, что везде в коде оно уже видно что только так, да и пользоваться удобно — копипастой ))) — там объяснять нечего и ошибиться он в дальнейшем нигде и никак не сможет — ни с фонтом, ни с кеглем, ни с высотой строки, ни с межбуквенным разбежкой… А столько вы времени потратите чтобы объяснить джуну про все свои стопятсот компонентов в нескольких проектах с разными решениями и тд? Ну серьезно, по честноку — "типографика должна быть везде одинаковая, но надежнее если в каждом месте это будет отдельно", так чтоле?
У меня нет цели вам что-то доказать и я работал с достаточным количеством программистов-манагеров которые не понимали и принимали моих методов (хоть и использовали меня для своих целей когда это было выгодно ))) ),
не любили, не умели и боялись верстатьили "вцеплялисьь в компонентность, CSS-in-JS" как в панацею "от всех проблем со стилями"… Я пишу в тексте что существуют ситуации, проекты на которых это будет даже удобнее и надежнее, проще… Но кроме таких случаев — существует намного больше задач на которых вы просто утоните с подобными "изолированными" подходами. Тут спорить не о чем.Пока что я не услышал от вас ничего кроме дешевых эмоциональных спекуляций и жалких провокаций — ни одного внятного, четкого примера или контрпримера, ни одного "варианта", решения, технологии, которые я, предположим — специально, или же по не знанию — упустил, или даже — будь ваш интерес к этому посту доброкачественным — мне бы было действительно полезно познакомиться… Давайте вы хоть что-то выдавите по теме, хоть минимально правдоподобное и полезное мне, сообществу, вместо того чтобы засорять эфир своим воображаемым таинственным величием и загадочной неординарностью? Если вы прячете от нас какие-то ценные знания, сокровища, козыри — уже пора их демонстрировать, публика давно в нетерпении, фанфары охрипли-заржавели, барабаны лопнули?.. Я буду искренне рад если ошибаюсь о ваших мотивах, и вы, действительно, сейчас покажете мне и всем что-то потрясающее и необычное?
Извините, но вам даже не хочется отвечать, так как вы, вероятно, совсем плохо читали текст, честно. Там даже прямо во вступительном мотивирующем вступлении есть на эту тему история:
Перечитайте еще раз раздел про типографику — там как раз все для того, и о том, чтобы "поравить в одном месте и ничего не сломалось". Кроме того, хочется понять, что это у вас за типографика такая — везде разная чтоле? (((( Типографика — это глобально раздаваемое свойство "гайдлайна" и "стилевой базы", а не частное — "каждого конкретного элемента, вьюхи"… Именно поэтому "нам все это и нужно глобально" — чтобы у вас, упрощая, "все параграфы были с одинаковым шрифтом"...
Ну и мне, так вообще кажется, что все эти мои подходы — это "во многом — БЭМ", только "с еще возможностями" — "расширенный-гибкий", "чуть более свободный" БЭМ, с некоторыми полезными вольностями, которые можно и нужно использовать очень осознанно и аккуратно. Если вам кажется что это не так — значит вы меня не поняли.
Ну это, скорее, ко второй части в моем пособии — как держать "мух отдельно от котлет" — с компонентным фреймворком. Абстракции препроцессора, конечно, вообще всю вьюху, шаблоны, стили — вероятно придется лихо перекромсать при таком раскладе — ну хорошо, в каком-то смысле — работа кипит). Просто если "вы будете к этому готовы" — возможно будет делать это гораздо меньшей кровью, и, скорее всего — каждую такую итерацию — все гораздо меньшей — так как можно прорабатывать, учитывать опыт,, "подкладывать соломки", все больше таких "соломок" в сложных, больных, опасных местах, нет? И в любом случае, имхо, с гибким и легко модифицируемым препроцессором это, вероятно, можно проворачивать намного проще, чем с "дубовым", якобы "супернадежным", полностью несвязным кодом, особенно если речь идет о сложной и разнообразной вьюхе? Ваша ситуация как раз, имхо, говорит о том что вся эта "надежность" — до ближайшей смены маркетологов и дизайнеров, разве нет?
Еще, кажется, что некоторые программисты "дорвавшиеся до полной компонентности", и решившие "что проблем с версткой больше никогда у них не будет" — просто нифига не поняли, и "прячутся" в это, вместо того чтобы наконец разобраться для чего нужен один полезный инструмент и для чего — другой. Как пример, вот прямо сегодня угорел: там где раньше был один простой и точно также, именно — "переиспользуемый" — класс-утилита для разметки — минимальная рамочная абстракция дизайн-макета — "контейнер для контента" — некоторые теперь пишут "целый компонент" (какое отношение "рамочка" ограничивающая контент на экране имеет к функциональности системы?), кладут его — реально!!! — в @/src/containers — "это же контейнер!!!"))), и до кучи еще спускают ему стили через модные CSS Modules (это в совсем крошечном проекте из нескольких простеньких страниц с несколькими элементами) — (((((… Там где раньше был один класс CSS и один HTML-элемент с ним — теперь целая тусовка модных технологий и концепций.))) Новые технологии и концепции — нужно применять по делу и к месту, а не потому-что "так модно", или "Левон в книжке написал", тут я не спорю, как раз "о том и пишу", во многом… Главное — понимать что и зачем делаешь и, еще неплохо — "быть готовым ко всему"...)
Спасибо за интерес к моему тексту и такой пространный комментарий. К сожалению, у меня вот прямо сейчас нет времени на то, чтобы ответить также подробно. Скажу только многие описанные мною подходы на практике хорошо годятся и для того и другого — проверено. Как и для быстрого проектирования и, например, поиска стилевых и интерфейсных решений, вариаций на гибких прототипах, так и для pixel to pixel реализации точных сложных графических макетов. У меня было уже очень много и того и другого разнообразного опыта и это всегда хорошо работало, вполне. Конечно, не бывает универсальной системы пригодной в одном и том же неизменном виде абсолютно во всех случаях. Чтобы добиться успеха, всегда нужно думать, менять, искать, улучшать… Простите, но хочется дать вам простой совет: попробуйте для любой задачи которая кажется вам подходящей просто взять любой мой стартовый шаблон — в тексте есть ссылки, разобраться с ним и двигаться в этом направлении. Я уверен что верстка и интерфейс это глубоко практическая дисциплина, полезно, конечно, читать книжки-статьи, обсуждать подходы, но чтобы начать чувствовать себя действительно уверено — нужно именно делать. Много и по-разному.
Я не огрызаюсь совсем, подробно вам ответил, хотя, правда, некогда совсем. И, видимо — зря. И я не стану сообщать вам о том, как выглядят советы незнакомым людям в интернете о том, как им нужно или не нужно себя вести, навешивание неприятных эпитетов на основе вашей субъективной рефлексии статьи и пары комментариев… Уверен — бесполезно и только раззадорит...) Общение, имхо — должно строиться на уважении к собеседнику, взаимном интересе и прочих приятных плюшках… А если всего этого нет — стоит стараться избегать.
Если вы считаете что, например, "на лыжах летом по асфальту бегать эффективно, и достаточно быстро, удобно", ну или вам "просто это нравится" — пожалуйста — бегайте-резвитесь, развлекайтесь. Можете даже попробовать проповедовать это, только не стоит навязывать — я вот предпочту хотя бы велосипед, смотря, опять же, какие цели и обстоятельства, необходимость… Риторика построенная на банальном передергивании и примитивных манипуляциях — тоже вас не красит в качестве достойного собеседника. Да — одна одежда нужна для зимы, другая для лета. Хотите щеголять в скафандре круглый год — может он у вас с терморегуляцией даже, но вряд ли в нем будет удобно, например — плавать или загорать.) Если у вас есть "универсальное решение" — покажите его, а не передергивайте на пустом месте.
Styled Components были упомянуты в общем контексте в ответ на заданный вами изначально вопрос: "Вы пробовали действительно другие подходы?" — тут вы тоже передергиваете откровенно и троллите, кажется. В контексте предложенного в моей работе основного подхода с "глобальным препроцессором для компонентности" — CSS-in-JS — как раз выглядит альтернативой. И с ней я тоже ответственно экспериментировал. Повторюсь, в моем тексте об этом есть, но вы, видимо, его не прочитали толком, но комментируете.
А вы прочитали мой текст по ссылке в конце статьи здесь на Хабре хотя бы почти до конца первой из двух частей? Там есть ссылки на примеры моих проектов, например, с TypeScript и/или Styled Components, вроде?..
Вы знаете, я вполне внутренне готов к тому, что меня здесь многие будут топить в фекалиях — да пожалуйста — если кому-то делать нечего… К сожалению, у меня вот прямо сейчас, честное слово, нет времени на холивары и прочее бессмысленное самоутверждение, и это не отмазка — нужно срочно выручать свою команду и вносить изменения в чужой проект с современными, но, при этом "несколько другими" подходами, организацией кода, чем я обычно использую… И это тоже по-своему интересно, точно интереснее, чем спорить о том, что неоднозначно, разнообразно и постоянно меняется...
А найти "окончательное решение", подробный точный рецепт — на все времена и все случаи жизни я правда считаю что совершенно невозможно, да и не нужно — фронтенд это невероятно быстро развивающаяся среда, проекты, задачи, системы бывают самые разные — об этом всем упомянуто в моем тексте, и об этом, я считаю, точно бессмысленно дискутировать. Кроме того, мы все разные, у нас разные склонности-привычки, характеры, жизненный опыт, обстоятельства, и так далее — и это замечательно… Если вы считаете иначе — напишите об этом тоже — я с удовольствием ознакомлюсь с вашим мнением.