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

Очень рекомендую

Июль выдался сумасшедшим. Мне написало куча народу с разными интересными предложениями. И в два я, в итоге, вписался, ждите еще постов сегодня 🙂

Но совмещать вместе: фултайм работу, продуктовую и девелоперскую разработку reatom.dev, семью с маленьким ребенком, и еще какие-то активности… Это уже за гранью, конечно.

Одной из моих проблем была прокрастинация над тулингом. Мне казалось что без идеального таск менеджера у меня ничего не получится. Я даже начал писать свой собственный! Ну, без фундаментальных недостатков, вы понимаете. Но это все игры.

Много думал, всю прошлую неделю пришлось серьезно пересматривать мой тайм менеджемент, с ним было много принципиальных проблем. Теперь больше планирования, рамок, приоритетов, дедлайнов.

И у меня такие выводы. Хороший тулинг помогает разгрести и проще анализировать все задачи. Но главный инструмент - это всегда ваша же голова и мотивация. Если вы не можете делать дела имея школьную тетрадку и ручку - вам ничего не поможет, в долгосрочной перспективе точно.

Это как с copilot. Он действительно крутой и очень мощный и может сделать из вас 10x enginear, но только если вы уже этим самым enginear являетесь, и вы используете copilot, а не он вам говорит как и почему что-то делать.

Я присоединился к стартапу https://facelink.cc/ - это no-code платформа для создания "видеоворонок", новый способ создать сайт в современном видео формате. Это как Tilda + TikTok 🤯

Пилотная версия уже показала огромный спрос рынка на такое решение, а также очень хорошие бизнес-метрики для SAAS-проектов (CR из регистрации в оплату 7,38%, LTV 6+ месяцев и другие) — пора создавать серьезный продукт. У клиентов множество требований, а самих клиентов много как по количеству, так и по качеству (крупный ритейл, известные бренды, топ-блогеры и т.д.).

Вот примеры, как продукт работает у клиентов:

- https://www.fuseservice.com (виджет на сайте)
- https://facelink.cc/sp36bli2t (лендос)
- https://facelink.cc/wdvcgzdo7 (лендос)
- https://facelink.cc/hdysetqwh/ (сбор отзывов)

Наша цель - выйти на мировой рынок (рынок с потенциалом 200+ млн. юзеров). И мы ищем в команду того, кто готов создавать продукт мирового уровня и имеет амбиции серьезно вырасти по доходу (у членов команды есть опцион).

Планируется настоящий highload как на беке, так и на фронте. Админка - мини фигма + куча статистики и аналитики. Клиент - приложуха с миллиардами открытий в месяц.
Базовый сетап: TypeScript, vite, react, reatom, urql, mantine, css-modules. На беке nestjs. Все в монорепе на Gitlab.

Текущая команда: 4 на беке, 3 на фронте, 5 за product design.

Макеты в фигме уже заждались. Если у вас достаточно опыта в больших или не обычных проектах и времени что бы быстро пилить фичи (с моим ревью) - пишите об этом @igeomax! Фаундеры стартапа — предприниматели с успешным 15 летним опытом в бизнесе. Создали 10+ компаний, несколько успешно продали.

На выходных обновил пост Декларативное программирование.

Накидайте лайкосиков.

https://github.com/domfarolino/observable/issues/41

Добавил в REPL реатома @discoveryjs/discovery от @gorshochekvarit (комит).

Вот так можно попробовать: t.me/reatom_ru_news/222

В целом штука прикольная и для больших жисонов удобная, особенно полезна когда нет возможности залезть в консоль, например с мобильного.

Не хватает только тёмной темы (надо бы пока добавить filter invert...) и кнопки copy для объектов. Мб кто законтрибьютит?)

JS challenge:

- you have a list of 1000 items
- you have an async function process(item)
- you need to process all items
- it needs to be done concurrently, but not more than 25 at a time
- collect items with errors

what's the cleanest way to do this?
libraries allowed

…

На скрине мой вариант решения :)

#не_вопросы_для_собеседований

Сколько логов будет выведено?

На этой неделе дроп сразу двух видеоверсий последних выпусков. Держите интереснейший двухчасовой разговор про Dart с его разработчиком, Славой Егоровым.

Да и вообще, не забывайте подписываться на наш YouTube канал и оставлять там побольше комментариев. На алгоритмы это не влияет, но нам очень радостно!

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

Как и какие данные передаются от сети к компоненту, от события в сеть, от страницы к странице, от функции к функции.

Мутабельные или иммутабельные, реактивные и/или сериализуемые, классы / функции / курсоры. Весь код что вы пишите - это обработка данных. Проблемы начинаются когда данные одного модуля / слоя нужно передать другому - это и есть архитектура.

Это вкратце, за деталями - думать.

Возможно версель уже год не чинит баг/очень плохое поведение, потому что они зарабатывают на этом.

Супер кратко:
1. Уже больше года есть баг, при котором у вас не инвалидируется клиентский кеш, что приводит к отображению устаревших данных. Буквально вы редактируете сущность, затем возвращайтесь к списку сущностей и там видите устаревшие данные.
2. Люди из команды верселя появились в issue полтора раза, затем всё стало выглядеть так, словно это намеренное игнорирование проблемы.
3. Через некоторое время (практически год!) они дописывают документацию, показывают схему кеша, но проблема не решается.
4. Согласено схеме, люди должны использовать функцию, которая приводит к инвалидации кеша, однако даже на приложениях для личного использования легко завалится за лимит в 100 инвалидаций, которые предусмотрены бесплатным тарифом.

В общем, кажется по итогу мы имеем поведение, которое чинится платной функцией официально и кучей разных ненадёжных workarounds от сообщества.

Ну или иными словами, используешь app routes? → плоти

https://github.com/vercel/next.js/issues/42991#issuecomment-1670794471

React.js в 2023

Десять лет назад была создана самая популярная библиотека для SPA. Может ли успех длиться так долго и что будет дальше?

Начнем с маркетинга, политики и социологии. У меня в них околонулевые знания, все нижесказанное просто мнение старпера.

Я уверен что 2/3 популярности библиотеки - это хороший маркетинг. Конечно, лейбл фейсбука сыграл не малую роль в продвижении реакта. "Все ли пишут новый фейсбук"... Но маркетинг не обязательно должен быть целевой, это может быть удача зацепить ярких фанатов и амбасадоров, набрать критическую массу сарафанного радио. Проблема в том что иногда, как вышло с реактом, этот процесс становится очень инертным и не затухающим. Куча человеков ввязалась в какую-то тему и будут ее отстаивать просто по принципу "мое самое лучшее".

Нам свойственно популярность приравнивать к качеству, хотя это не так. Можно апеллировать к большому количеству документации и сообществу, готовому придти на помощь, но реальность намного сложнее. Хорошая документация (react.dev) появилась 5 месяцев назад. Давайте еще раз, самая популярная в NPM библиотека для фронта обзавелась нормальной документацией только спустя 10 лет разработки. Ладно, предыдущая дока была не плохая, но множество моментов в ней было опущено. Хотя, и в новой документации все еще много чего не раскрыто или раскрыто не полностью. Конечно, есть множество курсов, статей, даже книг. Но на сколько они достаточны и корректны, актуальны? Я не говорю что с документацией у реакта все плохо, вполне хоршо, но я бы не идеализировал этот фактор и не переоценивал его значимость. По моему опыту, самое полезное что может быть - это комьюнити. Но. Вам комфортно в @react_js или заходить туда скорее не приятная необходимость? 😉

Экосистема. Ryan Florence - автор самого популярного пакета для роутинга react-router, который ломает обратную совместимость каждый год 🤦‍♂️🤦‍♂️🤦‍♂️ пишет, "а че это у нас в экосистеме нет 1-2 хорошего юй-кита для всех". Действительно, нет.

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

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

Хуки - это не способ выделения логики, это жесткая привязка к компоненту в частности и к реакту в общем (код на хуках вообще не портабельный). У Angular, Vue и других библиотек реактивный примитивы - это отдельная библиотека. Я не говорю что код логики нужно все время переносить между фреймворками, но когда он не привязан к вьюшке - это хорошо, его легче писать, перемещять, тестировать. А писать логику на пачке useEffect, многократно логировать данные в ререндерах и пытаться понять что лишнее, а что нет, уфф...

Про производительность реакта даже не хочется говорить. Самое важное - его не удачные примитивы помогают вам писать медленный код. В бенчмарках с правильно написанным кодом реакт не ужасен, просто плох. Но вы будете писать именно ужасный по производительности код, так уж он устроен.

Еще напомню про квирки React.js.

Конечно, в реакте много хорошего: очень редкие breaking changes, синтетические события удобны и надежны в рядовой разработке, иммутабельность и простота.

Но как все выше написанное взвесить вместе?

Точку нам помогает поставить vercel, который не столько пытается заработать на реакте, сколько просто напоминает нам - React.js был создан для решения конкретных проблем, не всех. Тому же фейсбуку он нужен не что бы его использовать как есть, как мы это делаем, а что бы мочь на нем построить свой внутренний, нужный только фейсбуку, фреймворк.

Реакт - микрофреймворк в специфическом стеке фулстек разработчика. Он точно не нужен большинству. Практика GraphQL показала что даже часть ответственности бекенда отдавать фронту - задача тяжелая и далеко не всегда профитная.

Куда вам уходить с реакта? Простой и надежный ответ (далеко не идельаный) - vue.

А я пойду пилить свои велосипеды.

Нет времени написать подробный пост. Но очень хочется поделиться своим открытием на выходных, для меня это микрореволюция.

Описывать хоть немного реактивную логику нормально сейчас очень сложно. С любым тулингом. Пока примите как данность.

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

...

Лонг стори шорт: debounce, throttle, sample обычно воспринимают как декораторы над каким-то процессом, которые как бы его оборачивают, контролируют снаружи. А я вот понял что это вкорне не верно, они являются частью процесса и при своем успешном выполнении продолжают процесс, а при не успешном - отменяют. Т.е. тот же дебаунс - не откладывает процесс до резолва таймаута, а отменяет все запущенные процессы при не достижении таймаута.

Понимаю что может быть не понятно пока, но я поэкспериментировал и такой подход позволяет радикально упростить кодстайл. Stay tuned.

Иконки и JSX.

Вот хороший обзор: Breaking Up with SVG-in-JS in 2023.

Но мне стало интересно, можно ли использовать JSX и компоненты для удобства темизации и параметризации, но не рендерить их в DOM?
Накидал прототип. Позамерял потребление CPU через профайлер - разницы не заметил =( Есть идеи что я мог сделать не так или тут впринципе нечего оптимизировать?

Спасибо всем за комментарии! Обновил песочницу, поправил способ замера, задеплоил прод версию (реакт в деве делает много лишней работы): https://csb-x6qhq3-azxnw4k6s-artalar.vercel.app/

Результаты, примерно, такие:

- JSX в полтора раза медленнее (на моем среднем телефоне).
- JSX хавает в два раза больше памяти.
- Сам парсер пока очень примитивный и может легко ломаться, но как способ оптимизации для некоторых редких случаев - неплохой вариант.