you can’t run html without a server, you never could. unless you hack the browser to allow local file urls. in the past you used python http servers and such. if you didn’t then all you used html for was plain text, now having opinions about stuff is fine but i don’t think that would qualify as informed.
writing that whole chapter cost you more time than typing: npm create vite and seeing for yourself where the benefits are.
Those were all some examples from the book, and I was buying the book in order to see how to make those samples. And they were only provided in the npm way. So yeah like, without the book I would have been just, without npm going forward no prob. The cdn way.
I just run local html via localhost.
I did run this stuff. And seeing no benefits and a bunch of added complexity and a change in how I were to work from now on, were I to program like the book’s examples. I became depressed.
Maybe I’m not informed. I don’t know. I only know what I know.
It’s a big universe and especially web development with servers and Threejs and the level of complexity in the world we are in is way beyond what we have evolved for.
Here is a solution to develop locally without using a build tool or local webserver.
Create a file called example.html
Copy the script below into it and save.
Open the example.html directly in your (modern) internet browser.
You should see a spinning multi coloured wireframe cube and can rotate further using the orbit controls.
If you want to start loading locally stored models, images, audio, etc into your code, then you will have less issues using a webserver.
If you use a build tool, it will usually come with a default dev server, HMR and the option to build an optimised version for use in production.
example.html
<!DOCTYPE html>
<html>
<head>
<meta charset="utf-8" />
<meta name="viewport" content="width=device-width, initial-scale=1" />
<meta name="author" content="Sean Bradley" />
<style>
body {
overflow: hidden;
margin: 0px;
}
</style>
<script
async
src="https://unpkg.com/es-module-shims@1.6.0/dist/es-module-shims.js"
></script>
<script type="importmap">
{
"imports": {
"three": "https://cdn.skypack.dev/three@0.151.3/build/three.module",
"three/": "https://cdn.skypack.dev/three@0.151.3/"
}
}
</script>
</head>
<body>
<script type="module">
import * as THREE from 'three'
import { OrbitControls } from 'three/examples/jsm/controls/OrbitControls'
const scene = new THREE.Scene()
const camera = new THREE.PerspectiveCamera(
75,
window.innerWidth / window.innerHeight,
0.1,
1000
)
camera.position.z = 2
const renderer = new THREE.WebGLRenderer()
renderer.setSize(window.innerWidth, window.innerHeight)
document.body.appendChild(renderer.domElement)
const controls = new OrbitControls(camera, renderer.domElement)
const geometry = new THREE.BoxGeometry()
const material = new THREE.MeshNormalMaterial({ wireframe: true })
const cube = new THREE.Mesh(geometry, material)
scene.add(cube)
function onWindowResize() {
camera.aspect = window.innerWidth / window.innerHeight
camera.updateProjectionMatrix()
renderer.setSize(window.innerWidth, window.innerHeight)
}
window.addEventListener('resize', onWindowResize, false)
function animate() {
requestAnimationFrame(animate)
cube.rotation.x = cube.rotation.y += 0.01
controls.update()
renderer.render(scene, camera)
}
animate()
</script>
</body>
</html>
Yeah I always develop without a local webserver.
So it seems the local webserver is to avoid some issues with the assets.
My assets are usually just data in the form of lines of text.
Or small images to use as textures.
because browsers became paranoid about reading local files (which is needed to load 3d models or textures). firefox was the last browser that allowed it, but it ended when somebody abused it to read attachments saved by some messenger app on android by sending an html attachment 
so now you need to run a server
This is the most confusing thread I have ever read on web development. How are the assets loaded without a server, what does the browser make requests to? Why didn’t you buy a book that has different examples?
You can probably get by with a one-line static web server but caddy looks pretty easy:
caddy file-server --domain localhost browse
You’ll also need to disable caching in the browser’s dev settings if you’re changing the files.
No sorry, I use nginx as a webserver, on all my machines.
Its just standard.
But I don’t use those servers which were a part of npm and seemed like the examples only worked with.
I didn’t know the examples in the book were some npm only examples.
If it is any consolation, I have not yet gotten to the point of using NPM.
I write my programs using an html editor.
I can still run some locally - ones that don’t require me to load objects or textures.
Where that is not possible, I simply upload the program to my server and then run it from there.
I have not yet run into an example where something more is needed.
But I am probably missing out on some helpful features like errors checking (beyond what Chrome provides), etc.
Can we all agree at least on one thing? His nginx server has absolutely nothing to do with npm. It’s like if we were discussing tug boats and and types of smoked tea.
I don’t use npm either.
But it’s probably more convenient for threeJS maintainers and large projects users.
the whole repo has become quite large so the use of external tools is understandable to remove some hassle. All these folks are doing it for free, we should not complain about this imo.
As long I can hack my way into it, and revert it back to module-only and no compiler structure, I’m totally fine spending few minutes to customize it. Could be waay worse (like imposing Typescript and other bloated frameworks) 
Exactly, what could go wrong with type safety.
For all those deeply concerned about the potentially exponential bloat of using NPM and other tools such as TypeScript,
see this branch : Threejs TypeScript Boilerplate : gh-pages branch
look at the index.html. It’s almost nothing.
look at the bundle.js that it references. It’s 809kb,
In that one bundle file, there are 5 libraries squeezing into that 809kb.
NPM, and the multitude of tools that you can use with it, are there to help you.
This branch I linked above, is the production build of my boilerplates cannonjs branch hosted using GitHub pages.
I built it by executing these commands
npm run build
npm run deploy
See it working here : Threejs TypeScript Boilerplate : cannonjs branch
Note that It loads almost instantly in the browser.
Nothing would ever go wrong because it’s code. And it’s common knowledge code is always 100% safe.
Would you describe how you implemented that?
A couple of hours ago I posted a question on this forum, whether it is possible to develope three.js displays while retaining my existing workflow using XAMPP als localhost webserver.
What you describe is what I am looking for: a self-sufficient development environment, not requiring internet connnection.
when you install three.js from npm, it downloads these files. you can get very same files directly from github. once you have these at your computer, you can disconnect from the internet.
Disclaimer: read this at your own risk. Many developers would say this approach is outdated and causes more problems than solutions. I tend to disagree, as in some specific cases I find this approach more suitable to my (subjective!) needs.
Here is what I do:
Pros: you do not need internet to develop things
Cons: no local modules/textures/models; no tree shaking; the size will be bigger as the whole three.js is included; difficult to use external libraries that have only module version; if you want to update the three.js version, you have to copy the new files by yourself
<script type="module"> tags and import in my JS code;Pros: you do not need internet to develop things, you have modules, textures and 3D models
Cons: the size will be bigger as the whole three.js is included, if you want to update the three.js version, you have to copy the new files by yourself
Here is analogy of what I do: if I want to send one greeting card, I write the greeting by hand. If I want to send 1000 greeting cards, I use a printer and print them. Of course, other people can do differently, some will prefer to handwrite 1000 greetings; other will advice to always use a printer even for one greeting card.
Thank you for your overview of cases, this allows me to make an informed choice.
I have an addititional question about deployment.
For comparison:
I use JSXGraph for 2D graphics. JSXGraph is a single .js file.
On my website I refer to each instance of ‘graphical applet’ as ‘graphlet’. The multiple graphlets on a page require a single resource: the single JSXGraph file. That is: the browser has to download that file only once.
In the javascript: each graphlet instance is declared with an IIFE.
JSXGraph declares the object ‘JSX’ in the global namespace; all JSXGraph objects/properties are within the JSX. namespace.
My 3D visualizations will contain only a few elements: an example would be a sphere (with meridians and latitude lines), and a dot moving over the surface of the sphere. There will be multiple graphlets on a page.
So for my use-case it is better if for all the 3D graphlets on page/website the visitor’s browser has to download the required .js files only once. It would appear that for my use-case it is better to have a large upfront download which has to be downloaded only once.
I’m guessing the workflow/deployment as described in ‘case 2’ will work like that.
I didn’t understand what is the question.
The size of the things that I publish online is relatively small and I have never been concerned with file sizes, download time, hosting quota etc. My biggest criteria is how convenient is the project for me to develop and for the users to use.
In the past I’ve made some experiments and the difference between one-monolith-file and a-cohort-of-many-smaller-files appeared to be insignificant for the scale of my projects. After all, browser cache quickly eliminates all load-time differences. Thus, the efforts spent to decide which one is better are more than the efforts for using any of them.
Rules of Optimization:
- Rule 1: Don’t do it.
- Rule 2 (for experts only): Don’t do it yet. ”
/ Michael A. Jackson /