Live data from Hacker News

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

github.com

11–20 of 253 posts

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

#11

I always saw VueJS as a successor to AngularJS in that it followed a lot of the same concepts/syntax/etc. that made it really easy to jump into. Now Vue is maturing and becoming more Angular/React like...so it's only a matter of time before another framework comes out that replicates VueJS2/AngularJS in being super easy to jump into and just write code and the cycle repeats.

Svelte?

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

#12

I always saw VueJS as a successor to AngularJS in that it followed a lot of the same concepts/syntax/etc. that made it really easy to jump into. Now Vue is maturing and becoming more Angular/React like...so it's only a matter of time before another framework comes out that replicates VueJS2/AngularJS in being super easy to jump into and just write code and the cycle repeats.

Scope creep. It's really hard to say "no" to feature requests, especially if hundreds of people give it thumbs up, but it's a necessity if you want to keep your project from bloating over time.

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

#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() is going to get pretty big.

I’d love to see a largish component converted to be able to compare the two instead of the small examples with one or two functions within it.

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

#15

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

This. I like that the Vue team thinks of ways to improve on the current state of the art and welcome new ideas, but please under a different name. It needs to be succinct enough so that search engines can distinguish the two. Otherwise, there is a big risk of things becoming confusing and frustrating quickly.

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

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

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

#18
post #12

I always saw VueJS as a successor to AngularJS in that it followed a lot of the same concepts/syntax/etc. that made it really easy to jump into. Now Vue is maturing and becoming more Angular/React like...so it's only a matter of time before another framework comes out that replicates VueJS2/AngularJS in being super easy to jump into and just write code and the cycle repeats.

Scope creep. It's really hard to say "no" to feature requests, especially if hundreds of people give it thumbs up, but it's a necessity if you want to keep your project from bloating over time.

Yeah I'm not saying it's a positive or negative change. Just an observation. Personally, I'd rename the next version to something else and let Vue be Vue, where Vue was founded as a replacement for the bloated SPA frameworks and super easy to just drop in and use.

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

#19
I switched from React to Vue because I didn't like the direction they were going with hooks. Now it looks like Vue is heavily borrowing from the same approach. Slightly upset about that but I guess I'll have to learn the new style. Maybe it will be better in the long run.

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

#20
> Function-based APIs are exposed as named ES exports and imported on demand. This makes them tree-shakable, and leaves more room for future API additions. Code written with function-based APIs also compresses better than object-or-class-based code, since (with standard minification) function and variable names can be shortened while object/class methods and properties cannot.

I don’t yet have an opinion on the wider changes but this is great. Tree-shaking really helps bring down file sizes and I’m not in the camp of “it only loads once and caches” group that disregard file size these days. And not just because that’s no longer true with async component loading depending on the route/page.

Post reply on HN