I like as well the idea as the annotation-style-API.
However I feel a little uncomfortable in adopting that;
why: I cannot really point my finger on it, might be the stringified-coupling by attributes or some worries about how good this will scale on a complex application...
but basically it's just a feeling and i guess i'll fiddle around with it for a while to get an actual opinion out of it for i like the basic premise of the framework.
Thanks for clarifying. Your concerns sound reasonable. However, using annotations is (almost) optional. Some of devs on my team prefer to bind events with this.$on() notation instead, and work with vanilla querySelectors rather than binding elements to the instance with @el. We could probably introduce a more flexible notation in form of something simmilar to Vue's composition API. However, the library was originally meant to be used by less experienced devs (or less JS-focused creative devs). So I wanted the API to enforce keeping the component's code tidy. By being a little more verbose, also motivates devs to better understand how the whole thing works (wants something to be reactive? declare it!).
When it comes to scaling up on a larger application - it probably won't. And it was never meant to. When my team builds complex apps, we use Vue (and love it very much). We built Ovee to help us write tidy and modern JS when working on designer websites, not large scale apps (like the typical stuff you find on Awwwards). In such scenario, your codebase is much more heavy with CSS, GSAP and WebGL animation code than with business logic. So you manage probably around 20-40 components, and for this scale it shines.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I like as well the idea as the annotation-style-API.
However I feel a little uncomfortable in adopting that;
why: I cannot really point my finger on it, might be the stringified-coupling by attributes or some worries about how good this will scale on a complex application...
but basically it's just a feeling and i guess i'll fiddle around with it for a while to get an actual opinion out of it for i like the basic premise of the framework.
Thanks for clarifying. Your concerns sound reasonable. However, using annotations is (almost) optional. Some of devs on my team prefer to bind events with
this.$on()notation instead, and work with vanilla querySelectors rather than binding elements to the instance with@el. We could probably introduce a more flexible notation in form of something simmilar to Vue's composition API. However, the library was originally meant to be used by less experienced devs (or less JS-focused creative devs). So I wanted the API to enforce keeping the component's code tidy. By being a little more verbose, also motivates devs to better understand how the whole thing works (wants something to be reactive? declare it!).When it comes to scaling up on a larger application - it probably won't. And it was never meant to. When my team builds complex apps, we use Vue (and love it very much). We built Ovee to help us write tidy and modern JS when working on designer websites, not large scale apps (like the typical stuff you find on Awwwards). In such scenario, your codebase is much more heavy with CSS, GSAP and WebGL animation code than with business logic. So you manage probably around 20-40 components, and for this scale it shines.