Hosszú fejlesztés után jelent meg ebben a hónapban a WebGL 2.0, amelyet a legújabb Firefox és Chrome böngészők támogatnak is. Sőt, maga szabvány a hosszú tesztelésnek hála rendkívül jó alapokra épül, és máris igen stabilak az implementációk, így az egész rendszer jól használható a fejlesztők számára. A WebGL 2.0 tehát kész, lehet rá építeni, de máris elkezdődtek a puhatolózások a jövő webes grafikai szabványáról. Egyelőre két koncepció létezik, amelyek közül az egyik az Apple, míg a másik a Mozilla ötletére épül.

Az Apple a WebGPU-t protezsálja, míg a Mozilla az Obsidian kódnevű projektet indította el. A két cég egyetért abban, hogy a webes grafika szempontjából a következő lépés csak egy evolúciós ugrás lehet, vagyis a WebGL 2.0 által használt OpenGL ES 3.0 helyett valami hardverhez közelibb megközelítéssel kellene előállni. Egyrészt ez az irány tűnik logikusnak, hiszen így lehetne teljesítményt nyerni, másrészt szembe kell nézni azzal a ténnyel, hogy az explicit API-k betörésével a szabványalkotók nem fogják normális ütemben, vagy rosszabb esetben sehogy sem fejleszteni a régi felfogás szerint kialakított platformokat. Utóbbi kifejezetten nagy probléma a WebGL jövőjére nézve, mivel az OpenGL ES 3.2-re ugyan még át lehet állni, de jelenleg nincs új generációs OpenGL ES, illetve OpenGL tervezete nincs a Khronos Groupnak, mivel minden erőforrással a Vulkan API fejlesztésére koncentrálnak. A régebbi API-kra csupán kiterjesztések vannak terítéken, ami finoman szólva is egy visszafogott tempóra utal.

Látható, hogy már a kényszer is az új API-k felé löki a fejlesztéseket, és ebből a szempontból lehetnek problémák. A WebGL-t ugyanis a nagyfokú kompatibilitásra alapozták a tervezők, és mára a 2.0-s verzióval ez amellett valósult meg, hogy elég biztonságos magát a felületet is használni, ami egy webes szabványnál kritikus tényező. Ráadásul a WebGL-nek nem is az volt az eredeti célja, hogy a webre biztosítson minőségi 3D-s grafikát, hanem sokkal inkább egy olyan alapot akart kialakítani a Khronos Group, ami valóban platformfüggetlen. Ergo, amit megír a fejlesztő WebGL-re, azt operációs rendszertől, meghajtóverziótól és kliensprogramtól függetlenül ugyanúgy látja viszont minden WebGL-t futtatni képes eszközön. Az már csak egy járulékos előny, hogy a kliens tekintetében a böngésző tűnt az optimális választásnak, tehát magát a rendszert kialakították a webre.

A két új konstrukció közül a WebGPU jár előrébb, mivel már prototípus kóddal is rendelkezik. Ez a WebGL-hez hasonlóan HTML5 canvas elemekkel lép interakcióba, de hatékonyabban működik, mivel nem kell minden rajzolási operáció előtt beállítani a szükséges állapotot, hanem maguk a kreált és elmentett objektumok reprezentálhatják ezt. Ezzel a rajzolási parancsok kiadása előtti validáció mértéke lecsökken, így több erőforrás marad a valós munkára. A WebGPU prototípusa a Metal shader nyelvet használja, ami várható döntés volt az Apple-től.

Az Obsidian kódnevű projekt még nem rendelkezik prototípussal, mivel egyelőre még a megbeszélés fázisánál tartanak az érintettek. A Mozilla egyelőre az alapot szolgáló API-ban sem biztos, de szóba jöhet a Metal, illetve a Vulkan.

Természetesen a weben egészen más szabályok élnek, mivel ügyelni kell a biztonságra, és arra is, hogy maga az új generációs webes grafikai platform olyan legyen, amivel tényleg megoldható az, hogy a kódot csak egyszer kelljen megírni és az mindenhol, platformfüggetlenül fusson. Ezen a ponton ütközik a legnagyobb problémákba a WebGPU és az Obsidian kódnevű projekt, ugyanis az explicit API-kat a hardver megfelelően alacsony szintű elérésére tervezték, vagyis a legtöbb kontrollt maga a programozó kapja. Akármelyik új API is lesz tehát az alap, a jelenlegi formában sem a Metal, sem pedig a Vulkan nem alkalmas egy átfogó webes grafikus felület létrehozására. Rengeteg funkciót át kell tehát alakítani az explicit API-kban, hogy ebből az irányból valóban működőképes rendszerek legyenek évek múlva. Többek között a fejlesztőre bízott memóriamenedzsment biztosan ugrik, hiszen webes szinten ezt nem lehet bevállalni. Egyszerűen túl sok hibalehetőséggel járna, miközben a biztonság tekintetében sem lenne a rendszer túlságosan védett.

Egyelőre azt lehet látni, hogy bármi is lesz a WebGL 2.0 evolúciós utódja eléggé messze van a tényleges bevetéstől, ugyanis komoly átalakításra van szükség mind a Metal, mind pedig a Vulkan API-ban, hogy alkalmas legyen a webre is.