Есть такой уже старый и почти заброшенный ponyfoo.com, которым я восторгался в свое время. Там можно найти множество глубоких и понятных статей по теме фронтенда и далеко не все из них уже устарели.

Например, туда писал Benedikt Meurer, один из разработчиков v8.

Или вот еще пара статей:
Polyfills or Ponyfills?
The JavaScript Standard

А по поводу проблем с производительностью спред оператора есть такие баги:

https://bugs.chromium.org/p/v8/issues/detail?id=10763

https://bugs.chromium.org/p/chromium/issues/detail?id=1204540

Выдержка от @cevek:

видимо проблема в том что спред создает новый объект не соответветсвующей мапе к оригинальному

The problem is that the CloneObjectIC creates local copies of object literal maps instead of reusing the shared trees from the cache. The following should be true but isn't:

 ~/v8$ v8 --allow-natives-syntax  --nolazy-feedback-allocation
 d8> o = {a:1, b:2}; %HaveSameMap({...o}, {...o})
 false

от этого случается мегаморфизм и прощай перформанс

Го войс на свободную тему минут через 5

Про легаси компоненты реакта, тестирование компонентов, конкурентные очереди в вебе и закрытые камьюнити

О канале

рекламу не даю

Привет, меня зовут Артём Арутюнян aka @artalar, я разрабатываю крупные ИТ-сервисы больше 10 лет, половину из которых программированием на JS. Выступаю на конференциях. Участвовал во множестве разнообразных проектах в роле системного администратора, девопса, продукта, менеджера, техписа, разработчика и лида. Сейчас работают линейным фронтендером, а в свободное время сфокусирован на разработке менеджера состояния Reatom.

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

Вот самые ценные материалы за все время:

- исправление уязвимости в nanoid
- архитектура и реактивное программирование
- кто такой лид
- простая и эффективная интернационализация
- gitpod
- cостояние на клиенте
- Temporal proposal (статья на английском)
- архитектура веба
- не функциональные требования

Еще интересное:

- headless ui
- доступность как архитектура UI
- иммутабельные и трансисдентные структуры данных
- про effector
- слоты в реакте
- Когда нужен SSR
- Декларативное программирование
- оценка производительности библиотек
- Service Worker для блога
- история микрохакатона
- что такое декларативное программирование
- оптимизации минификатора
- JavaScript empty mark
- простота кода
- синтаксис и семантика в программировании
- сложность API
- IoC & DI
- технологий: Hasura, Rome, SWC, linkedom, Preact signals, nx...

Иногда, случаются стихийные войсы на тему последних постов или просто обсудить чью-то боль. Например, вот детальное описание моего опыта с Hasura или дискуссия с Ильёй Климовым об архитектуре системы пермишенов.

Есть платный чат artalogg с еженедельными стримами для глубокого погружения: https://news.1rj.ru/str/artalog/1750

Смерть от тысячи порезов кеширования

Уже давно в разных чатиках @xbgnx высказывает мысль о том что реакт и все остальные библиотеки для рендеринга медленные не потому что в них не достаточно оптимизаций, а потому что их там слишком много и они в своей сумме только тормозят конечное приложение. "Правильный путь" - ререндерить все на каждый чих и не пытаться по дороге что-то мемоизировать. В заголовке поста есть ссылка на похожие мысли от Доддса.

Недавно у меня состоялся еще один разговор, где мне показали очень быстрый фреймворк для построение интерфейсов на Rust - github.com/emilk/egui. В первом же примере ридми сразу бросается в глаза такой код: age += 1. А как потом библиотека понимает что нужно перерисовать места отображения age? А никак, весь шаблон приложения просто целиком пересчитывается с нуля. И это не тормозит!

Как такое может быть и если это правда, почему такой подход ещё не стандарт, спросите вы?

Любое кеширование стоит ресурсов: помимо занимаемой памяти нужно больше процессорных ресурсов на ее обслуживание (GC) и инвалидацию кеша. В продвинутых реактивных системах под капотом используются графы по которым нужно бегать, иногда, по несколько раз.

А зачем нужно кеширование? Для предотвращения избыточных вычислений (если они идемпотентны). И вот в чем хитрость. Алгоритмы обслуживания кешей или реактивных графах выполняются достаточно быстро, кешировать их в вакууме незачем. Те кто познали этот дзен уже достаточно опытные и хорошо понимают что такое сложность алгоритма и как писать оптимальный код. Когда такие люди пишут примеры кода фичи / приложения без кеширования, что бы сравнить перф, их наивная реализация уже является оптимизированной версией, по сравнению с кодом рядового разработчика из массы.

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

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

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

someList.map(({id}) => anotherList.find(el => el.id === id))
VS
someList.map(el => anotherMap[el.id])

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

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

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

Помните медицинские карты в больницах? Картонные книжечки, в которые вклеены десятки листочков с анализами и тем самым докторским почерком. Сегодня клиники по всему миру переходят на электронные медицинские карты.

Первый протокол передачи медицинских данных в электронном виде появился в конце 1970-х — на 10 лет раньше веб-протокола HTTP. При этом комплексно задача хранения и передачи медицинских данных не решена до сих пор. Почему?

Разбираемся в новом эпизоде подкаста вместе с российским апологетом самого современного протокола передачи медицинских данных FHIR Николаем Рыжиковым.

Слушайте и подписывайтесь на всех платформах: Apple, Google, Яндекс, Spotify, Castbox, Overcast, веб-версия.

Декларативность

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

Я согласен с этим посылом, но количество ньюансов так велико, что теперь всю неделю я буду бомбить по этому поводу, ждите цепочку постов 🙂

А пока, могу предложить на этот счет мои мысли трехлетней давности в виде доклада или его текстовой расшифровки.

Готовлю сегодняшний пост, первый результат в поиске - моя статья, приятно удивлен 😅

Декларативное программирование - паттерн ограничения семантики.

Все эти "что VS как" часто оторваны от реальности. В действительности, какая-то синтаксическая конструкция может включать в себя много семантики, имея большой контекст работы, а может мало.

Семантика, что? Не очень понятно? Когда мы пишем код - мы решаем с помощью него какую-то задачу. Проблема мейнстримных ЯП в том что в нескольких строчках их кода может содержаться много смысла и то что этот же смысл может быть записан другими строчками кода. Массив в JS можно обойти с помощью ключевых конструкций for, for of, for in и while, встроенного метода forEach или вспомогательной библиотеки, вроде R.forEach. При этом, в циклах можно использовать break и continue, а в колбеках forEach никакого break, только early return. await внутри вычисления дает разное поведение в колбеках и в цикле. Крыша уже едет, а мы просто хотели посмотреть на элементы массива.

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

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

Какие есть еще способы достичь однозначности?

DSL (Domain Specific Language) - отдельный язык для описания очень ограниченного набора задач - в рамках выбранного домена. Т.к. он должен решать небольшой набор задач, то и код на нем проще и однозначнее. Причем, не обязательно такой код будет декларативен.

Бывают примеры, когда декларативный DSL оказывается чрезмерно сложным и позволяет одну задачу решать разными способами.
SQL прекрасный и, казалось бы, декларативный язык. Андрей рассказывал о его сравнении с наивной реализацией на общем языке программирования. Но как только вам нужна частая выгрузка для аналитики и перф, начинается профилирование сложности и пляски с джоинами (привет императив) вплоть до перестроения схемы. А по другому все еще не научились, оптимизация SQL до сих пор насущный вопрос.

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

Код должен быть однозначным - в этом заключается простота. Если глядя на код, не зная о входящих данных, можно с уверенностью сказать что он делает - это простой и однозначный код. Проектируйте API ваших библиотек с этой мыслью.

Почему на компьютере модалки не имеют бекдроп?

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

from this twit

Как же у меня бомбит с тайпскриптовых енумов.
Мало того что они используют зарезервированное в ЖС слово (что обязательно в какой-то момент сломается), так и реализованы криво и имеют плохой интероп с остальными типами / значениями и в общем ощущаются как очень странный костыль вместо юнионов.

Главная практическая проблема в них, для меня, в том что их нельзя мапить на уровне типов, те дженерик операции над енумами практически невозможны. Какие-то гиперболизированные, но бесполезные unique type, но иногда не unique 🤪

Про управление формами