Entity attribute syntax unintuitive

[potch]

The complex CSS-like syntax for some attributes is extremely strange.

For example:

wasd-controls="enabled: true; acceleration: 120"

Do I have to manually concatenate strings to update the acceleration value? Are there special setters?

I think of a-frame as great for beginners and this feels like complexity creep and diverges from the HTML metaphor in a way that isn't self-documenting.

[dmarcos]

we wrap setAttribute and you can do for instance:

el.setAttribute('wasd-controls', { enabled: true, acceleration: 120 });

or to update a single property

el.setAttribute('wasd-controls', 'acceleration', 120);

[ngokevin]

Going through the docs will help in understanding the entity-component system that A-Frame is introducing to the DOM. It's a new concept, but its composability over inheritance is powerful once learned. It's not actually complexity creep, it's actually the core and heart of A-Frame. If anything, helpers like <a-cube> can be considered creep.

If you want to update the component properties programatically, you can do:

el.setAttribute('wasd-controls', 'acceleration', 120);
// or...
el.setAttribute('wasd-controls', { acceleration: 120 });

Further reading: http://ngokevin.com/blog/aframe-vs-3dml/

[potch]

@ngokevin I guess my concern is that for novices, "introducing" non-standard metaphors may be more confusing than it is useful. At some point it's more useful to just have people write script. Or maybe have a <wasd-controls> element with top-level attributes and a target attribute to connect it to an entity?

[potch]

Also a bit concerned about the performance implication of overloading setAttribute, unless it's just using the attributechangecallback to do your logic

[dmarcos]

@potch We actually do all the components update within setAttribute to avoid the asynchrony of using attributechangecallback

[dmarcos]

@potch in reall world applications you will potentially have thousands of entities and thousands of components. I prefer to see an entity and its associated components all in one place. We also explored a child/parent relationship but that results in confusion because you won't be able to differentiate what elements belong to your scene vs their associated components.

[ngokevin]

Yeah, setAtttribute was made to run synchronously.

At this point, A-Frame is nearly a game engine and not just a toy, so naturally there will be some learning curve for traditional web developers. If we learn it, then we can appreciate the composability. There are solid reasons for the new syntax that overcomes the limitations of flat HTML attributes.

The problem with baking the logic into elements is that you lose complete flexibility such that it becomes useful to only a few people. That was always my problem with Web Component libraries like Brick. It looks pretty and succinct from the front, but in the end it's only as useful as the number of elements the maintainer ships and the attributes it exposes.

With A-Frame, if someone ships, say, a Speech Recognition or Physics component, it can be plugged into any existing entity to modify its behavior today rather than having to ship and bake another Web Component.

[dmarcos]

@potch the setAttribute wrapper only affects entity elements. In all the rest of DOM elements the default setAttribute applies

[potch]

@ngokevin I was under the impression the goal of A-Frame was to be a markup-driven way for novices to experiment with VR. If I'm knowledgeable enough to know entity-component, why would I use custom elements? I probably know a programming language and markup-based authoring would only get in my way.

[ngokevin]

Hm, at the moment, I'd say it's for web developers to easily create VR experiences. It's deceptively powerful, and we hope to resolve and improve messaging about it.

The DOM actually works nicely with entity-component. The DOM isn't just for writing static markup, but it's also an interface. It's something web developers are familiar with, and we get interoperability with libraries like React, D3, and Popmotion for free. It greatly reduces the barrier to entry, although there are still concepts to learn.

[ngokevin]

I like this translated-from-German quote from this A-Frame article by @rubenmueller

So far, we have focused in the series of articles to A-frame on the basics and simple areas. It can quickly create the impression that A-frame something for beginners is more and nothing for experienced programmers * inside or larger and complex projects.

Exactly the opposite is not the case: A-Frame enables especially in larger projects a clean structure and long-term expandability. I had already addressed this integration with the React Framework.

[dmarcos]

VR development tools are currently tailored to game / computer graphics developers. Even in JS world libraries like three.js / playcanvas / goo create are more appealing to a game developer wanting to deliver content in the Web than they are for a pure front end Web developer. A-Frame approaches the space from the other side of the spectrum. How can we onboard front end developers into the computer games/graphics domain? A-Frame fills a knowledge gap by letting people reuse some of the concepts and ideas that they already understand (that doesn't mean there are no new things to learn)

1. Entities are DOM elements and represent things that are rendered on screen.
2. Components with their CSS like syntax customize their appearance and behavior.
3. The events API is the same one you already know and use in the traditional DOM.
4. Web inspectors operate as expected
5. And as @ngokevin said. a-frame can easily integrate with existing front end libraries. We don't force people to give up the tools they already know and like.

A-Frame might become obsolete as Web Developers learn new skills. It will be worth the effort If a-frame just helps some people with the transition. Only time will say if a-frame is just an interim solution or delivers long term value. We have a bunch of features in the pipeline that we think enable interesting use cases that no other existing solutions offer today.

[ngokevin]

@potch A-Frame will still have the <a-camera look-controls-enabled="true" fov="80" acceleration="20"> syntax helpers for newcomers. We believe the extensibility and permissionless innovation enabled by entity-component is one of the core values of A-Frame and will not being going away

To help get past the style-like syntax, in the future we will have a stylesheet format for defining component properties.

Seriously, thanks for the feedback! Will be closing as not actionable.