Конечно не составит. В коммерческом аутсорсе, например, верстальщикам приходится иногда верстать лэндинги с "шикарным" адаптивным и сложным дизайном, но практически без какой-либо функциональности, и при этом — очень-очень быстро — прямо нереально быстро. И при этом критично сделать так чтобы "через пару дней" все было идеально "внешне" и было именно в срок. Или часто встречаются игры-презентации, где некоторый нетривиальный кастомный функционал-поведение присутствует, но шаблоны все равно будут отдаваться с сервера, верстка нужна для интеграции на бэкенде. Не только 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, вроде?..
Вы знаете, я вполне внутренне готов к тому, что меня здесь многие будут топить в фекалиях — да пожалуйста — если кому-то делать нечего… К сожалению, у меня вот прямо сейчас, честное слово, нет времени на холивары и прочее бессмысленное самоутверждение, и это не отмазка — нужно срочно выручать свою команду и вносить изменения в чужой проект с современными, но, при этом "несколько другими" подходами, организацией кода, чем я обычно использую… И это тоже по-своему интересно, точно интереснее, чем спорить о том, что неоднозначно, разнообразно и постоянно меняется...
А найти "окончательное решение", подробный точный рецепт — на все времена и все случаи жизни я правда считаю что совершенно невозможно, да и не нужно — фронтенд это невероятно быстро развивающаяся среда, проекты, задачи, системы бывают самые разные — об этом всем упомянуто в моем тексте, и об этом, я считаю, точно бессмысленно дискутировать. Кроме того, мы все разные, у нас разные склонности-привычки, характеры, жизненный опыт, обстоятельства, и так далее — и это замечательно… Если вы считаете иначе — напишите об этом тоже — я с удовольствием ознакомлюсь с вашим мнением.
В любом случае, спасибо за то что читали и даже за критический камментарий. ) А вы считаете можно отыскать какой-то единственно правильный однозначный ответ на этот практически риторический вопрос, универсальное решение пригодное на все времена и случаи жизни? Произведение вроде не ставит такой унылой и порочной цели… Оно обобщает достаточно уже продолжительный опыт, представляет несколько достаточно спорных идей, но рассматривает и альтернативные и подходы — старается возбудить интерес, прежде всего и в конце концов, к тому что происходит по теме в отрасли… Не думаю, что в принципе возможно написать по что-нибудь по данной теме, что уже очень скоро не окажется неактуальным. И да — я сам собираюсь «еще искать дальше», не останавливаться на достигнутом, пробовать что-то новое и так далее… Разве не в этом смысл и кайф?
Конечно не составит. В коммерческом аутсорсе, например, верстальщикам приходится иногда верстать лэндинги с "шикарным" адаптивным и сложным дизайном, но практически без какой-либо функциональности, и при этом — очень-очень быстро — прямо нереально быстро. И при этом критично сделать так чтобы "через пару дней" все было идеально "внешне" и было именно в срок. Или часто встречаются игры-презентации, где некоторый нетривиальный кастомный функционал-поведение присутствует, но шаблоны все равно будут отдаваться с сервера, верстка нужна для интеграции на бэкенде. Не только 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, вроде?..
Вы знаете, я вполне внутренне готов к тому, что меня здесь многие будут топить в фекалиях — да пожалуйста — если кому-то делать нечего… К сожалению, у меня вот прямо сейчас, честное слово, нет времени на холивары и прочее бессмысленное самоутверждение, и это не отмазка — нужно срочно выручать свою команду и вносить изменения в чужой проект с современными, но, при этом "несколько другими" подходами, организацией кода, чем я обычно использую… И это тоже по-своему интересно, точно интереснее, чем спорить о том, что неоднозначно, разнообразно и постоянно меняется...
А найти "окончательное решение", подробный точный рецепт — на все времена и все случаи жизни я правда считаю что совершенно невозможно, да и не нужно — фронтенд это невероятно быстро развивающаяся среда, проекты, задачи, системы бывают самые разные — об этом всем упомянуто в моем тексте, и об этом, я считаю, точно бессмысленно дискутировать. Кроме того, мы все разные, у нас разные склонности-привычки, характеры, жизненный опыт, обстоятельства, и так далее — и это замечательно… Если вы считаете иначе — напишите об этом тоже — я с удовольствием ознакомлюсь с вашим мнением.