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

#партнерський_допис
Товариство, уже 2 лютого починається наступний потік курсу “Мікросервісна архітектура” від Fwdays Academy та Кирила Мельничука!

За 12 занять ви дізнаєтеся, коли і як впроваджувати мікросервіси, які патерни та антипатерни слід враховувати, та як побудувати реальну архітектуру з нуля.

Графік: Пн, Ср та Сб
Детальніше:
https://bit.ly/48xM9dG

Ви навчитеся:
— Декомпозувати систему за допомогою DDD і Event Storming
— Проєктувати мікросервіси та їх взаємодію
— Працювати з API Gateway, BFF, Access Token
— Розгортати, моніторити й масштабувати сервіси
— Враховувати org-level трансформації

Ментор — Кирило Мельничук, CTO в AlterEGO та Uspacy, практикуючий архітектор з багаторічним досвідом трансформації систем. Він навчить не лише “як робити”, а й “чому так”.

Ви будете не просто слухати, а й працювати в командах, пройдете через весь процес та навіть захищатимете фінальний план переходу до мікросервісної архітектури!

Бонус для вас: 20% знижки за промокодом Babich

Отримуйте нові знання разом з Fwdays Academy!

Довге тире — вигадка ШІ?

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

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

В HTML існує ціла група спеціальних послідовностей для відображення таких символів. Називаються вони HTML Character Entities.

Поділяються вони на іменовані, наприклад < (<), та числові, виражені через десяткові коди — Æ (Æ). Деякі символи мають обидва представлення, інші ж — лише DEC-запис. Звичайно, ви можете використовувати й безпосередньо самі символи прямо в розмітці, але є кілька «але».

Деякі з них, як от <, є керуючими символами самого HTML, і можуть зламати розмітку. Або ж, якщо раптом ваш документ декодується не в UTF-8, символ може просто не відобразитись. А використання HTML-сутності гарантує, що бравзер покаже його незалежно від таблиці кодування (якщо документ взагалі парситься).

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

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

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

Лапок також існує велика кількість. І, що цікаво, деякі символи, які візуально нагадують лапки, ними не є. Наприклад, ″ — це не лапки, а подвійний штрих (″), який використовується для позначення координат на кшталт 50° 45′ 30″.

Так само для трикрапки на письмі існує… трикрапка — окремий символ ….

Ну і математика, куди ж без неї. Так, мінус — це не дефіс, а цілком собі мінус «−» (−), як от тут: «−15%». Для позначення нерівності варто використовувати символ ≠ (≠), а множення позначати символом × (×), а не астериском *.

Якщо вже повернутися до тире, то зазвичай на письмі використовується два: довге «—» (—) та коротке «–» (–), яке використовується для позначення діапазонів. Тож записати, до прикладу, «девʼять чи десять» правильно можна ось так: «9–10», а не «9-10».

Найпростіше ці символи вводити на Mac, адже там у стандартної клавіатури є спеціальний набір комбінацій саме для друкарських символів. На Windows з цим трохи сумніше — або користуватися Alt-послідовностями з «бухгалтерської» цифрової клавіатури, або ставити сторонні рішення.

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

Ну а при верстці в HTML найнадійніший спосіб зробити ваші тексти гарними та типографськи правильними — це використовувати HTML Entities.

Гарно оформлений текст і читається і сприймається набагато краще, навіть якщо це коротке повідомлення в месенджері.

Що почитати:
Technical Web Typography: Guidelines and Techniques

Що почитати душнілам:
WHATWG — Named character references

***
@babichdev

Товариство, завтра буду в Києві з візитом.

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

Має бути айтішно і смішно.

Коли?
31.01 (субота), збір гостей 18:00, початок - 18:30

Де?
м. Київ, коворкінг Kooperativ, вул. Січових Стрільців, 23A

Cкільки?
500 грн (квитки)

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

Далі пряма мова:

"Мене звати Ігор, я тімлід у Intellias. Шукаю людину у фронтенд-команду(Junior), для логістичного продукту у продакшені. Продукт активно розвивається, тому важливі уважність до змін і відповідальний підхід до якості.

Основний стек — Angular 21 та TypeScript. Роки досвіду не критичні, але важливо мати досвід командної роботи, розуміти Scrum-процеси, бути готовою працювати відповідально та навчатись.

У роботі багато взаємодії з бекенд-командою та дизайнерами: обговорення рішень, інтеграції, деталі реалізації.

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

Формат роботи: фултайм, віддалено. Локація — Львів, з можливістю працювати з офісу за бажанням.

За деталями в приват до мене @EducatedReptile"

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

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

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

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

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

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

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

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

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

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

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

@babichdev

P.S. Ви ж не забули, що у нас досі триває збір для Житомирського військового інституту? Правда? ПРАВДА?
Тим паче, де ви ще зможете виграти артбук по STALKER 2 за 100 гривень донату? Отож.

#коштозбір_для_ЖВІ
Товариство, щойно закрив частину рахунку на 30 000 гривень.
На банці нині 3 800 грн, треба ще 11 200 грн.

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

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

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

Дякую вам!

Енергоефективність. Слово, що перейшло з категорії "щось на політичному" до невідʼємної частини нашої буденності.

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

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

І в певний момент здавалося, що технологія ось-ось злетить — Chrome та Firefox додали повну підтримку, навіть Safari мала реалізацію (але тільки в коді, доступу не було).

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

Тут така річ, що будь-який додатковий сенсор стає частиною цифрового відбитка — і Battery Status API якраз із цієї категорії: він додає ще один стабільний сигнал про ваш пристрій.

Є одна цікава, але доволі перекручена в медіа історія про Uber, і хоч вона не повʼязана напряму з бравзерним Battery Status API, однак дає чітке розуміння, як корисні і невинні речі можна використовувати далеко не на користь.

2016 року Кіт Чен, на той час Head of Economic Research в Uber, висловив припущення, що клієнти з нижчим рівнем заряду набагато схильніші прийняти підвищену вартість поїздки. Це суто психологічне спостереження відкриває цікавий пласт питань — які ще непрямі поведінкові маркери можна зчитувати просто через ваш бравзер?

Ця фраза так сподобалась медіа, що "Uber піднімає ціну, якщо бачить низьку батарею" стало стійким міфом. Але чи міфом? У 2023 бельгійське видання Dernière Heure зробила один тест: два телефони, однаковий маршрут у той самий час, 12% батареї проти 84% — і ціна на низькій батареї вийшла вища (приблизно +6%). Uber це заперечив і заявив, що батарея не впливає на ціну, а ціноутворення залежить від попиту/пропозиції.

Реакція вендорів виявилася нетипово різкою для світу вебстандартів. WebKit заявили, що це суттєвий privacy-ризик і прибрали реалізацію Battery Status API з рушія. Mozilla також прибрала доступ до API у Firefox 52. А Chromium, хоч і не видалили його повністю, суттєво обмежили доступ до API.

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

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

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

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

Що почитати:
MDN: Battery Status API

Що почитати душнілам:
Battery Status Not Included: Assessing Privacy in Web Standards (pdf)

@babichdev

#нове_відео
Що стоїть між вами та офером з іншого континенту? Це не дотягуєте ви, чи проблема таки в фільтрах, рекрутерах, хибних очікуваннях з обох сторін, або, борони боже, в ШІ?

У новому випуску "Подкасту у нас вдома" разом з Ольгою Базуріною розкладаємо заокеанський найм по кроках: де вас може зрізати ATS/AI, чому «креативне» резюме інколи зводить нанівець усі шанси, і як читати сигнали компанії ще до призначення технічної співбесіди.

📺 Дивіться новий випуск вже:
АМЕРИКАНСЬКА МРІЯ В ІТ: як (не) дійти до офера з-за океану

Ольга — Global Talent Acquisition Manager із 10+ роками досвіду в США, Європі, Україні та LATAM; будує й масштабує технічні та C-level команди (зокрема Fortune 500); співвласниця міжнародної рекрутингової агенції, експертка з HRTech і Talent Intelligence.

Партнер випуску — RNRS Solutions: міжнародний рекрутинг для технологічних компаній — точковий підбір і побудова команд з нуля (IT, Miltech, FinTech, Data, Cloud, Telecom) у LATAM, США, ЄС, Великій Британії та MENA. Деталі — на сайті й у LinkedIn.

⚡️⚡️⚡️
А серед тих, хто дивитиметься дуже уважно, ми разом з RNRS Solutions розіграємо подарунки!
Умови прості: уважно слухайте, давайте правильні відповіді на запитання по відео, і дочекайтесь розіграшу.
⚡️⚡️⚡️

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

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

Чи може фронтенд-розробник зробити просто сайт?

Натрапив на просторах тредсу на допис, у якому авторка дещо висміює свою обізнаність про ІТ фразою "…спитала у front-end developer: «А в тебе є хтось, хто сайти робить?🤦‍♀️»". І подумав — так це доволі собі нормальне питання. От я не зможу.

Ну як «не зможу». Ручками лендос зверстаю. Чи там для себе якийсь статичний блоґ на якомусь реактоподібному фреймворку. А от так шоб «під ключ», на вордпресі, щоб клієнт не смикав мене за кожну зміну в тексті — тверде й рішуче ні.

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

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

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

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

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

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

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

Спеціалізація — це добре. Але, як я завжди кажу — лише на рівні галузі. Спеціалізацію на рівні React vs Vue я вважаю смішною і безглуздою (це так, шоб ви не забували, з яким душнілою маєте справу).

Тому так, «А в тебе є хтось, хто сайти робить?» — це абсолютно правильне і слушне питання до веброзробника.

@babichdev

#анонс
Співбесіда на сцені — Frontend Tech Lead

Хотіли побачити, як відбувається технічне інтервʼю такого рівня зі сторони? Цікаво, чи питають техлідів що таке івентлуп? Про що взагалі розмовляють на таких співбесідах?

28 лютого у Львові відбудеться запис нового випуску співбесіди на сцені, цього разу — з Frontend Tech Lead. Співбесіда обіцяє бути насиченою, цікавою і місцями несподіваною. Всіх карт не розкриватиму, але кандидат вас здивує ще до початку )

Партнером події є OBRIO — IT-компанія, що будує Nebula — продукт №1 в ніші spiritual wellness. Це продукт №1 у своїй ніші, який росте щороку х2 і вже завоював довіру 70+ мільйонів користувачів.

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

🗺️ Львів, вул. Ів. Франка 3, Львівський Університет Крафтового Пива ім. Св. Христофора.

⏰ 28 лютого, 12:00

***
Ексклюзивно для вас, товариство, відкриваю перші 10 квиточків за спеціальною ціною — 150 грн. Наступні 15 штук будуть вже по 170. А далі — хто зна ).

До речі, під час події розіграємо подарунки від партнера. І серед усіх квиточків, і серед тих, хто задонатить на збір для ЗСУ під час івенту.

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

#dom_in_action
DOM Node у вакуумі.

DOM API дозволяє нам створювати вузли, що не приєднані до документа. І поки ми їх туди не вставимо, вони просто висять у памʼяті та не впливають на рендеринг сторінки.

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

Для цього навіть існують спеціальні методи: removeChild(childNode) аби прибрати з дерева дочірній вузол, та node.remove() для самоусунення. Що важливо — вузол при цьому залишається в памʼяті.

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

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

І от якщо перший скрипт для оптимізації вилучає елемент з DOM для операцій, а другий у цей час намагається прочитати його геометрію, то результат буде дещо передбачуваним. Скрипт не впаде — він має посилання на вузол, тож усе буде чудово. Просто розміри й розташування будуть часто нульові — наприклад, у getBoundingClientRect(). Халепа?

Може й так, але запобігти їй можна за допомогою однієї-однісінької властивості будь-якого DOM-вузла — Node.isConnected. Цей ґеттер повідомляє нам, чи вузол зараз знаходиться в живому DOM, а чи теліпається в памʼяті.

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

Ось тут невеличка стіна консольлогів, яка демонструє, як працює isConnected:

console.group('1. Create element in memory:');
const element = document.createElement('section');
console.log(`element.parentNode: ${!!element.parentNode}`);
console.log(`element.isConnected: ${element.isConnected}`);
console.groupEnd();

console.group('2. Add child:');
element.innerHTML = '<div><p>Hello</p></div>';
const p = element.querySelector('p');
console.log(`p.parentNode: ${!!p.parentNode}`);
console.log(`p.isConnected: ${p.isConnected}`);
console.groupEnd();

console.group('3. Append element to live DOM:');
document.body.appendChild(element);
console.log(`p.isConnected: ${p.isConnected}`);
console.groupEnd();

console.group('4. Remove p:');
p.remove();
console.log(`element.isConnected: ${element.isConnected}`);
console.log(`p.isConnected: ${p.isConnected}`);
console.groupEnd();

Ставте 🔥, якщо дізналися про isConnected лише сьогодні, і ❤️, якщо знали про це давно.

@babichdev

P.S. І заберіть уже ті кілька квитків на запис нової Співбесіди на сцені.

float
Побутує думка, що CSS float — це щось дуже застаріле, а його використання вважається ледь не богохульством. Ну бо для лейауту ж маємо і flex, і grid. І частково з цим можна погодитись — для лейауту це дійсно моветон.

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

Справжнє ж призначення float просте як дрова — відтворювати типографський принцип "обтікання" зображення текстом. І все.

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

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

Чого ж тоді його взагалі використовували для цих задач? Це були темні часи. Таблиці впали в немилість, сходила зірка CSS 2.1, дизайнери вигадували нові, досі небачені структури сторінок, але над усим цим бовваніла одна величезна проблема — стандарти досі сприймали html-сторінки як документи, а не як інтерактивний інтерфейс для взаємодії з вебом.

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

Однак усе не було таким райдужним, як уявлялося. Навіть простенький лейаут на дві колонки міг несподівано розʼїхатись, якщо сумарна ширина колонок виходила бодай на нанопіксель більшою за 100%. Рахувати і прописувати ширини колонок потрібно було вручну, і розробники часто йшли безпечним шляхом, недотягуючи до 100%. Особливо підступним це було для трьох рівноширинних колонок. 33.33% — це найкраще, що ми могли запропонувати світу.

Є проблеми й окрім цього — наприклад, батьківський контейнер за замовчанням не підхоплює висоту float-елементів. І для вирішення цієї проблеми зʼявилися нові хаки: так званий clearfix, чи танці з overflow.

З іншого боку оця вся чудасія з float та спроби на їх основі будувати гнучкі й динамічні лейаути стали одним із чинників, що врешті призвели до появи flex, а згодом і до grid. Саме в епоху float зʼявилися CSS-фреймворки, які принесли у розробку поняття "12-колонкова сітка", що стала основою для макетів безлічі сайтів, і де-факто золотим стандартом дизайну.

Отут можна глянути як воно працює.

Якщо ви в очі не бачили float, і верстаєте виключно з flex та grid, ставте 🔥, ну а як ви такі самі динозаври, як і я, та провели не одну безсонну ніч, намагаючись зверстати той самий "священний Ґрааль", то ставте ❤️ і не забудьте випити таблетки від тиску ;)

Що почитати:
MDN — float
MDN Learn — floats

Що почитати душнілам:
W3C — CSS 2.1 Floats
W3C — CSS Display Module 3

@babichdev

P.S. Квитки на нову "Співбесіду на сцені" скоро здорожчають. Заберіть вже.

#нагадування
Співбесіда на сцені №2
Квитки закінчуються.

В суботу, 28 лютого, у Львові, в пабі Христофор. о 12:00 буде запис нового випуску.
Будуть забави, розіграші всяких приколів за донати, ну і очевидно, сама співбесіда на сцені.
Цього разу — з Frontend Tech Lead.

КВИТКИ ЗАКІНЧУЮТЬСЯ, КАЖУ

#партнерський_допис
Товариство, найбільший ярмарок вакансій в Defense Tech «Арсенал талантів» повертається!

https://arsenal.talantiv.in.ua

DOU та Lobby X знову збирають ключових гравців оборонної індустрії та фахівців, які прагнуть працювати у сфері оборонних технологій. 

🗓 Коли: 14 березня 
📍 Де: Київ, точну локацію ми надішлемо зареєстрованим учасникам в день події на пошту

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

👉🏻 Щоб відвідати «Арсенал талантів» заповнюйте форму та залишайте донат від 333 грн у фонд «Повернись живим». Одна транзакція = один квиток: https://arsenal.talantiv.in.ua/

Після цього триває обов'язкова безпекова перевірка (донат не гарантує її проходження). У випадку підтвердження квиток надійде на електронну пошту, яку ви вказали при реєстрації.