aframevr
Decreasing the Core code Size by making the mixin an entity instead of having its own element (discussion maybe needed)
I think we can make the overall code of A-Frame shorter, hence better for loading for first time, not sure if this can affect negatively, if we make the core code of an "
if the issues concerning are related to the nested mixins (an entity referencing another entity through "mixin" comp that by itself is also referencing to another entity), we can add a condition to check if the referenced mixin is already an entity that referencing another entity and warn the user (who use inspector/editor) and developers (who directly code)..!
I see many other future benefits from this change, but only if this change does not introduce lots of backward-compatibility issues to the existing projects or we make it clear for the upgraders to adapt their projects to this change by providing a script to automate the upgrading process for existing projects
Sorry I read what you said several times, but I'm not sure I understand what you're talking about here. Do you have a concrete example? Please share with us some html code with the current implementation and the code with proposed changes so we can visualize what we're talking about here. A mixin is a set of components with values to apply, not sure why you're talking about entity or element, an entity is an element. I thought at first you talked about aframe bundle size. Are you talking about the html file size of an experience? Are you talking about a template feature in core? We have a community template component here https://github.com/supermedium/superframe/tree/master/components/template/ Is that you're after?
If the goal is to reduce the bundle size, there are bigger fish to fry. You can use a source map explorer to get an idea, but things like switching to troika text, allowing tree-shaking or unifying systems and components are likely to reduce the bundle size more.
Mixins do introduce quite a bit of code complexity and issues. It would be nice to be able to get rid of this complexity, or at least some of it, see https://github.com/aframevr/aframe/issues/5484 for context. That said, mixins and entities are fundamentally different. I'm afraid that expanding the responsibilities of a-entity is only going to increase the complexity.
I see many other future benefits from this change
Feel free to expand on this. While I personally don't use mixins, I do see their usefulness when declaratively building an A-Frame scene (no-/low-code). If there are ways to make them more expressive/useful that might be worthwhile in and of itself. Seconding what @vincentfretin says, sharing some (pseudo) HTML code that illustrates your idea(s) would help a lot. The technical implementation/details can follow later.
I tried to clarify by editing the description and the comment above, sorry for my bad expression..!
"bigger fish to fry"
I think things like (https://github.com/aframevr/aframe/issues/5615#issuecomment-2609549117, https://github.com/aframevr/aframe/issues/4242 or https://github.com/aframevr/aframe/issues/4010) can take longer time and more efforts, while removing <a-mixin> can be easier (not sure though).
aframe bundle size
yes, it is about the final bundled size.
community template component
is something amazing and promising, in that case, I think removing the mixin completely would be better, because some of the projects are simple and does not need it and for those projects that are large, template component may help a lot.
I'm afraid that expanding the responsibilities of a-entity is only going to increase the complexity
I was afraid of that as well, will try to inspect before I come up with a proposal