WebGPU kao novi standard i gdje u toj priči ostaje WebGL
WebGPU je 12. svibnja 2026. dobio novi W3C Candidate Recommendation Draft. Time je još jasnije potvrđen kao službeni nasljednik WebGL‑a u web ekosustavu. U dokumentu se WebGPU eksplicitno navodi uz JavaScript, WebAssembly i WebGL kao dio skupine „teških” API‑ja. Ti API‑ji ulaze u posebne heuristike preglednika za sigurnost, potrošnju memorije i performanse.
Poruka je jasna: ozbiljan grafički i compute workload u preglednicima dugoročno se seli na modernije, niskorazinske API‑je. WebGPU uvodi eksplicitno upravljanje resursima, bolju kontrolu nad pipelineom i mogućnost korištenja compute shaderâ na način sličan Direct3D 12, Vulkanu ili Metal‑u.
Ipak, to ne znači da WebGL nestaje. Njegova uloga se redefinira. WebGL ostaje stabilni, široko podržani sloj, posebno važan na starijem hardveru, u laganim preglednicima i na embedded uređajima gdje WebGPU još neko vrijeme neće biti prvi izbor ili uopće neće postojati.
Zašto preglednici još ne mogu „ugasiti” WebGL
WebGL je danas de facto univerzalni minimum za 3D grafiku u pregledniku. Podržavaju ga svi glavni preglednici, uključujući mobilne, te velik broj starijih GPU‑ova i integriranih grafičkih rješenja. Ogromna količina postojećih aplikacija – edukativne vizualizacije, CAD preglednici, konfiguratori proizvoda, igre, geovizualizacija – izgrađena je oko WebGL 1 i WebGL 2 pipelinea.
Da bi WebGPU u potpunosti preuzeo ulogu, moraju se ispuniti tri uvjeta:
- dovoljno široka hardverska i preglednička podrška,
- zrela alatna podrška (debuggeri, profiliranje, shader toolchain),
- stabilni enginei i biblioteke s WebGPU backendom.
Svi se ti uvjeti razvijaju, ali prijelaz je postupan. Zato preglednici i dalje tretiraju WebGL kao ključni dio grafičkog sloja web platforme. Umjesto naglog „gašenja”, vjerojatniji je scenarij u kojem WebGL dugo ostaje fallback i kompatibilni sloj, dok WebGPU preuzima najzahtjevnije scenarije.
Babylon.js 9.0: praktični primjer koegzistencije WebGPU‑a i WebGL‑a
Najnovije verzije enginea poput Babylon.js 9.0 jasno pokazuju kako izgleda prijelazno razdoblje. Engine uvodi nove sustave osvjetljenja, volumetrijske efekte, naprednu post‑obradu i geovizualizaciju koji koriste compute shadere i moderne mogućnosti WebGPU‑a. Time se otključavaju scenariji koji su u WebGL‑u bili teško izvedivi ili preskupi za CPU.
Istovremeno, Babylon.js zadržava optimizirane fallbackove na WebGL 2. Cijeli rendering pipeline može se spustiti na WebGL ako WebGPU nije dostupan ili je nestabilan na određenom GPU‑u, driveru ili platformi. To uključuje:
- alternativne shader varijante bez compute faze,
- drugačiji raspored rendering passova,
- konzervativnije postavke rezolucije i post‑obrade.
Za vlasnike postojećih WebGL projekata to je važan signal. Investicija u WebGL i dalje ima smisla, osobito ako se arhitektura od početka dizajnira za dvostruki backend: WebGPU gdje je dostupan, WebGL 2 kao univerzalni minimum. Takav pristup produžuje vijek trajanja aplikacije i smanjuje rizik da će projekt „zapeti” na zastarjelom API‑ju.
Hibridni modeli: WebGPU za teške zadatke, WebGL za prikaz
U praksi se već pojavljuju hibridne arhitekture u kojima WebGPU i WebGL surađuju umjesto da se međusobno isključuju. Znanstveni radovi i geovizualizacijski projekti pokazuju tipičan obrazac:
- WebGPU preuzima compute‑intenzivne zadatke – super‑rezoluciju, filtriranje velikih volumena podataka, generiranje LOD struktura, obradu point cloudova ili neuralne efekte.
- WebGL ostaje glavni render‑sloj koji prikazuje konačnu sliku, koristi postojeću infrastrukturu za UI, interakcije i kompatibilnost s engineima.
Primjerice, masivna 3D scena s milijunima točaka može se u pozadini pripremati preko WebGPU compute shaderâ. Oni generiraju optimizirane tileove, klastere ili impostore, dok WebGL renderer crta već pripremljene geometrije i teksture. Korisnik i dalje vidi stabilan FPS i poznati WebGL‑based UI, ali dio teškog posla je premješten na moderniji API.
Takvi hibridi su posebno privlačni za:
- geovizualizaciju s dinamičkim slojevima i senzorima,
- znanstvenu vizualizaciju volumetrijskih podataka,
- analitičke panele na edge uređajima gdje je bitan odnos performansi i potrošnje energije,
- web aplikacije koje integriraju AI modele za obradu slike ili videa u pregledniku.
Što konkretno mijenja WebGPU za WebGL developere
Za većinu WebGL timova novi koraci u standardizaciji WebGPU‑a ne znače da treba „prepisati sve u WGSL”. Umjesto toga, mijenja se način razmišljanja o arhitekturi.
1. Jasna separacija render‑backenda
Umjesto da je WebGL poziv raspršen po cijelom kodu, preporučuje se uvođenje apstraktnog render‑sloja. Aplikacijska logika, UI i mrežni sloj ne bi smjeli ovisiti o konkretnom API‑ju. To olakšava kasnije dodavanje WebGPU backenda uz postojeći WebGL backend.
Praktično, to znači:
- uvođenje sučelja za buffer, teksture, shadere i pipeline state,
- centralizirano upravljanje rendering passovima i frame pacingom,
- izbjegavanje direktnog pristupa WebGL kontekstu iz poslovne logike.
2. Standardizirani asset pipeline
Dosljedno korištenje glTF‑a, PBR materijala i standardiziranih teksturnih formata smanjuje ovisnost o specifičnostima WebGL‑a. glTF je već dizajniran da se dobro mapira na više grafičkih API‑ja, što olakšava prijenos scena i materijala na WebGPU.
Preporuke uključuju:
- izbjegavanje custom binarnih formata koji kodiraju pretpostavke vezane uz WebGL,
- korištenje fizički baziranog renderinga (PBR) kao osnove,
- planiranje mipmapa, normal mapova i HDR tekstura s pogledom na budući WebGPU pipeline.
3. Oprez s vendor‑specifičnim ekstenzijama
WebGL ekstenzije specifične za pojedine vendore mogu kratkoročno dati performanse, ali dugoročno otežavaju migraciju. Ako se koriste, treba ih izolirati u male, zamjenjive module i uvijek imati „čisti” put bez ekstenzije.
WebGPU nudi eksplicitniji i konzistentniji model pristupa GPU‑u preko modernih drivera. Što je WebGL kod manje vezan uz specifične ekstenzije i workarounde, to je lakše kasnije preslikati koncepte na WebGPU pipeline, compute passove i resource bindanje.
4. Razmišljanje u terminima više API‑ja
WebGL će u idućim godinama često biti „prvi kontakt” korisnika s 3D webom, posebno u korporativnim okruženjima s konzervativnim IT politikama. WebGPU će ući kao „turbo mod” za korisnike s novijim uređajima i preglednicima.
Za timove to znači da bi ključne funkcionalnosti trebale raditi i na WebGL‑u, dok se napredne značajke – viši FPS, veći broj istovremenih senzorskih tokova, složeniji efekti – mogu otključavati kada je WebGPU dostupan. Takav pristup podsjeća na progresivno poboljšanje u klasičnom web razvoju.
Dugoročna uloga WebGL‑a: stabilni kompatibilni sloj
Novi WebGPU CRD dokument potvrđuje smjer: WebGL se pomiče iz pozicije „primarnog 3D API‑ja za web” prema ulozi stabilnog, univerzalno podržanog kompatibilnog sloja. To je dobra vijest za postojeće WebGL kodne baze.
One neće preko noći zastarjeti. Preglednici imaju snažan poticaj zadržati WebGL dugo vremena, jer o njemu ovise edukacijski sadržaji, industrijski alati, pa čak i kritični nadzorni sustavi koji u pregledniku prikazuju podatke sa senzora, gateway uređaja i edge čvorova.
No, istovremeno će se od timova očekivati da dugoročno razmišljaju o prelasku na eksplicitnije API‑je. Kako se povećavaju zahtjevi za kvalitetom renderinga, stabilnim FPS‑om i naprednim efektima, WebGPU će postajati prirodan izbor za nove projekte i veće refaktore.
Timovi koji danas ulažu u čistu, moduliranu WebGL arhitekturu bit će u boljoj poziciji. Moći će dio posla prebaciti na WebGPU bez potpunog rušenja postojećeg koda. Ad‑hoc WebGL projekti, s poslovnom logikom pomiješanom s WebGL pozivima i bez jasnog asset pipelinea, teže će pratiti nove zahtjeve.
Kako planirati sljedećih pet godina WebGL/WebGPU razvoja
Za većinu produkcijskih timova razumna strategija izgleda ovako:
- kratkoročno: nastaviti održavati i optimizirati WebGL projekte, s fokusom na stabilan FPS, dobar frame pacing i pouzdan rendering pass dizajn,
- srednjoročno: modularizirati render‑backend, standardizirati asset pipeline i uvesti ograničene WebGPU eksperimente u izoliranim dijelovima aplikacije,
- dugoročno: planirati veće nove funkcionalnosti i redizajne tako da WebGPU postane primarni API, uz WebGL kao fallback.
U tom scenariju WebGL ostaje „radni konj” koji pokriva širok spektar uređaja i preglednika. WebGPU preuzima ulogu specijaliziranog alata za situacije gdje su potrebne maksimalne performanse, napredni compute zadaci i precizna kontrola nad GPU‑om.
Najnoviji WebGPU standard samo je potvrdio da je smjer jasan. Pitanje više nije „hoće li WebGPU zamijeniti WebGL”, nego „kako će WebGL i WebGPU koegzistirati u sljedećem desetljeću” – i koliko će se današnje arhitekturne odluke pokazati spremnima za taj svijet višestrukih grafičkih API‑ja u pregledniku.
