серьезность проекта показывает тот факт, планируете ли вы его поддерживать в долгосроке, тайпскрипт де-факто стандарт, если пишется лендинг условный или какой-то мини проект, то конечно ок, но средние-большие проекты без тс, ну это выстрел себе в ногу
Далее вступает второй фактор, любой самый средний мидл + ИИ закрывает 99.99999%
Это скорее говорит о проектах над которыми работает человек, а не показывает реальную картину
Я сам овер квалифицированный специалист с опытом более 13 лет из них последние 9 лет в качестве ведущего разработчика / тех лида, но есть нюанс мои навыки никому не нужны на рынке теперь
Работу стало найти кратно сложнее, это факт, но если сложилась такая картина, может все таки не овер? ;)
Вопрос такой, что произойдет в случае, если мы предотвратим навигацию, когда источник ее изменения будет popstate. Как я понимаю будет рассинхрон между url и состоянием роутера?
Не очень понятно в чем преимущество подхода. Css in js хорош тем, что ты можешь использовать рантайм, если ты статически генерируешь стили, зачем это делать через compiled css in js если можно воспользоваться обычными css модулями
Я бы выкинул отсюда mui и ant и подходил к выбору решения для стилизации с позиции этапа генерации и сделал бы этот критерий краеугольным камнем, потому что плюсы и минусы исходят от этого. Хотите иметь возможность динамически создавать стили в зависимости от разных условий, css in js однозначно будет иметь преимущество, потому что это рантайм. Хотя мы все еще можем использовать инлайн стили, но это не так удобно как css in js. Минусы решения очевидны, дополнительные вычисления и нагрузка в рантайме. Хотите не нагружать рантайм, тогда можно взять любой CSS препроцессор или голый css + css modules для изоляции. Минус в том, что нет динамики, вы конечно сможете заинлайнить что-то, но это менее естественно в сравнении с css in js и не покрывает 100% кейсов, в основном касающихся динамического создания деклараций. Хотя наверное подавляющее большинство кейсов будет покрыто инлайн стилями либо css переменными. Есть еще css in js compiled time. Но тут я не понимаю зачем это нужно, ты пишешь css в js но не имеешь плюсов запуска в рантайме. Как по мне это какое-то извращение, но может я не прав.
Сперва нужно определиться, что вы понимаете под чистой архитектурой. Для меня это то, что описано дядюшкой бобом. Не более. У меня никак не получается натянуть сову на глобус и обосновать отказ от фреймворков, сборщиков и других тулзов чистой архитектурой.Если вам кажется, что вы такой крутой и можете на изян справится с проектом без существующей экосистемы, то поспешу разочаровать, скорее всего дело в том, что проект просто мелкий и в этом всем не нуждается. Фреймворки берут не по фану, а для того, чтобы решить проблему поддержки больших приложений через композицию компонентов, так как с этим ментально проще работать, а также для того, чтобы получить из коробки реактивность, возможно роутинг и http клиент. Сборщики нужны не по фану, а чтобы компилировать одни входные данные в другие, и не ломать приложение при импорте условного svg или css модуля, чтобы тайпскрипт превращался в js, чтобы писать на актуальном синтаксисе, но транспилировать его в тот, что будет поддерживаться желаемым набором браузеров, чтобы сплитить код на чанки или наоборот объединять их в общие, которые можно удобно кэшировать.
Мой посыл не в том, чтобы тащить в проект все подряд, там где это не нужно, а в том, что не надо пытаться маскировать тривиальность вашего проекта или собственное непонимание существующей сложившейся экосистемы разработки, тезисом о переусложнении и ненужности этой экосистемы.
серьезность проекта показывает тот факт, планируете ли вы его поддерживать в долгосроке, тайпскрипт де-факто стандарт, если пишется лендинг условный или какой-то мини проект, то конечно ок, но средние-большие проекты без тс, ну это выстрел себе в ногу
Кто сейчас вообще пишет на чистом js серьезный проект.
Инверсия зависимостей в js реализуется точно также как и везде, di контейнер просто добавляет удобства.
Это скорее говорит о проектах над которыми работает человек, а не показывает реальную картину
Работу стало найти кратно сложнее, это факт, но если сложилась такая картина, может все таки не овер? ;)
Движуха
Шел 2026 а разговоры о том какой фреймворк/библиотеку выбрать для разработки все еще не утихают. Печальное зрелище
Жир с экрана потек, пока двойка
Вопрос такой, что произойдет в случае, если мы предотвратим навигацию, когда источник ее изменения будет popstate. Как я понимаю будет рассинхрон между url и состоянием роутера?
Это было смешно😁
Tree Shaking есть
Капец вы всех под одну гребенку собрали
Не очень понятно в чем преимущество подхода. Css in js хорош тем, что ты можешь использовать рантайм, если ты статически генерируешь стили, зачем это делать через compiled css in js если можно воспользоваться обычными css модулями
Нейрослоп подъехал, с учетом прошлой поделки автора я бы стороной обходил его творения навайбкоденные
Зачем рушите манямирок гражданина тимлида
И все это надеюсь писалось с шапочкой из фольги на голове
Я бы выкинул отсюда mui и ant и подходил к выбору решения для стилизации с позиции этапа генерации и сделал бы этот критерий краеугольным камнем, потому что плюсы и минусы исходят от этого. Хотите иметь возможность динамически создавать стили в зависимости от разных условий, css in js однозначно будет иметь преимущество, потому что это рантайм. Хотя мы все еще можем использовать инлайн стили, но это не так удобно как css in js. Минусы решения очевидны, дополнительные вычисления и нагрузка в рантайме. Хотите не нагружать рантайм, тогда можно взять любой CSS препроцессор или голый css + css modules для изоляции. Минус в том, что нет динамики, вы конечно сможете заинлайнить что-то, но это менее естественно в сравнении с css in js и не покрывает 100% кейсов, в основном касающихся динамического создания деклараций. Хотя наверное подавляющее большинство кейсов будет покрыто инлайн стилями либо css переменными. Есть еще css in js compiled time. Но тут я не понимаю зачем это нужно, ты пишешь css в js но не имеешь плюсов запуска в рантайме. Как по мне это какое-то извращение, но может я не прав.
Да, вы единственный, кто понимает, я думаю это своего рода избранность
Тут комментировать только портить
Со статьей согласен, все херня, дайте фигму на jquery с прегенеренной статикой
Да, согласен, но рейтинг мне быстро в минус увели)
Сперва нужно определиться, что вы понимаете под чистой архитектурой. Для меня это то, что описано дядюшкой бобом. Не более. У меня никак не получается натянуть сову на глобус и обосновать отказ от фреймворков, сборщиков и других тулзов чистой архитектурой.Если вам кажется, что вы такой крутой и можете на изян справится с проектом без существующей экосистемы, то поспешу разочаровать, скорее всего дело в том, что проект просто мелкий и в этом всем не нуждается. Фреймворки берут не по фану, а для того, чтобы решить проблему поддержки больших приложений через композицию компонентов, так как с этим ментально проще работать, а также для того, чтобы получить из коробки реактивность, возможно роутинг и http клиент. Сборщики нужны не по фану, а чтобы компилировать одни входные данные в другие, и не ломать приложение при импорте условного svg или css модуля, чтобы тайпскрипт превращался в js, чтобы писать на актуальном синтаксисе, но транспилировать его в тот, что будет поддерживаться желаемым набором браузеров, чтобы сплитить код на чанки или наоборот объединять их в общие, которые можно удобно кэшировать.
Мой посыл не в том, чтобы тащить в проект все подряд, там где это не нужно, а в том, что не надо пытаться маскировать тривиальность вашего проекта или собственное непонимание существующей сложившейся экосистемы разработки, тезисом о переусложнении и ненужности этой экосистемы.