Join Yalantis and get a $1000 sign-in bonus! React.js, React Native, Python, Java, DevOps, BА. Apply now!
×Закрыть

Почему Vue.js — отличный выбор для веб-проектов и как он обошел React

Меня зовут Сергей Лысенко, и я Front-end разработчик в компании TemplateMonster. В этой статье расскажу о том, как мы переводили основной сайт templatemonster.com с React на Vue.js, почему приняли такое решение и каких результатов достигли. Материал будет полезен всем, кто интересуется фреймворком Vue.js, заботится о производительности своего сайта и хочет сделать взаимодействие посетителей с ним максимально легким и быстрым.

С чего все началось

В мае 2020 года Google Chrome Team объявили о добавлении целого ряда показателей, связанных с быстродействием, отзывчивостью и визуальной стабильностью веб-страниц. Новые метрики назвали Core Web Vitals. С их помощью разработчики сайтов могли измерять и анализировать пользовательский опыт. В основу метрик вошло три основных показателя:

  • LCP (Largest Contentful Paint);
  • FID (First Input Delay);
  • СLS (Cumulative Layout Shift).

LCP в отличие от FMP (First Meaningful Paint, или первое значимое отображение) является временем, когда браузер заканчивает отрисовку самого большого визуального блока на странице. Считается, что хороший показатель — это всё, что находится во временном интервале до 2,5 секунды.

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

CLS — показатель, измеряющий визуальную стабильность страницы. Это сумма относительных смещений всех визуальных составляющих веб-страницы на протяжении всего её жизненного цикла.

Сразу же после этого заявления в блоге Search Console вышла статья, в которой описывался процесс включения новых метрик в основной алгоритм ранжирования Google-поиска. И вот спустя 6 месяцев в очередной публикации объявляется, что с мая 2021 года эти изменения вступают в силу. Для пользователей Google-поиска это означает, что они будут получать в выдаче наиболее качественные ресурсы, а для владельцев сайтов — что при, условно говоря, одинаковой SEO-оптимизации выше в выдаче окажутся те ресурсы, у которых показатели Web Vitals лучше.

Мы с командой приняли решение подготовить наш основной сайт к грядущим изменениям заблаговременно и летом 2020 года начали работу над его новой версией. На тот момент ресурс использовал React как основную библиотеку для отрисовки вeб-страниц. И, несмотря на то, что DX (Dev Experience) был на высоком уровне, UX (User Experience) оставлял желать лучшего. Для любого маркетплейса важно, чтобы сайт был максимально адаптирован для поисковых машин (с точки зрения SEO), поэтому для первоначальной отрисовки страниц использовался подход SSR (Server-Side Rendering, или рендеринг на стороне сервера).

После загрузки всех необходимых ресурсов браузером начинался процесс так называемой регидратации (rehydration), когда фреймворк сравнивал HTML-код, который отдал в ответе сервер, с состоянием текущего посетителя и при необходимости вносил правки в разметку страницы.

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

Среди других сложностей, с которыми постоянно боролись:

  • слишком большой размер DOM-дерева из-за частого «оборачивания» компонентов в дополнительные контейнеры;
  • огромный JSON-объект в HTML-ответе от сервера для обеспечения регидратации страницы;
  • выделение браузером большого количества памяти на первоначальную отрисовку и дальнейшую перерисовку некоторых компонентов;
  • очень высокий TTI (Time to Interactive, или время, за которое страница становится интерактивной для посетителя);
  • постоянно возрастающая сложность поддержки кодовой базы и так далее.

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

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

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

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

Таким инструментом для нас стал Vue.js.

Почему Vue.js

Решение использовать этот фреймворк не было спонтанным или основанным на личных предпочтениях кого-то из разработчиков. Стоит отметить, что на тот момент ни у кого из членов команды даже не было опыта работы с Vue.js. Но этот фреймворк располагал целым рядом преимуществ, которые были важны при выборе инструмента для будущей версии сайта:

  • возможность работы с существующим DOM-деревом;
  • наличие директив для расширения возможностей работы с DOM-деревом;
  • относительно небольшой размер;
  • наличие большого количества готовых дополнительных библиотек;
  • низкий порог входа для разработчиков.

Возможность работы с существующим DOM-деревом

Это одна из ключевых особенностей фреймворка и один из самых важных факторов, повлиявших на окончательный выбор. Если у вас есть уже готовая HTML-разметка, которую вернул сервер, вы можете без труда использовать ее с помощью компилятора Vue.js. В этом случае достаточно инициализировать приложение на самом верхнем DOM-элементе и фреймворк возьмет всю внутреннюю разметку в качестве основного шаблона для вашего приложения. К сожалению, используя другие популярные инструменты, это не получится сделать с той же легкостью. С помощью Vue.js можно удобно взаимодействовать с разметкой страницы и легко добавлять необходимые интерактивные компоненты или дополнительную функциональность.

Директивы для расширения возможностей DOM-дерева

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

Относительно небольшой размер фреймворка

Vue.js, несмотря на все свои возможности, имеет наименьший размер JavaScript-кода среди «большой тройки» (Angular, React и Vue.js). Даже старый добрый jQuery обойдется вам «дороже».

Источник

Для сравнения: React последней версии весит всего 7 кБ в минифицированном виде, но обязательная зависимость в виде react-dom принесет в JavaScript-бандл еще 121 кБ.

Дополнительные готовые библиотеки

У фреймворка их много. Если вам понадобится удобное управление состоянием приложения, у Vue.js есть для этого готовое решение в виде библиотеки Vuex. Её размер всего 12 кБ в минифицированном виде, но преимущества неоспоримы. С ее помощью легко создать централизованное хранилище всех необходимых данных и состояний приложения и получить к нему доступ из любой его части. Единое хранилище можно использовать даже для обмена данными между отдельными приложениями, которые были запущены на одной странице (через инициализацию нового экземпляра Vue.js на отдельных корневых DOM-элементах). Именно такой подход мы применили на некоторых типах страниц сайта для еще большего их облегчения. Сократили время, которое необходимо фреймворку для компиляции шаблона страницы.

В арсенале Vue.js есть официальный роутер Vue Router, набор инструментов для разработчиков Vue CLI, а также Vue Devtools для ускорения разработки и отладки приложений.

Низкий порог входа для разработчиков

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

Над чем еще работали

Стоит отметить, что сильное влияние на производительность, быстродействие сайтов и приложений оказывает количество подключенных систем аналитики и разнообразных маркетинг- и SEO-инструментов. Мы используем Google Tag Manager, и не трудно представить, насколько просто с его помощью можно добавить огромное количество тегов и потерять над ними какой-либо контроль. Поэтому во время разработки нового сайта мы пересмотрели все используемые теги и провели их глобальную зачистку и оптимизацию:

  • все ненужные теги удалили;
  • все теги, которые синхронно подключали исполняемые файлы, перевели на асинхронную загрузку;
  • отложили запуск тегов, которые не являются критически важным в первые мгновения после загрузки страницы.

В результате всех вышеперечисленных действий получили неплохой прирост в показаниях инструмента PageSpeed Insights, подняв оценку на 10–15 пунктов.

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

Результаты

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

  • показатель PageSpeed Insights;
  • размер DOM-дерева;
  • суммарный размер загружаемой страницы и в особенности размер JavaScript-бандла;
  • отзывчивость интерфейса, в частности на мобильных устройствах;
  • нагрузка на сервер.

Показатель PageSpeed Insights и размер DOM-дерева

Вот таких изменений в баллах инструмента PageSpeed Insights удалось достичь сразу же после запуска новой версии сайта:

На графике представлены несколько типовых ключевых страниц сайта, таких как главная страница, каталог, страница продукта и так далее. Слева заметен значительный рост оценки, которую нашему сайту выставляет PageSpeed Insights. В правой части изображения представлены графики сокращения размера DOM-дерева, на котором видно, что для некоторых страниц количество DOM-элементов сократилось в два раза. Стоит отметить, что большое влияние на финальные оценки все еще оказывают оставшиеся теги из Google Tag Manager, от которых совсем не просто отказаться.

Суммарный размер загружаемой страницы

Размер страниц даже с учетом всех third-party скриптов также стал значительно меньше. Это ускорило загрузку сайта, что особенно заметили посетители, которые используют мобильные устройства или не очень быстрый интернет-канал.

Если же учитывать размер только JavaScript-бандла, который загружался при посещении главной страницы сайта, то его удалось сократить в 11 раз (с 845 кБ до 76 кБ в сжатом виде).

Отзывчивость интерфейса, особенно на мобильных устройствах

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

До перехода на новую версию:

После перехода на новую версию:

Нам удалось достичь четырехкратного роста для показателя First Contentful Paint, а Time to Interactive сократился в три раза.

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

Нагрузка на сервер

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

Вывод

Мир не стоит на месте, и посетители сайтов, пользователи веб-приложений и даже поисковые машины предъявляют все более высокие требования и ожидания к качеству продуктов. Но не стоит этого бояться, ведь в результате всевозможных оптимизаций все стороны оказываются в выигрышном положении. Количество инструментов и техник, которые позволяют к этому прийти, растет с каждым годом. Не бойтесь внедрять что-то новое, не бойтесь иногда ломать старое и проводить эксперименты!

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

Підписуйтеся на Telegram-канал «DOU #tech», щоб не пропустити нові технічні статті.

👍НравитсяПонравилось30
В избранноеВ избранном6
Подписаться на тему «frontend»
LinkedIn

Похожие статьи



58 комментариев

Подписаться на комментарииОтписаться от комментариев Комментарии могут оставлять только пользователи с подтвержденными аккаунтами.

Назва надто клікбейтна. Як на мене приріст вам дала чистка авгієвих конюшень тагманагера. Очікував якихось технічних моментів, а так.... різниця описана в кількох маленьких абзаців така сама як в типових статейках джунів про порівняння 3 фреймворків в 2021 році..

Весьма странные выводы вы сформировали после прочтения. В статье описано значительно больше, чем просто чистка конюшен GTM (Google Tag Manager). Да, чистка тегов GTM дала прирост, но если сравнивать именно оценки PSI старого и нового GTM, то они совсем незначительно отличаются в пользу нового. Все основные теги остались и они все еще влияют на производительность сайта, но все же чистка была проведена и объемы сторонних скриптов сократились. Основной прирост был из-за изменения архитектурного, если можно так выразиться, подхода. Жаль что у вас сложились такие впечатления от статьи :)

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

Angular теж підтримує SSR (в рамках Angular Universal)

Простите, но не совсем понял к чему вы написали о SSR. Насколько я знаю, его поддерживают все основные игроки на рынке JS фреймворков.

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

Я правильно понимаю что у вас до это было SPA и вы перешли SSR?
Как вы оцениваете насколько именно этот фактор повлиял на улучшение производительности?

Не совсем так. У нас и React был с SSR и последующей «регидрацией» на клиенте. А сейчас мы генерируем все страницы на сервере и добавляем только необходимую функциональность в ряде мест на сайте с помощью JavaScript (небольшие компоненты и директивы). Это и привело, по моему мнению, к максимальному приросту в производительности. Спасибо за вопрос :)

Не побачів якісних аргументів на користь переписування проекту саме на ву. Якісно отрефакторити на реакті імовірно було б швидше =дешевше в кілька разів. Ну, перевчили команду на ву за рахунок компанії... Особисто я Із статті я бачу, що найбільший приріст отримали з оптимізації сторонніх сервісів. Так треба було цього починати і тоди можна було хоч якось порівнювати «чистий код». Повелися на хайп і заголовок хайповий. Може ву дійсно краще, але питання з заголовку не розкрито.

В статье я и не призываю переписывать что-либо на Vue. Я лишь рассказал об опыте нашей команды, описал свои впечатления от фреймворка и показал как он помог, конкретно в нашем случае, улучшить сайт. Что бы это увидеть достаточно почитать статью. Или было бы лучше если бы заголовок гласил «Почему Vue.js — отличный выбор для веб-проектов и как он обошел React конкретно в нашем случае»? :)

Саме так, до статті у мене претензій меньше ніж до заголовку ))
Взагалі я вважаю що реакт вигадали рептілоїди для знищення людства. Це взагалі. Але в кожному кокретному випадку треба спиратися на затрати/очикувані результати/можливості команди/бюджет і не вестись на хайп. Реакт також починався з таких заголовків, як він там шось в тисячи разів прискорив.

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

На скриншотах вы приводите статистику по PageSpeed Insights по дням. Подскажите пожалуйста как и чем вы ее собираете?

Автоматизированные тесты запускаются несколько раз в сутки. Одной из задач тестов является замер фактических показателей PSI. Тесты сохраняют полученные данные в базу данных, а дальше, с помощью инструмента DataStudio от Google (datastudio.google.com), усреднённое значение выводится в виде постоянно обновляющегося графика. Это позволяет очень наглядно отслеживать изменения показателей после внедрения любых модификаций на сайте.

Не знаю як було раніше, але зараз все літає :) суб’єктивно якісно зроблено
цікаво, як довго писали першу версію на реакті?

Да, спасибо, мы старались сделать так что бы именно «летало» у посетителя и пока не так сильно гнались за показателями PSI.
Сложно ответить о точных сроках реализации версии на React, ее разработка длилась больше года. Да и не совсем корректно сравнивать сроки разработки двух версий, так как в прошлой версии сайта было куда больше логики на фронтенде.

Досвід дійсно корисний.

Рад, что оказался полезен.

Переехать на новый фреймворк с нуля за 3 месяца — впечатлило! 🤘

То-есть вместо оптимизации React приложения (на крайняк что-то типа Next.js с SSG старницами для SEO страниц) сразу перелезли на Vue... Специалисты, чо :)

К сожалению, ограничения в роутинге Next.js не позволяли нам использовать этот замечательный инструмент. Да и генерация нескольких миллионов SSG страниц при сборке билда — наверное, то еще удовольствие :)

Ну минут 30 от силы. В общем несколько раз в день можно спокойно релизиться :)

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

У вас сейчас на главной под мобайл аж 49/100 :( А стоит просто отложено загурузить LiveChat и аналитику — все станет топчик

P.S. Как вы теперь без Брауна то? Никому не икается? :)

Сейчас npm build со всеми оптимизациями занимает немного больше 2-х минут, включая установку пакетов (это время пайплайна GitLab, не локальная сборка). Вы же предлагаете решение, которое будет собирать минут за 30 (приводя, на мой взгляд, очень позитивные прогнозы времени).
Кроме Google Page Speed Insights (PSI) есть еще целый ряд важных для конечного посетителя показателей (скорость первой отрисовки, объемы загружаемых данных, количество памяти которая выделяется вкладке браузера, влияние на энергопотребление устройства на котором пользователь взаимодействует с сайтом или приложением и т.д.).
Да и начал я своё объяснение с ограничений в роутинге Next.js (я очень люблю этот фреймворк, но он действительно не подходил для решения нашей задачи). Статья ведь вовсе не о том, что один фреймворк лучше другого, а о том что некоторые инструменты больше подходят для решения конкретных задач.
Спасибо за советы по возможной оптимизации аналитики но, к сожалению, отложить аналитику настолько, что бы она перестала оказывать влияние на показатели PSI не представляется возможным.
Не уверен как ответить на ваш последний вопрос и как он связан со статьёй, поэтому оставлю его без ответа ;)

Я знаю несколько статик генераторов которые вообще не требуют никакого фреймворка

Даже react-snap, не смотря на название, билдит что угодно, а не только реакт :)

Из минусов SSG/statics: параметры гугл-аналитики и прочих скриптов «хардкодятся» Приходится их добавлять уже после загрузки страницы... Но так гуглю даже больше нравиться :)

В общем Vue или React — разницы нет, с Ангуляром все в разы хуже :(

А еще ж есть AMP....

А что конкретно хуже с ангуляром?

Только SPA, статик рендеринг сделать тяжело, для SEO почти ничего нет...

А так все норм, во внутри корпоративных приложениях прижился, ибо все ходят строем и тестами все покрыто по дифолту.

SEO и SPA это вообще интересная комбинация ))) Тесты это хорошо, если сделано с умом, и для статики есть angular.io/guide/universal

nextjs.org/...​ental-static-regeneration
а вот nuxt так не может, так же как и gatsby
и еще вот
nextjs.org/...​n-is-fallback-true-useful
fallback: true is useful if your app has a very large number of static pages that depend on data (think: a very large e-commerce site). You want to pre-render all product pages, but then your builds would take forever.
как решение

ну если глянуть на то что блокинг тайм 3+ сек, явно что-то криво подключали
а вобще не важно какой фреймворк юзать все они быстрые, просто нужно все оптимизировать gzip, lazy loading для картинок и тд

Согласен, отличная функциональность (я о Incremental Static Regeneration). Но она появилась в версии 9.5, которая вышла в конце июля 2020 года, когда мы были уже в production с новой версией сайта. Страницы продуктов часто меняются, ввиду того что авторы изменяют описания, всевозможные свойства или же попросту выливают новую версию. Ну и вопрос с крайне ограниченными возможностями роутинга все еще остается открытым, к сожалению. Ведь смысл статьи не в том что нужно выбросить React и заменить его на Vue, а в том что в некоторых случаях лучше глобально изменить выбранный подход в разработке ;). Vue был выбран на смену React исходя из описанных в статье причин.

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

Зумери придумали jQuery

Я вряд ли могу претендовать на звание зумера ;)

Дорогой автор, как уже было прекрасно подмечено, основной профит был в переписывании с нуля. Все те же метрики поддерживаются реактом... Я думаю, что если бы вы решили уменьшить свою криворукость в том же самом переписывании с нуля на том же самом фреймворке — получили бы похожую картину.

Спасибо за конструктивный отзыв на статью и критику моих рук. Если я в какой-то части статьи задел ваши чувства или обидел ваш любимый фреймворк — прошу прощения.

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

Я сам бекендер. Сейчас увеличил долю в одной онлайн игре и загорелся идеей улучшить там все. Думаю на каком фреймворке сделать с нуля редизайн фронта. Заодно одними махом решить многие проблемы старого фронта, поскольку он реально крайне стар.

В последнюю неделю определился более явно в сторону React. Убедило большое сообщество и популярность. По сути все мои знакомые фронты имели опыт именно в этом фреймворке. И тут я увидел данную статью.
Теперь опять в раздумьях, что лучше взять React или Nuxt (Vue).
Ох и изменчиво у вас во фронте...
Если у вас есть какие-то мысли по этому поводу буду очень рад узнать.

Из моих наблюдения, на Vue намного легче начать писать и деливерить фичи (особенно бекендеру). Но большее количество магии в сравнении с React на долгой дистанции усложняет поддержку. Если у вас относительно небольшой проект то Vue доставит много радости, для чего-то крупного рекомендую смотреть в сторону React/Angular + Typescript

Угу, ясно Фронт часть я точно не буду делать. Разве что в api получаствую. Буду нанимать фрилансера. Как понял любой из фреймворков будет хорошим выбором и я особо не ошибусь для начала с 0.

+ по поводу большого количества магии не понял. Тут имеется ввиду какая-то скрытая функциональность фреймворка, хуки или синтаксический сахар?..

Сахар. Кроме сахара во Vue нет никакой магии. Вот только зачем жить без сахара, если можно жить с сахаром? Тем-более что учится он за 2 дня и дальше никаких вопросов не создает даже у джунов.

Sergey Lysenko, Lev Davydov, Dmytro Svyrydenko Благодарю за помощь)

А що в Vue ви вважаєте магією?

Похожих показателей производительности можно достичь используя практически любой современный фреймворк. Все дело в специфических требованиях, которые по разным причинам может предъявлять ваш проект. Если вам, как и в нашем случае, нужны «вкрапления» дополнительной функциональности в разных местах сайта — не уверен что React вам сможет в этом помочь. Разработчикам, которые приходят из бекенда, я не рекомендую начинать с React, так как придется принимать очень большое количество решений относительно всех дополнительных библиотек, которые будут необходимы (если у вас есть достаточное количество времени для подобных исследований npm пакетов — то я не вижу в этом проблемы). Если же у вас приложение, render которого происходит полностью на фронтенде — подойдет любой фреймворк, с которым у вас есть хоть какой-то опыт или к которому лежит душа. Под магией Vue скорее всего подразумеваются миксины, директивы, вычисляемые свойства и т.д. — достаточно взглянуть на руководств Vue что бы увидеть разнообразие полезных дополнений, которые предлагает этот фреймворк: ru.vuejs.org/v2/guide/index.html.

мне кажется, что основной профит был от переписывания с нуля, а не от использования вью

Совершенно верно. Именно по этой причине в статье описаны те возможности, которые предоставил Vue.js как фреймворк в ходе переписывания сайта с нуля, используя совершенно другие подходы в разработке.

заметил, что при разработке react приложений приходится писать намного больше кода, чем если бы это был vue.

React ведь всего-лишь отличная библиотека для отрисовки разметки в зависимости от переданных свойств (и для достаточно быстрой её перерисовки). Vue.js, в этом плане, больше похож на фреймворк, так как «из коробки» содержит в себе достаточное количество вспомогательных дополнений и готовых решений. У Vue.js есть ряд готовых пакетов для решения самых частых проблем, которые возникают при разработке приложений или сайтов. При использовании React вам предоставляется бОльшая свобода выбора, но цена поддержки такого зоопарка библиотек, в некоторых случаях, может оказаться слишком высокой.

Если писать React без TypeScript то кода будет гараздо меньше чем для Vue :)

А багов будет гораздо больше :)

Это фронтенд, тут всем все пофик ;)

Отучаемся говорить за всех :)

Ну так про всех начал :) У меня на JS будет меньше багов чем у кого-то на TS...

В смысле пофиг? А как твоё приложение работать то будет, постоянно красная консоль?

Так же как и все остальное в интернете :)

Хз с какого места руки должны быть чтобы без тайпскрипта сразу красная консоль

бомба, супер, спасибо! особенно за конкретные метрики

Рад, что статья оказалась полезной :)

Подписаться на комментарии