#нагадування
Співбесіда на сцені №2
Квитки закінчуються.

В суботу, 28 лютого, у Львові, в пабі Христофор. о 12:00 буде запис нового випуску.
Будуть забави, розіграші всяких приколів за донати, ну і очевидно, сама співбесіда на сцені.
Цього разу — з Frontend Tech Lead.

КВИТКИ ЗАКІНЧУЮТЬСЯ, КАЖУ

#партнерський_допис
Товариство, найбільший ярмарок вакансій в Defense Tech «Арсенал талантів» повертається!

https://arsenal.talantiv.in.ua

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

🗓 Коли: 14 березня 
📍 Де: Київ, точну локацію ми надішлемо зареєстрованим учасникам в день події на пошту

Впродовж ярмарку 70+ компаній презентують власні проєкти, розробки та актуальні вакансії. Учасники зможуть поспілкуватися з роботодавцями, знайти однодумців та дізнатися більше про оборонно-промисловий комплекс України.

👉🏻 Щоб відвідати «Арсенал талантів» заповнюйте форму та залишайте донат від 333 грн у фонд «Повернись живим». Одна транзакція = один квиток: https://arsenal.talantiv.in.ua/

Після цього триває обов'язкова безпекова перевірка (донат не гарантує її проходження). У випадку підтвердження квиток надійде на електронну пошту, яку ви вказали при реєстрації.

Товариство!
Просто зараз стрим на каналі DOU, де я покажу, як можна зробити дійсно інтерактивний інтерфейс без жодного рядочка JS.

https://www.youtube.com/watch?v=gL9GN8906FU

Лишилося усього 12 квитків.
Завтра, о 12:00, чекаю на вас на записі нового випуску "Співбесіди на сцені" з Frontend Tech Lead!

🗺️ Львів, вул. Ів. Франка 3, Львівський Університет Крафтового Пива ім. Св. Христофора.

⏰ 28 лютого, 12:00

https://secure.wayforpay.com/payment/fe_tech_lead_interview

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

Ще встигаєте узяти квиток на запис "Співбесіди на сцені" ;)

https://secure.wayforpay.com/payment/fe_tech_lead_interview

Дякую усім, хто прийшов на запис цього випуску! Сподіваюсь, вам сподобалось )
Діліться враженнями )

А от і фото підвезли ) Розбирайте на аватарки )
https://15837-mariia-gnip.gallera.io/563289-spivbesida-2

Нове відео на каналі!
Я стільки чекав на цей реліз, що не можу й передати. "Одне питання — три відповіді" — це спроба довести усім, і в першу чергу собі, що цілком реально провести технічну співбесіду за одним і тим самим планом фахівцям різних рівнів.

Пілотний випуск я записував з фахівцями компанії appflame — української продуктової IT-компанії, що вже 7 років працює на ринку, має 500+ спеціалістів в команді. ТОП-5 у рейтингу найкращих роботодавців за версією Forbes Ukraine та robota_ua у 2025 році.

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

Приємного перегляду!

https://youtu.be/eOK11Pvc2RM

Бабіча багато не буває )
https://youtu.be/bhQnXtKHDIg?si=POSEAupf7t_j2ZSx

Товариство, я тут зрозумів, що вже давно не проводив старих-добрих публічних онлайн-співбесід. Ну тих, де ви позоритесь в прямому етері )

Оці всі подкасти, офлайн-розваги і нові формати це все, звісно, дуже добре, але не варто й забувати, звідки ростуть ноги у мого каналу )

Тому ось вам посилання на форму, де можна лишити заявку на участь в онлайн-співбесіді. Чекатиму з нетерпінням!

https://forms.gle/ytgXa619bE8xy1mBA

#js_in_action
В кожній мові програмування існує безліч способів вистрілити собі в ногу, і JavaScript — не виключення. Буквально днями мені пригадався один з таких способів, який я навіть колись (дуже давно) використовував в продакшн-коді.

Мова йде про оператор with.

const user = { name: "Elvira" };

with (user) {
  console.log(name); // Elvira
}

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

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

with втручається саме в звертання до простих імен. Усередині такого блоку JavaScript спочатку намагається трактувати name як властивість переданого об’єкта, і лише потім шукає це ім’я далі по scope chain. Звертання через явний об’єкт, як-от user.name, цієї проблеми не мають.

const user = { name: "Elvira" };
const name = "Oliver";

with (user) {
  console.log(name);
}

У цьому прикладі буде виведено "Elvira", а не "Oliver", тому що with змушує JavaScript спочатку шукати name у user.

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

Яскравим прикладом є потенційне перекриття глобальних та локальних імен:

const user = { name: "Elvira", console: true };

with (user) {
  console.log(name);
}

Проблема тут полягає в тому, console буде резолвитись як user.console, а не як глобальний об’єкт console. Насправді, існує механізм обходу глобальних імен через [Symbol.unscopables], але розібратися з ним я залишаю моєму цікавому читачу.

Хоч with і не вилучено зі специфікації ECMAScript повністю, його використання, мʼяко кажучи, не заохочується. В strict mode він заборонений, і лишається лише як частина зворотньої сумісності.

Якщо вважати, що призначенням with було спрощення доступу до властивостей обʼєкту на письмі, то нині у нас є набагато кращі й надійніші способи спрощено звертатися до таких властивостей, наприклад, та сама деструктуризація:

const user = { name: "Elvira"};
const { name } = user;
console.log(name);

Попри добрі наміри, with виявився конструкцією, що втручається в один із фундаментальних механізмів JavaScript — пошук ідентифікаторів через scope chain. І через це привносить неочікувану невизначеність, через що код стає неочевидним і складним для аналізу.

Що почитати:
MDN: with statement
MDN: JavaScript Guide — Working with objects

Що почитати душнілам:
ECMAScript: with statement
ECMAScript: Object Environment Records
ECMAScript: GetIdentifierReference

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

@babichdev

#css_in_action
Навіть у 2026 році люди не перестають дивуватися, що відносні (тобто відсоткові) вертикальні margin та padding насправді рахуються не від висоти, а від ширини (насправді ширини containing block) елемента). 100% розуміння, 0% засудження — свого часу для мене це теж стало неприємним відкриттям.

Тож чому так? Насправді, це один з моїх улюблених випадків, коли "так історично склалося". Той факт, що ця поведінка зафіксована в CSS2.1, не означає, що вона просто прийшла комусь в голову і її затвердили по приколу. Річ у тім, що цей документ значною мірою був радше не оновленим стандартом, а таким собі "зліпком" того, що коїлося в дивовижному світі веброзробки на той час. І саме така поведінка була вже усталеною.

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

Відверто, дуже багато речей, які здаються нелогічними чи незрозумілими в CSS, насправді спричинені ось такими непростими рішеннями, бо на світанку веброзробки доводилося шукати шляхи, аби обійти нестачу обчислювальних ресурсів та недосконалість алгоритмів. От такий hack driven development.

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

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

Але лишається відкритим питання — чи можемо ми усе ж задавати відносні відступи залежно від висоти? Відповідь — нуууууууу… майже.

Відносно самого елемента? Тверде ні. Відносно чогось іншого? До вибору, до кольору.

Як мінімум, тепер можна використовувати vh та dvh. Так, це відносно висоти вʼюпорту, і я не дуже уявляю, кому треба такий падинг чи маржин, але суть від того не змінюється — це відносна величина, яка рахується від потрібної нам вісі.

І, звичайно, сьогодні ми маємо контейнерні одиниці. cqh, cqb, cqi, cqw. Цікавлять нас cqh — 1% від висоти контейнера, та cqb — 1% від блочного розміру. За замовчуванням ці напрямки співпадають, але є нюанси при зміні напрямку письма.

Проте з cq* одиницями є надзвичайно важливий момент — вони рахуються від найближчого query container, а не від безпосереднього батьківського елемента. Це, якщо спрощено. Взагалі, тема container queries доволі цікава, і беззаперечно потребує окремого допису. Що скажете?

Однак на даний момент саме container query units виглядають як найбільш надійний спосіб вирішити давню проблему — задавати вертикальні відступи відносно вертикальної вісі. І щодо підтримки перейматись не варто, згідно Can I Use це майже 95% сучасних бравзерів.

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

Хотів би написати "…рішення, що робить хак непотрібним", але ми усі розуміємо, що це не так. В деяких випадках, як з aspect-ratio, хак дійсно розчиняється в небутті, але часто, як із cq* одиницями, ми отримуємо рішення, що лише частково закриває початкову проблему. Але при цьому — дозволяє вирішити ще низку проблем, про які ми й не здогадувались.

Що почитати:
MDN — Layout and the containing block
MDN — padding
MDN — CSS container queries

Що почитати душнілам:
W3C — CSS 2.2 Box model
W3C — CSS Containment Module Level 3

@babichdev