How to build 3D web apps. Part 3. Client-side libraries for 3D data display | CAD Exchanger

As was established the last time, for the next few posts we’re going to assume that we’re developing a client-server application with client-side 3D rendering. This time we will see what tools can be used to implement the interactive 3D model display on the client.

Can I use raw WebGL?

This route is extremely time-consuming, and ultimately not recommended for your average web development team. Does it make sense at all? One viable use case for this can be an implementation of a custom high-performance visualization mechanism. Such a mechanism might not afford the overhead introduced by higher-level libraries, while hiding the complexity of WebGL. Implementing high-performance visualization requires optimizing meshes and shaders, reducing the number of draw calls to squeeze all the framerate out of the GPU. High-performance visualization is a must, if the 3D models are truly massive, but luckily there are alternatives to doing custom renderer from scratch, as there are commercial projects providing such tools (e.g. Zea).

What JavaScript 3D library to pick?

Fig. 1. CAE and BIM are two of the areas where domain-specific visualization tools, aimed at the datasets of the respective areas, can be helpful to app developers.

An alternative approach would be to use a domain-specific tool. There’s a number of CAD and BIM data display, scientific visualization and other libraries. They typically provide extra features specific to their areas: loaders for domain-specific 3D formats, ready-made primitives to display domain-specific 3D object types and tools, customarily used to manipulate the objects. Thus, if the domain-specific application’s functions fall in line with the general needs of its potential users, they can potentially save lots of development time. We won’t cover them in detail here, as discussion of these tools is out of scope for this post.


Fig. 2. Three.js main page, showcasing projects built with the library. Some of these are built by big and famous organizations, such as NASA, Apple, Oculus and Maserati.

Three.js tries to strike a balance providing as much useful functionality as needed, while being fairly lightweight and minimal. As a result, some capabilities reside not in Three.js itself, but in third-party plugins for it: notably acceleration data structure for object selection, text and UI controls, some format loaders and others. Another consequence is to implement custom workflows (e.g. importing meshes from your own format), one needs to use some lower-level Three.js objects — buffers and buffer attributes. They are still not as tedious as raw WebGL, but are more technical than using primitives or built-in loaders and require a certain level of understanding of graphical programming.


There are also a few tools, which can speed up the development process. Babylon.js provides a complete 3D model viewer that you can just drop into your web page without having to write any code at all. There’s a visual material editor, which comes in handy when experimenting with implementation of custom shaders, or if you want to make a custom material without writing shader code altogether. There’s also a Playground, an online environment useful for prototyping ideas without having to create a separate local project.

Fig. 3. The Babylon.js material editor, allowing creation of custom materials without the use of a shading programming language.

Three.js vs Babylon.js comparison

function animate() {
requestAnimationFrame( animate );
renderer.render( scene, camera );

Meanwhile, in Babylon.js there’s a massive class Engine among whose responsibilities is managing the loop:

const engine = new BABYLON.Engine(canvas, true);
engine.runRenderLoop(function () {

So, Babylon.js provides many helpful abstractions with predefined behavior, often making it more convenient to use. This comes with the cost of a heavier package size, coming in at more than 3 MB minified, compared to just 300 KB for the entire Three.js. Both can be used in the form of ES6 modules, allowing to utilize tree-shaking for smaller package sizes. For example, Babylon.js could be reduced to a few hundred KB (depending on the scope of objects used), but that will likely still be more than the Three.js. Because of that for lightweight apps, such as simple asset displayers, it makes more sense to choose Three.js over Babylon.js.

Three.js and Babylon.js also have different approaches to the development: the former releases new versions frequently and sometimes breaks the API, while the latter prioritizes backward compatibility, so its API is significantly more stable. Practically this means that it’s easier to migrate to newer versions with Babylon.js, whereas with Three.js it’s probably better to just fix the version you used in your app, and only update it if the new one adds something vital later.


Next time we’ll consider the backend of a 3D web app, its responsibilities and the influence they have on the implementation choices.

Find out more about CAD Exchanger visualization library and request a trial here.

Learn more:

How To Load 3D CAD Data Into Three.js. Part 1

How To Load 3D CAD Data Into Three.js. Part 2

Building 3D web applications with CAD Exchanger Web Toolkit

Next parts:

Part 4: Backend of 3D web apps

Originally published at on December 8, 2021.



CAD Exchanger is a technology that enables data exchange in the multi-CAD world.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
CAD Exchanger

CAD Exchanger is a technology that enables data exchange in the multi-CAD world.