I 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..
Couldn’t agree more, this is the reason I bailed on Angular. Not smart.
Vue RFC: Expose logic-related component options via function-based APIs instead
171–180 of 253 posts
Re: Vue RFC: Expose logic-related component options via function-based APIs instead
#172Earlier quoted context omitted.
A few months ago I had to decide between Vue and React/Redux for porting over a very large Angular 1.x app at work (I decided against Angular2+ - mostly because I feel pretty burned by Angular). Seeing this headline made me very glad that I picked React. 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"
Why you didn't considered Ember.js? It is modern, great community support, opinionated and easy to use.
Re: Vue RFC: Expose logic-related component options via function-based APIs instead
#173Earlier quoted context omitted.
Is Svelte 3 production ready? I've been meaning to start a project with Svelte 3, but I'm not sure what tools to use. Is Sapper ready for v3 or is it still mostly on v2? I've also somewhat been hoping that Svelte 3 will get TypeScript support so I can have a typed interface between my Svelte frontend and my Rust backend...
On what I've read, Sapper is still v2. Understandable I guess since Svelte has a small community.
Re: Vue RFC: Expose logic-related component options via function-based APIs instead
#174Vue team lead here. There is a lot of FUD in this thread so we need to clarify a bit: - This API is purely additive to 2.x and doesn't break anything. - 3.0 will have a standard build which adds this API on top of 2.x API, and an opt-in "lean build" which drops a number of 2.x APIs for a smaller and faster runtime. - This is an open RFC, which means it's not set in stone. The whole point of having an RFC is so that u…
Earlier today, there was a "Standard" build and a "Compatibility" build.
The "Standard" build excluded support for "data", "computed", "methods", "watch", "provide/inject", "mixins", "extends", and all lifecycle hooks.
In the updated document, the old "Compatibility" build became the "Standard" build, and the old "Standard" build became the "Lean" build.
Re: Vue RFC: Expose logic-related component options via function-based APIs instead
#175Here's the problem: when Vue was released, people jumped on board because its design was incredibly simple when compared to React, which at the time was heavily focused on the functional, performance based approach to UI development (and to this day, still is.)
If you've got a team that's super focused on performance and loves FP, React is always going to be the better choice. Facebook continues to invest heavily into performance improvements. I can appreciate that you guys care about performance too, but you're now stepping on the toes of the guys who really only care about that one thing.
Performance is not the selling point of Vue, nor is functional programming or any of the other weird changes that have been introduced in this RFC. Nobody looked at Vue and was like, "wow, thank god Vue is 2ms faster than React when you render this benchmark component a thousand times."
The people who adopted Vue are the ones who had first rejected the complexity introduced by React. And now your team is saying "well, this approach is for more advanced users" -- what an insult, honestly. Many of us had the foresight to recognize that the complexity introduced in React was not worth it for our teams, or we had already experienced the problems that such complexity introduces, and we chose Vue because it managed in general to be as effective as React without the fuss.
What Vue 3 seems to be is an answer to the question: how can we beat React at its own game? And congratulations if you've done it, but that's not what your users are here for. That's not what we pitched to our teams, our bosses, our stakeholders, etc.
My question to you is: honestly, how am I supposed to manage this? The long term answer seems to be that I have to change my code base to this new syntax (beyond or during Vue 3), at which point I'll be right back where I started when I decided to leave React for Vue. Do you think this is fair to ask of your users? Are you sure this is what we want?
Re: Vue RFC: Expose logic-related component options via function-based APIs instead
#176Vue team lead here. There is a lot of FUD in this thread so we need to clarify a bit: - This API is purely additive to 2.x and doesn't break anything. - 3.0 will have a standard build which adds this API on top of 2.x API, and an opt-in "lean build" which drops a number of 2.x APIs for a smaller and faster runtime. - This is an open RFC, which means it's not set in stone. The whole point of having an RFC is so that u…
"This API is so different, shouldn't you rename the project?"
Scroll down in the comment threads here and you'll see this question raised over and over again; I think it's fair to say that it is "frequently asked" and belongs in a FAQ.
Re: Vue RFC: Expose logic-related component options via function-based APIs instead
#177Earlier quoted context omitted.
I'm almost done with it as well. I can actually handle the churn and the random rewrites, a lot of them have been marked improvements, that doesn't bother me. What bothers me is when things change in ways that make them more complex than they were before, which also happens constantly. Not only that but I'm sick and tired of tool developers pandering to noobs. Nobody should ever be learning to use a library like Reac…
I'm trying to focus on the good parts of it, like: at least our jobs are safe. Anyway do you have a minute to talk about our lord and saviour Rich Harris? https://svelte.dev/
Re: Vue RFC: Expose logic-related component options via function-based APIs instead
#178Evan, although the proposal as it stands indicates that these changes are slated as optional for Vue 3, the longer term focus is unclear. It looks like the set up to a bait and switch in Vue 4. Here's the problem: when Vue was released, people jumped on board because its design was incredibly simple when compared to React, which at the time was heavily focused on the functional, performance based approach to UI devel…
Second, I think it is over-simplifying the issue by equaling the new API with Complexity. The RFC can be tough to grok because it is dense; but actually looking at some examples will probably show you that the new API really isn't about "complexity": https://gist.github.com/yyx990803/762ec427882a61be3e4affe02f...
Vue has a wide range of users. I honestly don't quite get how introducing an optional API can be an insult - because we clearly see some use cases we ran into can be more elegantly solved with the new API. Maybe you haven't run into them personally, but that doesn't mean your use case is "inferior" - we are all dealing with different types of applications. However, I think it would be a real insult if you think Vue will never have a use case that is complex enough to warrant these advanced APIs.
Regarding your question: feel free to stay with the current API for as long as you wish. As long as the community feels there's a need for the old API to stay, it will stay. The only one that can make the decision to switch to the new API is yourself.
Re: Vue RFC: Expose logic-related component options via function-based APIs instead
#179I'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…
I’m curious what it means for people using single page components and how the default exported module would be structured with the new API. All the examples use the inline template strings. 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() i…
Re: Vue RFC: Expose logic-related component options via function-based APIs instead
#180Evan, although the proposal as it stands indicates that these changes are slated as optional for Vue 3, the longer term focus is unclear. It looks like the set up to a bait and switch in Vue 4. Here's the problem: when Vue was released, people jumped on board because its design was incredibly simple when compared to React, which at the time was heavily focused on the functional, performance based approach to UI devel…
First of all, this new API has relatively little to do with performance. The main performance gain in Vue 3 comes from a new template compilation strategy invisible to users. Second, I think it is over-simplifying the issue by equaling the new API with Complexity. The RFC can be tough to grok because it is dense; but actually looking at some examples will probably show you that the new API really isn't about "complex…
Meteor.js, another project with which you are familiar, started with a similar promise of developer simplicity, but it was subsumed and abandoned in favor of the "Facebook-level scalability for all apps and at all costs" mantra that has swept through the JS community.
Regardless of the nuances of this RFC, please remember the value of simplicity as Vue evolves.