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

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

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

Також уже сьогодні буду розмовляти з учасниками нових випусків на ютубі. Тут я вирішив зробити кілька кроків назад, і повернутися до ваших улюблених співбесід. Тепер з присмаком лайна ШІ. Будемо експериментувати і шукати ідеальний баланс між вимогами до власної експертизи та вміння витрачати токени. Такі часи. Найближчий запис нового випуску, як дадуть боги і здоровʼя відбудеться доволі скоро.

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

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

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

Тож лишайтеся на звʼязку і, сподіваюся, до скорої зустрічі.

Всім цьом у лобіка.

Занотуйте собі в календар — наступного четверга будем записувати новий випуск вайбкод рев'ю по NodeJS.

#css_in_action
У вас є декілька однотипних класів: item-1, item-2, item-3 … item-N. Опустимо, чому вони у вас є, це питання іншого штибу, тож у вас є задача — написати селектор, що вибиратиме усі елементи з такими класами.

Перше, що може прийти в голову — використати селектор [class^="item-"]. Він вибиратиме усі елементи, значення атрибуту class якого починається з item-. І це працюватиме, поки ваш клас item- стоїть першим. Щойно ви додасте щось на початок, наприклад warning item-1, селектор "зламається".

Тоді вам в голову може прийти ось таке чудо: [class^="item-"], [class*=" item-"]. Ви додаєте селектор, який додатково ловитиме входження рядка " item-" в значення атрибуту. І це теж буде працювати. Поки у вас не зʼявиться (з якоїсь причини) щось на кшталт class="item-" чи class="item--foo". А вам треба виключно сімейство item-*, бо item--* — це якась дич.

Що ж робити? Ну, на даний момент — засмучуватися. Але ненадовго. Буквально 6 серпня CSSWG погодила додати class prefix selector до Selectors Level 5.

Виглядає він ось так:

.item-* { … }

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

Тобто отаке працювати не повинно:

.item_* { … }

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

.item--* { … }

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

<div class="primary
item-main">…</div>

Нестинг працюватиме як і зазвичай:

.item-* {
  &:hover {}
  > .icon {}
}

А от на конкатенацію імені розраховувати не варто. Залиште це SCSS, хай вже помре конячка.

.item-* {
  &bar {} /* .item-bar не буде. Бо це неправильний селектор. */
}

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

А яких селекторів не вистачає вам, товариство? Пишіть в коментарях, не соромтесь.

Що почитати:
The Future of CSS: Class Prefix Selector

Що почитати душнілам:
CSSWG #10001 — Class Prefix Selector proposal
Selectors 5 spec source

@babichdev

А як людям ще дізнаватися про мої нові відео?! Страшне.

#партнерський_допис
Товариство, запрошую вас цієї пʼятниці, 18 вересня, на найкулуарнішу конфу України — Party Hard #12.
Цього року конфа буде про стартапи, ШІ, продукти, найм та, звичайно ж — про спілкування. Нетворкінг на цій конфі просто шальоний.

Особисто я теж дуже-дуже постараюсь там бути, бо пора б вибратись зі свого лісу і вийти до людей.

Я прям дуже рекомендую відвідати Party Hard, тим паче маю для вас знижку у 7%.

Деталі події за посиланням:
https://yoy.events/lviv-12-promo-babich

Оце я, канєшна, провтикав.
Конфа завтра, 19 вересня.
Ще встигаєте взяти квиточок.

Який ШІ найкращий для навчання?

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

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

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

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

І я навмисно кажу "інформації", а не знань, бо знання — це коли ви знаєте і вмієте застосувати те, що дізналися.

І тут неважливо, що у вас — ChatGPT, Perplexity, Claude чи ще якась китайська модель. Важливо те, що ви з нею робите.

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

Особисто я активно використовую ШІ для пошуку нової інформації — від нових рецептів і білдів в Diablo IV до абсолютно нових для себе проблем в розробці, програмуванні чи якихось інших професійних аспектах. Про самі підходи до того, яку інформацію шукати, і як навчитись їй не довіряти — це, певно, тема для двогодинного монологу.

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

До речі, один приклад я таки наведу. На так давно я почав активно працювати над Python задачами на проєкті, проте сам Python я знаю на рівні "ну, це пайтон, ну, я плюс-мінус здатний осягнути що тут написано". Але далеко не на 100%. І от коли я зустрічав в згенерованому коді не зовсім зрозумілі фрагменти, я часто просив ШІ пояснити їх мені на прикладі JavaScript. Тобто я брав конкретну необізнаність і накладав її на свою обізнаність. І це було прям дуже помічне.

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

В першу чергу вчіться вчитися.

***
До речі, нагадую, що збір на авто для 21 ОМБр нікуди не дівся, тож буду дуже вдячний за кожну вашу гривню.

🔗 send.monobank.ua/jar/AeXQ6YRf2X
💳 5375411202918178

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

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

На ділі що setTimeout, що setInterval не виконують ваш код через заданий проміжок часу. Вони ставлять його в чергу. Це суттєва різниця. Тобто це не "виконай через точно 1000ms", а радше "я тут вам задачку залишив, запусти за нагоди, але не раніше ніж 1000ms". Це якщо прям дуже приблизно. Я не буду вдаватися в деталі, там вам і улюблений event loop, і черги, і так звана однопоточність.

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

Перше, що прийде нам в голову для такого лічильника, — запустити setInterval:

setInterval(() => doMagic(), 1000);

Це найнаївніший спосіб. setInterval намагається запускати callback із заданою періодичністю, але не гарантує момент його фактичного виконання. Якщо main thread зайнятий, виклик відбудеться пізніше. Якщо ж ми просто робимо seconds++, то починаємо вимірювати не час, а кількість викликів — і рано чи пізно ці дві величини можуть розійтися.

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

const tick = () => {
  …
  setTimeout(() => tick(), 1000);
}
tick();

Краще розраховувати наступний таймаут як залишок до бажаного моменту в майбутньому:

let next = performance.now() + 1000;
const tick = () => {
  next += 1000;

  const delay = Math.max(0, next - performance.now());
  setTimeout(tick, delay);
}
setTimeout(tick, 1000);

Оцей delay буде трошки менше за 1000ms, бо враховує похибку попередньої ітерації.

Це працює в ідеальних умовах, коли основний потік нічим суттєво не зайнятий. Але setTimeout не гарантує, що callback виконається саме в заданий момент. Якщо main thread зайнятий JavaScript, layout, rendering чи іншою роботою, callback чекатиме. Якщо потік буде заблокований більше секунди, ми можемо взагалі проскочити момент оновлення інтерфейсу.

А оскільки нам зрештою треба не просто щось порахувати, а намалювати нове значення, можна передати останній крок requestAnimationFrame. Він не робить таймер точнішим і не обходить заблокований main thread — він просить браузер виконати оновлення перед наступним repaint.

let next = performance.now() + 1000;

const tick = () => {
  console.log('tick');

  next += 1000;

  const delay = Math.max(0, next - performance.now());
  setTimeout(() => requestAnimationFrame(tick), delay);
};

setTimeout(() => requestAnimationFrame(tick), 1000);

Тут requestAnimationFrame розвʼязує не проблему точності, а іншу: якщо результат треба показати користувачу, ми можемо синхронізувати DOM-update з наступним кадром браузера. Аби не перескакувати секунди, варто ще знати, скільки часу пройшло з останнього виконання:

let previous = performance.now();
let seconds = 0;

const tick = (now) => {
  // Ось тут визначаємо, скільки реально минуло секунд
  // і на скільки нам треба "стрибнути" вперед
  const elapsed = now - previous;
  previous = now;
  seconds += elapsed / 1000;
  …
  setTimeout(() => requestAnimationFrame(tick), 1000);
};

requestAnimationFrame(tick);

Такий підхід дозволяє максимально точно рахувати "тіки". Але є одне але, якого ну ніяк не уникнути — якщо ваш UI таки важкий, то іноді лічильник буде прострибувати значення не через рівні проміжки часу, наприклад 0.5с > 1с > 3с. Але при цьому показуватиме точний час. Це вимушений трейдоф через завантажений основний потік. Але це вже проблема не лічильника, а ваша — бо чого це у вас така важка сторінка, га?

Що почитати:
MDN — setTimeout()
MDN — requestAnimationFrame()

Що почитати душнілам:
HTML Living Standard — Timers

---

Збір на авто для 21 ОМБр триває, зібрано 22 200грн з необхідних 271 500грн.

🔗 send.monobank.ua/jar/AeXQ6YRf2X
💳 5375411202918178