Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

github.com

Post reply on HN
Print view View original

221–230 of 253 posts

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

#221

Post by swyx »

karaokeyoga wrote: post #174
EvanYou wrote: post #161

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…

very significant indeed! thank you

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

#223

Post by xmprt »

Tade0 wrote: post #216
Can_Not wrote: post #208

Earlier quoted context omitted.

Are there any svelte tutorials/examples that specifically target vuejs users?

I haven't seen any, but as a relatively early proponent of Vue(as in: I was there when v2 came out), I found Svelte even easier to get into than Vue. Anyway Rich Harris' presentation is a good starting point: https://youtu.be/AdNJ3fydeao

God why did you show this to me. Now I really want to build something with Svelte but the project that I'm working on currently is built in Vue...

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

#224

Post by adevx »

This is painful. I am finalizing a 4 month migration to Typescript using the now abandoned Vue class based decorator approach (including Vuex Decorators) Even though the migration probably is a 50% split between frontend and backend, it looks like a lot of time has been wasted.

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

#225

Post by andrewprock »

karaokeyoga wrote: post #174
EvanYou wrote: post #161

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 one option obviously missing is the "Production" build, which ships the 2.x API without any of the fancy new stuff that people don't want.

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

#226

Post by BigJono »

lwansbrough wrote: post #177
Tade0 wrote: post #148

Earlier quoted context omitted.

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.

I don't think it's just because the devs get bored. It's because the users crack the shits if their specific use cases aren't handled, and when it comes to 'frameworks' nobody wants to switch or use anything that's not the most popular, so over time they just get more and more bloated trying to handle more use cases.

It's twice as bad if there's financial incentives for having a userbase (see all the tools not owned by FB/Google etc where the contributors sell training etc) because then it literally pays to add as much crap into your library as possible to try and get as many people using it as you can, regardless of the effect it has on quality. Even if something would make more sense as a fork or alternative, it's getting added in, whether it's good for the library and ecosystem or not.

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

#227

Post by boubiyeah »

karaokeyoga wrote: post #174
EvanYou wrote: post #161

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…

Not sure why Evan is not being more transparent regarding this renaming.

It would be easy to just say "yes, I got a bit carried away with the naming and my big future plans, but the community reaction made me realise perhaps it was not a great idea"

Insead he's like: "what? it was the plan all along :)"

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

#228

Post by boubiyeah »

jrs95 wrote: post #137
pier25 wrote: post #88

Earlier quoted context omitted.

The problem with Angular 1 is that it was slow and bloated, relatively speaking. Google could have improved on that instead of starting from scratch, or ok, start from scratch but use a different name.

Restarting was honestly the best decision, they just had the wrong abstractions in AngularJS

It was! The new result just isn't all that much better. They got trapped in their own bubble of complexity.

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

#229

Post by gustojs »

One of the biggest advantages of the function API is the flexibility it gives for the library authors, making them more powerful and much easier to maintain, so instead of fighting against the API they will be able to focus on new fancy features, better documentation or community support.

This gain will be visible for all Vue developers regardless of which API they use because we all want to have the best quality libraries in our ecosystem.

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

#230

Post by gustojs »

boubiyeah wrote: post #227
karaokeyoga wrote: post #174

Earlier quoted context omitted.

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…

Not sure why Evan is not being more transparent regarding this renaming. It would be easy to just say "yes, I got a bit carried away with the naming and my big future plans, but the community reaction made me realise perhaps it was not a great idea" Insead he's like: "what? it was the plan all along :)"

That's partly my fault. Evan focuses on more technical sides of things but there are people in the team that focus more on the community aspect and we didn't catch that potential naming issue and the whole message that the RFC gives away.

We're all still learning how to work with the RFC documents. We want them to be an important tool for the community but initially, the response from the community was very low. Paradoxically this whole situation made the wider community aware of those RFC documents so hopefully it will go in a good direction. But that initial low response made us believe "oh we have time to sort out things like the phrasing". Turned out it was wrong.

The advice to change the names came from the community and it was a good one. It got support in the core team internal channels and got implemented.

Post reply on HN