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

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

СОДЕРЖАНИЕ

1. "Вступление"
2. Чем могут помочь WebWorkers?
3. Многоэкранные приложения
4. Многоэкранные приложения для мобильных устройств
5. Как мы можем включить код нашего приложения в воркер?
6. Что такое удаленные методы?
7. В чем проблема с шаблонами?
8. Уменьшение DOM в среднем на 80% +
9. Код ES8 + прямо в браузере
10. Получите документацию по вашему приложению из коробки
11. Любопытно? Что такое neo.mjs?
12. Как набрать скорость?
13. Что будет дальше?

1. Введение

Интернет движется вперед с огромной скоростью - а вы?

Когда были представлены Angular и React, браузеры плохо поддерживали функции ES6 +. В результате вся разработка пользовательского интерфейса была перенесена в node.js.

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

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

Большинство приложений сегодня по-прежнему используют следующую настройку:

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

2. Чем могут помочь WebWorkers?

Что мы хотим решить из этой дилеммы, так это следующие установки:

Фреймворк и логика вашего приложения могут и должны работать внутри воркера.

При такой настройке в основном потоке нет фоновых задач. Ничто не может замедлить или даже заморозить ваши переходы пользовательского интерфейса.

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

3. Многоэкранные приложения

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

Посмотрите это демо-видео 95-х годов:

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

4. Многоэкранные приложения для мобильных устройств

Это будет большим делом. Многие мобильные приложения используют собственную оболочку, содержащую несколько WebView. Здесь также может работать настройка SharedWorkers, в результате чего фреймворк и связанный с приложением код загружаются только один раз и, что более важно, также перемещаются деревья компонентов вокруг WebViews.

Команда Webkit (Safari) думает о том, чтобы снова поднять эту тему. GitHub добавил вес тикету:

Тебе действительно стоит поступить так же!

5. Как мы можем включить наш код приложения в воркера?

Ваш index.html файл будет выглядеть так (режим разработки):

Вы просто втягиваете код основного потока фреймворка (40 КБ).

Вам не нужно создавать этот файл вручную. Все, что вам нужно сделать, это:

npx neo-app

Или клонируйте репо и используйте программу create-app. Это импортирует WorkerManager и сгенерирует для вас the Workers, зарегистрирует удаленные методы и загрузит код вашего приложения в работника приложения.

Https://github.com/neomjs/neo/blob/dev/src/worker/Manager.mjs

Если вы внимательно посмотрите на файлы, то заметите, что все обновления виртуального домена помещаются в очередь в requestAnimationFrame. Вы можете создать аналогичную настройку самостоятельно или позволить neo.mjs позаботиться об этом за вас.

6. Что такое удаленные методы?

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

Это может потребовать много работы, особенно если вы хотите дополнительно поддерживать SharedWorkers.

Если вы запустите свой собственный код внутри Worker (внутри neo.mjs контекста работника приложения), вы заметите, что:

• window не определено
• window.document не определено

Вы просто не можете получить доступ к настоящему DOM. Это делает использование виртуального DOM обязательным.

Тем не менее, есть крайние варианты использования, когда вы хотите получить прямой доступ к DOM. Прокрутка хороша:

Https://github.com/neomjs/neo/blob/dev/src/main/DomAccess.mjs#L402

Как следует из названия файла, Neo.main.DomAccess доступен только внутри основного потока. Он не импортируется в работника приложения.

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

Теперь внутри вашей области (работника приложения) вы можете вызывать эти удаленные методы как обещания. Они будут автоматически сопоставлены с пространством имен Neo.

Https://github.com/neomjs/neo/blob/dev/src/calendar/view/MonthComponent.mjs#L216

Это так просто.

7. В чем проблема с шаблонами?

Angular, React и Vue используют шаблоны на основе строк псевдо XML. Эти шаблоны необходимо анализировать, что дорого. Вы можете сделать это во время сборки (например, Svelte), но тогда вы больше не сможете легко изменить их во время сборки. Это возможно (например, манипулирование JSX-выводом вручную), но на данный момент его использование уже невозможно.

Шаблоны представляют собой смесь разметки dom, циклов, операторов if и переменных. Они могут снизить вашу продуктивность (например, определить объем) и ограничить вас.

Хотя эта тема, безусловно, является спорной, neo.mjs избавился от шаблонов. Вместо этого существуют постоянные структуры, подобные JSON:

Https://github.com/neomjs/neo/blob/dev/src/calendar/view/MonthComponent.mjs#L99

Подобное JSON означает: вложенные объекты и массивы JS, которые вы можете изменять любым способом в течение всего жизненного цикла компонента. Они не содержат переменных, операторов if или циклов.

Согласитесь, что JavaScript идеально подходит для работы с этими структурами.

Их никогда не нужно разбирать:

Https://github.com/neomjs/neo/blob/dev/src/calendar/view/MonthComponent.mjs#L232

Сопоставление изменений конфигурации с vdom довольно тривиально. Вы можете добавлять флаги к определенным узлам и использовать VdomUtil для их получения.

Вы можете добавить флаг removeDom к любому узлу, который удалит узел (или дерево) из реального DOM, сохраняя при этом вашу vdom структуру.

8. Уменьшение DOM в среднем на 80% +

Этот removeDom атрибут, который мы только что упомянули, невероятно мощный. Я просто использовал его для улучшения макетов карточек, чтобы по умолчанию удалить все неактивные карточки из DOM.

Вы также можете изменить его с помощью конфигурации, если хотите.

Хотя узлы со стилем display:’none’ будут исключены из расчетов макета браузера, они все еще используются.

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

Это простой способ еще больше повысить производительность.

Как видите, у календаря есть 4 основных представления (День, Неделя, Месяц, Год), но только одно находится внутри DOM.

SideBar будет удален после его свертывания.

SettingsContainer будет удален после его свертывания.

Настройки содержат TabPanel с пятью вкладками. Только одно тело вкладки находится внутри DOM в любое время.

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

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

9. Код ES8 + прямо в браузере

Взгляните на следующий снимок экрана:

Здесь следует отметить следующие важные моменты:

• Вы можете видеть темы (Main, App, Data, Vdom).
• Файл WeekComponent.mjs находится внутри App Worker.
• Вы можете увидеть настоящий код (это не исходная карта).
• Вы можете увидеть улучшения системы пользовательских классов: Полноценная система конфигурации.

Это приводит к непревзойденному опыту отладки:

• Измените свой код, перезагрузите браузер и готово.
• Никаких сборок или транспиляций не требуется.
• Хотя модули JavaScript полностью поддерживаются во всех основных браузерах, они по-прежнему не поддерживаются в рабочей области Firefox и Safari. Над этим работают команды разработчиков.
• Для neo.mjs существуют версии dist на основе Webpack, которые отлично работают в Firefox и Safari.

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

10. Получите документацию по вашему приложению из коробки

Хотя многие библиотеки или фреймворки предоставляют приложение Docs, этот предоставляет только представления документации для файлов фреймворка.

Используя neo.mjs, вы также получите представления документации для вашего собственного кода, связанного с приложением. Все, что вам нужно сделать, это добавить комментарии к вашим конфигам, методам и событиям.

11. Что такое neo.mjs?

neo.mjs - проект с открытым исходным кодом (вся кодовая база, а также все примеры и демонстрационные приложения используют лицензию MIT).

Приложение для веб-сайта:

Репозиторий:

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

В дорожной карте есть еще много вещей и идей.

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

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

12. Как набрать скорость?

Вероятно, самый простой способ изучить neo.mjs - это следовать первым двум руководствам о том, как создать приложение Covid Dashboard с нуля.

12. Что будет дальше?

Прямо сейчас я сосредотачиваюсь на новом компоненте Calendar для выпуска v1.4. Цель состоит в том, чтобы создать отличный UX, опередив GMail или собственные календари MacOS.

Вы можете посмотреть на текущий прогресс здесь:

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

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

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

Вы определенно можете повлиять на дорожную карту!

Не стесняйтесь использовать трекер проблем. Любые отзывы приветствуются!

С уважением и удачного кодирования!