Для десктопа так делать не советую. Ну можно для маленькой ширины, но это когда адаптировать совсем лень. Удобно использовать для телефона, планшета или телевизора.
Много лет использую этот прием с rem. Даже делал доклад на MoscowJS. Это по сути получается векторная графика - и соответственно получаем проблему дробных пикселей у маленьких элементов. Это линии в один пиксель или когда нужно выравнивать что-то по вертикали .
Из минусов - нужно постоянно помнить что верстаешь векторную графику. В коде js тоже нужно это помнить. Всем картинкам не забывать указывать размер.
Кому интересно как работает могут посмотреть тут https://ooko.pro . Только нужно через телефон или в инспекторе включить мобильный и перезагрузить. Так как учитываю агент браузера.
Давно использую "динамические пиксели". Но не для больших экранов, а для мобильных. Если вижу что агент браузера от мобильного телефона то вычисляю размер rem относительно ширины экрана, для других экранов фиксировано от px.
Очень помогает когда интерфейс невозможно вогнать в размеры 380px мобильника. Делаю имитацию 550 и уже сложные формы помещаются.
Верстаю в пикселях, но при сборке конвертирует в rem. Из минусов нужно всегда помнить что верстаешь векторную картинку. Делал на эту тему доклад лет 10 назад. Все жду когда появится наивное решение.
Кому интересно можете попробовать тут https://ooko.pro . В инспекторе включите мобильник и перезагрузите, а потом меняйте ширину экрана.
Сложность задач может быть разной, причем значительно. А если сложность однородна то можно заранее планировать объём работы. Да и на разных этапах сложность тоже будет разной. Вот спринты всегда дают результат, а лимиты на этапы как пальцем в небо
Bun хорош. Но разработку думаю лучше делать на node . Так как если писать под bun то может получится что не будет работать под node. А возможности работать и там и тут очень большой плюс
Для десктопа так делать не советую. Ну можно для маленькой ширины, но это когда адаптировать совсем лень. Удобно использовать для телефона, планшета или телевизора.
Много лет использую этот прием с rem. Даже делал доклад на MoscowJS. Это по сути получается векторная графика - и соответственно получаем проблему дробных пикселей у маленьких элементов. Это линии в один пиксель или когда нужно выравнивать что-то по вертикали .
Из минусов - нужно постоянно помнить что верстаешь векторную графику. В коде js тоже нужно это помнить. Всем картинкам не забывать указывать размер.
Кому интересно как работает могут посмотреть тут https://ooko.pro . Только нужно через телефон или в инспекторе включить мобильный и перезагрузить. Так как учитываю агент браузера.
Давно использую "динамические пиксели". Но не для больших экранов, а для мобильных. Если вижу что агент браузера от мобильного телефона то вычисляю размер rem относительно ширины экрана, для других экранов фиксировано от px.
Очень помогает когда интерфейс невозможно вогнать в размеры 380px мобильника. Делаю имитацию 550 и уже сложные формы помещаются.
Верстаю в пикселях, но при сборке конвертирует в rem. Из минусов нужно всегда помнить что верстаешь векторную картинку. Делал на эту тему доклад лет 10 назад. Все жду когда появится наивное решение.
Кому интересно можете попробовать тут https://ooko.pro . В инспекторе включите мобильник и перезагрузите, а потом меняйте ширину экрана.
https://track-hub.mos.ru/
https://wiki-hub.mos.ru/
Спасибо за статью, очень полезна. Добавил правило в черный список
/БАРС|Радмир|Гимаев|360|performance review/iУже ответил - все задачи разные по сложности, приоритету, влиянию на другие задачи и этапа выполнения. Просто расставив лимиты чуда не произойдет.
Как грубый индикатор он еще работает, но как решение это не не работает.
Сложность задач может быть разной, причем значительно. А если сложность однородна то можно заранее планировать объём работы. Да и на разных этапах сложность тоже будет разной.
Вот спринты всегда дают результат, а лимиты на этапы как пальцем в небо
Все так. Лимиты на этапы не работают.
В России последние два года новых проектов для тренинга задач прям изобилие.
У меня приложение стало быстрее отдавать ответы. Но для прода ещё сильно молодая булочка
Bun хорош. Но разработку думаю лучше делать на node . Так как если писать под bun то может получится что не будет работать под node. А возможности работать и там и тут очень большой плюс