@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.
Yes, that's what the React team should have done when they implemented hooks.
Vue RFC: Expose logic-related component options via function-based APIs instead
41–50 of 253 posts
Re: Vue RFC: Expose logic-related component options via function-based APIs instead
#42Re: Vue RFC: Expose logic-related component options via function-based APIs instead
#43I might be totally and completely wrong, but changing everything does not help anyone except scratch the itch of the framework's designers. I'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..
The page mentions providing a compatibility build: > “The proposed APIs are all new additions and can theoretically be introduced in a completely backwards compatible way.” One thing they want to avoid is the whole Python 2 vs 3 distinction that went on forever. I’m not entirely sure these differences are that significant but having to merge in all of the data/computed/watch etc options into a single setup() function…
That was overplayed in my opinion by Python 3.2 or so a large percentage of Python 2 code could be made Python 3 code with the addition of: from __future__ import print_function at the top of the file (provided your libraries also went to 3 that is) most people didn't use any of the stuff that was removed.
Re: Vue RFC: Expose logic-related component options via function-based APIs instead
#44Re: Vue RFC: Expose logic-related component options via function-based APIs instead
#45I switched from React to Vue because I didn't like the direction they were going with hooks. Now it looks like Vue is heavily borrowing from the same approach. Slightly upset about that but I guess I'll have to learn the new style. Maybe it will be better in the long run.
You could look into other options like Svelte.
Re: Vue RFC: Expose logic-related component options via function-based APIs instead
#46I might be totally and completely wrong, but changing everything does not help anyone except scratch the itch of the framework's designers. I'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..
To be fair to Angular, if they'd stuck with what they had, it'd have faded into obscurity far more than the current version has. Angular.js was great for its time, but lost most of its advantages as the web caught up, and what used to be its advantages started to become kludges.
Re: Vue RFC: Expose logic-related component options via function-based APIs instead
#47I want a JS framework simple enough that even hobbyist devs can understand in an afternoon.
React syntax is an overly complicated mess; like reactivity forcing itself onto HTML.
Current Vue syntax is neat, simple and clear; like HTML with added reactivity.
Re: Vue RFC: Expose logic-related component options via function-based APIs instead
#48Re: Vue RFC: Expose logic-related component options via function-based APIs instead
#49Well that's enough to reinforce my switch to https://svelte.dev I want a JS framework simple enough that even hobbyist devs can understand in an afternoon. React syntax is an overly complicated mess; like reactivity forcing itself onto HTML. Current Vue syntax is neat, simple and clear; like HTML with added reactivity.
Re: Vue RFC: Expose logic-related component options via function-based APIs instead
#50(And also: with not that much pressure to adopt it. Having a "Standard" and a "Compatibility" build does result in that pressure.)