Эффектор.

Кто я такой? Тут про общий опыт. Я был примерно пятым человеком в мире который начал писать на эффекторе прод, когда он еще только появился. Было прикольно, сильно лучше редакса. Я много его тестировал и экспериментировал с ним, изучал исходники и даже записывал туториалы на ютубе. Это еще в 2019 было.

С самого начала эффектор заявлялся как быстрое решение, там использовался достаточно интересный алгоритм для топсорта и решения проблемы глитчей. Были бенчи, эффектор был на хорошем уровне. Заголовок про перф так и остался, но потом что-то пошло не так и об этом мы еще поговорим.

Сначала скажу по тех части.

- Используемая концепция вечногорячих обсерваблов наиболее предсказуемая и “просто работает” - это хорошо. Плохо то что это может негативно сказываться на перфе (вычисляется вообще все и всегда, для всех загруженных страниц, которые уже не показываются) и чинить это фабриками считается плохой практикой и чревато мемори ликами, нужно в этом случае очень хорошо понимать как и что делать.
- Атомарности нет вообще и лично для меня это катастрофический недостаток. Я не верю в то что непредвиденных ошибок в вычислениях в проде не может быть, как заявляют пользователи эффектора. Требование к идеальному тестированию для использования библиотеки мне кажется очень странным.
- Декларативное апи - птичий язык, позволяющий красиво описать простые кейсы и страдать (городить чрезмерные конструкции, с точки зрения процедурного программирования) при попытках описать что-то сложное. Это мое мнение. Кому-то такое апи кажется прекрасным балансом между выразительностью и количеством кода, я же вижу в этом избыточную сложность, которая накладывает ограничения не там где надо. Постоянные баги с типизацией это доказывают, нет? Мне говорят что такое апи близко к естественному языку бизнеса, но покажите мне заказчика не программиста, который поймет в этом коде хотя бы что-то. Говорил давно и скажу опять, хотите хорошее декларативное апи - делайте свой DSL с упрощенным синтаксисом.
- Производительность. Она в целом лучше чем у редакса и достаточная для множества случаев. Околомобыксовая, зависит от кода конечно. Хотя есть множество публичных и не публичных (тут мне на слово придется поверить) случаев, когда авторы заявляли про максимальный перф, а потом оказывалось все сильно иначе. Бенчей нет и текущий тейк от ментейнеров про “перф нормально невозможно замерить” для меня выглядит как очевидная отговорка что бы замять тему.

И тут мы приходим к ответу на вопрос “А какое тебе вообще дело?”. Агресивность, токсичность и необъективность фанатов эффектора постоянно переходят все границы. Я не могу это спокойно воспринимать, а приходится, тк сталкиваюсь с этим периодически. Это очень похоже на религию - есть только один верный путь, остальному - джихад. Ужасно.

Представители комьюнити эффектора часто не воспринимают мнение человека, унижая его идеи и даже факты от него, без попыток объективного анализа и доказательства, оперируя субъективными терминами “красиво” или “интуитивно” (и десятком других), без анализа всей картины.
Сотни случаев советовать эффектор не к месту бьют все рекорды, пользователи других библиотек так не делают.
Агресивные наезды на мнение о каких-либо недостатках эффектора - норма.
Агрессия к тем кто переиспользует код из репозитория эффектора без указания авторства (лицензия MIT). Речь о нескольких десятках строк, этот инцидент произошел со мной давно, но мне кажется он хорошо илюстрирует проблему.

Пост, наверное, еще будет дополнятся, но я надеюсь что мне не придется больше учавствовать в прямых дискуссиях со сторониками эффектора в их привычной агресивной манере. У меня больше нет сил на это.

Я хочу что бы эффектор развивался и задавал здоровый конкурентный тон экосистеме нашей индустрии. Я хочу увидеть обещанные несколько лет назад девтулзы, которые перевернут мое представление о дебаге. Я правда хочу что бы его перф соответсвовал реалиям 2022, а не 2020 - нам еще многое предстоит сделать в этом направлении и конкуренция здесь необходима. Я хочу видеть больше крутых идей и их реализаций. В дружественной среде.

transferables

Подписан на создателя https://bundlejs.com в тви (twitter.com/okikio_dev).

У него вышла новая либа для проверки возможности передачи объекта между потоками - почитайте доки и исходники, там интересно!

Закинул ему пару мелких ПРов по улучшению производительности, простые и наглядные: раз, два.

На внезапном стриме через 2 минуты с @artalar посмотрим недавно вышедшую вторую версию менеджера управления состоянием reatom

🐶 Напишем игру с цветами 

📺 Посмотреть: twitch.tv/kirjs | youtu.be/SdOPCKXhc0k 
🎫 Доки: reatom.dev

JPEG XL

Текст не мой, анрол этого треда, который мне показался очень полезным. Igor Strebz пишет:

Меня не волновала монополия Google Chrome, ведь браузеры итак поддерживают достаточно стандартов для комфортного сёрфинга.

Отношение изменилось, когда Google заблокировало развитие формата JPEG XL по надуманной причине. Смотрите, каким с ним станет веб: https://youtu.be/UphN1_7nP8U

1. Уже после 50 килобайт (8%) браузер уже смог бы что-то показать, не дожидаясь окончания загрузки
2. Оптимальный по весу, на 30% меньше чем JPEG
3. Можно пережать JPEG → JPEG XL без потери качества, сэкономив место
4. Мемы станут стабильнее, даже 2000 пересохранений спустя картинка не меняется, в отличии от других форматов: https://pbs.twimg.com/media/FljpjyUXEAEV-hp?format=jpg&name=large
5. Можно использовать для фотографий космоса с колоссальным разрешениями и весом файлов за 100 Мб
6. Без патентов, чистый open source

Как ни крути, формат отличный.

Google решили так продвигать свой AVIF ≃ стоп-кадр видео-кодека AV1. Из-за чего есть ограничения, сравните: https://pbs.twimg.com/media/FljqLokXoAUMH46?format=jpg&name=large

Для webdev'a безумно много фичей, снимающих головную боль:
- альфа канал
- жмёт loseless лучше чем PNG
- параллельный decoding
- 10x быстрее encoding по сравнению с AVIF
- XYB color space, больше тёмных цветов
- браузеры с progressive decoding автоматом могли бы получать @1x из @2x

Сообщество взбунтовалось, ответ Google убил:
> The new image format does not bring sufficient incremental benefits over existing formats
🤨⁉️
> There is not enough interest from the entire ecosystem to continue experimenting with JPEG XL
😕 тоже ложь
https://bugs.chromium.org/p/chromium/issues/detail?id=1178058#c64

Там буквально пришёл principal engineer из Intel и указал им, что последнее утверждение не подтверждается на практике: Adobe, Serif, Krita и Intel — в своих продуктах внедрили поддержку JPEG XL из-за HDR и предлагают использовать по умолчанию 🤷🏻‍♂️

Act

Самая-самая библиотека для описания реактиных связей!

Сделал по приколу. Но я серьезно. Треть килобайта, Карл! По перфу в топе топов, причем не в простых кейсах, а с разруливанием всех пограничных случаев условных переподписок… На простых кейсах оно в космос улетает.

Апишка намеренно максимально простая. Это современное перерождение легендарного S.js.

А в чем секрет? Аллочка ты сума сойдешь! Вместо сложных проверок инвалидации кеша я просто пересоздаю весь граф на каждый апдейт, оказывается это быстрее, иммутабельный подход быстрее! А учитывая то что графы в рядовых приложениях редко бывают большими, скорее множество отдельных и мелких - проблем с этим не возникнет. Вообще в 2023 память работает очень хорошо, на мобилках (критичном сегменте) используется SoC и за счет этого там скорости побыстрее ваших i7 бывают.

Биндингов нет, сами пишите, мне не охото. У меня отпуск.

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

По рекомендация из чата:

помню доклад, года 2017 на cppcon, где часть браузера с OOP на DOP переписали и код стал в 450 раз быстрее

Видимо, время пришло.

Немного поделаем самую быструю (?) либу для работы с JSX

За час сделали поддержку условного рендеринга для act!

Посмотреть можно тут. Принцип act-jsx: рендер один раз (мемоизировать ничего не надо), в значения прокидываем акты (обсерваблы) и происходит очень точечная автоподписка на все свойства. Все очень ленивое и быстрое, но стейт нужно хранить вне компонентов. К счастью с act с этим проблем нет, смотрите пример, в общем 🙂

P.S. этот же пример на реакте занимает в 2 раза больше кода и в десятки раз больше памяти и бандлсайза. act + act-jsx всего 700 байт.

Может, кто-то поможет с типами для JSX биндингов?
#help_oss https://github.com/artalar/act/issues/2

Новостей много, но не успеваю их расписать на посты :)

Вот вам первая демка @reatom/form-web: https://codesandbox.io/s/reatom-form-web-tefn82?file=/src/App.tsx

Этой ночью запаблишил альфа версию, там ещё могут быть баги. Фичи кмк наивкуснейшие:

- апи специально задизайнено для наилучшего решения всех простых и сложных случаев: максимальный вывод типов и возможность легко работать с динамически добавляемыми полями
- фреймворк агностик, более того, используются стандартные биндинги из пакета npm-react, те не нужен еще пакет биндингов для формы, как у tanstack распространено
- построен поверх @reatom/form - абстрактной либы для фабрикации филдов, включающей в себя менеджемент фокуса и валидации. Достаточно просто можно писать свои филды (актуально для react-native, сложных автокомплитов, дарг&дропов и вообще чего угодно)
- естественно, работает на @reatom/core, что дает кучу слажанных фич: зависимые поля, динамические филды, лайфсайкл хуки и куча оптимизаций производительности
- весит всего 3кб
- по скорости инициализации как react-hook-form (мб еще ускорю), ререндеров вообще нет даже при срабатывании логики зависимых полей

Это лишь сухой список фич. Попозже понаделаю примеров и покажу как рвать в хлам другие библиотеки.

Давайте минут через 10 войсом расскажу о дерти-чекинге внутри реатома