В Твіттері хвиля геніальних ідей — схоже, після відео ютубера 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

Але побачим....

Раніше цього року прочитав книгу Radical Candor від Kim Scott.

Ця книга пояснює, як створити культуру, у якій ви щиро дбаєте про людей (Care Personally) й водночас прямо кидаєте їм виклик (Challenge Directly). Книга орієнтована на менеджерів, та буде корисною будь-кому, хто співпрацює з іншими.

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

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

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

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

Ключові думки:

- Чотири квадранти фідбеку
1. Radical Candor — турбота + пряма відвертість.
2. Ruinous Empathy — багато емпатії, жодної прямоти.
3. Obnoxious Aggression — прямота без турботи.
4. Manipulative Insincerity — ні турботи, ні чесності.

- Фідбек має бути швидким, конкретним і регулярним. Хваліть одразу, коригуйте теж одразу, не чекаючи «perf-review».

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

- Мітинги 1:1 та «career conversations». Регулярно говоріть про коротко- і довгострокові цілі, перешкоди та ресурси для зростання.

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

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

Є ще одна цікава і важлива, на мою думку, річ, якою часто нехтують. Проводити team events ну чи тім білдінги.

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

Але найкраще це проходило коли ми грали якісь ігри разом.
Ось декілька найпопулярніших для нас:
- https://skribbl.io/
- Among us
- https://www.geoguessr.com/

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

Будуте команди навіть якщо ви не менеджер, це значно спрощує роботу!

https://www.youtube.com/watch?v=azk-GuGiy3E

Прогрів перед Rolldown
Постараюсь про це розписати пізніше

Ще десь у травні відклав собі нотатку, щоб зробити пост про Activity API в React, але постійно відкладав. Тема загалом проста, але цікава, тому час.

У React є експериментальна фіча — компонент (якщо це ще так можна назвати, ну або API) під назвою Activity.

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

Я додам відео, де це класно показано, та приклад звідти мені дуже сподобався. Там показано велику кількість анімованих інтерфейсів, які при одночасному рендері садять FPS. Якщо приховати лише в CSS, то все одно блокуватимуть основний потік, бо HTML треба рендерити. Якщо не рендерити взагалі — не вийде прорахувати state наперед. Тут якраз Activity посередині: рендерить тільки віртуально, не блокує потік і тримає активним state.

Цікава фіча, нечасте застосування, але точно буде корисною.

https://react.dev/reference/react/Activity

Раніше писав про LiveStore. Його автор, Johannes Schickling, схоже, став великим популяризатором бібліотеки Effect. А потім це підхопив лисий чєл (не той, що ви подумали), відомий своїми відосами про TypeScript — Matt Pocock.

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

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

https://x.com/mattpocockuk/status/1936145776465391658

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

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

https://effect.website/