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

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

Какие проблемы мы пытаемся решить?

Когда мы говорим о создании сложных веб-приложений и/или PWA, мы должны спросить себя, какие отдельные проблемы мы на самом деле пытаемся решить. Если мы этого не сделаем, мы в конечном итоге будем использовать молоток, потому что мы видим все как гвоздь.

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

  1. Компонентизация HTML
  2. Маршрутизация
  3. Государственное управление и обмен

Рассмотрим подробно каждый из этих вопросов, ведь все они имеют свою специфику.

Компонентизация HTML

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

Теперь, если вы знаете, что примерно в 2011 году W3C начал работу над первой версией стандарта веб-компонентов, предназначенного для этого, вы можете спросить, какого черта все известные фреймворки имеют (и имеют сохранили) свою собственную, полностью проприетарную модель для веб-компонентов. Посмотрите эту отличную статью об этом очень интересном фрагменте истории, если хотите узнать подробности.

Что еще более странно, так это то, что даже в 2023 году все фреймворки все еще усиливают мнение о том, что вам нужен их фреймворк для создания компонентов HTML.

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

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

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

Это ответ ChatGPT, когда я спросил его о интерфейсных фреймворках, которые охватывают веб-компоненты и не переопределяют уровень композиции HTML:

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

У Google даже есть лаборатория (электронное обучение) по переходу с React на Lit.

💡Вывод: есть веские причины отказаться от проприетарной HTML-композиции и перейти к устойчивой разработке нативных веб-компонентов.

Маршрутизация

Мы можем быть краткими об этом.

В веб-браузерах нет собственного API-интерфейса маршрутизации. Или есть?

Если приглядеться, все, что нужно для работы маршрутизации, на самом деле полностью доступно во всех браузерах (и было уже много лет), как для маршрутизации на основе хэша (hashchange), так и для маршрутизации на основе истории (pushState/popState). ). Чего не хватает, так это немного клея, но бояться нечего, как убедился на себе. На Github и Codepen есть множество небольших библиотек посадочных мест и фрагментов кода, которые показывают, как это делается. Никакой ракетостроения.

💡Вывод: вам никогда не понадобится фреймворк для маршрутизации.

Государственное управление и обмен

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

… и они правы.

Многие из этих разработчиков обращаются к Redux или подобным инструментам. Комбинация React+Redux — одна из самых популярных в целом.

Несколько важных вещей, чтобы сказать здесь.

Во-первых, даже соавтор Redux Дэн Абрамов говорит, что вашему приложению может не понадобиться Redux. Люди склонны использовать Redux задолго до того, как он понадобится их приложениям.

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

💡 Вывод: вам не нужен фреймворк для управления состоянием. Всякий раз, когда ваше управление состоянием становится действительно сложным, используйте библиотеку, например Redux.

Заключение

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

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

Также необходимо устранять — и противодействовать — предвзятости, связанной с маркетингом фреймворков. За годы я написал довольно сложный JavaScript, но я всегда переоценивал, как это сделать. Может быть, это был технический директор во мне все время ;-).

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

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

Там сумасшедший мир.

Литература

Дополнительные материалы на PlainEnglish.io. Подпишитесь на нашу бесплатную еженедельную рассылку новостей. Подпишитесь на нас в Twitter, LinkedIn, YouTube и Discord .

Заинтересованы в масштабировании запуска вашего программного обеспечения? Ознакомьтесь с разделом Схема.