Дивовижний світ веброзробки

За смішний мем з вас по дві гривні на збір.

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

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

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

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

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

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

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

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

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

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

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

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

А ще я додав кілька шарів для короткострокової та середньостроковї памʼяти у вигляді mcp-сервера для sql. І абізяни самі розрулюють свої тудушки і нотатки через базу даних замість створення гігантських markdown-файлів.

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

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

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

Поки писав, зрозумів, що про це можна цілу серію про це зробить.
Тож закриваєм збір і буде вам ;)

@babichdev

Товариство, вітаю.
По-перше, хочу поділитися хорошою новиною — РЕБ, на який ми з вами збирали кошти, уже місяць захищає бійців 115 ОМБр, дозволяючи їм безпечніше виконувати бойові завдання, зокрема з матеріально-технічного забезпечення підрозділів на передовій. Дякую усім, хто допоміг з цим збором!

А по-друге, знову маю до вас прохання. Підрозділ з 65-ї бригади просить допомогти з придбанням позашляхових шин для пікапа.
Сума збору — 20 000 гривень. І якби ми з вами змогли швиденько закрити його, я був би найщасливішою людиною у світі.

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

Як і завжди — надзвичайно вдячний за кожен ваш донат, за кожну вашу гривню.

P.S. Я не зник, просто потрібна невеличка перерва в усьому. Я маю купу ідей для нових дописів, але банально бракує сил. Сподіваюся, це скоро мине, і нові тексти знову поллються нескінченним потоком. Не втрачайте в мене віру )

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

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

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

До речі, хтось ще цими вихідними робитиме собі вікенд ментального здоровʼя на Карибах разом з Едвардом Кенвеєм? Там, якшо шо, ремейк AC IV виходить.

Тож гарного вам усім понеділка і продуктивного тижня вам і вашим Клодам ;)

#партнерський_допис
Товариство, тут SKELAR проводить завтра конференцію Code2Lead, головними темами якої є поточні події в tech-світі та яким буде код завтра. Вони зібрали інженерів з найсильнішою експертизою у BigTech і стартапах, аби вони поділилися з вами свом досвідом та знаннями.

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

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

Детальніше про спікерів та саму подію за посиланням:
https://bit.ly/3QTe3uQ

До речі, серед спікерів фахівці з Netflix, Google, Superhuman, Mono, Perply та інших великих продуктів. Тож не проґавте нагоди та долучіться завтра до конференції Code2Lead від SKELAR!

#про_інтернет
Одного погожого ранку Джон Сміт вирушив у мандрівку усього свого життя — він почав своє паломництво до Єрусалиму. Узявши до рук патерицю та перекинувши через плече дорожню сумку, він запитавсь в алдермена: "Як мені дістатися Єрусалиму?". На що отримав відповідь: "Спочатку дійди до Некствілю та запитайся там".

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

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

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

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

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

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

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

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

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

@babichdev

Що почитати:
• Common Internet Network Interconnection and Charging Practices
• How to properly interpret a traceroute or MTR
• Internet History of 1960s

Дивовижний світ веброзробки pinned «#нове_відео на каналі! Цього разу з Марком, Ярославом і Анною з YouScan говорив про джунів — точніше, про те, чи справді їх ніхто не хоче брати, чи усе ж не так все страшно, і є команди, які навпаки надають їм перевагу. Вийшла розмова про ріст усередині…»

#нове_відео на каналі!

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

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

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

Комент, вподобайка й поширення, як завжди. Дякую ;)

https://youtu.be/UtSfAFwNl5k

Товариство, запрошую вас на мітап у Львові!

25 червня спільнота для айтівців "ЛАМПА" разом з Ruby Labs проведе мітап про те, як змінюється роль інженера в епоху AI.
Два спікери:

🎙 Костянтин Гломозда — CTO & Co-Founder, Dym Solutions — про context engineering: як дати AI правильний контекст, щоб він перестав здогадуватись і почав реально допомагати вашій команді.

🎙 Я — про те, чи забирає AI роботу програмістів, чи це просто чергова трансформація професії, де розуміння задачі і відповідальність за результат досі залишаються за людиною.

Готуйте найгостріші питання — за найкращі розіграють браслети WHOOP і інші подарунки.

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

Локація в центрі, буде анонсовано додатково.

📅 25 червня, 18:00, Львів

🎟 Участь за донат від 300 грн у фонд KOLO

Кількість місць обмежена.

Реєстрація обовʼязкова: https://luma.com/rlabs-tmlj

Бравзер прощає дуже багато помилок вашому HTML-документу.

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

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

Ви можете написати в .html файлі просто:

Hello, world!

і бравзер перетворить це на:

#el(html)
  #el(head)
  #el(body)
    #text("Hello, world!")

Бо DOM-дерево мусить мати кореневий елемент, мусить мати head і body. І йому простіше їх самому вставити, ніж драматично падати під час парсингу.

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

Так от. У бравзера є багато правил, за якими він обробляє ваш html, і суттєва їх кількість забезпечує певні "неявні" перетворення.

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

<p>Hello
<p>World

Бравзер явно перетворить це на два параграфи:

#el(p)
  #text("Hello")
#el(p)
  #text("World")

Чому? Бо параграф не може містити блочні елементи всередині себе, тому, зустрічаючи відкриваючий тег для блочного елементу після відкриваючого p, він робить висновок, що попередній елемент закінчився, і його пора закрить. До речі, він застосує таке виправлення, коли вам заманеться покласти div всередину p:

<p>
<div></div>
</p>

Це перетвориться на:

#el(p)
#el(div)
#el(p)

Хід "думок" приблизно такий: "так, ось параграф, шо там далі? О, div, значить p треба закрить. Так, div закінчився, шо там далі? Закриваючий p? А шо він закриває? Непорядок! У мене попередньо все закрите, тому тут буде просто параграф. Пустий."

До речі, просто текст бравзер не перетворює автоматично на параграф, а створює текстовий вузол, який цілком собі є повноправним учасником DOM.

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

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

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

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

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

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

Ось такий веб дбайливий щодо свого спадку.

@babichdev

Коли захтілось ввечері чучуть покодить:
2020 — pet-project
2026 — ✨SaaS✨

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

Сучасний CSS дозволяє вирішувати усе складніші задачі, зокрема через певну реактивність, закладену у CSS змінних, себто CSS custom properties, та широкий спектр нативних CSS-функцій на кшталт clamp(), color-mix() та інших. І тепер ми можемо створювати доволі хитромудрі вирази на кшталт:

clamp(var(--min), 2vw + 1rem, var(--max));

Проте досі перевикористання таких виразів лишається болючою скалкою в дупі. Ми вимушені писати таку логіку наново в усіх місцях, де вона нам потрібна, що, погодьтеся, дещо незручно. Однак надія є, і вже досить давно в роботі знаходиться специфікація CSS Functions and Mixins Module Level 1, хоча й у статусі Working Draft.

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

Виглядають вони приблизно ось так:

@function --fluid-size(--min, --max) {
  result: clamp(var(--min), 2vw + 1rem, var(--max));
}
…
font-size: --fluid-size(1rem, 3rem);

Синтаксис простий:

- Оголошуємо через at-rule @function;
- Назва має префікс --, як і решта синтаксису для користувацьких властивостей в CSS;
- Функція може приймати параметри;
- Параметри можуть мати значення за замовчуванням: --fn(--x: 1px) {…};
- Параметри можна типізувати: --fn(--clr <color>) {…}
- Параметр може бути списком: --fn(--list <length>#), width: --fn({1px, 7px, 2px}) (саме так, з фігурними дужками);
- Ключове слово result є, по суті, відповідником нашого улюбленого return;

Можна навіть писати досить складну (наскільки це можливо) логіку. Наприклад, створювати проміжні змінні з власними розрахунками чи просто як константи:

@function --fluid-size(--min: 1rem, --max: 3rem) {
  --preferred: calc(2vw + 1rem);
  --safe-min: max(var(--min), 0.875rem);

  result: clamp(var(--safe-min), var(--preferred), var(--max));
}

Ба більше, користувацькі функції підтримують медіа-запити:

@function --narrow-wide(--narrow, --wide) {
  result: var(--wide);
  @media (width < 700px) {
    result: var(--narrow);
  }
}

та умовну функцію if(), яку варто розібрати окремо.

Що по підтримці? Ну, поки трошки сумно. Реалізацію поточного драфту для custom functions викотив Chromium, що означає, що ми можемо спробувати цей синтаксис в Chrome, Edge та решті хроміум-зоопарку.

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

Я, насправді, дуже чекаю коли CSS custom functions увійдуть до Baseline, бо це, насправді, дуже зручна можливість. До речі, рука в руку з ними йде й чернетка CSS mixins, на які я теж чекаю. Про міксіни поговоримо згодом, коли до них дійдуть руки хоча б у Chromium, але маю сподівання, що чекати лишилося недовго.

Чого я з таким нетерпінням чекаю на момент, коли ці специфікації увійдуть до Baseline? Бо це означатиме початок забуття SCSS та всіляких інших LESS, до яких я відчуваю безпідставну та пекучу неприязнь. А якщо цей допис набере бодай 100 реакцій, то я розповім чому. А як не набере, то не розповім.

@babichdev

***
Що почитати:
MDN: @function CSS at-rule
MDN: Using CSS custom functions

Що почитати душнілам:
W3C: CSS Functions and Mixins Module

P.S. Товариство, дуже сподіваюсь, що у вас все добре, наскільки це може бути.
Росія — кончена країна кончених людей.
Тримаймося.

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

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

Але тим не менш. Цього четверга запрошую вас на перші лампові дебати у Львові: https://t.me/it_lampa/61

Я там буду модератором. І що супер важливо: квитків усього 20, лишилося усього 7, більше не буде, і запису не буде, і стриму не буде. Ексклюзив, в общім.

Буду радий вас бачити!

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

А тим часом ви можете добити мені дві тисячі переглядів на "Одне питання — три відповіді".

Можете ж? Можете?

Всім гарного завершення тижня і спокійних вихідних!

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

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

Дякую.

Новий випуск "Одне питання — трив відповідь" уже на каналі!

https://youtu.be/IESsvnPfPtU

ОБОВ'ЯЗКОВО: вподобайка, коментар і поширення. А то забаню всіх.

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

Я розпочав карʼєру у веброзробці 2011 року. Здається, це було не так давно, але минуло вже 15 років.

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

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

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

Наприклад, моєю першою роботою, повʼязаною з компʼютерами, був веб дизайн. Очевидно, що тоді (а це плюс-мінус 2006-2011 роки) все малювалося у фотошопі, який я запускав щодня, аби намалювати черговий сайт-візитку. І хіба міг 20-річний я навіть здогадуватися, що мій повсякденний інструмент зʼявився тоді, коли я ходив до радянського дитсадочку?

Так-так, саме радянського, бо перша версія Adobe Photoshop зʼявилася у лютому 1990 року. Ба більше, другий їхній продукт, яким я користувався паралельно з фотошопом, взагалі старший за мене на кілька місяців. До вашої уваги — Adobe Illustrator, 19 березня 1987 року.

Рухаємося далі. Я не уявляю собі людини, яка за віком може бути моєю колегою по роботі, що в житті не чула про Microsoft Word та Excel. Ці два продукти є де-факто стандартом в багатьох галузях, успішно витримавши конкуренцію як від хмарних продуктів, так і від опенсорсних аналогів. Їх досі викладають в школах. А зʼявилися вони…

Excel виходить 1985 року, тоді ж, коли в совєтському союзі розпочинається "пєрєстройка". Яка в свою чергу стала одним з каталізаторів розвалу цієї недоімперії. От би й в 2026 році Microsoft випустили щось, що через сову на глобусі призведе до розпаду Росії…

А Microsoft Word побачив світ 1983 року, практично одночасно з підключенням четвертого енергоблоку ЧАЕС до мережі. Гм, у мене починає зʼявлятися думка, що усі ці події якось повʼязані між собою… Але сова чогось не погоджується.

Пірнаємо глибше? Тоді зануримося у 70-і роки. Несподівано, так?

1979 року, коли мій тато працює на будові і отримує зарплату у віконечку, компанія RSI випускає Oracle V2, що стала першою комерційною SQL-базою даних. Хоча й у нас тоді відбувалися примітні події — до прикладу, вийшла кінострічка "Вавілон ХХ" Івана Миколайчука, яка нині посідає 10 місце у топ-100 українських фільмів у рейтингу "Довженко-Центру".

І тут ви такі "ШООООО?! Який такий SQL?!". Ну так. SQL. Першу версію якого, під назвою SEQUEL (а ви думали це прикол такий?), було описано IBM Research 1974 року (повноцінно стандартом SQL став, щоправда, аж у 1986). Що ще цікавого відбулося цього року? Славнозвісний Watergate і відставка Ніксона. Та, були часи, політики йшли у відставку через скандали, уявіть собі таке…

Копнути ще разочок? Добре. Але разочок. І цього разу нам доведеться відвідати… Місяць.

І тут ви такі "ШООООО?! Який такий Місяць?! Забув таблетки випить?". Таблетки то я забув випить, але поки, дякувати богу, ще не ті. А на Місяць ми з вами летимо разом з екіпажем Apollo 11, члени якого стали першими в історії представниками людства, що ступили на інше небесне тіло. І поки 20 липня 1969 усі, затамувавши подих, слідкували за висадкою астронавтів, у нетрях Bell Labs Кен Томпсон писав перші (а може й не перші) рядки коду операційної системи, яка згодом стала відомою як UNIX.

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

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

#нове_відео
Товариство, нове відео вже на каналі!

Розмовляв з Ігорем Закутинським, CTO в FORMA, про масштабування глобальних продуктів з України, AI у щоденній роботі CTO та про те, чому наступне десятиліття української tech-індустрії може стати визначальним для світу.

З вас вподобайки, коментарі та поширення.

Приємного перегляду!
https://youtu.be/lIugEWpCzX4

Фреймворк-абізянство — це такий особливий спосіб мислення, коли навіть hover робиться через setState. І так, я цей приклад не вигадав, я бачив такий код в проді.

А от як назвати протилежне мислення, я ще не знаю. Суть його полягає в тому, що замість робити ВСЕ на умовному реакті, спочатку треба трошки подумати — "а може HTML/CSS/JS вже самі таке вміють?".

Дивіться, я тут останнім часом ношусь і з dialog, popover, @layout, @scope, всякими приколами з Browser API, що аж примудрився зібрати цілком собі робочий застосунок чисто на нативці. І поки я робив ту альфа-версію, усе частіше ловив себе на думці, що величезну кількість речей ми досі робимо максимально складно. Просто за звичкою.

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

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

Річ у тім, що нам геть не обовʼязково використовувати Shadow DOM і мудохатися з ізоляцією стилів. Custom Elements чудово себе почувають в так званому Light DOM (неофіційна назва), коли вони виступають просто такою собі обгорткою для відкритого фрагменту дерева.

Так от. Custom Elements виявились дуже зручними для невеличких "тупих" компонентів, задачею яких є якийсь простенький функціонал, наприклад, перемикання активного елемента всередині в залежності від значення атрибуту. Чи той же collapse/expand, але з зовнішнім керуванням. У мене взагалі є компонентик, який просто показує поточний слайд у вигляді "7/8", склеюючи два значення докупи.

В чому ж, на мою думку, вигода? По-перше, Custom Elements підтримуються сьогодні будь-яким відром. По-друге — сумісність. Ваш фреймворк не зможе відрендерити Custom Element лише в одному випадку — він не вміє рендерити усі інші теги. По-третє — зменшення залежності на внутрішні приколи вашого стеку, кастомні елементи залежать тільки на вебстандарти і бравзери. По-четверте — якщо засукати рукави і перенести всі банальні й прості рішення з фреймворку на Custom Elements, то можна нічогенько так скоротити фінальний розмір бандлу.

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

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

2. Чи треба мені для цього мій фреймворк?
Нативна платформа, хоч і вміє вже багато, усе ж дає нам радше кубики з леґо аніж готові рішення. І часто рішення треба зібрати самим. Але тут теж є певний простір для маневру — часто певні рішення цілком собі складаються докупи без залучення додаткової складності. Ті самі Custom Elements — це той шар, який дозволяє зібрати певний функціонал, надаючи вам і реактивність, і інструменти для DOM, і події, і команди, і ще купу всього просто з коробки.

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

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

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

@babichdev