Запостив я отакий шорт на ютубі в підтримку останнього відео і отримав у коментарях наступний діалог:

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

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

***
Тут як. Колись дійсно тікети в джирі багато хто використовував для обліку робочого часу. Я сам таку практику застав. Відверто — це херня. Бо це нічого не дає, крім можливості підкручувати собі години.

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

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

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

Але в даному фрагменті мається дещо інше на увазі. Тут Артем казав про ситуацію, коли ми маємо безініціативного виконавця, який ніби й буде робити задачу, але тільки тоді, коли ХТОСЬ інший ЙОМУ зробить тікет. Вирішить за нього усі питання, уточнить незрозумілості, і на тарілочці подасть фінальний документ. І аж тоді наш програміст підніме дупцю і піде шось там кодірувать.

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

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

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

Якось так.

***
Ви вже подивилися це відео? Це просто відвал сраки, наскільки воно вийшли цікаве та круте.
https://www.youtube.com/watch?v=oyswnHaq_3E

Таска в жирі — страва традиційної айтішної кухні. Може мати шкідливий вплив на тиск та призводити до передчасного вигоряння.

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

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

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

Мова йде про datalist. Це надзвичайно простий елемент, який водночас забезпечує саме те, що від нього очікується — виведення списку підказок при введенні тексту у поле введення.

Виглядає це так:

<label for="city">Місто</label>
<input list="cities" name="city" id="city"/>

<datalist id="cities">
  <option value="Київ" />
  <option value="Львів" />
  <option value="Харків" />
  <option value="Одеса" />
</datalist>

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

При виборі елемента списку в інпут буде підставлено значення з атрибуту value і викликано стандартні події поля вводу, тому немає технічної можливості дізнатися, як саме значення було введено.

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

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

Щодо відмінності поведінки в бравзерах, тут, звичайно, доведеться прийняти стан справ як є.

Наприклад, Chromium та Webkit бравзери зараз покажуть і значення з атрибуту value, і текст між тегами option у випадайці. А от Firefox покаже лише підпис. Взагалі, саме у Firefox datalist має доволі обмежену імплементацію. До прикладу, логіка пошуку по списку суттєво відрізняється, якщо у option є і атрибут value і текст.

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

Ну або вішайте табличку "Найкраще працює в Chrome/Edge", ми це вже проходили.

Що почитати:
MDN: <datalist>

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

@babichdev

P.S. Якщо не поставите вогник чи серденько — я дуже засмучусь. Ви ж не хочете, аби я засмутивсь? Правда? ПРАВДА?

#анонс
Товариство, тут в четвер буде просто зашкалююча концентрація крутості на одному стримі )

Я йду в гості на ютуб, до Сергія Немчинського. Ви тільки погляньте, в якій компанії проведемо час: будуть і Артем Биковець, і Ілля Климов! Згадаємо, яким був IT-2025 — що здивувало, що дратувало, що смішило. Трішки зазирнемо в 2026-й, поділимось відчуттями, прогнозами й думками.

Одним словом — потеревенимо. Приходьте.

18 грудня, о 15:00

Стрим буде за ооооось цим посиланням:
https://www.youtube.com/watch?v=Jeudw2EeDrI

#css_in_action
Поставити box-sizing: border-box і забути. Ну якось так сьогодні виглядає перший рядок CSS на проєкті. Але чи всі знають, що це таке та на що впливає? Давайте глянемо.

box-sizing визначає, в який спосіб буде розраховано значення розмірів у box model – тобто як бравзер рахує фактичний розмір елемента в макеті. Давайте пригадаємо, з чого складаються фактичні виміри:

— content: розміри вмісту всередині елемента;
— padding: внутрішні відступи між вмістом та бордером;
— border: товщина рамки навколо елемента;

Ці три значення й визначають фінальний розмір. А от як саме — визначає та сама box model.

За замовчуванням усі блочні елементи використовують content-box, і це означає, що властивість width застосовується до content box, тобто до внутрішньої зони.

Таким чином фінальний розмір визначається формулою:

total = content + padding + border;

де content це значення width або height, залежно від виміру. Саме тому, якщо задати елементу width: 100px, padding: 4px та border-width: 1px ми отримаємо фактичну ширину в 110 пікселів.

А що робить border-box? Він змінює підхід до розрахунку. І тепер формула набуває іншого вигляду:

content = total - padding - border;

Тепер width описує розмір усього елемента, а внутрішній content автоматично підлаштовується.

Чому ми надаємо перевагу саме border-box? Причина проста: розміри стають передбачуваними. Якщо ми кажемо, що ширина має бути 100 пікселів, вона й буде 100 пікселів, незалежно від падінгів та бордерів.

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

До речі, колись у Firefox існував ще експериментальний padding-box, в якому значення width задавало суму content та padding, лишаючи border поза формулою. Але це не прижилося. Може й на краще.

І ще важливо, що margin ніколи не входив, не входить і, сподіваюсь, не входитиме до box-model, адже це не вимір елемента, а його відступ від навколишніх елементів в макеті.

border-box у стандарті зʼявився не відразу, перші робочі драфти було опубліковано на початку 00-х. А от широкої підтримки це значення набуло десь так в 2012 році.

Цікавий факт: саме така поведінка box model була в IE5-IE6, але не через прогресивне мислення розробників бравзера, а через банальний баг. І багато хто вважав, що така поведінка є інтуїтивнішою, ніж стандартна.

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

Що почитати
MDN: box-sizing

***
@babichdev

#анонс
Товариство, пишемо новий покдаст!

Цієї суботи, 20 грудня, о 19:00 відбудеться запис нового випуску подкасту "Подкаст у нас вдома", на якому разом з Уляною Білінською-Шута поговоримо про "Американську мрія: як працює найм в США".

Будемо говорити про американський ринок не тому, що туди «обовʼязково треба йти», а тому що саме там найчіткіше видно, як працює зрілий tech-найм. У США довші процеси, вища конкуренція й більша ціна помилки, тому рішення про найм рідко ухвалюють навмання. Цей ринок швидко знімає ілюзії й показує, що компаніям важливо не лише що ти знаєш, а як ти думаєш, говориш і береш відповідальність.

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

Моя гостя —Senior Manual Quality Assurance Engineer, ex- Uber,ex- Linkedin. 7 років назад з юристки перевчилась на тестувальницю у Кремнієвій Долині, і з тих пір працює в професії. Також, Уляна — QA Mentor і допомагає як новачкам, так і досвідченим QA рухатися карʼєрною драбиною.

Запис відбудеться онлайн, посилання на студію прикріплено до події в календарі. Додавайте собі, буду радий бачити усіх вас!

ДОДАТИ ПОДІЮ СОБІ В КАЛЕНДАР

@babichdev

#css_in_action

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

Firefox нарешті додав підтримку @scope.

Проблема ізоляції селекторів в CSS стара як світ. В першу чергу через те, що механізм каскаду не передбачає ізоляції, лише перевизначення. Специфічність, порядок, !important врешті решт.

Люди всіляко намагалися це вирішити, кидаючись з крайнощі в крайнощі — то богопротивний БЕМ, то дияволоугодний CSS-in-JS.

Аж ось, 2021 року, зʼявилася цікава специфікація — @scope. Вона окреслювала механізм "області видимості" стилів, який давав можливість дійсно ізолювати селектори. Перша реалізація не забарилася, і вже 2023 року підтримка зʼявилася у Chrome/Edge, з наступного року у Safari, ну а до Firefox її нам підвезли майже під ялиночку.

Чому це важливо? По факту, механізм @scope працює не на ізоляцію селекторів, а на їхню область видимості. За замовчуванням усі селектори в CSS глобальні. А от @scope дозволяє сказати, що .title всередині .card поводиться ось таким чином. І якщо ми визначаємо певне "обмежене" правило, то стилі будуть застосовуватися виключно до елемента всередині області видимості. А поза нею до такого ж селектора — не будуть.

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

<div class="card">
  <h2 class="title">Превіт</h2>
</div>
<h2 class="title">Світ</h2>

@scope (.card) {
  .title { color: lime }
}
.title { color: red }

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

Логічне питання: може це тому, що @scope додає специфічности? Але відповідь — ні, не додає. Ви можете перевірити це в Dev Tools.

Хоча зі специфічністю таки є нюанс — якщо я замість просто .title напишу h2.title в останньому правилі поза @scope, то цей стиль таки перебʼє наш зелений колір. "Специфічність, безсердечна ти сука", як сказав би Шелдон Купер.

Можна, звичайно ж, написати звично:

.card .title { … }

Але. В такий спосіб зʼявиться додаткова специфічність, якої зі @scope немає. Специфічність селектора в @scope визначається самим селектором, а не специфічністю селектора, яким задається область видимості. Тому навіть така конструкція матиме специфічність (0,1,0):

@scope (#card.override) {
  .title { color: lime }
}

На відміну від #card.override .title, яка матиме специфічність (1,2,0).

А ще області видимості можна задавати явно і початок, і кінець:

@scope (.parent) to (.child) { ... }

Це значить, що область видимості діє всередині .parent, але не поширюється на піддерево, коренем якого є .child.

Я особисто використовую @scope для стилізації своїх компонентів. Це дозволяє уникати складного "ізоляційного" коду, а також використовувати різні "утилітарні" класи без обмазування їх специфічністю.

Таким чином я можу спокійно мати щось на кшталт:

<h2 class="size-xxl"></h2>
<div class="card size-xxl"></div>

і описувати ось цей size-xxl всередині відповідного скоупа в один простий селектор замість бавитися у "Вгадай специфічність":

@scope (:is(h1, h2, h3)) {
  .size-xxl { … }
}
@scope (.card) {
  .size-xxl { … }
}

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

@scope в цілому дозволяє писати чистіший та зрозуміліший CSS, а також явно керувати правилами застосування селекторів. Це дуже важливий момент — не специфічністю, а саме тим, чи буде селектор застосовано взагалі. Це дуже суттєва різниця, яку необхідно дуже чітко зрозуміти.

Що почитати:
MDN: @scope

Що почитати душнілам:
W3C: Scoping Styles: the @scope rule

Вогник, серденько, цьом у лобіка.

@babichdev

#партнерський_допис
Ринок ІТ зараз турбує багатьох — особливо питання, як у ньому не потонути й усе-таки дійти до офера.

Саме про це Вікторія Захарова проведе завтра, 23 грудня, практичний воркшоп на 2–3 години. Буде про конкретні речі:

— Як поводитися та як готуватися в процесі пошуку: аналіз ринку, резюме, супровідні листи, профіль в LinkedIn, нетворкінг;

— Що робити зі своїми емоціями: звідки взяти дисципліну, як не зневіритися в пошуку а також які софт-скіли взагалі очікуються роботодавцями;

— Практичні поради, зведені у воркбук: як ним користуватися, аби були дійсні зміни і як їх контролювати.

Якщо коротко — це спроба зібрати цілісну картину пошуку роботи: від старту до офера з урахуванням реалій ринку 2026 року.

Корисно буде і тим, хто тільки починає пошук, і тим, хто вже давно в процесі.

Зустріч безоплатна, реєстрація тут:
https://bit.ly/workshop_strategy2026

🗓 Коли: 23 грудня о 19:00
📌 Формат: Google Meet + підтримка в Telegram
⌛️ Тривалість: 2–3 години


P.S. 100% коштів за розміщення допису спрямовано на потреби ЗСУ.

Зі святами, товариство!

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

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

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

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

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

З Різдвом та Новим роком!

Побачимось після свят ;)

DOU 2026
Відсьогодні розпочинається голосування за переможців Третьої Премії DOU, і завдяки виключно вам, товариство, моє імʼя — серед номінантів в категорії "Вони надихають".

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

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

Механіка дуже проста:
— Заходите на сторінку https://dou.ua/awards-2026/#voting
— Знаходите номінацію "Вони надихають";
— Довго (або не дуже) скролите, поки не знайдете картку, на якій скромно пише "Сергій Бабіч";
— Тицяєте в картку;
— Натискаєте кнопку "+ Обрати";
— Голосуєте за інших кандидатів та номінації;
— Отримуєте від мене безмежну подяку та уявний цьом у лобіка.

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

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

І це мотивує мене ще більше.

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

ПРОГОЛОСУВАТИ

Товариство, вітаю вас з Днем Програміста!

Зелених білдів та швидких деплоїв!

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

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

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

Натомість я проводив час з рідними: додивилися Stragner Things і навіть переглянули усі гідні уваги фільми про Чужого (так, час прийшов знайомити дітей з невмирущою класикою), завершив проходження ігор Gears of War із сином, шуфляв сніг надворі, хворів, читав. І от коли від цього усього лишалося трошки вільного часу, то займався своїми ідеями.

Наприклад, зробив форму запису на індивідуальну співбесіду для свого сайту. Який ще не в релізі, очевидно. Але побавився з Astro, поплювався на Svelte і замінив його на htmx, зробив інтеграцію з Notion та зламав вщент мозок об Google service accounts і їхню авторизацію.

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

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

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

Гарного усім початку робочого тижня!

@babichdev

Цейво, в четвер у Львові новий мітап від Лампи, лишилось 4 квитки, забирайте бігом.
https://secure.wayforpay.com/payment/lampa_3

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

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

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

Всім гарного дня!

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

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

Приходьте, буде затишно і лампово. І піца спільнокоштом теж буде.

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

Відкриваєм двері о 18:30 за адресою Львів, вул. Наукова 7д, офіс компанії Sigma Software.

Кошти з квитків ідуть на потреби ЗСУ

Зачекалися на нове відео? Цей день настав — вийшов запис першої «Співбесіди на сцені». Вона відбулася ще у вересні, і ось нарешті дісталася ваших екранів.

Думаєте, технічне інтерв’ю в прямому етері — це стрес? А як вам співбесіда перед живою авдиторією в 40 людей у залі?

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

Поставте вподобайку, напишіть коментар і поширте відео колегам.

📺 Співбесіда на сцені №1 — Senior Frontend

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

***
Подія відбулася завдяки Headway Inc — глобальній IT-компанії з українським корінням, що розвиває EdTech-продукти для навчання впродовж життя.

Інженерні вакансії Headway Inc

20 років тому я "навчався" на третьому курсі ЖДТУ, балансуючи між лютими пʼянками та маже авантюристськими спробами здавати сесії, не знаючи навіть, як виглядає викладач.

І от, поки я віддавався доступним мені гріхам, десь за океаном Джон Резіґ під час BarCamp NYC представив світу свій маленький пет-проєкт під назвою jQuery. А вже в серпні світ побачила перша релізна версія. І лише декілька років потому ніхто в здоровому ґлузді не починав робити новий проєкт, не підключивши до нього в першу чергу останню версію цієї бібліотеки. Чим же пояснюється така популярність?

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

А jQuery дбайливо заховав він розробника усе це длубання, і залишив йому простий як двері декларативний інструмент, виражений одним символом $.

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

Можна казати, що саме jQuery сформував культуру плагінів задовго до npm. Для усього був плагін — усі знають скриншот зі StackOverflow з питанням "як скласти два числа в JS" та відповідь на нього.

Ці плагіни покривали все: буквально від a + b до складних компонентів на кшталт каруселі зображень. Магією було те, що якою не була складна задача, вона закривалася одним рядочком коду (умовно).

І, звичайно, не можна не говорити про той вплив, який з часом здійснив jQuery на веб загалом. Саме завдяки йому ми маємо querySelectorAll, classList, fetch, addEventListener тощо. Зміни в стандарті підтягуються за потребами. Часто люди плутають причину й наслідок, і кажуть (в тому числі і я колись) щось типу "так а нафіг той jQuery треба, тето й тето є в стандарті!". Ну так от — а як воно в стандарті зʼявилось? Отож.

jQuery перетворив нудний статичний інтернет на місце сміливих експериментів та цікавого досвіду. Анімації, динамічний контент, активне використання AJAX — усе це дозволяло будувати вже не сторінки, а сайти. У повітрі відчувався той самий вітер змін, і лише питанням часом було пришестя Single Page Applications.

Так. Без jQuery не було б AngularJS, ReactJS та іншого зоопарку екзотичних способів забезпечити собі гідну зарплату та вбиті нерви.

"Write less, do more" — цей девіз відповідав дійсності на 100%. Крива входу нагадувала навіть не криву, а пряму лінію, яка ледь відлипала від осі X. Ваш покірний слуга так само прийшов до веброзробки ще 2010 року, взагалі нічого не розуміючи, але маючи змогу підключити плагін та налаштувати його так-сяк, покладаючись на матюки та інтуїцію.

Очевидно, існували й проблеми. Першою і найбільшою був менеджмент залежностей. Маю підозру, що й npm має завдячувати своїм існуванням jQuery. Один плагін працює з однією версією бібліотеки, інший з іншою, вони несумісні, їх треба ізолювати і коному дати свою версію, а один плагі ламає інший, бо перевизначає метод з таким же імʼям.

І це все вручну. Буквально. Жонглювання підключенням версій в HTML, маніпуляції з Immediately Invoked Function Expression для хоч якої симуляції модульности — дякую, спогад розблоковано.

Може здатися, що він вмер, але це далеко не так. На ньому стоїть сучасний інтернет. Майже 90% сайтів у світі, на яких використовується JavaScript, мають в своєму складі jQuery. Згадайте це наступного разу, коли будете тішити себе популярністю React.

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

"Write less, do more".

@babichdev

#коштозбір
Артбук S.T.A.L.K.E.R 2
за 100 гривень на збір для Житомирського військового інституту ім. С. П. Корольова.

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

А цього разу нас попросили допомогти з оплатою розхідників для стоматкабінету. По секрету нам сказали, що у них зараз служить стоматолог від бога, і він зможе робити справжні дива, якщо матиме усе необхідне.

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

Сума збору — 45 000 гривень (рахунок в коментарях).

А за кожні 100 гривень вашого донату ви отримаєте нагоду виграти Артбук S.T.A.L.K.E.R 2!

Дякую за кожну гривню, друзі. Разом ми робимо дійсно важливі речі.

https://send.monobank.ua/jar/3eiZbzwj8f

4874100024217146

Товариство, до завершення голосування за переможців у третій Премії DOU лишилося усього два дні.

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

Лишилося лише довести справу до кінця, та забезпечити призове місце )

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

Механіка дуже проста:
— Заходите на сторінку https://dou.ua/awards-2026/#voting
— Знаходите номінацію "Вони надихають";
— Довго (або не дуже) скролите, поки не знайдете картку, на якій скромно пише "Сергій Бабіч";
— Тицяєте в картку;
— Натискаєте кнопку "+ Обрати";
— Голосуєте за інших кандидатів та номінації;
— Отримуєте від мене безмежну подяку та уявний цьом у лобіка.

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

Дякую за кожен ваш голос!

Знаєте, що спільного між фразою "Х замінить програмістів" і лялькою Барбі?

Обидвоє зʼявилися 1959 року.

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

І почалися вони, ви не повірите, з… COBOL. Навіть його назва розшифровується як Common Business-Oriented Language. Мова мала спростити створення бізнес-програм, обіцяючи, що менеджери та аналітики зможуть читати код, розуміти його логіку і навіть писати програмні рішення самостійно.

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

Нічого не нагадує?

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

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

Наприкинці 1980-х індустрія задумуватись над тим, аби прибрати потребу в написанні коду — усе одно типові рішення усі однакові, навіщо їх щоразу писати? Краще описувати моделі й специфікації — а система генерує код. Так народилася парадигма CASE (Computer-Aided Software Engineering).

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

Нічого не нагадує?

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

А потім прийшли 90-і та принесли візуальну розробку. Тепер взагалі не треба було бути програмістом — наклікав собі вікна, наставив кнопки, притрусив простим як двері Visual Basic і, вуаля, ви тепер стартапер з власним продуктом (нічого не нагадує)?

Ну а далі цей локомотив лише набирав оберти: Excel, ERP-системи, Web та його no-code редактори, які зʼявилися задовго до самого терміну. Перші візуальні конструктори для вебу зʼявилися взагалі в середині 90-х років, коли сам веб ледь на ноги став. Ну хто з дідів не памʼятає Adobe Dreamweaver? Щоразу, коли хтось презентує "революційне" рішення для створення веб-рішень виключно мишкою, ми лише перевертаємось на інший бік і буркотим, що молодь знову вигадала дрімвівер. Бо ми знаємо його долю.

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

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

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

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

І лише Барбі сидітиме в своєму кабріолеті та дивитиметься на цю метушню з ледь помітною посмішкою.

@babichdev

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

Також нагадую, що за кожні 100 гривень вашого донату ви отримаєте нагоду виграти артбук S.T.A.L.K.E.R 2!

Дякую за кожну гривню!

https://send.monobank.ua/jar/3eiZbzwj8f

4874100024217146