Rivalry2

HTML Diff

1 added 1 removed

Original 2026-01-01

Modified 2026-02-21

1 <a>#Мнения</a>

2 <ul><li>29 апр 2022</li>

3 <li>0</li>

4 </ul><h2>Что такое фреймворк и как выбрать фреймворк для фронтенда: советы бывалых</h2>

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

6 Иллюстрация: Simon Lee / Unsplash / Bhalej / Walcker / Cleanpng / Adrian Ciurea / Turbosquid / Themes.getbootstrap / Meery Mary для Skillbox Media

7 Фанат Free Software Foundation, использует Linux и недолюбливает Windows. Пишет истории про кодинг и программы на Python. Влюблён в Lisp, но пока что не умеет на нём программировать.

8 Фреймворк - это программная платформа, которая упрощает разработку программного продукта, определяет структуру проекта и помогает удобно объединять в нём разные компоненты.

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

10 <h2>Что такое фреймворки и чем они отличаются от библиотек и паттернов проектирования</h2>

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

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

13 Фреймворки иногда путают с библиотеками и паттернами проектирования. Но разница между ними существенна.

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

15 А фреймворки накладывают достаточно жёсткие рамки на правила проектирования программы. К тому же внутри фреймворка может быть много разных библиотек. Примеры библиотек: jQuery и React (да-да, это именно библиотека).

16 Паттерн проектирования- это просто абстракция, схема, метод решения проблемы, который помогает правильно выстроить программный продукт. Нередко в основе фреймворков лежит какой-то паттерн проектирования - например, Django, Laravel и Ruby on Rails реализуют<a>модель MVC</a>(Model-View-Controller).

17 MVC помогает разделить логику приложения на три независимых части:

18 <ul><li>Model. Получает данные от контроллера и выполняет необходимые операции и передаёт их во View.</li>

19 <li>View. Получает данные от Model и отправляет их пользователю в удобном виде.</li>

20 <li>Controller. Обрабатывает действия пользователя, проверяет данные на входе и передаёт их в Model.</li>

21 </ul>Magento Tech Lead Front-End at Overdose

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

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

24 Примеры веб-фреймворков (для фронтенда и бэкенда):

25 <ul><li><a>Ruby on Rails</a> - фреймворк, написанный на Ruby для разработки веб-приложений.</li>

26 <li><a>Laravel</a> - PHP-фреймворк для создания веб-приложений.</li>

27 <li><a>Symfony</a> - PHP-фреймворк для создания веб-приложений.</li>

28 <li><a>Svelte</a> - фреймворк на JavaScript для создания веб-приложений.</li>

29 <li><a>Django</a> - фреймворк для веб-приложений на Python.</li>

30 <li><a>Bootstrap</a> - фреймворк для создания сайтов и веб-приложений на базе HTML, CSS, JavaScript. Иногда его называют библиотекой, но корректнее относить его к фреймворкам.</li>

31 <li><a>Angular</a> - основанный на TypeScript фреймворк для создания веб-приложений. Курируется Google и особенно популярен в корпоративной среде.</li>

32 <li><a>Vue.js</a> - JavaScript-фреймворк для создания пользовательских интерфейсов.</li>

33 </ul>Популярность веб-фреймворков и библиотек среди профессиональных программистов в 2021 годуИнфографика:<a>Stack Overflow</a>разработчик из Amazon, живёт в Эдинбурге, Великобритания. Автор Telegram-канала<a>Coding interviews</a>

34 В разработке интерфейсов каждый программист сталкивается с похожими задачами:

35 <ul><li>Как сделать переходы между разными экранами при изменении URL в строке браузера без перезагрузки страницы?</li>

36 <li>Как получать данные от API?</li>

37 <li>Как динамически обновлять интерфейс в ответ на действия пользователя?</li>

38 <li>Как разделить данные и представление, чтобы можно было рисовать различные части интерфейса по одним и тем же данным?</li>

39 </ul>В принципе, никто не мешает решать эти задачи в лоб, то есть применительно к конкретному интерфейсу, а не в целом. Однако у такого подхода есть большой минус - каждый новый проект никак не использует опыт предыдущих. Снова те же баги, снова те же фиксы. Было бы неплохо написать и протестировать некоторую базу один раз, а потом переиспользовать её во всех проектах.

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

41 Иногда слово "фреймворк" понимают в узком смысле - как некоторую библиотеку и набор инструментов, с помощью которых как раз и разрабатывается приложение; а иногда в широком - как некую архитектуру приложения, которой придерживаются разработчики конкретного продукта в команде. Я предпочитаю разделять эти понятия.

42 Фреймворк решает типовые задачи и не знает о бизнес-области, в которой применяется: React, Angular, Vue.js - то, что поможет организовать роутинг (где-то как часть оригинального фреймворка, а где-то - как стороннее решение поверх, но не так важно), разделение моделей (данных) и вьюшек (шаблоны), перерисовку частей интерфейса при изменении данных.

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

44 Исторически сложилось, что мой родной фреймворк - Vue.js. Легковесный, простой, подробно документированный, со множеством коробочных решений - отлично подходит для стартапов, любых MVP, с крупными проектами тоже справится отлично при умелом обращении.

45 С выпуском третьей версии пришло много улучшений, но были и проблемы: для SSR-проектов удобно использовать Nuxt, но Nuxt 3 пока слишком далёк от production-ready-состояния - и неясно, когда он там окажется. Так что либо живёшь с Nuxt на Vue.js 2, либо решаешь задачи с SSR без Nuxt.

46 Искать разработчиков под Vue.js непросто, что нужно учитывать при планировании проекта (если у вас долгострой и надо набрать пять человек, будет больно). Если проект необходимо собрать быстро и нет планов по кратному масштабированию команды, то Vue.js - идеальное решение, на мой взгляд.

47 В "МойОфис" я сейчас работаю на React - этот фреймворк как будто чуть более требователен к уровню разработчика, документирован чуть хуже, зато у него очень большое и активное сообщество. А ещё он отлично подходит для монструозных долгостроев, нет проблем с масштабированием, он упоминается в большом количестве вакансий и используется многими разработчиками - что хорошо и для бизнеса, и для соискателей вроде бы. С другой стороны, из-за обилия вакансий искать разработчиков и масштабировать команду не сильно проще, чем в случае с Vue.js.

48 С технической точки зрения в React.js мне не очень нравится уход в функциональные компоненты, но в остальном это мощный, контролируемый, популярный инструмент. Ну и круто, что есть React Native, а значит, можно в родном стеке собрать мобильное приложение приемлемого качества (у Vue.js есть Vue Native, но на деле это просто надстройка над React Native, что меня в итоге не впечатлило).

49 Из новых фреймворков я бы обратил внимание на Svelte, который, по сути, является компилятором: ни виртуального DOM, ни фреймворка в рантайме - интересный сдвиг парадигмы. Близко ещё его не смотрел, вакансий не видел, но, насколько успел понять, Ozon уже мигрирует на Svelte с Vue.js. Так что технология явно заслуживает внимания.

50 руководитель фронтенд-направления глобальной IT-компании<a>SimbirSoft</a>

51 SimbirSoft - сервисная компания, поэтому на практике у нас всегда есть три варианта развития событий.

52 1. Заказчик приходит с готовым требованием того или иного фреймворка. Это происходит в том случае, если у него, например, есть команда на поддержку.

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

54 - 3. Заказчик просит нас провести анализ и понять, на каком фреймворке лучше сделать IT-продукт. В большинстве случаев это React, поскольку в будущем окажется проще найти разработчиков для поддержки проекта, а сама разработка получится менее затратной в сравнении, например, с Angular.

54 + 3. Заказчик просит нас провести анализ и понять, на каком фреймворке лучше сделать IT-продукт. В большинстве случаев это React, поскольку в будущем окажется проще найти разработчиков для поддержки проекта, а сама разработка получится менее затратной в сравнении, например, �� Angular.

55 Есть несколько критериев выбора фреймворка/библиотеки: масштабность проекта, прозрачность и понимание функциональных возможностей, которые нужно реализовать, наличие специалистов на рынке и уровень их экспертности.

56 Для enterprise-проектов с большой долей вероятности подойдёт Angular. Если будущая бизнес-логика ещё не до конца известна, лучше обратить внимание на React.

57 Мы в SimbirSoft ведём несколько проектов, которые по масштабности не уступают крупным проектам на Angular, но пишутся на React, так как заказчик сразу обозначил, что требования могут изменяться в процессе и необходима гибкость в разработке. А поскольку React - это всё же библиотека, а не фреймворк, он эту гибкость предоставляет.

58 Для MVP хорошо подойдёт Vue.js. Но если нет свободных специалистов, React тоже прекрасно справится с этой задачей.

59 Мы уверены, что в ближайшее время React, Vue.js и Angular останутся актуальными. На наш взгляд, уделять время изучению устаревших фреймворков, например jQuery и AngularJS (не путайте с Angular), нужно только в особых случаях - скажем, если вы работаете с легаси-проектом, на котором были использованы эти технологии.

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

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

62 фронтенд-разработчик и преподаватель

63 Расскажу о разнице между React, Solid, Vue.js, Web Components и Svelte. Важное замечание: все они поддерживают TypeScript.

64 <a>React</a> - не совсем фреймворк, его принято относить к библиотекам.

65 Плюсы:

66 <ul><li>Стандарт де-факто в индустрии - очень большое сообщество, есть что угодно на любой случай.</li>

67 <li>Небольшое количество концепций - проще выучить.</li>

68 <li>Минималистичность и универсальность - можно скрестить с чем угодно.</li>

69 <li><a>JSX</a> - текущий стандарт для шаблонизации (собственно, он и стал таковым благодаря React), поддерживается всеми инструментами.</li>

70 <li>С <a>MobX</a>React становится похож на урезанный Vue.js.</li>

71 </ul>Минусы:

72 <ul><li>Из-за минималистичности и того, что это библиотека, а не фреймворк, приходится выбирать, как именно его "готовить": обилие библиотек и подходов порождает проблему выбора.</li>

73 <li>Производительность на среднем уровне, и за ней нужно хотя бы изредка следить - как минимум встречаются лишние<a>ререндеринги</a>компонентов.</li>

74 <li>Концепция<a>хуков</a>слегка костыльна - необходимо вручную отслеживать зависимости (но это решается, например, тем же MobX).</li>

75 <li>Работа с состоянием классовых компонентов тоже не слишком интуитивна из-за асинхронности (и нереактивности React).</li>

76 <li>В принципе, легко затянуть глобальное состояние внутрь компонента и потом с болью его оттуда выдирать - приходится внимательно следить за архитектурой. Это тоже следствие отсутствия "фреймворковости".</li>

77 </ul>Плюсы:

78 <ul><li>У <a>Vue.js</a>хорошая производительность благодаря встроенной системе<a>реактивности</a>и компилятору шаблонов.</li>

79 <li>Минимум<a>бойлерплейта</a>(причина та же, что и в пункте выше).</li>

80 <li>Расширенная функциональность для работы с компонентами или<a>DOM</a>: сигналы, слоты, директивы.</li>

81 <li>Фреймворк от создателей идёт в комплекте по необходимости - хорошая модульность.</li>

82 <li>Более простой аналог хуков в виде<a>setup-функции</a> - не нужны зависимости (тоже благодаря реактивности).</li>

83 <li>Есть поддержка стандартного JSX.</li>

84 <li>Большое сообщество.</li>

85 <li>Систему реактивности можно использовать и отдельно - по аналогии с MobX.</li>

86 </ul>Минусы:

87 <ul><li>Необходимо понимать принципы реактивности - отличается от традиционных библиотек наподобие<a>RxJS</a>.</li>

88 <li>Из-за языка шаблонов сложнее синтаксис: поддерживается инструментами хуже, чем JSX, - специфичен для Vue.js.</li>

89 <li>Сложнее интегрировать с другими подходами по управлению данными из-за наличия<a>preferred way</a>.</li>

90 <li>В целом достаточно большое количество концепций, из-за чего выучить его сложнее.</li>

91 </ul>Далее идут уже менее распространённые библиотеки.

92 <a>Solid</a> - это React плюс MobX минус Virtual DOM.

93 Библиотека с очень интересной концепцией - полностью построена на реактивности, как и Vue.js, при этом работает без<a>Virtual DOM</a>, но с JSX. Сложнее React, зато одна из самых быстрых - потому что работает напрямую с DOM, изменяя только необходимые её части, которые выявляются в момент компиляции JSX и отслеживаются с помощью реактивности. Сообщество пока крайне маленькое, но сама идея очень примечательна и может перерасти во что-то большее. Поддерживает все фичи React.

94 <a>Svelte</a>чем-то похож на Solid: его шаблоны и код компилируются на этапе сборки, выдавая очень близкий к оптимальному код, как если бы его писали вручную. В плане концепции и синтаксиса Svelte сильно отличается от обычных библиотек, которые работают в рантайме. Скорость условно на уровне React и Vue.js, но запускается быстрее. Уже есть небольшое сообщество.

95 Это<a>фреймворк от GitHub</a>. Можно писать и на чистом JS или TS, используя веб-компоненты, - таким путём идёт сам GitHub. Сильная инкапсуляция компонентов через Shadow DOM (что влечёт и свои проблемы - например, глобальные стили придётся подключать в каждом компоненте) и максимальная нативность.

96 Но это не решает многие проблемы, при которых всё равно необходимо использовать сторонние библиотеки. Например, для того же хранения глобального состояния GitHub даже сделал свой<a>набор утилит</a>для разработки.

97 разработчик из Amazon, живёт в Эдинбурге, Великобритания. Автор Telegram-канала<a>Coding interviews</a>

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

99 Имеет смысл выбрать любой и инвестировать своё время и силы в изучение и работу с конкретным фреймворком. Что, на мой взгляд, действительно важно при выборе фреймворка, так это сообщество. Чем оно больше, тем лучше. Потому что от этого напрямую зависит качество документации, количество вопросов-ответов на Stack Overflow, полезных решений с открытым исходным кодом вокруг фреймворка.

100 Расскажу о своём опыте. Мы с командой пилим проект, посвящённый подбору тренеров по большому теннису, -<a>40-30.ru</a>. Пока успели доделать анкеты, форму регистрации и чаты между клиентами и заказчиками.

101 Вообще, мы нередко делаем сайты на CMS - например, том же WordPress. И по сравнению с разработкой на CMS фреймворки - это дорого и долго.

102 Однако у CMS, хотя они тоже в каком-то смысле являются фреймворками, есть ограничения - на них сложно собирать кастомные решения, многое упирается в стандартные функции. Например, всё очень непросто с разработкой личных кабинетов: если вам нужны ЛК с кучей сценариев, CMS такой проект вытянуть не смогут. А с фреймворком мы можем сделать то, что захотим, - и тут нас ограничит только наша фантазия и знания.

103 Изначально я планировал собирать проект на Laravel. Хороший PHP-фреймворк - даже некая экосистема. Но я не стал рисковать, поскольку проект у нас планируется серьёзный: как Profi.ru, только с фокусом на большом теннисе. Ещё мне все советовали React, объясняя, что на нём, в принципе, сейчас и делают все сложные проекты.

104 Однако я пообщался с разработчиком, и в итоге мы выбрали Angular - фреймворк, разработанный Google. На моё решение повлияли два момента:

105 <ul><li>Мне интересен новый опыт.</li>

106 <li>В команде есть человек, который отлично разбирается в Angular.</li>

107 </ul>Frontend Developer в LightBox. Увлекается игровой индустрией, любит путешествия, Vue.js и картографические JavaScript-библиотеки

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

109 Три самых важных и популярных в последние несколько лет фреймворка: React, Vue.js и Angular. Каждый из них имеет свои особенности, но в целом все они справляются со своей главной задачей на отлично. Безусловно, существуют и другие фронтенд-фреймворки, но я предположу, что более 95% проектов и вакансий содержат требования именно по этим мастодонтам.

110 Важные критерии для выбора фреймворка - наличие разработчиков и порог входа.

111 Количество вакансий. Если мы заглянем на один из самых популярных сайтов по поиску работы в РФ, hh.ru, и выберем Россию, то на 29 марта 2022 года увидим 4463 упоминания React в вакансиях, 2157 упоминаний Vue.js, 1883 упоминания Angular. Этот топ-3 прекрасно отражает популярность фреймворков в России на текущий момент.

112 Времена величия и популярности Angular в странах СНГ постепенно уходят, хотя он и занял свою нишу - большие и серьёзные финтех-проекты. Поэтому зачастую немалая часть Angular-проектов - это поддержка легаси-кода, хотя, конечно же, и новые проекты иногда решают делать на Angular. Этот фреймворк также горячо любим многими разработчиками, имеет свой особый путь и философию и очень контрастирует с React и Vue.js.

113 Порог входа.Angular достаточно "тяжеловесный" во всех смыслах этого слова - плюс у него довольно высокий порог входа. Для контраста: Vue.js можно освоить за один день на уровне, достаточном для написания простенького проекта, - и даже начать выполнять простые задачи на более крупном проекте. React по сложности занимает промежуточное положение между Angular и Vue.js.

114 Производительность.С точки зрения производительности React и Vue.js одинаково хороши, а Angular немного отстаёт.

115 Мобильная разработка.В экосистеме React есть технология React Native, которая позволяет создавать мобильные приложения, используя ту же самую React-модель - это даёт React дополнительный балл. У Vue.js подобная технология тоже есть, но такого широкого применения она не получила - хотя и используется в некоторых проектах.

116 Популярность на Западе.Уместно будет сравнение российского рынка с западным, в частности с США. Я, как Vue-разработчик, столкнулся с тем, что на Vue.js работу в США найти крайне сложно и большинство вакансий с требованием Vue.js в США - это работа в очень маленьких стартапах (менее пяти человек) с отсутствием адекватного финансирования.

117 Я пользовался множеством ресурсов для поиска работы в США, но, как правило, самым действенным всегда был LinkedIn. Если мы заглянем в LinkedIn и выберем United States, то на 29 марта 2022 года увидим 142 565 упоминаний React, 77 556 упоминаний Angular и всего лишь 17 294 упоминания Vue.js. React лидирует с большим отрывом, а Vue.js с таким же большим отрывом отстаёт.

118 Примечание: числа с LinkedIn и hh.ru - не количество вакансий, а количество упоминаний технологии в вакансиях. Например, можно встретить Angular, React и Vue.js в одной вакансии - порой работодателю достаточно, чтобы вы знали хотя бы один из фреймворков, если вы готовы освоить нужный уже в процессе работы. Тем не менее на больших цифрах статистика упоминаний показывает вполне достоверный результат.

119 В итоге я прошёл несколько десятков собеседований и убедился на практике: всем нужен React - от крупных корпораций до небольших стартапов. При этом популярность React в США только растёт. Такая же тенденция прослеживается и в странах СНГ, хотя тут серьёзно растёт и популярность Vue.js.

120 Свои личные проекты я стараюсь делать на Vue.js - он прост, комфортен для разработки, субъективно привычен, имеет эталонную документацию и замечательное комьюнити. Однако на работе я использую React. В результате получается своего рода круговорот: чем больше компаний предлагают работу на React, тем больше разработчиков станут его учить. И чем больше разработчиков будут знать React, тем больше компаний будут начинать или даже переписывать проекты на React.

121 Также я заметил, что в США даже многие крупные проекты написаны на "ванильном" JS (+ jQuery), а компании нанимают сотрудников, чтобы переписать их на один из фреймворков. И какой фреймворк они обычно выбирают? Правильно, React. Поскольку на React можно найти больше квалифицированных разработчиков. В результате имеем то, что имеем: React в США стал практически стандартом индустрии. Несмотря на огромную любовь к Vue.js, изучить React пришлось и мне :)

122 руководитель группы разработки интерфейсов складов "Яндекс.Маркета"

123 Дело было так: сначала кассы писались на React и всё шло хорошо. Но в какой-то момент мы поняли, что не дотягиваем по перформансу - нужно было оптимизировать добавление товара в корзину до 200 мс. Мы исследовали разные способы оптимизации, но всё было тщетно.

124 И тут я прочитал статью, в которой были бенчмарки Svelte. Когда мы занимались профилированием, то поняли, что выходили за рамки по оперативной памяти - разрабатывали мы под старенький IBM. Было решено в качестве эксперимента попробовать написать маленькую часть приложения на Svelte.

125 Сравнивали по следующим показателям:

126 <ul><li>Оперативная память: React - 5 МБ, Svelte - 3 МБ.</li>

127 <li>Скорость добавления товара в корзину: React - 120 мс, Svelte - 20 мс.</li>

128 <li>Общая производительность: гоняли в девтулзах профайлер.</li>

129 <li>Помимо всего прочего, смотрели на DX и скорость разработки - и здесь Svelte тоже опережал React :)</li>

130 </ul>В итоге всё приложение для операторов и касса самообслуживания были сделаны на Svelte. Но это были другие времена, мы были молодые и беззаботные, а сейчас алгоритм выбора фреймворка у меня примерно следующий:

131 <ul><li>Понять, насколько просто нанять разработчиков. Основной рынок - это React и Vue.js.</li>

132 <li>Если у вас уже есть команда - понять, на чём сотрудники уже умеют писать и готовы ли переучиваться на что-то новое.</li>

133 <li>Если вы эксперт в каком-то из фреймворков - нужно понять, есть ли у вас время на обучение новых разработчиков (но, опять же, смотрите пункт 1).</li>

134 <li>Сравнить фреймворки по синтетическим бенчмаркам (например,<a>вот этим</a>).</li>

135 <li>Сравнить DX в разных фреймворках.</li>

136 <li>Понять, есть ли нужные для вас библиотеки в выбранном фреймворке.</li>

137 <li>Понять, подходит ли вам парадигма данного фреймворка - возможно, какие-то вещи в нём будет сложно реализовывать или вам нужна реактивность (подробнее можно почитать в статье на <a>dev.to</a>).</li>

138 <li>Посмотреть: возможно, в вашей компании уже есть много библиотек под определённый фреймворк.</li>

139 </ul>Ну, и обобщённый совет: фреймворк - лишь инструмент, под каждый проект можно выбирать свой на основе того, что нужно для выполнения требований, что удобно для вас как для команды и что нравится конкретно вам. Хотя, конечно, можно писать всё на React (но лучше так не делать).

140 <a>Научитесь: Профессия Фронтенд-разработчик + ИИ Узнать больше</a>