Here's a rule for framework creators... if your framework is changing more than jQuery has in its entire 13 years of existence, save everybody the pain/frustration and just start a new framework.
Vue RFC: Expose logic-related component options via function-based APIs instead
91–100 of 253 posts
Re: Vue RFC: Expose logic-related component options via function-based APIs instead
#92Well 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.
A JS framework that a hobbyist can understand in an afternoon is frequently, but not always, not a framework that works at cloud scale. I support all the choices you make, but there are those of us who have good reason to value useful complexity. <3
Re: Vue RFC: Expose logic-related component options via function-based APIs instead
#93Earlier quoted context omitted.
Since the majority of the community will probably be using hooks from now on it will be assumed that is the default React methodology which will break books, talks, blog posts, SO answers, etc.
You can mix-and-match. If you want to write an individual component as a class you can, and if you want to later convert it to using hooks there's nothing stopping you.
The point is that most of the React literature available today will become obsolete.
Re: Vue RFC: Expose logic-related component options via function-based APIs instead
#94Earlier quoted context omitted.
You can mix-and-match. If you want to write an individual component as a class you can, and if you want to later convert it to using hooks there's nothing stopping you.
That's not the point. The point is that most of the React literature available today will become obsolete.
Re: Vue RFC: Expose logic-related component options via function-based APIs instead
#95FINALLY. What took so long? Seemed like we're long overdo for a big syntax change to take up engineering time with no real gain. I should have never left C.
Re: Vue RFC: Expose logic-related component options via function-based APIs instead
#96I 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.
I feel like I'm shilling a bit for React over here, but they are nearing two years without major breaking changes, and has been the de facto framework to go to for quite a while now.
Re: Vue RFC: Expose logic-related component options via function-based APIs instead
#97Earlier quoted context omitted.
Maybe just call it Nue.js or something
I don’t see how changing the name helps over a version number. This is changing the syntax for setting up components, somewhat similar to the class API difference, but it’s still fundamentally the same library. It’s largely just moving functions store on the root object into the setup() function while using a more function-y tree-shaking supporting style. It’d probably cause as much confusion as it helps.
Re: Vue RFC: Expose logic-related component options via function-based APIs instead
#98Quick reminder that you can still write complex and useful form-driven web applications with no JavaScript at all.
Re: Vue RFC: Expose logic-related component options via function-based APIs instead
#99I 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..
Edit: Because my comment will probably age poorly, the old headline used to be: "Vue 3 set to change in a big way – Current Syntax to be deprecated"
Re: Vue RFC: Expose logic-related component options via function-based APIs instead
#100I'm glad I've held off for this long... almost time to jump in!