Status update and demo: code cleanup to be followed by docs/demos

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).

1 Like

This is very interesting @joe. Glad to see you moving forward on a famous replacement.

Curious though, how does this compare to the Samsara effort? Is there synergy there? In looking for a famous replacement going forward I’d like to know the pluses and minuses.

Personally, I’d like to see an all JS approach to dynamic GUI. Preferably with an abstracted DOM, so that it can be migrated to other platforms, i.e. mobile.

Congratulations on your progress!

I think you’ll have a better answer to that question once I have soe docs/demos, then you can compare. It won’t be too far from now.

Me too, and this is exactly the sort of thing I’m aiming for, to make the API flexible and many parts of it re-usable in different environments (though I personally will be sticking with Web for my personaly projects, at least for now). Famous 0.5+ API was abstracted in such a way that, as you see in this GitHub issue that I wrote, I was able to imagine Famous engine running in the QML JavaScript environment, but instead of Nodes having DOMElement components they would have QMLRectangle components (Note, a DIV is to HTML as a Rectangle is to QML, both are quad surfaes in their respective engines). As you can see in the example code there, there is a conditional if-statement that creates one component or the other based on the detected environment. Another possibility could be to have the library running in Android, iOS and Universal Windows Platform by using React-Native’s JS environment or using Nativescript, where a “surface” (I don’t know the specific class names they’d have in each environment, but I assume each environment has it’s own quad primitive).

So yeah, it’s still a little ways before we get to that point, but in general I’m keeping in mind to develop the API so many parts of it are re-usable in any JS environment. :]

Small update: A new website/rebrand is in progress. Docs are actually coming soon here (though the new URL will different, and that old one will forward to the new one). It currently has installation steps and a few examples, but a complete guide and API docs are coming soon!