1 让人搞不清楚状况的API@click="handleClick"
这个写法大家都很熟悉的。然后，Vue还允许这样写：
@click="handleClick()"
emmm……？？？？
精彩。
于是，当我们有这样一个函数的时候呢：
handleClick : (fnType) => () => { .... }
@click="handleClick(1)"
请问：在点击之后，我们预期中的那个函数到底是会执行呢，还是不会执行呢？
括号这东西，要加就加，要不加就不加，怎么做都是对的，但这一会儿加一会儿不加的……emmm？
这种省几个字母造成更大困惑的地方我印象中可能还不止这一处。
作者：匿名用户
链接：https://www.zhihu.com/question/315734889/answer/624608264
来源：知乎
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。

2 不方便编辑器/IDE提供支持，相关支持较为滞后首先要承认，这个现在这个已经基本不算问题了。不过曾经还是让人很卵痛的。vue的组件的配置项大概是这样：
{
  data(){ return {...} }
  methods: {
    xxxFn(){ this.xxxx  }
  }
}
于是，通常来说，在methods对象而言，this指针访问不到data函数return的对象里面的数据，这个应该算是js的正常表现吧？但是在vue里面是可以的。其间发生了什么大家肯定都知道也就不必多说。但是，但是呐——
编辑器/IDE（包括Typescript）的智能提示是怎么知道的呢？
一开始的时候大概也就是瞎猜，后来TS专门为了这玩意儿更新了一些特性，终于能支持了。
但是我们可以马后炮地回想一下，vue的这个组件API设计之初……肯定是没考虑IDE的支持问题的。
事实上，不止如此。
包括那个什么.vue文件，这个东西推出的时候，IDE支持是跟着同步推出的吗？我印象中好像是没有的。包括vetur什么的，也都是第三方提供的吧。那么在此之前是怎么写.vue文件的呢……？
谈到这个话题恐怕就要男默女泪了。
究其根本，那就是vue一开始并非为工程化而设计的。某些特性提出来，配套工具却不一定跟上了的。相对应的，你看React丢一个hooks出来，会为之配套eslint规则；Vue群众最喜欢黑的“超级复杂的”Angular框架，也有模板语法的语言服务啊？
当然，这只是针对现阶段的Vue来黑的。
3 做不了面向对象编程有一些大佬以为在React“代表了函数式编程”之后，Vue就可以被称作是“面向对象之大成”了，以至于如果有人说喜欢React、厌烦Vue，那么就可以给他打上“此人不懂面向对象”的标签。
殊不知Vue这个框架也就是个谜一样的this指针比较万能，开发起来的体验其实更像是过程化编程……（当然，我不是说面向过程编程就有问题了）
我们都知道，vue的结构是data是data，methods是methods，分的很开的。而这个“分的很开”的做法，恰巧就和面向对象一毛钱关系都没有。可能各位非常懂得面向对象编程的Vue大佬们会不屑于看一下其他语言吧，但是……通常来说，一个存储了各种数据、没有挂方法的“对象”……是会被称作为“结构”的……（当然，这个也不是准确的定义，很多语言的结构上也是能挂方法的）
那么，这样有什么坏处呢？来举个简单的例子。
比如我们有个pager: { pageSize: number, pageNum: number, totalCount: number }
然后项目里规定了一些通用的翻页事件，比如这样:
next() {
  this.pageNum++
  // ...someting else
}
那么，这个时候，pager对象里面既有数据又有方法，它该不该放到data里面呢？顺带，哪怕你硬着头皮把它放到data里面了，它的this也依然会指偏啊。
可能有人会想起来，我们还有autobind之类的装饰器，能够方便地把this锁住。然而，这就涉及到另一个悲伤的故事了：vue是会用getter和setter做代理的，而autobind之类的库也会用到getter和setter……它们……冲突了……
可能这个时候有人会想：“一个pager而已，直接拆开写又怎么了。”
那么，很好，现在就进入了面向对象的领域……
如果某些页面的pager需要一些强化的功能呢？是不是要扩展这个对象？那么拆开写可怎么extend啊？要用魔法mixin吗？
组件因为涉及到模板部分，所以想做扩展是真的难。可是vue这面向过程的设计，怕是连组件逻辑都很难拿出来做扩展了。
4 vuex魔法字符串过多，且基本不大可能用常量解决。
和v-model冲突。（这一条其实可以理解，但是就实际情况而言……新人们好像经常中招啊）
mapState/mapGetters，在大部分情况下意义不明。
action-mutation看上去好像很美，实际上大部分人写的代码都是重复的……别提redux，提了就一起黑。
5 路由那个keep-alive……可真是个好功能。（棒读）
6 社区对全局注册的滥用这个严格意义上来说不是vue本身的问题，但是你看某组件库……
他们的组件是<xx-xxxx>这样命名的，为啥消息框却是this.$message呢……叫this.xxMessage我觉得大概也没什么特别能引起人不适的地方吧？（还是说我没能理解这样做的好处……？）

1 让人搞不清楚状况的API@click="handleClick"
这个写法大家都很熟悉的。然后，Vue还允许这样写：
@click="handleClick()"
emmm……？？？？
精彩。
于是，当我们有这样一个函数的时候呢：
handleClick : (fnType) => () => { .... }
@click="handleClick(1)"
请问：在点击之后，我们预期中的那个函数到底是会执行呢，还是不会执行呢？
括号这东西，要加就加，要不加就不加，怎么做都是对的，但这一会儿加一会儿不加的……emmm？
这种省几个字母造成更大困惑的地方我印象中可能还不止这一处。
作者：匿名用户
链接：https://www.zhihu.com/question/315734889/answer/624608264
来源：知乎
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。

2 不方便编辑器/IDE提供支持，相关支持较为滞后首先要承认，这个现在这个已经基本不算问题了。不过曾经还是让人很卵痛的。vue的组件的配置项大概是这样：
{
  data(){ return {...} }
  methods: {
    xxxFn(){ this.xxxx  }
  }
}
于是，通常来说，在methods对象而言，this指针访问不到data函数return的对象里面的数据，这个应该算是js的正常表现吧？但是在vue里面是可以的。其间发生了什么大家肯定都知道也就不必多说。但是，但是呐——
编辑器/IDE（包括Typescript）的智能提示是怎么知道的呢？
一开始的时候大概也就是瞎猜，后来TS专门为了这玩意儿更新了一些特性，终于能支持了。
但是我们可以马后炮地回想一下，vue的这个组件API设计之初……肯定是没考虑IDE的支持问题的。
事实上，不止如此。
包括那个什么.vue文件，这个东西推出的时候，IDE支持是跟着同步推出的吗？我印象中好像是没有的。包括vetur什么的，也都是第三方提供的吧。那么在此之前是怎么写.vue文件的呢……？
谈到这个话题恐怕就要男默女泪了。
究其根本，那就是vue一开始并非为工程化而设计的。某些特性提出来，配套工具却不一定跟上了的。相对应的，你看React丢一个hooks出来，会为之配套eslint规则；Vue群众最喜欢黑的“超级复杂的”Angular框架，也有模板语法的语言服务啊？
当然，这只是针对现阶段的Vue来黑的。
3 做不了面向对象编程有一些大佬以为在React“代表了函数式编程”之后，Vue就可以被称作是“面向对象之大成”了，以至于如果有人说喜欢React、厌烦Vue，那么就可以给他打上“此人不懂面向对象”的标签。
殊不知Vue这个框架也就是个谜一样的this指针比较万能，开发起来的体验其实更像是过程化编程……（当然，我不是说面向过程编程就有问题了）
我们都知道，vue的结构是data是data，methods是methods，分的很开的。而这个“分的很开”的做法，恰巧就和面向对象一毛钱关系都没有。可能各位非常懂得面向对象编程的Vue大佬们会不屑于看一下其他语言吧，但是……通常来说，一个存储了各种数据、没有挂方法的“对象”……是会被称作为“结构”的……（当然，这个也不是准确的定义，很多语言的结构上也是能挂方法的）
那么，这样有什么坏处呢？来举个简单的例子。
比如我们有个pager: { pageSize: number, pageNum: number, totalCount: number }
然后项目里规定了一些通用的翻页事件，比如这样:
next() {
  this.pageNum++
  // ...someting else
}
那么，这个时候，pager对象里面既有数据又有方法，它该不该放到data里面呢？顺带，哪怕你硬着头皮把它放到data里面了，它的this也依然会指偏啊。
可能有人会想起来，我们还有autobind之类的装饰器，能够方便地把this锁住。然而，这就涉及到另一个悲伤的故事了：vue是会用getter和setter做代理的，而autobind之类的库也会用到getter和setter……它们……冲突了……
可能这个时候有人会想：“一个pager而已，直接拆开写又怎么了。”
那么，很好，现在就进入了面向对象的领域……
如果某些页面的pager需要一些强化的功能呢？是不是要扩展这个对象？那么拆开写可怎么extend啊？要用魔法mixin吗？
组件因为涉及到模板部分，所以想做扩展是真的难。可是vue这面向过程的设计，怕是连组件逻辑都很难拿出来做扩展了。
4 vuex魔法字符串过多，且基本不大可能用常量解决。
和v-model冲突。（这一条其实可以理解，但是就实际情况而言……新人们好像经常中招啊）
mapState/mapGetters，在大部分情况下意义不明。
action-mutation看上去好像很美，实际上大部分人写的代码都是重复的……别提redux，提了就一起黑。
5 路由那个keep-alive……可真是个好功能。（棒读）
6 社区对全局注册的滥用这个严格意义上来说不是vue本身的问题，但是你看某组件库……
他们的组件是<xx-xxxx>这样命名的，为啥消息框却是this.$message呢……叫this.xxMessage我觉得大概也没什么特别能引起人不适的地方吧？（还是说我没能理解这样做的好处……？）