Интенсивное чтение «Фундаментальная причина существования современных js-фреймворков»

1. Введение

Глубоко подумайте, зачем интерфейсу нужен фреймворк и могут ли веб-компоненты заменить интерфейсный фреймворк?

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

2 Обзор

Фронтенд-фреймворков сейчас так много, что если ответить на вопрос «Зачем использовать фронтенд-фреймворк», то как вы думаете, это следующие причины?

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

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

Решите проблему синхронизации пользовательского интерфейса с состоянием.

Автор предполагает проект без front-end фреймворка, как и в эпоху Jquery нам нужно вручную синхронизировать состояние с UI. Как код ниже:

addAddress(address) {
  // state logic
  const id = String(Dat.now())
  this.state = this.state.concat({ address, id })

  // UI logic
  this.updateHelp()

  const li = document.createElement('li')
  const span = document.createElement('span')
  const del = document.createElement('a')
  span.innerText = address
  del.innerText = 'delete'
  del.setAttribute('data-delete-id', id)

  this.ul.appendChild(li)
  li.appendChild(del)
  li.appendChild(span)
  this.items[id] = li
}

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

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

Таким образом, самая важная помощь современного фреймворка — синхронизировать пользовательский интерфейс с состоянием.

Как это сделать

Есть две идеи:

Повторный рендеринг на уровне компонентов: например, в React, когда состояние изменяется, сопоставляется измененный виртуальный DOM, и, наконец, изменяется реальный DOM, отображаемый текущим компонентом.Этот процесс называется согласованием.
Мониторинг модификации: например, в Angluar и Vue.js изменение состояния напрямую вызывает изменение значения значения в соответствующем узле DOM.

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

Эти три фреймворка были объединены, и две упомянутые автором идеи теперь представляют собой гибридную технологию.

Что насчет веб-компонентов?

Люди часто берут React, Angluar, Vue.js иweb componentsДля сравнения, самая большая проблема с веб-компонентами заключается в том, что они не решают синхронизацию пользовательского интерфейса и состояния.

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

Так что даже с веб-компонентами нам может понадобиться фреймворк для синхронизации пользовательского интерфейса, такой как Vue.js илиstenciljs.

Автор также приводит краткий пример синхронизации состояния пользовательского интерфейса, который здесь пропущен.

В итоге даются четыре вывода:

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

3 Интенсивное чтение

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

Это может быть основной проблемой веб-разработки.

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

Фронтенд Три мушкетера

Проблема в разделении html, js и css.

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

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

Подсчитано, что спроектировать современный фреймворк в официальной html-спецификации сложно, потому что три мушкетера в официальном дизайне — это отдельные решения. должен быть полностью заменен js, который почти является jsx, или поддерживает шаблонную грамматику html, но это противоречит оригинальным идеям веб-дизайна.

HTML независим и может работать даже без js, что естественно приводит к проблеме UI и синхронизации состояний.

Почему вы должны использовать js

Дизайн html, не зависящий от js, возможно, не поспевает за темпами фронтенд-разработки, возможно, за jsx или шаблоном будущее.

Правда, html теперь предназначен для выполнения в браузерах, которые не поддерживают js, но совсем недавно все современные браузеры поддерживали сервис-воркеры, которые представляют собой скрипты js, которые переопределяют время выполнения html и могут даже перехватывать html-запросы. Браузер, который не поддерживает js, также может не поддерживать сервисных работников, а настойчивое требование отключить js может оставить только средства защиты.

Фактически, современные веб-страницы используют js, чтобы полностью доминировать в отображении веб-страниц, так что это превратилось из технической проблемы в социальную проблему.Сколько веб-страниц можно нормально получить в браузерах, которые отключают js сегодня? За исключением некоторых очень крупных веб-сайтов, которые сделали специальную оптимизацию для отключения состояния js, почти ни один внешний проект сейчас не будет рассматривать возможность отключения js, потому что мы не предполагаем, что код фреймворка React, Angluar, Vue.js не может работать.

Так почему бы не объединить html и js?

Поскольку пользовательский интерфейс фактически привязан к js, почему w3c не указывает jsx или шаблон в качестве стандарта? Возможно, для прямой совместимости спецификация никогда не сделает этот шаг.

К счастью, это не мешает массовой популярности современных интерфейсных фреймворков и является ошеломляющей.

4 Резюме

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

Внешний интерфейс — это не только веб, или, может быть, следующий прорыв — это не веб, а ar/vr или следующий сценарий взаимодействия человека с компьютером. Точно так же веб — это не только три мушкетера внешнего интерфейса. фреймворки и новые языки на основе виртуального DOM.

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

Наконец, резюмируя мнения:

Также от оригинального автора,Современные js-фреймворки в основном решают проблему синхронизации пользовательского интерфейса и состояния.
Традиционная фронтальная тройка мушкетеров переживает кризис дальнейшего развития.
Современные интерфейсные фреймворки рассказывают нам о новых трех мушкетерах: js (виртуальный дом, виртуальный css).

еще 5 обсуждений

Адрес обсуждения:Интенсивное чтение «Основная причина существования современных JS-фреймворков», выпуск № 84 dt-fe/weekly

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