Коротко — сравнение двух стратегий, основные трудности по доступности/масштабируемости/тестированию и практичные компромиссы.
1) Сравнение: DOM/HTML/CSS (включая SVG) vs canvas/WebGL
- Доступность
- DOM/SVG: нативная поддержка доступности (ARIA, фокус, таб-навигция, текст для читалок), легко реагировать на клавиатуру и селектирование текста.
- Canvas/WebGL: поверхность — графический пиксельный буфер без встроенной семантики; нужно вручную строить отдельную доступную «дубль»-структуру (ARIA-элементы, скрытые DOM-списки, live regions), маппинг фокуса и событий.
- Производительность и масштабируемость
- DOM/SVG: удобен для сотен—нескольких тысяч элементов; при больших числах (тысячи+) падает производительность из‑за большого числа DOM-узлов и GC; сложные CSS-анимации и layout-ревалиды замедляют.
- Canvas/WebGL: GPU-рендеринг, хорошо масштабируется к десяткам тысяч объектов при правильной организации (батчинг, инстансинг, culling); минимальные накладные расходы на DOM. Но CPU-операции по логике/хит‑тестингу/физике всё ещё нужны.
- Интерактивность и хит‑тестинг
- DOM/SVG: события pointer/mouse/keyboard приходят «из коробки», hit-testing — браузерный.
- Canvas/WebGL: хит‑тестинг нужно реализовать: color-picked framebuffer, пространственные индексы (quadtree/R-tree) + геометрические проверки или GPU picking; сложнее для точного ввода.
- Стилизация/анимация и отладка
- DOM/SVG: CSS, devtools для инспекции отдельных объектов.
- Canvas/WebGL: шейдеры/ручной рендер — труднее отлаживать; визуальные регрессии тестируются пиксельно.
- Code ergonomics / ecosystem
- DOM/SVG: проще интегрировать формы, контекстные меню, существующие компоненты (React/etc).
- Canvas/WebGL: нужно больше инфраструктуры (менеджер сцен, рендер-пайплайн, кеши). Библиотеки: Konva/Fabric для canvas, PixiJS/Three.js для WebGL.
2) Конкретные трудности
- Доступность
- Canvas/WebGL не предоставляет semantic tree → требуется синхронизировать отдельную DOM-структуру с видимой сценой (дубль-дерево объектов, кликабельные/фокусируемые элементы).
- Обновления состояния и фокус-менеджмент сложнее: надо хранить id объектов, обеспечивать стабильные aria-метки и порядок табуляции.
- Экранные читалки не понимают графику, нужно текстовые альтернативы (описание сцены, список объектов, свойства).
- Клавиатурная навигация и работы с инструментами (перемещение, масштаб, выбор) нужно проектировать отдельно.
- Масштабируемость / производительность
- DOM при большом числе узлов → перерасчёты layout, repaint, GC; медленные анимации на мобайле.
- Canvas/WebGL решает рендер, но CPU‑нагрузка на логику (хит‑тест, селекции, трансформации) и передачи данных между main thread и GPU; без OffscreenCanvas и WebWorkers часть тяжёлой работы блокирует UI.
- Мобильные GPU/память ограничены → нужно агрессивное culling, LOD, упрощённые меши/спрайты.
- Инструменты тестирования
- DOM: доступность тесты (axe/lighthouse), unit/e2e (Jest/React Testing Library, Playwright, Cypress), легко симулировать события.
- Canvas/WebGL: визуальные регрессии (pixel diff) чувствительны к платформенным отличиям; автоматизированная проверка доступности сложна (надо тестировать скрытую доступную структуру отдельно); сложнее юнит‑тестировать шейдеры, рендер-пайплайны.
- Интеграционные E2E с реальными screen reader-ами (NVDA, VoiceOver) нужны для проверки поведения, но сложно автоматизировать стабильные сценарии.
3) Практичные компромиссы и архитектурные паттерны
- Гибридный слой (рекомендуемая общая стратегия)
- Использовать canvas/WebGL для «тяжёлого» визуального рендера (массовые объекты, эффекты, быстрая анимация).
- Параллельно поддерживать семантический DOM‑слой: скрытый/видимый список объектов с aria-метками, кнопки/панель свойств, панель навигации и инструменты. Этот слой обеспечивает доступность и клавиатурную навигацию.
- Для интерактивного выбора: реализовать GPU/CPU picking (color‑id buffer или spatial index) и при выборе синхронизировать фокус на соответствующий DOM-элемент (или создать фокусируемую кнопку в скрытом списке).
- Стратегии по количеству объектов
- Небольшо/среднее (до сотен—пару тысяч объектов): SVG + DOM дает лучшую доступность и простоту.
- Большие сцены (тысячи+): canvas/WebGL + скрытая доступная структура; по необходимости виртуализировать представления (UI список/дерево объектов).
- Техники для производительности
- Слойная архитектура: несколько canvas-слоёв (фоны, объекты, UI) для минимального перерисовывания.
- OffscreenCanvas + WebWorker для тяжёлых расчетов и рендеринга (особенно WebGL2/OffscreenCanvas в поддерживаемых браузерах).
- GPU instancing, батчинг, текстурные атласы, culling, LOD.
- Пространственные индексы (quadtree/R-tree) для быстрого поиска и хит‑тестинга.
- Ограничение количества активных интерактивных объектов; lazy-load/LOD на мобильных.
- Доступность: практическая реализация
- Всегда предоставлять альтернативное текстовое представление сцены и дереву объектов (panel/list с кнопками и aria-labels).
- Клавиатурные команды для навигации и операций (четкие фокусные точки и видимые индикаторы фокуса).
- При рендере на canvas поддерживать «focus proxy» — невидимые фокусируемые элементы, синхронизированные с объектами.
- Для сложных визуальных элементов — дублировать ключевую информацию в aria-describedby и live regions при изменениях.
- Тестировать с реальными читалками и автоматическими инструментами (axe, jest-axe, Lighthouse).
- Тестирование и CI
- Разделить тесты: логика/API и доступность — unit + DOM; визуальная согласованность — визуальные регрессии (Playwright/Puppeteer + pixel-diff) и E2E.
- Для canvas/WebGL добавлять функциональные тесты хит‑тестинга: эмулировать клики по координатам и проверять, что доступный DOM‑элемент получает фокус/событие.
- Интеграционные тесты с NVDA/VoiceOver вручную/полуавтоматизировано для критичных сценариев.
4) Краткий пошаговый план реализации (компромиссный)
1. Начать с модели данных (scene graph, id объектов, атрибуты доступности).
2. UI/controls/lists — реализовать в DOM сразу (доступность).
3. Выбрать рендер: SVG для начального прототипа; при росте производительности перейти на canvas/WebGL.
4. Реализовать слой для выбора: color‑buffer picking или spatial index + геометрия.
5. Построить скрытый доступный дубль (list/tree) и синхронизацию фокуса/aria при выборе на сцене.
6. Оптимизировать рендер: слои, батчинг, OffscreenCanvas/WebWorkers.
7. Добавить мониторинг производительности и набор accessibility E2E тестов.
5) Практические рекомендации по библиотекам/инструментам
- SVG/DOM: React + SVG, D3 (для сложной геометрии/данных).
- Canvas: Konva, Fabric (простая интерактивность).
- WebGL: PixiJS (2D), Three.js (3D), кастомные шейдеры для производительных сцен.
- Accessibility тесты: axe-core, jest-axe, Lighthouse.
- E2E/визуал: Playwright / Puppeteer + pixel-diff, Cypress для пользовательских сценариев.
- Spatial indexing: rbush, quadtree библиотеки.
Итог: если критична доступность и количество объектов невелико—DOM/SVG; если критична производительность при тысячах объектов—canvas/WebGL с параллельным доступным DOM‑дублем и продуманной архитектурой слоёв, хит‑тестинга и клавиатурной навигации. Это даёт лучший компромисс между UX, производительностью и доступностью.