Using THREE with modules - to THREE or not to THREE

Questions
1

In my efforts to update my programs to utilize the latest map conventions, I reviewed the current batch of examples and noticed that:

  • where programs load the three.js library using “import * as THREE from ‘three’;”, all the references to three.js items use the prefix THREE.
  • where programs load only specific three.js items (e.g. AmbientLight), the references to three.js items do not use the prefix THREE.

When I switched to using modules, I also started using the second method in my programs. So I assumed that the elimination of THREE was a feature of modules. However, in the examples, I reviewed, the main programs use the first method (requiring THREE) while the modules use the second method (no THREE).

This seems a bit inconsistent. Is this part of a change that is ongoing? Or is this a feature of three.js? Which is the preferred practice?

1 Like
2

Using import maps eliminates the need of having relative paths inside modules, which are hard to maintain.

When it comes to using THREE, there is a matter of convenience, if you don’t use it, you need to mention all classes/functions/constants explicitly in the imported object. If you import everything then you can use object name (THREE) to prefix w/e you need, which might be a long explicit list otherwise.

I’m not sure if there is any performance difference between importing all (*) and importing specific parts, JS engine should figure out what parts of the library are in use and do not create overhead.

2 Likes
3

Just to be clear, I am not complaining. I think the use of maps, especially the recent addition of “three:addons” is a great improvement - even if it does cause problems with apple devices.

I was just surprised to see that the THREE convention is still being used with modules. And now that I know the rules (or think I do), I have no problem living with this dichotomy. I was primarily interested in determining if there was a plan to change these rules in the future, so that I can anticipate those changes.

4

browser esm is an incomplete spec. dealing with web dev like that, manual script tags and import maps, is self inflicted pain, you will jump from one problem into the next. but this is not how web dev normally functions. javascripts eco system is npm, you normally consume node modules through bundling.

use vite, all the pain goes away. type:

  • npm create vite and you are set up
  • npm install three, now three exist
  • npm run dev now you have a dev environment with hot reload, any change you make in your editor is reflected in the browser
  • npm run build and you have something you can publish, it only contains the code you are actually using, it is the smallest your app can be.

PS

import * as THREE from 'three'
THREE.AmbientLight

import * as FOOBAR from 'three'
FOOBAR.AmbientLight

import { AmbientLight } from 'three'

that is all the same. it’s a matter of convenience or style. there is no “THREE”, you can name it anything you like. it would make sense for you to read up on modules because, yes, everything is a module.

2 Likes
5

Thanks, I will give that a try.

I see your point. The real “game plan” is for everyone to switch to using a programming stack, something like vite and npm. So these interim “issues” are the result of my efforts to avoid taking that final step. (I have been spoiled by the fact that both html and js appear to allow you to run text code.)