Vue RFC: Expose logic-related component options via function-based APIs instead
1–10 of 253 posts
Re: Vue RFC: Expose logic-related component options via function-based APIs instead
#2@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
#3@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.
Isn't this half the fun of using JavaScript frameworks?
Re: Vue RFC: Expose logic-related component options via function-based APIs instead
#4I haven't done front end work for about one year. Looks like I'll be re-learning everything at some point, because this looks like a fairly major change. I'd strongly prefer backwards compatibility over a breaking change.
Re: Vue RFC: Expose logic-related component options via function-based APIs instead
#5I 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
#6Please don't
Re: Vue RFC: Expose logic-related component options via function-based APIs instead
#7@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.
AngularJS/Angular split community still have this problem, although less so this year than last.
Re: Vue RFC: Expose logic-related component options via function-based APIs instead
#8I haven't done front end work for about one year. Looks like I'll be re-learning everything at some point, because this looks like a fairly major change. I'd strongly prefer backwards compatibility over a breaking change.
This change is large enough that’ll be looking at the alternatives after more than two years of defaulting to vue, I mean I may still pick vue but I’ll be looking now where before I wouldn’t have.
Change isn’t a bad thing but nor is change for changes sake.
Re: Vue RFC: Expose logic-related component options via function-based APIs instead
#9I'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 who hasn't yet adopted them in my React projects, either).
This will require one hell of a migration path to support and I imagine lots of people will be on that "Compatibility Build" for a long time. I'm very, very curious whether folks who have large-scale Vue apps have had a look at this proposal, and if they've had any input on it.
Re: Vue RFC: Expose logic-related component options via function-based APIs instead
#10I 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.
And nothing new changes.
Frontend webdev is musical chairs.
This is not engineering, its marketing