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.
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.