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

181–190 of 253 posts

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

#181

Post by brylie »

brylie wrote: post #180
EvanYou wrote: post #178

Earlier quoted context omitted.

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

Another article, currently trending on HN, describes how we should strive to reduce cognitive load and simplify the development process:

> A good platform acts as a force multiplier for [development] teams, helping them to focus on core domain functionality through attention to the developer experience, ease of use, simplicity of tooling, and richness of documentation. > https://techbeacon.com/app-dev-testing/forget-monoliths-vs-m...

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

#182

Post by goguy »

lwansbrough wrote: post #80

Python 3 vibes. Terrible decision. Our team has decided after seeing this to use Vue 2.x until we can move away from Vue. Extremely disappointed. Simplicity was Vue’s bread and butter. Literally the only reason to use it over React. Now what’s the point? We get it, you’re a smart guy who likes FP, quit punishing the rest of us.

I'm not a fan of this RFC but how can you make such as drastic decision at such an early stage?

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

#183

Post by kabes »

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…

It kind of reminds me of Meteor's Tracker reactivity system more than react hooks. Since you used to work for Meteor for a short while, how would the 2 compare?

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

#184

Post by DigitalSea »

It's moves like this which make me feel good about doubling down on Aurelia - https://aurelia.io and forgoing the latest trend frameworks and libraries that many seem to jump on and use because they're popular. I was disappointed when I saw Evan and Vue jumping on the "classes are bad, functions are good" bandwagon. There is a lot of misinformation out there about classes in Javascript. If you use them without inheritance (like Aurelia promotes) they're really useful and great. I also admire the fact that Aurelia itself has never had a major breaking change in syntax, I've got Aurelia apps that have been running since 2015 without issue.

I think this undoubtedly means that Vue's private prototype they've been working on will be thrown out and they'll be starting from scratch again, which means Vue 3 probably won't be out for at least another year or more. If Evan and the team proceed with these proposed changes, it'll be the end of Vue.

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

#185

Post by kabes »

lwansbrough wrote: post #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 devel…

> The people who adopted Vue are the ones who had first rejected the complexity introduced by React

I dont know if that's true, I think react is super easy, but I prefer the template approach of vue. I think a lot of people are just searching for a modern angularjs that's not the monstrosity angular 2+ is.

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

#186

Post by scns »

Androider wrote: post #108
AngeloAnolin wrote: post #81

Breaking changes such as this makes me rethink what could be the best approach with regards to front end development. I can recall the time when I moved past Angular when they introduced so many breaking change on their next version. I started using React but was not comfortable enough to keep pace with its progression. Then I found Vue which was a breath of fresh air as this framework has allowed me to deliver end p…

I have a 100K+ LOC project in React started in 2015 that's going strong, and I imagine Facebook has much, much bigger projects than that using React. I can't recall a single time during all these years that something would have broken in a non-backwards compatible way. We're on the latest version of React, writing class-based components (with zero intent to move to hooks) and feeling very good about it.

I think Abramov said they habe over 38000 components at facebook, which is enough reason for Thema to keep backwards compatibility.

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

#187

Post by luismartinezs »

I welcome the added flexibility of this new syntax. This eases encapsulation of related logic within the same block of code, instead of having it spread over different Vue directives.

Plus, at a glance, it seems very easy to pick up and very intuitive.

I also appreciate that you stay away from "javascript classes"

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

#188

Post by luismartinezs »

chupa-chups wrote: post #2

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

How about Vue 3.0?

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

#189

Post by acemarke »

scns wrote: post #186
Androider wrote: post #108

Earlier quoted context omitted.

I have a 100K+ LOC project in React started in 2015 that's going strong, and I imagine Facebook has much, much bigger projects than that using React. I can't recall a single time during all these years that something would have broken in a non-backwards compatible way. We're on the latest version of React, writing class-based components (with zero intent to move to hooks) and feeling very good about it.

I think Abramov said they habe over 38000 components at facebook, which is enough reason for Thema to keep backwards compatibility.

A lot more than that - roughly 100K now. Shawn Wang collected comments from the React team over time showing the growth of React's usage inside Facebook:

https://www.reddit.com/r/reactjs/comments/btx9nq/reacts_grow...

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

#190

Post by tuesdayrain »

EvanYou wrote: post #178
lwansbrough wrote: post #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 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…

In my opinion the old API looks significantly better in every every example here. I really hope you guys figure out a way to better preserve that original simplicity. It was what drew me to Vue as a clear winner in the sea of JS frameworks.
Post reply on HN