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

61–70 of 253 posts

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

#61

Post by pserwylo »

tnolet wrote: 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..

While I don't disagree about the fact it will likely cause a split similar to Angular, they seem quite explicit about the reasons (not to scratch the itch of the framework's designers).

For me, working in a large project with TypeScript vs one in vanilla JavaScript makes all the difference in terms of how maintainable it is. The number and the nature of the tests I need to write for such project changes, the IDE tooling available makes development much more pleasant, and I generally feel like it is harder to write code that is buggy, because a large amount of potential errors are avoided through use of the type system.

Whether or not they've made the right decision with this split is a different question that I can't answer.

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

#62

Post by c487bd62 »

I guess that's my cue to leave front-end programming forever, and my current job (I'm not joking). I've been through too many cycles and it will never end. There's no way I'm staying for whatever crazy migration my company is going to go through again. And we have apps written in every single JS framework ever conceived. Time to learn COBOL.

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

#63

Post by treelovinhippie »

mlevental wrote: post #49
treelovinhippie wrote: post #47

Well that's enough to reinforce my switch to https://svelte.dev I want a JS framework simple enough that even hobbyist devs can understand in an afternoon. React syntax is an overly complicated mess; like reactivity forcing itself onto HTML. Current Vue syntax is neat, simple and clear; like HTML with added reactivity.

but isn't it likely that svelte will undergo the same scope creep eventually?

Hopefully they recognise their niche and stick to it. I'm particularly interested in Svelte for compiling down to vanilla WebComponents to be used in P2P apps (eg Holochain) where you want the end users to be able to modify components themselves.

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

#65

Post by evo_9 »

tnolet wrote: 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.

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

#66

Post by pier25 »

NewsAware wrote: post #41
pier25 wrote: post #21

Earlier quoted context omitted.

Yes, that's what the React team should have done when they implemented hooks.

Well, with React you can "opt in" when searching by simply adding "hooks" to the search term. Such wasn't possible with Angular back then

Since the majority of the community will probably be using hooks from now on it will be assumed that is the default React methodology which will break books, talks, blog posts, SO answers, etc.

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

#67

Post by superasn »

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.

Yes it becomes a nightmare to search Stackoverflow too.

I still get answers for Vuejs 1.0, with suggestions to use 'partials' for example, only to find out that there exists no such thing in Vue 2.0.

This would be very bad for developers if they still call it Vue with another version number.

Even if they call it VueThree, VueNext or similar then the problem can be easily mitigated I think.

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

#68

Post by davnicwil »

quickthrower2 wrote: post #37
pier25 wrote: post #11

Earlier quoted context omitted.

Svelte?

Even better avoid using a framework if you can. Vanilla JS is reasonable for a lot of things.

This is completely true, but in my opinion there's no overlap of usecases where either one of these frameworks or vanilla js are both reasonable solutions. If you have a usecase that vanilla js is reasonable for, using a framework in the first place was just a plain bad choice, most likely.

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

#69

Post by dmix »

tnolet wrote: post #31
dmix wrote: post #27

Earlier quoted context omitted.

The page mentions providing a compatibility build: > “The proposed APIs are all new additions and can theoretically be introduced in a completely backwards compatible way.” One thing they want to avoid is the whole Python 2 vs 3 distinction that went on forever. I’m not entirely sure these differences are that significant but having to merge in all of the data/computed/watch etc options into a single setup() function…

Maybe just call it Nue.js or something

I don’t see how changing the name helps over a version number.

This is changing the syntax for setting up components, somewhat similar to the class API difference, but it’s still fundamentally the same library. It’s largely just moving functions store on the root object into the setup() function while using a more function-y tree-shaking supporting style.

It’d probably cause as much confusion as it helps.

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

#70

Post by arxpoetica »

mlevental wrote: post #49
treelovinhippie wrote: post #47

Well that's enough to reinforce my switch to https://svelte.dev I want a JS framework simple enough that even hobbyist devs can understand in an afternoon. React syntax is an overly complicated mess; like reactivity forcing itself onto HTML. Current Vue syntax is neat, simple and clear; like HTML with added reactivity.

but isn't it likely that svelte will undergo the same scope creep eventually?

Far, far less likely. Svelte has undergone some changes, and will continue to do so, but the latest round of change swung heavily in favor of USING THE LANGUAGE. Most of what you write in Svelte, with some notable exceptions, is vanilla JavaScript.

We in the Svelte world love it so much, it seems highly unlikely there will be any drastic switch from what we've all grown to love. (It's truly fantastic, give it a whirl: https://svelte.dev/repl/hello-world?version=3.5.3)

(Side note: I actually clicked on this link hoping Vue was learning a similar lesson, only to be disappointed.)

Post reply on HN