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

https://www.youtube.com/live/3aBzFZjxb6w?si=dmx4xNBWdEdr1rA5

А сьогодні я на DOU Day ) Тож хто тут ще є — підходьте, будем робить селфіки і обмінюватись контактами ;)

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

А я вам скажу — на конференціях треба займатись усім! Якщо вас не дуже приваблює тема доповіді — сміливо йдіть пити каву та знайомитись. Втомились від розмов — ласкаво просимо до зали, там якраз виступає Бабіч. І не забудьте пробігтись партнерськими “будками” — там, окрім стікерів, шкарпеток та іншого дрібʼязку, іноді розігрують класні подарунки в обмін на ваші повні контакти, включно зі скрином з Дії. Але без жартів: саме на стендах я познайомився з багатьма HR, PR та рекрутерами, з якими досі спілкуємось. Одне таке знайомство навіть принесло мені роботу.

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

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

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

Жартую (чи ні). Беріть від таких подій максимум: дізнавайтесь нове, знайомтесь, тусіть — і, по можливості, завжди потрапляйте на неофіційні пре- та афтепаті (але носіть із собою бетаргін).

Хто з вас був на моїй доповіді на DOU Day? Діліться відгуками в коментарях!

@babichdev

***
До речі, вже цієї суботи я виступатиму на JavaScript fwdays’25, і у вас є шанс виграти один із двох квитків на цю подію. Що треба зробити? Задонатити від 100 гривень та покластися на удачу!

Good Enough Code. ч.1
Код на відчепись, чи відчепіться від мого коду?

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

Так ось це і є зіткнення перфекціонізму з "достатністю" — і саме тут починається наша розмова про Good Enough Code.

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

У реальності більшість задач — це не архітектурні шедеври, а практичні компроміси. І намагання зробити "ідеально" часто шкодить більше, ніж допомагає. Час іде на дрібниці, фідбек затримується, команда буксує в ревʼю. Продукт стоїть. Користувач чекає.

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

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

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

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

Зацікавило? Тоді ставте вподобайки і діліться з друзями!

І якщо цей допис набере понад 150 реакцій та 1000 переглядів, то у наступних дописах ми з вами обовʼязково розглянемо:
– Як відрізнити достатній код від халтури?
– Які критерії “good enough”?
– Чому перфекціонізм — це теж технічний борг?
– Як впровадити цей підхід у команду й не перетворити все на безконтрольну лінь?

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

100 гривень на РЕБ — квиток на fwdays

@babichdev

Друзі, у вас лишається лише доба на те, аби взяти участь у розіграші одного з двох Full Ticket квитків на JavaScript fwdays'25!

Усе, що треба — просто долучитися до збору на РЕБ для в/ч А3892.

Кожні 100 грн — ще один шанс виграти.
Фінальна ціль — 260 000 грн.

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

Номер картки банки
4441111125077309

Переможців обиратиму уже завтра, 21 травня, рандомом від monobank.

@babichdev

То null це обʼєкт чи не обʼєкт?!
Певен, ви не раз натрапляли на чергову добірку "приколів" в дусі "ха-ха, JavaScript тупий", в якій точно була згадка про те, що typeof null === 'object'. Хоча насправді null не object. Правда, тупо?

На перший погляд. Але якщо копнути глибше, виявиться, що null це null, а причина такої поведінки typeof захована у глибині віків.

У ранній реалізації JavaScript оператор typeof не мав окремої перевірки на null. Він просто дивився: чи значення схоже на обʼєкт — тобто, чи є посиланням у памʼяті (pointer). А null тоді представлявся як 0x00 — класичний null pointer. Не буквальний, як у C, але концептуально споріднений: “порожнє місце”, що колись мало би бути посиланням.

І через те, що typeof не заглиблювався в перевірку, а лише умовно питав: «Чи це посилання?», то 0x00 сприймалося як “так” — і typeof null повертав "object".

Цю поведінку закріпили в ECMA-262, і пізніше вже не змогли виправити — занадто багато коду залежало від цього “багу”. А Брендан Айк прямо назвав таку поведінку помилкою: (1)

I said typeof null == “object” was a mistake because code that condition guards must null-test before dereferencing

***
Ну а тепер — “ок, а нашо це нам?”. А ось навіщо: ця поведінка лишається актуальною. І банальна перевірка:

if (typeof x === 'object') {
  x.foo();
}

…пропустить null. І при звертанні до foo зловите класичний Uncaught TypeError: Cannot read properties of null.

Тому при перевірці на обʼєкт варто додавати й перевірку на "не null":

typeof x === 'object' && x !== null

Ось такий цікавий "баг"-стандарт, що старіший за більшість сучасних веброзробників.

А ви стикалися з ним на практиці? Скільки ночей коштував вам пошук, чому код постійно падає від "Uncaught TypeError…"? Діліться в коментарях!

P.S. Так, так я знаю про оператор ?. і сам активно ним користуюсь. От набере цей допис 101 вподобайку, тоді й розглянемо, чи є цей оператор панацеєю від усіх null.

***
Останній шанс виграти один з двох Full Ticket квитків на JS fwdays'25! Долучайся, донать 100 гривень і вигравай!

@babichdev

Вітаю переможців розіграшу!

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

Дякую ще раз, і до зустрічі уже цієї суботи!

З переможцями звʼяжусь щойно отримаю контакти.

Good Enough Code. ч.2
GEC ≠ халтура
[ч.1 | ч.3]

Часто можна почути: мовляв, “достатньо хороший код” — це просто красива назва для того, щоб зробити абияк. Проте, це не так.

Good Enough Code — це не про недбалість. Це про свідомий, зважений вибір з розумінням наслідків та прийняттям відповідальности за ці наслідки.

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

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

Як відрізнити достатній код від халтури?
Ключ — у мотивації та наслідках. Халтура — це “аби відчепилися”, без розуміння впливу. GEC — це “зроблено достатньо добре для цієї задачі”, з розрахунком на підтримку, ризики й фокус на результат.

І ось тут треба зрозуміти найголовніше: "достатньо добре" не існує без контексту.

GEC це не універсальний стандарт якості, це про відповідність якості обставинам:

– Якщо це скрипт, який разово пройде по CSV-шці для маркетологів — “достатньо” може означати “працює, не падає, зроблено за 20 хвилин”.

– Якщо це MVP — enough це коли ви можете за дві хвилини показати користувачеві цінність.

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

Good Enough Code — це не компроміс заради компромісу. Це розуміння, де саме пролягає межа між "ще треба доробити" та "вже не має сенсу".

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

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

***
Наступного разу ми поговоримо про найбільшого ворога розробника — diminishing returns та чому більше часу далеко не завжди значить більше якості.

@babichdev
.

Тим часом вирушаю до Києва, аби зустрітися з вами на JavaScript fwdays'25 та розповісти вам про таємничі сигнали з космосу )

І так, завтра буде препаті ;)

На неймовірно ламповій та затишній конференції JavaScript fwdays'25 розповідав про сигнали, що це таке, кому вони треба, і чому ми маємо знати про них вже.

Дякую глядачам за неймовірно теплий прийом )

P.S. Велика стаття про сигнали встала в чергу ;)

27 травня, Львів. Атляс. 19:00.
Жива дискусія про якість і швидкість у розробці.

Я — за Good Enough Code. Роман Марінський — за Clean Code. За філіжанкою (не)кави шукатимемо істину та обговоримо переваги й недоліки обох підходів.

Квиточки: https://secure.wayforpay.com/payment/cctd_vs_gec

Усі гривні — на ЗСУ.

Чекатиму на вас.

@babichdev

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

Що таке Symbol? Для чого він? Які задачі вирішує? Гайда розбиратися.

Символи — це особливі примітиви, які гарантують максимальну унікальність значення. Настільки максимальну, що Symbol('foo') !== Symbol('foo'). Оця текстова мітка — по суті просто ваша примітка до змінної, а не частина самого значення.

Символи дозволяють уникати конфліктів у ключах обʼєкта. Навіть якщо у вас символздєсь і символздєсь — це завжди різні значення. Ви можете абсолютно спокійно робити таке (тільки от нашо?):

const object = {
  [Symbol("підпиздєсь")]: "foo",
  [Symbol("підпиздєсь")]: "bar"
};

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

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

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

Символи неперелічувані — їх не видно в Object.keys, for...in, JSON.stringify. Але можна дістати через Object.getOwnPropertySymbols(obj) або Object.getOwnPropertyDenoscriptors(obj).

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

До речі, про унікальність. Існує API Symbol.for(), яке дозволяє створювати загальнодоступні символи з єдиною ідентичністю, які зберігаються в глобальному реєстрі військовозобовʼязаних:

const here = Symbol.for('підпиздєсь');
const there = Symbol.for('підпиздєсь');

console.log(here === there); // true

Також існують так звані well-known Symbols, які працюють як API-хуки: ті ж Symbol.iterator, Symbol.toStringTag, які дозволяють описувати власні імплементації для певних поведінок. Наприклад, описавши метод [Symbol.iterator] у класі або обʼєкті, ми зробимо такий обʼєкт Iterable.

Швидше за все, ви не будете стикатися з ними щодня. Хіба ви розробляєте якусь бібліотеку або рішення, в якому надзвичайно важлива інкапсуляція на рівні обʼєктів.

🔗 MDN

Зізнавайтесь, хоч трошки зрозуміли, що таке Symbol? І обовʼязково поділіться своїм досвідом роботи з ним в коментарях (навіть якщо й не зрозуміли)!

@babichdev

Вподобайки, поширення — я про це вже не мав би вам нагадувать ;)

***
📣 Нагадую, що завтра (27.05) чекатиму вас на затишній дискусії про Clean Code vs Good Enough Code у Львові! Приходьте самі та запрошуйте колег!

Good Enough Code, ч.3 — Diminishing returns
[ч.2] | [ч.4]

Що найбільше заважає нам у розробці? Звісно, ми самі. Але сьогодні мова про більш конкретного ворога — diminishing returns.

До прикладу, вам до рук потрапляє якийсь модуль, який вам за першу ітерацію вдається оптимізувати, припустимо, на 50% — з 400мс до 200мс. Наступні дві ітерації дають ще 10% — з 200мс до 180, потім ще 10%, вже до 162. Але зусиль — утричі більше.

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

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

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

Ось тут вперше й прозвучить головна ідея усієї концепції Good Enough Code:
"Час від часу випускайте на волю свого внутрішнього Януковича, який казатиме вам “АСТАНАВІТЄСЬ“".

Вкрай важливо розуміти, коли ваше пакращення уже не буде пакращенням. Якщо ви намагаєтесь досягти прискорення вашого алгоритму на 2мс у фінансовому застосунку — це абсолютно виправдано. Там це може означати втрачені мільйони. Але якщо ви третій тиждень поліруєте форму на п’ять полів, щоб кнопка Submit спрацьовувала на 20мс швидше — це марно згаяний час. Користувач не помітить різниці.

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

Не все потребує покращення. Я знаю, цю думку складно прийняти. Ще раз: не все потребує покращення. Але усе потребує стабільности. Про що ми й поговоримо наступного разу.

Якщо вам дуже сподобався цей допис, звичайно.

@babichdev

Дуже цікаво дізнатися вашу думку щодо diminishing returns — згодні, не згодні, вважаєте це проблемою чи вигадкою? Ласкаво прошу до дискусії!

#good_enough_code

Як "вимкнути" частину форми?
Доволі часто перед нами постає задача "вимкнути", або ж задізейблити відразу цілу частину форми, а не один якийсь інпут. Не знаю, як ви, а я часто вимикав усі контроли по одному.

А виявляється, що це можна зробити за допомогою атрибуту disabled елемента fieldset! Якщо встановити значення цього артибуту у правдиве значення, то усі вкладені в цей fieldset інтерактивні елементи заблокуються. І інпути, і кнопки, і селекти. Все.

Але існує запасне рішення на той випадок, якщо вам потрібно, до прикладу, залишити якийсь елемент активним. Наприклад, кнопку "Редагувати". Тоді ви можете її помістити до вкладеного legend, всередині якого закони й правила не діють. Ну, як мінімум, батьківський disabled ігнорується.

<fieldset disabled>
  <legend>
    Legend
    <button>Edit</button>
  </legend>

  <input>
  <button>Click me</button>
</fieldset>

Мені ця фіча точно стане в нагоді, а що скажете на це ви? Чи мали в практиці випадки, коли це могло б спростити ваш код? Розкажіть!

@babichdev

Цікаво? Корисно? Тисни вподобайку та ділися дописом з друзями та колегами!

#ДонатНаРЕБ
Збір для 109 ОГШБ 10 ОГШБр "Едельвейс"

Друзі, потрібно зібрати 100 000 гривень для дооплати засобу радіоелектронної боротьби для 109 окремого гірсько-штурмового батальйону. Більшу частину рахунку вже сплачено — залишилось добити фінал.

Щоб заохотити вас долучатися трохи активніше — я запускаю розіграш! За кожні 50 гривень донату ви отримуєте шанс виграти один із подарунків:

🎁 Пазл GoodLoot "Witcher: Griffin Fight"
Подарунок від мене особисто
🎯 Мета: 20 000 грн

🎁 Клавіатура R-Go Compact Break
Від друзів з ERGO PLACE
🎯 Мета: 50 000 грн

🎁 LEGO Dune Atreides Royal Ornithopter
Від української продуктової IT-компанії Brainstack
🎯 Мета: 100 000 грн

Щойно досягаємо відповідної мети — розігрую черговий подарунок серед усіх донатерів за допомогою monobank.

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

💳 Картка mono:
4441111124390562

Памʼятайте: не існує замалих донатів.
Кожен ваш внесок — це ще один збитий дрон.
Ще одне збережене життя.
Ще один крок до Перемоги.

Гра у хованки
Одна з найпоширеніших задач в розробці інтерфейсів — тимчасово приховати той чи інший елемент. І рішення, здавалось би, очевидне — зробити display: none, та й по всьому.

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

Приховати елемент можна у кілька способів, і вже згаданий display: none впевнено утримує першість. Коли ми застосовуємо цю властивість до елементу, він "зникає" з потоку документа, припиняючи брати участь в побудові рендер-дерева і, відповідно, візуального макету сторінки, так званого layout. При цьому з DOM він нікуди не зникає. Якщо коротко, то display: none прибирає усі видимі сліди присутности елемента.

А є visibility: hidden. І тут постає питання — а в чому ж різниця? А різниця в тому, що ця властивість прибирає лише відображення елемента, але його місце в render tree та layout зберігається. На сторінці при цьому утворюється "дірка" на місці цього елемента.

display: none нагадує магічний трюк зі зникненням, але з кінострічки "Престиж": елемент дійсно зникає, не припиняючи свого існування. Чи?.. Але це вже інше питання. А от visibility: hidden це як той же трюк, але в актовій залі вашої школи: елемент від вас просто затуляють білим простирадлом, усі знають, що він там, а крайні ряди навіть можуть трошки його побачити.

Чи згадати тоді про атрибут hidden? Хіба побіжно. Бо це просто ще один спосіб приховати за допомогою <div hidden> чи el.hidden = true. Але тільки у тому випадку, якщо ви не перевизначили стилі для селектора [hidden], який браузери за замовчуванням стилізують як display: none. А ви можете, я знаю.

А ви як, користуєтесь цими можливостями, чи не задумуючись, просто викидаєте елемент з DOM?

@babichdev

***
Приєднуйтесь до збору на РЕБ та вигравайте чудові подарунки від мене та моїх друзів!

Друзі, запрошую вас на Стрим для своїх №3!

Що це? Це затишно й по-дружньому проведений разом з вами вечір неділі і чудова нагода поставити мені запитання, на яке я можу дати як розлогу відповідь, варту цілого відео, так і вкластися в одне речення )

Досі тривожить, чи прийде сіренький вовчок ШІ і забере роботу? Цікавить, чому я не вважаю React найкращим у світі інструментом? Хочете зрозуміти, як рухатись далі в карʼєрі? Словом — питайте мене що завгодно, а я з радістю відповім вам наживо уже цієї неділі, 1 червня, о 18:00 на закритому Стримі для своїх!

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

Чекатиму на вас!

Стрим для своїх №3
01 червня 2025, 18:00

Реєструйтесь тут: https://streamyard.com/watch/rYCqYEfzf5x9

А ще під час стриму я розіграю позачерговий подарунок за донати у зборі на РЕБ.

Гра в хованки 2: Швидкодія завдає удару у відповідь
В коментарях до попереднього допису про display vs visibility ви ніби жартома згадали opacity. Чи не згадав я про нього незаслужено? Дивіться, цей спосіб вирізняється однією суттєвою деталлю: навіть будучи повністю "невидимим", а по факту просто прозорим, елемент повністю зберігає всю інтерактивність — фокусабельність, події клавіатури й миші, а ще залишається повністю "видимим" скрінрідерів.

І зі скрінрідерами така історія, що майже усі способи направду сховають елемент від них, окрім того самого opacity. З ним вам доведеться вручну додавати атрибут aria-hidden. Тому жарти жартами, а a11y в сучасному світі треба знати й практикувати.

А що зі швидкодією?
Ховаючи елемент, нам важливо знати дві речі: як він поводитиметься зі скрінрідерами та скільки "коштуватиме" його відновлення.

І на це впливає в першу чергу те, чи викликатиметься reflow — процес перерахунку макету з видимих елементів. Цей процес насправді надзвичайно легко викликати, достатньо змінити будь-яку властивість елемента, що відповідає за його "фізичну" поведінку: розміри чи відступи. Ну і, очевидно, display.

Не вдаючись в подробиці, зазначу, що цей процес тим затратніший, чим більше у вас елементів у render-tree. Однак при цьому не найзатратніший, бо при цьому не змінюється DOM.

А от visibility та opacity reflow не викликатимуть, бо вони не змінюють жодних "фізичних" параметрів елемента, тож їх застосування викличе лише repaint. А він, у свою чергу, достатньо швидкий і давно дуууже сильно оптимізований бравзерами.

Я відчуваю гостру необхідність зануритись разом із вами в процес відображення сторінки бравзером, а саме розібрати усі ці дерева, та як вони між собою повʼязані. Що скажете? 100 вподобайок вистачить?

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

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

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

Майже кожна, навіть найменша зміна в DOM (а, тим паче, видалення/додавання елемента) потребує перевиконання повного циклу:
1. Оновити DOM
1¾. Оновити CSSOM (якщо змінили інлайн-стилі)
2. Оновити render-tree
3. Виконати reflow
4. Виконати repaint

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

У мене колись давно в практиці була задача з кастомним багаторівневим акордеоном, і виявилося, що ховати секції з display: none набагато швидше, аніж з класичним conditional rendering. Так, лаги усе одно були, але значно менші.

Тож підібʼємо підсумок: не всі "хованки" однаково корисні.
display: none і умовний рендеринг справді прибирають елемент із рендер-дерева, але коштом повної перебудови макету, а conditional rendering так і взагалі за рахунок зміни структури DOM. visibility: hidden і opacity: 0 лишають елемент у потоці, але поводяться зовсім по-різному з погляду доступности та взаємодії. Перший — неактивний і “німіє”, другий — поводиться як повноцінний видимий елемент, просто невидимий.

І лише розуміючи ці відмінності, можна ефективно керувати поведінкою інтерфейсу, не жертвуючи швидкодією та доступністю.

***
Ви вже долучилися до збору на РЕБ? Усього 50 гривень і шанс виграти класні подарунки — ваш!

#цього_тижня ми з вами дізналися багато нового і зробили багато корисного! Дивіться самі:
— В понеділок спробували зрозуміти, що таке Symbol в JS;
— У вівторок продовжили подорож до Good Enough Code, розглянувши що таке diminishing returns;
— В середу дізналися, як вимикати відразу цілу частину форми з fieldset;
— В четвер нагадали собі про різні способи сховати елемент на сторінці;
— У пʼятницю ж відразу порівняли, які з них псують швидкодію найбільше;

А також розпочали збір на 100 000 гривень для 109 ОГШБ 10 ОГШБр "Едельвейс", — і кожен донат бере участь у розіграші подарунків!

***
А завершимо ми цей тиждень завтра на Стримі для своїх №3. Буду радий бачити кожного з вас!