Today I was amazed to see the usually positive and friendly VueJS community descend into a bitter war. Two weeks ago Vue creator Evan You released a Request for Comment (RFC) for a new function-based way of writing Vue components in the upcoming Vue 3.0. Today a critical Reddit thread followed by similarly critical comments in a Hacker News thread caused a flood of developers to flock to the original RFC to voice their outrage, some of which were borderline abusive. It was claimed in various places that
- All Vue code would have to be rewritten in a totally new way because the existing syntax was being removed and replaced with something else;
- All the time people had spent learning Vue had been wasted given everything was about to change;
- The new syntax was worse than the old, did not enforce structure, and would lead to spaghetti code;
- The Vue Core team had suddenly implemented a huge breaking change without any consultation;
- Vue is turning into React!
- No, Vue is turning into AngularJS/Angular!
- All HTML now needs to be written as a giant string!
With walls of negative comments on the Reddit Thread one may be surprised to discover on going to the RFC page that You's RFC has an overwhelmingly high ratio of positive to negative emoji reactions, and many of the initial comments were quite positive. Indeed, the very first comment is particularly full of praise.
I was the person who wrote that first comment. I happened to get a notification that there was a new RFC, read it straight away, saw that it was just what I wanted from Vue 3.0 and that it would help immensely, and left the first comment within 15 minutes of the RFC being published to express my gratitude. I hope to expand here on why I think the new proposal is such a great idea, but first, to address some of the criticism.
I suspect that many people got a little worked up after reading the Hacker News or Reddit threads which had some somewhat misleading comments, and voiced their outrage without reading the original proposal. Evan You has now updated the proposal with a Q&A that addresses many of the issues people have, but to summarise,
- You don't need to rewrite any code if you don't want to - the new syntax is additive, and the old syntax will remain valid throughout Vue 3.0 and as long as it is still widely used. Even if it eventually gets removed from the Core code, plugins could easily allow the old syntax to be still 100% valid.
- Time spent learning Vue was not wasted - the new component syntax uses the same concepts that you spent time learning, and other concepts such as Single File Components, templates, and scoped styles work exactly the same.
- A change hasn't been made without consultation - the RFC is the consultation. The new syntax is still a long way from being released.
- And no, HTML code doesn't need to be written as a giant string.
A slightly more subjective point is that the new syntax is inferior to the old, and will lead to less structured code. I hope to demonstrate with a simple example why I got so excited when I saw the RFC, and why I think it is superior and will lead to better structured code.
Consider the following fun component that allows a user to enter details of their pet. Note that
- A message gets displayed when they finish typing their pet's name;
- Another message gets displayed after they select their pet's size.
You can try out a demo of the component here and can view the full code using Vue 2.x here (see components/Vue2.vue).
Consider the JavaScript of this component:
export default {
data() {
return {
petName: "",
petNameTouched: false,
petSize: "",
petSizeTouched: false
};
},
computed: {
petNameComment: function() {
if (this.petNameTouched) {
return "Hello " + this.petName;
}
return null;
},
petSizeComment: function() {
if (this.petSizeTouched) {
switch (this.petSize) {
case "Small":
return "I can barely see your pet!";
case "Medium":
return "Your pet is pretty average.";
case "Large":
return "Wow, your pet is huge!";
default:
return null;
}
}
return null;
}
},
methods: {
onPetNameBlur: function() {
this.petNameTouched = true;
},
onPetSizeChange: function() {
this.petSizeTouched = true;
}
}
};
Essentially we have some data, properties computed off that data, and methods that manipulate that data. And notice that in Vue 2.x there is no way to keep related things together. We can't keep the petName data declaration next to the petNameComment computed property or the onPetNameBlur method because in Vue 2.x things are grouped by type.
Of course this doesn't matter too much for a small example like this. But imagine a bigger example, that had multiple pieces of functionality that needed data, computed, methods, and even a watcher or two. There's currently no good way to keep related things together! One might use something like Mixins or Higher Order Components but these have issues - it's hard to see where properties are coming from and there are problems with namespace clashing. (And yes, in this case it would be possible to split things into multiple components, but consider this similar example where it isn't.)
Rather than organising components by option type, the new proposal allows us to organise components by actual functionality. It's similar to how you organise your personal files on your computer - you usually don't have a 'spreadsheets' folder and a 'word documents' folder, instead you might have a 'work' folder and a 'holiday plans' folder. Consider the above component written in the proposed syntax (as best as I am able to without seeing the output - let me know of any bugs you see!):
import { state, computed } from "vue";
export default {
setup() {
// Pet name
const petNameState = state({ name: "", touched: false });
const petNameComment = computed(() => {
if (petNameState.touched) {
return "Hello " + petNameState.name;
}
return null;
});
const onPetNameBlur = () => {
petNameState.touched = true;
};
// Pet size
const petSizeState = state({ size: "", touched: false });
const petSizeComment = computed(() => {
if (petSizeState.touched) {
switch (this.petSize) {
case "Small":
return "I can barely see your pet!";
case "Medium":
return "Your pet is pretty average.";
case "Large":
return "Wow, your pet is huge!";
default:
return null;
}
}
return null;
});
const onPetSizeChange = () => {
petSizeState.touched = true;
};
// All properties we can bind to in our template
return {
petName: petNameState.name,
petNameComment,
onPetNameBlur,
petSize: petSizeState.size,
petSizeComment,
onPetSizeChange
};
}
};
Note that
- It's ridiculously easy to group related things together;
- By looking at what gets returned by the setup function we can easily see what we have access to in our template;
- We can even avoid exposing internal state ('touched') that the template doesn't need access to.
On top of that, the new syntax easily allows full TypeScript support which was difficult to achieve in the Vue 2.x object-based syntax. And we can easily extract out reusable logic into reusable functions. Something like
import { state, computed } from "vue";
function usePetName() {
const petNameState = state({ name: "", touched: false });
const petNameComment = computed(() => {
if (petNameState.touched) {
return "Hello " + petNameState.name;
}
return null;
});
const onPetNameBlur = () => {
petNameState.touched = true;
};
return {
petName: petNameState.name,
petNameComment,
onPetNameBlur
};
}
function usePetSize() {
const petSizeState = state({ size: "", touched: false });
const petSizeComment = computed(() => {
if (petSizeState.touched) {
switch (this.petSize) {
case "Small":
return "I can barely see your pet!";
case "Medium":
return "Your pet is pretty average.";
case "Large":
return "Wow, your pet is huge!";
default:
return null;
}
}
return null;
});
const onPetSizeChange = () => {
petSizeState.touched = true;
};
return {
petSize: petSizeState.size,
petSizeComment,
onPetSizeChange
};
}
export default {
setup() {
const { petName, petNameComment, onPetNameBlur } = usePetName();
const { petSize, petSizeComment, onPetSizeChange } = usePetSize();
return {
petName,
petNameComment,
onPetNameBlur,
petSize,
petSizeComment,
onPetSizeChange
};
}
};
In Vue 2.x I often find myself writing a "monster component" that is hard to break up into smaller pieces - it can't be decomposed into other components because there is too much happening based on a small amount of state. However using the proposed syntax it's easy to see how big components could have logic broken up into smaller reusable pieces, moved into separate files if necessary, leaving you with small, easy-to-understand functions and components.
Is this Vue's darkest day so far? It looks like it. What was until now a community mostly united behind the project's direction has splintered. But I have hope that people will take another look at a proposal that doesn't break anything, still allows them to group things by option type if that's what they like doing, but allows for so much more - clearer code, cleaner code, more interesting library possibilities, and full TypeScript support.
Finally, when using open source software, it's good to remember that the maintainers are putting a lot of effort into something that you get to use for free. Some of the borderline abusive criticism seen today is something that they really shouldn't have to put up with. Thankfully the disrespectful comments were a minority (albeit a sizeable one) and many were able to express themselves in a more respectful manner.
Update June 23 2019:
I wrote the original post very quickly and without expecting it to receive the attention that it has. Since then I've realised that the code example was too complex for the point I was trying to illustrate, so I've simplified it greatly. The original code sample can be found here.
Oldest comments (112)
I’d recommend not waiting and starting now. Key concepts are the same - you make some properties available on a component using JavaScript and then use them in a HTML template. Only difference will be a minor change to the syntax of where exactly things go in the JavaScript component part. It’s more important to know concepts like component “data”, “computed properties” and “methods”, and those ideas will all remain the same, you might just express them differently and once you know the Vue 2 way of doing things the new way will be easy to move to if you want.
And as a bonus the Vue 2 way of writing components will still work in Vue 3.
social media/speed of communication seems to bring out the worst in ppl. i guess it gives the podcasts new material.
Thank you for saying this! I felt so disheartened reading the more negative RFC comments and the Reddit/HN threads. There has been much bitterness about a change proposal. Feedback is absolutely necessary, but there's no need to call the framework dead and tell everyone to switch to others.
ya Give me a function with everything stuffed in it, that’s way better than splitting things into intuitive fields grouped by functionality. Not.
If you like grouping your component by option type, you can continue doing so. If you decide you want to group things by purpose, you can now do that too, which you couldn't do before.
Dude, those are React hooks. LOLz
I find it funny that Vue stays relevant by copying what other frameworks do. Every time.
On the other hand, Vue just validated React's new approach.
Agree that React Hooks are a great idea, and the concept (like for example a Virtual DOM) is worth adopting in other frameworks. I think Vue's version is even better than React Hooks - see this comparison. Also see this comment.
Hm, these points do not really ring for me. The thing that made hooks so neat is that you can compose them. I know you can do this here, too, but i have trouble understanding how this would go. In React there's a call order, which i don't see as a negative despite the memoization, imo it helps to establish linear intent. Also to me it seems thinking in lifecycles (mount/unmount) isn't ideal, too. With hooks you're dealing with what are essentially effects.
Here's an example, i wonder how something like this would look in Vue: twitter.com/dan_abramov/status/109... In that example you see how they're composed in a linear order, one feeding the other. Items go into a shuffle, then together with columns and width go into the grid, the grid goes into a transform. If these were all observables that just happen to be driven by some one-shot hooks, would you be able to glance over it like that and see the connection?
I'm honestly curious, overall i must say i like the direction Vue is now going.
I've tried to flesh out the Vue version here:
gist.github.com/LinusBorg/f4378944...
Make sure to read the README. I'm open to questions :)
@linusborg Nice! You may want to change the third link in the README from a duplicate CodeSandbox link to dev.to/drcmda/comment/c7l9 🙂
Oh, thanks. Will do
Nice! That helps a lot to understand the differences.
No, there's no implementation available yet, the proposal is still being discussed and not adopted
There is an implementation github.com/liximomo/vue-function-api
Right, we came across this userland implementation as well in the meantime, it's pretty cool :)
Considering all that's going on right now I haven't had the time to try it, and can't say wether I will find time to use it for bringing this example to life in the coming days.
I think it's about time we all admit that Flux has gotten out of hand. It's way too much boilerplate code to write, keeping track of reducers becomes unmanageable, and you end up with lots of data thrown into global application state that has no business being there.
At least this is being planned and communicated...I love Elm but I wouldn't dare use it in Prod because of how immature the community is. Someone decided that something is inelegant and needs to be removed, but no replacement is offered. It's okay though, if you have problems go to the chat room and someone should be able to help you figure it out! Lolwhut? You deleted my shit!
I'm just sick of JS period right now. DLL hell is nothing compared to NPM hell. I'm sick of spending hours chasing down broken builds with no rational explanation and having 60MB of crap in node modules that could be the culprit.
I really just want to go back to pure JS and an event bus. Front end dev is incredibly frustrating now. None of the technologies I get excited about are stable enough to invest in and I have no idea who the target audience is for some of these tools...it sure isn't developers or users.
At times the ecosystem feels like a parody of itself where were so far up our asses we can't take a step back and reconsider where we are today.
And get off my lawn! 😂
Funny how different perspectives can be. I for one love the current ecosystem and couldn't imagine having to go back to pure JS over an event bus :)
I don't want to ever build a website with vanilla Js again😂😂
Tbh, it's never been a better time to be a "vanilla" JS developer, you can write pretty complicated and full featured apps with zero dependencies a lot easier than before.
Sure, many of the browser apis are low level and just recently the old browsers have died enough to serve es-modules and don't lose that big of an audience but if you actually use those the dev experience is not that bad, it's actually an interesting exercise to see just how much you can do with zero building/transpiling/dependencies/polyfills
It's a lock file dude. And if you also want to lock down transitive dependency, use yarn's offline cache with a lock file.
I've had almost the exact opposite experience.
Vue - originally designed for newbies and designers. Copies patterns from other frameworks to entice developers to switch. You know where that's going---Angular 1 all over again! (Easy first few days but then you need a PhD to engineer complex apps).
React - seems to be designed for engineers. Features are added because they solve use cases (not because of "where the industry is going").
I've used Vue, Angular, and React and have always had a pleasant experience with React.
Would not use pure JS for a complex app---you end up reinventing the wheel before you know it!
In one instance, it was a brand new project I was starting where dependencies were breaking. I feel after a clean start no problems should have been possible. But I also had a manager standing behind me yelling so I couldn't focus at all, so perhaps it was something really trivial and I was just too irritated to focus.
I wish Elm was a little more mature, I am learning F# so I love Elm's syntax. It has a long way to go, however. I'd like to play around with PureScript and some of the other functional languages now that I have some time.
But that
setup()function trigger me everytime.I'm not gonna lie, I was kinda flabbergasted when I read the RFC a few days ago. Everything I knew and loved about Vue from my 3+ years of using it was about to turn into React. Don't get me wrong, I like React too, but I like Vue better because it's NOT React.
Then I read the part of your post about extracting reusable functions and I got excited. Like you, I've written a lot of large components that I'd like to split up, but by doing so, I'd either run into using a lot of mixins (which I'm not as apposed to as others, but can definitely see how they'd get confusing, especially with global mixins) or a bunch of small components that would need to interact with each other, making the logic between them more complex.
This solves the problem fairly well, I'm just not really sold on the "grouping" aspect of this RFC and it leading to more organized code. The same can be done with React but that doesn't stop people from not doing it. Vue, as it is, imposes a structure that allows a developer to easily look at the code and understand how it all fits together. Sure, you might have to scroll up and down a few times to figure out what the data properties, computed properties and methods all are, but it's all easy to find and that's the point.
Still, with the way you can compose things from other functions with the proposed changes, I suppose this leads to being able to build smaller components, thus reducing the need for a strict structure, since there will be less going on in them. That said, I'm still definitely not 100% sold on it, yet. I think it still needs some work (ie: the .value thing is kind of confusing when you'll need to use it or not, I think that definitely needs to be hashed out better) but can be a viable option for improvement to both the current way Vue is written and in the future.
You make a couple of good points here and they are aligned with what the team is discussing internally. There are things we can do better about the current version of the function API syntax, so let's hope we reach a point in which we're fully satisfied with it.
Awesome post! I believe it is mostly fear of change thus people are expressing anger. Indeed the new way to abstract your code and make it more re-usable and more flexible to maintain and test it more straightforward is a good thing imo. Also it is a great way for frameworks/libraries like Angular/React/Vue to make case for interoperability in the future by having generic "hooks like" library to bridge common features. And for the last but not least I support core team that it is better to evolve rather that to stagnate.
I'm traditionally a React developer but have been dabbling more and more with Vue lately and have really liked it. Also I want to emphasize that I am commenting in good faith and am very supportive of the Vue community. I do have a comment about the above point:
When a framework moves towards a new API, you have to also consider the ecosystem around it (stackoverflow q & a, github issues, open source plugins, tutorials, documentation etc..). Saying that people can use the old syntax with plugins does not really make a lot of sense considering this will cause fragmentation. I think what this new API would possibly do is similar to what happened with Angular (I am a former Angular developer who moved to React after 1.5 to 2.0 debacle).
When searching for documentation and information, it will become hard for people to discern between the versions and be especially hurtful for newcomers. For a change like this, would it ever make sense to instead introduce a new framework and continue to support both for the long term? Maybe this new API could continue to evolve into something even more sophisticated if it was branded as a new project and the people who enjoy the existing Vue APIs could also continue using Vue as they have in the past.
The benefits in my mind would be:
Overall, the new API looks like a net positive and an improvement and the Vue team is doing a great job. This feedback is more centered around how people will find and utilize resources efficiently for the new API.
Either way, I know this is still just an RFC and nothing set in stone, just my 2 cents.
Thanks for your well thought-out comment Nader! Agree that considering the ecosystem is very important, and there are lessons to learn from Angular. The switch from Angular JS to Angular was almost a new framework with the same name - upgrading was a nightmare and typically involved having to rewrite a lot of code, and required you to have to basically learn a new framework. I don't think this proposal is anything like that, given that it doesn't break any existing code and it isn't a proposal for a different framework - just like Vue 2.X you have components that can have props, state, properties computed off that state, watchers and methods and these can be bound to templates. For beginners, designing a Vue component is the same - you need to work out what will be the component's props and data, what needs to be computed off these, and what methods are needed to respond to events. Template bindings will work the same and follow Vue 2.X's syntax. Only difference is a different (and improved) way of writing these options that opens up more possibilities. I think understanding the basic concepts is more important than the syntax, and these don't change.
Agree that there may be some initial pain as the ecosystem switches over, but I don't think it will be too bad. For a time some resources using a setup() function may need to include a disclaimer that this is only valid in Vue 3.X, and some beginners might still come across tutorials that use the object syntax - but it'll still work, and will still teach them the fundamental concepts involved in thinking about and building Vue components, which don't change in the new API.
I think your comments apply equally to React Hooks, but the React team has done a fantastic job explaining the new API, particularly emphasising that like the Vue proposal it is purely additive and does not break anything. At the moment there might be a bit of pain for beginners given that there is a mixture of tutorials and documentation around the internet that use or don't use hooks. But I hope you'd agree that the benefits outweigh this initial pain.
I can see Nader's point. Beginners might find answers to their questions in places like Stack Overflow where older answers use the current API, and newer answers might use the new API.
Even worse, they might get answers to their own questions, asked with e.g. the new syntax, and someone in favor of the current syntax will reply in that style.
Meaning: In order to make full use of the resources available online, Newcomers have to learn both approaches, and learn to differentiate between them.
That could of course be a pain in the ass.
But I also agree that it wouldn't be as painful as AngluarJS -> Angular since most examples would at least be translatable 1:1 from one version to the other, as we still have the same lifecycle methods, computed etc, just written differently, whereas Angular completely replaces the core logic of what a component is and does.
Bumping into answers written in multiple syntax styles is difficult enough as it is without throwing different versions of the API into the mix, but these problems are an unavoidable consequence of growth, and perhaps something StackOverflow should look to mitigate against rather than having it make developers too tentative.
It should be possible for StackOverflow to do API inferences based on the tags, titles, and the code samples — but this is a tangential consideration.
Clearly this person did not write projects using vue-property-decorator, where everything is a class. Those of us that wrote using class based components have now been neglected and left in the dark to fend for ourselves. No longer recommending Vue to anyone if this is how they treat their developers.
LongLiveSvelte
I can already see the toches and pitforks from people coming for us, proclaiming how we completely abandon current Vue in order to write a new hipster framework.
And I'm only half joking.
Thanks for sharing the idea! :)
One of the most important beneficiaries of the function API are the library authors. They can take advantage of the new composition pattern in so many ways.
Going with a new framework would force them to write two versions of their libraries - the easier to maintain for new framework and much more tricky for the old one.
With the current approach, they can just use the function API to write their libraries and expose them to users of object, function or class API without any issues.
I even got a name - Nue /njuː/
This is my biggest worry. I'm about to start learning Vue, so I don't really even understand most of what people are posting about, but I do understand that people are saying this is going to make everything we've learned get changed, so now I'm hesitant to even start. 😔
It's much ado about nothing. Start learning and building now, all things change over time (js, frameworks, life).
This API change is much more like what happened to React when they deprecated React.createClass() or introduced hooks. Why are these changes not called a debacle?
I think Vue has been attracting a lot of people new to front-end/js development, that see Vue as the anti-React. They find react hard, has too much boilerplate, and too much facebook, or some mixture of these. So any movement towards anything react-like is met with loud reverberations in their misinformed echo-chambers.
It's not like Vue 2 is not going to be available as soon as Vue 4 is out.
Thoughtful post, but please please please no not a new framework! That would really mean fragmentation and the death of Vue, look at what happened with Angular (Angular isn't completely dead but it's being surpassed left and right by React and Vue).
Instead it's fine with me if the 'old' and 'new' syntax coexist for a long time to come, and people gradually adopt the new style how and when they want. This gradual adoption also means that the ecosystem and community can slowly adapt/evolve/migrate and the "old style" knowledge (SO and so on) does't become obsolete overnight (as was the case with Angular 1).
We shouldn't dramatize these changes - compare it to React, obviously the new proposal reminds me a lot of React Hooks. In the React world you see that new styles/APIs are being proposed and adopted without a lot of drama, why couldn't it be the same in the Vue world?
This new proposal does not mandate a "new Vue framework", please let's stay far from that.
This is done by the express framework team.
The express framework API won't change.
All the post ES6 work is being done in their new framework Koa.
Though I think adaption of Koa is still lower than Express because Express just works. Same can happen with Vue.
Just wanted to share my thoughts. There are advantages and disadvantages of all the approaches (even Angular's approach). I trust the Vue team will do their best as long as the community give constructive feedback.
I'm afraid introducing a new framework and supporting both for the long term won't work. Angular has proven that. Now all the dudes who remained in the boat of angularJS have no captain and they will inevitably have to move to Angular or another framework. Soon or later the users of vue2.x will have to face again the same issue. This will just delay it....
I’d probably have been happy with the new API being available, but the initial builds were called standard and compatible. The Core devs have shown their hands on this one, even if the old API stays it has no future. Nevermind depreciation, you can’t keep using it and run the risk of having any jobs you apply for being shops using lean build.
The new APIs look ugly but I’m going to wait until after I refactor away from the old APIs before I make final judgement on whether I stick with Vue for new projects, though I’ll almost certainly stay with it for existing projects.
There are already many kinds of shops that use Vue in their own way. Many of them use TypeScript with classes, others use render functions, some other use Vue as a JQuery replacement. The industry is heavily leaning towards TypeScript and you're right, there will be many companies that use the lean build exclusively because of the TypeScript reason.
With the naming of the builds, I do agree it was a mistake, but it mainly came from the fact that the team members focused on the technical side of things and didn't realize how it all sounds.
I do hope you'll be satisfied with Vue 3 and that we'll see each other here again discussing Vue 4 in a few years.
These types of arguments and discussion are very common when a framework reaches a certain level of adoption / maturity. When MS changed from VB6 to VB.NET people were having, word by word, the exact same discussion. Some of them much more pissed off because they spent tons of money in MS certifications as well.
I've very thankful to Vue creators. Vue allowed me to learn more about web development. If Vue is evolving, it's probably good for me - it's an opportunity to learn even more about coding, become better. That's why I'm looking forward to Vue 3.0, whatever it brings. I would love it to be sharp, not blunt compromise. So my learning would have a way higher value.
Anatomy of a JavaScript framework:
I am still wondering how React is still flying... To me I find it too complex.
Seems complexity is the new Bae
The first time I looked at a React tutorial video, I almost burst into tears. I was just coming from the jQuery, .Js, .htm, .CSS background. I thought I would never be able to move to a modern FW. Then I saw Vue. The first video I watched, wow. I just fell completely in love.
From the article: "Essentially we have some data, and various properties computed off that data. And notice that in Vue 2.x there is no way to keep related things together. We can't keep the data declaration petColor next to the petColorDarker computed property because in Vue 2.x things are grouped by type."
Maybe I'm totally crazy, but wouldn't the best approach for an established framework to fix those issues at the internal framework level? just make sure data, computed, and all else can be accessed.
Surely creating a new API instead of fixing that issue is an admission of failure?
Some comments may only be visible to logged-in visitors. Sign in to view all comments.