loading...

Vue's Darkest Day

danielelkington profile image Daniel Elkington Updated on ・7 min read

Today I was amazed to see the usually positive and friendly VueJS community descend into a bitter war. Two weeks ago Vue creator Evan You released a Request for Comment (RFC) for a new function-based way of writing Vue components in the upcoming Vue 3.0. Today a critical Reddit thread followed by similarly critical comments in a Hacker News thread caused a flood of developers to flock to the original RFC to voice their outrage, some of which were borderline abusive. It was claimed in various places that

  • All Vue code would have to be rewritten in a totally new way because the existing syntax was being removed and replaced with something else;
  • All the time people had spent learning Vue had been wasted given everything was about to change;
  • The new syntax was worse than the old, did not enforce structure, and would lead to spaghetti code;
  • The Vue Core team had suddenly implemented a huge breaking change without any consultation;
  • Vue is turning into React!
  • No, Vue is turning into AngularJS/Angular!
  • All HTML now needs to be written as a giant string!

With walls of negative comments on the Reddit Thread one may be surprised to discover on going to the RFC page that You's RFC has an overwhelmingly high ratio of positive to negative emoji reactions, and many of the initial comments were quite positive. Indeed, the very first comment is particularly full of praise.

I was the person who wrote that first comment. I happened to get a notification that there was a new RFC, read it straight away, saw that it was just what I wanted from Vue 3.0 and that it would help immensely, and left the first comment within 15 minutes of the RFC being published to express my gratitude. I hope to expand here on why I think the new proposal is such a great idea, but first, to address some of the criticism.

I suspect that many people got a little worked up after reading the Hacker News or Reddit threads which had some somewhat misleading comments, and voiced their outrage without reading the original proposal. Evan You has now updated the proposal with a Q&A that addresses many of the issues people have, but to summarise,

  • You don't need to rewrite any code if you don't want to - the new syntax is additive, and the old syntax will remain valid throughout Vue 3.0 and as long as it is still widely used. Even if it eventually gets removed from the Core code, plugins could easily allow the old syntax to be still 100% valid.
  • Time spent learning Vue was not wasted - the new component syntax uses the same concepts that you spent time learning, and other concepts such as Single File Components, templates, and scoped styles work exactly the same.
  • A change hasn't been made without consultation - the RFC is the consultation. The new syntax is still a long way from being released.
  • And no, HTML code doesn't need to be written as a giant string.

A slightly more subjective point is that the new syntax is inferior to the old, and will lead to less structured code. I hope to demonstrate with a simple example why I got so excited when I saw the RFC, and why I think it is superior and will lead to better structured code.

Consider the following fun component that allows a user to enter details of their pet. Note that

  • A message gets displayed when they finish typing their pet's name;
  • Another message gets displayed after they select their pet's size. Form before any data entered - messages are not displayed Form after data entered - messages are displayed

You can try out a demo of the component here and can view the full code using Vue 2.x here (see components/Vue2.vue).

Consider the JavaScript of this component:

export default {
  data() {
    return {
      petName: "",
      petNameTouched: false,
      petSize: "",
      petSizeTouched: false
    };
  },
  computed: {
    petNameComment: function() {
      if (this.petNameTouched) {
        return "Hello " + this.petName;
      }
      return null;
    },
    petSizeComment: function() {
      if (this.petSizeTouched) {
        switch (this.petSize) {
          case "Small":
            return "I can barely see your pet!";
          case "Medium":
            return "Your pet is pretty average.";
          case "Large":
            return "Wow, your pet is huge!";
          default:
            return null;
        }
      }
      return null;
    }
  },
  methods: {
    onPetNameBlur: function() {
      this.petNameTouched = true;
    },
    onPetSizeChange: function() {
      this.petSizeTouched = true;
    }
  }
};

Essentially we have some data, properties computed off that data, and methods that manipulate that data. And notice that in Vue 2.x there is no way to keep related things together. We can't keep the petName data declaration next to the petNameComment computed property or the onPetNameBlur method because in Vue 2.x things are grouped by type.

Of course this doesn't matter too much for a small example like this. But imagine a bigger example, that had multiple pieces of functionality that needed data, computed, methods, and even a watcher or two. There's currently no good way to keep related things together! One might use something like Mixins or Higher Order Components but these have issues - it's hard to see where properties are coming from and there are problems with namespace clashing. (And yes, in this case it would be possible to split things into multiple components, but consider this similar example where it isn't.)

Rather than organising components by option type, the new proposal allows us to organise components by actual functionality. It's similar to how you organise your personal files on your computer - you usually don't have a 'spreadsheets' folder and a 'word documents' folder, instead you might have a 'work' folder and a 'holiday plans' folder. Consider the above component written in the proposed syntax (as best as I am able to without seeing the output - let me know of any bugs you see!):

import { state, computed } from "vue";
export default {
  setup() {
    // Pet name
    const petNameState = state({ name: "", touched: false });
    const petNameComment = computed(() => {
      if (petNameState.touched) {
        return "Hello " + petNameState.name;
      }
      return null;
    });
    const onPetNameBlur = () => {
      petNameState.touched = true;
    };

    // Pet size
    const petSizeState = state({ size: "", touched: false });
    const petSizeComment = computed(() => {
      if (petSizeState.touched) {
        switch (this.petSize) {
          case "Small":
            return "I can barely see your pet!";
          case "Medium":
            return "Your pet is pretty average.";
          case "Large":
            return "Wow, your pet is huge!";
          default:
            return null;
        }
      }
      return null;
    });
    const onPetSizeChange = () => {
      petSizeState.touched = true;
    };

    // All properties we can bind to in our template
    return {
      petName: petNameState.name,
      petNameComment,
      onPetNameBlur,
      petSize: petSizeState.size,
      petSizeComment,
      onPetSizeChange
    };
  }
};

Note that

  • It's ridiculously easy to group related things together;
  • By looking at what gets returned by the setup function we can easily see what we have access to in our template;
  • We can even avoid exposing internal state ('touched') that the template doesn't need access to.

On top of that, the new syntax easily allows full TypeScript support which was difficult to achieve in the Vue 2.x object-based syntax. And we can easily extract out reusable logic into reusable functions. Something like

import { state, computed } from "vue";

function usePetName() {
  const petNameState = state({ name: "", touched: false });
  const petNameComment = computed(() => {
    if (petNameState.touched) {
      return "Hello " + petNameState.name;
    }
    return null;
  });
  const onPetNameBlur = () => {
    petNameState.touched = true;
  };
  return {
    petName: petNameState.name,
    petNameComment,
    onPetNameBlur
  };
}

function usePetSize() {
  const petSizeState = state({ size: "", touched: false });
  const petSizeComment = computed(() => {
    if (petSizeState.touched) {
      switch (this.petSize) {
        case "Small":
          return "I can barely see your pet!";
        case "Medium":
          return "Your pet is pretty average.";
        case "Large":
          return "Wow, your pet is huge!";
        default:
          return null;
      }
    }
    return null;
  });
  const onPetSizeChange = () => {
    petSizeState.touched = true;
  };
  return {
    petSize: petSizeState.size,
    petSizeComment,
    onPetSizeChange
  };
}

export default {
  setup() {
    const { petName, petNameComment, onPetNameBlur } = usePetName();
    const { petSize, petSizeComment, onPetSizeChange } = usePetSize();
    return {
      petName,
      petNameComment,
      onPetNameBlur,
      petSize,
      petSizeComment,
      onPetSizeChange
    };
  }
};

In Vue 2.x I often find myself writing a "monster component" that is hard to break up into smaller pieces - it can't be decomposed into other components because there is too much happening based on a small amount of state. However using the proposed syntax it's easy to see how big components could have logic broken up into smaller reusable pieces, moved into separate files if necessary, leaving you with small, easy-to-understand functions and components.

Is this Vue's darkest day so far? It looks like it. What was until now a community mostly united behind the project's direction has splintered. But I have hope that people will take another look at a proposal that doesn't break anything, still allows them to group things by option type if that's what they like doing, but allows for so much more - clearer code, cleaner code, more interesting library possibilities, and full TypeScript support.

Finally, when using open source software, it's good to remember that the maintainers are putting a lot of effort into something that you get to use for free. Some of the borderline abusive criticism seen today is something that they really shouldn't have to put up with. Thankfully the disrespectful comments were a minority (albeit a sizeable one) and many were able to express themselves in a more respectful manner.

Update June 23 2019:
I wrote the original post very quickly and without expecting it to receive the attention that it has. Since then I've realised that the code example was too complex for the point I was trying to illustrate, so I've simplified it greatly. The original code sample can be found here.

Discussion

markdown guide
 

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.

 

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.

 
 

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.

 

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.

 

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

 

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.

 

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

 

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.
 

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.

 

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.

 

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

 

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!

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 🙂

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

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.

 

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

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

 

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

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

 

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.

 

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.

 

But that setup() function trigger me everytime.

 

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

 

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.

 

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.

 

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.

 

Just decided learning Vue, should I wait until Vue 3 is out so I start with the new way of coding?

 

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.

 

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

 

"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

 

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.

 

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

 

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?

 

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.