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 ...
For further actions, you may consider blocking this person and/or reporting abuse
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.
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.
I even got a name - Nue /njuː/
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
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.
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.
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).
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....
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.
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.
I can certainly understand why the Vue team is heading in this direction (some of what you propose will make it easier to write less code and have that code be easier to follow), you're substituting one complexity for another. While yes you will be able to group named attributes together so that they flow logically, you're distributing functionality all over a component making THAT part harder to read.
As many others have said, knowing that all my computed properties are in one place (for example) is a good thing. It's easy to read and it's fast to find the computed, watch, etc. components because they are in the same place - grouped by framework functionality. That's one thing that I really enjoy about Vue. Where the break occurs is not so much in that area with respect to collecting things together - its that the data section is declaring one type of functionality (standard vars) and the others are declaring vars that have a behavior. That part in the current syntax is less than elegant and this seems to address it in a way - though have to const everything and return the variable list seems less DRY when in that syntax.
Will the world end if you make this change - no, but it starts to look a whole lot like the frameworks we didn't choose because we liked the simplicity that came from Vue's syntax. Large bodies of React code can be a nightmare to work through because React doesn't require adherence to any spec - and what you're doing here can lead to the same. It will likely end up littered all over the place as it ends up in larger React projects.
Quite frankly if I wanted heavy TypeScript support - I would have just stayed playing with Angular. If I wanted to have React Hooks - I would be using React. Vue will run the risk of losing the thing that makes people like Vue as opposed to the other frameworks, and the benefit is negligible IMO. Don't write it off as people being afraid of change - but moreso people having made an intentional choice in framework for very specific reason.
That said, I would MUCH prefer a @props based approach if you're going to shake up the syntax. Going with classes and annotations is very readable and tends to be organized given the way a traditional developer writes code.
"Quite frankly if I wanted heavy TypeScript support - I would have just stayed playing with Angular. If I wanted to have React Hooks - I would be using React. Vue will run the risk of losing the thing that makes people like Vue as opposed to the other frameworks"
Totally agree!
You are absolutely correct, you just read my mind.
This new syntax is looking so much like React IMO
Exactly. It seems less DRY and less KISS
You're right about what I mean "It's easy to read and it's fast to find the computed, watch, etc."
I think it's disingenuous to claim this. This isn't our first rodeo. We all know the old syntax will become deprecated over time and won't be maintained with the same vigor as the new, shiny way. In time you will be (essentially) forced to rewrite to the new way. And it's not a question of if it will be removed, but only when. It always is.
Resources are always limited and most resources will be devoted to the new and the old will languish. It can't be any other way.
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.
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.
As someone who is relatively new to front-end ecosystem, I chose Vue because all other frameworks seemed very complicated to me. When I see Vue3, I get the same feeling about it. I understand all the arguments why to choose this new way of doing things, but I guess Vue will loose the "very easy to grasp" vibe, for me at least.
I would understand your fears if Vue was going to switch to the new syntax completely. But with keeping the current syntax as a default option I think Vue won't become any harder to learn. In fact, right now the framework has plenty of advanced options like functional or renderless components or using JSX + render functions. Yes, they are niche and fully optional; so the function-based API will be.
I hope this help to resolve your concerns about Vue 3 learning curve ;)
In my honest opinion this scares me even more. Now I feel like when a newcomer is beginning to learn Vue they HAVE to know that Vue actually has two different syntax's. This is going to make it incredibly hard to get help. Just because both API's are supported doesn't mean they will be supported fairly. You have to be honest, resources aren't unlimited. At some point more resources will be spread to making the documentation better or the examples better for one of the API's. Chances are examples and code snippets being shown and kept up to date using both API's are rare in my mind. Every framework or language says they will. Guess what? every framework or language lies. They realize the resources aren't there.
I love Vue, but I'm just being honest: I do not think both API's would be treated the same. At some point it will cause a big separation in the community because some people are going to argue that the old syntax is better, while some people are going to argue that the new syntax is better.
I honestly think if you make a change like this, then you have to do it a certain way and saying you'll support both just isn't the way to do it in my mind.
To my opinion on the new syntax though: I can see where it can help and be easier to see what you actually have and where things are. But I can take the example from the original post (or even any example I've seem from the new syntax) and easily make it very hard to read and follow. I feel like they are acting like this just automatically makes components easier to read. They don't. It's 100% up to the person coding it to code them that way. You can write good code or bad code in ANY framework.
You have said it all
Thing is, you dont know for how long is it going to be around, and not considered legacy.
I was about to teach vue to a junior coworker, will I be teaching him a way to code in vue that is doomed to be conidered legacy in a year?
It's already promised that object syntax will be around for the whole 3.x lifecycle (which is not less than a couple of years) and there is no clear promise to deprecate it in 4.x (which is not even planned so far). I think in a modern frontend development world where everything changes very fast, this can be considered as 'stable'.
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.
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.
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! 😂
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
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😂😂
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.
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.
Nice idea but why not to extend mixins possibilities with this syntax:
I use TypeScript with Vue via the vue-class-component. I can group data, computeds, props, watches, functions, etc. anyway I want to. I had hoped that this syntax would become more popular. It's great.
Read your example. Thanks, but still think the new Syntax is a massive shift from the reasons we chose Vue and I'm pretty sure most of us will shift to SvelteJS if this will be what Vue 3 will look like. (or React which at least is as complex syntactically but much more commercial).
Who is "most of us"? I think Svelte is looking great but there is a lot more reasons I use Vue than syntax. The cli UI for instance is pretty neat. And again nothing is being removed for the foreseeable future...
I browsed through HN, Reddit, the comments here. There's a strong majority of Devs who chose Vue even though React was much more popular, especially 1-2 years ago, and by being more popular it also made it easier for them to find a new job/gig. So the reason they chose it was because they found it easier to pickup, more intuitive, with less boilerplate, without ugly stuff like
this.handleClick = this.handleClick.bind(this);. I actively filtered 80% of the job offers I had 2 years ago and went with a Vue project.I fail to see how
setup() { dump everything here }responds to these needs. I would bet actual money if this RFC becomes reality (seems like it) that's going to be quite a big popularity hit for Vue. (sadly, because I really liked it.)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.
I absolutely disagree with this example, second one is completely unreadable, what is the point of putting things together when you can't normally read that. Imagine every developer will be doing this his own way, some will group watchers and computed together, some will group by some logic, other will just put everything randomly. This new RFC is going to create complete mess in the code. Having separate computed, watch, data, etc... is the main reason why I use Vue instead of React, cause in React I already see this mess when it's not clear what comes from where and it's pain to work with that code if it's not written by you.
Imo your composition is not right.
Split components and communicate them - and you will have petSize and petName very close to each other.
Trying to justify very, very complex change with too simplistic and poorly designed example is not a good approach imo.
Hi Michał, thanks for the feedback. Agree that the component composition of the example isn’t ideal - in a real application you could split them.
Coming up with a good example is hard. One could opt for
In this post I’ve opted for the latter.
If you’re interested in a slightly more complex example that can’t really be split into multiple components, check out this example.
I'll preface this by stating I was, at first, fully on board with this RFC and excited for its release. The more I look into it though the less I like it. It seems overly verbose and hard to read at a glance due to the amount of stuff that is passed into function calls. There are brackets all over the place!
What is this RFC actually solving:
thisrefers to the Vue component instance and sidesteps most of the other quirks that we currently deal with.The question is: is it really worth it? It's gonna be confusing for newcomers to learn two different methods of doing basically the same thing. It also doesn't really solve the modularity issue all that well either. Sure, it's better than what we currently have but it isn't the prettiest syntax to look at and requires a lot of boilerplate which is what we are trying to avoid in the first place right?
The main issue I have at the moment is that I have yet to see an example where I can clearly say the new syntax is better than what we currently have. Everything I've seen has just appeared like a different way of doing the same thing instead of a better way as pretty much every example is overly simple and really doesn't benefit from the new features.
In the example above it feels like the event handlers were forced in there just to demonstrate how methods in the new syntax work and add another thing to group together. If I were implementing that UI I would just base the
touchedstate on whether thenameorpetSizein either case had a value. That's sorta the whole benefit of vue being data driven.What I would prefer instead of this proposal is a way to make self contained vue objects which act somewhat like mixins but don't actually get merged into the component. Currently you can create a new vue instance and use that to modularize your code:
Ideally, there would be a way to bind this instance in such a way that lifecycle hooks are called automatically (I've used methods in my example) and vars like
this.$elare bound to those of the parent component so it is a self contained object which inherits context from the component it is bound on. For me, this would solve the issue of modularity in a much cleaner way. With such a system you get the benefit of modularity without worrying about name collisions and you keep the syntax we all know (for now anyway) but it doesn't help with typescript support in any way.I've said it before on other topics, it's ridiculous that people start commenting/venting in disrespectful ways like that. Even You is putting his heart and soul into this stuff, what are people thinking? After all it's only technology, not politics or religion.
Besides, the proposal obviously looks a lot like React Hooks - do we see people in the React world getting all worked up like that? They simply discuss the merits and pros/cons of a new idea, and then decide to adopt it or not. No need for flame wars or to get personal ...
But that
setup()function trigger me everytime.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.
Congrats on the time spent writing this post. I believe it's a great new option for architecting a frontend application. Evan You is to be congratulated, again, for giving us the possibility of acting with functional programming. The community needs to understand that it is a new way and not a single way.
I think the main issue of the community was that 1. This was not presented as a consultation (the 2.x API is going away in v.4), and 2. The way the negative reaction was handled (often condescending, and without addressing the issues which were brought up).
A good explanation is here: old.reddit.com/r/vuejs/comments/c3...
A comment addressing this article very, is here: old.reddit.com/r/vuejs/comments/c3...
Lastly, the RFC was changed to add some clarifications about keeping the 2.x API in v.3 mid-discussion.
I don't know how you can compare your code samples and reach the conclusion:
It is much less easy to group things and to quickly make sense of the component structure.
"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. " - My last 2 years
No, don't wait. Pretty much everything you'll learn now will still be valuable when v3 comes!
I explained it in more detail in this Reddit comment: reddit.com/r/vuejs/comments/c36gp9... 🚀
Let me tell you something. I hated the whole React hooks system. It has been an absolute mess of a pattern because developers, no matter how much we teach them to separate concerns and to keep things maintainable, continue to create large, bloated, and messy components. Additionally, we keep treating functions like classes. Classes have properties and methods, functions don't, yet we have this hooks antipattern infecting not just React, but now Vue; it's just not natural. You get much better legibility with classes and objects because I can quickly look for where props, methods and data are supposed to be. Now I have to look for an endless list of
constvariables that are intermingled and not separated carefully. You can say that this API is optional, but look what happened to React, their hooks are optional too but the whole industry decided to use them for everything, so who's to say that might not happen with Vue too. I'm sorry but I'm not supporting this Composition API, but sticking to Vue-Property-Decorator as soon as it finishes migrating. If I'm gonna be forced to write this way in the future, I might as well move to Svelte instead. If I want better performance, Svelte is beating all three major frameworks already.Thank you @danielkington for your beautiful insight. For Vue2.x, it is also possible to have reusable functions and make it less painful to write giant components. Though, I prefer separation of concerns having the JavaScript, css and template separated. The only issues I might have with vue3.x is finding solutions and insights easily on stackoverflow and library supports. Thanks
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.
At end of the day, like any other framework, Vue is just a tool. A great tool.
I first started with Vue and I’m very thankful because it allowed me to easily understood the concepts of a modern js framework(and a lot more, ofc). I’m also thankful for the work that the team and the community put in to give us good and reliable learning resources.
I’ll still enjoy every line written in Vue no matter what happens to the framework.
It’s just JavaScript, right?
As a developer with 25+ years experience who has selected Vue.js for projects that my team works on but who never actually developed with Vue.js, I find your 3.0 code much easier to reason about than your 2.0 code in this article.
#fwiw
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.
This is EXACTLY the change I want; I appreciate your demonstrating why this is a good thing so cogently. Creating "wizard" style multipanel inputs has been more painful in the web world ever since I joined the webdev game years ago. This should make my code MUCH more compact and more importantly, readable. Thank you.
I think the main issue of the community was that 1. This was not presented as a consultation (the 2.x API is going away in v.4), and 2. The way the negative reaction was handled (often condescending, and without addressing the issues which were brought up).
A good explanation is here: old.reddit.com/r/vuejs/comments/c3...
A comment addressing this article, is here: old.reddit.com/r/vuejs/comments/c3...
Lastly, the RFC was changed to add some clarifications about keeping the 2.x API in v.3 mid-discussion.
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?
Thanks for this article. I was wondering what the fuss was all about, and then I saw it's about a RFC (Request for Comment) and some people seem to be freaking out like it's going to be released next week.
This already happened with Angular with many breaking changes and along the way many people left and I'm guessing learned to hate Angular.
I am just starting off ramping-up on Vue + TypeScript for a new consulting role. For me, as long as the TypeScript code remains the same I don't care what the underlying JS code looks like.
I personally think Vue.js is still to basic and not a mature Framework or productive as Angular. It will continue to evolve and break things along the way. It will come up with new way to do things.
I'm guessing a lot of junior coders scared of by Typescript and Angular see Vue as simple and easy to learn. So if their reality of "simple" is threatened, they will get upset. If they are forced to do things in new way, they will get upset.
You didn't address the fact that new hipster coders will always want to use the new way to do things, but you will still have a lot of coders who want to do it the old way. No one likes changes and having to keep learning. Most developers want ROI on their learning.
As a consultant, I hate breaking changes, because then I am forced to work on legacy code and also forced to learn the new way because hipster coder like to change stuff up. This is just a problem with the JavaScript eco-system and JS coders in general. JS is like building a house on sand. In a few weeks to a month, code that once worked will break.
Something about this new API reminds me quite a lot to Knockout JS. What you are exporting is basically the viewModel that we have in KO and you can also declare the computed properties, normal properties, etc in quite a similar way that the old dog KO :P I'm not sure if I'm the only one seeing the similarities here hehe
social media/speed of communication seems to bring out the worst in ppl. i guess it gives the podcasts new material.
Your second example already has more code. More code scares me and I'm sure there are people like me who gets put off by more code. In the case of apps with multi functionality. Does Vuex not solve that problem?
The main reason I see this as the darkest day for Vue. Is that they are actively choosing to abandon the one thing that made Vue so popular and morphing it into something that starts to look like react. With that you loose your right to exist. More developers would have chosen react over Vue if it wasn't for Vue's current style.
What they should have done? Keep the good and loved bits and make the bad ones better:
The next path of VueJS is exciting. It might bring new adepts, and make other leave. Let's see what will happen shortly.
Who bets? x))
For sure, as one of the most stable, code breaking-free and community-driven framework ever made, EmberJS is the one I recommend to focus on.
Observation: after removing comments, replacing consecutive spaces with single spaces, and removing remaining spaces from line starts, your old-style code example is 640 characters, and your new-style code example is 854 characters, an increase of about a third.
Yes, it's just one example, code size is highly dependent on choices such as variable naming, longer code may be justified by greater clarity, etc. But it's a hint.
Frankly, I don't find your new-style code example any easier to understand. You seem to think there's no value in "organising components by option type", but knowing what's a datum, what's a computed property, what's a method, etc. is, in fact, part of understanding a component, and in old-style code, these things are obvious, whereas in new-style code, they're less so - not deeply obscure, of course, but it takes a little more effort to grasp them. That the code is somewhat longer doesn't help.
But for purposes of discussion, let's suppose many people do or would find new-style code easier to understand. My advice would be to make it available as a new, separate framework - call it Nue.js. As other commenters have already remarked, those of us who've been around for awhile - and I've done many kinds of programming for over 30 years - have seen this kind of situation before. Inevitably, the new style will become the de facto standard. Ironically, Evan You himself has seen something like this kind of situation before, when he worked for Meteor Development Group, and MDG deprecated Blaze in favor of React. It was highly controversial, and for good reasons. (I and a few others urged MDG to adopt Vue, if they didn't want to maintain Blaze, but to no avail.)
As Yogi Berra may or may not have said, if it ain't broke, don't "fix" it. Every time you change the rules of a programming language or framework, you impose a significant burden on the people who use it, most of whom typically have many other things on their minds and would really like your language or framework to just keep working in the way they're familiar with. Accordingly, it's something to do only with great care and for compelling reasons. "Things would/might be a little clearer this way" is not a compelling reason.
Nice article. Vue code is starting to look my old-school knockout code a little.
I haven’t started using TypeScript with Vue, but I will definitely look at this new structure when I move to that.
Thanks!
I started using Vue after having worked on personal projects with react. So I was very much a beginner. I LOVED the fact that I did not have to differentiate between different syntaxes, as I did with React.
So yes - from a beginner's perspective, this change WILL make things harder. I can't say I understand the new syntax yet.
The current one is super-intuitive for front-enders. If you know HTML, CSS and Javascript, the template structure is an obvious way to organise things. Sure, for advanced use it has limitations, but it is so VERY legible. I love it.
I suspect that I would hesitate to use the new syntax as a default, simply because the old one is so much more intuitive.
In the example code I'm totally lost: where is the html that gets rendered? I don't even see a render function! (as I would have in react).
Well the new style just looks like react.
And what i dont like about this style. You dont know where stuff is.
Everyone structers the functions else. Every group can be split diffrently.
Already those simple examples are hard to read.
In the current syntax i know exactly where to look at.
I use vue because i like vue not because i want it to be like react or angular
Btw. simple example but already big diffrents between lines count.
Great explanation of the advantages of the new syntax! If used well this can greatly improve modularity and reuse, but it requires some getting used to this new way of thinking.
But I think any ambitious and open-minded Vue dev/user welcomes this.
Thank you for this post! "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." - This 100%. As a software engineer, I'm thankful everyday to the thousands of people pouring their heart into open-source. It is mind boggling how one can be so small-minded and rude.
I appreciate you providing an example as to why you like the new vue3 structure. In reading the code, I can't help but think, why doesn't vue.js use an OOP paradigm. OOP can be combined with functional code, as in Scala. Even Vanilla JavaScript provides a class syntax now. Why aren't we "grouping" by object and adding listeners and methods to a class. Components could be composed of classes instead of lots of functions. If code organization and scalability is the issue, OOP might provide helpful, rather than requiring a lot of function syntax. If devs hate writing curly braces (as in python devs), they're really going to get sick of writing the arrow function syntax which adds "=>" to another pair of curly braces. In addition, if the new framework code structure is to enable the use of Typescript, that seems like another reason to start thinking OOP and developing encapulated, inheritable, polymorphic classes in the browser.
The second example just doesn't look like Vue anymore... I can't get my head around how unpretty it's going to become 🙁
This happening only because it's pull request number 42!
With a tiny hello world-lish example the lack of structure doesnt look too bad, but take this to real world componets and it is a recipe for spagethi IMO.
What a mess. It looks like React and that's not a good thing.
If you get a chance, I'd recommend taking a look at this live coding presentation of the Composition API in action. I think it helps to demonstrate how much cleaner things can be with this new syntax - much better than the example in my post! youtube.com/watch?v=JON6X6Wmteo
Thanks Daniel, awesome post 👍
I can already see how this new proposal is going to help on existing projects.
Just wanted to say thanks for taking the time to write this up! Really appreciate your perspective, and definitely excited for the future! 🙂
agree vue is becoming more like react
You can use vue-function-api to implement the vue3 version.
In this great Industry we must be prepared for the changes of X technology. Vue is great and version 3 comes with excellent improvements.
Hooks disrupting communities since 2019 🤣
This is what happens when the core values are not adhered to. And Typescript now? Really? Typescript is not JavaScript.
Well, if you ask me, I'll say that nothing lasts forever 😁, Vue is subject to change and So is every other thing 🤷
All publicity is good publicity
All publicity is good publicity :v
Sounds like a fun time to learn Ember.js!
Sad news.
The Vue adoption will decline and, in my eyes, more complicated React will win.
We had good times with Vue but I guess it's time to move on.