Live data from Hacker News

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

github.com

201–210 of 253 posts

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

#201

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…

Evan I think this is a great experiment. React hooks was an interesting idea and I like how Vue’s approach feels even more reactive (a la observable.com)

There seems to be an overall trend towards more reactivity and I applaud Vue for taking a creative approach to that. Will it stay, and become the da facto paradigm to do webdev? Only time will tell, but I don’t think we should be afraid to experiment with it.

The Vue team have always been excellent stewards of the project. I’m sad to see so much negativity here :(

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

#203
post #79
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.

> with no real gain Did you read the linked motivations?

I did but with no mentions of tradeoffs.

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

#204
post #171
post #65

Earlier quoted context omitted.

Couldn’t agree more, this is the reason I bailed on Angular. Not smart.

If I remember correctly it wasn't just that angular broke stuff but also that they no longer supported older versions and the wanted to bump major versions multiple times a year. Breaks are one thing, promising constant instability is quite another.

AngularJS had it's last major release in 2018 and is in LTS from Google until 2021.

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

#205

It seems like a distant dream where Evan You promised 99% syntax backwards compatibility: https://medium.com/the-vue-point/plans-for-the-next-iteratio... . About a year ago, my team rebuilt a large solar power plant prediction modeling Angular 1 application with Vue.js 2.0. It was the only big bang rewrite I've heard of that was a massive success. I work in Vue.js everyday and swear by it. Mr. Evan You, don't do this…

The new Function-based API is not replacing the current syntax. You will still be able to use your components in v3.

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

#206

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.

Is Svelte 3 production ready? I've been meaning to start a project with Svelte 3, but I'm not sure what tools to use. Is Sapper ready for v3 or is it still mostly on v2? I've also somewhat been hoping that Svelte 3 will get TypeScript support so I can have a typed interface between my Svelte frontend and my Rust backend...

Svelte has been production ready for a while now (I've had it in production for 2+ years).

Svelte 3 was released 2 months ago, but TypeScript support is still in the works: https://github.com/sveltejs/svelte/issues/1639#issuecomment-...

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

#207

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.

Svelte has supported compiling to custom elements for over a year.

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

#208
post #200

Earlier quoted context omitted.

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

Are there any svelte tutorials/examples that specifically target vuejs users?

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

#209
These API improvements (aka potential situation to refactor code within the next 3 - 4 years max) is why I think compile-time frameworks are going to win eventually.

People want to build UI. They don't want to migrate from function components to class components. They don't want to migrate from mixins to HOC. They don't want to migrate from Hooks, to whatever comes next. They just want to build UI by writing code once such that it stays performant and maintainable for as long as possible.

Now is a good time to switch to Svelte / Elm / Whatever. Something that helps me declare my UI layout and behavior with a minimal API, but has a deeper understanding of my intentions. Such that, whatever that is better is eventually a compiler advancement - not an userland API change.

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

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

The last major breaking Vue change was 21 months ago. So react wins nothing in that regard.
Post reply on HN