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

191–200 of 253 posts

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

#191

Post by cush »

tuesdayrain wrote: post #190
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…

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.

What better way to preserve it than to just keep it, and not change it?

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

#192

Post by dessant »

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…

> Compatibility

That's a clue for where the Vue team's mind is regarding the current API. Compatibility to me reads like legacy. That's in contrast with the claims above that this is just a new optional API to serve a broader range of use cases.

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

#193

Post by ergo14 »

treelovinhippie wrote: post #63
mlevental wrote: post #49

Earlier quoted context omitted.

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.

Sorry, but seems Rich is not too happy with WC', if you want to do use a compiler to vanilla WC's I think stenciljs might be your best option. LitElement is also good - but it is not a compiler. Svelte V3 doesn't even have custom element section documented at all at the time of the writing.

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

#194

Post by hinkley »

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…

And people are voicing their opinions. Hope you’re taking notes

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

#195

Post by indalo »

tuesdayrain wrote: post #190
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…

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.

your comment lead me to take a look and I have to say I agree. it looks denser but feels more cryptic. sure hope it remains optional.

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

#196

Post by hinkley » 

    // expose bindings on render context
    return {
      count,
      plusOne,
      increment
    }
No, this here is why you want classes. On a large project you are going to have multiple people touching contiguous code. This block is going to have several pages of code between it and half of the declarations and that kind of ping pong is no big deal for a limited percentage of the Dev population but is NOT trivial for everyone else.

There’s a difference between having a problem and admitting you have a problem and lots of devs trip up on code constructs like this on a regular basis. It’s double data entry and that is bad. It also hamstrings editors, adding friction to discoverability. All things I shouldn’t have to explain to a framework writer but constantly find myself having to soapbox.

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

#197

Post by leadingthenet »

stupidcar wrote: post #87
the-pigeon wrote: post #54

Earlier quoted context omitted.

I don't know. I prototyped with Angular and it just seemed like one of those approaches that sorta made sense verbally but not at all on paper. Like trying to take jQuery and make it a framework like React. But in their attempt to make it "simple" they made it useless. And then the next generation of frameworks like React came out and basically killed it.

You may not like it as a technology, but one search on recruitment sites will show you that it's far from dead.

Seems almost completely relegated to .Net shops though, at least where I live.

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

#198

Post by conta »

dfabulich wrote: post #176
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…

May I request an addition to the Q&A section? "This API is so different, shouldn't you rename the project?" Scroll down in the comment threads here and you'll see this question raised over and over again; I think it's fair to say that it is "frequently asked" and belongs in a FAQ.

I would love to see their answer to this but my guess is that it would be: "Nope. See Semantic versioning (semver.org)"

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

#199

Post by Devasta »

While I can appreciate its their project and they can do what ye want, at least have the fortitude to admit the 2.x API is depreciated. Please, no nonsense about compatibility builds, anyone who uses one of those might as well accept becoming this generations VB6 devs.

We don't all work as freelance webdevs or in some startup. I work in a bloated, slow, soulless financial services firm; depreciating now or depreciating in 3-4 years as part of Vue 4 time might as well mean you're depreciating next week; it'd be the height of irresponsibility for me to use Vue for a new project knowing I would need to refactor everything, I'm going to have enough code to rewrite as a result of this as it is.

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

#200

Post by Tade0 »

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'm aware of that - hence the form of my previous comment.

"This time it's different" though.

The difference being: this here is radically less complex and unlikely to become much more.

All this complexity in frameworks was always added in a vicious cycle, namely:

1. Developer looks at a component - they see complexity.

2. They don't know how much of it is due to the business logic being complex and how much is introduced by the framework, which has to deal with the limitations of the platform, so they assume it's the latter.

3. To deal with this they create yet another abstraction and an associated convention, which makes one problem better and a good few others worse.

4. Other developers see the examples and figure that this new method indeed solves that one problem, so they adopt it.

5. The result is ever increasing complexity.

Enter Svelte(and similar technologies): it's not a framework, but a compiler - it doesn't have to play by the same rules, so it (eventually) avoids framework-related complexity.

It's noticeable in the way how Svelte 3 ditched setState() altogether and replaced it with simple variable assignment.

Post reply on HN