I always saw VueJS as a successor to AngularJS in that it followed a lot of the same concepts/syntax/etc. that made it really easy to jump into. Now Vue is maturing and becoming more Angular/React like...so it's only a matter of time before another framework comes out that replicates VueJS2/AngularJS in being super easy to jump into and just write code and the cycle repeats.
Vue RFC: Expose logic-related component options via function-based APIs instead
11–20 of 253 posts
Re: Vue RFC: Expose logic-related component options via function-based APIs instead
#12I always saw VueJS as a successor to AngularJS in that it followed a lot of the same concepts/syntax/etc. that made it really easy to jump into. Now Vue is maturing and becoming more Angular/React like...so it's only a matter of time before another framework comes out that replicates VueJS2/AngularJS in being super easy to jump into and just write code and the cycle repeats.
Re: Vue RFC: Expose logic-related component options via function-based APIs instead
#13Re: Vue RFC: Expose logic-related component options via function-based APIs instead
#14I've been following the Vue + TypeScript progress on and off for the past couple years (ever since I converted a React project to Vue and threw out TS in the process, since it was just so fundamentally incompatible with Vue's APIs). This is a pretty wild change compared to the now-abandoned class proposal, and I'm somewhat bummed by it, but I'll admit that's mostly due to my continued skepticism of hooks (as someone…
The primary change seems to just be merging most of the keys/options (data, computed, watchers, etc) of the module into various functions within setup() which itself may require from coding best-practice guidelines since setup() is going to get pretty big.
I’d love to see a largish component converted to be able to compare the two instead of the small examples with one or two functions within it.
Re: Vue RFC: Expose logic-related component options via function-based APIs instead
#15@Vue team if anyone should read this: I'd recommend to rename vue in the process (for example vueNG or whatever) in order to reduce the amount of false/outdated information when searching for a topic.
Re: Vue RFC: Expose logic-related component options via function-based APIs instead
#16I'm pretty sure this is all with the best intentions, but this would be a disaster similar to how Angular suddenly changed everything.
Not against change, but the API is fine. Just iterate and evolve it.
disclaimer: Big fan of Vue, early user and conference attender..
Re: Vue RFC: Expose logic-related component options via function-based APIs instead
#17Edit: Might as well give it a completely new name.
Re: Vue RFC: Expose logic-related component options via function-based APIs instead
#18I always saw VueJS as a successor to AngularJS in that it followed a lot of the same concepts/syntax/etc. that made it really easy to jump into. Now Vue is maturing and becoming more Angular/React like...so it's only a matter of time before another framework comes out that replicates VueJS2/AngularJS in being super easy to jump into and just write code and the cycle repeats.
Scope creep. It's really hard to say "no" to feature requests, especially if hundreds of people give it thumbs up, but it's a necessity if you want to keep your project from bloating over time.
Re: Vue RFC: Expose logic-related component options via function-based APIs instead
#19Re: Vue RFC: Expose logic-related component options via function-based APIs instead
#20I don’t yet have an opinion on the wider changes but this is great. Tree-shaking really helps bring down file sizes and I’m not in the camp of “it only loads once and caches” group that disregard file size these days. And not just because that’s no longer true with async component loading depending on the route/page.