A guide to hiring a three.js developer
Three.js is an open source JavaScript library for showing 3D graphics in a web browser. It is built on WebGL, the browser technology that draws 3D on a device’s graphics chip. With it, a team can put a rotating product, a virtual showroom or an animated hero scene on a normal web page, with nothing to install. A three.js developer builds those scenes and keeps them quick. If you want visitors to explore something in 3D instead of reading about it, this is the role to look at.
What a three.js developer actually owns
The work goes beyond showing a model. A three.js developer sets up the scene, the camera and the lights, then loads models and adds controls so people can move around them. They write the code that reacts to clicks, touch and scroll. They also care about the part visitors never see: how big the files are, how often the scene redraws and how the page behaves on a phone that is running low on battery. Good 3D feels simple because someone sweated those details.
Product viewers and configurators
The most common use is a product viewer. People turn an item around, zoom in on details and sometimes change the colour, material or parts. A configurator takes it further and sends their choices to a quote form or a shop. These tools can cut doubt before a purchase, but only if they load fast and are easy to use. A developer helps you decide what to show in 3D and what a simple photo does better.
React Three Fiber
React Three Fiber is a React renderer for three.js. It lets a team describe a 3D scene with components, in the same way they build the rest of a React site. That helps when the scene must share state with buttons, forms and menus on the page. It also needs care. A React developer who is new to 3D can trigger needless redraws, so ask candidates how they keep updates cheap.
Shaders, in plain words
A shader is a small program that runs on the graphics chip and decides how each pixel or point looks. Shaders create effects such as glowing edges, flowing water, soft gradients and smooth transitions. Three.js comes with many materials, so a lot of projects need no custom shader at all. A developer who can write one is useful when you want a particular look, and a developer who knows when not to is saving you time.
Models and glTF
The models usually come from a 3D artist, often made in a tool such as Blender. For the web, a common format is glTF, an open format from the Khronos Group that is designed for loading 3D into apps quickly. A good developer agrees the details with the artist early. That includes the size of the model, how materials are named and how many parts it has. Many delays come from a model that was made for film and then dropped on a web page.
Performance on phones
Most of your visitors may be on phones, and phones are not gaming computers. Large textures, many separate objects and heavy effects can make a scene stutter or warm the device. Developers keep it smooth by reducing the number of draw calls, shrinking textures, limiting the pixel density and turning off costly effects on weaker devices. Ask any candidate how they test, and look for answers that mention real devices and not only a fast laptop.
Working with designers and artists
3D work involves more people than a regular page. A designer decides how the scene fits the brand and the page. An artist builds the models. The developer joins them with code. Agree who signs off on the look, who prepares the files and how changes are shared. A front-end developer on your team can build the page around the scene, while the three.js developer focuses on the scene itself.
How a three.js developer differs from other roles
A JavaScript developer knows the language but may never have drawn 3D. A game developer knows scenes and frame rates, usually in an engine, while a web page needs small files and a quick first load. A front-end developer builds the page around the scene. A three.js developer joins those worlds and works inside the browser. Choose that depth when 3D is part of what your visitors came to see.
The jobs people hire for
One common brief is a product viewer or configurator for an online shop. Another is an animated landing page or a campaign site where 3D tells the story. A third is a rescue, where an existing scene is slow or crashes on phones. A fourth is a data or training tool that shows a model people can explore. Each brief needs a slightly different mix of skills, so say which one you have.
When a three.js developer makes sense
- Seeing a product from every side would help people decide.
- You want an interactive scene in a web page, with nothing for visitors to install.
- You already have 3D models, or an artist who can make them.
- An existing 3D feature is slow, heavy or breaks on some phones.
- You need 3D that fits into a React site and shares data with the rest of the page.
If a few good photos or a short video would do the job, a 3D scene may cost more than it earns. A developer who tells you that up front is on your side.
Reading a three.js developer’s background
Ask for a live scene they built and open it on your own phone. Watch how long it takes to show something, how it feels to drag and zoom and whether the device gets warm. Listen for what went wrong during the project and how they fixed it. A list of library names tells you little, since anyone can type three.js on a resume. The better sign is a scene that still works well months after launch.
Interview questions to try
- How would you keep a scene smooth on a mid range phone?
- What do you check first when a model looks too dark or too large?
- How do you load a heavy model without leaving the page blank?
- When would you write a custom shader, and when would you avoid one?
- How would you handle a visitor whose device cannot run the scene?
The best answers give reasons and an example from past work. Be wary of a candidate who talks only about how good the result looks and never about how it was measured.
Run a small paid exercise
Give each finalist the same small task based on your real project. It could be loading one of your models into a viewer with rotate and zoom, or finding why an existing scene is slow. Pay for the time. Then compare the code, the frame rate on a real phone, the questions asked and how clearly each person explains the choices.
Agree how the work is kept healthy
Agree how code is reviewed, where models and textures are stored and who approves changes to the look. Ask for a short note that explains how the scene is organised and how to add a new model. Keep the code repository and hosting accounts in your own name, with a separate login for each person. Then nothing is lost if the people change.
Settling in
Show your developer the devices your visitors use most, the models you have and the pages where the scene will sit. A weekly call and one shared task board keep progress easy to see. Share the awkward cases early, such as an old phone that struggles or a model that looks wrong, because fixing those is what a three.js specialist is for.
Mistakes to avoid
- Judging a candidate by a video, and not by the live scene on a phone.
- Sending models made for film or games without preparing them for the web.
- Putting 3D on a page where a photo would do the job.
- Leaving page speed and fallbacks until the end of the project.
For related skills, see our JavaScript developers for code that runs in the browser, or our Unity developers when the project is an app or game and not a web page.