What is three.js?

Render engine


Hi @Fyrestar , could you elaborate a bit on your statement? What makes you see it as a rendering engine? I think of something like PicoGL when i think of that.

I started learning JavaScript at the same time I started learning three.js. I would say from the outside three.js is only as complicated to use as JavaScript is. Having said that I can use blender already so maybe that’s an advantage.

I’m currently using it to make my companies website. Basic stuff… a scrollable affair that people outside of this forum would be impressed by. So in terms of three.js standards it’ll be a 4/10… but in terms of web design… it’ll be up there.

Recently more of our physical event clients have been asking for more digitally complex ‘experiences’. We’ve been installing day/night cycle moving light installations, fake windows with a streamed countryside views, VR experiences and projection mapped walls. We have an event in September that plans to have it’s entire event interior decoration achieved in augmented reality. We think three.js makes sense for that.

I come at three.js from the point of view of someone who would never and probably will never get close to actual webgl. It’s terrifying and I have pretty bad attention span issues. I see three.js as a creative tool and I know that’s going to stress people out.


three.js is a 3d thing.

  • Does it have a rendering engine?

yep, at least 2 official ones (css and webgl)

  • Does it offer an editor?

yep, and it seems to be just as important as the rendering engine, according to some core maintainers.

  • Does it offer VFX?

Sort of, particles, post-processing fx.

  • Does it offer physics?

Sort of, again, judging by the examples, cloth simulation, liquid simulation, integration with other physics engines.

  • Does it offer IK?

Sort of…

  • Does it offer sound support?

Yep, as first-class

  • Does it offer I/O ?

Sort of, there are various camera controllers, drag controllers etc.

  • Is it a language?

Sort of, there’s the node-based shader programming language, there’s the extended GLSL with includes and pragmas

  • Is it a VR toolkit?

I believe so…?

I guess what I’m trying to say, is that I have little idea of what is three.js, I know that it’s not a spoon and it’s not a llama, but that still leaves a few possibilities open.


That a lot of these features being not directly in the core, instead modular is typical for a render engine and i love it this way.

OGRE (object-oriented graphics rendering engine) for example is similar, but even more abstracted.

The choice of name also perfectly fits THREE and it’s focus, and i absolutely love THREE for sticking to this, staying and getting more powerful but also staying flexible to use it for different purpose/kind of engines, from more lightweight viewers to large games.

I wouldn’t worry about some explicit drawer THREE fits in, a render engine can be small and less abstracted similar to the one you mentioned, but also cover a lot basics which can be found in game engines usually like THREE has modulary available.

What i’d like to see would be the examples folder being split into actual examples and a folder for separate features/modules like the posteffects, compositor, controls, physics engine etc.


Hey @Fyrestar,

I get what you’re saying. I don’t mean to say that three.js is :poop:

I like it, heck, I wouldn’t have picked it or kept using it as the rendering backend for my game engine.

What I am saying is - I am confused, and I have been confused for a very long time. What is three.js has as its goal?

Because that matters. What is git? What is Unity? What is a llama? - those things are pretty clear in my head. Three.js - I know what it has, but I have no idea what the core maintainers see it as, and what direction this ship is sailing. And you know what? Having invested a ton of time into it - it makes me worried.

Have you ever gotten onto a long-haul flight with no knowledge of the exact destination when you really needed to be somewhere specific? Well, I feel I have.

I have raised a bunch of issues on github over time, and I can see that some people share my views on what I perceive three.js as, but I also have gotten a distinct feeling through those discussions that @mrdoob and West don’t share my view. In a recent discussion, @Mugen87 stated:

TBH, I doubt that deferred rendering will ever be part of the engine’s core. The resources of the project are limited and there are a lot of other issues which have a higher priority.

I personally think that WebGL 2 as well as WebGPU are a bit overrated. You can already build great applications with the existing technologies. A way more important feature request than let’s say a WebGPURenderer is a more advanced scene editor .

Am I the sole arbiter of what three.js should be? - of course not. For that matter, I am not even trying to steer this ship. But statements like this give me pause. Because that’s really confusing. Based on that statement - I expect three.js to turn into a casual game engine, friendly to most newbies. Graphics quality is unimportant. Advanced feature-set is unimportant. Beyond that - it is not even seen as viable in the scope of three.js.

So… what is three.js? Or perhaps a better question is - what are the goals of the project, and what are the priorities?

Tell me, are you happy with the answer “it’s a 3d library” when you’re picking a graphics engine to use for the next 5 years? I’m not. I like three.js, but this lack of clarity in direction is most definitely not the reason why I like three.js.


It was a reply to pailhead, my ipad sometimes glitches on discourse and jumps around :smiley_cat:

THREE can be a render engine as well as game engine, it just separates the logic and covers in this regard more than a overblown engine like Unity or Unreal, i wouldn’t use a game engine for an app.

yay, adventure!
left to right: @mrdoob, @Usnul


I never said I don’t like threejs, but I share most of usnuls feelings. I’d still like to come up with an understanding of both what threejs is and what it’s intended to be. I don’t share @Usnul’s concerns though. AFAIC three.js could be a space shuttle, or a llama, i’m just being curious.

I don’t get the Rick and Morty reference, but on another topic, could you elaborate what you meant when you mentioned the size of the repo? How does this relate to the library being lightweight?


Do you have some examples of other rendering engines, come to think of it im only familiar with game engines. I thought PicoGL might be one.That one describes it self as “minimal” not lightweight though.

Can you elaborate on this?

Are you referring to the examples, or the way /src stuff is broken up?

@pailhead Rick never gives Morty full disclosure before going on an adventure, which is why Morty is always worrying. Just look at the picture again.

the size of the repo? How does this relate to the library being lightweight?

ah so now you suddenly DO know that all that stuff in the repo does not relate to what 3js is, what happened? did the fuzzy line suddenly sharpened itself in your eyes :smiley:

1 Like

To me three.js is a pretty non opinionated wrapper for WebGL that exposes core graphics programming constructs in a more intuitive way. To that end I expect that if three.js doesn’t do something for you that is possible with WebGL that you’re able to build it on top of the library. My use cases are probably different than the typical three.js user who something like the three.js editor is being built for but I don’t see building the editor as being at odds with my needs of the project as long as long as the library doesn’t become more strict or closed in order to accommodate it.

@Mugen87 mentioned in the other post that he doesn’t see a deferred rendering engine being a part of the three.js core and I’d agree with that. I don’t think it needs to be. You should be able to build one on top of everything thee.js already provides. Three.js shouldn’t impose an optimization strategy on me because the use cases can differ so broadly. People are using three.js for creative coding, data visualization, marketing websites, games, robotics, and more. There is no one size fits all solution for these cases. The more solutions that get imposed the closer you get to something like Unity or other game engines which is not what I want. You can build that on top of three but it shouldn’t be built in. Keep it lean so I can make the decisions. I continue to be impressed with the work people put into the API and its capabilities and if there’s an underlying webgl feature that isn’t available I expect there to be at least a little support in exposing it if you’re willing to put the work in.


“lightweight 3D library” with a repo approaching 1GB :wink:

watch this guy recreating shadertoy in under 300 bytes 14 and cry :slight_smile:

ah so now you suddenly DO know that all that stuff in the repo does not relate to what 3js is, what happened? did the fuzzy line suddenly sharpened itself in your eyes :smiley:

I think statements like this are pretty disingenuous and unhelpful. I don’t think it needs to be explained that you can’t do in shadertoy what you can in three.js. Shadertoy likely just sets up a quad and renders whatever shader gets passed into it so I don’t think it’s all that surprising that it can be so small. And the library portion of three.js is lightweight. Maybe you’re getting at something else but I think your interest in being sarcastic in your posts often obscures your ability to effectively communicate your point.


THREE can be a render engine as well as game engine, it just separates the logic and covers in this regard more than a overblown engine like Unity or Unreal, i wouldn’t use a game engine for an app.

I think I see three.js as a library that can be used at the core of a game engine or that a game engine can be built around it. Things like life cycle behavior, physics, and collisions all need to be handled by the wrapping engine.


Are three.js examples three.js? Most (all?) of these come from someone experimenting with three.js and sharing their results. Some seem more relevant than the others. There is some criteria probably for what makes it “into three.js” ie. the repo and what not? Are some examples more relevant than others, for example OrbitControls compared to Octree?

Regarding the examples I think looking at the history of them is telling. I came to the project late but it seems like a lot of the examples started off as something to show off what you can do with the library but have since been transformed into modular, reusable code. Personally I consider the “examples” folder to be more optional addons or extensions of the core library rather than examples. I think the folder name is a red herring at this point – I think it should be renamed or at least some of the components moved to a more properly descriptive folder like “extensions”. Given that there’s a desire to shrink core further my impression is that unless there’s some technical reason a component within core needs to know about the component (like WebGLRenderer) then it should belong in examples.


People have suggested this many times on the repo but it always meets strong resistance (just from one person I think) and gets abandoned. Feel free to suggest it again though, maybe you’ll be lucky, and you’ll have my support.

In any case, there’s a split - some things are just examples, like say the LightningStrike, while other like OrbitControls or post-processing are certainly more than just examples.

I don’t think your use cases are that different from a current three.js user. The goal of improving the editor is to open up the user base to less technical people.

naaah, the point was about webgl being verbose - and this alone. I do not compare shadertoy to 3js. the rest, well, is just me fooling around ) npm version of 3js has much sane-r size (25MB).

1 Like

I remember there was a person on github who edited auto-instancing into the WebGLRenderer, but the PR was rejected, basically for the reasons you mentioned.
He then proposed to introduce Renderer Middleware - something that would allow such optimizations to be optional, modular add-ons, without adding all the extra size to the core. To me, it makes sense, although Im not sure how plausible that is and if possible, would probably require a lot of work & thought about how to implement a standard for such add-ons.

However it is sweet, to think about a future where a user can import optimization addons best-suited for his/her app, without having to build it himself or bloating the library size with things you dont need :slight_smile:

I wonder what others think about it?

1 Like

or a future where he just uses alterative WebGL renderer. this could be very close future, too. all it takes is just writing one :slight_smile:

In case it’s not obvious yet, I’m more of an artist mindset than an engineer.


I started building the library because I needed it to express myself.
I needed it to create these kind of things.

While creating I saw that there were a lot of computer graphics problems to solve, so I tried to solve them and shared my “solutions” so other creative web devs didn’t have to.

It’s also good to know that, before that, I was using Adobe Flash. Even if Flash was great, relying on Adobe was not. I didn’t like depending on a corporation for expressing myself, so in the transition to HTML5/WebGL I saw an opportunity of building a toolset that would let creative web devs free from having to give your email/password to a corporation in order to get new features. Let alone paying a subscription fee.

I just didn’t expect it was going to take me 10 years, and counting…

So you can think of it as a collection of open solutions for computer graphics problems that work in harmony (more or less).

WebGL2, WebGPU and the editor

It’s easy to get lost by adding features and more features that make graphics more advanced; order-independent transparency, deferred rendering, … These are a bit use-case specific and hard to develop and maintain.

I’m personally more interested in solving problems that allow people to express themselves. OIT and DR do not add “that much” value. People are not going to feel happier, sadder or angrier when playing your game, but it sure will increase the maintenance burden on the library side (unless someone solves it nicely).

Look at what people are doing with DreamsPS4. I’m more interested in facilitating that kind of output and experimentation. I’m more interested in reducing the friction of creation.

But, at the same time, I’m trying to keep an open mind, trying to empathize with the library users and accommodate use cases I could never imagine, and then I look at the maintenance cost of each feature to see if it’s viable or if it could damage the traction of the project.

Having said that, I was planning on working on WebGPU on the second half of this year.

What is Three.js?

Going back to my artist mindset… I see the project more and more like a painting. And in between all of us we paint different parts.

Then you step back and try to explain the painting. A painting means different things depending on the viewer. Depending on your past experiences. Depending on your use case.

Unfortunately, I can’t say what Three.js is, I just know that it helps me create things without too much friction. Seems like it helps others too, but the things they create are very different than the things I create.

I hope this makes things a bit more clear.

PS: So, yes @makc3d… I definitely see the Rick resemblance :sweat_smile:


It is a tool to help you do 3D graphics in JavaScript, by providing a higher level extrapolation of the otherwise intolerably nasty WebGL.

For me it is the core interface for the Future of all Computing.

JavaScript is the winning language, [TypeScript is just a distraction for old school coder to help the bigger corporation thinking make the switch. They unfortunately loose the advantages a typless logic has that helped it win, and oh look python is similar in that way.] Alas that is another topic but the point is JavaScript and NodeJS on the server side leaves you wanting a JavaScript based solution for all your needs.
When it comes to the next wave of VR and AR we can and ultimately will cast aside the old 2D & CSS way of thinking (but not entirely surface mapping and overlays etc.) .

The momentum that the open source community and Mr. Doobs early efforts have made are why I still believe THREEjs is the future and the most important thing to do in computing today.

Sure we all have our differences and it’s mostly inclusive and open to contributions with a firm simple guided core-visionary’s vision. This is why it is not so definable. Anyway if the future as I believe is in community and consensus then you will need to adopt a ‘gray area’ understanding of the world, to understand its components. This project is a perfect reflection of this newer modern way forward for humanity.
It is not always B&W we live in Color now. Take your stenciled one color fax-able logo and maybe you should extinguish it, or not but ultimately you should then bring it to life with an interactive 3D color version via THREEjs! And yes I meant that as a metaphor for perceiving the world in general.

Anyway I was glad to see the question and read the thread. Mr. Doob’s comments were insightful and I related to many of his comments.

I hope you now understand in simple B&W words. “THREEjs It’s a library tool kit to help you do 3D in JavaScript.” In technicolor it’s the future of computer interfaces and a reflection of the new paradigm of OpenSource community consensus. An inclusive versatile JS library tool kit to enable 3D and better visual experiences in the language that has distilled out over the history of computing from all languages into a superior hybrid. So to it can be said for what 3JS is within a much needed niche of enhanced 3D visualization.

Look into Smalltalk creator Alan Kay’s wisdom about longterm thinking to understand anything transformative should have a longer timeline by design. Thinking short term even quarterly is a degenerative stagnant problem for modern corporate mantality that is hopefully being phased out. Lets think ahead to another 10 years and ask what will 3JS be then. Alas that would require another thread but is really an ongoing discussion but as was said no one knew at the time it would have been 10+ years. I ask myself often what would Alan do today if we gave him a billion dollars? The answer I get is in part THREEjs but it is only a critical face forward UI part of something much bigger. What will it be in another 10 years a robust UI to something distilling out of computing in the Cloud server level. Also good things coming out of the inventor of HTML in the solid pods etc. Well that is the most public variation of the decentral grid ideas that I see happening today.


Thanks for the explanation. It does make your position more clear, even if it doesn’t really answer the core question. It’s still helpful to know.

I think that creation is better facilitated with other tools, some of which are built on top of three.js

I always saw three.js as a thing that is low-level, fast, and is an enabler for other tech. You want to build an app and want to visualize 3d stuff? - go for it, you want to build a game and need a rendering engine? - great.

I never saw it as something that a complete newbie in 3d could pick up and run far with. The reason I feel at odds with the project’s direction is that as a fast and low-level rendering library - i feel that three.js is a failure. It has little in the way of optimization, and it rejects or fails to accept features that would make it better as a low-level rendering library.

I feel this is both a really relatable statement and one with little meaning. Why do I want deferred rendering? Is it because the game will look more slick? or is it because it will let me add dynamic decals into the game?

Do dynamic decals make the player “feel” something? Well, according to your logic - no. But they are valuable for gameplay, to mark certain things in the game world. Can I do without? - sure. Do I even have to have 3d graphics? Can my game be done using pen and paper instead? - maybe. Is there a point to this kind of reductionist line of thinking?.. I think not.

Take a game like “The last of us”, it offered a ton of beautiful things, a lot of those things were only possible due to rendering tech, and that beauty? - don’t know about you, but it definitely did make me feel something.

Lets say I want to tell a story about a group of 30 people. Without instancing, showing 30 detailed models on-screen might be hard for some hardware. This means that tech limits my ability to express myself. That PR with auto-instancing you shut down? - that would enable creative people who do not understand instancing to be able to express themselves in the ways they currently can’t.

I started using three.js because it was pushing the envelope, because it impressed me with it’s technological capabilities. I feel that your attitude now and my impression from years ago are at odds. Let’s say that I’m a useless person to this community and the development of this project, but I do believe I am representative of a larger group, if not in my expression, then at least in my attitude towards the project. I would suggest that you that that into consideration.

Why walk when you can crawl, why take flight, why innovate? after all, it doesn’t…

Would I pick three.js for rendering if I was to start a graphically demanding project today, knowing what I know about your attitude and given the state of the “library” - no.

It is a rendering library, a nice one, but it’s not one that faces the technological future.


@Usnul With all due respect but I feel you have misunderstood the aim of the project. It was always an important (maybe the most important) aspect of three.js to support developers with less experience in computer graphics in creating web-based 3D content. Of course it still requires a certain amount of know-how especially when implementing more complex applications. But videos like the following show that even the youngest can work with three.js :blush:.

Providing more high-level, editor-like tools will allow to open up the user base even more. That said, I think it’s not fair to state three.js does “not face the technological future”. Last year for example the project migrated the entire code base to ES6 modules and added TypeScript support. In the next step, the development group tries to find out how to remove legacy code ( examples/js) and adding more ES6 features like classes.

Besides, as mentioned by @mrdoob expect to see some movement in WebGPU and WebGL 2 this year. I’m sure stuff like MRT will land in the core over time. I’m currently trying to improve the support of multisampling FBOs. In this context, I’d like to highlight that our activities actually revealed a bug in Chrome’s multisampling FBO implementation. I would expect that other engines like BabylonJS which already provide broad WebGL 2 support could revealed such browser implementation issues a bit earlier. But obviously not…


I disagree with this. I had never done any 3D work before I came to three.js (well, besides a few days failing to accomplish anything with Unity). I found that three.js inspired me to learn both 3D and web development.

The main issue at the time was that the docs were terrible, and that’s been largely fixed now.

Well, perhaps the question itself doesn’t have much meaning. three.js is a toolkit, it excels in some areas and is lacking in others, just like every other toolkit.

It’s also an open-source, unfunded project, and there’s a limit to how fast development can proceed when every decision must be carefully considered by one person.

It sounds like what you mean is that it’s not facing the future you want.