Awesome game.

[trusktr]

Hey guys, awesome game! Love it!

One thing that I would love to see in future project is more markup. Maybe you guys can adopt React or Angular for a future game/project, and manipulate a-* elements with them for things like adding/removing game objects from scenes or from game objects (sub scenes). The markup-based approach would place those objects into the DOM hierarchy with initial attributes, then plain JS can take over during the lifetime of the elements (f.e. to animate things, game logic communication, etc).

Currently there is a ton of JavaScript used for A-Blast (which isn't bad at all), but I think using more markup (for example React components for changing DOM structure and simple attribute modification, but not for animation because that would run React's diff algo every tick) would really show and promote the declarative 3D paradigm that A-Frame introduces, which I think would be really really awesome in general for this type of technology (declarative 3D), while using only the minimal required amount of imperative programming.

But yeah, excited to see what comes out next!!

[trusktr]

What I mean is, in the language bar:

It would be awesome to see the HTML portion increase as much as possible and the yellow bar decrease and much as possible, with the objective being to promote as much declarative code as possible and saving JS for last (for example maybe physics in JS, or an animation loop in JS after a component is mounted). If you were to use Angular for example, all components' markup could be stored in .html files.

But yeah, I'm just writing about this with a more general thought in mind; I would love to see more declarative 3D in the world, and I think you guys can help the world to have more of that! 😄

In the meantime I'm doing my part to help the world have more declarative 3D over at github.com/trusktr/infamous, but I have a ways to go. I'm in the process of adding WebGL-from-scratch to mine. I've dug myself into the rabbit's hole!

[ngokevin]

A-Frame wasn't meant to be build everything 100% in HTML. It's a full-fledged framework/engine that uses HTML/DOM as a base structure. I need to modify the docs to re-iterate it's not a vanilla declarative 3D language like X3DOM, VRML.

While 90% of the project is JavaScript (which is approriate because there are a lot of 3D/VR and application-specific pieces), all of it is built with components, meaning they could be used from HTML (or via .setAttributes which counts as DOM as well). As the ecosystem progresses, more components will be formed, allowing more to be done in simpler ways, but there'll be a need for JS somewhere in complex applications.

React/Angular are nice (I have heavy experience with both), but they weren't made for 3D/VR so it's natural they potentially aren't the best solution and introduce overhead. They can do data binding and state management, but that can be easily managed in less intrusive ways.

[trusktr]

A-Frame wasn't meant to be build everything 100% in HTML.
it's not a vanilla declarative 3D language like X3DOM, VRML.

True true, it is impossible to have game logic 100% in HTML unless you were to make HTML custom elements that act as code, f.e.

<function name="blah">
  <var x="true" />
  <if condition="x == true">
    ...
  </if>
</function>

but that would be ludicrous, hehe.

But, I definitely see more opportunity in A-Frame projects for markup that can be manipulated dynamically and declaratively to morph scene graph structures. For example, suppose we have a simple game written in React, here's a super basic idea about adding/removing enemies from the scene

class Game extends React.Component {
    constructor() {
        this.state = {
            enemies = [] // put default enemies here.
        }
    }

    render() {
        return (
            <a-scene>
                {/* ... render static stuff here, like what you do in
                    index.html currently.  But some parts can be dynamic, like
                    ading removing game objects: */}

                {this.state.enemies.map((enemy, index) =>
                    <a-enemy type="cutest-creature-in-the-universe" onHitByBullet={() => this.onEnemyDestroyed(index)}>
                    </a-enemy>
                )}
            </a-scene>
        )
    }

    onEnemyDestroyed(index) {
        this.state.enemies.splice(index, )
        this.forceUpdate() // re-render
    }
}

The concept here is that adding/removing enemies is just manipulating the DOM by re-stating what the DOM should be, declaratively.

Currently, A-Blast uses imperative JavaScript to to morph the scene, whereas with React you would simply describe what should be in the scene declaratively depending on any given state.

Of course, there's still JavaScript required, like manipulating the enemies array with an event handler. Things like bullet hit testing, physics, etc, would still require imperative JS; the React render function doesn't render physics logic, it only renders declarative structure.

This type of thing is the new paradigm that Angular, React, etc, give to us: to manipulate declarative structures with JS, avoiding entirely imperative description of tree structures.

I believe that if you can make some projects using Angular or React to dynamically morph your scene structures, it will be a win/win because it will show those Angular/React users how easy it is to start using A-Frame inside their framework, and it will in turn draw those users to A-Frame. Those users will be drawn to A-Frame if they know they can use these new paradigms. WebGL has a high barrier of entry, even with Three.js, because entire applications have to be written entirely imperatively. HTML alone makes things easier, but default HTML/JS in browsers means imperatively manipulating the DOM. Angular, React, Handlebars (and similar libs) maximize a developer's ability to declaratively describe how a declarative structure changes while still taking advantage of declarative programming as much as possible.

Imperative programming will always be needed, forever, but I believe that it can be minimized while achieving the same effect, and making structures easier to reason about (f.e. a scene written with a-frame elements).

React/Angular are nice (I have heavy experience with both), but they weren't made for 3D/VR so it's natural they potentially aren't the best solution and introduce overhead.

True, but A-Frame gives the declarative layer that those frameworks can manipulate. Of course, one should not rely on those frameworks for things like animation; React's DOM diffing will kill the animation loop in more complex cases (it still works great in simple cases, especially for animating only one thing at a time like is common in UIs). Angular and React can be used to merely describe the structure of the tree in a dynamic way (adding/removing node) while animation overhead can be minimized by writing imperative code (or even declarative code if you provide custom elements to describe animations).

TLDR, you guys can replace the imperative manipulation of the scene graph with declarative manipulation, and it won't impact performance if done right.

[trusktr]

To further the point, I think maximizing declarative manipulation of a scene if important in promoting the concept of A-Frame, because there's already Three.js, physics engines, etc, that users can already use for imperative 3D programming, and I believe that A-Frame's strong point is declarative 3D VR.

[ngokevin]

DOM diffing has a performance impact on each update. A-Frame directly manipulates three.js objects, there's very little in between. When you did the mapping over the enemies, that can be inefficient since you'll be creating + recreating entities versus doing something like object pooling. It's things like these that can expose that React or other frameworks make you ignore the best solution.

I understand what you're saying. I used React pretty early on and stuff like Redux on the day it was released. I fully get all the concepts. That's what we have aframe-react as an option. There's no stopping people from using React, Vue.js, or Angular. We prefer to focus on A-Frame itself to improve it and discover its own patterns rather than get distracted by trends.

A-Frame has JavaScript, but in the end of the day with components, it's still mentally declarative. The components are modular and can be used declaratively. A-Frame provides a strong structure for three.js, that's what frameworks do. They don't eliminate the work, they make it easier to reason about. It's the exact same with React, you structure things "declaratively", but it's still all JS.

Framework are nice for web developers, but the people that can understand React/Angular ecosystems are a minority of possible developers for VR. Other audiences such as game developers, artists, common users don't care, and from what I've seen, they're more equipped to build compelling VR scenes than the standard web-dev.

[cvan]

@trusktr @ngokevin Thanks for the feedback and discourse. Very valid points brought up.

I'm sure if there are pull requests, @fernandojsg (and @caseyyee?) would be able to shepherd code improvements. A-Blast is a pretty darn impressive demonstration of what's capable with WebVR (mobile included!). With that being said, any improvements to the developer ergonomics, readability, end-user usability, and loading + performance would be a blast to add.

[trusktr]

DOM diffing has a performance impact on each update.

That may be true, but then we may as well not use custom elements, and just use imperative javascript the whole 100% rather than 99%. Otherwise the declarative benefit of HTML markup isn't really being used to it's fullest and it isn't making dev easier if most code still has to be imperative anyway.

Just imagine replacing a React application with entirely imperative vanilla JS code. The developer productivity would take a nose dive.

Yes, using React instead of vanilla JS is slower, but the benefit is big gain in productivity, and for specific use cases the performance loss is perfectly acceptable, even in 3D applications.

The developer productivity is the purpose of declarative programming.

In my opinion, using declarative code in only 1% of the code base (for the application bootstrap) is hardly improving developer productivity, and the barrier of entry is still high if an HTML developer can not really take advantage of HTML if you tell the they need to write 99% imperative code for describing their 3D scenes.