How to start using Three.js, local development, when the existing workflow already uses a localhost webserver

I am looking into starting to use Three.js

My current setup is that I use XAMPP as localhost webserver. I have a couple of php commands in use (for instance: I use the php ‘include’ instruction to populate the navigation column of the pages of my website.)

For graphics I use the javascript library JSXGraph. JSXGraph is a single .js file. For local development I have a local copy of it (filename: jsxgraphcore.js)

To deploy I push the (updated) files to my web hosting provider.

It it possible to do local development with three.js, while retaining my workflow using XAMPP as localhost webserver?

The reason I’m asking that:

The installation instruction appear to describe a workflow such that the tasks of managing dependencies and acting as localhost webserver are both assigned to node.js

I have no previous experience with node.js If you answer this question please assume that my knowledge of node.js is limited to the wikipedia description of node.js

My concern is:
Given that I am using XAMPP as localhost webserver, when I use node.js according to the three.js installation instructions, will that result in the two webservers competing to be available on the IP address?

The following earlier question appears related to mine:

Replying to ccammack:

I assume you are referring to your answer in that thread in which you describe importing the necessary files from a remote server

However, my question is about development such that a localhost webserver creates the webpage from files available locally.

Later edit:
I just noticed that the link you posted is to post /34 in that thread. That post /34 in that thread is also about something other than what my question is about. (I rely on a PHP instruction to populate the navigation column of each webpage, so that is a dependency on being able to use a webserver that provides PHP functionality.)


the requirement is to have any webserver, because of browser security restrictions when working with local files. nobody says that the server must be node.js-based.

a web server isn’t enough, you can use that yes, but you will be shut out of the javascript eco system where each and every library that you want to use lives. this is where all the developers share their work. javascript web dev in general is one hundred percent through node and npm, and to consume npm you need something like vite.

the good news is that it couldn’t be easier, xamp is a lot harder to set up and use. just install node, then open your shell and type:

npm create vite
cd yourprojectfolder
npm install three
npm run dev

use any editor you want, any file you change gets refreshed in the browser.

you use three (or any other library) like so:

import { Vector3 } from 'three'


once you want to publish type

npm run build

and it will create a compressed dist ready for upload that only contains the code you actually use.

PS. as for the post you linked, bruno simons threejs journey also uses node + vite. the course where he’s teaching that is free Three.js Journey — Local Server

…to do what? you can even use tools like rollup in the browser without npm and bundle your code XD

I guess Im saying that npm is a matter of convenience. It is linked to from docs because it is the easiest way, but if you hate npm guts you do not have to use it - there is a harder way for you, with a lot of manual file copying.

replying to makc3d:

My concern is:
Given that I am using XAMPP as localhost webserver, when I use node.js according to the three.js installation instructions, will that result in the two webservers competing to be available on the IP address?

I have no objections against any particular piece of software;
I just want to make sure that I will not cause a conflict.

well yes, you would have one at, say, and another at for example. most of them are smart enough to increment a port if default is busy; if they try 8080 and it fails (because you already have a server listening to it) they go and try 8081.

Can this be turned into a usable workflow?

I have tried finding information about the way port numbers are used, but it is rather a specialized subject.

I am aware that there are conventions of assignment of port number; one such convention is the association of port 25 for the send activity of an email client. Generally: different applications, different port numbers.

In my html source I use a PHP instruction to populate the navigation column of each webpage. That is pretty much my PHP usage. Using PHP to populate the navigation column allows me to have a single file for the content of the navigation column, used for every page.

In that sense I am dependent on a workflow that allows me to use a local web server that includes PHP functionality.

I’m just trying to find out: given the way that three.js is organized, is there a way to fit in three.js with my workflow, and if so, how?

I’m not sure why there’s always gotta be so much waffle about npm and vite in every post an OP asks about using three with their preferred way of working and coding, the simple answer is yes you should be able to incorporate three into your php project using your current setup, scroll down till you see option #2 in the installation documentation this will require you simply to have a local copy of the three.js library as well as a local copy of module shims, the process is also well explained and pretty straightforward. Hope this helps with your preference of workflow.

iirc this applies to ports under 1K, and above that it is wild wild west. e.g. wast majority of internet web servers use port 80 (well, pre-https, now it’s like 443-something), so in order to not clash with that, people started using 8080, since they knew nobody else is going to use 8080. fast forward several years and everyone was using 8080 XD so new generation had no choice but to hardcode different default ports - that’s how 3000 or 5000 appeared. if it is not mentioned by 3js docs, you are often able to configure these node.js -based servers to use any port number you want, actually. you could use 9652 if you want to.

I think it is because drmca relies on react/jsx in his 3js-related work, and it is probably quite a pain to do that without npm :laughing:

For sure, that’s understandable and it’s a very useful workflow but when everyone’s at a beach, sunbathing with an ice cream, maybe having a swim and there’s just someone walking up and down the beach shouting about how good snow boarding is trying to get people to join going up the mountain it just becomes noise :rofl: not to offend but I think it’s just not conducive to helping people use three how they need in a support forum…

Here is a quick example of Threejs in a PHP page. Use for reference.

Threejs in PHP : exciting-roentgen-luy0zv - CodeSandbox



The link goes to the top post. The title of the link contained /34, which I have since fixed for future readers.

That entire thread contains useful information about working locally both with and without node and it explains that you’ll need a web server for most situations, offering several web server options other than the one that comes with node. It doesn’t mention XAMPP by name, but web servers mostly do the same things.

The thing is: that thread is dominated by one person ranting. In that thread: separating the wheat from the chaff is far from straightforward.

I had seen that thread in exploration of the subject, but because of the ranting I had dismissed it.

Here is how my preferred workflow would look like:

I would prefer to delegate dependency management to the build tool. The developers have created that build tool for a reason; it seems to me: not using it would be silly.

Webhosting providers do not use node.js as web server; web hosting provides use nginx, or apache, or what have you.

For reasons of workflow: for local development I prefer to use the same type of web server as in use by the webhosting provider. In my case: I happened to start using XAMPP, and I’ve not had reason to change that. XAMPP provides PHP functionality, so it does the job for me.

Thank you for providing that specific example.

Let me give some explanation of where my request is coming from. I am not a professional, I will be using three.js for visualization on my own website.

While I am aware of the concept of javascript import maps, I have no prior experience with it. Up till now there is one javascript library that I have in use: JSXGraph. JSXGraph is a single .js file. So: my prior experience with using a javascript library is minute.

Not having prior experience with javascript import maps I started looking up information about it. For instance, I checked out the ‘Can I use’ resource, which shows when which browsers moved to making javascript import map support the default setting. Firefox made import map support the default setting as of december 2022.

With limited experience in usage of javascript library I would if possible avoid using technology that has only recently been moved to ‘supported by default’ status. (When troubleshooting is necessary information will be harder to find.)

As we know: when trying to coordinate multiple pieces of software: more components => more opportunity for things to not work.

For instance: the link to that page on CodeSandbox that you provided:
I tried with two browsers: Firefox and Chromium: with both I get a throbber in in the rightmost column that says ‘build container image’. But it appears that build fails.

I get it that the three.js developers want to make three.js available in modular form, to make the advantages of that available. On the other hand: it appears the moduluar form introduces dependency management.

I guess not really? It is possible to make a version of three.js library that requires no import maps / imports but it also takes some experience to do that. However, you can use older version of three.js (click “raw” button there to download it) - that one is the last you could just <script src="three.min.js"></script> with no experience. Eeeh I think misunderstood things - they still have this version up.

Can you confirm explicitly that the three.js build you linked to is a version that as you described in the section with the strike-through is an all-in-one build.

For local development, using a localhost webserver, using an all-in-one build is the most efficient setup, it would appear.

(Not necessarily efficient for deployment - I have no way of assessing that - but for me deployment is far into the future anyway.)