Сейчас то да, но нередко тебя собеседуют спрашивая про то, что прочитали эн лет назад

Поэтому на вопрос "зачем нам нужен реакт" часто ждут ритуального ответа "скажи что знаешь про существование виртуал дом"

Я ж не отрицаю что упоминание перформанса важно

Если бы я был принимающим решения, для проектов среднего уровня, я бы брал Вью или реакт из-за их доминирования на рынке и огромного комьюнити.

В моей голове, для коммерческого продукта, это несёт гораздо больше преимуществ, чем даже любая более развитая "технологичность" фрейма

Хотя реакт может вполне существовать и без виртуал дом

На такой ответ я бы спросил а за счёт чего они добились доминирования. Какие боли они решали?

Ну мы про одно и то же, я тоже считаю что это более-мене важно, но что это совсем не главное.

Потому что на реальных приложениях генерация верстки через document.createElement() будет одним из первых боттлнеком в скорости и тут как раз нужен реакт чтобы решить проблему производительности

На реальных приложениях скорость не будет боттлнеком качества приложения :)

+1

Как же раньше жили без реакта. Я писал вполне production-ready приложения на бэкбоне не создавая сущности через create element в принципе

Потому что сам реакт довольно медленный в своей реализации виртуал-дома при сравнении двух деревьев а "time slicing"/файберы это своеобразный костыль - вместо того чтобы ускорить сам реакт используя советы по производительности (мономорфность и более предсказуемы конструкции js чтобы v8 и другие движки эффективно инлайнинили код через jit в ассемблер) - команда реакта просто решила скрыть проблемы производительности реакта размазывая тормоза по фреймам. И если в случае простых сайтов где анимации работают через css с нативным скроллом рендер через приориетизацию работает хорошо (поскольку эти занимается движок браузер в другом потоке) то как только мы будем писать figma-like приложение с кастомным скроллом или сложными динамическими анимациями через js то здесь уже смысл в приоритетах/файберах теряется. И это не говоря про кучу проблем которую приносят файберы/time-slicing (и то что команда реакта уже наверное 3 года никак не выпустит свои файберы из беты кое о чем говорит)

Но я понял к чему вы клоните - что на больших приложениях и сложной логикой боттлнек производительности будет не в скорости сравнения верстки а в тормозах тех binding-выражений в шаблонах внутри которых будет происходить вычисления derived/computed data от большого количества данных состояния (например когда в коде шаблона будет инлайном записываться мап-фильтр-сортировка-редюс-аггрегация-вычисления). Но для решения этой проблемы time-slicing/файберы а также советы команды реакта постоянно следить за перерендерами компонентов и использовать useMemo, useCallbask, etc также подходят плохо - тут более правильным решением будет автоматическая реактивная мемозация самих вычислений как это делает мобикс в компютедах. Кстати советую взглянуть как эту проблему решает современный Ember который очень сильно напоминает mobx

А Markojs  от eBay кто-нибудь использовал в проектах? С какими минусами столкнулись? Наткнулся случайно вот сегодня на него. Выглядит лаконично.

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

Маркетингом задавили

Меньше писать повторяющегося кода по управление и обновлению дом дерева

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

Это всё конечно было и до реакта с Вью. Но наверное другие просто хуже решали эти проблемы

Дальше раскрывать сложнее :)
Ведь если раскрывать дальше, то скорее всего так же ждут причины в порядке их веса и значимости

Ага, особенно вью с маркетингом :)

Эван первый сделал норм доку для китайцев.
Это был самый грамотный маркетинговый ход

Я понимаю что это звучит немножко как "угадай что я хочу чтобы ты ответил", но не знаю как навести конкретнее :)
Скажем так, с опытом начинаешь по разному смотреть на разные аспекты разработки программного продукта. Ответ "фреймворки нужны нам потому что они популярны на рынке" хоть и является не совсем тем чего хочется услышать, но куда ближе чем "фреймворки нужны нам чтобы решать проблемы с производительностью".

@xanf_ua я не прав насчет производительности? Или какой по вашему ответ на вопрос зачем нужны реакт/vue/жс-фреймворки и какую первую задачу они решают? Понятно что всегда можно ответить про сообщество и готовый набор библиотек-компонентов или готовые подходы/архитектуру но это не имеет отношение к технической сути и если не считать критерий производительности (как при сравнении шаблонов так и при вычислении computed/derived-данных) то все то же самое можно построить поверх простого подхода перегенерации верстки через document.createElement (и вычисления всех нужных данных в компонентах-шаблонах)