Vue RFC: Expose logic-related component options via function-based APIs instead (opens in new tab)

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

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 users can voice their opinions. It's not like we are shipping this tomorrow.

For more details, we added a Q&A section at the top of the RFC to avoid further confusions: https://github.com/vuejs/rfcs/blob/function-apis/active-rfcs...

@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.

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.

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

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

I switched from React to Vue because I didn't like the direction they were going with hooks. Now it looks like Vue is heavily borrowing from the same approach. Slightly upset about that but I guess I'll have to learn the new style. Maybe it will be better in the long run.

Evan, although the proposal as it stands indicates that these changes are slated as optional for Vue 3, the longer term focus is unclear. It looks like the set up to a bait and switch in Vue 4.

Here's the problem: when Vue was released, people jumped on board because its design was incredibly simple when compared to React, which at the time was heavily focused on the functional, performance based approach to UI development (and to this day, still is.)

If you've got a team that's super focused on performance and loves FP, React is always going to be the better choice. Facebook continues to invest heavily into performance improvements. I can appreciate that you guys care about performance too, but you're now stepping on the toes of the guys who really only care about that one thing.

Performance is not the selling point of Vue, nor is functional programming or any of the other weird changes that have been introduced in this RFC. Nobody looked at Vue and was like, "wow, thank god Vue is 2ms faster than React when you render this benchmark component a thousand times."

The people who adopted Vue are the ones who had first rejected the complexity introduced by React. And now your team is saying "well, this approach is for more advanced users" -- what an insult, honestly. Many of us had the foresight to recognize that the complexity introduced in React was not worth it for our teams, or we had already experienced the problems that such complexity introduces, and we chose Vue because it managed in general to be as effective as React without the fuss.

What Vue 3 seems to be is an answer to the question: how can we beat React at its own game? And congratulations if you've done it, but that's not what your users are here for. That's not what we pitched to our teams, our bosses, our stakeholders, etc.

My question to you is: honestly, how am I supposed to manage this? The long term answer seems to be that I have to change my code base to this new syntax (beyond or during Vue 3), at which point I'll be right back where I started when I decided to leave React for Vue. Do you think this is fair to ask of your users? Are you sure this is what we want?

I've been following the Vue + TypeScript progress on and off for the past couple years (ever since I converted a React project to Vue and threw out TS in the process, since it was just so fundamentally incompatible with Vue's APIs). This is a pretty wild change compared to the now-abandoned class proposal, and I'm somewhat bummed by it, but I'll admit that's mostly due to my continued skepticism of hooks (as someone who hasn't yet adopted them in my React projects, either).

This will require one hell of a migration path to support and I imagine lots of people will be on that "Compatibility Build" for a long time. I'm very, very curious whether folks who have large-scale Vue apps have had a look at this proposal, and if they've had any input on it.

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 always saw VueJS as a successor to AngularJS in that it followed a lot of the same concepts/syntax/etc. that made it really easy to jump into.

Now Vue is maturing and becoming more Angular/React like...so it's only a matter of time before another framework comes out that replicates VueJS2/AngularJS in being super easy to jump into and just write code and the cycle repeats.

Why don't they just call it a new framework if its undergoing such a major overhaul. This only makes me feel better about picking react at my current company as now I view this framework as dangerous for building anything long lasting.

Breaking changes such as this makes me rethink what could be the best approach with regards to front end development.

I can recall the time when I moved past Angular when they introduced so many breaking change on their next version. I started using React but was not comfortable enough to keep pace with its progression. Then I found Vue which was a breath of fresh air as this framework has allowed me to deliver end products faster yet being simple enough to allow for easy scalability & enhancements.

With these upcoming enhancements, I hope that it wouldn’t introduce major changes that would require for me to rewrite large portions of my applications.

I have a lot of trust and confidence with Evan and the Vue Community and I guess all these changes are in line with best practices and better productivity rather than following a path because another framework is doing things like that.

The whole html template is one long string literal. I prefer JSX, where the XML is treated as code rather than a long string that needs to be parsed.

Before you lament this move (and it's similarity to hooks/increase in complexity for questionable gain), check out John Lindquist's talk on Proxies:

https://www.youtube.com/watch?v=95haj8RqR5o

This is what Vue 3 is using -- Proxy support enables really easy and natively supported observables (as well as enabling a bunch of other crazy stuff), and it's actually pretty impressive.

I think the reactivity system is Vue's biggest wart -- I've been surprised by it way more than I would expect. I strongly dislike the complexity react seems to encourage, I'm not a fan of hooks, but I am coming around to seeing this as a way that Vue gets closer to KnockoutJS -- not as a way that it gets closer to react. Knockout had the simplest reactivity model you could ask for -- make an observable object and you're done -- it's observable, no surprises, very predictable interactions/behavior. I'm choosing to think of this as Vue going in this direction, although by more complicated means (Proxy vs a simple souped up observable wrapper).

That said, at this point I feel it's up to Vue to bungle my high opinion of the project -- they made it this far by being the simplest component frontend library with the best features, and the day they stop being that I'll be moving on. Already warming up to MithrilJS in my own projects, it's wonderfully minimal, performant, and light.

Hopefully history will repeat itself and some clever dev will fork Vue 2.0 and create a new framework which has all the good parts of Vue 2 and nothing from this react inspired Vue 3 and all would be good again

(just like Evan did when Angular went rogue)

Not a Vue programmer, but looking at the code, why is the example code using {{ count }} instead of standard JS interpolation like ${count}, and using an App.template block instead of just returning the template with the count and other params. E.g. why not just make it plain JS, and minimize framework surface? I could rewrite that example removing almost all of the "Vueisms", and it wouldn't be a single line longer.

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 glad I've held off for this long... almost time to jump in!

Classes really seem to have gone out of fashion in JavaScript land these days.

Churn in the JavaScript ecosystem you say? What what tally ho pip pip!

Python 3 vibes. Terrible decision. Our team has decided after seeing this to use Vue 2.x until we can move away from Vue. Extremely disappointed. Simplicity was Vue’s bread and butter. Literally the only reason to use it over React. Now what’s the point? We get it, you’re a smart guy who likes FP, quit punishing the rest of us.

There is a theory which states that if ever anyone discovers exactly what a JavaScript framework is for and why it is here, it will instantly disappear and be replaced by something even more bizarre and inexplicable.

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 3 now, the answers that I get are likely still relevant today. It's not because Flask has always made the right design choices. But the maintainers stick to their decisions, because people have already invested time to learn to do stuff that way. It's not the best approach, it's not the worst either. You just learn it like this and when you have a problem, you ask on StackOverflow and someone will tell you what hoops to jump through. You'll scratch your head for a minute, but then be on your way to get shit done.

When I look for an answers related to Vue, everything seems to have an expiry date attached to it. Anything dated 2017 raises flags in my mind. Things seem in a constant state of flux. It's like trying to learn to walk on quicksand.

I saw the list of improvements/simplifications/deprecation. Not bad. If Vue was a fresh new framework these changes might have had more value, but it's not. A lot of time and efforts have already been invested to learn to do things the Vue 1 way and the Vue 2 way (not to count the accessory libraries and tooling). So I don't know if after tallying up all the pros and cons (which go beyond the technical concerns listed in the specs) whether this change might actually be more costly than helpful.

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 to us.

I personally feel like I need some time to play with this in the context of my own projects before truly passing judgement. My initial reaction “seriously, wtf?” Personally, for me, if Vue can remain the simple, compact, non-dependency hell that is React, I’ll take whatever they do.

My big question is how does this approach scale, and does it need a more fleshed out set of helpers, a la the mappers they have in the current API. Won’t really know until I work with it. Would also love to see how this approach works into, for example, Vuex.

This isn't what I signed up for. I wanted the class api. This is spaghetti garbage. One god function that returns 47 variable wrappers because we can't make the number 4 reactive. And we'll put .value after everything.

I used to be a huge Vue proponent for about 3 years and stopped using it at the end of 2018.

I moved to Inferno + MobX because the cognitive overhead is practically nil. You can architecture your application and specially your state in any way you wish since your reactive data is made of objects, classes, or whatever you want to use.

MobX also makes your React/Inferno components much more enjoyable. No need to use setState() anymore since your component state is reactive much like Vue or Svelte do.

After using that for a while and coming back to an old Vue/Vuex project I realized how many conventions and ad-hoc abstractions it has which was quite oppressive.

A couple of weeks ago I discovered mobx-jsx[1] which is pretty interesting. It's a very thin rendering library that compiles JSX to imperative DOM instructions and relies on MobX for tracking state changes which makes the virtual dom irrelevant. It adds loops and conditionals which IMO are the biggest annoyances of using JSX. This is probably what I'll be moving on in future projects.

(Actually what converts JSX to DOM instructions is a babel plugin from the same author)

[1] https://github.com/ryansolid/mobx-jsx

Man, this is quite a bummer. It’s basically a new framework to learn.

Edit: Might as well give it a completely new name.

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.

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.

It's important to note that this is an RFC for 3.x, and they seem to want to provide it for a 2.x revision, and provide a compatibility build, so it's not like angular 2+ where there's no real migration path.

If you have comments, this is where to tell the vue team: https://github.com/vuejs/rfcs/pull/42

Welp, it's dead to me then. There's a lot of thought seems like it went into the redesign and he(they?) have my respect but I'll be damned if I spend more time learning another js framework, I've already gone through react, angular 1 -> ∞ and vue. This is tiring.

It's amazing to me that after so many years of being the leading framework due to being the first to introduce a new paradigm (the virtual DOM), React is still "the framework to follow", i.e. again being the first to come up with an innovation (hooks) that spreads like wildfire. And even more amazing that they managed to do so in a backwards-compatible way.

(And also: with not that much pressure to adopt it. Having a "Standard" and a "Compatibility" build does result in that pressure.)

The more they change Vue the more I wonder why I'm not just using React.

One of the best features of Vue 2 is how declarative components are.

The syntax proposed here is much more imperative, making it more difficult to read and understand components.

It's moves like this which make me feel good about doubling down on Aurelia - https://aurelia.io and forgoing the latest trend frameworks and libraries that many seem to jump on and use because they're popular. I was disappointed when I saw Evan and Vue jumping on the "classes are bad, functions are good" bandwagon. There is a lot of misinformation out there about classes in Javascript. If you use them without inheritance (like Aurelia promotes) they're really useful and great. I also admire the fact that Aurelia itself has never had a major breaking change in syntax, I've got Aurelia apps that have been running since 2015 without issue.

I think this undoubtedly means that Vue's private prototype they've been working on will be thrown out and they'll be starting from scratch again, which means Vue 3 probably won't be out for at least another year or more. If Evan and the team proceed with these proposed changes, it'll be the end of Vue.

I'm happy they provide a way of migrating incrementally at least. But I really don't see us migrating any time soon, like possibly years.

To give a timeframe, this is the first major rework of this web based UI in nearly a decade. I wish these JS libraries had longer support timelines.

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.

Evan You is responding to comments on twitter

https://twitter.com/youyuxi/status/1137567675356291072

To be honest, I don't actually mind these changes. Grouping all exposed members together makes for a cleaner API and the functional style makes reuse a lot easier, so that should trim down code length.

But.....that's not a sufficiently compelling reason to change. Even with backwards compatibility, it still adds confusion to the mix, requires a huge effort in new/updating documentation, etc.

I can't really see how the benefits justify the effort.

It's Angular all over again.

I welcome the added flexibility of this new syntax. This eases encapsulation of related logic within the same block of code, instead of having it spread over different Vue directives.

Plus, at a glance, it seems very easy to pick up and very intuitive.

I also appreciate that you stay away from "javascript classes"

> Function-based APIs are exposed as named ES exports and imported on demand. This makes them tree-shakable, and leaves more room for future API additions. Code written with function-based APIs also compresses better than object-or-class-based code, since (with standard minification) function and variable names can be shortened while object/class methods and properties cannot.

I don’t yet have an opinion on the wider changes but this is great. Tree-shaking really helps bring down file sizes and I’m not in the camp of “it only loads once and caches” group that disregard file size these days. And not just because that’s no longer true with async component loading depending on the route/page.

One of the biggest advantages of the function API is the flexibility it gives for the library authors, making them more powerful and much easier to maintain, so instead of fighting against the API they will be able to focus on new fancy features, better documentation or community support.

This gain will be visible for all Vue developers regardless of which API they use because we all want to have the best quality libraries in our ecosystem.

I've written a blog post with my own feelings about it (hopes and fears included ;) ) - feel free to check it out: https://lukaszkups.net/notes/do-we-have-to-be-afraid-because...

If it's going to break compatibility anyway, go big. I would welcome something like what Svelte did for v3.

Sorry about the breaking changes, but glad “this” will be going away.

Thinking about transitioning (from AngularJS) to Vue, but prefer FP to OOP, and I’m glad that these new value wrapper things can be passed or used as partially applied arguments, as well as the other functional composition support changes.

I proposed new Scoped Mixins API (only basic draft ideas), could you looks at this and give feedback - https://github.com/vuejs/rfcs/issues/60

[I have no affiliation with the Vue team .. just a happy user]

IMHO, composition functions are an elegantly simple and well thought through addition to Vue brought about by a good consultative process. I think this demonstrates that Vue is in good hands with intelligent and wise counsel steering the ship. This small change is nothing like the Angular v1 => V2 experience! No one is breaking backward compatibility!!

Vue is all about coding simplicity ... and although reading through this RFC is at times heavier reading (meaning Evan's team thought through this addition very thoroughly), the final outcome is not! It's uses syntax that is very similar to existing Vue components so if you needed to refactor existing larger components into smaller composition functions, the coding experience is fast and would feel very natural and familiar with minimal to learn. No one is forcing this additional on you ... its just there if you needed it.

So please before getting spun up on any further misinformation in this thread please read the RFC from Evan You or this very thorough explanation of the RFC which has some nice coding examples.

- https://dev.to/danielelkington/vue-s-darkest-day-3fgh

Is it just React Hooks? ... here's a Comparison

- https://github.com/vuejs/rfcs/blob/function-apis/active-rfcs...

My personal journey

I've coded Angular/Ionic, ExtJS & Sencha Touch, Knockout/jQuery in the past. Learning Vue was nothing like learning and keeping up with these! I was highly productive in Vue in 3 days and the learning curve and documentation was much simpler and lighter so more time to stay focused on the code. I've refactored a legacy boostrap/jQuery web site into nice Vue components in a few hours (impossible with the others!).

I'm absolutely loving the super productive Quasar Framework built on Vue 2.x/3.x which now delivers 130 components, directives and boot plugins with builders for ALL platforms: Web or SPAs (Desktop & Mobile), PWAs, SSR, SSR + PWA, Cordova iOS/Android mobile, Desktop/Electron and dream documentation.

- Check it out: https://quasar.dev

I hope Vue.js gets some kind of automatic migration tool. Otherwise, I'm not sure how migration would be possible, given the amount of code certain projects have (sometimes without proper testing).

Eh, it was either this or wait till everyone switched to another implementation of 'vue with hooks' or react.

Oh well, Angular is a safer bet.

We have a (currently) 50-60KLOC SPA that, in the past 8 years, has survived migrations from a homegrown backbone+jquery-based MVC framework into angularjs (starting from v0.9), then to componentised angularjs v1.5 with webpack and TypeScript, to a heavily deangularised (but still based on v1.7) app where we've removed all useless DI (it didn't even help testing) and made all angular services into pure ES6 (well, in TypeScript) classes imported as modules, with Jest and TS transpilation via Babel.

We also have our own Redux/Vuex-inspired uni-directional state management solution that uses immer under the hood.

The next step, largely motivated by the fact it's hard to find developers who want to work with older frameworks, is to convert the app into Vue from the inside-out using ng-vue as glue, and when all components are Vue, remove the outer angular shell.

So we have been tracking these proposals. The original class-based RFC looked perfect for us, since that was 95% matching how our current (class-based) components look like. Seeing it get abandoned was a cold shower, but okay, not the biggest problem. Our components are as dumb as possible anyway, and we have all business logic in services. It'll just be some additional manual text-wrangling work.

The new proposal looks okay. I guess, just as React hooks made classes unusable in React, they had to go from Vue as well (though honestly, I don't really see the fascination with hooks, but maybe that's because we don't do anything like the Hooks examples I've seen in our app). I do really like the idea of the reactivity system being completely separate from the rest of the framework.

I personally never liked the original JS-only API either, with the { props:, methods:, computed:, } etc. "separation" (commenters here call it "simple", but I think it's far from that), so in my Vue 2.x projects I used vue-class-component.

Overall, the motivations and reasoning in this RFC seem sound to me.

However, here I come to my three biggest problems I have with this API:

1) The fact that you have to return the render props from the setup() function. It's annoying repetition, and I foresee people forgetting to add a newly added prop here. It also makes the definition of the component feel procedural instead of declarative. You have to read/mentally run the setup function to know the shape of the component. Hopefully maybe you can notate the setup() function return type to match a TS interface without breaking editor support?

2) The fact that they couldn't come up with a better-looking way to declare a prop with a complex TS type other than `prop: (null as any) as PropType<SomeComplexType>`. I guess I could make a noop generic helper function for this, though.

3) props are optional per default. I feel this is the completely wrong default for a TS project (mentioned as a consideration in the RFC though)

That everyone on HN seems to be unanimously shitting on it, I am now certain that Evan is going 100% THE right way with this, and am super-stoked about trying it out!

    // 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.