Вчора була презентація по Skia, в стилі Apple (це зараз дуже модно). Бачу, що я про це раніше не писав, тому якщо коротко: Skia — це рушій для 2D-графіки, особливо популярний у React Native (завдяки зусиллям Shopify).

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

З’явилась підтримка WebGPU в React Native, що відкриває можливості для однорідного API між вебом та RN. Можна буквально скопіювати код із вебу й запускати на телефоні. Це також покращує перформанс і дозволяє використовувати окремий потік для графіки, не блокуючи інтерфейс.

Суттєво вища підтримка 3D.

Показали колаборації з іншими командами, як-от Software Mansion, їхній TypeGPU та інші інструменти.

Заделіверили 0 нових фіч, але сильно попрацювали над продуктивністю.

І трохи розповіли про майбутнє Skia Graphite — рушія поверх WebGPU.

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

Але думаю, я таки повернусь до Skia.

До речі, знали, що весь інтерфейс Flutter-додатків — це саме Skia? Вони повністю обходять нативні інтерфейси. Пішли своїм шляхом, так би мовити.

https://www.youtube.com/watch?v=t9t-VXwIc4I

Нещодавно мав багато роботи по оптимізації й автоматизації релізу пакетів. У таких PR легко випадково зламати package-lock.json, коли з’являється кілька десятків тисяч змін — весь CI червоний, важко зрозуміти, що саме спричинило проблему. Найпростіше рішення в такому випадку — взяти lock-файл з main і перезапустити npm install, щоб усе синхронізувалось.

Але не раз бачив, як такі зміни залишались непоміченими, і хтось мерджив pull request з величезним diff'ом у lock-файлі. Потім у когось щось не працює, і починається відлов проблем. Один із типових сценаріїв — коли у вас локально різні версії NPM, і через це змінюється формат package-lock.json.

Тому я вирішив зробити простий «захист від дурня». За один вечір накинув і релізнув GitHub Action, який перевіряє, чи не занадто великі зміни, і якщо так — залишає коментар у PR.

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

https://github.com/bohdanbirdie/fat-lock-action

Zed editor нарешті релізнув Agent Panel. До цього я, коли треба було поюзати АІ, користувався Windsurf, доводилось переключатись.
Але схоже, що це вже позаду. Pro підписка за 20$ виглядає непогано, дуже імовірно що перейду з Windsurf.

https://zed.dev/blog/fastest-ai-code-editor

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

https://github.com/krzyzanowskim/ObjectivePGP/pull/236

До речі, коли я захотів зробити таймер на Mac, то задумався: яку ж анімацію він має мати? Можна було вибрати щось типу аналогового годинника, pie chart і т.д. Але я згадав, що є дуже гарний стиль анімації для змінного тексту. Не знаю, хто це першим придумав, але я давно зберіг собі один пакет для вебу. Дивно, що він досі не потрапив у Shadcn.

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

Поділюсь і з вами: https://number-flow.barvian.me/

Безпощадний ринок ІТ — ніколи не знаєш, звідки буде наступний удар.

Microsoft звільнили (layoff) одного з початкових та довготривалих розробників TypeScript. Одразу зазначу, що він не був головним автором, але давно працював над цим проєктом. А в Microsoft взагалі пропрацював 18 років.

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

Не знаю коли я вже використаю Drizzle десь в проекті, але їх вайб це бомба!

https://mssql.drizzle.team/

https://x.com/DrizzleORM/status/1922728686089904554

В ідеальному світі додатків лоадінг-спіннери взагалі не мали б існувати.

Жоден юзер не хоче дивитись на спіннери, скелетони та інші хаки й шпаги від девелопера. Юзер хоче бачити одразу цінну для себе інформацію. До речі, local-first підхід намагається максимально наблизити нас до того, щоб кількість випадків, коли потрібен спіннер, була менша за умовний 1%.

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

І ось, щоб менше тригерити своїх юзерів — іноді можна їх трошки обманути (заради їхнього ж блага).

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

А для прикладу — от вам зручний пакет: https://www.npmjs.com/package/spin-delay

Local-first підхід набирає все більше популярності — і мене це дуже пре.

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

Я паралельно ще слідкую за Zero (про який писав раніше) — вони активно розвиваються й додають багато цікавого. А з появою нових open-source конкурентів все стане ще цікавіше.

https://x.com/DavidKPiano/status/1923740185520378365

Натрапив на ще один симпатичний генератор mesh-градієнтів — і знову крута робота!

Цього разу з цікавою фічею: можна закинути фото, і він згенерує mesh-градієнт на основі нього. Може стати крутою альтернативою для blurred placeholders під час завантаження зображень — виглядає стильно й сучасно.

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

https://photogradient.com/

🔧 Storybook 9 перейшов із Beta у Release Candidate!
Я якраз у процесі міграції на декількох проєктах.

Що цікавого й корисного:

✅ Можна запускати декілька тестів одночасно прямо з UI

✅ Підтримка локального запуску visual tests
(але все одно деплоїться на Chromatic, і це влітає в квоту)

✅ Менший білд — особливо приємно на великих проєктах

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

🧪 Ще одна цікава новинка (ще з середини Storybook v8.*) — Vitest як тест-раннер.
До цього все було жорстко зав’язано на Jest, але будьмо чесні — він вже давно програє Vitest за швидкістю та UX. Я вже перевів кілька проектів — працює щонайменше не гірше, а в деяких випадках навіть приємніше. Думаю, рух у цьому напрямку продовжиться.

https://storybook.js.org/blog/storybook-9-beta/

🔄 Netflix, пошта і автоматизація, яка реально полегшує життя

Дивитесь Netflix у спільному акаунті з друзями? У нас 5 профілів на одному акаунті. Всі використовують одні й ті самі креденшали. І це ще півбіди.

📧 Але час від часу Netflix присилає лист:

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

🙅 Ділитися основною поштою незручно. Заводити окрему під це ок, але все ще не достатньо.

🧠 Тому я зробив просту автоматизацію:

1. Листи від Netflix приходять на окрему пошту.
2. Якщо в темі чи тілі листа є певні ключові слова — скрипт парсить його.
3. Посилання для підтвердження локації надсилається в Telegram через бота.
4. Усі учасники мають доступ до цього бота.

📆 Плюс:
Раз на місяць бот тегне того, хто платить за акаунт. І далі йде ротація по учасниках.

Використав https://www.relay.app/

Хто хоче повну автоматизацію - пишіть в коментарях ⬇️

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

А тепер щей багато хто використовує shadcn registry, а зверху щей registry MCP.

І вчора випадково натрапив ще один UI kit який дистрибютиться через shadcn - Animate UI.

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

Дуже хотілось би десь таке використати.

https://animate-ui.com/

Вкрав у твіттері

В Chrome завезли чергову CSS-функцію — if.

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

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

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

https://www.youtube.com/watch?v=Apn8ucs7AL0

https://developer.chrome.com/blog/reading-flow

Вчора експериментував із міграцією npm на pnpm. В основному заради того, щоб трохи пришвидшити CI. Не сказав би, що відчув суттєві зміни, але в проєкті багато пакетів, тому поки забив на це.

Але в процесі використав цікаву штуку — $npm_execpath.

Якщо коротко, то це змінна, яка завжди посилається на executable менеджер, яким ви запустили скрипт — тобто npm, pnpm, bun і т. д.

Часто можна побачити package.json, у якому є скрипти, що викликають інші скрипти:

"build": "npm run build:ts && npm run build:css"

Ну і це можна замінити на версію з $npm_execpath:

"build": "$npm_execpath run build:ts && $npm_execpath run build:css"

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

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

"preinstall": "npx only-allow npm"

https://www.npmjs.com/package/only-allow

Помітив на просторах Твіттера цікавий інструмент, називається RedwoodSDK. Ну як помітив — LiveStore, про який я недавно писав, репостнув твіт про фінансову підтримку від перших.

Переглянув їхню документацію — виглядає як цікава ідея. Ось коротка інформація:

RedwoodSDK — це React-інструмент, який покладається на різні фічі Cloudflare, такі як Durable Object, Worker і так далі. На перший погляд звучить як типовий vendor lock. Але бенефіт від цього — легка інтеграція з Cloudflare (а на фоні останніх скандалів із Vercel — Cloudflare зміг переманити чимало проєктів до себе).

Автор на демо показує набір цікавих прикладів, але мені особливо сподобалося про Durable Object з лайв-синхронізацією.

Не знаю, чи я був би готовий до такої зав'язки на вендора, але виглядає цікаво для невеликих проєктів.

Демо: https://www.youtube.com/watch?v=omKvO9KoPLs

Сайт: https://docs.rwsdk.com/

Декілька днів тому в твіттері була чергова драма. Один користувач опублікував коміт з react-router або remix, вже не можу знайти той твіт. Там був "злив" того, що команда планує робити з Remix надалі, але в незавершеному форматі, такий собі чорновий варіант. Цей твіт дуже розлетівся, бо деякі розробники побачили в майбутніх змінах зраду, і основні контрибютори цих бібліотек, а саме Майкл Джексон та Раян Флоренс, почали на це відповідати.

Але це вже не так важливо, бо швидко після цього вийшов пост про те, що Remix після відносно тривалої паузи повертається, але в формі окремого рішення, а не як відгалуження react-router, як це було раніше.

https://remix.run/blog/wake-up-remix

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

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

https://x.com/youyuxi/status/1927992416075927659

В Твіттері хвиля геніальних ідей — схоже, після відео ютубера Theo, який показав, як він у Next-проєкті використовує React Router тільки в декількох місцях.

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

Люди беруть Next.js-проєкт, створюють єдиний ентрі-поінт для Next-роутера, а далі все переходить у владу React Router. А чому? Бо Next-роутер має затримку в підвантаженні сторінок, SSR і т.д. Людей це, звісно ж, напрягає. Але це просто так працює той роутер — це певною мірою плата за інший функціонал, який дає Next.

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

Хтось може сказати, що це все одно зручно, бо Next дає ще вбудований API. Але я вважаю, що це занадто. Для таких задач є суттєво простіші підходи. Та й Next сам по собі має чимало інших проблем, а в більшості випадків буде достатньо Vite.

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

Спершу думав не писати про це, але бачу що є однодумці: https://x.com/letstri/status/1929463573127831666

Перечитував всю документацію LiveStore — свіжий sync engine, про який я писав недавно. Його особливість — це event-driven state.

У документації багато посилань на цікаві статті, які більше пояснюють філософію та прагнення цього рішення.

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

І лиш трошки розповідається про вирішення проблеми — causal ordering, але на щастя є матеріал від інших авторів.

Спробую коротко підсумувати. У розподілених системах поняття синхронізованого часу відсутнє в силу природи самої системи. Як не старайся, але глобального синхронізованого часу бути не може. Тому і сортування івенти по часу (timestamp, наприклад) не гарантуватиме порядку. Для цього використовують causal ordering. Causal — від слова cause, причина.

Максимально спрощуючи, causal ordering дозволяє відсортувати події за їхньою причиною. Юзер залогінився → юзер отримав токен. Ці події можна відсортувати. Але не всі події є залежними, і багато можуть бути зовсім не пов’язаними, а отже, не можна відсортувати абсолютно всі події.

Найпопулярніший механізм реалізації цього — vector clocks. Його ви бачите на скріншоті.

А більше можна прочитати тут: https://www.scattered-thoughts.net/writing/causal-ordering/

Після публікації про Remix я натрапив на дещо схожий по філософії, але не зовсім по функціоналу, фреймворк. Знаєте від кого? Від Deno! Називається Fresh.

Взагалі, Deno хоч і стараються, але такого хайпу, як у Bun, ніяк не можуть набрати. Але все одно працюють. Я в квітні писав про їх JSR, тепер — про Fresh.

Давайте дивитися, що ж це таке.

Fresh позиціонує себе як фул-стек фреймворк, заточений під продуктивність і простоту. Під капотом використовує Preact. Zero-config, мінімальний розмір, власний роутер, форми і т.д.

З незвичного — island architecture. Дещо схоже на micro-frontend підхід, але простіше, бо все відбувається під капотом. Сервер віддає всю HTML-сторінку, а деякі з зон позначає як такі, що будуть інтерактивними. Всі ці кроки спрямовані на швидкість та продуктивність. А стейт між острівцями можна шарити через Preact Signals.

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

https://fresh.deno.dev/