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

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

Зачем мигрировать?

KnockoutJS - отличная библиотека; однако, если приложение достаточно большое / сложное, оно имеет некоторые ограничения:

• это библиотека, а не фреймворк : он предназначен для обработки привязки данных и прочего, оставляя задачу найти подходящие библиотеки или инструменты для обработки многих других вещей (интернационализация, перехватчики жизненного цикла компонентов, сетевые запросы, управление состоянием);
• производительность : современные фреймворки используют новые возможности языка / браузера, недоступные в KnockoutJS; это особенно заметно в длинных / вложенных списках с компонентами, где KnockoutJS, по нашему опыту, может быстро стать невыносимо медленным;
• поддержка и развитие сообщества : KnockoutJS - стабильный фреймворк, что хорошо, но имеет недостаток, заключающийся в том, что многие его ограничения не будут устранены быстро (если вообще будут); Кроме того, интерес сообщества к нему ослабевает, и вместо этого гораздо проще найти ресурсы (статьи, библиотеки / плагины, инструменты) для новых фреймворков.

Критерии выбора (требования)

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

• доступная кривая обучения : это важный аспект, поскольку он позволяет нам сосредоточиться на бизнес-логике, а не на громоздких технических деталях, а также позволяет быстрее ускорить работу новых сотрудников или новых участников любого проекта;
• совместимость : нам необходимо иметь возможность интегрировать новую структуру в различных ситуациях (внутри веб-сайтов клиентов, в качестве отдельного продукта или внутри расширений браузера / мобильных приложений), поэтому нам нужна структура для поддержки нескольких различных сценариев;
• сообщество и поддержка : активное сообщество является требованием для здоровой и развивающейся экосистемы фреймворка, оно снижает вероятность того, что вам придется изменить стек технологий всего за пару лет;
• придерживаться стандартных языков : мы хотим свести к минимуму дополнительные языки и инструменты, придерживаясь стандартного ES6 +; это упрощает нам повторное использование старого кода (что было бы сложно, например, с Typescript) и переход на новый фреймворк при необходимости в будущем.

Экосистема JS невероятно богата библиотеками, фреймворками и даже языками, которые в нее компилируются, поэтому нам нужно было фильтровать потенциальные варианты, не «пробуя их все». К счастью, наши требования помогают в этом. Мы стремимся к простоте внедрения и функциональной совместимости, поэтому такие вещи, как Elm или Svelte , не соответствуют требованиям. Кроме того, библиотеки, подобные Inferno , очень интересны, но они не идеальны для нашего варианта использования, поскольку их сообщество слишком мало, и риск их исчезновения или отказа от их разработки велик. После этих размышлений (и после удаления наших «старых» альтернатив, таких как Ember и Backbone, это не имело особого смысла с точки зрения модернизации), мы остаемся с «большой тройкой» JS-библиотек / фреймворков, которые были оценены более подробно. глубина.

Угловой

Angular - это полнофункциональный фреймворк, цель которого - предоставить разработчику все необходимое для разработки современного веб-приложения (сетевые запросы, управление состоянием, набор инструментов, тестирование). Его упрямый подход означает, что легче (хотя иногда и ограничивает) определить «способ Angular» для выполнения чего-либо, что дает вам четкий способ кодирования и организации вашего проекта. В нем есть Typescript для обеспечения статической типизации, проверки типов и вывода.

В то время как множество функций и инструментов, предлагаемых Angular, интересны, его «монолитный подход» беспокоил нас как с точки зрения производительности, так и с точки зрения сложности. Поскольку все уже включено, проекты, которые уже используют другие библиотеки, могут подвергаться риску включения дублирующих функций (и увеличивать сложность).

Реагировать

React намного легче и тоньше, чем Angular; это библиотека, а не фреймворк, и он передает сторонним лицам такие вещи, как маршрутизация, управление состоянием и сетевые запросы. Это вызывает множество вариантов, но также обременяет разработчика поиском и интеграцией «правильного» плагина / библиотеки для многих вещей, мы бы предпочли более оптимизированное решение. Его также труднее всего изучить из-за подхода к функциональному программированию и использования JSX вместо старого простого HTML. Также стоит упомянуть, что во время нашего оценочного периода React также входил в сферу лицензирования FUD (бояться неопределенности и сомнений).

Vue

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

Выбор

Как вы уже догадались, мы остановились на Vue.js, поскольку его сильные стороны лучше соответствуют нашим требованиям, а его недостатки не слишком актуальны для нас. Итоги нашей оценки Vue.js:

• большая производительность, чем у KnockoutJS (спорный вопрос в сравнении - React и Angular здесь тоже хороши);
• он разработан для интеграции в другие реализации и постепенного внедрения;
• у него лучшая кривая обучения по сравнению с преимуществами, которые он приносит;
• в то время как сообщество меньше, чем у React и Angular, оно является самым быстрорастущим , что заставляет нас меньше беспокоиться о том, что его бросают или не хватает опций библиотеки / плагина.

Через несколько месяцев после усыновления

С Vue было приятно работать: он «заставляет» вас писать и четко организовывать код, он очень доступен и хорошо интегрируется с нашими существующими базами кода. Нам очень понравился подход «однофайловый компонент», который позволяет нам сохранять наш код как можно более компактным, не распределяя его между файлами CSS, JS и HTML.

Аспекты, которые беспокоили нас больше всего, связаны с инструментами: поскольку отдельные файловые компоненты требуют, чтобы вы писали файлы .vue вместо «стандартных» .js, нам было сложно настроить параметры с помощью eslint, babel, различных инструментов документации и автоматизации. . Варианты, предоставленные сообществом, оказались недостаточно хорошими, и мы были вынуждены внедрять собственное решение чаще, чем мы прогнозировали. Примером является подход, который мы используем для документации: такие вещи, как Vue Styleguidist , великолепны, но слишком ограничивают - сейчас мы тестируем гибридное решение на основе JSDoc ( documentation.js ) для синтаксического анализа и Vuepress, чтобы создавать фактическую документацию в красивой и настраиваемой форме. .

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

Несмотря на эти «проблемы», мы очень довольны своим выбором. Мы с нетерпением ждем возможности учиться и получать больше удовольствия от работы с Vue.