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

241–250 of 253 posts

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

#241

Post by rk06 »

mekoka wrote: post #130

Mixed feelings. I decided to pick up front-end JavaScript a year ago and chose Vue. Although I'm a fan of that specific framework, one thing that I found annoying about the ecosystem (and the great JavaScript family in general) is the "unsteadiness". When I go on StackOverflow and look at questions related to, say, Flask and I see answers dated 2012, I have a sense that although Python has mostly migrated to version…

this is a javascript problem, not vue problem.

Because of libraries are working around javascript's limitation, it is inevitable that they will be as fast and ever-changing as js and js ecosystem is

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

#242

Post by mcintyre1994 »

Vinnl wrote: post #55
lucidone wrote: 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 internal politics at Facebook seem really smart here - the React team have said they’re responsible for keeping all the React code there working and updated when things change with the library. So it’s basically infeasible to make breaking changes that can’t be fixed automatically.

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

#243

Post by crimsonalucard »

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.

Vue is not a clear winner. Clear winner to you, but not a clear winner overall.

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

#244

Post by gustojs »

adevx wrote: post #224

This is painful. I am finalizing a 4 month migration to Typescript using the now abandoned Vue class based decorator approach (including Vuex Decorators) Even though the migration probably is a 50% split between frontend and backend, it looks like a lot of time has been wasted.

I'm sorry to hear that. The class API will still stay with us though, even the current plugin solution will work better thanks to Vue internals rewritten to TypeScript. It won't be as good as the function API, but during the works on a native class API we realized there are problems with classes API that even a native solution wouldn't solve.

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

#245

Post by adevx »

gustojs wrote: post #244
adevx wrote: post #224

This is painful. I am finalizing a 4 month migration to Typescript using the now abandoned Vue class based decorator approach (including Vuex Decorators) Even though the migration probably is a 50% split between frontend and backend, it looks like a lot of time has been wasted.

I'm sorry to hear that. The class API will still stay with us though, even the current plugin solution will work better thanks to Vue internals rewritten to TypeScript. It won't be as good as the function API, but during the works on a native class API we realized there are problems with classes API that even a native solution wouldn't solve.

Thanks, I guess it's a bit early for me to jump to conclusions. I'll just have to wait and see what you guys come up with :-)

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

#246

Post by dham »

asark wrote: post #110
c487bd62 wrote: post #62

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.

If you don't hate front-end period now, mobile's a hell of a lot easier and I think it still pays better than front-end webdev for some reason. As long as you stay away from the web-tech-on-mobile crap and write actual native code. It's especially easier if you specialize in one of the Big Two, but even working on both isn't that bad. I mean, it's not JS "culture" bad. iOS is far and away the saner of the two if you…

I don't quite understand this. Since 2013 React has remained a JS framework and introduced 1 new concept(hooks). iOS programming on the other hand(since 2013) has introduced a new language(Swift) and a new paradigm (Swift UI) for writing interfaces. All to target around 25% of the mobile market.

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

#249

Post by samhh »

lwansbrough wrote: post #86
samhh wrote: post #79

Earlier quoted context omitted.

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

Nobody cares what the motivations are if they can’t update their code base without thousands of hours of work.

This new API is additive and not a breaking change, much like React's addition of hooks.

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

#250

Post by arxpoetica »

ergo14 wrote: post #236
TehShrike wrote: post #235

Earlier quoted context omitted.

See the `customElement` and `tag` compile options https://svelte.dev/docs#svelte_compile Here are the docs from v2 https://v2.svelte.dev/guide#custom-elements

Yes but svelte is on v3 - I'm asking about that.

That first link was to the v3 docs. Here it is again for your convenience: https://svelte.dev/docs#svelte_compile
Post reply on HN