Adopt some ES6 features

[lmcd]

ES6 is coming, with browsers and tools now rapidly gaining support. I think THREE.js could benefit enormously from some of the new features brought by ES6.

For fun and to encourage debate surrounding a possible migration of the project, I've created this issue and created some code examples.

Features demonstrated in the below examples:

• Default parameters
• Block-scoped let keyword
• Iterators + For..Of
• Classes
• Arrow Functions
• Generators
• Modules

Class Example

import Object3D from '../core/Object3D';
import Geometry from '../core/Geometry';
import MeshBasicMaterial from '../materials/MeshBasicMaterial';

class Mesh extends Object3D {
    constructor(
        geometry = new Geometry(),
        material = new MeshBasicMaterial({color: Math.random() * 0xffffff}
    ) {
        super();

        this.geometry = geometry;
        this.material = material;

        this.updateMorphTargets();
    }
}

export default Mesh;

Traversal Generator Example

class Object3D {
    constructor() {
        ...
    }

    traverse(callback) {
        callback(this);

        for (let object of this.children) {
            object.traverse(callback);
        }
    },

    *traversalGenerator() {
        this.traverse(object => yield object);
    }

    ...
}

Generator in use:

for (let object of scene.traversalGenerator()) {
    if (object.name === 'Blah') {
        break;
    }
}

Note: I haven't tested any of this

[benaadams]

Probably a bit early? Support isn't consistently great cross browser: http://kangax.github.io/compat-table/es6/

let not exposed in FF and not in 100% of situations in Chrome and IE.
generators not available in IE
class is only in Chrome, IE12(Spartan) technical preview for Win10 and FF39 which is two above current version.
import isn't available anywhere yet
super is only available in IE12, not IE11, Chrome or FF
arrow functions not in IE11 or Chrome

Also both generators and for-of are optimization killers for Chrome

[jonnenauha]

Imo also too early just for fancier looking syntax. Debatable when something on the list would give noticeable performance gains or code readability benefits. Maybe someone who knows the codebase and ES6 features can comment on that.

[erichlof]

I'm a little late to the ES6 party. This looks like a different language to me. I regularly contribute to Three.js but if it looked like the snippets above, I don't know if I would continue. I just don't have the patience to learn a different-looking and different-functioning version of JavaScript, that basically does the same things as 'new function()' and 'object.prototype', but possibly slower.

Is this what the web community has been demanding of the ES6 language committee? I've been coding for 20 years and the word 'class' does not appear anywhere in my projects (nor will it ever if I have my way). Frankly, JavaScript is starting to look like JAVA...(script). :-\

I'm with @benaadams and @jonnenauha ; too early, and it might slow the code down if Chrome and Firefox don't heavily optimize this new version of the language like they are already optimizing JavaScript under the hood (V8, etc...).

👍

[jonnenauha]

@erichlof Well, I'm actually waiting for ES6 class and module support the most. I'm currently using AMD for my apps. The main JS project I work on is ~10k lines with hundreds of "classes" and AMD is a life saver. Both during development and in producing builds. Imo big or even smaller projects need to have some kind of module system and a way for things to declare what they depend on. It just gets too hairy to manage once you have a complex project structure. It should not be left for the programmed to figure out in what order to put 25x <script> tags. This is just silly once you have the amount of files like three.js does. Most projects resolve this by building one big js file (like three.js) and then there is a random extras/helpers folders where you can include other stuff. This is somewhat limiting and I have to include a ~500kb (minified) build to get ~everything under the sun.

At one point I think three added AMD support, but thats just a small code block that detects if AMD is used and it calls a function instead of effectively declaring window.THREE. I don't know how hard it is currently to make custom builds that would drop functionality that I dont need and add things I want outside of the core and optimize it to a single working file that loads things in order.

You might not have "class" in your projects but if you use object.prototype (like three.js does heavily) it's effectively the same thing, would you agree? We like putting objects together and giving them a purpose. Other code then wants to use said objects and a clean declarative way to import them.

All I'm saying ES6 classes and modules would be a nice addition also to three.js to give it some more structure and modularity for builds. It's wayyyy too early because afaik no browsers support eg. modules yet. Others might say should just start using them and use babel etc. and output ES5 compliant builds, I'm not sure if thats a good idea, but who knows. This makes developing harder, you have to auto start the build when you save files, and debugging might get more complex too. For these things alone I tend to think these transpilers are not worth it atm.

P.S. Was not a rant against three.js, just saying there might be benefits in ES6 for projects like three.js once browser support is there :) and mostly its more syntactical sugar than making it a whole new language. It just will have more stuff.

[jonnenauha]

Another feature that might be beneficial for three.js is WeakMap and possibly WeakSet. I'm not sure about the implications but it seems like this could be used to track things without keeping the GC doing its job if the "owner" no longer holds the ref. There is a lot of state like this in three.js and using it internally might make a difference. It seems to me that this is a bit similar to shared/weak ptrs in C++ to declaring ownership.

A good candidate might be things like https://github.com/mrdoob/three.js/blob/master/src/lights/SpotLight.js#L12 where this could be a weak ref and would get automatically cleared if the target was removed from the scene and collected. But I guess you could not anyway depend on the collection, but would anyway need to null that out once the target is removed from the scene.

Who knows, I'll wait for experts to write some blog posts how all these features might benefit apps in general :)

[erichlof]

Hi @jonnenauha ,

Yes I agree that new features like 'import' and 'export' will be useful, especially where modularity is concerned. I believe that's the direction that @coballast and @kumavis are trying to go with making THREE.js more modular and manageable for custom builds and code-base maintainability. I'm all for modules and re-use of objects and functions, especially when we have a large library format such as THREE.js.

However I don't think that we need the additional syntactic sugar of classes, super, let, for, of, arrow functions, etc.. when we basically get the same functionality in JavaScript now that has been in use for decades and has a lot of traction already. I may be antiquated but I'm with Douglas Crockford when he says JavaScript is already an object-oriented language (meaning functions = objects = first class citizens), but not a 'class'ical one - so we shouldn't be concerned with shoehorning classes into JavaScript. It was designed with a different approach - an approach I was taken aback by at first (coming from C/C++ programming in the 1990's) , but one I agree with more and more every time I sit down to code or try to solve code architecture problems.

Instead of syntactic changes to THREE.js I would rather see migration towards features like the new SIMD programming interface. I think ALL of THREE's Math code (especially Vector3 and Matrix4) could greatly benefit from this. Here's a video link (check out 22:51 in the time code) :
https://youtu.be/CbMXkbqQBcQ?t=1371
When this feature lands in major browsers, every THREE.js user would see a noticeable speedup in their framerate as a result.

Sorry if my earlier post sounded like a rant, I just like THREE.js how it looks now - I can easily select any random part of it and know what's going on, where it came from, and what it uses. :)

@erichlof @jonnenauha I feel compelled to point out that es6 classes are just sugar and they are internally using the prototype mechanism to implement everything at runtime.

I am fairly optimistic that es6 features won't impact computational performance. es6 modules might affect load time when those are finally implemented by engines, because you're fetching a bunch of little files rather than one big file. HTTP/2 might make that a non-issue though. Either way, if we use es6 modules we can use browserify to build a bundle like we always do.

I personally am for using es6 syntax in the codebase as much as possible, because it would make the code more concise and reduce errors. I think many people tend to abuse the prototype chain and use it incorrectly. I don't have a good example though.

I also think sitting and waiting for es6 to be implemented in engines is the wrong idea. Transpilers are available right now that produce good results that run in browsers right now. I think the benefits of doing this are enormous, so we should be impatient and start working on this immediately.

I don't think manually moving code over is a good idea. As Doug McIlroy, the inventor of unix pipes and generally a demigod said:
"Use tools in preference to unskilled help to lighten a programming task, even if you have to detour to build the tools and expect to throw some of them out after you've finished using them."

I would encourage anyone interested in es6 to jump in and help contribute to this repo: https://github.com/5to6/5to6

[gero3]

I disagree on converting the whole library to a different subset of javascript. As always we should discuss what is possible and what the pro and cons are. Because performance is going to differ between versions.

For instance, weakmaps is something that would be a huge gain in the renderers to handle states of objects. It's biggest disadvantages were a weak polyfill and very little browser support and unknown performance characteristics. ( It has been a while since I investigated this, so chances are that this is changed)

And we shouldn't only look at es6. For instance, ams.js would be great as the technology that runs a software renderer. For more info, http://stackoverflow.com/questions/18427810/three-and-asmjs/18439786#18439786.

And we shouldn't forget that most of the contributors are mainly contributing because javascript is familiar and es6 isn't yet for most.

@gero3 Those are good points that I didn't think of. If we are talking micro optimization then I 100% agree with you. I wouldn't want to take advantage of those features without browser support.

Largely what I was talking about above was using syntactic sugar that has identical semantics to existing es5 features, and so could be built with transpilers without affecting performance too much.

UPDATE:
Maybe nobody cares, but I changed my mind. I believe we should not use classes. I still think es6 modules are a good idea.

[lmcd]

I'm totally in favour of classes. I get all the wonderful things the object prototype in JavaScript can do. However, in THREE.js (and many other modern OS projects) we're using prototypal inheritance to simulate classes, so why not have the nice syntactics to go along with it, and get rid of the hacky stuff like:

THREE.Object3D.call( this );

and

THREE.Scene.prototype = Object.create( THREE.Object3D.prototype );

[mrdoob]

As soon as classes are supported in stable Chrome and Firefox I wouldn't mind considering updating the code 😊

[lmcd]

@mrdoob Classes are supported in stable Chrome 42 today and Firefox 39 shipping in June FYI 😊