А вот остальные тейки разбирать как-то даже влом.

Написав на несколько строк кода больше, мы получили логику, которая:

- может быть переиспользована с разными входными данными, то есть на странице может быть одновременно несколько независимых компонентов поста, каждый в своём состоянии;

Да, но SSR и гидратация состояния вышла из чата.
Только такой простой случай и будет работать хорошо.

А если хук зависит от кучи других данных, придется
либо а) поднимать состояние выше, что уже выглядит не так красиво и вызывает props-drilling,
либо б) использовать контекст и перерендеривать кучу VDOM-деревьев на каждый чих, что вызывает просадки перфа,
либо в) выносить состояние из компонентов и получать все те же проблемы, о которых статья.

- может быть с лёгкостью модифицирована благодаря тому, что весь логически связанный код находится в одном месте и у нас нет ограничений на использование значений переменных. Например, мы добавили отмену устаревших запросов с помощью AbortController (напишите в комментариях, как то же самое сделать в коде на Effector);

Да, всё так, но только до тех пор, пока кейс простой. При подписке на любой источник данных, сложность кода взлетает сразу же. И жить без СТМ или query/swr уже почти нереально.

- работает чуть более эффективно, потому что вся инициализация и загрузка данных происходят только тогда, когда они действительно нужны;

Работает эффективно? В каких случаях? Ведь при запуске фичи, придется сделать кучу работы по инициализации всей фичи.

- проще читается и понимается большинством JS-разработчиков, которые видят её впервые, благодаря тому, что код более линейный и не требует знания Effector.

Отчасти да, но все опять упирается в простейший пример.
А ведь в приложениях не простой код и этой сложностью хочется как-то управлять.
Ребята из бигтеха наверняка должны это знать.

Мой наброс сюда:
Как эту логику, намертво завязанную на версию реакта и тулинга вокруг тестировать?

Или тесты будут падать при обновлении рендерилки в html? Хоть тест и никак не связан с react, но он будет падать из-за совершенно посторонних проблем.

И это я привожу только самый яркий пример.

ИТОГИ

Здесь мои супер субъективные набросы. Обратите внимание, что я высказываю свою точку зрения и могу ошибаться на счет других людей.

1. Тейки про производительность стоит десять раз проверять.
Автор сделал выводы о производительности и внутреннем устройстве библиотеки на основе поверхностного исследования и пишет статью об этом как эксперт.
Это грустно, но что поделать.

2. Документация сейчас действительно не объясняет ценность инструмента и как им глобально пользоваться.
Это минус, которым сейчас занимается effector core team.
Держим в уме.

3. Тейки про простоту кода основаны на сравнении простых примеров, хотя в самом начале автор пишет, что документация рассматривает тривиальные, далёкие от реальности примеры вроде счётчика.
Почему не показать как надо? Зачем повторять в статье такие же тривиальные примеры?

С разделом выводы я согласен.
Читать статью стоит хладнокровно, критично, объективно и взвешенно.

Это негативный опыт, причиной которого стал в основном недостаток обучающих гайдов и желания разбираться.
Он ценен, во первых критическим взглядом на статьи, даже от гигантов вроде VK.
А во вторых, подсвечивая слабые места и как их можно исправить.

Как помочь?
1) Прийти на effector.dev, почитать всё что есть, предложить изменения через Edit this page.
2) Открыть issues, вычитать то, что вы понимаете, вписать своё мнение, предложить решение, открыть PullRequest.
3) Создать новый issue, которого еще не было, но который важно обсудить.

Спасибо всем, кто вкладывается в создание и улучшения effector.
🧡

Я уже много лет пользуюсь nvm для манипуляций версиями Node.js.

Хоть меня и все устраивает в nvm, все равно поглядываю на альтернативы.
fnm вроде неплохой, но я не нашел официального экшена для Github Workflows.

А у Volta экспериментальная поддержка pnpm, которым я пользуюсь почти всегда.
https://docs.volta.sh/advanced/pnpm

Кто-то пользуется Volta+pnpm? Как опыт?

Ждем?

Рассматривал логи с лендинга frontend.vision и заметил странный Yandex Browser

А также скрипт, которого в коде лендинга нет

Кто-то уже пользовался GitHub Models?

Что на счет новых моделей? Тестируем?

К слову, про новую «думающую» модель

Вот непонятно, есть ли смысл отказываться от Rectangle app.

Я обычно пользуюсь tig, но тут по советам из комментов решил попробовать lazygit.

Открываю софтину, а там you rock

🗿

У кого есть инвайт в Deadlock?

Github теперь отображает префиксы, вроде test: или feature: в названии коммита в виде лейблов!

Тем временем, после появления дженериков в Go, потихонечку добавляют и все остальные фичи из Rust.

https://t.me/crossjoin/361

Давайте повангуем в комментариях: с какой версии Go приблизится к Rust, по сложности синтаксиса и количеству фич?

Я думаю, где-то к 1.70, Go уже не будет "простым" языком, а чисто типа Rust, только с GC и компилится побыстрее.

Поэтому прямо сегодня выбираю для себя язык сегодняшнего и будущего дня — Zig(нет).

Тем временем, Winamp открыл исходники своей легендарной версии под Windows.

Написано на плюсах, можно скомпилить себе или портировать на Rust

https://github.com/WinampDesktop/winamp

Cloudflare присоединяется к OpenNext
Astro умеет в SSR с серверными экшенами

В чем смысл Next.js?
Все равно, сложные приложения на нем делать больно

Открыл картинки гугл…

Google полностью ушел из качественного UX?

В ближайшую пятницу 4 октября будет ViteConf.
Я буду слушать и всем советую взять онлайн билет.

Уверен, что покажут что-то интересное, особенно, если вы не следите за beta версиями и обсуждениями в репозиториях Vite.

Пока я смотрю записи докладов ViteConf, записался на Next.js Conf.

https://nextjs.org/conf

Создавать красивые штуки Vercel конечно умеет