
Vue RFC: Expose logic-related component options via function-based APIs instead - no1youknowz
https://github.com/vuejs/rfcs/blob/function-apis/active-rfcs/0000-function-api.md
======
EvanYou
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...](https://github.com/vuejs/rfcs/blob/function-apis/active-
rfcs/0000-function-api.md#high-level-qa)

~~~
karaokeyoga
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 the "Lean" build.

~~~
boubiyeah
Not sure why Evan is not being more transparent regarding this renaming.

It would be easy to just say "yes, I got a bit carried away with the naming
and my big future plans, but the community reaction made me realise perhaps it
was not a great idea"

Insead he's like: "what? it was the plan all along :)"

~~~
gustojs
That's partly my fault. Evan focuses on more technical sides of things but
there are people in the team that focus more on the community aspect and we
didn't catch that potential naming issue and the whole message that the RFC
gives away.

We're all still learning how to work with the RFC documents. We want them to
be an important tool for the community but initially, the response from the
community was very low. Paradoxically this whole situation made the wider
community aware of those RFC documents so hopefully it will go in a good
direction. But that initial low response made us believe "oh we have time to
sort out things like the phrasing". Turned out it was wrong.

The advice to change the names came from the community and it was a good one.
It got support in the core team internal channels and got implemented.

------
lwansbrough
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?

~~~
EvanYou
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 "complexity":
[https://gist.github.com/yyx990803/762ec427882a61be3e4affe02f...](https://gist.github.com/yyx990803/762ec427882a61be3e4affe02f8af555)

Vue has a wide range of users. I honestly don't quite get how introducing an
optional API can be an insult - because we clearly see some use cases we ran
into can be more elegantly solved with the new API. Maybe you haven't run into
them personally, but that doesn't mean your use case is "inferior" \- we are
all dealing with different types of applications. However, I think it would be
a real insult if you think Vue will never have a use case that is complex
enough to warrant these advanced APIs.

Regarding your question: feel free to stay with the current API for as long as
you wish. As long as the community feels there's a need for the old API to
stay, it will stay. The only one that can make the decision to switch to the
new API is yourself.

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

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

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

~~~
pier25
Yes, that's what the React team should have done when they implemented hooks.

~~~
NewsAware
Well, with React you can "opt in" when searching by simply adding "hooks" to
the search term. Such wasn't possible with Angular back then

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

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

~~~
pier25
That's not the point.

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

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

~~~
pier25
If you learned React with hooks the class notation won't make sense, and
viceversa.

~~~
BigJono
This is what I don't get about hooks. Remembering Markbages great talk on
'Minimal API Surface Area'? How is having multiple ways of doing the same
thing minimal API surface area?

React is losing sight of what made it great when it came out. Do one thing, do
it well, and do it the simplest way possible.

~~~
thatswrong0
That sort of absolutist logic will never allow a framework to progress and
become better. Sometimes good ideas come around (IMO like hooks) that are
worth increasing the API surface area for.

I for one loathe using class components now and not being able to share logic
compositionally via hooks when I work with them. I feel more productive and I
feel like my components are smaller and more focused, and I don’t repeat
myself as much. It’s been a net win for me, and I think it’s well worth having
two supported APIs that do roughly the same thing.. because despite this,
React is still a small and focused library API-wise.

------
hardwaresofton
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](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.

~~~
jcadam
As a "full-stack" developer I just don't have the time to follow the JS circus
as closely as a dedicated front-end dev would. I switched from Backbone to
Mithril a few years back (major improvement to my productivity) and I see no
reason to go through the effort of learning a new framework again.

But if I had to find a new framework for some reason, I'd probably go with
Vue.

~~~
hardwaresofton
A very reasonable stance -- congratulations on getting lucky (unless it was
the result of tons of research) and picking Mithril after jumping from
Backbone (+Marionette I assume). There were _a lot_ of wrong, but good-looking
choices to make there.

In case it wasn't clear, I still think Vue is the best minimal component
library all things considered -- simple syntax, simple and mostly clear usage,
support for typescript, not too much overbearing tooling (they're trying to
"fix" this with vue-cli though), and a large community & ecosystem. I'm just
scared they're going to blow it and start putting in , but I'm well aware I'm
just a hanger-on to the project (I don't contribute to it).

Mithril[0], on the other hand is almost allergic to change, in the linux
kernel way, which is great until you have a problem with how it works or think
it should work differently. Mithril is also the most complete though -- it has
routing, AJAX, all that stuff built in (context: normally when people say
"vue/react" they mean "vue/react + vue/react-router + vuex/flux"). I also
particularly like how Mithril uses the hyperscript syntax and just calls it a
day -- full "single file components" without the transpilation hassle. Mithril
also passes one of the key indicators for high quality software, a comparisons
page[1].

Shameless plug -- I wrote a short guide[2] on how to get started with mithril
& parcelJS (ignore the link URL, I started with rollup and then quit because
it was too inconvenient to use, I write about it in Step 5):

[0]: [https://mithril.js.org/](https://mithril.js.org/)

[1]: [https://mithril.js.org/framework-
comparison.html](https://mithril.js.org/framework-comparison.html)

[2]: [https://vadosware.io/post/mithril-systemjs-and-rollup-
gettin...](https://vadosware.io/post/mithril-systemjs-and-rollup-getting-
started-guide/)

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

~~~
intothemild
I just left frontend, and I’m the maintainer for express-vue. Vue is great in
its current iteration. But the whole JS ecosystem is just horrible right now.
Looking at these changes, it’s not for the better.

~~~
BigJono
I'm almost done with it as well.

I can actually handle the churn and the random rewrites, a lot of them have
been marked improvements, that doesn't bother me. What bothers me is when
things change in ways that make them _more_ complex than they were before,
which also happens constantly.

Not only that but I'm sick and tired of tool developers pandering to noobs.
Nobody should ever be learning to use a library like React before
understanding the programming language they're working with. For the React
team to come out and say something as stupid as 'classes are too hard', in the
context of the sheer wall of accidental complexity around the front end space,
is a joke.

All the problems with PHP back in the day are going to come back with a
vengeance when our new generation of coders that don't understand basic
language constructs all graduate to tool making.

~~~
Tade0
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/](https://svelte.dev/)

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

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

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

~~~
Tade0
I haven't seen any, but as a relatively early proponent of Vue(as in: I was
there when v2 came out), I found Svelte even easier to get into than Vue.

Anyway Rich Harris' presentation is a good starting point:

[https://youtu.be/AdNJ3fydeao](https://youtu.be/AdNJ3fydeao)

~~~
xmprt
God why did you show this to me. Now I really want to build something with
Svelte but the project that I'm working on currently is built in Vue...

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

~~~
Rapzid
I really disliked the function API and felt the class API with decorators was
much easier to read and work on.. I'm pretty sad they are doubling down on
function API and, apparently, ditching the class API?

~~~
gustojs
The class API will remain the current status of an add-on. The idea was that
if we make the class API built in to the core, it will somehow be better than
now and remove all the issues with it. More and more into the game it was
turning out that's not that easy.

Even the decorator thing was problematic. Remember that the core Vue library
is supposed to work both with and without build tools, but in case of
TypeScript it's not possible. There is a decorator proposal for JavaScript but
it works differently than the TypeScript one so there would be a clash.

In the meanwhile we found out a new solution that not only solves these but
also some other problems (composability).

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

~~~
hohohmm
adams is a visionary :P

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

~~~
samhh
> with no real gain

Did you read the linked motivations?

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

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

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

~~~
umvi
Scope creep. It's really hard to say "no" to feature requests, especially if
hundreds of people give it thumbs up, but it's a necessity if you want to keep
your project from bloating over time.

~~~
KukicAdnan
Yeah I'm not saying it's a positive or negative change. Just an observation.
Personally, I'd rename the next version to something else and let Vue be Vue,
where Vue was founded as a replacement for the bloated SPA frameworks and
super easy to just drop in and use.

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

~~~
Vinnl
> this would be a disaster similar to how Angular suddenly changed everything.

To be fair to Angular, if they'd stuck with what they had, it'd have faded
into obscurity far more than the current version has. Angular.js was great for
its time, but lost most of its advantages as the web caught up, and what used
to be its advantages started to become kludges.

~~~
grezql
Im still om angularjs. Cant bother to learn new frameworks every other month.
Also using Angularjs in recent projects i never ever thought I was hobbled.
Angularjs,jquery,vue - doesnt matter which tool one use. If you know any of
these at advanced level you can create anything

~~~
JMTQp8lwXL
The initial release was 8 years ago. Surely, you've had at least an ounce of
curiosity about how the front-end ecosystem has changed since then? Even if
you didn't adopt it, just to maybe poke around and look at what React, Vue,
et. al. are up to?

It's not be dismissive of what you currently do. But perhaps you might see new
efficiencies that allow you to do more with less, with these newer solutions.

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

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

~~~
jeremyjh
It seems inevitable that hooks will be the only API 3 years from now though,
and its already the case that all the new literature and examples are only
going to teach hooks. Vue might maintain compatibility just as long but
they've totally hosed their messaging on this judging from all the comments in
this thread.

~~~
Vinnl
True, though as I said elsewhere: relegating the "old" syntax to a
"compatibility build" is giving a strong signal that they will be deprecated
soon.

But yeah, for now it appears they'll maintain compatibility well enough.

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

------
pier25
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](https://github.com/ryansolid/mobx-
jsx)

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

~~~
rk06
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

------
seancoleman
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...](https://medium.com/the-vue-point/plans-for-the-next-iteration-of-
vue-js-777ffea6fabf).

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.

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

------
treelovinhippie
Well that's enough to reinforce my switch to
[https://svelte.dev](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.

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

~~~
michaelchris
On what I've read, Sapper is still v2. Understandable I guess since Svelte has
a small community.

~~~
KitDuncan
You can use Sapper with v3 already and could for a while now. It's RC for now
though.

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

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

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

~~~
elwayman02
The React ecosystem introduces huge breaking changes and paradigm shifts
literally all the time... _coughreactroutercough_

~~~
mharroun
Reactrouter is a 3rd party npm package... the core react framework has been
very stable and backwards compatible.

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

~~~
numbsafari
Also, this seems like the kind of change that would greatly benefit from some
automatic code rewriting tools a la go.

------
superasn
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)

~~~
Can_Not
I think it's inevitable that if EvanYou does betray us, we really could just
have a community fork of 2 and 3. You can see the support exists in this
thread, and let's be honest here, VueJS seems pretty good and complete as is
anyways.

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

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

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

~~~
Scarbutt
Sure, why not? highly depends on the product of course.

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

~~~
Androider
I have a 100K+ LOC project in React started in 2015 that's going strong, and I
imagine Facebook has much, much bigger projects than that using React. I can't
recall a single time during all these years that something would have broken
in a non-backwards compatible way. We're on the latest version of React,
writing class-based components (with zero intent to move to hooks) and feeling
very good about it.

~~~
scns
I think Abramov said they habe over 38000 components at facebook, which is
enough reason for Thema to keep backwards compatibility.

~~~
acemarke
A lot more than that - roughly 100K now. Shawn Wang collected comments from
the React team over time showing the growth of React's usage inside Facebook:

[https://www.reddit.com/r/reactjs/comments/btx9nq/reacts_grow...](https://www.reddit.com/r/reactjs/comments/btx9nq/reacts_growth_rate_in_facebook_some_datapoints/)

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

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

~~~
Can_Not
Single File Components are converted to functions at build time (not run time)
and that's the syntax for "string interpolation, but the variable is not
trusted html". This protects against html injection.

------
ehutch79
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](https://github.com/vuejs/rfcs/pull/42)

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

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

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

~~~
pier25
You could look into other options like Svelte.

~~~
mdanger007
Svelte is really nice because it makes the mundane easy (some say magic) and
the tough stuff like reactivity and animation manageable.

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

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

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

~~~
akhilcacharya
I prefer this because it doesn’t require a build step.

~~~
root_axis
True, but realistically you need some kind of build pipeline for production
quality JS anyway so adding it in is pretty painless.

------
DigitalSea
It's moves like this which make me feel good about doubling down on Aurelia -
[https://aurelia.io](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.

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

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

------
ehutch79
Evan You is responding to comments on twitter

[https://twitter.com/youyuxi/status/1137567675356291072](https://twitter.com/youyuxi/status/1137567675356291072)

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

------
Philipp__
It's Angular all over again.

------
luismartinezs
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"

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

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

~~~
adevx
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 :-)

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

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

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

~~~
mvgmvg
That.

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

------
lukaszkups
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...](https://lukaszkups.net/notes/do-we-have-to-
be-afraid-because-of-latest-vuejs-rfc/)

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

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

------
malvikus
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](https://github.com/vuejs/rfcs/issues/60)

------
tohagan
[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](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...](https://github.com/vuejs/rfcs/blob/function-apis/active-
rfcs/0000-function-api.md#comparison-with-react-hooks)

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](https://quasar.dev)

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

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

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

~~~
mvgmvg
JS land and Frontend in general changes fashion every 6 months (tops)

------
neximo64
Oh well, Angular is a safer bet.

------
moogly
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)

------
jstewartmobile
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!

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

~~~
tuesdayrain
No one is forced to upgrade. An ecosystem with optional churn is better than
an ecosystem that has no churn just because people aren't creating new things
for it.

~~~
quickthrower2
Yes I love the Windows 2000 UI, but I guess I'm not forced to update.

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

~~~
goguy
I'm not a fan of this RFC but how can you make such as drastic decision at
such an early stage?

~~~
Can_Not
Everyone's treating this "request for comment" as if it's an official
declaration of the new API.

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

