Коли цей проєкт розпочався, вибір між Three.js і Babylon.js зовсім не був очевидним. Обидва чудові. Обидва підтримують WebGL 2 і WebXR, мають активні спільноти та визначення типів для TypeScript. Після прототипування кількох симуляцій у кожному з них переміг Three.js. Ось чому — і чому Babylon.js переміг би в іншому проєкті.
Пряме порівняння
| Критерій | Three.js r168 | Babylon.js 7.x |
|---|---|---|
| Мінімальний бандл (gzip) | ~150 КБ (ядро) | ~420 КБ (мінімальне ядро) |
| Філософія API | Тонка обгортка, явний контроль | Повний рушій, усе включено |
| Граф сцени | Дерево Object3D | На основі вузлів, більше автоматичного керування |
| Власні шейдери | ShaderMaterial — мінімум шаблонного коду | ShaderMaterial + вузловий редактор |
| PBR-матеріали | MeshStandardMaterial | PBRMaterial (більше параметрів) |
| Постобробка | EffectComposer (окремий пакет) | PostProcessingPipeline (вбудований) |
| Вбудована фізика | Ні (використовуйте Cannon.js, rapier тощо) | Havok, Ammo.js вбудовані |
| XR / VR | Підтримка контролерів WebXR | Повний XR-режим із коробки |
| Завантажень npm/тиждень | ~1.5 млн | ~200 тис. |
| Tree-shaking | Повний ESM, чудово | Частковий, покращується |
| Спільнота / туторіали | Величезна (drei, r3f тощо) | Сильна, особливо серед розробників ігор |
| Інспектор / інструменти розробника | Three.js devtools (розширення браузера) | Вбудована панель інспектора |
Аргумент розміру бандла
Кожна симуляція на цьому сайті завантажується незалежно. Різниця у 270 КБ на сторінку × 40 симуляцій означає в найгіршому випадку ~11 МБ додаткового трафіку, якщо користувач відвідає все. З кешуванням HTTP бібліотека завантажується один раз — але перше завантаження важливе для мобільних користувачів і показників Core Web Vitals. Three.js постачається як повністю дерево-відсічувані модулі ESM; невикористані класи зникають на етапі збирання.
Власні шейдери — основа справи
Майже кожен візуальний ефект тут — власний шейдер GLSL: океанські
хвилі (Герстнера), рендеринг рідини (нормалі в екранному
просторі), галактика (GPU-білборди точок), реакційно-дифузійні
процеси (пінг-понг фреймбуферів). ShaderMaterial у
Three.js — це просто:
- Рядок вершинного шейдера
- Рядок фрагментного шейдера
- Словник
uniforms
Жодного вузлового графа, жодної абстракції, з якою треба боротися.
Ви пишете GLSL — і саме він виконується. ShaderMaterial
у Babylon.js подібний, але якщо ви починаєте з їхніх вбудованих
матеріалів (PBRMaterial, StandardMaterial), ментальна модель — це
рушій, що генерує шейдери — доводиться перевизначати більше, коли
потрібен повний контроль.
Коли варто обирати Babylon.js
Вам не слід слідувати вибору цього проєкту, якщо ваші цілі включають:
- 3D-гру з фізикою — інтеграція Havok у Babylon промислового рівня. Three.js потребує ручного підключення Cannon.js або Rapier.
- Нетехнічних художників — вузловий редактор матеріалів Babylon.js і конвеєр експорту з Blender чудові для дизайнерів.
- VR/XR як основну функцію — XR-режим Babylon обробляє введення з контролерів, відстеження рук і телепортацію з коробки.
- Підприємство з повільними конвеєрами збирання — різниця у tree-shaking важливіша для швидких бандлів, ніж для внутрішніх застосунків за CDN.
Коротко — Three.js перемагає для наукових симуляцій, що керуються даними та живуть чи вмирають завдяки власному GLSL і мінімальному розміру бандла. Babylon.js перемагає для повноцінних ігор, багатих інтерактивних вражень і всього, що потребує вбудованої фізики чи VR.