Oxlint розвивається, ставка на ESLint-формат

Раніше я вже писав про Oxlint - альтернативний лінтер для JS, написаний на Rust і заточений під високу продуктивність.
Але от проблема всіх цих нових інструментів - adoption. Важко впарити щось таке розробникам, якщо воно хоч трохи не покриває їхній поточний сетап.

Тому Oxlint йде вперед і пробує дати можливість писати плагіни для їх лінтера на JS, на додачу з можливістю залишити ESLint-формат.

Але найцікавіше в цьому - як їм це вдається зробити і не зашкодити продуктивності? Бо комунікація між JS і Rust мусять бути по якійсь шині, а дані мають серіалізуватись та десеріалізуватись, а це все додаткова робота і, відповідно, час.

Так от, вони пробують дуже цікавий підхід, працює він приблизно отак:

1. Oxlint вбудовує середовище Node.js усередину Rust, тому обидва працюють у спільному просторі пам’яті.
2. Використовується N-API (`napi-rs`), щоб напряму передавати дані та функції з Rust у JavaScript.
3. Rust розбирає код і зберігає AST у спільному блоці пам’яті (арені).
4. JavaScript-плагіни отримують легкі проксі-об’єкти, які читають поля вузлів через N-API з цієї арени.
5. Без JSON і копіювання - JS просто читає пам’ять Rust напряму -> мінімальні накладні витрати.

Круто і обнадійливо, бачу шанси впровадити це в роботі.

https://voidzero.dev/posts/announcing-oxlint-js-plugins

https://oxc.rs/blog/2025-10-09-oxlint-js-plugins.html#under-the-hood

Музична перерва 🫀

https://music.youtube.com/watch?v=e1N_fJlJaXY

Wouter - мікро роутер

Давно висить у моєму списку цікавих проєктів, але ніяк не доходили руки про нього тут написати.

Коротко - це справді дуже маленький роутер з обмеженою кількістю функціоналу. Але з досвіду - цього вистачає у 80% випадків.

API схожий на React Router, працює для React та Preact.

Ми полізли його юзати спочатку для створення ізольованих hash-роутів всередині деяких інтерфейсів.

Але крім цього він мені цікавий (хоча я в процесі роботи над PoC) тим, що дозволяє створювати паралельні роутери і відловлювати зміни в навігації. А от RR це блочить, просто забороняє мати, наприклад, MemoryRouter всередині BrowserRouter і т.д.

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

https://github.com/molefrog/wouter/tree/v3

Pull request і його ревювер

Наглядно показано, чому Effect це не ще один RxJS та що таке errors as values.

Взагалі, я глянув це відео заради прикладу LSP, але там і всі інші теми класні і зрозумілі.

https://youtu.be/V_XfZbxabI8

Not bad

Це красиво

.scroller {
animation: mask-up;
animation-timeline: scroll(self);
animation-range: 0 1rem;
mask-composite: exclude;
}
@​keyframes mask-up {
to { mask-size: 100% 120px, 100% 100%; }
}

https://x.com/jh3yy/status/1789359851094614449

Музична перерва 💅

https://music.youtube.com/watch?v=uAO_R-SOd3k

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

Не знаю, чи помічали ви багато твітів про те, як люди використовують агентів типу Claude Code та інших у більш інтегрований спосіб. Наприклад, через GitHub issues, де описують задачу, а агент робить зміни, створює PR, і це можна мерджити.

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

Ми користуємось Linear для трекінгу задач. Там маємо Claude інтеграцію - на неї можна заасайнити таск, як на юзера, і воно почне щось там кодити.

Сподобалось, що тімейт пішов ще далі - просто в локальному Claude Code агенті попросив створити таск у Linear і заасайнити його на Claude Code. Таск був досить простий, але воно непогано його виконало, і залишилось тільки коротке ревʼю коду та мердж.

На цей таск пішло би трохи більше часу, якби його робив девелопер.

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

https://react.dev/reference/react-compiler/directives/use-no-memo


)))))

Чому в ІТ стало стільки ж драми як в холостяку?

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

https://x.com/windscribecom/status/1982645218307694825

Але з іншого боку 💅

Цікаво, що що ж там за пост був))))

Свіженький допис про те що таке dithering.

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

https://typefully.com/DanHollick/why-do-we-need-dithering-Ut7oD4k

Різні форми кодування під різні цілі, це база

Знайшов цікавий інструмент, Toon, факично ще в зародках, бо перший коміт був 2 тижні тому.

Коротко: дозволяє кодувати структуровані дані для LLM в більш компактному форматі. Синтаксис взятий від yaml, але сама структура дещо відрізняється.

Ціль: менше токенів - менше полюцій в context window, а значить більше можна зробити за одну ефективну сесію.

https://github.com/johannschopplich/toon