От автора: как веб-разработчик, я стараюсь регулярно оценивать свой инструментарий и определять, могу ли я обойтись без того или иного инструмента. Недавно я исследовал, насколько легко разрабатывать сложные приложения без front-end фреймворка JavaScript.
Что такое JavaScript-фреймворк?
В общем, JavaScript-фреймворк — это инструмент, который вы можете использовать для разработки современных веб-приложений, особенно SPA.
В свое время веб-разработчики реализовали логику интерфейса, полагаясь в основном на vanilla JS и jQuery. Но по мере того, как приложения становились все более и более сложными, инструменты для решения этой проблемы стали развиваться.
Популярные на сегодняшний день фреймворки имеют несколько основных общих черт. Большинство интегрированных сред / библиотек, от Vue до React, предоставляют некоторую комбинацию следующего:
Синхронизация состояния и представления
Маршрутизация
Система шаблонов
Многоразовые компоненты
Фреймворки все еще необходимы?
Это зависит от. Многие утверждают, что front-end фреймворки не нужны и никогда не были нужны. Другие — что это очень полезные инструменты. Итак, вопрос в том, являются ли фреймворки jQuery сегодняшнего дня? Будут ли они решать важные проблемы?
Трудно сказать, но прогресс нативного JS, спецификации веб-компонентов и легко настраиваемые инструменты сборки сделали разработку SPA без фреймворка простой, как никогда ранее.
Чтобы изучить это глубже, я разработал одностраничное приложение, использующее только стандартный JavaScript, нативные веб-компоненты и Parcel. В процессе возникло несколько сложностей, которые подчеркивали сильные стороны JS.
В то же время, когда я преодолел эти препятствия, я был удивлен тем, насколько просто создать одностраничное приложение с использованием только vanilla JS.
Обзор
Приложение очень просто. Это приложение рецептов с основными возможностями CRUD. Пользователь может создавать, редактировать, удалять, добавлять в избранное и фильтровать список рецептов.
Главный экран
Экран создания рецепта
Компоненты
Создание веб-компонента также просто. Вы создаете класс, который расширяется HTMLElement (или HTMLParagraphElement и так далее), а затем используете этот класс для определения пользовательского элемента.
Вы также можете использовать хуки жизненного цикла, такие как connectedCallback, disconnectedCallback, attributeChangedCallback.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 |
import template from './recipe.html' import DATA_SERVICE from '../../utils/data' export default class Recipe extends HTMLElement { constructor () { // прилагаем shadow DOM, инициализруем закрытое свойство recipe и инициализируем сервис данных super() this._shadowRoot = this.attachShadow({ mode: 'open' }) this._recipe = null this.ds = new DATA_SERVICE() } connectedCallback () { // устанавливаем html-контент для ипортируемого шаблона this._shadowRoot.innerHTML = template // прилагаем метод delete для удаления кнопки this._shadowRoot .querySelector('.delete') .addEventListener('click', () => this._delete()) } _render (title) { // устанавливаем заголовок рецепта и текст кнопки "в избранное" this._shadowRoot.querySelector('.recipe-title').innerHTML = title this._shadowRoot.querySelector('.favorite').innerHTML = this._recipe .favorite ? 'Unfavorite' : 'Favorite' } _delete () { // Удаляем рецепт или выводим ошибку try { await this.ds.deleteRecipe(this._recipe.id) } catch (e) { console.error(e) alert( 'Sorry, there was a problem deleting the recipe. Please, try again.' ) } } get recipe () { // геттер для рецептов return this._recipe } set recipe (recipe = {}) { // сеттер для рецептов, который запускает метод render this._recipe = recipe this._render(this._recipe.title) } } window.customElements.define('recipe-item', Recipe) |
Компонент My Recipe Item для отображения рецептов в списке
Маршрутизация
Маршрутизация для приложения рецептов также довольно проста. Учитывая событие навигации, я установил для содержимого приложения соответствующий веб-компонент.
Первоначально я использовал npm-пакет под названием Vanilla JS Router. С помощью API истории браузера не так уж и сложно реализовать собственный контент менее чем в 100 строках кода! Примечание: я не реализую действительно сложную логику, такую как гард маршрута.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 |
import './components/error/error' import content404 from './components/404/404.html' import DATA_SERVICE from './utils/data' const ds = new DATA_SERVICE() // получаем элемент, содержащий SP const $el = document.getElementById('app') // определяем маршруты const home = async () => { await import('./components/recipe/recipe') await import('./components/recipe-list/recipe-list') await import('./components/modal/modal.js') $el.innerHTML = `<recipe-list></recipe-list>` } const create = async () => { await import('./components/create-recipe/create-recipe') $el.innerHTML = `<create-recipe></create-recipe>` } const edit = async () => { await import('./components/edit-recipe/edit-recipe') $el.innerHTML = `<edit-recipe></edit-recipe>` } const error404 = async () => { $el.innerHTML = content404 } // сопоставляем маршруты с путями // захватываем рецепт по параметру id для маршрута редактирования const routes = { '/': home, '/create': create, '/error': error404, '/edit': async function (params) { const id = params.get('id') const recipe = await ds.getRecipe(id) await edit() $el.querySelector('edit-recipe').recipe = recipe } } // для состояния pop получаем параметры из url и передаем в маршрут // если таких маршрутов нет, ошибка window.onpopstate = async () => { const url = new URL( window.location.pathname + window.location.search, window.location.origin ) if (routes[window.location.pathname]) { await routes[window.location.pathname](url.searchParams) } else routes['/error']() } // для состояния pop получаем параметры из url и передаем в маршрут // если таких маршрутов нет, ошибка // добавляем маршрут в историю браузера let onNavItemClick = async pathName => { const url = new URL(pathName, window.location.origin) const params = url.searchParams if (routes[url.pathname]) { window.history.pushState({}, pathName, window.location.origin + pathName) await routes[url.pathname](params) } else { window.history.pushState({}, '404', window.location.origin + '/404') routes['/error']() } } // устанавливаем соответствующий маршрут для загрузки / перезагрузки страницы ;(async () => { const url = new URL( window.location.pathname + window.location.search, window.location.origin ) if (routes[window.location.pathname]) { await routes[window.location.pathname](url.searchParams) } else routes['/error']() })() // экспортируем маршрута и метод клика nav const router = { onNavItemClick, routes } export { router } |
Я хочу сохранить размер этой статьи в разумных пределах. В последующих статьях я могу привести более подробные объяснения. Я реализовал несколько забавных функций, таких как бесконечная прокрутка, пользовательский перетаскиватель и многое другое!
Переосмысление
После создания приложения мне потребовалось некоторое время, чтобы подумать о плюсах и минусах всего процесса от начала до конца. Начну с плохих новостей.
Минусы
Спецификация все еще развивается
Спецификация веб-компонентов является и старой, и новой. Она используется уже намного дольше, чем я первоначально думал. Веб-компоненты были впервые представлены Алексом Расселом на конференции Fronteers 2011. Тем не менее, за последние год или два, их востребованность существенно возросла. Таким образом, в спецификации все еще много неразберихи. Например, импорт HTML является устаревшим, хотя большая часть документации / ресурсов по-прежнему ссылается на него.
Тестирование
Существует не так много выделенных ресурсов для тестирования нативных веб-компонентов. Есть несколько многообещающих инструментов, таких как skatejs ssr и web component tester от Polymer. Но эти инструменты на самом деле предназначены для использования с соответствующими библиотеками. Это создает некоторые трудности для их использования с нативными веб-компонентами.
Обнаружение изменений
Наличие базовой системы, автоматически поддерживающей синхронизацию представления с моделью данных, невероятно. Это то, что в первую очередь привлекает многих в Angular и других фреймворках.
Поддерживать синхронизацию состояния с представлением не так сложно в небольшом масштабе. Но все может очень быстро выйти из-под контроля, и вы обнаружите, что добавляете множество прослушивателей событий и селекторов запросов.
Shadow DOM
Я действительно в растерянности по поводу Shadow DOM. С одной стороны, мне нравится идея инкапсуляции. Это разумный шаблон проектирования, который делает каскад стилей более управляемым, упрощает задачи и так далее. Однако это также создает проблемы, когда вы хотите, чтобы определенные вещи проникали в эту инкапсуляцию (например, разделяемая таблица стилей), и о том, как лучше всего это сделать, ведутся постоянные споры.
Генерация структур DOM
Часть великолепия фреймворков / библиотек, таких как Angular и React, заключается в том, что они работают со своим DOMain. То есть они отлично справляются с эффективным рендерингом и рендерингом структур в DOM. Из блога Angular University: Angular не генерирует HTML, а затем передает его в браузер для анализа, вместо этого Angular генерирует структуры данных DOM напрямую!
Например, Angular, в отличие от jQuery, визуализирует структуры данных DOM напрямую. То есть, вместо того, чтобы передавать HTML в браузер, он должен быть проанализирован, а затем преобразован в структуры данных DOM. Это более эффективно, так как устраняет этот шаг анализа. Виртуальный DOM также весьма полезен, поскольку он позволяет вам не перерисовывать все каждый раз, когда вам нужно обновить представление.
Плюсы
С другой стороны, есть несколько неоспоримых преимуществ для разработки веб приложений таким образом:
Размер пакета
Конечный продукт может быть (с акцентом на может быть) намного меньше и компактнее, чем что-либо, разработанное с использованием современного фреймворка. Например, финальная сборка моего полнофункционального приложения с рецептами была меньше, чем половина сборки Angular.
Размер пакета Angular
Пакет приложения рецептов
Примечание. Это обновленные оптимизированные размеры пакетов.
Понимание
Если вы на самом деле разрабатывали только с помощью фреймворка и его интерфейса командной строки, это может быть отличным упражнением для создания веб-приложения без дополнительных инструментов. Как человеку, который хочет достичь определенного уровня мастерства (насколько это возможно) в веб-разработке, мне было важно получить больше практического опыта с инструментами сборки, API-интерфейсами браузера, шаблонами проектирования и т. д.
Производительность
То, что эти front-end фреймворки и библиотеки делают под капотом, удивительно. Однако это может стоить вам производительности; нет такого понятия, как бесплатный сыр. Существует множество потенциальных проблем производительности: масштабные повторные рендеринги, избыточные прослушиватели, глубокое сравнение объектов или ненужные и масштабные манипуляции с DOM. Вы можете избавиться от многих сложностей, реализуя все с нуля.
Похоже, что команды Angular и React знают об этих подводных камнях и предоставляют в качестве средства дальнейшей оптимизации производительности такие вещи, как переопределения методов shouldUpdate и onPush ChangeDetection.
Простота и управление кодом
Вы рискуете всякий раз, когда вводите сторонний код. Этот риск уменьшается с помощью проверенных и протестированных библиотек / фреймворков, но никогда не устраняется. Если вы пишите код самостоятельно или с вашей командой, вы можете уменьшить этот риск и поддерживать кодовую базу, которую вы знаете, как внутри, так и снаружи.
Примечания
У меня был отличный опыт работы с Parcel. Иногда он немного более ограничен, чем Webpack, когда пытается обойти определенные пограничные случаи, но я обнаружил, что утверждение ‘zero config’ по большей части справедливо.
Мне также ясно, что многие называют React «библиотекой», а Vue — «прогрессивным» фреймворком. Хотя я понимаю причины этого, я думаю, что React, Vue и Angular решают во многом те же проблемы. Таким образом, я рассматриваю их все вместе, как «фреймворки».
Почему бы не использовать Stencil or Polymer? Я хотел по возможности избегать использования пакетов, библиотек и фреймворков. И посмотреть, насколько стали хороши веб-стандарты, чтобы соответствовать современным потребностям разработкам (не учитывая инструментов сборки).
Я уверен, что есть много других способов разработки SPA или приложения в целом без фреймворка или библиотеки, я попробовал один способ, и хотел бы услышать о других от вас!
Подводя итоги
Отличная эвристика для решения использовать или не использовать фреймворк — это то, что я называю «переломным моментом». По мере роста вашего приложения наступает момент, когда вы в конечном итоге создаете свою собственную платформу для повторного использования функционала и структуры. Например, у вас есть куча форм, и вы хотите создать повторно используемую логику для реактивной проверки.
Если вы окажетесь на этом этапе, вам придется решить, стоит ли тратить время на создание систем, чтобы добиться того, чего вы можете быстро достичь с помощью фреймворка или библиотеки. У вас будут разные переломные моменты в зависимости от того, какие у вас временные или бюджетные ограничения, но фреймворки по-прежнему очень актуальны в определенных сценариях.
Тем не менее, с течением времени многое из того, что делают фреймворки, вероятно, станет легче реализовать с помощью небольших библиотек и / или собственного кода. Возьмите мой пост в качестве примера. В то же время, если большие фреймворки и библиотеки остаются универсальными, они могут изменяться, адаптироваться. В противном случае они могут закончить так же, как jQuery — по большей части инструмент из прошлого.
Заключение
В заключение, существуют многообещающие способы разработки сложных интерфейсных приложений без фреймворков. Тем не менее, спецификации для таких вещей, как веб-компоненты, все еще развиваются, и есть некоторые вещи, которые необходимо проработать. Фреймворки по-прежнему делают много удивительных вещей и могут сделать разработку намного более гладкой.
На данный момент, насколько я могу судить, плюсы использования фреймворка часто перевешивают минусы. Однако если фреймворки не начнут решать новые проблемы и не будут развиваться, они в конечном итоге исчезнут.
Автор: Luke Joliat
Источник: //medium.freecodecamp.org/
Редакция: Команда webformyself.
