Изучение различий в пользовательских компонентах даты в Vue.js и ванильном JavaScript.

Недавно у нас была причина переработать способ сбора дат рождения (и других дат в Серафине). Хотя поначалу реализация браузера по умолчанию могла помочь, мы столкнулись с несколькими проблемами:

  1. Реализация не одинакова во всех браузерах.
  2. Большинство браузеров открывали ввод календаря с упором на сегодняшнюю дату, из-за чего нашим пользователям было сложно вводить дату своего рождения.

Мы решили создать наш компонент ввода даты, чтобы исправить это (используя Vuejs).

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

Следовательно, эта серия, вы находитесь в третьей статье, сравнивающей компоненты даты Vue.js и vanilla JavaScript.

В первой части мы рассмотрели, как создать собственный ввод даты в Vue.js.

Во второй части мы рассмотрели, как создать собственный ввод даты с помощью ванильного JavaScript.

Спецификации

Спецификации для нашего компонента DateInput должны вести себя как собственные входные данные даты в браузерах за вычетом выбора календаря, то есть:

  • Мы можем ввести только две цифры для дня и месяца.
  • Мы можем ввести только четыре цифры года.
  • День должен быть между 1 и 31
  • Месяц должен быть между 1 и 12
  • Год должен быть между 1900 и 2100 (это на нас, а не на браузере)
  • Нам нужно вводить даты, набирая цифры напрямую или перемещаясь вверх и вниз с помощью клавиш со стрелками.
  • Если мы вводим даты с помощью клавиш со стрелками и достигаем верхнего или нижнего пределов, отображаемое число должно зацикливаться.
  • Если мы вводим даты, набирая числа, ввод должен быть привязан к марже (max(input, highMargin) или min (input, lowerMargin)
  • Мы должны интуитивно направить пользователя к следующему полю.
  • Мы должны проверить правильность даты.

Предвзятые представления (гипотеза)

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

Я также считал, что «реактивность» страницы будет лучше на Vue, чем на ванильном JavaScript.

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

Выводы

JavaScript и Vue.js имеют схожий опыт разработки.

Я не пытался заставить вещи работать в ванильном JavaScript и мог даже выразить то, что хотел, более кратко (хотя и не полностью рефакторинг).

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

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

реактивность

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

Вес/производительность

С точки зрения веса компонент Vue.js имеет больший вес, но его выполнение выполняется быстрее.

Для нашего компонента Vue.js самая высокая стоимость исходит от chunk-vendors.js и составляет 2,54 МБ, а общая стоимость составляет около 2,66 МБ. Все события DOM (и макет) заканчиваются примерно через 200 мс.

У нашего ванильного компонента JavaScript нет требований к сети, и все выполняется менее чем за 750 мс (все события DOM завершились). Сам файл весит 4,7 Кб.

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

Другие замечания

Еще одна вещь, на которую стоит обратить внимание, это то, что мой компонент Vue.js легче понять, чем мой обычный компонент JavaScript. Я считаю, что это из-за внутренней организации компонентов Vue.js.

Эта неотъемлемая организация упрощает навигацию по ним (если вы знаете, что ищете), чем ванильный Javascript, но я, вероятно, мог бы приложить больше усилий, чтобы мой файл JavaScript был более разборчивым.

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

Наконец, помните, что я закодировал это с помощью Vue 2, а не Vue 3. Тот же пример в Vue 3 может отличаться, если вы используете API композиции в более крупном проекте.

Заключение

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

Я считаю, что это в основном ваш выбор и то, что вам удобнее использовать. Если вы используете ванильный JavaScript, вы можете предъявлять меньше требований к сети, но Vue.js довольно хорошо оптимизирован. Если вам это более удобно, производительность, которая у вас будет, может снизить потенциальные затраты на его использование.

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

Также важно отметить, что вы можете улучшить производительность раздутого приложения Vue.js, немного поучаствовав в нем.