Frontend Project от начала до конца

Привет, Ник Барт, я опытный разработчик полного цикла, работающий по контракту с Braingineers. Раньше я создавал и поддерживал производственные приложения Vue и React, но в этом проекте у меня была возможность создать два приложения одновременно. Я подумал, что это будет забавная возможность сравнить два самых популярных фреймворка с точки зрения разработчиков.

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

Внутренняя оснастка? Не заботитесь о стиле? Большой старый CRUD? Реагировать.

Я решил использовать React для внутреннего инструментария, так как экосистема была более зрелой, и мы будем сильно полагаться на библиотеки, в частности, на material-ui. Не имея никаких проектов и реальных требований, кроме стандартных операций CRUD, я принял решение не оставлять никаких сомнений и позволить себе управлять арендаторами Material Design.

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

Обработано? Для клиентов? Pixel Perfect? Vue.

Vue был выбран для клиентского приложения; Поскольку я работал со всеми примитивами пользовательского интерфейса, мне нужна была гибкость и точность. Нам повезло с красивым дизайном, любезно предоставленным Sander Crombach, и, короче говоря, мы хотели, чтобы он выглядел фантастически.

Хотя стиль может быть идеальным как для Vue, так и для React, я обнаружил, что с собственными системами Vue гораздо приятнее работать. Тот факт, что мы писали весь наш пользовательский интерфейс, означал, что мы могли спокойно игнорировать большую экосистему готовых библиотек компонентов, которые есть в React. Это означало, что мне нужно было быть осторожным при создании итеративной и поддерживаемой кодовой базы, для которой самоуверенный подход Vue больше подходил.

Ниже мы сравним некоторые аспекты наших двух проектов.

Секрет успеха в том, чтобы начать. Установите сейчас!

Поскольку нам не требовалось SEO и не было проблем с производительностью, я не смог найти убедительных аргументов в пользу использования Nuxt.js или Next.js. Я придерживался классики как для Create-React-App, так и Vue CLI. Оба являются многофункциональными автономными инструментами для соответствующих фреймворков. Оба предлагают простые и необязательные заранее подготовленные конфигурации, которые практически полностью сокращают время настройки проекта. Оба решения CLI предлагали мне отличные стартовые комплекты и документацию для начала, и, поскольку проект никогда не становился достаточно сложным, мне никогда не приходилось извлекать Create-React-App.

Я использовал Netlify для развертывания разрабатываемых версий обоих приложений, которые без проблем интегрировались с поставщиком SaaS. Оба проекта были запущены в среде разработки примерно за 10 минут.

Как работать с каталогом проекта

Vue

components
routes
layouts
directives
filters
store

В моей папке src у меня было на несколько папок больше, чем было бы в React, из-за упрямого подхода Vue к служебным функциям, которые разделены на директивы и фильтры. Мне не понадобилось больше пяти из них. Маршруты содержат представления с логикой выборки требуемых данных. Компоненты были моей самой большой папкой с 54 подпапками, так как я написал свою собственную библиотеку компонентов. Мы использовали Storybook для управления всеми этими компонентами.

Реагировать

components
routes
hooks
utils

Наше приложение React имело значительно меньший размер папки, так как мы могли втиснуть все в утилиты и хуки, поэтому единственное, что осталось, - это наша маршрутизация и компоненты. Папка компонентов также была довольно ограниченной по размеру, так как мы использовали такую ​​всеобъемлющую библиотеку в material-ui.

Радовать дизайнеров и разработчиков системами стилей

Vue

В своих компонентах я использовал свой любимый стек CSS.

Хотя охват CSS во Vue достаточно прост, я поддерживал дисциплину в отношении БЭМ, поскольку считаю, что это лучший опыт разработчика при попытке отладить проблемы с CSS.

Однако в своих маршрутах я решил использовать Однофайловые компоненты Vue (SFC). Поскольку мои маршруты имели ограниченный и повторяемый стиль, я попробовал эти отдельные файлы, и, к моей радости, это сработало превосходно! Меня беспокоила большая длина файла, однако flex-box или CSS-сетка были самой большой частью CSS, которую я в конечном итоге написал в этих файлах.

Удерживая компоненты небольшими по размеру, мы уменьшили большую часть головной боли при написании БЭМ, а то, что осталось, убирается с помощью удивительного трюка SASS, который должен быть встроен в CSS!

Реагировать

Текущее (было несколько перебоев) решение для стилизации пакета Material-ui - это решение CSS-in-JS. Как и большинство внешних интерфейсов, я пишу большую часть своего CSS в браузере, и изменение синтаксиса вызывает разочарование при копировании и вставке, это может показаться произвольной проблемой, но это значительно уменьшило мое удовольствие от стилизации.

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

Хотя реализовать другую систему было достаточно просто, я хотел дать им шанс на стиль. Однако я не думаю, что мне снова понравится использовать CSS-in-JS без очень правильного варианта использования.

Маршрутизация и управление состоянием, также как и сохранение области видимости

Vue

Приложение Vue находилось за экраном авторизации, поэтому первым делом нужно было настроить Vuex и VueRouter. Я стараюсь, чтобы мое глобальное состояние было как можно более легким, поэтому в конечном итоге я сохранил только auth и еще один часто используемый бит пользовательской информации в магазине. VueRouter широко использовался и очень любим - его документация была безупречной, его Navigation Guards просты и чрезвычайно полезны. Четкая маршрутизация на основе вложенных массивов VueRouter более понятна и намного опережает декларативный подход, представленный в ReactRouter.

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

Реагировать

ReactRouter, теперь в версии 5.x, был аморфной сущностью в течение последних 5 лет моего опыта разработки. Текущая документация написана не в идеальной песочнице, однако, я думаю, что реальная слабость кроется в ее декларативном характере.

Его декларативный характер способствует его маршрутизации, разделенной на несколько файлов в вашем приложении, вместо централизованного компонента маршрутизации. Использование нескольких разных маршрутизаторов не дает никаких преимуществ перед VueRouter - и приводит к более запутанной и фрагментированной кодовой базе. Кроме того, мне не нравится смешивать логику маршрутизации с JSX, и я считаю, что картина намного яснее при работе с простыми массивами javascript для описания отношений маршрутизации.

React реализовал несколько нативных попыток избавиться от необходимости в огромных библиотеках Redux, React прибил это с помощью React Context. Это было пустяк, команда React проделала отличную работу по реализации собственной альтернативы глобальному управлению состоянием.

Опыт разработчика или: Как я научился не беспокоиться и полюбил Framework

Vue

Самоуверенный способ реализации SPA в Vue действительно улучшил мой опыт создания этого приложения. Я всегда знал, откуда берутся каждый файл, маршрут, строка CSS, фильтр, директива и метод. Благодаря этому принудительному формату очень легко структурировать ваше приложение так, чтобы его было удобно поддерживать. Я обнаружил, что единственное место, где мне нужно было поддерживать жесткую дисциплину, - это писать БЭМ CSS.

Обо всех остальных архитектурных решениях за меня позаботился сам Vue. Это достойный похвалы способ создания приложений, поскольку он приведет к стандартизированному подходу во всем мире. Эта стандартизация как документации, так и реализации очень способствовала моей продуктивности и удовольствию от работы над моим приложением Vue.

Реагировать

Поистине дикий запад, все можно сделать, как угодно, с чем угодно. Крошечный API React обеспечивает очень разнообразный ландшафт реализаций. Поскольку я использовал сборную библиотеку компонентов, я позволил библиотеке принимать за меня как можно больше решений, что немного снизило нагрузку на выбор.

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

Чтобы создать приложение, нужна целая деревня, экосистема npm

Vue

Поскольку я вручную катал большинство своих компонентов, меня не беспокоила относительно небольшая и молодая экосистема Vue. Оказалось, нормально. Я пытался ограничить количество используемых мной внешних пакетов; в итоге потребовалось 17 пакетов. Несмотря на то, что все они в конечном итоге работали, средняя оценка и частота коммитов в этих сторонних библиотеках были намного ниже, чем у их аналогов React. От диаграммных библиотек с отсутствием коммитов в течение нескольких месяцев до окна выбора со 120 открытыми проблемами - во Vue выбор библиотек с открытым исходным кодом - гораздо менее упорядоченный процесс, чем выбор React, основанный на популярности.

Документация по всем библиотекам была единообразной, насколько они прекрасны. Благодаря VuePress большая часть документации стандартизирована и эффективна. Это был приятный сюрприз, потому что я никогда не видел такого в другой экосистеме.

В целом экосистема Vue оказалась лучше, чем я ожидал.

Реагировать

React предлагает на выбор огромное количество мощных библиотек с открытым исходным кодом! В основном я выбрал React из-за простоты и удобства использования Material-ui. В итоге я использовал 20 пакетов для своего проекта React. Документация варьировалась от отличной (material-ui) до совершенно убогой (react-router).

Опять же, фрагментированный характер React приводит к трудностям с поддержанием хорошей документации, требуя отдельной документации для хуков и компонентов класса. Даже вопросы stackoverflow превратились в множественные ответы из-за колебаний в управлении версиями.

Развитие React, значительно улучшив опыт разработчиков внутри их IDE, резко снизило качество документации и самих библиотек, которые теперь вынуждены поддерживать как хуки, так и компоненты классов или отстают.

Хотя накладные расходы были огромными, React движется в правильном направлении, и я приветствую смелость их нового направления.

То, что мне интересно. Но было слишком трусливо, чтобы пытаться.

Из-за ограниченного объема этого проекта я не упомянул несколько процессов и технологий в названии shippin ’it. TypeScript, который я использовал в предыдущих проектах React, и, не считая некоторой кривой обучения, мне очень понравилось пользоваться его функциями. Однако меня беспокоит, что из-за более слабой экосистемы Vue определения не будут столь же легкодоступными, я бы хотел, чтобы кто-нибудь сообщил мне о своих результатах использования TypeScript и Vue.

Тестирование - это еще один аспект, под которым мне не удавалось сравнивать фреймворки, потому что я не проводил тестирования на протяжении всего процесса разработки. И Create-React-App, и Vue CLI имеют встроенные средства тестирования, с которыми я хотел бы поэкспериментировать. Пожалуйста, дайте мне знать ваше мнение!

Мне интересно узнать о возможностях Vue рендеринг на стороне сервера. Поскольку я использовал как Next.js, так и Razzle.js, а также развернул собственное универсальное приложение, я понимаю и уважаю трудности поддержки SSR в среде React, и мне очень любопытно посмотреть, как Nuxt.js Обрабатывает одну из самых недружелюбных технологий, с которыми сталкивается интерфейс.

Заключение

В битве React против Vue, какая разница! Эти фреймворки могут сосуществовать, концептуально они почти идентичны, реализация и синтаксис составляют большинство различий между ними. Краткое описание преимуществ каждого из них:

Vue

  • Мнения (поэтому стандартизованная) реализация
  • Единая документация
  • VueRouter
  • Встроенная поддержка перехода

Реагировать

  • Зрелое и надежное сообщество с открытым исходным кодом
  • Рост собственной библиотеки, т.е. ловушек и контекста
  • Переносимые навыки, gatsby.js

Мне было приятно создавать и поддерживать оба приложения. С точки зрения опыта разработчиков, я считаю, что решающим фактором был уровень обработки. Создание (и, следовательно, знание) всех моих компонентов создало три отдельные точки воздействия.

  • Знание компонентов внутри и снаружи. Если что-то пошло не так, я обычно мог очень точно оценить, где и что не удалось. Я знал, какие инструменты у меня были в наличии, без необходимости консультироваться с документацией.
  • Все было именно так, как я хотел, например CSS-in-JS просто сводится к предпочтениям, а я предпочитаю разделение задач. Выбирая такую ​​обширную библиотеку компонентов, как Material-ui, вы вынуждены работать в рамках своей системы.
  • Ответственность за управляемый продукт полностью ложится на вас или вашу команду. Во время работы над проектом React мне пришлось сделать 4 проблемы и 1PR для отдельных библиотек, что замедляло скорость разработки и полагалось на команды, не заинтересованные в помощи. Все проблемы, возникающие в моем продукте Vue, касались исключительно меня.

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