В статье ставится проблема избыточной сложности использования фреймворка React.js при богатстве его функций, описана возможная тенденция роста технического долга и зависимость между предоставляемыми средствами и величиной технического долга.
Что подразумевается под необоснованной сложностью проектов?
Для начала необходимо отметить, что «React» в отличии от «Vue» предоставляет огромную свободу разработчику. Благодаря этому разработчики любят данный фреймворк и всячески указывают, что приложения на «React» будут быстрее и производительнее чем на «Vue». Это несомненно так, «React» приложения можно сделать быстрым, производительным и легко тестируемым. К сожалению, достичь этого крайне тяжело и из-за этого многие компании могут иметь не высокопроизводительные приложения, а наоборот перегруженные излишним кодом и трудно тестируемые приложения. Это связанно с тем, что начинающим разработчикам сложно понять, как правильно писать приложения на «React».
«React» словно тренер по плаванию, бросает вас в воду и говорит плыви, ему не важно будете вы правильно дышать или махать руками, ему важно чтобы вы плыли. Проецируя данный пример на «React», мы получаем возможность писать очень плохой рабочий код. Особенно это распространено в командах, где нет специалиста по «React». Люди меняются и каждый раз поддерживать приложение все труднее и труднее, кто-то увидел пример в функциональном стиле:
function Counter() {...}А кто-то решил использовать классы:
class Counter extends React.Component {...}Широкие возможности написания «рабочего кода» и отсутствия жесткого контроля кода со стороны руководителей команд разработки могут повлечь за собой переписывание одного и того же функционала. Все это влечет за собой появление так называемых «проектных знаний». «Проектные знания» подразумевают под собой, что разработчик имеет знания, которые невозможно получить из документации или из описания работы приложения. Это крайне важно для компаний и для разработчиков в целом и может повлечь за собой зависимость от этих людей. Данные «проектные знания» крайне нежелательны и могут повлечь за собой убытки со стороны компании, а со стороны разработчиков высокие трудозатраты времени для поддержки и тестирования приложений.
Фреймворк «Vue» имеет свои особенности, данный фреймворк ограничивает возможность генерации HTML путем введения особых атрибутов (директив). Данная особенность имеет положительные стороны. Во-первых, скорее всего скопированный код из интернета будет идентичен всему проекту, во-вторых, разработчикам труднее запутаться и вероятность написания плохого кода значительно снижается. Фреймворк задает свои правила, которым необходимо следовать, а благодаря исчерпывающей и понятной документации, разработчики смогут повысить качество кода и конечного продукта в целом. Во «Vue» структура компонента удобно поделена на HTML, CSS и JS.
<template>
// HTML
</template>
<script>
export default {
data() {
return {
// Свойства
}
}
}
</script>
<style>
// CSS
</style>«Vue» декларативный фреймворк, в отличии от «React» он не говорит «как» генерировать HTML (например при помощи цикла map):
const numbers = [1, 2, 3, 4, 5];
const listItems = numbers.map((number) =>
<li>{number}</li>
);«Vue» говорит «что» (директива v-for) нужно сделать для получения необходимого результата.
<ul>
<li v-for="item in items" :key="item.id">
{{ item.text }}
</li>
</ul>Фреймворк дает все необходимое для разработки, в случае необходимости можно создавать и пользовательские директивы. В большинстве случаев в этом нет необходимости и ограничения фреймворка способствуют лучшей разработке и поддержке конечного продукта. При этом уровень «проектных знаний» существенно сокращается, благодаря чему, новые разработчики смогут быстро вникнуть в работу приложений.
Данная тема достаточна обширна и многие аспекты не были рассмотрены полноценно. Исходя из вышеописанного, можно прийти к выводу что, для компаний, которые часто работают с начинающими разработчиками хорошим решением будет использовать фреймворк «Vue». Это позволит существенно ускорить процесс обучения и дальнейшей разработке, благодаря однообразности кода и хорошей документацией. А также сокращению технического долга при долгой разработке.
В свою очередь «React» следует использовать при наличии грамотных специалистов и налаженной системы контроля за кодом. Из-за своей обширности, богатого функционала и порой сложной в понимании документацией, разработчикам требуется жестко установленные правила разработки и строгой проверки кода со стороны руководителей команд, иначе это может повлечь за собой написание плохого кода и рост технического долга в дальнейшем.
Комментарии (36)
Devoter
16.04.2022 14:17+4Подключаем JSX к Vue и все позитивные моменты React сходят на нет (исходя из текста статьи). Не стоит начинать писать статьи с подобного рода текстов, по моему мнению.
crispart
16.04.2022 14:20+4Похоже на очередную интерпретацию древнейшего холивара «какой язык/фреймворк использовать для проекта?».
И выводы всё те же: «используйте тот, которым умеете пользоваться, а тот, которым не умеете - не используйте». Хотелось бы большего раскрытия темы. Чем фреймворк отличается от библиотеки - понятно было и так. Насчёт производительности, опять же - вопрос крайне спорный.
На Vue тоже можно таких делов наворотить при неумелом использовании - мама не горюй. Там есть, где разгуляться. От проекта к проекту, что я видел, разве, что структура директорий, в целом, схожи, а в остальном - кто во что горазд.
Так в итоге: Vue или React изучать начинающим? И почему? Ожидал увидеть в статье нечто подобное. Какой профит на длительной дистанции можно получить при выборе той или иной технологии?
t0lik
16.04.2022 19:45+2По моим личным впечатлениям во Vue "зайти" проще и что-то начать делать.
crispart
17.04.2022 17:25+1Начать делать «что-то» - да. Речь в статье о длинной дистанции и техдолге. И здесь во Vue есть, где разгуляться. Особенно с появлением третьей версии при близкой к полной обратной совместимостью со второй.
Я и сам люблю Vue, использую его в проектах чаще прочих, но, поверьте, видел всякое. И взаимодействие всех подряд компонентов через стор. И абсолютно запутанные схемы взаимодействия компонентов с помощью EventBus. И бесконечные череды совершенно однотипных props и emits при глубокой вложенности. И ещё многое-многое-многое, что тяжело поддерживать и нужно приводить в порядок.
Процитирую комментатора из ветки чуть ниже:
При этом, если рассматривать рост техдолга, то Vue 3 все же догоняет React. Да, стили и сторы все еще организованы лучше чем React, но вот для разработки компонентов создатели Vue оставили слишком много места. Их теперь можно писать и на JSX, и с render функциями, и темплейты, и с options API, и с setup-функцией, и со script setup.
Всё так. Зайти - проще. Начать делать «что-то» - проще. А вот накопить техдолг - без проблем.
Sway
18.04.2022 01:50Зайти однозначно проще. Я быстро зашел. Но потом так же быстро вышел т.к. Vue 3 + Typescript почти невозможное сочетание. А без Typescript - зачем вообще так жить? После довольно долгих мучений я таки подружил его с Typescript, а потом напоролся на то что часть сторонних библиотек не обновлена под Vue 3 и полностью с ним несовместима. Мне, например, не улыбается самостоятельно велосипедить Bootstrap компоненты, но пришлось бы если б остался. После прототипирования пары страниц я понял что работая с Vue я превозмогаю его, а не использую с удовольствием. На этом я ушел в React и настроил всё что мне нужно было намного быстрее, с меньшей болью и усилиями. Даже удовольствие получил от того что оно "просто работает". Typescript из коробки доступен, всё прекрасно работает в IDE со всеми возможными подсказками включая стили. Добавить react router, i18n, transition и набор бутстраповских компонентов на выбор - и можно работать. Для react есть практически все возможные либы и многие из них поддерживаются на свежих версиях реакта, т.е. есть вполне живая экосистема. Для vue 3 экосистемы за пределами стандартных либ можно считать что нет. Такое чувство было что многие решили не обновлять либы с Vue 2 на Vue 3 из-за довольно объемных изменений в ядре Vue 3. Единственное что мне прямо очень понравилось во Vue - как красиво и удобно реализовано глобальное состояние. Redux, часто используемый в паре с React - это мозговыносящая переусложненная боль прямо. Может для супер больших online+offline проектов оно и оправдано, но у меня проект довольно средненький и я предпочел Modx - как-то он логичнее и понятнее. Тем не менее лучшее решение из тех что я пробовал именно у Vue. Хотя в общем я согласен с автором что React слишком либерален и для совсем кривых рук не подходит - там нужно понимать что ты делаешь. Те же хуки - это прямо кладезь потенциального технического долга. Но при этом и очень мощный инструмент при правильном использовании.
vintage
18.04.2022 05:17
Sway
18.04.2022 16:27Использовать фреймворк не имеющий нормальной поддержки и не получившей её за 4 года существования равносильно выстрелу в голову для руководства. Каким бы ни был прогрессивным фреймворк - если его не используют массово, то он никому не нужен. Ну и синтаксис шаблонов - это отдельный трэш. Шаблоны невозможно понять быстро - они почти полностью нечитабельны. Соответственно нужно вникать в каждую строку и расшифровывать бесконечные спецсимволы, даже если их всего несколько. Это контрпродуктивно как для разработки, так и для поддержки. В добавок нет поддержки со стороны IDE что еще больше усугубляет ситуацию. Я оценил фичи, некоторые действительно крутые, но поймите - как бы Вы не пиарили фреймворк, если его разрабатывает пара человек в свободное время без поддержки со стороны бизнеса, то использование такого фреймворка имеет высокие риски остаться с непопулярным фреймворком наедине. И им придется переписывать проект на что-то другое. Высокие риски допустимы для некоторых стартапов, но не для более-менее крупных компаний. И стартапы тоже предпочтут React/Vue/Angular т.к. у всех у них есть много документации, экосистема, сообщество, разработчики, которых можно нанять. Где вы найдете разработчиков знающих или готовых работать со $smal на замену ушедшему? На рынке сейчас итак недостаток качественной рабочей силы, а тут еще и неизвестный малопопулярный фреймворк. Да все качественные кандидаты просто пойдут к конкурентам после того как ознакомятся со $mol и Вашими статьями в стиле "всё вокруг говно, а $mal лучше всех!". Может и лучше, но почему-то никому не нужен...
mattersj
18.04.2022 11:52т.к. Vue 3 + Typescript почти невозможное сочетание.
А можно конкретный пример, что там такое за "невозможное сочетание"? Очень интересно, с учетом, что весь тулинг вокруг Vue 3 делает упор в первую очередь на TS.
Sway
18.04.2022 13:30К сожалению уже нет конкретного примера. Было это год назад и после того как понял что дело так дальше не пойдет, я удалил всё что там было. Если правильно помню, то проблема там была в том что практически все сторонние либы под Vue не дружили с TS, что делало использование TS болью из declare module. Еще какая-то беда была с первоначальной настройкой TS. Глянул сейчас документацию по активации TS - мне кажется это довольно сложным даже сейчас, когда я намного больше знаю про настройку TS и webpack. С реактом всё как-то сильно проще было.
mattersj
18.04.2022 13:45Глянул сейчас документацию по активации TS
Сейчас, в принципе, никакой активации и не нужно, по умолчанию рекомендуется писать компоненты на script setup, где достаточно поставить
lang="ts"и все, дальше никто ни в чем не ограничивает. Пропсы объявляются через интерфейсы, эмиты тоже, в остальном весь компонент теперь выглядит очень похоже на функциональные компоненты в реакте - те же хуки, только сделанные немного иначе. Помимо этого, в VSCode есть отличное расширение Volar, которое добавляет типизацию даже шаблону (под капотом она основывается на JSX).В общем, с типизацией сейчас едва ли есть какие-то проблемы. Но стоит отметить, что год назад не было script setup и там действительно требовалось чуть больше усилий для типизации чистого Composition API.
Sway
18.04.2022 14:24Вот скорее всего допилили поддержку. Я не помню конструкций вида `lang="ts" ` и `script setup`.
VanishMax
16.04.2022 14:31+6Спасибо за статью. Пишу проекты на разных фреймворках, и каждый раз возвращение к проектам на React сопровождается головной болью.
При этом, если рассматривать рост техдолга, то Vue 3 все же догоняет React. Да, стили и сторы все еще организованы лучше чем React, но вот для разработки компонентов создатели Vue оставили слишком много места. Их теперь можно писать и на JSX, и с render функциями, и темплейты, и с options API, и с setup-функцией, и со script setup.Видимо, начинающему разработчику будет сложно в любом случае, хоть с React, хоть с Vue.
mclander
16.04.2022 15:14+2Когда то так могли написать про ангуляр в сравнении с реактом)
«React» словно тренер по плаванию, бросает вас в воду и говорит плыви, ему не важно будете вы правильно дышать или махать руками, ему важно чтобы вы плыли.
pavel_shabalin
16.04.2022 16:11+4«React» приложения можно сделать быстрым, производительным и легко тестируемым. К сожалению, достичь этого крайне тяжело ...
... Это связанно с тем, что начинающим разработчикам сложно понять, как правильно писать приложения на «React».
... мы получаем возможность писать очень плохой рабочий код.
Даже немного страшно стало.
makar_crypt
16.04.2022 18:57+7vue намного лаконичней . Фронтенд - пишешь как фронтент . А не копаешься в js для составления разметки.
serginho
16.04.2022 20:05+4Это все ерудна. Надо нормально писать и документировать код с увежением к тому, кто будет читать и модифицировать код после тебя. фреймворк неважен.
over_seer
17.04.2022 09:06Я бы выделил ещё один аспект применения того или другого инструмента: кто именно будет взаимодействовать с системой для ввода/вывода информации. Если система предназначена для работы оператора (внутренний пользователь в организации), задача которого ввод информации и принятие решения по результатам обработки, то здесь нет необходимости применять сложные инструменты, как react. А если система предназначена для внешнего пользователя, задача которого получить быстро и удобно нужную ему информацию, и далее минимальным взаимодействием с интерфейсом ввода/вывода, выполнить действие, то здесь лучше использовать такие инструменты как react.
Ilusha
17.04.2022 14:16+2Как показывает практика: оператор системы работает качественнее, если инструмент этому способствует.
В b2c/b2b тоже нет играет роль уже решение проблем, интерфейс - это уже про конкурентное преимущество. Нет большого смысла делать хороший интерфейс, если конкурентов нет и не будет. Зачем вкладываться?
react/vue/etc - это про сложные или потенциально сложные интерфейсы, вне зависимости от их назначения, которое нужно развивать и поддерживать. Когда большую долю сложности забирает на себя библиотека/фреймворк :)
over_seer
18.04.2022 23:03Спорное суждение, по моему мнению, качественная работа оператора не зависит от инструмента, а напротив, зависит от сценариев обработки вводимых данных. Т.е. данная проблема лежит не в плоскости инструментария, а в плоскости дизайна и анализа сценариев работы оператора, а следовательно, с помощью какого инструмента, оператор вводит данные, react это или vue, или jsf, или jquery, или dojo, или excel, не имеет значение ;)
Sway
18.04.2022 02:00Только вот огромные формы со сложными зависимостями полей друг от друга сильно проще делать как раз на Vue/React, а не на чистом js или js + dotJs, например. И дело не в визуальной части а именно в функциональной.
Я на своем проекте оценил насколько проще, быстрее и функциональнее стали формы после переделывания их на React. Это не повод, конечно, специально переделывать то что есть если оно работает и не требует серьезных изменений. Но новый функционал можно довольно эффективно внедрять в уже существующий проект. Если правильно настроить webpack.
over_seer
18.04.2022 22:49Да, nps и его webpack это особая история. Главное, как не ломай его, он будет работать)). Но нет смысла это все разворачивать для оператора, если есть простые инструменты, типа jsf и тому подобное. Где как раз сложные формы неплохо работают в связки полей и т.п.. в том числе где нет необходимости поддержания реактивого вывода данных с использование асинхронного взаимодействия пользовательских интерфейсов с системой обработки данных.
Sway
19.04.2022 00:11Где как раз сложные формы неплохо работают в связки полей и т.п.. в том числе где нет необходимости поддержания реактивого вывода данных с использование асинхронного взаимодействия пользовательских интерфейсов с системой обработки данных.
В моем понимании это как раз и есть сложные формы =) Т.е. форма в которой, например создается родитель и дети, например - опрос с вариантами ответов. Знаю, вариант довольно простой, но бывают даже такие с кучей настроек как у опроса так и у вариантов ответов. Я рассматривал LiveWire как альтернативу, но решил что React меньше будет сервер грузить, да и опыт у меня с ним уже был неплохой. Вообще мне понравилось когда сервер - это просто API, а фронт как бы отдельно от этого всего. Есть в этом что-то правильное.
GothicJS
17.04.2022 09:06Раскройте тему поподробнее, а то действительно как будто введение получилось. И неплохо бы еще увидеть сравнение инструментов из их экосистем, например, vuex vs redux.
kashey
17.04.2022 14:11+1Писал про что-то похожее, примерно теми же словами 5 лет назад - https://blog.cloudboost.io/why-react-is-better-than-vue-js-and-when-9545049652d8
Главная проблема была в том что я думал - «я знаю React» и могу его использовать. Могу честно признать - был не прав.
Aleksandr-JS-Developer
17.04.2022 14:43+2Чтобы сделать хоть какие-то выводы, нужно собрать, обработать и прожить опыт джуна/мидла/синьора на Vue/React. Поруководить командой Vue/React. Позаниматься онбордингом. И много ещё другого. И в самом конце понять, что Vue/React - это разные инструменты, которые решают прблемы по-разному и выбор зависит от проекта, команды, сроков, компании и т. д. Объективные вопросы (производительность, вес, и т. д.) примерно на одном уровне.
Без этого стремится к объективности - просто глупо.
А вот субъективности уже предостаточно.
Моё субъективное по вопросу - С Vue работал (и работаю) гораздо больше, чем с React. Типичный вид компонента React для меня переусложнён излишней писаниной.
Справедливости ради отмечу, что бывал я на проектах, где использовали Vue... как бы выразиться... не зная его и не понимая. Классический проект-тех_долг. Там не осталось ни одного компонента, который можно было бы не трогать при рефакторинге. такое впечатление, что изначально его отдали на аутсорс, там сделали заготовку и дальше свои джуны (штук 5 поочереди) пилили как могли... Лучше уж реализовали на JQ, честное слово...
mattersj
18.04.2022 09:43Во-первых, скорее всего скопированный код из интернета будет идентичен всему проекту
С подключением в 2022 год, во Vue уже давно есть Options API, есть Composition API и есть script setup, поэтому нет.
Вы если уж беретесь сравнивать в 2022 году Vue и React, то стоило бы для начала углубиться в тему и изучить оба инструмента, посмотреть, как сейчас на них пишут и что в них нового.
Итого: поверхностное сравнение уровня 2016 года на 2 минуты чтения. Абсолютно ни о чем.
over_seer
18.04.2022 22:39Поддерживаю ))) "В отличие от моделей работы над более масштабными системами, которыми являются React и Angular, поддержкой Vue, опенсорсного проекта, занимается один разработчик, Эван Ю. Проект финансируется по схеме краудсорсинга. Эван говорит, что это — одна из особенностей проекта, которая отличает его от остальных, так как это вдохновляет на написание кода более высокого качества, чем обычно, и на создание отличной документации."
ExConfessor
Скажу больше: я был уверен, что читаю лишь введение, когда статья вдруг закончилась.
koeshiro
Полностью поддерживаю. Мне казалось что это просто широкие мазки, но это всего лишь один мазок в виде стрелки, не больше.