- WebSockets for real time data transfer,
- MediaStream API to get the webcam video stream and to send it in peer to peer,
- WebGL to use the GPU for rendering or computing,
- WebAudio to use advanced audio features.
Web programming has many advantages : write once, run everywhere is maybe the greater. If these browser APIs are so great, why should not we add many more ? These days submitting a new browser API draft has become very trendy. In this short article I give my opinion about which should be accept and which should be rejected.
the case of WebGL
From the day the specification was accepted by a main standard organization like W3C or Khronos Group and and the day when all browsers implement correctly the new API without having to add dirty workarounds and polyfills, a lot of times goes by…
I have a special experience with WebGL as I am a WebGL expert. This is the simplified chronology of the epic of integration :
- Google implements first WebGL with Chrome 6 in September 2010. WebGL specification were still a draft,
- The official WebGL specification were accepted in February 2011. Chrome and Firefox were WebGL compliant. Microsoft had bet on another technology for Internet Explorer,
- 3 years later, only 2/3 of the Internet users were compatible (source : webglstats.com),
- In February 2017, WebGL2 specification were released.
More than 7 years after official WebGL1.0 release, there is still some work to do :
- If we use WebGL1.0 extensions, even if they are widespread like floating point textures handling, we need to add workarounds in order to be WebGL2 compliant. Indeed, most of these extensions had been integrated into the WebGL2.0 standard but the syntax has changed. It adds complexity and execution paths. WebGL2.0 is supported by 62% of the device and the implementation is often only partial,
- If a graphic driver has security failures, it is blacklisted by the browser until a security update is done. It is now rare new because graphic hardware manufacturer take more security into account but it took several years,
- Still 7% of users are not compatible (source : caniuse.com), and 5% of the compatible user have major performance caveat,
- The browser almost always have to add workarounds to compensate graphic driver problems. Enter
chrome://gpuin the Chrome URL bar and take a look at the Driver Bug Workarounds and Problems Detected sections…
At Jeeliz, we develop deep learning networks running with WebGL. There are many execution paths to implement, depending on the hardware.
It takes really a lot of time and efforts to bring a new important feature, like GPU access, to the browser. Some attempts even fail, like WebCL, which was an API to bring GPU acceleration for computation in the browser. WebRTC, WebAudio,… had stories similar to WebGL.
Let’s avoid a bloated browser
The main challenges of web programming are :
- to be almost as fast as native programming,
- to give access to the same features,
- to work everywhere.
- WebGL gives low level access to the GPU. Without WebGL we cannot bring the 3D in the browser,
- WebRTC gives access to the Webcam, this is a basic need too,
- WebXR will give access to augmented reality devices, it is important otherwise we won’t be able to do web programming for them.
So these 3 APIs bring basic capabilities to the browser and they should be implemented. But :
- WebML implements specific machine learning algorithms which may change in the next 10 years. And it is the required time before it could become mainstream,
- Face Detection API is even more specific than WebML…
- Web3Dviewer : an API to display 3D objects (like WebGL based 3D viewer),
- Web3DPose : add pose estimation in the browser,
- WebCollisions : collision engine in the browser,
- WebMatrix : an API to perform matrix computations…
I wish they will never be added to the web browser.
I still strongly believe in web development. I think the browser should become a reliable platform, like a virtual machine, able to execute safely the same application everywhere. It should not become a kind of bloated operating system. The road is still long but it’s worth it. Fortunately standards are better and better applied and I wish one day, we won’t have to implements so many workarounds to take account of each configuration.