Могу абсолютной точно заявить что на рынке вне рф - не сильно луче, если не хуже :)
Проблема есть и с удаленной работой, когда кандидатов из рф не рассматривают, и с позициями на месте. Где-то чуть лучше, где-то хуже, но тренд на разработчиков везде один.
Есть вот такой классный график - это количество публикуемых вакансий на площадке Indeed в штатах согласно данным ФРС. Мне кажется тут не требуется никаких пояснений.
Согласен, мне кажется что тревога только потому что - неизвестность.
Т.е. пугает не сам факт того что надо приспособиться или овладеть новыми навыками, а именно неизвестность пути. Если отбросить это, то и тревоги станет поменьше :-)
Читать было интересно, спасибо. Прямо целый рассказ получился с завязкой и кульминацией :-) Хорошо что стадия депрессии длилась всего неделю. Это может быть не очень с точки зрения напряжения и драмы, но прекрасно с точки зрения решения проблемы.
---
Рынок сейчас действительно очень сложный. Наверное самый сложный за все время моего опыта. Никто особо не понимает куда будет двигаться процесс разработки и как он будет организован при внедрении AI. Плюс накладывается экономическая ситуация. Поэтому компании и могу себе позволить не отвечать, снимать вакансии и просто отказывать. Потому что требования к вакансии могут меняться очень часто.
Ну и пока не видно чтобы ситуация как-то начала меняться в лучшую сторону.
Если я правильно вас понимаю, то ваш комментарий только подтверждает вывод написанный в заголовке статьи - 'нельзя построить жизнеспособную дизайн-систему на основе Tailwind'.
Потому что то что вы описали - это использование Tailwind как utility framework в проекте, а все остальное создается самим разработчиком. Т.е. вы не используете его как основу, а просто для удобства использования utility классов.
Я же пишу о том что классические фреймворки используются не как допонение к проекту, а как основа дизайн-системы, которую можно легко расширять и дополнять через внутренние механизмы, вместо того чтобы придумывать все самому.
это не может быть холиваром так как я рассматриваю разные варианты. Холивар - это когда есть два решения основанные на предпочтениях. Если у вас есть свое решение, буду рад его услышать :-)
> Проблемы которые вы описали в статье, они же не только utility-first подхода касаются, это последствия плохой архитектуры Эти проблемы конкретно Tailwind как основы дизайн-системы. Я написал как это обычно реализовано в классических фреймворках типа Bootstrap или Ng-Zorro. И потом написал какие есть варианты реализации на базе Tailwind.
> А с хорошей архитектурой вы можете строить дизайн систему как поверх Tailwind Tailwind - не просто часть а основа архитектуры и вы не можете это не учитывать. Если вы хотите построить свое решение через CSS и просто использовать некоторые утилитарные классы из Tailwind или некоторые CSS-переменные, то вы не строите систему ПОВЕРХ фреймворка, вы строите ее РЯДОМ. Хорошее решение должно быть расширяемым.
Потому что в данном случае я рассматриваю проблему в рамках построения целой дизайн-системы, а не отдельное решение. Честно говоря ваше решение не до конца понял.
Компонент - ок. А какая у него связь с другими вариациями чтобы можно было задать единные правила для всех кнопок?
Про нейминг классов - абсолютно точно. Это тоже называется одной из основных причин и увеличения скорости разработки и почему такой подход популярен у разработчиков.
Это вы конечно сделали обобщение 😳 Т.е. если дизайнеры VW сделали ошибку, то в дизайн-системе в приложении не должно быть лишних кнопок? Давайте разделять продукты, которые надо продавать и продукты, которые имеют характерное функциональное предназначение. Первые - будут экспериментировать, чтобы повысить продажи, а вторые - будут придерживаться более консервативного подхода. И ничего мы с этим сделать не можем. --- Вообще весь этот пост не про нужны ли нам кнопки или нет, а про то как взять готовый фреймворк и адаптировать его под серьезный проект чтобы можно было эффективно работать. В любом случае хоть 1 раз из 1000 добавление нового типа кнопки будет абсолютно оправдано. И я лично с таким сталкивался на проектах. Об этом и пишу.
Я буквально за последние 4 недели обсудил этот вопрос с примерно 50-ю разработчиками на linkedin и скорость был одним из основных аргументов почему они выбиирают Tailwind. Но вам конечно же виднее :-)
давайте я попробую сформулировать иначе: Адам Уотан в 2019 выпускает Tailwind и основная идея была следующая: вы учите синтаксис этого фреймворка, но взамен можете писать стили прямо в компоненте чтобы увеличить скорость разработки. Компонент = CSS класс, CSS классы = CSS свойства.
Да, сейчас вы можете писать свои классы черещ utility чтобы их применять в компонентах. Или через apply использовать классы внутри другого класса. И еще кучу всего. Но основная идея - не поменялась.
Если же мы отходим от этой идеи и пишем опираясь в основном на css как daisyUI, то нафига там Tailwind? Они легко могут писать все на CSS, просто добавив свои утилитарные классы и используя свои CSS переменные. Потому что Tailwind в таком исполнении - еще одна прокладка, которая усложняет читаемость кода и требует изучения. Убрав ее, мы получаем более эффективную систему с точки зрения разработчиков и в целом продукта.
да, я понимаю смысл, но это все выгядит временным решением а не паттерн на котором можно построить систему.
> то есть монструозные sass конструкции с миксинами и прочей изотерикой по вашему читаемо? я буквально посмотрел синтаксис arbitrary style и на него и написал свой комментарий. Можно монструозные конструкции слепить из чего угодно, но не надо обобщать. Есть плохие варианты, а есть хорошо читаемые на sass.
популярность shadcn - увы как в песни ВИА "Ленениград" "Любит наш народ всякое г*вн*!"
использовать слова из песни в качестве аргумента - так себе затея. Я могу точно также негативно сказать про Tailwind и игнорировать, что он сейчас 80% рынка занимает просто потому что он мне не нравится. Но какой в этом смысл?
> И вполне разумно если нужно сделать свой велосипед можно подчерпнуть их подходы мне не нужен свой велосипед, но я рассматриваю варианты можно ли использовать Tailwind как базу для сложных проектов.
> потыкать можно ту же кнопку и в хедере есть тоглер тем я посмотрел код и могу сказать что они просто вернулись к более классическому паттерну. Tailwind предполагает использование прямо в коде компонента без написания css напрямую. Тут же явно смещается акцент на css классы, просто построено это поверх css переменных из tailwind и немного их кода как в примере
т.е. по сути это микс и чтобы серьезно с ней работать и расширять для своих нужд необходимо: 1) потерять в скорость разработки так как идет возврат к стилям 2) знать хорошо синтаксис Tailwind чтобы мешать его со стилями 3) иметь ограничения css которые пока существуют (без sass и less)
Могу абсолютной точно заявить что на рынке вне рф - не сильно луче, если не хуже :)
Проблема есть и с удаленной работой, когда кандидатов из рф не рассматривают, и с позициями на месте. Где-то чуть лучше, где-то хуже, но тренд на разработчиков везде один.
Есть вот такой классный график - это количество публикуемых вакансий на площадке Indeed в штатах согласно данным ФРС. Мне кажется тут не требуется никаких пояснений.
Согласен, мне кажется что тревога только потому что - неизвестность.
Т.е. пугает не сам факт того что надо приспособиться или овладеть новыми навыками, а именно неизвестность пути. Если отбросить это, то и тревоги станет поменьше :-)
Читать было интересно, спасибо.
Прямо целый рассказ получился с завязкой и кульминацией :-)
Хорошо что стадия депрессии длилась всего неделю. Это может быть не очень с точки зрения напряжения и драмы, но прекрасно с точки зрения решения проблемы.
---
Рынок сейчас действительно очень сложный. Наверное самый сложный за все время моего опыта. Никто особо не понимает куда будет двигаться процесс разработки и как он будет организован при внедрении AI. Плюс накладывается экономическая ситуация. Поэтому компании и могу себе позволить не отвечать, снимать вакансии и просто отказывать. Потому что требования к вакансии могут меняться очень часто.
Ну и пока не видно чтобы ситуация как-то начала меняться в лучшую сторону.
Если я правильно вас понимаю, то ваш комментарий только подтверждает вывод написанный в заголовке статьи - 'нельзя построить жизнеспособную дизайн-систему на основе Tailwind'.
Потому что то что вы описали - это использование Tailwind как utility framework в проекте, а все остальное создается самим разработчиком. Т.е. вы не используете его как основу, а просто для удобства использования utility классов.
Я же пишу о том что классические фреймворки используются не как допонение к проекту, а как основа дизайн-системы, которую можно легко расширять и дополнять через внутренние механизмы, вместо того чтобы придумывать все самому.
если честно я не понимаю вашего комментария
Вы спорите с идеей статьи, не читая ее, но заявляя свою позицию :-)
Интересный подход.
тоже вариант :-)
я исследую этот вопрос именно с точки зрения tailwind как основы системы. Сейчас это очень популярно именно в таком виде - через CVA
это не может быть холиваром так как я рассматриваю разные варианты. Холивар - это когда есть два решения основанные на предпочтениях. Если у вас есть свое решение, буду рад его услышать :-)
> Проблемы которые вы описали в статье, они же не только utility-first подхода касаются, это последствия плохой архитектуры
Эти проблемы конкретно Tailwind как основы дизайн-системы.
Я написал как это обычно реализовано в классических фреймворках типа Bootstrap или Ng-Zorro. И потом написал какие есть варианты реализации на базе Tailwind.
> А с хорошей архитектурой вы можете строить дизайн систему как поверх Tailwind
Tailwind - не просто часть а основа архитектуры и вы не можете это не учитывать.
Если вы хотите построить свое решение через CSS и просто использовать некоторые утилитарные классы из Tailwind или некоторые CSS-переменные, то вы не строите систему ПОВЕРХ фреймворка, вы строите ее РЯДОМ. Хорошее решение должно быть расширяемым.
> Если пересмотрите этот поинт, сразу все станет проще
это не мой пойнт, а основная идея которую заложил его создатель
https://adamwathan.me/css-utility-classes-and-separation-of-concerns/
Если вы строите дизайн-систему на базе CSS, то зачем вам там Tailwind?
Tailwind сейчас 80% рынка фреймворков.
Не фигово так хайпанул :-)
Потому что в данном случае я рассматриваю проблему в рамках построения целой дизайн-системы, а не отдельное решение. Честно говоря ваше решение не до конца понял.
Компонент - ок. А какая у него связь с другими вариациями чтобы можно было задать единные правила для всех кнопок?
если честно, то я не вижу предмета спора и аргументов - тоже
В 2017 году он написал вот такую статью - https://adamwathan.me/css-utility-classes-and-separation-of-concerns/ где собственно и изложил всю идею utility-first фреймворка.
Про нейминг классов - абсолютно точно. Это тоже называется одной из основных причин и увеличения скорости разработки и почему такой подход популярен у разработчиков.
Это вы конечно сделали обобщение 😳
Т.е. если дизайнеры VW сделали ошибку, то в дизайн-системе в приложении не должно быть лишних кнопок?
Давайте разделять продукты, которые надо продавать и продукты, которые имеют характерное функциональное предназначение. Первые - будут экспериментировать, чтобы повысить продажи, а вторые - будут придерживаться более консервативного подхода. И ничего мы с этим сделать не можем.
---
Вообще весь этот пост не про нужны ли нам кнопки или нет, а про то как взять готовый фреймворк и адаптировать его под серьезный проект чтобы можно было эффективно работать. В любом случае хоть 1 раз из 1000 добавление нового типа кнопки будет абсолютно оправдано. И я лично с таким сталкивался на проектах. Об этом и пишу.
точно!
вот это интуиция у вас :-)
Я буквально за последние 4 недели обсудил этот вопрос с примерно 50-ю разработчиками на linkedin и скорость был одним из основных аргументов почему они выбиирают Tailwind. Но вам конечно же виднее :-)
давайте я попробую сформулировать иначе:
Адам Уотан в 2019 выпускает Tailwind и основная идея была следующая:
вы учите синтаксис этого фреймворка, но взамен можете писать стили прямо в компоненте чтобы увеличить скорость разработки. Компонент = CSS класс, CSS классы = CSS свойства.
Да, сейчас вы можете писать свои классы черещ utility чтобы их применять в компонентах. Или через apply использовать классы внутри другого класса. И еще кучу всего. Но основная идея - не поменялась.
Если же мы отходим от этой идеи и пишем опираясь в основном на css как daisyUI, то нафига там Tailwind? Они легко могут писать все на CSS, просто добавив свои утилитарные классы и используя свои CSS переменные. Потому что Tailwind в таком исполнении - еще одна прокладка, которая усложняет читаемость кода и требует изучения. Убрав ее, мы получаем более эффективную систему с точки зрения разработчиков и в целом продукта.
да, я понимаю смысл, но это все выгядит временным решением а не паттерн на котором можно построить систему.
> то есть монструозные sass конструкции с миксинами и прочей изотерикой по вашему читаемо?
я буквально посмотрел синтаксис arbitrary style и на него и написал свой комментарий. Можно монструозные конструкции слепить из чего угодно, но не надо обобщать. Есть плохие варианты, а есть хорошо читаемые на sass.
использовать слова из песни в качестве аргумента - так себе затея. Я могу точно также негативно сказать про Tailwind и игнорировать, что он сейчас 80% рынка занимает просто потому что он мне не нравится. Но какой в этом смысл?
> И вполне разумно если нужно сделать свой велосипед можно подчерпнуть их подходы
мне не нужен свой велосипед, но я рассматриваю варианты можно ли использовать Tailwind как базу для сложных проектов.
> потыкать можно ту же кнопку и в хедере есть тоглер тем
я посмотрел код и могу сказать что они просто вернулись к более классическому паттерну. Tailwind предполагает использование прямо в коде компонента без написания css напрямую. Тут же явно смещается акцент на css классы, просто построено это поверх css переменных из tailwind и немного их кода как в примере
т.е. по сути это микс и чтобы серьезно с ней работать и расширять для своих нужд необходимо:
1) потерять в скорость разработки так как идет возврат к стилям
2) знать хорошо синтаксис Tailwind чтобы мешать его со стилями
3) иметь ограничения css которые пока существуют (без sass и less)
.
Вы можете сгенерировать новый вариант кнопки через одну функцию в Tailwind?
Если да, то поделитесь пожалуйста