DEV Community

Vue's Darkest Day

Daniel Elkington on June 21, 2019

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 ...
Collapse
 
dabit3 profile image
Nader Dabit • Edited

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.

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:

  1. The existing API continues to be supported and improved. The projects using it continue to be stable and resources surrounding it continue to be valid.
  2. The new framework / project could be even more innovative & completely breaking changes could be introduced right out of the gate without any negative outcome.

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.

Collapse
 
linusborg profile image
Thorsten Lünborg

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?

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.

Collapse
 
krzysztofkarol profile image
Krzysztof Karol • Edited

I even got a name - Nue /njuː/

Collapse
 
danielelkington profile image
Daniel Elkington

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.

Collapse
 
linusborg profile image
Thorsten Lünborg

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.

Thread Thread
 
octaneinteractive profile image
Wayne Smallman

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.

Collapse
 
ozzythegiant profile image
Oziel Perez

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

Collapse
 
dasdaniel profile image
Daniel P 🇨🇦

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

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.

Collapse
 
gustojs profile image
Darek Gusto

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.

Collapse
 
sunshinydave profile image
Dave Williams

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

Collapse
 
dasdaniel profile image
Daniel P 🇨🇦

It's much ado about nothing. Start learning and building now, all things change over time (js, frameworks, life).

Collapse
 
leob profile image
leob

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.

Collapse
 
itaditya profile image
Aditya Agarwal

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.

Collapse
 
xsm4el profile image
Ismael Olliver OUEDRAOGO

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

Collapse
 
jwkicklighter profile image
Jordan Kicklighter

the RFC is the consultation

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.

Collapse
 
dinsmoredesign profile image
Derek D • Edited

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.

Collapse
 
gustojs profile image
Darek Gusto

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.

Collapse
 
gregorypierce profile image
Gregory Pierce

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.

Collapse
 
ggojedap profile image
Gustavo Ojeda-P

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

Collapse
 
creativejoe007 profile image
Joseph Martin

You are absolutely correct, you just read my mind.

This new syntax is looking so much like React IMO

Collapse
 
emmymay profile image
EmmyMay

Exactly. It seems less DRY and less KISS

Collapse
 
anhz9x profile image
Anhnt

You're right about what I mean "It's easy to read and it's fast to find the computed, watch, etc."

Collapse
 
michaelhipp profile image
Michael Hipp

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

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.

Collapse
 
bkairu5 profile image
Halafu

Anatomy of a JavaScript framework:

  1. At some point in its life make sure it borrows from or becomes almost similar to ( insert "popular" framework here ).
  2. Make sure it doesn't remain simple and intuitive. As long it remains simple its not good, it has to be complex, exclusive and esoteric. In JavaScript the more esoteric a framework is, the better.
Collapse
 
creativejoe007 profile image
Joseph Martin

I am still wondering how React is still flying... To me I find it too complex.

Seems complexity is the new Bae

Collapse
 
emmymay profile image
EmmyMay

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.

Collapse
 
danielelkington profile image
Daniel Elkington

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.

Collapse
 
vrerabek profile image
vrerabek

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.

Collapse
 
n_tepluhina profile image
Natalia Tepluhina • Edited

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

Collapse
 
twigman08 profile image
Chad Smith

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.

Thread Thread
 
creativejoe007 profile image
Joseph Martin

You have said it all

Collapse
 
andreud profile image
Andres

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?

Thread Thread
 
n_tepluhina profile image
Natalia Tepluhina

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

Collapse
 
drinkredwine profile image
Jozo Kovac

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.

Collapse
 
echoes2099 profile image
echoes2099

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.

Collapse
 
ssimontis profile image
Scott Simontis

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

Collapse
 
alangdm profile image
Alan Dávalos

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

Collapse
 
pringels profile image
Peter Ringelmann

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

Thread Thread
 
emmymay profile image
EmmyMay

I don't want to ever build a website with vanilla Js again😂😂

Collapse
 
echoes2099 profile image
echoes2099

I'm sick of spending hours chasing down broken builds with no rational explanation

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!

Thread Thread
 
ssimontis profile image
Scott Simontis

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.

Collapse
 
danielelkington profile image
Daniel Elkington

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.

Collapse
 
drcmda profile image
Paul Henschel • Edited

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.

Thread Thread
 
linusborg profile image
Thorsten Lünborg

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

Thread Thread
 
danielelkington profile image
Daniel Elkington • Edited

@linusborg Nice! You may want to change the third link in the README from a duplicate CodeSandbox link to dev.to/drcmda/comment/c7l9 🙂

Thread Thread
 
linusborg profile image
Thorsten Lünborg

Oh, thanks. Will do

Thread Thread
 
drcmda profile image
Paul Henschel • Edited

Nice! That helps a lot to understand the differences.

Thread Thread
 
linusborg profile image
Thorsten Lünborg

No, there's no implementation available yet, the proposal is still being discussed and not adopted

Thread Thread
 
liximomo profile image
liximomo

There is an implementation github.com/liximomo/vue-function-api

Thread Thread
 
linusborg profile image
Thorsten Lünborg

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.

Collapse
 
talismax profile image
talismax

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.

Collapse
 
gerasimvol profile image
Vladimir Gerasimenko • Edited

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

Nice idea but why not to extend mixins possibilities with this syntax:

import commonLogic from '~/mixins/commonLogic'

export default {
  mixins: {
    foo: commonLogic
  },

  computed: {
    bar () {
      return this.foo.someData
      // Now I use this.foo.someData instead of this.someData
      // So we know where someData came from
    }
  }
}
Collapse
 
katsanos_george profile image
George Katsanos

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

Collapse
 
collectasaurus profile image
Collectasaurus

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

Collapse
 
katsanos_george profile image
George Katsanos

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

Collapse
 
vedmant profile image
Vedmant

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.

Collapse
 
majkelch profile image
Michał Chruściel

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.

Collapse
 
danielelkington profile image
Daniel Elkington

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

  • A more real, “complex” component that can’t be broken down into smaller components and contains enough moving parts to really justify why the new API is necessary. Problem with putting this sort of example into a blog post is that the reader has to spend a lot of time trying to understand it, and many people understandably won’t.
  • A dumbed-down “simple” component that one can very quickly understand but requires the reader to “imagine” a more complex version of it to understand the problem we are trying to solve.

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.

Collapse
 
despreston profile image
Des • Edited

ya Give me a function with everything stuffed in it, that’s way better than splitting things into intuitive fields grouped by functionality. Not.

Collapse
 
danielelkington profile image
Daniel Elkington

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.

Collapse
 
jamescoyle profile image
James Coyle

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:

  1. Typescript support - I think this is the main benefit of this proposal. I don't use typescript currently so I can't really provide much input on this aspect.
  2. Modularity - This is the big one for me. I think it makes a lot of sense to abstract certain parts of a large component into smaller blocks of functionality.
  3. Less magic? - The new syntax is arguably easier to understand for a complete novice as it doesn't require knowing that this refers 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 touched state on whether the name or petSize in 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.$el are 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.

Collapse
 
leob profile image
leob

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

Collapse
 
chanlito profile image
Chanlito • Edited

But that setup() function trigger me everytime.

Collapse
 
typerory profile image
Rory

"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

Collapse
 
xereda profile image
Jackson R. Schroeder

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.

Collapse
 
martinsotirov profile image
Martin Sotirov

I don't know how you can compare your code samples and reach the conclusion:

It's ridiculously easy to group related things together;

It is much less easy to group things and to quickly make sense of the component structure.

Collapse
 
andrei_says profile image
Andrei Andreev

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.

Collapse
 
devasta_ie profile image
Devasta

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.

Collapse
 
gustojs profile image
Darek Gusto

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.

Collapse
 
dseeker profile image
D See Ker • Edited

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?

Collapse
 
namstel profile image
Namstel

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.

Collapse
 
paulcellsworth profile image
Paul Ellsworth

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.

Collapse
 
anduser96 profile image
Andrei Gatej

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?

Collapse
 
imanhodjaev profile image
Sultan Iman • Edited

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.

Collapse
 
ozzythegiant profile image
Oziel Perez • Edited

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

Collapse
 
procaseycash profile image
Kazeem Olanipekun

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

Collapse
 
aadsm profile image
António Afonso

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.

Collapse
 
mikeschinkel profile image
Mike Schinkel

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

Collapse
 
jonaskuske profile image
Jonas

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

Collapse
 
andrei_says profile image
Andrei Andreev

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.

Collapse
 
angularnodejs profile image
AngularNodeJS 🚀 • Edited

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.

Collapse
 
jdmerinor profile image
Juan Merino

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

Collapse
 
kinghat profile image
kinghat

social media/speed of communication seems to bring out the worst in ppl. i guess it gives the podcasts new material.

Collapse
 
emmymay profile image
EmmyMay

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?

Collapse
 
egranville profile image
Edward

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:

  • Vuex is not what it needs to be
  • We need to share functions between components like we do with filters
Collapse
 
tleperou profile image
Thomas Lepérou

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.

Collapse
 
ralphhaygood profile image
Ralph Haygood

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.

Collapse
 
joelvarty profile image
Joel Varty

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!

Collapse
 
smilingkite profile image
Katinka Hesselink

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

Collapse
 
wenish profile image
Wenish • Edited

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.

Collapse
 
rebeccapeltz profile image
Rebeccca Peltz

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.

Collapse
 
leob profile image
leob • Edited

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.

Collapse
 
yashsway profile image
Yash Kadaru

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.

Collapse
 
jeck5895 profile image
jeck labasan

agree vue is becoming more like react

Collapse
 
jnnrz profile image
Johann

What a mess. It looks like React and that's not a good thing.

Collapse
 
danielelkington profile image
Daniel Elkington

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

Collapse
 
maynor96 profile image
maynor96

In this great Industry we must be prepared for the changes of X technology. Vue is great and version 3 comes with excellent improvements.

Collapse
 
liximomo profile image
liximomo

You can use vue-function-api to implement the vue3 version.

Collapse
 
andreud profile image
Andres

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.

Collapse
 
shetlandj profile image
James

The second example just doesn't look like Vue anymore... I can't get my head around how unpretty it's going to become 🙁

Collapse
 
gilesbutler profile image
Giles Butler

Thanks Daniel, awesome post 👍

I can already see how this new proposal is going to help on existing projects.

Collapse
 
joshblack profile image
Josh Black

Just wanted to say thanks for taking the time to write this up! Really appreciate your perspective, and definitely excited for the future! 🙂

Collapse
 
manutopik profile image
Emmanuel Salomon

This happening only because it's pull request number 42!

Collapse
 
ndiecodes profile image
Ndifreke Friday

Hooks disrupting communities since 2019 🤣

Collapse
 
navicsteinr profile image
Navicstein Rotciv

Well, if you ask me, I'll say that nothing lasts forever 😁, Vue is subject to change and So is every other thing 🤷

Collapse
 
qm3ster profile image
Mihail Malo

All publicity is good publicity :v

Collapse
 
rogerjohn0 profile image
Roger John

This is what happens when the core values are not adhered to. And Typescript now? Really? Typescript is not JavaScript.

Collapse
 
qm3ster profile image
Mihail Malo

All publicity is good publicity

Collapse
 
perpetual_education profile image
perpetual . education

Sounds like a fun time to learn Ember.js!

Collapse
 
igorkosta profile image
Igor

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.