Before I describe what I’m working on, let me link up a small demo that does practically nothing except animate some letters into a grid formation while rotating the whole thing, since we all love to look at things and go “oooooh, aaaaaah” first before reading (tested in Chrome only, needs some polyfills in Safari and Firefox, but that’s not a priority at the momentas much as just making the API work, oh and please don’t mind performance, many improvements planned for little later…):
I’m currently refactoring my code, to make the code base easier to reason about, before finally making the first components with my API (with docs and demos!).
I’m coming up with a multiple-inheritance scheme that will make it possible to refactor my enormous classes so their declarations can go from looking like this:
class Node {
// A freakin' ton of code in here!...
}
class Scene extends Node {
// ...
}
to looking like this:
import multiple from 'somewhere-yet-to-be-disclosed'
class Node extends multiple(ImperativeBase, TreeNode, Transformable) {
// Less code here, re-usable code moved to the other classes...
}
// Scene is not transformable:
class Scene extends multiple(ImperativeBase, TreeNode) {
// ..
}
This refactor exemplifies the top-down approach I’m taking at defining the API. These changes are going to clean up the code base a ton, which I wanted to do before building a component model around the Node and Scene classes. The ImperativeBase defines basic parts of the JavaScript-only API when going the JavaScript-only route, while the MotorHTMLBase class (not shown in the above example) is the foundation for the HTML-based API when opting to write scene graphs using HTML.
I just wanted to mention what I’m working on, and that my efforts are nowhere near dead, and are actually completely alive. Literally all I do on my free time is Eat, Drink, Sleep, Workout (sometimes running trails, other times skateboarding), and work on this project. I am completely dedicated to making the API a reality all the way up to DOM+WebGL mixed mode, with event handling as we’re already familiar with on DOM but applicable to WebGL objects defined by writing HTML, compatible with all the view libraries (React, Angular, Meteor Blaze, Ember’s Handlebars, Riot.js, etc) by the simple merit of exposing Custom Elements using the new Web Component APIs built into browsers (polyfilled for browsers that don’t have it in their “stable” branches yet, as all of them already have work-in-progress versions in their testing branches).