Live data from Hacker News

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

github.com

91–100 of 253 posts

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

#91
Why not release a completely different framework if things are changing so much?

Here's a rule for framework creators... if your framework is changing more than jQuery has in its entire 13 years of existence, save everybody the pain/frustration and just start a new framework.

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

#92

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.

A JS framework that a hobbyist can understand in an afternoon is frequently, but not always, not a framework that works at cloud scale. I support all the choices you make, but there are those of us who have good reason to value useful complexity. <3

JS frameworks have nothing to do with "cloud" scale.

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

#93
post #76
post #66

Earlier quoted context omitted.

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.

You can mix-and-match. If you want to write an individual component as a class you can, and if you want to later convert it to using hooks there's nothing stopping you.

That's not the point.

The point is that most of the React literature available today will become obsolete.

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

#94
post #93
post #76

Earlier quoted context omitted.

You can mix-and-match. If you want to write an individual component as a class you can, and if you want to later convert it to using hooks there's nothing stopping you.

That's not the point. The point is that most of the React literature available today will become obsolete.

How? It's still perfectly valid, usable, idiomatic React.

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

#95
post #36

FINALLY. What took so long? Seemed like we're long overdo for a big syntax change to take up engineering time with no real gain. I should have never left C.

I get your sarcasm, and agree for the most part, but there are some benefits like TS support.

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

#96
post #55
post #4

I haven't done front end work for about one year. Looks like I'll be re-learning everything at some point, because this looks like a fairly major change. I'd strongly prefer backwards compatibility over a breaking change.

I feel like I'm shilling a bit for React over here, but they are nearing two years without major breaking changes, and has been the de facto framework to go to for quite a while now.

React is the major breaking change.

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

#97
post #69
post #31

Earlier quoted context omitted.

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.

You would get Google answers that are specific to your current version vs wondering if it applies to Vue 1, 2, or 3.

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

#98

Quick reminder that you can still write complex and useful form-driven web applications with no JavaScript at all.

Sure, but are there any people or companies who would willingly pay for this kind of web applications?

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

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

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"

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

#100

I'm glad I've held off for this long... almost time to jump in!

You're making the assumption JavaScript frameworks are iterating towards perfection when in reality it's just generational churn. We're still talking about mostly trivial business form apps. Yet they need to be thrown away after 3-5 years because nobody can maintain them, and nobody wants to. Much better to lure young developers with "exciting" (immature) tech.
Post reply on HN