Чому б я використовувала Three.js і Pixi.js
CSS і GSAP анімують сторінку. Three.js і Pixi.js малюють сцену на GPU. Коли продукту потрібні тисячі спрайтів, 3D-конфігуратор або canvas, який тримає 60 fps, DOM - не той інструмент. Як я обираю між ними.
Сторінка в браузері - це документ: заголовки, кнопки, форми, посилання, які бачить crawler. CSS, GSAP і Framer Motion рухають цей документ. Це правильний інструмент майже для кожного маркетингового сайту, який я здаю. Three.js і Pixi.js існують для іншої роботи: сцена, яку малює GPU, а не дерево div. Команди беруть їх, коли DOM сипле кадрами, коли об’єкт - 3D-SKU, або коли дві тисячі монет мають лишатися на екрані при 60 fps.
Я вже писала, коли GSAP і Framer Motion виправдовують себе на здачі Figma в код. Це не та стаття. Це коли я б вийшла з DOM, для чого насправді кожна бібліотека, і який рахунок ви платите в Core Web Vitals, SEO й доступності, якщо повісите WebGL-canvas на бізнес-URL.
1. DOM - документ. Canvas - поверхня для малювання
Кожен DOM-вузол несе розкладку, стиль, hit-testing і місце в дереві доступності. Ця ціна - сенс вебу: текст виділяється, форма табається, Google індексує заголовок. І саме тому тисяча абсолютних div на середньому телефоні буде підгальмовувати. Canvas - це бітмап. Ви кажете GPU, що малювати цього кадру. У спрайта немає layout. Немає й заголовка для crawler і імені для скрінрідера, якщо ви не збудуєте це поруч із canvas.
Сирий WebGL (і тепер WebGPU) - це камери, буфери, шейдери й draw call. Написати можна. Більшості продуктових команд не варто. Three.js і Pixi.js загортають цю поверхню в граф сцени, лоадери й ринок найму. Платите вагою бандла і чорною скринькою посеред сторінки. Питання ніколи не «чи крутий GPU-рендер». Питання - чи продуктові справді потрібна сцена.
2. Three.js: 3D-світ у вкладці
Three.js - 3D-рушій для браузера. Ви отримуєте сцену, камеру, світло, меші, матеріали й текстури. Бібліотека говорить з WebGL; для новіших GPU є рендерер WebGPU. Ним користуються, бо GLTF-модель дивана, кухні чи турбіни дешевше крутити у вкладці, ніж знімати кожен ракурс, і бо камера, яку можна облетіти, продає краще за карусель PNG.
Типова робота, яку я бачу: конфігуратори продукту (колір, тканина, опції), прогулянки архітектурою, наукові чи фінансові дані в просторі, WebXR-стенди, hero-сцени на брендовому сайті, які мають відчуватися як кадр фільму, якого можна торкнутися. Babylon.js - справжня альтернатива з сильнішим редактором. Three.js виграв приклади, відповіді на Stack Overflow і React Three Fiber - так я б врізала сцену в Next.js-застосунок, який уже мислить компонентами.
- Three.js - коли в об’єкта є глибина: облетіти, розібрати деталь, змінити матеріал, пройти кімнату.
- Тримайте GLTF худим. Диван на 40 МБ убиває мобільний. LOD, стиснуті текстури й poster-картинка, доки сцена не завелася.
- Не кладіть ціну, CTA і чекаут у canvas. HTML поруч. Сцена продає об’єкт; документ закриває угоду.
3. Pixi.js: 2D на 60 fps, не ігровий рушій
Pixi.js - 2D-рендерер. Спрайти, список відображення, фільтри, системи частинок, скелетна анімація в стилі Spine. Він пакує draw call на GPU, тож барабан слота, навчальна дошка для дітей або мапа з кількома тисячами пінів не плавить main thread так, як DOM-список. Ним користуються, бо Canvas 2D на такій кількості повільний, і бо веб-застосунок уже є - не хочеться брати повний ігровий фреймворк лише щоб швидко малювати.
Phaser - ігровий фреймворк: сцени, фізика, інпут, звук. Pixi - шар під ними, коли React, роутинг і auth уже ваші. Інтерактивна реклама, брендовані мініігри, дашборди з більшою кількістю точок, ніж варто віддавати SVG, і UI в казино-стилі - типовий бриф. Якщо продукт - справжня гра з рівнями й фізичним світом, почніть з ігрового рушія. Якщо продукт - Next.js-застосунок, якому на одному маршруті потрібна гаряча 2D-сцена, Pixi - бібліотека, по яку я б пішла.
- Pixi - коли проблема це кількість і плавність у 2D: частинки, спрайтшити, фільтри, сцена, яка перемальовується щокадру.
- Збирайте спрайти в атлас. Десять тисяч окремих PNG зупинять завантаження, навіть якщо GPU потім щасливий.
- Ставте ticker на паузу, коли вкладка схована. Сцена Pixi, яка тікає у фоні, - скарга на батарею, яка ще не прийшла.
4. Як я обираю: CSS, GSAP, Pixi, Three
Дорога помилка - гасити кнопку 3D-рушієм. Я вже писала: преміальний scroll-сторітелінг - це GSAP і ScrollTrigger, а стан React-UI - Framer Motion. Ці бібліотеки анімують вузли, які лишаються в документі. Three і Pixi створюють світ, якого в документі немає. Мішати можна. Заміняти не той шар - отак лендінг виїжджає з WebGL-hero на 800 КБ, який ніхто не просив облітати.
- Ховер, акордеон, перехід сторінки, фідбек форми: CSS або Framer Motion. Лишайтесь у DOM.
- Припинені секції, скраб таймлайну, кінематографічний скрол: GSAP. Усе ще документ, просто хореографія.
- Тисячі 2D-об’єктів, частинки, сцена, яка має тримати 60 fps: Pixi.js.
- Глибина, камера, світло, модель, яку облітаєте: Three.js. Не 2D-барабан слота.
5. Рахунок: vitals, SEO, a11y, дешеві телефони
WebGL-canvas невидимий для crawler. Усе, що користувач має прочитати - назва, ціна, юридичне, FAQ - живе в HTML навколо сцени, а не намалюване в текстуру. Я вже писала, як Core Web Vitals рухають виручку. Нетерплячий 3D-hero на головній - класичний власний гол по LCP і INP: GLTF б’ється з першим пейнтом, потім цикл рендеру краде інпут. Підвантажуйте сцену, коли документ уже корисний. Спочатку статичний постер. Знищуйте рендерер на unmount, інакше GPU потече крізь клієнтські навігації.
Доступність - паралельний UI, не атрибут canvas. Клавіатурний обліт, текстова альтернатива моделі, reduced-motion, який зупиняє цикл. Дешевий Android термічно придушить зайнятий fragment shader. Обмежте pixel ratio, дайте запасний шлях «2D-фото» і не робіть єдиним шляхом до SKU WebGL-контекст, який не зміг стартувати.
6. Next.js: клієнтський острів, не Server Component
На сервері немає WebGL. Сцена - клієнтський компонент, через next/dynamic з ssr: false, за постером або скелетоном. React Three Fiber, якщо решта застосунку - React. @pixi/react, якщо сцена має говорити з тим самим деревом стану. Я б не SSR-ила canvas «для SEO»: crawler усе одно бачить порожній бітмап. Текст кладіть у серверний HTML. Острів хай заводиться, коли користувач готовий крутити об’єкт.
Висновок: обирайте поверхню під об’єкт
Команди беруть Three.js, бо 3D-SKU продається краще, коли клієнт може його облетіти. Беруть Pixi.js, бо дві тисячі спрайтів на 60 fps не виживуть як div. Жодна з бібліотек не замінює CSS, GSAP чи швидкий документ. Якщо бриф - «зробіть преміально», я починаю з руху в DOM. Якщо бриф - «покрутіть цю кухню» або «тримайте монети на екрані», я виходжу з DOM навмисно, ізолюю canvas і лишаю в HTML текст, який потрібен Google і скрінрідеру. Я це закриваю як senior web engineer: острови Next.js, лінивий WebGL, GSAP там, де сторінка ще сторінка. Напишіть через форму кількість об’єктів, 2D це чи 3D, і чи той самий URL має ранжуватися. Ми не почнемо з canvas на головній «щоб виглядало сучасно».
Треба зібрати, а не лише прочитати?
Розробка web app: Next.js, React, PostgreSQL. Прямий підряд.
Готові обговорити проєкт?
Я senior веброзробниця, спеціалізуюсь на React і Next.js - відкрита до фриланс-проєктів по всьому світу.
Місто
Київ, Україна
Upwork
Переглянути профільTelegram
Напишіть меніViber
Напишіть мені