Пані та панове, нагадую, що вже завтра у Львові відбудеться благодійний мітап "Від ʼхотілкиʼ до задачі: звідки беруться таски у вашій джирі"!

Обговоримо типові проблеми на кожному етапі трансформації вимог:
— Як різні ролі бачать одну й ту саму задачу
— Які питання треба ставити, щоб уникнути недопорозумінь
— Практичні інструменти для ефективної комунікації між командами

Після дискусії — сесія Q&A, де ви зможете поставити свої запитання панелістам та отримати поради для конкретних ситуацій.

Ну а я цю подію модеруватиму.

Коли: 14 червня, 13:00
Де: Гастропаб "Довгі бурхливі оплески", Львів, вул. Січових Стрільців 3
Вартість: благодійний внесок 500 грн
Для кого: BA, PM, QA, розробники, тімліди — всі, хто працює з вимогами та управлінням завданнями

🚀 КВИТКИ ПРИДБАТИ ТУТ

Усі виручені кошти підуть на потреби ЗСУ!

#цього_тижня ми дізналися:

— Як зупиняти DOM-події
— Що Safari виходило під вінду
— Як масштабувати компоненти як Чак Норіс

А зараз — час відпочити та подивитися улюблений серіал чи почитати цікаву книжку. Відкладіть все до понеділка, робота нікуди не дінеться ;)

Шлях від .html до пікселів на екрані
…довгий, тернистий та заплутаний. Сьогодні хочу оглянути те, як бравзер перетворює текст в html-файлі на зображення у вікні перегляду. Але заглиблюватись не буду, бо навіть у форматі півторагодинної лекції мені не вдавалось охопити усю глибину.

Починається усе з того, що ще під час завантаження файлу бравзер уже на льоту намагається зібрати DOM. Для цього йому достатньо знайти в текстовому потоці токен: відкриваючий чи закриваючий тег, текстову послідовність чи коментар. Щойно токен знайдено, він відразу передається до tree builder, що створює DOM-вузол в DOM-дереві. І ось такою чехардою, крок за кроком, бравзер створює те саме DOM-дерево: токен-вузол-токен-вузол….

Це може відбуватися плавно й безперервно, а може перериватися, якщо бравзер натикається на вставлений або підключений скрипт. В такому випадку парсинг та побудова DOM відкладаються до кращих часів (хоча зараз для оптимізації парсинг може продовжуватися на тлі, але результат викидається на смітник в разі чого), бо бравзер очікує, що скрипт може змінити структуру документа.

Якщо ж бравзер знаходить стилі, то парсинг не припиняється, але може заблокувати безпосередній рендер, себто відмальовку. Чому — трошки далі. Усі стилі також паралельно собі парсяться і з них складається окреме дерево — CSSOM.

І от коли бравзер має на руках усі козирі обидва дерева, DOM та CSSOM, він з них складає третє — render tree. Його призначення — бути інструкцією до збірки фінального зображення, тому той же display: none не включається до render tree.

Тому будь-яка зміна в DOM чи CSS призводять до перерахунку цього render-tree. Майте на увазі.

Наступний крок, після того, як весь дендропарк зібрано докупи — розрахунок layout, або ж блочного макету. На цьому етапі бравзер, беручи за основу render-tree, розраховує, як саме розташовані блоки відносно один одного. Саме на цьому етапі враховуються розміри елементів, відступи, бордери та інші "фізичні" метрики.

Зазвичай бравзер намагається завершити це в один прохід, користуючись "потоковою моделллю", вважаючи, що елементи "плинуть" зліва направо та зверху вниз. Однак, якщо ви використали таблички або CSS-grid, бравзеру доведеться цей процес повторити далеко не один раз.

Після того, як він нарешті обробиться усі ваші хитромудрі лейаути, і блочний макет буде збудовано, бравзер нарешті зможе зайнятися антистрес-розмальовками, тобто збирати все докупи в одне зображення на етапі paint. Тут він буде вже застосовувати і шрифти, і кольори, і картинки ваші, і склеювати усі шари, які ви постворювали своїми position: absolute чи трансформами.

І аж по тому, як він все "запече" в одне зображення, бравзер виведе його у вʼюпорт, тобто у область відображення.

Якщо допис був корисним — можна подякувати донатом на збір на РЕБ для 109 ОГШБ 10 ОГШБр "Едельвейс"
Усього 50 грн — але це реальна користь для фронту.

Звичайно ж, я надзвичайно спростив усе, і не розповів про ту неймовірну купу оптимізацій, до яких вдаються сучасні бравзери. Але для загального розуміння нам вистачить, я сподіваюсь.

А як хочете глибшого огляду — дайте знати в коментарях. Ну і вогників насипте вже, вам не складно, мені приємно.

@babichdev

Пані та панове, хоч на сьогодні заплановані й інші дописи, але просто зараз мушу нагадати про наш збір на РЕБ для 109 ОГШБ 10 ОГШБр "Едельвейс".

Нам лишається навіть менше, аніж 40 000 гривень до мети.

Від нашої з вами допомоги залежить дуже багато.

🔗 Банка mono:
https://send.monobank.ua/jar/9XkNDTzHAZ

💳 Картка mono:
4441111124390562

І просто як нагадування: Росія — це кончена країна кончених людей. А ми мусимо встояти, бо іншого шляху немає.

#про_співбесіди
У вас пʼять років досвіду, ви переписали десятки компонентів (і двічі — один і той самий), але досі не знаєте, чи вже синьйор? Ось запитання, яке я ставлю кожному кандидату — і воно швидко розкладає все по місцях.

Чи брав кандидат участь в якійсь значній технічній ініціативі: чи як ключовий учасник, чи ініціатор?

Це запитання — один з найсильніших індикаторів для мене: чи готова людина до синьйорної ролі. Яким чином? Дуже просто — за рахунок глибини відповіді.

Якщо ви почнете розповідати деталі імплементації, що саме було зроблено, які бібліотеки використали чи патерни застосували, але при цьому не розкриєте вплив, який ці рішення мали на продукт, кодову базу чи процес розробки — що ж, на жаль (на мою особисту думку), ви ще не готові.

Чому? Бо синьйор має в першу чергу мислити стратегічно, зважувати плюси й мінуси рішень, передбачати цей самий вплив, а вже потім думати про конкретні кроки імплементації. Я не кажу зараз про те саме затаскане "продуктове мислення", хоча воно тут теж має значення. Мова йде про розуміння в цілому, широке бачення, усвідомлення довгострокового впливу.

Щоб відповісти на такі питання, треба мати досвід "кроку назад", коли ви оцінюєте не тільки наслідки тут і зараз, а прикидаєте, що саме це дасть: прискорення розробки, підтримуваність коду, легкість внесення змін, покращення швидкодії і так далі. Це цілком може бути частиною досвіду й мідл-інженера.

Для цього, стаючи до роботи над подібними змінами, треба питати себе не лише "як це зробити", а й "що це нам дасть". Не соромтесь діставати цими питаннями ваших синьйорів, лідів, продактів та інших дотичних до рішення людей. Тоді ви навчитеся оцінювати ініціативи не лише суто з практичної точки зору, а й почнете потроху розуміти довгостроковий вплив.

А коли ви його зрозумієте, то до прийняття багатьох рішень ви будете підходити геть з іншого боку, і навчитеся відкидати такі, що здаються вигідними тут і зараз. Бо горизонт планування й оцінювання розшириться далі одного спринта.

А це і є, на мою особисту думку, однією з важливих якостей дійсно синьйорного інженера, бо у завтрашній день можуть дивитися не тільки лиш усі.

Тому, готуючись до співбесіди, підготуйтесь до цього питання, згадайте, коли ви пропонували велику технічну зміну і спробуйте пояснити самі собі, які наслідки вона мала, згадайте, як вона вплинула на процес розробки й ефективність команди.

@babichdev

#про_співбесіди
Просто зараз я готуюсь до вечірнього етеру зі співбесідою — підбираю теми, завдання, придумую хитрі задачки. І на думку спало швиденько поділитися з вами моєю точкою зору щодо того, як проводити співбесіди з лайвкодингом.

Саме не проходити, а проводити. Бо в цьому випадку відповідальність за вдале проходження такої сесії лежить саме на інтервʼюєрі. Чому?

Бо це дуже стресово. Навіть я не завжди блискуче справляюсь з таким завданнями з дуже простої причини: одна справа розповідати теорію чи ділитися досвідом, і зовсім інша — перемикнутись на "розробницький режим", коли дедлайн не за два тижні, а за 20 хвилин. І при цьому треба ще й коментувати усе, що ти робиш.

Так от. Найперше і найголовніше — підготуйте нескладну і очевидну задачу. Наприклад, якщо це вправа з код-ревʼю, то хай там буде дві-три, максимум пʼять суперочевидних проблем. Не варто перетворювати сесію на квест-кімнату, де помилка криється в сімнадцятій ітерації квантового алгоритма Безоса–Мікі-Мауса.

Не змушуйте мене кожному з вас писати в особисті, щоб ви поставили вподобайку і поширили цей допис

Не перебивайте. Ви можете зупинити кандидата, коли чуєте, що він у своїх роздумах уже мандрує степами Монголії. Але якщо він просто дещо по іншому висловлює свої думки — стуліть писка ненадовго. Нагадати про свою присутність можна, коли запала незручна тиша — тоді можна запропонувати підказку чи допомогу.

Не перетворюйте практичні задачі на театр одного актора у вакуумі, в якому він змушений котити свій камінь на гору в повній тиші, поки ви витріщаєтесь на нього, як Віго Карпатський зі свого портрета. Дозволяйте гуглити, питати у чата, користуватися тим же Cursor чи Copilot, питати поради у вас, врешті-решт. Неважливо, як саме зʼявився код, головне аби кандидат його розумів і міг пояснити.

І не змушуйте учасника співбесіди обовʼязково написати повністю робочий код в установлений час. Це додасть ще більще стресу, і можна взагалі зловити тупняк. Ваша задача — побачити, як кандидат мислить, як працює над рішенням, як він розбирається з вимогами і таке інше. В наш час власне сам код уже не є самоціллю, набагато важливіше, як саме до нього прийшли.

Якщо коротко — не будьте душними, будьте привітними та відкритими, і все складеться добре, як для кандидата, так і для вас.

До речі, нагадую, що сьогодні ввечері — новий прямий етер зі співбесідою на моєму ютуб-каналі, і закликаю вас усіх прийти подивитися саме стрим, а не запис. Буде дуже цікаво, це я вам обіцяю. Чекаю на усіх вас!

Заразом подивитеся, як я ігнорую власні поради, бгг.

@babichdev

До початку — рівно п'ять хвилин!

Мерщій заварюйте чай і готуйте смаколики, бо рівно о 19:00 розпочнеться прямий етер з новою співбесідою на моєму ютуб каналі!

https://youtube.com/live/bCqM9T3AbFQ

Всім привіт! Мені здається, прийшов час нам познайомитися дещо глибше.

Мене звати Сергій Бабіч, і я веброзробник.

У розробці я вже понад 14 років. За цей час працював в багатьох компаніях і на дуже різних проєктах, з різними технологіями та дуже різними людьми.

Протягом карʼєри я здобув стільки знань і досвіду, що їх стало просто неможливо утримувати в собі, тому я врешті-решт і вирішив започаткувати цей канал. Не блоґ, не інфопомийку з перепостами з інфопомийок, як ви вже помітили, а таке місце сили, через яке я можу ділитися з вами своїми знаннями, своїм досвідом, роздумами та точками зору.

Але не все тут — з мого 14-річного досвіду. Часом спеціально занурююсь у нову тему — і виходжу з неї з відкриттями, якими й ділюсь із вами.

В цьому каналі я пишу про все, що вважаю за дійсно важливе для вас: веброзробку, проведення й проходження співбесід, архітектуру, досвід з проєктів, анонси моїх і не тільки подій, та обовʼязково — про допомогу ЗСУ. І так буде й надалі.

“Але ж ти постиш і рекламу!” — скажете ви. І будете праві. Я справді публікую партнерські дописи. Але тільки ті, що мають сенс саме для вас. І відбираю я кожне оголошення вручну, зважайте.

А ще:
— Моя улюблена частина Assassin's Creed це Black Flag.
— Я з Житомира.
— На українську перейшов сам у віці 18 років далекого 2005 року. Тому не вірю в "не такі щелепи" і "мнє сложна, я живу в [рандомне_місто]". Дивіться пункт 2 ;)
— Обожнюю риболовлю.

А тепер — ваша черга, розкажіть трохи про себе в коментарях: хто ви, звідки, чому підписалися і чи любите робити свою роботу так само, як це люблю я.

А підтримати "Дивовижний світ веброзробки" можна наступним чином:
— Заохотити підписатися хоча б одного колегу, який в житті про мене не чув;
— Ставити на кожен допис як не вогник, то хоча б серденько;
— Стати патроном на BASE від monobank.

@babichdev

Коротеньке оголошення:
Цього четверга буде невелика неофіційна тусовка в "Довгих бурхливих оплесках" (Львів). Не івент, не мітап — просто хто прийде, той прийде, познайомимось, поспілкуємось, потусуємось.
Можете підходити під 19 годину, я там уже точно буду.

Чекатиму!

Товариство, тим часом нам лишилося зібрати усього 27 500 гривень у нашому зборі для 109 ОГШБ 10 ОГШБр "Едельвейс"

Давайте натиснемо разом і закриємо нарешті його.

Нагадую, що кожні 50 гривень вашого донату — це квиточок в розіграші LEGO Dune Atreides Royal Ornithopter від української продуктової IT-компанії Brainstack.

🔗 Банка mono:
https://send.monobank.ua/jar/9XkNDTzHAZ

💳 Картка mono:
4441111124390562

@babichdev

#партнерський_допис
Давайте будемо відверті — від штучного інтелекту уже нікуди не сховатися. Але й не треба, на мою думку.

А що точно треба робити просто вже, то це опанувати штучний інтелект в усіх його доступних нам проявах, і, замість нити як він забере всю роботу в світі, стрімко вриватися в майбутнє цифрових технологій вже сьогодні.

Тому я запрошую вас долучитися до AI-конференція Fwdays+DevRain, що відбудеться вже 5 липня в Києві.

Серед тем, які будуть обговорюватися: погляд Microsoft та Google на генеративний AI, що буде з вашою командою завтра, книга про генеративний AI за його допомогою, чи варто інвестувати в AI в 2025 та багато іншого.

Серед спікерів будуть Тетяна Лукинюк (Google), Олександр Краковецький (DevRain), Артем Биковець (mono, Simplesense.), Олексій Мінаков (Generative AI) та інші.

Використайте промокод BABICH10 та отримайте знижку 10%

Деталі за посиланням: https://fwdays.com/event/fwdays-devrain-ai

@babichdev

Я не до кінця розібрався з useEffect. І тепер про це знає весь інтернет.

Ті з вас, хто дивились минулий етер зі співбесідою, мали бачити, як ми з Альбертом розмірковували над практичною задачею. І декому здалося, що я підштовхував його до не найкращого рішення цієї задачі. Так от, друзі. Вам не здалося.

І зараз чудовий час для мене визнати помилку та закріпити цей урок.

Тож, в чому проблема? Як виявилось, я дещо наплутав механізм роботи effect cleanup, а саме коли викликається та сама cleanup функція:

useEffect(() => {
  // якась магія
  return () => {
    // знову прибирати за цими магами
  };
}, [dep]);

Так от, я чомусь був переконаний, що cleanup викличеться при знищенні, або ж unmount компонента. Очевидно, що це в корені невірно, адже ця функція викликатиметься щоразу, як зміняться залежності. Перед виконанням самого ефекту.

Чому ж я був такий впевнений в зворотному? Бо останнім часом не дуже то й писав ефекти як такі, а з cleanup і поготів. А якщо писав, то зазвичай ішлося про ініціалізаційні ефекти, що мають виконатися лише раз:

useEffect(() => {
  // одноразова магія
  return () => {
    // разочок прибрав і все
  };
}, []);

І ось саме в цьому випадку cleanup функцію буде викликано лише один-єдиний раз — на unmount.

Давайте ще раз зафіксуємо:

useEffect(() => {
  return () => {
    // ОДИН раз на unmount
  }
}, []); <- пусті залежності

useEffect(() => {
  return () => {
    // ЩОРАЗУ на зміну залежностей + ОДИН раз на unmount
  }
}, [dep]); <- не пусті залежності

Що цікаво, я не так давно досліджував, як саме працює сам useEffect, як ставляться в чергу ефекти, як реєструються хуки і чому не можна виклики хуків класти в умовні конструкції. А про механізм cleanup просто забув.

Якщо дуже коротко, це все впирається в масив залежностей. React на кожен ререндер перевіряє попередні залежності і нові (не сам масив, а саме залежності) і ставить в чергу ефект лише тоді, як хоча б одна залежність зміниться за значенням або посиланням. До речі, важливо памʼятати, що useEffect не виконує сам ефект, а лише відповідає за постановку його в чергу.

Тож так, беручи прикладу з етеру, нам дійсно не потрібні ніякі рефи, проміжні значення та інші ускладнення:

useEffect(() => {
  const intervalId = setInterval(...);
  return () => clearInterval(intervalId);
}, [userId]);

Що ж, сподіваюсь, це нагадування стане в нагоді не лише мені самому, а я більше не морочитиму людям голову і не позоритимусь із тими ефектами на всю країну в прямому етері.

До речі, хто таки дивився останній випуск, чи винесли ви для себе щось корисне? Розкажіть хоч тут в коментарях, якщо на ютубі соромитесь ;)

@babichdev

#мої_кращі_практики

One hook to rule them all
Мене завжди бентежив підхід, коли компонент бере на себе й логіку, і ефекти, і обробку стану — усе підряд.

Десь ми беремо якісь дані, створюємо змінні з похідними станами, описуємо колбеки і хендлери, ефекти і тому подібне. І якщо описувати це в самому компоненті, то він перетворюється на чорну скриньку, бо тоді єдине місце, де ми можемо перевірити чи правильні значення у нас у стейті — це відображення цих даних в HTML.

І це мені дуже не подобається. Бо я вважаю, що логіку треба тестувати окремо, як логіку, а в самому компоненті ми маємо перевіряти лише те, чи вірно відображаються дані в залежності від різних станів.

Тому я користуюсь далеко не інноваційним, не оригінальним, проте дуже зручним підходом state hook. Він полягає в тому, що усі сторонні дані, які потрібні компоненту, я отримую й обробляю в хуці, який має назву use<ComponentName>State.

І повертає цей хук виключно стан, який необхідний для рендеру UI. Таким чином компонент отримує виключно ті дані, які будуть в JSX. І навіть якщо для цього стану потрібен якийсь інший, сам компонент про них не знатиме.

Це дозволяє дуже чітко розділити відповідальності — всередині стейт-хука я роблю усі обчислення, перетворення за необхідності, створюю усі хендлери та ініціалізую всі ефекти, а UI-компонент просто перетворює цей "зліпок" на інтерфейс.

function useComponentState() {
  const [filter, setFilter] = useState('');
  const { data, isLoading } = useSomeFetch(filter);
  const isDisabled = isLoading || !data?.length;
  const displayList = useMemo(() => {
    return data.map(doSomeStuff);
  }, [data]);

  const onInputChange = useCallback((event) => {
    setFilter(trim(event.target.value));
  });

  return {
    filter,
    displayList,
    isDisabled,
    onInputChange
  }
}

function Component() {
  const {
    filter,
    displayList,
    isDisabled,
    onInputChange
  } = useComponentState();

  return (
    <>
      <input value={filter} onChange={onInputChange} />
      <List items={displayList} />
      <button disabled={isDisabled}>Click me</button>
    </>
  )
}

Що це мені дає? По-перше, розділення відповідальностей. По-друге — компонент перестає бути чорною скринькою і перетворюється на абсолютно прямолінійну систему.

Це полегшує тестування. Бо я тепер можу тестувати суто стейт-хук як юніт, перевіряючи значення замість відображення. А саме відображення можна потестувати просто замокавши цей хук кількома потрібними "снапшотами" стану.

Це полегшує контроль за залежностями компонента, бо у нього вона стає лише одна. А залежності стейт-хука це вже геть інша історія.

Я не скажу, що це срібна куля і панацея, яка вирішує усі проблеми. Бо навіть інтеграційні тести все одно вимагатимуть від нас перевірки різних сценаріїв на відображенні. Але на рівні суто компонента такий підхід суттєво мені спростив роботу. Як мінімум, я не харюсь через те, що всередині компонента купа заплутаної логіки, бо її там просто немає.

Взагалі це лише частина загального підходу з розділення логіки на декілька шарів, зокрема аж на чотири, який я запропонував команді, і який знайшов дуже теплий відгук серед колег.

Цікавить, як це працює на рівні чотирьох шарів? Дайте знати в коментарях — розповім про весь підхід, який у нас суттєво покращив якість як суто коду, так і побудови наших інтерфейсів.

@babichdev

Хочеш потрапити в телевізор?

Подавай заявку!

Чергова співбесіда відбудеться 3 липня 2025, і саме ти можеш стати наступною зіркою каналу "Сергій Бабіч та Дивовижний світ веброзробки"!

Заявки приймаються до 21:00 неділі, 29 червня! З обраним зв’яжусь в понеділок, 30 червня.

Обов’язково мати стабільний інтернет та резервне джерело живлення. Камеру та мікрофон для ефіру я надішлю.

Записи етерів лишаються в публічному доступі. Мова спілкування — українська.

Прошу дуже серйозно поставитися до того, чи ви готові до власне публічної співбесіди

ПОДАВАЙТЕ ЗАЯВКУ ВЖЕ!

@babichdev

P.S. Форма має буть відкрита вже

Доброго ранку, друзі! Розпочну цей тиждень не з веброзробки, а набагато важливіжих справ.

Бійці 109 ОГШБ 10 ОГШБр "Едельвейс" передають вам привіт і подяку. Вони отримали першу частину РЕБу з модулем для високих частот.

І тепер чекають на модуль для низьких частот, на який якраз ми з вами і збираємо кошти. А зібрати лишилося не так уже й багато — якихось ~25 000 грн.

Нагадую, що кожні 50 грн вашого донату — це додатковий шанс виграти подарунок, а саме LEGO Dune Atreides Royal Ornithopter від моїх друзів з української продуктової IT-компанії Brainstack

🔗 Банка mono:
https://send.monobank.ua/jar/9XkNDTzHAZ

💳 Картка mono:
4441111124390562

@babichdev

P.S. Бійці дали дозвіл на публікацію як є, не закриваючи обличчя

Новий допис буде тільки після того, як доведем збір до 80 000.
Отак.

#css_in_action
Навіть невеличка зміна стилів одного елементу в DOM може потягнути за собою цілий каскад перерахунків, які можуть зачепити увесь документ. Так-так, навіть звичайний :hover на вашій картці товару може змусити бравзер запустити reflow та repaint для цілої сторінки. І чим складніший ваш застосунок, чим більше у ньому елементів, тим важчий та складніший такий перерахунок, тим більше ресурсів на нього йде.

Але чи існує якийсь спосіб вказати бравзеру, що усе так і задумано, і не варто випускати кракена там, де достатньо звичайної піратської дуелі на шаблях? І моя відповідь — так, існує!

Мова йде про властивість CSS contain, за допомогою якої можна вказати, що цей конкретний елемент — річ в собі, і тут своя атмосфера. Тобто зміни всередині цього елемента не мають впливати на оточуючий лейаут, і є ізольованими від зовнішнього контексту.

Існує 4 типи такої ізоляції: розміру, лейауту, "стилю" та відмальовки і усі вони відповідають за різні аспекти стилізації та впливають або на сам елемент, або на його нащадків. Обʼєднує їх одне: будь-які зміни відповідні всередині ізольованого контексту не мають впливу на оточуючі елементи.

Що важливо памʼятати. При використанні contain створюються новий containing block, stacking context та block formatting context. Тобто елемент ізолюється настільки, що навіть fixed елементи всередині нього тепер будуть позиціонуватися відносно нього, а не відносно viewport.

Чудова нагода саме зараз поставити вподобайку, чи не так?

Ви можете комбінувати різні значення властивості contain між собою (а самих значень є вісім), проте не всі між собою сумісні. Ну і є strict, яке поєднує в собі усі інші.

Тож яка користь з того? Повернімося до прикладу з початку допису — припустимо, у вас є на екрані 100 карток. Ви наводите курсор на одну з них, аби подивитися деталі, і бравзер починає запускати повністю весь процес рефлоу та репейнту, бо хто зна, яких ви там стилів на ховер навішали, може ви весь DOM перемішали? І це вийде досить дорого з точки зору швидкодії.

Однак, вказавши contain, ви поясните бравзеру, що ви так і планували, а кожна картка — ізольована і не повинна впливати на сусідів та загальний лейаут. В такому разі бравзер обмежить свої розрахунки суто цим елементом, заощаджуючи ресурси та час.

Так, звичайно, сучасні бравзери давно навчилися оптимізувати багато речей, включно з рендерингом, передбачаючи різні сценарії, однак усі вони ґрунтуються на припущеннях. Але contain дає вам змогу точно вказати, як саме та де саме ви полегшуєте бравзеру його й без того невдячну працю.

Використовувати contain ви можете просто вже, адже він є частиною Baseline.

🌐 MDN

А чи були у вас випадки, коли :hover перетворював швидкодію вашої сторінки на гарбуз? Розкажіть в коментарях!

@babichdev

Друзі, новини щодо збору!
Сьогодні зранку я оплатив модуль для РЕБ, на який ми збирали, тож збір завершено!

Розіграш останнього приза проведу дещо згодом, бо справ маю стільки, що не влазить вже.

Залишок від цього збору піде в наступний.

Щойно матиму фотозвіт від бійців, відразу викладу тут.

Дякую усім, хто долучився і долучається! Ви неймовірні!