For example using this tweening library to animate properties of the object: https://github.com/byrdal/tween-js sure, this can be achieved by just using a plugin, but I think it can be more straight forward as a behavior.
Now I get it, thanks. Well, I thought of implementing it as a behaviour. When I gave it a thought, I realized that a plugin would be much more multipurpose. I'm pretty sure you can see this.
Are you planning to add a callback functionality into your plugin? Sort of an async trigger.
I thought of that too. But I decided that the system of states (that you can implement yourself) is no worse. And furthermore, if I implemented a system of Construct-triggers, you would have to fire them in your js-scripts with "runtime.trigger()". Sounds like API to me. I didn't want not to burden user scripts with that.
Callbacks make a lot of sense in a system where a programmer doesn't do event management — like javascript invoronment. In Construct you have framerate-based event sheets. So just check the state of a js-object every frame and do something if the object's state is legit.
I stand by MVC paradigm. A game object shouldn't shoot a trigger that moves the sprite. A game object knows nothing about sprites, Construct does. Construct should move sprites according to the game object's properties. In other words, a game object shouldn't draw itself. If you want to shoot a Construct trigger that does something that you can't see (changes states, checks the logic...), then don't. Construct doesn't have to do that. Do that right in JS. Construct should only draw things, get user's input and pass it to JS.
In other words, again, if you're using a tweening library, tween the variables in your JS, not the sprites. On second thought, tweening on a js-side doesn't make any sense because it's supposed to be framerate-related.