Треба віддати належне 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/

Я залип тут

Spline дуже крутий!

https://viewer.spline.design/

Трохи повернусь до теми React Native.

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

Є непогана стаття від одного з розробників Bluesky. Їх мобільний додаток написаний на React Native — напевне, один із найбільших публічних та відомих проєктів, що доступні в open-source.

Автор розповідає, як вони на практиці покращили сприйняття додатку, щоб він відчувався справді як нативний, а не як веб-сторінка, запакована в додаток.

Основні пункти:

- Тонші бордери ніж 1px, бо це краще виглядає і мобільні дисплеї мають високий DPI
- Нативні модалки (sheet) замість кастомних рішень
- Нативна навігація
- Анімації
- Анімовані кнопки при натисканні

І я з цим усім згоден, бо дерев’яний додаток можна написати і на Swift, і на Java/Kotlin. Але там все-таки багато речей зроблено "з коробки", і девелопер може навіть не задумуватись.

Взагалі сам факт того, що існують великі проєкти на React Native, доводить, що ідея не є мертвонародженою. Але розробники мають платити за cross-platform уважністю до дрібниць.

https://mozzius.dev/post/3l777nhz4h32w

Свіжа стаття від Дена Абрамова про так званий Progressive JSON.

Хоч назва статті додає цікавості, але в сумі він пояснює те, як працюють React Server Components у дещо простішій для сприйняття формі — просто у вигляді JSON.

Ось короткий переказ:

Не всі дані для одного запиту можуть одразу бути присутніми, але блокувати відображення сторінки — не дуже ок. Одним із рішень є RSC, де ми можемо “стрімити” компоненти в міру появи потрібних даних. Уявімо, що ми хочемо стрімити JSON. Просто стрімити байти даних не вийде, бо щоб його розпарсити — стрім має бути завершеним, і JSON має бути валідним. Тому можна стрімити структуру з посиланнями (ну типу ref), а дані вже будуть підвантажуватись по мірі їх наявності. Зрештою, це матиме вигляд як JSON зі значеннями типу Promise, які рано чи пізно зарезолвляться.

Більш наглядні приклади є в самій статті.
https://overreacted.io/progressive-json/

А для лінивих також доступний відеоформат.
https://www.youtube.com/watch?v=MaMQLNBZz64

Там Anthropic декілька тижнів тому опублікували The Way of Code в колаборації з Ріком Рубіном. Цей персонаж не є сильно відомим в Україні, але дуже відомий в Америці — був продюсером у багатьох музичних зірок. Я вперше дізнався про нього з випадкової вирізки інтерв’ю, де він каже, що нічого не шарить у музиці.

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

Але на кожній сторінці — жива абстрактна ілюстрація у 2D графіці, багато з них зроблені на Three.js. Напевне, кожна була навайбкоджена.

Ділюсь цим як мінімум завдяки ілюстраціям з кодом — але, можливо, хтось знайде щось цікаве й у тексті.

https://www.thewayofcode.com/

Таке життя

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

Від сьогодні буду на пет-проектах пробувати щось нове — conar.app.

Знаю, що автор проєкту підписаний на мій блог, раніше постив про його пакет permix.

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

А ще — можна глянути на код проєкту, він відкритий на GitHub.

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

Загалом, круто і мотивує теж щось робити!

https://x.com/letstri/status/1932045192195911717

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

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

Ну і акції Apple трохи просіли під час презентації, але то, може, щороку так (я не перевіряв).

Глянемо, може, звикнеться і буде зручно.

Скріншот взяв тут.

Буквально думка авторитетної людини.
Якщо не знаєте хто це, то може чули про React Aria.

https://x.com/devongovett

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

Вони обіцяють щось таке, поки дуже абстрактне, але амбітне.
Форк Preact, власний валідатор не гірше Zod, no build і тд. Це щось кардинально інше від всього що популярне зараз.

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

Вчора відбувся реліз Oxlint v1.

Трошки контексту. Напевне, всі знають про Vite (здивуюсь, якщо ні). Минулого жовтня відбувся ViteConf у форматі ютуб-стріму. Там Іван Ю (Evan You 😅), розробник Vite, розповів, що стартує компанію VoidZero зі стартовими інвестиціями 4.6 мільйона доларів. Ціль компанії — створити набір ефективних інструментів для екосистеми JavaScript. Не знаю, як вони планують заробляти на цьому — може, підуть шляхом Vercel — але це тема на інший день.

Отож, до VoidZero входить 4 основні проєкти:

- Vite
- Vitest
- Rolldown
- Oxc

Сьогодні акцент на Oxc (Oxidation Compiler), одним з елементів якого і є Oxilint, ну або просто лінтер.

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

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

Особливо важливо — в них є близько 500 правил, які вони взяли з популярних ESLint-плагінів. А головне — є інструмент міграції з ESLint.

Я вже створюю собі таск, щоб потестувати на робочому проєкті.

https://voidzero.dev/posts/announcing-oxlint-1-stable

Недавно відбулась Local-First Conf в оффлайн режимі і ось вони публікують записи презентацій.
Я вже глянув один з категорії найбільш цікавих для мене - від Ink&Switch.
Вони стоять за Automerge, я про нього писав раніше.

Цього разу презентували превю нового інструменти для encrypted синхнронізації даних.
Презентація лиш на 10 хв, тому якщо цікаво то вартує глянути!

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

Я не багато користуюсь LLM для програмування (в роботі), вони більше стали заміною гугла для мене — і то лише у випадках, коли важко сформулювати запит у гуглі.

Але трохи більше користуюсь ними для пет-проєктів, особливо коли пробую щось нове і треба накинути якусь мінімальну версію.

Часта проблема в таких випадках — LLM вигадує неіснуючі API, рідко заглядає в документацію і фантазує, як п’яна тусовка про політику. Часом виглядає як rage bait, щоб я використав більше промптів.

Ну коротше, вчора випадково натрапив на цікавий MCP — називається Context7. Додав його в Zed editor, почав тестувати. Нарешті LLM почав трохи поважати документацію. Хоч не ідеально, але явно стало краще. Думаю, вартує, щоб я тут поділився.

А ще — в Zed editor доступна Claude Sonnet 4, і тиждень безкоштовного trial на Pro-підписку. Це хороша можливість спробувати як сам редактор, так і нову модель.

https://github.com/upstash/context7