(Эта статья изначально была размещена на https://sgoel.dev.)
VueJS в последнее время получает довольно много внимания прессы. По большей части это люди, которые зарабатывают на жизнь написанием кода внешнего интерфейса. Вместо этого я провел большую часть своей профессиональной жизни, работая с серверным кодом и кодом инфраструктуры, поэтому считаю себя новым участником мира JS. У меня есть некоторые воспоминания о написании JS, но они восходят к тем временам, когда Rails 2.3 был еще новым, а jQuery был горячей новинкой. Это означало, что в те дни вы могли добавить тег скрипта, обернуть все вокруг $(document).ready, и никто бы не поднял бровь.
Конечно, с тех пор характер и сложность разрабатываемых приложений изменились. Простых обратных вызовов сейчас недостаточно, и нам нужны более сложные инструменты для выполнения работы. Существуют сотни фреймворков и множество других руководств, в каждом из которых рассматривается своя перестановка фреймворков / инструментов. Но я думаю, что хуже всего то, что каждый проект утверждает, что делает что-то лучше, чем любой другой проект. А как новичок в экосистеме вы не знаете, кому доверять и как узнать. Возможно, это тоже способствует утомлению Javascript.
Многие люди приводят всевозможные технические причины, по которым Vue лучше X. Я не буду этого делать. Отчасти потому, что сравнительное руководство Vue это уже делает. И отчасти потому, что я считаю, что каждый проект лучше, чем любой другой, поскольку он обслуживает хотя бы один вариант использования. Так что сравнивать инженерные подходы кажется неправильным. Вместо этого я перечисляю 3 основные причины нетехнического характера, по которым мне нравится работать с Vue.
Познавательная нагрузка
Фреймворки должны облегчить вашу жизнь, предоставляя вам набор инструментов, а затем позволяя думать о логике вашего приложения. Для меня это похоже на причину существования фреймворков. И чем ниже площадь поверхности API (насколько интуитивно понятен API, это может быть другая метрика вместо площади поверхности), тем легче держать все это в голове. Это, в свою очередь, освобождает ваш мозг для размышлений о реальной проблеме. И это как раз первая причина, по которой мне нравится Vue. Сам по себе API крошечный. У вас есть HTML-представления, свойства data, methods и computed. Вот и все. Вы можете просмотреть документацию менее чем за полдня и в основном начать писать код приложения.
Решения
Мы принимаем решения весь день, и каждое принимаемое нами решение требует умственных усилий. Я часто замечал, что чем больше решений я должен принять, тем хуже моя способность принимать больше решений. В наши дни JS-фреймворк должен предоставлять больше, чем просто уровень представления. Тот факт, что Vue предоставляет «официальные рекомендации» о том, какое программное обеспечение выбрать и как настроить инструменты для организации конвейера сборки, экономит мне так много токенов решений. Для новичка может быть очень сложно настроить весь процесс сборки до того, как даже написать код приложения. И если фреймворк вам в этом поможет - отлично!
Нет строгого соблюдения
Третья и немного техническая причина заключается в том, что Vue позволяет моему приложению развиваться. Каким-то образом он попадает в золотую середину между добавлением обратных вызовов к страницам, отображаемым на стороне сервера, и полноценным веб-сайтом SPA. Я могу подтянуть его к концу jQuery и просто добавить тег скрипта и написать небольшую логику, которая синхронизирует одни элементы с другими. И когда сложность моего приложения возрастет, я также могу переместить фреймворк в сторону React и организовать все вокруг компонентов, чтобы внести некоторую разумность. С самого начала ничего не навязывается. Эволюция полностью органична.
В конце концов, все мы хотим решать проблемы. Ваше приложение может всегда быть лучше с инженерной точки зрения. Но найти эту золотую середину, когда она достаточно хорошо спроектирована и одновременно решает потребности бизнеса, может быть непросто. И каким-то образом Vue помог мне добраться туда быстрее, чем что-либо еще. Нельзя сказать, что это недостижимо с использованием других фреймворков. В основном это сводится к выбору правильного инструмента для работы с учетом ограничений контекста.
