Новий допис буде тільки після того, як доведем збір до 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

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

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

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

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

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

Співбесіда Junior Angular з Нікітою Топчієм розпочнеться рівно за 5 хвилин!

youtube.com/watch?v=NxZYD5KZyNs

#browser_api
Ви коли-небудь відкривали вебінспектор для підсвіченого коду на тому ж GitHub? Якщо так, то бʼюся об заклад, що ви бачили щось таке:

<span class="blob-code-inner blob-code-marker " data-code-marker=" ">
  <span class="pl-s1">llm_type</span>
  <span class="pl-c1">=</span>
  <span class="pl-s1">fields</span>
  .
  <span class="pl-c1">ChoiceField</span>
  (
</span>

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

Але прийшов час радіти, бо тихо й непомітно зʼявилася специфікація Custom Highlight API, яка дозволяє розцяцьковувати текст на будь-який смак, не перевантажуючи сторінку оркестром диких span!

Тепер можна просто реєструвати Highlight, в який можна передати декілька діапазонів Range з позиціями, і вказувати стилі — усе без змін розмітки, завдяки CSS псевдоелементу ::highlight.

const range = new Range();
range.setStart(node, startOffset);
range.setEnd(node, endOffset);

const highlight = new Highlight(range);
CSS.highlights.set('myHighlight', highlight);

::highlight(myHighlight) {
  background-color: yellow;
}

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

І нам лишається лише розпарсити текст на токени й описати яким діапазонам які стилі призначені.

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

🌐 MDN: CSS Custom Highlight API

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

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

@babichdev

Good Enough Code. ч.4 — поради чи догмат?
[ч.3]

Зі сторони може здаватися, що Good Enough Code базується на якихось догмах, яких треба неухильно дотримуватися, і тоді код буде good enough сам по собі. Але насправді це зовсім не так — це не набір обов’язкових принципів, а радше філософія балансу.

Проте існує декілька орієнтирів, які добре знайомі розробникам і можуть допомогти не збитися з курсу, і як приклад можна узяти найвідоміші з них: YAGNI, KISS, DRY, Pareto.

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

Втім, важливо пам’ятати: сліпе застосування цих принципів може зашкодити не менше, ніж повне їх ігнорування. Тут, як і завжди в інженерії, все вирішує контекст.

YAGNI (You Aren’t Gonna Need It)
Цей принцип каже нам: «Не реалізовуй функціональність “про запас”, якщо в ній нема потреби просто зараз».

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

KISS (Keep It Simple, Stupid).
Простота — найбільша чеснота коду. Але простота без структури швидко перетворюється на хаос.

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

DRY (Don’t Repeat Yourself). «Не дублюй без потреби — це рятує від багів».
Водночас не варто передчасно абстрагувати, створюючи нечіткі ієрархії там, де простий повтор був би зрозумілішим і дешевшим.

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

Pareto principle (80/20 rule): 80% ефекту дають 20% зусиль — чудова ідея, якщо дозволяє контекст.
Але для критичних компонентів навіть дрібні недопрацювання можуть мати катастрофічні наслідки, тож тут Pareto працює значно обережніше.

Важливо розуміти: надмірне слідування будь-якому одному принципу майже гарантовано порушить інший. Спробуєш фанатично уникати повторів — постраждає простота; спростиш усе до мінімуму — втратиш масштабованість; поженешся за Pareto — ризикуєш пропустити критичні баги.

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

– Чи я не перестарався із ускладненням?
– Чи справді варто так абстрагувати?
– Чи достатньо цей код вирішує задачу тут і зараз?

Good Enough Code — це не догмат, не заповіді. Він радше покладається на вміння балансувати між простотою, якістю і контекстом, а головне питання, яким треба задаватися в пошуку цього балансу — «Для кого і навіщо цей код?»

#good_enough_code #мислення_розробника

@babichdev

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

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

Чекатиму ;)

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

А нині у мене до вас прямо дуже термінове прохання. Маємо на бронюванні Mavic для 184 навчального центру, і треба в дуже стислий термін зібрати 80 000 гривень. Проте є важливий момент — двох місяців, як минулого разу, у нас нема, а є тиждень.

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

Дякую!

***
На Mavic для 184 навчального центру

🎯 Ціль: 80 000 ₴

🔗Посилання на банку
https://send.monobank.ua/jar/AeXQ6YRf2X

💳Номер картки банки
5375411202918178

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

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

cache = {}

fn square(x):
  if not (x in cache):
    cache[x] = x * x
  return cache[x]

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

Так от. Головне питання — коли ж має сенс користуватися мемоїзацією?

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

Часто я бачу в коді "оптимізацію" на кшталт

const doubled = useMemo(
  () => value * 2,
  [value]
);

І це зовсім не оптимізація. На ділі value * 2 виконується практично миттєво, а головне — без використання надлишкових ресурсів.

У випадку з useMemo, відбудеться наступне: спершу створюється екземпляр анонімної функції, потім — новий масив залежностей; далі виконується useMemo, у якому спочатку порівнюються поточні залежності з попередніми, а за тим — відбувається умовна перевірка; і якщо value змінилося — то запускається ще й саме обчислення.

І усе це — заради однієї операції, яка сама по собі відбудеться настільки блискавично, що ваш M4 навіть її не помітить.

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

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

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

Тож давайте занотуємо: мемоїзація — це не синонім продуктивности. Це засіб уникнути повторної роботи там, де вона справді затратна. Якщо обчислення швидкі, чи виклики функції одноразові — не чіпайте.

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

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

***
@babichdev

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

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

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

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

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

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

В одному з попередніх дописів ми розглянули, що відбувається, коли 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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

@babichdev

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

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

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

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

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

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

@babichdev

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

#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