Live data from Hacker News

Vue RFC: Expose logic-related component options via function-based APIs instead

github.com

171–180 of 253 posts

Re: Vue RFC: Expose logic-related component options via function-based APIs instead

#171
post #65
post #16

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.

If I remember correctly it wasn't just that angular broke stuff but also that they no longer supported older versions and the wanted to bump major versions multiple times a year. Breaks are one thing, promising constant instability is quite another.

Re: Vue RFC: Expose logic-related component options via function-based APIs instead

#172
post #99

Earlier 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.

More community support than Vue? I’m also confused about the hostility towards Vue by the parent.

Re: Vue RFC: Expose logic-related component options via function-based APIs instead

#173

Earlier 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.

You can use Sapper with v3 already and could for a while now. It's RC for now though.

Re: Vue RFC: Expose logic-related component options via function-based APIs instead

#174

Vue 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…

I just wanted to point out a significant change made to the above document today.

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

#175
Evan, 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 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

#176

Vue 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…

May I request an addition to the Q&A section?

"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

#177
post #148

Earlier 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/

This was literally the exact same pitch Vue made when it came out. The developers get bored and add complexity. Don't get your hopes up.

Re: Vue RFC: Expose logic-related component options via function-based APIs instead

#178

Evan, 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 "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

#179
post #14
post #9

I'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…

I've noticed this example of converted component on the RFC discussion: https://gist.github.com/Akryum/6eff23ae9f7483d6b5151c26d1884...

Re: Vue RFC: Expose logic-related component options via function-based APIs instead

#180

Evan, 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…

I also appreciate Vue's simple elegance. It is a breath of fresh air, amidst all the dust and commotion of the JavaScript ecosystem's tooling bloat and constant reinvention, that Vue can just be dropped in to ant standard HTML page.

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.

Post reply on HN