Web programming is getting closer and closer to native programming. This is due to the performance increase of JavaScript engines and to the new functionalities brought by new APIs. There are among others :

  • 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://gpu in 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.

To quickly illustrate the case of WebRTC, at Jeeliz our JavaScript wrapper which request the video stream from the webcam and launches a callback function has 500 lines of code. We have to process a lot of tests on user configuration, to generate downgraded video constraints and to try them if the provided constraints does not work… If the specifications were correctly applied we would only need 50 lines of code in the worst case…

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.

JavaScript engines are currently very fast and they keep on improving so I am not very worried about this point. But the last 2 points may be contradictory: we need to add new browser APIs in order to add features, but then it would not work everywhere because it will take a lot of time to adopt, standardize then implement them correctly. So I think we should add new browser APIs only if we really have too. For example :

  • 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…

Both APIs implement features which can be efficiently developed using JavaScript/WebGL. The Face Detection API, only implemented on Chrome if we toggle on a specific flag setting, is worse than some web implementations and it has even no interest for augmented reality because it does not detect head rotation. Moreover if this API was implemented in all web browsers, I bet that the quality of face detection will vary a lot between them. Indeed this feature is hard to benchmark objectively.

The web browser should be as homogeneous as possible in the level exposed to the developers. Current APIs are nice because they are low level enough. WebGL, WebAudio are quite low level for example. Then JavaScript libraries manage the higher level as Three.js allows to display 3D models. This is great because the low level is accessible, and I can still use WebGL for processing computation. If we begin to implement higher level APIs which do not add a real new capacity to the web browser we start an endless race. Moreover as we increase the implementation level the number of possibilities grow up exponentially. These are some fancy API ideas at the same level of implementation than Face Detection API :

  • 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.

Conclusion

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.


Xavier Bourry

CTO @Jeeliz