Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.Sign up
Replace <a-animation> with component form #1927
This is a well-ingrained API, and a lot of people like it. Unfortunately, I think there are too many issues with it that are inherent making
Here are the issues:
are you comfortable with people using https://github.com/ngokevin/kframe/tree/master/components/animation?
honest question: why not move your component into core?
I understand the desire for faster development, but for front-end devs it's not trivial to drop in a component, unless they're comfortable with the command-line + Node/npm + Browserify. (until there's some sort of graceful component loading such as how it works with the Holodeck Club's
I can imagine a third-party component with (even more) stock animations (i.e., canned effects) such as those defined in https://daneden.github.io/animate.css/ but for A-Frame.
Faster iteration is pretty much it. We can bump a component and release it rather than people having to wait at least a month for a new A-Frame. And we have more leniency to include additional features if it were to live as third-party. It also lets us offload work to community so that we so that we can focus on larger things because there are a lot of of costs to keeping this module (documentation, issues, support, bugs).
I think difficulty in requiring a component is a separate and larger issue. But people don't need command-line/NPM/Browserify, it's just a script tag. Front-end devs are accustomed to pulling in code via
I was somewhat on the fence, but I think offloading to community vs. a large batteries-included library is best long term (for now).
Forgot to answer the first question, I'm comfortable maintaining that just as I have
perhaps it's worth finally adopting
That's awesome and reassuring. I can actually see (and am a bit concerned) that
That seems fine. I just wonder where to draw the line. Could go the
Asking these questions because they're things I've wondered myself about A-Frame's vision and strategy. More precisely:
I don't share the worries. Every framework you're going to pull at least one dependency. It's hard to imagine if someone was able to make fireballs or mountains with a component, but were deterred by having to include a
p.s., I also think it's quite beautiful that developers are adopting
Thin vs. large standard library is a legitimate question. I've thought about it over the months, and thin is best for us currently for the long term. It is sort of micro-modules, but I think that isn't necessarily a bad thing for WebVR today to enable open experimentation and to keep bundle sizes down. Component packs like
As we see more necessary things (i.e., link traversal) or unbeatable/must-have components pop up (i.e., perhaps a solid
I think three.js is already like the jQuery of 3D/VR. Grab bag of convenient modules with no opinionated structure.
I think it is possible to get the A-Frame's API in a solid state since we don't have the burden of trying to enable every feature. We can have a healthy ecosystem of components, shaders, controls, primitives, etc. that are all created without hassle through that API. By that point, we should have a good story of where components live. Then we focus less on the API, and more on human-centric tools like a full Editor or VR Editor (although we have the capability to do these things in parallel).
If we all build more scenes and components, we can continue to iterate A-Frame's API as well as gauge what is necessary to include into the core.
Nothing is in the way, necessarily. We're making progress. All the above helps move things along. My itch is having more innovative scenes being built.
(First off, apologies for the wall of text. I'm trying to get in the habit of over-documenting things, as our team is effectively remote as is the A-Frame community.)
Awesome, this all makes perfect sense. Thanks for writing that all up. I can dig it. Personally, as someone who doesn't want to bother with build steps (though I am very comfortable with build systems), I don't want to manually add scripts (
I'm asking these questions – and my apologies for my questioning (and these questions are perhaps better left to be answered in a separate issue in this repo) – in the hopes that we can keep things simple and usable. It's great to keep the A-Frame core small + elegant is great and enable developers to not have to have their components vetted by us. But I wonder if we could borrow some lessons from hapi.js and express.js).
All-in-one editor tools such as
three.js doesn't have a module system (though I know there have been attempts and arguments for/against it), but it could be considered opinionated in that it offers an anti-modular, expansive feature set.
It's certainly frustrated me that with three.js I couldn't just pick and choose modules like I can with customised jQuery/lodash builds (which admittedly causes fragmentation and makes bugs harder to trace, report, reproduce, etc.).
three.js' solution to this problem is to include everything in one giant bundle (though with Webpack/rollup.js, tree-shaking makes the problem obsolete; and also a promising contender has recently entered the ring: optimize.js) and encourage the community to build an ecosystem of examples that also live in the repository.
I agree adoption and ease of use would falter if A-Frame took the same approach. But, I will say that even npm and GitHub are suffering from the problem of "which module does what I want it to, is it compatible with the core library (and the version I'm using), do I have a guarantee that it is and will be well maintained and tested." I've heard from tweets, blog posts, podcasts, etc. that folks at both the companies are working on this problem. Curation helps for sure, but at the end of the day things need to work (most of the time).
I think it's important to support the pro-build folks and the anti-build folks. And, the anti-build folks aren't necessarily JS-naïve; they may instead want to simply invest more time in a scene than searching components, testing components, and settings things up from the command line.
I look at at
I have no doubt A-Frame will continue to thrive with its growing ecosystem of components and abundance of developers creating cool scenes.
I just hope the tools aren't getting in the way. I'm not necessarily advocating a "monorepo" (see this, this, and this), but I wonder if there's a way we can ensure that folks can compose scenes easily without having to worry about compatibility and quality (and build-step complexity).
A fair comparison I'd say is assets. There is a wildly active community of artists out there, and you can find some good assets (paid and free), but making sure they work with three.js/A-Frame out of the box requires a lot of manual work. I know there are steps we can take to automate those steps and reduce those stressors. And, I'm excited to introduce tooling to improve that process.
I just question whether scattering components and creating third-party packs improves or complicates the mental model and scaffolding of what A-Frame is, what A-Frame isn't, and when to rely on third-party modules. IMO, ease of scene creation for developers should be the #1 priority, whatever it takes.
So to bring things back, here are some ideas to solve the problems mentioned above:
There's a bit of a tangent with the pro-build vs. anti-build in the entire comment: build steps are a barrier to adoption. Firstly, there are no build steps. I don't know why Node + NPM + Browserify are being mentioned, they are by no means required nor are they pushed over normal HTML. Secondly, people have no issue including script tags for extra features, we can see this based on how well
That being said, yeah, we can definitely improve the process. And we are! Most of your suggestions sound good, so keep those noted down.
I have no strong opinion about whether
That's beneficial, especially until points 3 and 4 come together. I don't particularly need to sit on
Right now, I am starting to gather un-published components that I think are useful to re-use (e.g., the sun shader example, A-Painter landscape, reverse look controls drag) in K-Frame. Also I'm making it easy to add new things with auto-generated example pages, README, and component templates. As we learn more from this, we'll get a better idea in the future.
I've been teaching workshops/giving talks on A-Frame for 8 months now & I've consistently recommended the
Just wanted to chime in that
I'm going to add this to the
EDIT: Actually, bumped to 0.9.0 after talking to dmarcos.