Дивовижний світ веброзробки

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

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

І тоді людство згадало про так чудову річ, як пропорції, і почало "резервувати" місце під зображення, поки сам файл вантажиться. Найнадійнішим способом тривалий час був так званий padding-top hack — коли за допомогою внутрішнього відступу, абсолютного позиціонування і такоїто матері вдавалось таки забезпечити сталі пропорції. Але якою ціною?

<div class="box">
  <img class="fixed-ratio">
</div>

<style>
.box {
  position: relative;
  width: 100%;
  padding-top: 56.25%; /* 9 / 16 = 0.5625 → 56.25% */
  overflow: hidden;
}

.fixed-ratio {
  position: absolute;
  top: 0;
  right: 0;
  bottom: 0;
  left: 0;
}
</style>

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

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

Хто не поставить серденько — втратить доступ до каналу через 3… 2… 1…

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

.fixed-ratio {
  aspect-ratio: 16 / 9;
}

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

.fixed-ratio {
  aspect-ratio: 1.77777778;
}

А, що ще важливо — очевидно, що aspect-ratio працює для усіх блочних елементів, не лише для зображень.

Частиною Baseline ця властивість є з вересня 2021 року, а це означає, що ви можете спокійно використовувати її у ваших продакшн-проєктах. Якщо ви досі не пишете під IE, звичайно.

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

🌐 MDN: aspect-ratio

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

@babichdev

#партнерський_допис
Товариство, а ви чули? ШІ стукає в наші таски! І як він змінить роботу фронтенд-розробників у найближчі роки — говоримо на панельній дискусії appflame talks!

📅 31 липня, 18:00–20:00, онлайн
Спікери з appflame, WIX, Softsich. Модератор — щиро ваш Бабіч.
Ця подія — і для розробників і тімлідів, які хочуть розуміти, куди рухається індустрія.

Поділимося практичними кейсами та інструментами, що варто використовувати вже сьогодні!

🔗 Реєстрація: http://bit.ly/4lszyfW

#html_in_action
Отже, вам терміново потрібно додати до статті ілюстрацію з підписом. Не знаю, для чого, просто дуже треба.

Ваша перша реакція:

<div class="illustration">
  <img src="…" />
  <p class="description">…</p>
</div>

Якщо це так — зупиніться! В HTML5 уже давно існує спеціальна семантична конструкція figure + figcaption!

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

<figure>
  <img src="…" />
  <figcaption>…</figcaption>
</figure>

Порядок, до речі, неважливий: підпис може йти як перед вмістом, так і після — головне, щоб він був першим або останнім елементом всередині відповідного figure. Відсутність figcaption, до речі, допускається.

Як допускається й вкладення figure у figure:

<figure>
  <img src="…" />
  <figcaption>…</figcaption>

  <figure>
    <img src="…" />
    <figcaption>…</figcaption>
  </figure>
</figure>

Проте, якщо ви вкладете два figcaption в один figure, то на вас насвариться валідатор, бо підпис до ілюстрації має бути лише один. Бо екранні читалки трактують figcaption як пояснення до вмісту.

Щодо вмісту, то "ілюстрацією" може бути що завгодно, хоч текст, хоч відео, хоч код.

Чому ви досі не втисли вподобайку цьому допису, я вас питаю?

Ну і, звісно, не варто плутати figcaption з caption в таблиці. Це геть інший елемент зі своєю поведінкою та семантикою.

І ось вам ще бонус — як додати наскрізну нумерацію до ілюстрацій на кшталт "Рисунок 2.1 Реакт-абізяна в природі":

<figure>
  <img src="react-monke.jpg" />
  <figcaption>
    Реакт-абізяна в природі
  </figcaption>
</figure>

:root {
  counter-reset:
    section-counter,
    item-counter;
}

section {
  counter-increment: section-counter;
}

figure {
  counter-increment: item-counter;
}

figure::before {
  content: "Рисунок. "
    counter(section-counter)"."
    counter(item-counter);
}

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

🌐 MDN: figure
🌐 MDN: figcaption
🌐 MDN: Using CSS counters

@babichdev

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

P.S. До речі, згідно правил української мови, слово "рисунок" — правильне. Просто його треба використовувати в правильному значення. Розрізняти "рисунок" від "малюнка" дуже просто — перший це зображення, утворене рисками, штрихами, а друге — мальоване, фарбоване. Отака хвилинка філології.

Товариство, хто хоче стати зіркою наступної співбесіди на ютубі? Яка, до речі, відбудеться наступної пʼятниці, 1 серпня.

Заповнюйте анкету і хапайте нагоду попозоритись показати свої знання в прямому етері!

https://forms.gle/T8SKFTpuCbY1vK8E6

Чекаю на ваші заявки до вечора неділі. Всім гарного вечора пʼятниці!

#про_співбесіди
У мене вчора трошки пригоріло від одного допису в Threads. Якщо коротко: історія про співбесіду, де кандидат класно відповідає на питання, розповідає кейси, і взагалі повний метч. Але аж тут, при завершенні тімлід раптом питає: "А що більше, 5² чи 2⁵?' Кандидат розгубився, просить калькулятор. І висновок мене вбив: "Це не про математику. Це про базову уважність, реакцію, спокій під тиском."

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

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

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

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

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

Підсумовуючи, залишу просто дуже влучну цитату з коментарів: "В гуглі всі знають, чому люки круглі, але чомусь досі пишуть код з null exception".

Все, ніби випустив пару. Не будьте душні, одним словом.

@babichdev

Зловив ) Дякую!

#нове_відео
Хто такі синьйори?

Цей подкаст чекав на свій зірковий час ще із січня, і ось нарешті ви маєте змогу послухати, як ми з Нікітою Галкіним розбираємо тему, що давно потребувала відвертої розмови. Що таке синьйорність? У чому вона проявляється? Як не сплутати її з фреймворковою експертизою? І що взагалі чекає після?

Ходіть дивитися і приємного перегляду!

Хто такий Senior Software Developer? | Подкаст з Нікітою Галкіним

І не забудьте поширити це відео серед усіх родичів і знайомих.

#про_співбесіди
Сир, сирок і race condition
Ви шукаєте "сирок", а бачите "сир". Ні, це не випадок в "Сільпо", а цілком собі питання на технічному інтервʼю.

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

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

Отже, питання:

У вас є табличка з пошуком, і якщо в пошуку спочатку набрати "сир", а потім швиденько дописати "-ок", то таблиця усе одно відображатиме список і сирів і сирків. Чому так може бути?

Відповіді, звичайно, я отримую доволі різноманітні, проте серед найчастіших є одна умовно невірна, і одна — вірна.

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

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

Схема проста: запит на “сир” пішов першим, але довго обробляється. Тим часом користувач встиг дописати “-ок”, і запит на “сирок” пішов другим — але відповів швидше. У результаті інтерфейс спочатку показує правильний список, а потім перезаписується старішою, але пізнішою відповіддю. Особливо легко це проґавити, якщо показується лише один індикатор завантаження.

Рішення саме цієї задачі надзвичайно просте — необхідно скасовувати попередні запити при відправці нових. Зазвичай для цього використовується AbortController.

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

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

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

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

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

Тож, якщо ваш колега знову "пакращить" відповідь на інтервʼю — покажіть йому цей кейс ;)

До речі, чи були у вас випадки на співбесідах, коли ви на просте питання давали занадто кучеряву й складну відповідь? Діліться смачненькими фейлами!

@babichdev

#партнерський_допис
Товариство, триває набір на курс «Дизайн архітектури програмного забезпечення» від Олександра Савченка в Fwdays Academy!

Старт курсу — 28 липня
Тривалість — 3 тижні
Формат — живі сесії + практичні завдання
Вартість — від 10 800 грн

Програма курсу охоплює:

Повний процес проєктування архітектури:
від аналізу функціональних і нефункціональних вимог до оцінки, вдосконалення та адаптації наявних рішень.

Практики сучасної розробки:
Architectural Kata з використанням AI, інтеграційний та Brownfield-дизайн, підхід через ADR.

Роботу з різними аспектами:
ASR/ADR, governance, AI-сценарії, проєктування інфраструктури й платформ, реліз-менеджмент.

Цей курс для тих, хто хоче впевнено працювати з архітектурою складних систем у реальних умовах. І я його вам раджу, як я радитиму все від Fwdays Academy, майте на увазі ;)

🔔Реєстрація відкрита за посиланням:
🌐https://bit.ly/4lYobfM

#css_in_action
Ну що, поцентруємо трошки div? У мене тут вчора в Threads попросили, то як я можу відмовити? А то все архітектури, гуд інаф коде. Одним словом, донт пуш зе хорсес, треба й ділом зайнятись. Тож…

ЦЕНТРУЄМО ГОРИЗОНТАЛЬНО
Margin

.el { 
  margin: 0 auto;
  width: ...;
}

Працює, коли елемент має обмежену ширину. Не працює для інлайнових елементів.

Для інлайнових блоків

.parent { text-align: center; }
.el { display: inline-block; }

Класичний спосіб для вирівнювання inline або inline-block елементів. Батьківський text-align впливає лише на інлайн-контент.

Flexbox

.parent {
  display: flex;
  justify-content: center;
}

Найстабільніший спосіб для X-центрування. Важливо памʼятати, що align-items за замовченням stretch, тому вертикаль може "роздувати".

Grid

.parent {
  display: grid;
  justify-items: center;
}

Просто, сучасно, стильно, молодіжно.

Absolute + transform

.el {
  position: absolute;
  left: 50%;
  // або
  inset-inline: 50%;
  transform: translateX(-50%);
}

100% надійність. Потрібен position: absolute|fixed. Підтримка inset-inline чудова у всіх сучасних бравзерах (навіть Safari).

justify-self

.el { justify-self: center }

Працює у Grid. Не працює в Flex (бо цим керує сам контейнер). Працює поза grid в блочних контекстах, але тільки в Chrome та Edge. Firefox і Safari цю поведінку ігнорують, сподіваюсь, тимчасово.

ЦЕНТРУЄМО ВЕРТИКАЛЬНО
Flexbox

.parent {
  display: flex;
  align-items: center;
  height: ...;
}

Працює за умови flex-direction: row. Важливо памʼятати, що потрібна висота контейнера, інакше нічого не відцентрується.

Grid

.parent {
  display: grid;
  align-items: center;
}

Просто, сучасно, стильно, молодіжно.

Absolute + transform

.el {
  position: absolute;
  top: 50%;
  // або
  inset-block: 50%;
  transform: translateY(-50%);
}

Це ж було вже.

align-self

.el { align-self: center; }

Працює поки лише всередині flex та grid. Всередині flex це вертикально, якщо flex-direction: row, якщо це column, то вирівнювання буде по горизонталі. Очікується підтримка в блочних контекстах.

Table-cell

.parent {
  display: table-cell;
  vertical-align: middle;
}

Дідівський спосіб, не позбавлений недоліків. Багатьох недоліків.

ЦЕНТРУЄМО ЦЕНТРАЛЬНО
Flexbox

.parent {
  display: flex;
  align-items: center;
  justify-content: center;
  height: ...;
}

Один із найнадійніших способів. Потрібна висота в контейнера.

Grid

.parent {
  display: grid;
  place-items: center;
}

Найменше коду. Повна підтримка. Але потрібен grid.

Absolute + transform

.el {
  position: absolute;
  top: 50%;
  left: 50%;
  // або
  inset: 50%;
  transform: translate(-50%, -50%);
}

Найнадійніший варіант з абсолютним позиціонуванням. inset — скорочений запис для top/right/bottom/left усіх разом. Боже, як я мріяв колись про цю властивість…

place-self

.el { place-self: center; }

Працює тільки всередині grid. Поза ним — частково підтримується в Chromium, але не в Safari чи Firefox.

---
Ну от якось так можна відцентрувати div в липні місяці 2025 року. Можливо ви знаєте ще якийсь чудернацький спосіб, то обовʼязково розкажіть про нього в коментарях. До речі, приєднуйтесь до чату, як іще будемо ділитися глупими мемами про джаваскрипт?

MDN: CSS Box Alignment Module Level 3

@babichdev

Жарт безсовісно спертий у @dobermanko

#css_in_action
Що робити, коли в DOM зʼявляються небажані обгортки, які ми не можемо прибрати, і які ламають нам розмітку? Звичайно ж, перша думка — надавати по рукам автору такого коду, але життя бентежне, та й іноді ці обгортки мають сенс, але для якоїсь логіки, про яку ми можемо бути й не в курсі.

Однак тут на поміч спішить таке значення властивості display, як contents. Якщо спробувати пояснити на пальцях, то при побудові бравзером лейауту, такий елемент буде ігноруватися (але саме блокові стилі, декоративні ж лишаються), і його дочірні елементи будуть поводитися так, ніби вони належать до батьківського елемента їхнього батька. Ну тобто display: contents по факту відвозить своїх дітей до діда. А сам на риболовлю десь тікає.

Спробувати це можна на дуже простому прикладі:

<div class="дід">
  <p class="дядько">1</p>
  <div class="батя">
    <p class="дитина">2</p>
    <p class="дитина">3</p>
    <p class="дитина">4</p>
  </div>
</div>

.дід {
  outline: 1px solid blue;
  display: grid;
  grid-template-columns: 1fr 2fr 1fr 2fr;
  width: 400px;
}

.батя {
  display: contents;
}

.дитина {
  outline: 1px solid green;
}

Якщо прибрати у баті display: contents, то діти зібʼються в купку, і ніхто ні на яку риболовлю не поїде. А от якщо не прибирати, то дітиська будуть поводитись так, як скаже дід.

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

<div class="дід">
  <p class="дядько">1</p>
  <div class="батя">
    <p class="дитина">2</p>
    <div class="батя">
      <p class="дитина">3</p>
      <p class="дитина">4</p>
    </div>
  </div>
</div>

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

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

Тож, підсумуємо: display: contents — це чудовий спосіб позбутися зайвих обгорток, не змінюючи DOM.

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

Зате якщо перед тобою безглуздий div, що тільки заважає верстці й не несе жодного смислового навантаження — сміливо став display: contents і відправляй його на риболовлю. Він свою справу зробив.

MDN

@babichdev

***
А збір на Mavic для 184 навчального центру, між іншим, вкляк. Тож якщо ви не тільки поставите вогник цьому допису, а й закинете пʼять гривень на збір, цей день стане набагато світлішим. Дякую всім і цьом вам у лобіка.
https://send.monobank.ua/jar/AeXQ6YRf2X
5375411202918178

#думки_вголос
З кожним роком стає усе важче боротися з "гімно мале"-mentality. Ну тобто коли ти весь такий поважний і вкритий мохом дивишся на умовних 25-річних синьйорів і бухтиш собі під носа "ну який ти в сраку синйьор, ти ж жизні не видів, де там того синьйора взяти".

Проте накладати власний досвід на чужий — часто справа невдячна. Бо це я в 25 і на мідла не стягував, адже почав в 24. А якщо людина почала кар'єру в дев'ятнадцять років, і при цьому сумлінно працювала, в не тільки тасочки закривала, то чому вона не може здобути за цей час необхідний досвід? Може. І здобуде.

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

І взагалі, чому мати дітей в 22 можна, а бути синьйором в 25 не можна? Отож.

Головне при цьому бути не "паперовим" синьйорами, і розуміти, що це не лише личка, в й відповідальність.

Гарних вихідних!

@babichdev

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

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

Почну я з сильних сторін, які мені впали в око, і які варто виокремити:

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

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

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

Звичайно ж, не обійдусь і без зауважень:

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

Перевантаженість відповідей деталями — часто переходив у надмірне заглиблення в питання, що ускладнює фокус інтервʼюєра й демонструє слабке управління розповіддю. Моя особиста порада — завжди відповідайте на поставлене питання, давайте трохи глибини, але на керованому вами рівні. Тобто так, щоб інтервʼюєр поставив вам уточнююче запитання, на яке ви точно відповісте. Ви просто можете договоритися до речей, знання про які у вас можуть бути не дуже впевнені, а от я, наприклад, цим обовʼязково скористаюсь. Усе, що ви скажете, може і буде використано проти вас ;)

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

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

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

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

@babichdev

Товариство, початок публічної співбесіди React Native Junior уже за пʼять хвилин, не проґавте!

https://youtube.com/live/alIvA6pZ-nM

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

В одному з попередніх дописів ми розглянули, що відбувається, коли HTML-документ потрапляє до бравзера. Серед цих етапів — парсинг і рендеринг. Якщо коротко, то парсинг це перетворення текстового представлення HTML на DOM, а рендеринг — це процес перетворення цієї структури на зображення у вікні переглядача.

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

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

Чому так? Бравзер припускає, що скрипт може змінити структуру документа. Наприклад, вставити щось через document.write() чи переписати DOM через innerHTML. Щоправда, нині деякі бравзери вдаються до speculative parsing, продовжуючи "паралельний" парсинг, готуючись до найгіршого, але сподіваючись на краще.

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

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

Стилі ж блокують суто рендеринг. Чим більше у вас підключено різних стилів, чим більшою буде затримка, бо кожен з них бравзер оброблятиме окремо. Це потрібно для того, щоб перед рендером у бравзера вже був готовий CSSOM. З нього він будує Render Tree — і тільки тоді малює сторінку.

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

Також, якщо ви використовуєте @import, ви додаєте ще одну затримку до цього процесу, бо такі імпорти обробляються відкладено.

Тут в нагоді стане використання так званого critical path, коли найнеобхідніші стилі, які потрібні для побудови першого відображення, яке дозволяє користувачу вже взаємодіяти зі сторінкою, "вшивають" в сам HTML, тобто додають прямо в head.

І як вишенька на торті — шрифти. Так, шрифти теж блокують рендер, але у свій спосіб — якщо ваш шрифт вантажиться довго, то ви побачите саму сторінку, а от текст на ній не побачите. Це називається FOIT — Flash of Invisible Text.

Зарадити цьому можна в кілька способів. Можна використати font-display: swap, тоді текст відобразиться системним шрифтом, поки ваш красивий ще вантажиться.

Можна зробити передзавантаження шрифту через <link rel="preload" .../> в head (але без фанатизму). Це не позбавить цієї проблеми повністю, але дозволить суттєво знизити час очікування.

"Схуднення" файлу шрифта теж, очевидно, допоможе. Прибрати усі непотрібні накреслення, зменшивши таким чином розмір файлу, допоможе прискорити його завантаження.

Найнепопулярніший, але найнадійніший спосіб же — не використовувати зовнішні шрифти. Але кому то цікаво в 2025 році?

🔗 Web Dev: First Contentful Paint
🔗 Web Dev: Render Blocking CSS
🔗 MDN: Optimizing JavaScript downloads

Та й таке. Щось з того практикуєте, чи покладаєтесь на хорошу погоду і стабільний інтернет користувача? Зізнавайтесь.

***
Якщо вам сподобався цей допис, то разом із вогником або серденьком до цього допису додати ще й кілька гривень донату на Mavic для 184 навчального центру. А якщо не сподобався, я це і так зрозумію. Дякую всім і цьом вам у лобіка.
https://send.monobank.ua/jar/AeXQ6YRf2X
5375411202918178

***
@babichdev

#анонс
Товариство, прийшов час пробувати щось нове, тож уже цього четверга, 17 липня, о 19:00 нова публічна співбесіда на ютубі, і цього разу це буде React Native!

Мій гість — Вадим Ващук, React Native-розробник із понад 2 роками досвіду. Починав під менторством досвідченого фронтендера, а згодом став єдиним мобільним інженером у продуктовій команді.

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

Тож готуйтеся до нових вражень від співбесіди, бо ми пірнаємо у мобільну розробку!

📆 17 липня, 19:00

📺 youtube.com/live/alIvA6pZ-nM

Обовʼязково зайдіть поставити вподобайку на відео та втиснути дзвіночок, аби не пропустити етер! Як завжди раджу дивитися наживо.

***
Партнер етеру — appflame, українська продуктова ІТ-компанія, що створює такі продукти, як Taimi, Hily, AdConnect, Mailkeeper. 6 років на ринку, 450+ спеціалістів, ТОП-5 роботодавців за версією Forbes Ukraine.

Вакансії appflame: bit.ly/4nTbWD2

***
@babichdev

#анонс
Товариство, маю чудову новину! Уже за два тижні я візьму участь у найкулуарнішій (шо б це не означало) конференції України Party Hard!

26 липня я розповідатиму про свій досвід вайбкодинга, які плюси, мінуси й підводні камені я зустрів, поділюся спостереженнями щодо того, як використовувати ШІ та кодогенерацію в роботі та побуті і, звичайно ж, зачіплю тему того, що я вважаю вайбкодингом, а що — ні.

Беріть квиточки на конференцію поки є, не зволікайте!

м. Львів, !FESTrepublic
26 липня 2025 | 11:33

🔔 КВИТКИ ТУТ

#html_in_action
Працюючи з формами, ми часто стикаємось з однією з найпоширеніших задач — "вимкнути" певний інпут із взаємодії з користувачем. Тобто ми хочемо, аби користувач бачив поле для вводу, але не міг змінити його значення.

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

Однак, як виявляється, це не завжди правильне рішення. Справа в тому, що атрибут disabled доволі радикальний, і не просто "вимикає" інпут, а радше робить його "вигнанцем". Дивіться самі:

— Значення поля не потрапляє до FormData;
— Екранні читалки його попросту ігнорують;
— Інпут випадає з клавіатурної навігації;
— Інші події також перестають працювати.

Дещо надмірно, еге ж?

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

Рішення просте і, як виявилося, далеко не нове. На додачу до disabled у інпутів є атрибут readonly, який робить саме те, що потрібно в більшості випадків: просто не дозволяє взаємодіяти зі значенням. Але усі інші взаємодії при цьому лишаються:

— Поле лишається фокусованим;
— Значення буде додано до FormData;
— Скринрідери бачитимуть елемент і описуватимуть його відповідно, з оговіркою про неможливість редагування;
— Події працюють, як і зазвичай — focus, blur, click і так далі.

Також цей атрибут має супутній псевдоклас в CSS — :read-only, дозволяючи стилізувати такий інпут у потрібний спосіб, не обмежуючи при цьому його доступність для документа.

Як я зазначив дещо раніше, це геть не нова можливість. Вперше цей атрибут зʼявився ще 2004 року у Firefox!

Якщо підбити короткий підсумок, то видається очевидним, що для "вимикання" інпуту варто використовувати саме атрибут readonly, особливо якщо це значення потрібно на бекенді.

disabled же, по суті, лише за один крок від display: none, тож я би радив за можливості не користуватися ним для інпутів. Кнопки — безперечно так, а от щодо поля вводу — краще подумати ще раз. Ліпше вже видалити його з DOM, ніж прирікати на таку долю.

🔗 MDN: readonly

Ану розкажіть, які причини, окрім того, що ви не знали про readonly, змушують вас і далі всюди розставляти disabled?

***
@babichdev

***
Пропоную разом із вогником або серденьком до цього допису додати ще й кілька гривень донату на Mavic для 184 навчального центру. Дякую всім і цьом вам у лобіка.
https://send.monobank.ua/jar/AeXQ6YRf2X
5375411202918178

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

Натомість нагадаю вам про збір на Mavic для 184 навчального центру. Логічно — він потрібен, аби новобранці знайомилися з дронами ще під час БЗВП.

https://send.monobank.ua/jar/AeXQ6YRf2X
5375411202918178

Дякую за кожну гривню! Буквально. А хто її вже закинув і закидатиме — цьом вам у лобіка.

Побіг в справах.