Итак сегодня 12 марта. Что это значит? А значит, что обманывать метрики в Core Web Vitals станет сложнее (да-да не удивляйтесь если у вас упадут в скором времени циферки в Lighthouse).

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

Сейчас на смену ей приходит метрика которая больше расчитана на общий пользовательский опыт работы со страницей: плавность скролла, скорость отклика на кнопках и тп. Поэтому если вам важны высокие метрики лучше ознакомиться получше с рекомендациями от google. Там целый раздел посвящен теперь только метрике INP(внимание в левую часть сайта, там целая куча ссылок по различным вопросам).

Как сильно изменится от этого выдача в поисковиках большой вопрос. Но вот директора/менеджеры могут прибежать с "у нас упали показатели Lightouse!!". Так что будьте готовы к такому повороту событий.

Посмотреть показатели можно тут: https://pagespeed.web.dev/?hl=ru

Раз уж подняли тему производительности, то вчера было еще одно важное событие в мире web perf-а. Под началом команды WebKit команды других браузеров (Google Chrome / Mozilla / Edge) и даже Intel объединились для прокачки бенчмарка для браузеров Speedometer 3,0.

1) Были улучшены способы замеры для более честной оценки производительности браузеров (подробнее можно ознакомиться в статье пункт Improved Test Harness)
2) Сместили очки: с предыдущей школой результаты могли улетать за 500. Теперь норма в 20-30 пунктах
3) Для всех популярных фреймворков на данный момент добавлены демки с замерами
4) Для приложения TODO сделаны 2 версии: с простым DOM и специально усложненным, чтобы лучше оценить как браузер с фреймворками справляются
5) 2 демки приложений имитирующих новостной сайт на Next и Nuxt
6) Несколько демок для визуализации данных (как D3 так и chart.js)
7) Из любопытного к бенчу добавлена демка с WYSIWYG-редактором

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

Так же в репе замечено что уже многое запланировано на 4-ую версию и даже 3.1

Хех. апрель выдастся жарким :D

Чтобы не мучаться придумывая 3 доклада разом, то на Стачку поедет переосмысление доклада с UfaDevConf-а: JS которого нет

Поговорим о уровнях погружения в язык и какие есть особенности у этих этапов

А эта конфа: Стачка. В городе Ульяновск 12-13 апреля. Буквально через неделю после нее уже лететь на Holy.js

Если раньше шутили что фронтенд фреймворки растут как грибы после дождя, то теперь это же можно сказать про рантаймы для JS. Чувствуется уже усталость народа от node.js, все так и норовят от него уйти (как и от v8 в частности).

Сейчас я хочу поведать о релизе нового рантайма WinterJS. Чем он примечателен? Да, это очередной Blazing-fast рантайм для JS/WASM на Rust на основе движка SpiderMonkey (это тот что у мозиллы под капотом); при этом заявлено что он WinterCG совместимый.

Начну с WinterCG. Это рабочая группа на основе объединения множества компаний, которые хотят обеспечивать совместимое API для рантаймов вне браузера, но разработанное для веба. Те есть спека в которой описано поведение fetch в браузерах, но как быть node.js/bun/deno и другим решениям? А они тоже пишут свои спеки относительно спецификаций Web-платформы, как для того же fetch. Таким образом разработчикам библиотек проще поддерживать решения которые будут совместимы между рантаймами, да и в целом разработчикам жизнь заметно упрощается, когда есть стандартизация. Ну вот WinterCG совместимая -- та что соответствует спецификациям этой рабочей группы.
Важный момент WinterCG не имеет прямого отношения к WinterJS!

Есть еще одна не неменее интересная тема, которая достойна отдельного разбора: WinterJS может быть собрана полностью в WASM и работать через WASIX. Это расширение для WASI. Так, не пугаться. Давайте по порядку. Начнем кратко с WASM. WASM - это особый формат для стековой виртуальной машины, которая почти идет придатком к JS рантаймам (JS движки также обеспечивают поддержку WASM). Но этот бинарный формат беззубый, те сам по себе у него нет никакого I/O, работы с системой и тп. Для того чтобы вооружить WASM и был инициирован проект WASI (его разрабатывает подгруппа WebAssembly CG, которая отвечает и за WASM). Ок, а WASIX это еще дополнительное расширение вокруг WASI, но уже уже от wasmer-а (Wasmer это рантайм для WASM приложений).

Итак, пока все не вылетело из головы. Мы имеем новый рнтайм от команды Wasmer и он обещает быть чертовски быстрым (до 150к запросов в секунду). Он направлен на облачные решения. Совместим с основными Web фреймворками (пункт Compatibility with existing Web frameworks. там же демки и стартеры).

Завоюет ли он какую-то популярность сказать сложно, но людям точно пора отвыкать что JS вне браузера = только Node.js. Уж больно много альтернатив повылезало для специфичных задач. Планирую подробнее подрасписать какие вообще сейчас есть решения и для чего они, ибо запутаться в них уже ой как не сложно. Точно также можно сказать и про v8: JS это не обязательно V8. Рантаймы активно пробуют другие решения: SpiderMonkey, JavaScriptCore. QuickJS etс...

Ух, подготовка к Holy.js в самом разгаре. Напоминаю, что тема будет кастомные рендереры во Vue. Тема очень интересная.
И я решил проверить, а что если отрендерить Vue приложение в React приложение? Те это не просто средендерить Vue в элемент и его использовать в React. А выходом Vue являются именно VNode от реакта

ОНО РАБОТАЕТ! Сижу, играюсь и радуюсь как ребенок :D

Финальная цель это запустить Vue приложение на Next / ReactNative / Expo

Те попытаться реализовать полный интероп из Vue в React.

Поиграться можно будет чуть позже

Больше стандартов богу стандартов! В недавней новости вы скорее всего впервые столкнулись с WinterCG(Web-interoperable Runtimes Community Group). Но вот буквально вчера анонсирована новая рабочая группа: OCWG(github).

Чем же займется эта группа? А тут надо отступить к другой новости, которую я решил не публиковать. Есть такой продукт Obsidian. Он нужен для заметок и прочего markdown-based контента с учетом, что это все на local-first(те первична работа от локальных файлов если упрощать). И вот там был особый синтаксис для хранения данных их WYSIWYG-редактора контента в свободной форме. Далее они решили, что этот формат стоит доработать и опубликовать как публичную спеку: JSON Canvas. Через нее можно описывать элементы на бесконечном холсте.

Казалось бы на этом можно и закончить, но инициативу подхватили другие продукты реализующие идеи бесконечных полотен такие как: tldraw, excalidraw, stately.ai, kinopio, dxos и другие. И будут они заниматься разработкой и распространением общего стандарта для приложений с функционалом бесконечного холста. Их великое множество и есть целый сайт посвященный таким приложениям. Однако, они не стали говорить, что JSON Canvas это их формат, вместо этого они обещают пойти еще дальше. Против JSON Canvas они ничего не имеют, но они хотят смотреть шире и быть группой по решению общих проблем для форматов описания бесконечных холстов.

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

Ожидаемые результаты работы группы:
- Разработка общего базового формата на основе принципов команды.
- Расширение формата для широкого спектра инструментов.
- Возможность синхронизации в реальном времени между несколькими полотнами.
- Создание тестового стенда сродни CSS Acid Tests.
- Предложение по улучшению спецификации JSON Canvas.

Формат встреч будет публичный(?) каждые 2 недели. Для обсуждения идей есть Discord, куда зовут всех заинтересованных.

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

3 ** 3

JS !== v8

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

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

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

Я верю, что совместными усилиями мы сможем преодолеть дефицит информации по движкам и упростить их изучение!

Такс, для frontend-разработчиков caniuse не пустой звук. Но что делать если речь идет о рантаймах отличных от браузера коих сейчас расплодилось немало?

Ну тут к нам и приходит на помощь новый инструмент runtime-compat(Github) от unjs,
runtime-compat выдает нам таблицу современных рантаймов JS-а и их поддержку отдельных фичей. Также имеется дополнительный фильтр по совместимости со спецификацией от WinterCG о которой я писал ранее. Несмотря на схожесть с тестами в браузере, тесты для рантаймов несколько сложнее, так как часто требуется индивидуальный подход для вызова функионала того или иного рантайма. За основу были взяты тесты для браузеров в mdn-bcd-collector. Также стоит отметить, что тесты во многом автосгенерированы и могут быть несколько неточными по этой причине.

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

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

Состоялся крупный релиз. Vitepress наконец-то получил свою долгожданную версию 1,0,0 (и все это после 45 release candidate).

Что это за фрукт? Изначально продукт назывался Vuepress и был предназначен для генерации статики в экосистеме Vue. Стоит отметить, что несмотря на заявленный SSG для Vue, люди оставляют неоднозначные отзывы про такое использование. а вот для контентных сайтов/документаций он подходит прямо отлично. Легко встроить в любой уже существующий проект, чтобы дать ему документацию.

Как можно понять, то основной движок при всем теперь: vite, а работает внутри как фреймворк все еще vue. Контент пишется на markdown c интеграцией Vue компонентов прямо внутри. Это действительно удобно, так как Vue полностью встраивается в markdown так как его синтаксис шаблонов полностью поддерживается парсерами HTML. Все докуменетации во Vue экосистеме написаны именно с использованием Vitepress(исключение экосистема Nuxt, но про нее позже).

На самом деле все больше в интернете вижу различных сайтов использующих Vitepress, даже если они никак не связаны с Vue, например сайт Hono или Mermaid.

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

Такс, особо не расслабляемся, сразу ходом пошел 1-ый release candidate у SolidStart(старая дока) и выход из статуса beta-версии. Это решение из разряда мета-фреймворков. Те нечто схожее по смыслу с Next.js(React) / Nuxt(Vue) / Analog(неофициальное решение для Angular) / SvelteKit(Svelte) но теперь, как можно долгадаться, для Solid.js.

Нам сходу заявляют о 3-ех режимах работы CSR(client-side rendering), SSR(server-side rendering), SSG(static site generator), те все по классике. В комплекте идут пресеты для развертывания на различных решениях: Netlify, Vercel, AWS, и Cloudflare.

Никого уже не удивить и роутинге основанном на файлах в папке routes. Отдельно выделены API Routes, для серверного API и они тоже работают на основе файлового роутинга.

"use client"/"use server" тоже идут в комплекте. Те опробовать мощь server functions можно и в нем.

Что у нас под капотом? SolidStart основан на Vinxi + Vite. Vinxi это по своей сути движок/набор примитивов для помощи в создании полноценных FullStack фреймворков на JS. Vinxi же держит под капотом Nitro, что достаточно любопытно. Nitro это решение для написания веб серверов со спецификой мета-фреймворков. Разрабатывается же Nitro как часть экосистемы unjs для нужд Nuxt-а. Нитро в свою очередь является надстройкой над h3. h3 - тоже часть экосистемы unjs и выполняет функцию высокопроизводительного аналога express-like решения для серверного фреймворка.

В остальном по тому что я вижу (я не разрабатывал конкретно на SolidStart еще), то решение пока сыроватое и ему нужно дать время окрепнуть и обрасти жирком.

Мне нравится Solid.js и я желаю этому фреймворку удачного развития и покорения рынка на смену React.js :D
Теперь ждем действительно первый релиз 1,0,0

А я напоминаю что сегодня у вас еще есть время чтоб проглядеть курсики по Vue которые вам интересны от vueschool.

И нет, это не реклама, а рекомендация от себя, так как часто спрашивают, какие брать курсы по Vue.
Так почему бы не воспользоваться шансом сделать это бесплатно?

Antfu вновь доказывает, что DX в мире JS-туллинга можно еще развивать и развивать.
Если вы его еще не знаете, то самое время познакомиться, но для начала о его новом решении: eslint-typegen

Кратко: решает проблему с отсутствием типизации в конфигах ESlint на основе кодогенерации. Те при первом прогоне он создает .d.ts файл основываясь на переданных правилах ESlint.

Имеется 2 варианта использовать:
- кодогенератор на основе переданного конфига (основной)
- Low Level API с преобразованием к строке для последующей записи в нужное место

Работает все это чудо основываясь на JSON Schema, которая указывается у правил в ESlint. Далее прогоняется через json-schema-to-typescript и далее небольшие трансформации для приведения к нужному виду. Готово. Общий объем библиотеки менее 300 строк кода, так что можно вполне изучить его за пару часов.

Из любопытного:
- если вы пользуетесь @antfu/eslint-config, то вам можно это дело не подключать, все уже настроено из коробки
- автором идеи он называет @Shinigami92

Если вас давно раздражает, что никаких подсказок в ESlint толком нет, то вот способ это исправить

Ура! Спустя N лет документация доступна на русском. Чуть-чуть тоже прикладывал усилия в переводе и планирую продолжить. По поводу багов и очепяток писать сюда: https://github.com/vuejs-translations/docs-ru/issues

Сайт: https://ru.vuejs.org/

To close or not to close

Забавная дискуссия(на самом деле самый настоящий холливар) выдалась в одном ишьюсе в репозитории Svelte.

Кратко: Рич Харрис(создатель Svelte) только сейчас обнаружил, что

<div /> Hello

Это не

<div></div> Hello

А

<div> Hello</div>

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

Вначале разберемся с ситуацией в HTML:
HTML - не имеет понятия self-closing element. Вместо этого есть void elements: br / hr / input и тп. Так же есть допущение для внешних элементов: svg/mathml, которые реализованы на основе XML. В стандарте XML self-closing tags называются empty-element tags(элементы у которых нет контента). В остальных случаях HTML просто... игнорирует завершающий /, но с 1 исключением

<a href=login/>  

<a href="login/"> тоже самое
<a href="login" /> не верно (Svelte и этот тест провалил)

Самое забавное, что все фреймворки ведут себя по разному относительно этого вопроса:

JSX(React. Solid etc...) - поддерживает self-closing tags
Angular - только с 16-ой версии начал их поддерживать для своих компонентов, в остальном все как HTML. Кстати, там тоже была бойня, хоть и поменьше
Lit - все согласно HTML. Кстати, согласно спеке даже custom elements не могут быть самозакрывающимися. Один человек недовольный отказом, даже сделал расширение добавлющее этот функционал
Ember - официально поддерживает self-closing tags, как часть расширения HTML
Vue - тут все сложнее.
1) Если используется рантайм компиляция шаблонов из HTML, то работают правила HTML и все работает согласно спеке
2) Если происходит этап билда шаблонов, например со сборщиком, то self-closing tags доступны.
При этом в vue eslint можно четко разграничить желаемое поведение. Но и это было не всегда и сам Эван был против self-closing tags, но с появлением vue-loader все-таки поддержали данный функционал.

Как мы видим единого мнения в сообществе вообще нет. На одной чаше удобство, на другой плашка "соответствует HTML5"и куча различных трейдоффов.

А что считаете вы, как должны поступать фреймворки?

Ну вот и день Х. Чуть позже залетит сюда преза и исходники даже для тех, кого нет на холи

Так. Это заняло некоторое время (пришлось написать текстовое описания слайдов и поднастроить репу, чтобы я мог множество презентаций в ней хранить). О итогах моей поездки и Holy в целом сообщу чуть позже.

А вот пока и обещанная презентация с исходниками к ней.
А вот исходники к шуточному Vueact.

PS. Управление презентаций стрелочками, либо мышкой направить в левый нижний угол.
Там же можно включить режим спикера и увидеть текстовое описание к каждому слайду (оно достаточно сильно отличается от того что было на Holy, но в достаточной мере, чтобы поработать с материалом самостоятельно и без видеозаписи)

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

С последнего поста народу тут явно поприбавилось. Welcome!
Поэтому кратенько о себе:
Я - Чернов Денис. Работаю в Спортмастер-е на Vue-хе. Влюблен в кодинг уже 13+ лет
Увлекаюсь IT-шкой в широком смысле. Внимательно слежу за всеми колебаниями в области фронтенда.

Что можно увидеть на канале:
1) Новости которые показались мне наиболее интересными. Обязательно с разборами и кучей ссылок на источники
2) Интересные моменты из Frontend-разработки и не только
3) Отчеты и доп материал по моим докладам.

Говорю я о всех фреймворках, но особой любовью тут пользуется именно Vue.
Что впрочем и стало причиной моего последнего доклада на Vue Msk.
Это стал заключительным выступлением в моем первом "спикерском сезоне". За пол года 3 конфы и 1 митап (все доклады разные, но один модификация более старого)

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

Материал для дальнейшего изучения:
1) chibi vue - буквально лучшего руководства не найти в духе с 0 до своего мини-Vue. Позволяет хорошо прочувствовать работу под капотом
2) rfc effectscope - хорошо разбирается тема с effectScope
3) watch with @vue/reactivity - в докладе я говорю про отсутствие watch/watchEffect внутри @vue/reactivity. В статье Энтони разбирает подкапотную работу реактивности во Vue и как все-таки вернуть watch
4) reactivue - шуточный (или нет) способ объединить "лучшее" по мнению Энтони между react и vue. Как раз способ запустить @vue/reactivity внутри react.
5) vue-lit - PoC как запустить реактивность vue внутри lit-html
6) исходники @vue/reactivity, Но внутри @vue/runtime-core тоже хватает интересностей (scheduler, apiWatcher/apiComputed)

Всем привет. Тем временем Holy.js сделал подарок и выложил сразу 4 видео по 4 наиболее популярным фреймворкам

- как работает Next.js
- как человек делает свой фреймворк a la Svelte
- мой доклад по Vue Renderer-ам
- и доклад с точно такой же сутью как у меня только по Angular (только тут делают на примере консольного приложения).

Так что можете выбрать доклад по своему любимому фреймворку и посмотреть.

И вот вам список докладов, но относительно работы рендереров в разных фреймворков:

- Мой доклад по Vue Renderer-ам. Тут я упоролся и сделал рендерер из Vue в React дерево элементов.
- Angular Universal. Разбирается на примере рендера в консоль
- React Reconciler с примером рендеринга в Figma
- Solid Universal. Доклад от самого создателя Solid.js (естественно на английском)
- Конкретно по рендерерам Svelte ничего конкретного не нашел. Но вот есть такое видео, где Svelte приделывают фичу по рендеру из маркдауна в компонентах в HTML. (если у кого есть больше инфы, обязательно поделитесь)

PS. Повторно прошу прощения за ввод за заблуждение неймингом доклада про Canvas. Изначально он был в концепции, но потом я увидел решения существующие и что описывать его будет не так весело, как ресерч рендерера в React. Дополнительно напомню, что главная цель этого рендерера -- это пощупать гибкость рендереров Vue даже на таком экзотическом примере, а не реальное использование на продакшене. Для тех кому все-таки интересен в canvas: vuvas (код рендерера).

И так. спустя более чем полгода мы все-таки получили результаты от State Of JS 2023(я уже и не ждал). Все задержалось из-за того что организатор опроса выгорел и попросил помощи других людей с анализом собранных данных. Может поэтому в некоторых местах пугающие цифры по объемам данных которые "не учли". Чуть позже поймете о чем я.

Проведу небольшие итоги от себя:

1) Народ считает самой главной проблемой в JS:
1.1) Отсутствие статической типизации из коробки. Причем лидирует этот пункт с большим отрывом (33% vs 9% у второго места). Оно же лидирует в списке "фичей которых не хватает"
1.2) борьбу между CommonJS и ES Modules
1.3) Болезненность работы с датами
2.3) 84% ответов не смогли определить куда-то в конкретное место. Число зашкаливающее

2) Народ считает самой главной проблемой при работе с браузерами:
2.1) Поддержка браузерами. Достаточно спорный пункт на мой взгляд. Вспомнить что было лет 15 и даже 10 лет назад, то сейчас кроссбраузерность гораздо меньшая проблема. Возможно этот пункт стоит скорее считать как "скорость поддержки". Те, люди видят классные фичи, а потом понимают, что N лет все равно не смогут ими воспользоваться. Вот это уже действительно несколько огорчает. Процент отметивших этот пункт 32%, что тоже ЗНАЧИТЕЛЬНО выше второго места с 6%
2.2) Safari. Когда я проходил опрос этого пункта не было, но это не помешало ему забраться на второе место... Думаю этого достаточно, чтобы понять всю радость программистов от этого "инструмента".
2.3) 76% ответов не смогли определить куда-то в конкретное место. Это что-то перебор. Думаю, что потеряли большое кол-во информации

Далее переходим к самому интересному разделу: библиотеки
Тут можно написать 1 слово: Vite. Vite буквально рвет все топы. Из 6 "наград" опроса Vite взял 3. При этом еще в 1 отстав всего на 2% процента от... Vitest, который тоже замечательно показал себя заняв топ тир среди инструментов тестирования. А вот Webpack четко летит на дно по показателю удовлетворенности. 48% респондентов отметило его как "использовал его, впечатления неприятные". Я могу его назвать самым быстропадающим с точки зрения впечатлений о нем. Забавный момент, что на приложенном графике. То где сейчас находится Vite, это то где в 2017ом был Webpack. Так что, возможно, лет через 6 Vite может ждать такая же судьба.
Что касается других сборщиков, то SWC и esbuild также попали в топ тир. А вот строчки аутсайдеров занял Parcel и Webpack.

Теперь идем к тому чего я больше всего ждал: Frontend Frameworks. И тут ситуация любопытная. Разберемся с каждым фреймворком по отдельности. При этом я оставлю предупреждение:
Опросы всегда штука специфичная и может давать ошибки в зависимости от захваченных групп опрашиваемых. Обычно люди проходящие опросы более заинтересованы в разработке, чем люди их игнорирующие. При этом люди проходящие опросы тоже чаще являются early adopters(люди берущие на вооружения или пробующие что-то малопопулярное/свежевышедшее). Поэтому стараемся учитывать эту погрешность и не принимать результаты опроса близко к сердцу. Конец предупреждения.

React. Мягко говоря cдает позиции относительно опроса. При этом он не падает в популярности (а даже растет), но вот процент недовольных им очень быстро растет. (это можно увидеть на том же графике с "кометами"). И черная полоса пошла с 2019. Я это связываю с подниманием головы других решений: Vue3, Svelte/Solid. Народ буквально увидел, что можно решать проблемы иначе. Далее команда реакта начала жить своей жизнью, время от времени повергая в шок программистов своими новыми фичами, которые приходилось откатывать после волны справдливого хейта. Опрос был сделан в декабре 2023, так что в 2024 интересно увидеть динамику после выхода React 19, все большего доминирование Next и нового React Compiler-а. Но сколько не ругай реакт, а с точки зрения популярности он все еще только растет. А вот Next.js прям очень сильно скакнул вниз по "уровню счастья". Сомнительные решения и app router, думаю, приложили к этому свою руку.