Gdy projekt się zaczynał, wybór między Three.js a Babylon.js był wszystkim, tylko nie oczywisty. Obie biblioteki są znakomite. Obie mają wsparcie WebGL 2 i WebXR, aktywne społeczności i definicje TypeScript. Po prototypowaniu kilku symulacji w każdej z nich zwyciężyło Three.js. Oto dlaczego — i dlaczego Babylon.js wygrałoby w innym projekcie.
Porównanie bezpośrednie
| Kryterium | Three.js r168 | Babylon.js 7.x |
|---|---|---|
| Min. paczka (gzip) | ~150 KB (rdzeń) | ~420 KB (min. rdzeń) |
| Filozofia API | Cienki wrapper, jawna kontrola | Pełny silnik, wszystko wbudowane |
| Graf sceny | Drzewo Object3D | Oparty na węzłach, więcej automatyki |
| Własne shadery | ShaderMaterial — minimalny narzut | ShaderMaterial + edytor węzłów |
| Materiały PBR | MeshStandardMaterial | PBRMaterial (więcej parametrów) |
| Post-processing | EffectComposer (osobny pakiet) | PostProcessingPipeline (wbudowany) |
| Fizyka wbudowana | Nie (użyj Cannon.js, rapier itp.) | Havok, Ammo.js wbudowane |
| XR / VR | Wsparcie kontrolerów WebXR | Pełny tryb XR od ręki |
| Pobrania npm/tydzień | ~1,5 mln | ~200 tys. |
| Tree-shaking | Pełny ESM, znakomity | Częściowy, poprawia się |
| Społeczność / samouczki | Ogromna (drei, r3f itd.) | Silna, zwłaszcza wśród twórców gier |
| Inspektor / narzędzia dev | Three.js devtools (rozszerzenie przeglądarki) | Wbudowany panel inspektora |
Argument rozmiaru paczki
Każda symulacja na tej stronie ładuje się niezależnie. Różnica 270 KB na stronę × 40 symulacji oznacza w najgorszym razie ~11 MB dodatkowego transferu, jeśli użytkownik odwiedzi wszystko. Przy cache'owaniu HTTP biblioteka ładuje się raz — ale pierwsze pobranie ma znaczenie dla użytkowników mobilnych i Core Web Vitals. Three.js dostarcza w pełni tree-shakeable moduły ESM; nieużywane klasy znikają w czasie budowania.
Własne shadery to podstawa biznesu
Niemal każdy efekt wizualny tutaj to własny shader GLSL: fale
oceanu (Gerstner), renderowanie płynu (normalne w przestrzeni
ekranu), galaktyka (bilboardy punktów GPU), reakcja-dyfuzja
(bufory ping-pong). ShaderMaterial w Three.js to po
prostu:
- Ciąg znaków shadera wierzchołków
- Ciąg znaków shadera fragmentów
- Słownik
uniforms
Bez grafu węzłów, bez abstrakcji do przezwyciężania. Piszesz GLSL,
to właśnie działa. ShaderMaterial w Babylon.js jest
podobny, ale jeśli zaczynasz od ich wbudowanych materiałów
(PBRMaterial, StandardMaterial), model mentalny to silnik
generujący shadery — jest więcej do nadpisania, gdy potrzebujesz
pełnej kontroli.
Kiedy warto wybrać Babylon.js
Nie powinieneś podążać za wyborem tego projektu, jeśli Twoje cele obejmują:
- Grę 3D z fizyką — integracja Havok w Babylonie jest gotowa do produkcji. Three.js wymaga ręcznego podłączenia Cannon.js lub Rapier.
- Nietechnicznych artystów — edytor materiałów węzłowych Babylon.js i pipeline eksportera Blendera są znakomite dla projektantów.
- VR/XR jako funkcję pierwszorzędną — tryb XR Babylona obsługuje wejście z kontrolera, śledzenie dłoni i teleportację od ręki.
- Przedsiębiorstwo z wolnymi pipeline'ami budowania — różnice w tree-shakingu mają większe znaczenie dla szybkich paczek niż dla aplikacji intranetowych za CDN.
TL;DR — Three.js wygrywa dla symulacji naukowych opartych na danych, które żyją lub umierają dzięki własnemu GLSL i minimalnemu narzutowi paczki. Babylon.js wygrywa dla pełnych gier, bogatych doświadczeń interaktywnych i wszystkiego, co wymaga wbudowanej fizyki lub VR.