This needs a complete overhaul

[frostney]

While some of this isn't regarding the core library, the workflow should also be improved and simplified.

Some ideas:

• Webpack
• Webpack Dev Server
• CommonJS
• Remove grunt entirely (scene/prefab generator as Webpack loader)
• Grunt commands should be npm commands instead
• Karma (there's an issue for that)

Things I don't like about the current architecture:

• Hide jQuery away, if possible don't use jQuery at all
• Prefab shouldn't be used in code (Prefab should be inserted in code)
• Backbone/Meteor style event binding (:fire: Breaking change)

I'm also thinking about moving to a more generic XML-style syntax:

<Prefab name="hithere" />
<Layer>
  <Button>Click</Button>
</Layer>

[Polooo2]

Sounds super. Would like to preserve the possibility to include lyria into a project which uses grunt

[frostney]

I'm not sure if I'll use Webpack for bundling the library yet. As for compatibility, I'd probably release the current master as stable in a bit (which is somewhat compatible to the 0.2.x releases) and do a clean cut then.

[Peter-Rene-Menges]

As it's been quiet a while since I've been working with lyria I don't know if this statement is still valid, but: For some parts of the library / framework consider using angularjs. With it's MVC structure it has a build - in template language for the views, a clean separation between the model and the view itself and provides routing components. This would free lyria from the overhead of doing rendering things (which is quiet an development effort itself), provide a template based approach for defining scenes in a way common to many JS - developers (which could increase the number of contributors), and leaving the core functionality of lyria being a framework for developing games.

[Polooo2]

I wouldn't use angularJS at least not version 1. The two-way binding would eat up most of the performance.

[Peter-Rene-Menges]

Habt ihr da mal Performancetests gefahren? Wie lange dauert der Aufbau einer Scene mit Angularjs vs. direkt mit Lyria?

[frostney]

Thank you for your feedback @Peter-Rene-Menges. To be honest if I had known that someone else except me is going to read the issue afterwards I wouldn't have made the initial description sound as brash as it currently does. I feel some context may be missing and I don't want this issue being turned into a discussion about comparing performance of different frameworks.

Lyria in itself has a hard time finding an audience. I've identified these points as potential problems:

1. Mobile first: While stating that is nice, Lyria doesn't do a lot to be mobile first. To be that, Lyria would at least need to support some kind of helpers for responsiveness and animation. (Users shouldn't need to manually avoid non-hardware accelarated transitions.)
2. DOM. With Lyria's first prototype in 2010 and growing into something more full-fledged in 2012, DOM seemed like a logical choice back then. I feel that changed quite significantly: Canvas and WebGL got a lot better across all platforms, even the mobile ones. Would I develop Lyria from scratch today, I would refrain from using DOM.
3. jQuery. Similar to the DOM bullet point, this began out of comfort. I feel if jQuery alone could be removed as a dependency, this would also help in the "Mobile first" department. I feel a bit more negative than ambivalent about replacing jQuery with another framework - be it Angular or any other. While I see some gains here, my concern here is that Lyria might then become too opinionated and maybe even bloated. I'm also saying that Lyria right now may already be too opionated and bloated. Developers that might give Lyria a shot, might get turned away because of the framework being used under the hood.
4. Current audience: Developers who know web development and want to make games without re-learning what they already know. This is currently the niche Lyria goes for. There are a couple of advantages and disadvantages in that. The goal being that web developers should find most of it familiar. The downside is that Lyria will never been seen as more than a stepping stone for a better or more traditional JavaScript game engine. Traditional JavaScript game engines don't provide a view layer or layouting at all, everything is JavaScript usually in some kind of entity-component pattern. A JavaScript game developer would never choose Lyria, as they already grown into using something more traditional.
5. Too much magic: Scenes and prefabs don't use an established module system and somehow package themselves under the hood. It kinda feels like Meteor in that regard.
6. The technology stack is not current enough. ES2015 support is barely given, live reloading is not as live as it should be, using jQuery these days is frowned upon, the JavaScript community is moving away from task runners unless absolutely necessary.
7. I currently don't have a high stake in supporting Lyria as I don't have a commercial project or side project actively using Lyria.

While each of those points is important on its own and some of them are intertwined, this issue is supposed to deal with point six of this list.

I agree that for Lyria to gain more popularity and potential contributors, Lyria needs to have more of a unique selling point either to web developers or game developers. Having a stricter MVC structure might be the way to go here.

As for Lyria's vision and target audience specifically, I'm having a hard time coming up with something absolute. Additionally, I myself prototyped a couple of alternatives that have a clearer vision and fit better for specific purposes:

• flockn: A game engine which abstracts away render backends (DOM, Canvas) and provides a declarative structure for defining a game. Also ES2015.
• moirai: A game engine based on React. Also ES2015.
• I even made a more low-level game engine which concepts are rooted in functional programming which I haven't open-sourced yet

[Peter-Rene-Menges]

@frostney thank your for this clarification and extensive answer. I like the idea behing moira as this pure declarative approach in game termonogy with GameObject Scene and Texture seems to be quiet common amongst developers.