在 SegmentFault，解决技术问题
每个月，我们帮助 1000 万的开发者解决各种各样的技术问题。并助力他们在技术能力、职业生涯、影响力上获得提升。
一线的工程师、著名开源项目的作者们，都在这里：
获取验证码
已有账号？
问题对人有帮助，内容完整，我也想知道答案
问题没有实际价值，缺少关键内容，没有改进余地
想用h5的drag实现拖拽,drop时，没有出现对应的console，求大神解释代码如下
&!DOCTYPE html&
&title&title&/title&
&style type="text/css"&
width: 100
background-color:
height: 100
width: 400
height: 300
&script type="text/javascript" src="vue.js"&&/script&
&div id="app"&
&div id="box" draggable="true" @dragstart='drag($event)'&&/div&
v-for="(item, index) in list"
:style="item.styleObj"
@drop='drop($event)'
@dragover='allowDrop($event)'
&{{item.id}}&/li&
&script type="text/javascript"&
el:"#app",
id:'001',styleObj:{background:'url(img/1.jpg)'}
console.log(e.currentTarget.offsetTop)
console.log('drop')
allowDrop(){
console.log('allowDrop')
答案对人有帮助，有参考价值
答案没帮助，是错误的答案，答非所问
开发拖拽业务最好使用插件
答案对人有帮助，有参考价值
答案没帮助，是错误的答案，答非所问
设置可拖拽目标.设置属性draggable="true"实现元素的可拖拽.监听dragstart设置拖拽数据为拖拽操作设置反馈图标(可选)设置允许的拖放效果,如copy,move,link设置拖放目标,默认情况下浏览器阻止所有的拖放操作,所以需要监听dragenter或者dragover取消浏览器默认行为使元素可拖放.监听drop事件执行所需操作
你的代码改成这样就能触发了
allowDrop(e){
e.preventDefault();
console.log('allowDrop')
分享到微博？
关闭理由：
删除理由：
忽略理由：
推广（招聘、广告、SEO 等）方面的内容
与已有问题重复（请编辑该提问指向已有相同问题）
答非所问，不符合答题要求
宜作评论而非答案
带有人身攻击、辱骂、仇恨等违反条款的内容
无法获得确切结果的问题
非开发直接相关的问题
非技术提问的讨论型问题
其他原因（请补充说明）
我要该，理由是：为啥我要牺牲陪老婆孩子的时间来替你省学英语的时间？&br&&br&---&br&&br&没想到这个答案居然这么多赞，这真不是段子... 借此机会啰嗦一些吧：&br&&br&1. 英语好好学，这是为你自己好。英语是如今当程序员的必备技能，“英语不好也能成为好程序员” 是自欺欺人，不要为自己的懒惰找借口，更不要把这种责任转嫁到别人身上。&br&&br&2. 开源项目，不管人多人少，总是精力有限的。翻译是个体力活，不要想当然地觉得作者顺手翻译一下工作量不大... 你连看英文都嫌麻烦呢，你的麻烦就是麻烦，我的麻烦就不是麻烦了？感情我已经免费提供了一个框架还得劳心劳力把您伺候周到了才算是有责任感... 用开源项目的时候，请千万不要有这种错把自己当客户的想法。觉得缺了什么的话，先想想自己能不能出一份力，而不是作者能为我再做些什么。事无巨细地同步多语言文档，对于项目的核心开发者而言，绝对是一个高投入低回报的行为，所以绝大部分开源项目都只有英文文档。Vue 的中文、日文文档也都是由社区成员主导和维护的。对于社区成员来说，参与翻译一来锻炼英语，二来加深理解，三来可以作为自己的开源贡献资历，其实好处很多。&br&&br&3. 评论里有人说我原始答案的态度让人失望，请别搞错了：我对于为了自己方便理直气壮地向开源项目索求更多的人从来都是这种态度，但这不代表我对所有用户都是这种态度。另外，我最讨厌的就是那种在别人微博/回答下面教别人注意说话口气，说什么取关/粉转路人的人，你要转路人就转，不用特意让我知道。
为啥我要牺牲陪老婆孩子的时间来替你省学英语的时间？ --- 没想到这个答案居然这么多赞，这真不是段子... 借此机会啰嗦一些吧： 1. 英语好好学，这是为你自己好。英语是如今当程序员的必备技能，“英语不好也能成为好程序员” 是自欺欺人，不要为自己的懒惰…
&p&从刚正面的角度来说，&a href=&/p/& class=&internal&&我已经把大漠穷秋第一篇文章里的技术事实谬误都一一指出了&/a&，他的整篇文章从头到尾没有一个点是站得住脚的。后几篇都是人身攻击，没有回应的兴趣。&/p&&p&顺便容我指出一个事实：大漠穷秋的这一系列文章是&b&恶意攻击&/b&，已经不属于争论的范畴了。单纯的技术争论我是敞开了欢迎的，但请别玩下三路的东西。&/p&&p&如果我写了一篇评论别人框架的文章，首先我不会用这么 low 的语言去攻击别人，其次如果里面有事实错误，那我肯定会道歉。如果大漠在看过我的反驳文章之后至少对他自己文章里那些和事实不符的地方道歉，那我也敬他是条汉子。但是他的选择是无视我的回应，在恶意攻击的路上越走越远。到这里我已经发现这个人根本没有沟通的意向 —— 你打脸对面装作没发生，继续自说自话，这还怎么『争论』？&/p&&p&如果他只是个野生 Angular 爱好者，这事儿也就到此结束了，拉黑就是了。但是大漠穷秋是顶着 Angular PM 的招牌，官方指派来推广 Angular 的，现在他做的这些事情，完全就是在给 Angular 招黑... 说真的，我是看不下去了才告诉 Igor 好让他管管，这是为 Angular 好，我跟 Angular 又没有仇，故意放着让他继续代表 Angular 那才是真小人。&/p&&p&有人说『凡是把技术问题上升到政治问题就是不对 / 以后技术讨论不高兴了就告诉你领导』的，我问你们两个问题：&/p&&p&1. 大漠穷秋这样的行为还算是在讨论技术么？如果你觉得大漠穷秋的言论属于合理的技术讨论，我只能报以呵呵然后拉黑你。&/p&&p&2. 如果你是他老板，他顶着你公司的名头来这么一出，你是希望早点有人知会你呢，还是后知后觉不可收拾了才得知？&/p&&p&还有一些上蹿下跳说我推广 Vue 是靠喷别的框架的人，造谣成本真是低啊，说着说着就像真的一样了，有本事你倒是拿具体的例子来啊。&/p&
从刚正面的角度来说，，他的整篇文章从头到尾没有一个点是站得住脚的。后几篇都是人身攻击，没有回应的兴趣。顺便容我指出一个事实：大漠穷秋的这一系列文章是恶意攻击，已经不属于争论的范畴了。单…
谢谢邀请，这个问题我要认真回答一下，尽量不带主观偏向。&br&&br&我们学一个东西，通常两个目的：&br&&br&- 为了解决现有的问题&br&- 为了解决将来可能会有的问题&br&&br&所以，在学这些东西之前，先必须了解，它们是用来解决什么问题的。&br&&br&Angular，React，Vue，这三者其实面对的是同一个领域，那就是Web应用，什么是Web应用呢，我之前有一篇大致讲了：&a href=&///?target=https%3A///xufei/blog/issues/5& class=& wrap external& target=&_blank& rel=&nofollow noreferrer&&构建单页Web应用 · Issue #5 · xufei/blog · GitHub&i class=&icon-external&&&/i&&/a&&br&&br&这三者中，Angular的适用领域相对窄一些，React可以拓展到服务端，移动端Native部分，而Vue因为比较轻量，还能用于业务场景非常轻的页面中。&br&&br&在Web应用中，我们需要解决的问题可以归纳为三类：&br&&br&- 状态&br&- 组织&br&- 效率&br&&br&1. 状态&br&&br&什么是&b&&u&状态&/u&&/b&？&br&&br&在一个业务界面中，我们可能会根据某些数据去生成一块界面，然后通过界面上的某些操作，改变一些数据，从而影响界面的另外一些部分。&br&&br&这里面就存在两种关系，一种是从数据到界面，一种是从界面到数据。能够描述界面当前状况的数据，就可以被称为状态。&br&&br&如果不对状态作抽象，很可能会导致逻辑的混乱，比如说，一个地方点了，要改多个地方，这种代码直接写，很容易写乱的，所以，不同的框架采用不同的方式进行了处理。&br&&br&比如说MVVM流的Angular和Vue，还有Avalon，Regular，Knockout，都是走的这一流派，通过类似模板的语法，描述界面状态与数据的绑定关系，然后通过内部转换，把这个结构建立起来，当界面发生变化的时候，按照配置规则去更新相应的数据，然后，再根据配置好的规则去，从数据更新界面状态。&br&&br&React走的是另外一个流派，就是所谓的函数式，在这个里面，推崇的是单向数据流：给定原始界面（或数据），施加一个变化，就能推导出另外一个状态（界面或者数据的更新）。&br&&br&在这里需要额外提一下ReactiveJS，它的理念又有所不同，是基于Reactive的。&br&&br&2. 组织&br&&br&刚才这些，都可以看作是满足最基本的需求，那就是业务的正确性。在这之后，就有另外的诉求了，首当其冲的就是整个业务代码的组织。&br&&br&所谓&u&&b&组织&/b&&/u&，指的是两个方面，一方面是模块关系，另一方面是业务模型。&br&&br&我们是怎样解决模块关系的呢？共识就是组件化。整个应用形成倒置的组件树，每个组件提供对外接口，然后内部只关注自己的实现。这些东西说起来简单，但实际做的时候还是有非常多需要考虑的东西，包括组件的定义，约束，管理，测试等等，而在Web这个体系中，组件化也有一些不太适合的场景，需要做一些权衡，这方面详细说就比较复杂了，需要好多篇幅才能说清楚，可以看看我这篇：&a href=&///?target=https%3A///xufei/blog/issues/22& class=& wrap external& target=&_blank& rel=&nofollow noreferrer&&Web应用组件化的权衡 · Issue #22 · xufei/blog · GitHub&i class=&icon-external&&&/i&&/a&&br&&br&那么，业务模型又是指什么呢？我们提到React的时候，就会听到Flux，Redux之类的东西，为什么又要有它们呢？我们必须认识到，脱离了这类东西，纯上层的组件化是不牢固的，如果你感受不到，只有一个原因：你的项目的业务层太薄。&br&&br&业务模型指的是所处领域中的业务数据、规则、流程的集合。即使抛开所有展示层，这一层也是应当要能够运作起来的。&br&&br&那么，这跟Redux之类又有什么关系呢？&br&&br&我们刚才提到组件化，整个应用形成了一个组件树，组件之间可能会需要通讯，它们通讯的内容可能是简单的界面事件，也可能是业务含义较深，能够牵一发而动全身的。界面是怎么来的？是由初始界面加上状态形成的，为了能够反映界面的变化，我们必须使得对业务模型的每一个扰动都收敛到确切的状态，所以，这也就是Redux这类东西的意义所在。&br&&br&所以，没有Redux之类辅助方案的React，是不完整的。而Redux本身，也不是局限到只能作为React辅助方案的，它的理念，对于Angular，Vue，照样是非常重要的补充。在同一业务场景下，对于每个框架来说，数据模型层面临的问题都是一样的，在这一层并没有任何分别。&br&&br&另外，Angular 2中引入了RxJS，这个东西处理这方面也是有很大优势的。&br&&br&在这里我要插一句自己的想法，很多学习能力较强的朋友，当他发现FP，FRP之类编程模型的时候，会非常喜欢，但对于大型项目，需要很多人协作的状况来说，不一定是好事。&br&&br&用面向过程，面向对象的那些方式，虽然笨重，但好处是门槛低，符合大多数人的理解和思维方式，并且可以复用几十年积累的各种设计模式和经验。所以，如果不是小而精悍的团队，我对引入FP和FRP都是比较保守的。&br&&br&在这些东西下层，还有Relay，GraphQL等等致力于业务模型同步的方案，但这个引入代价同样是非常大。&br&&br&再插另外一句：很多人吐槽Angular大而全笨重，吐槽React全家桶，但其实世界上大部分人是没有框架整合能力的，小而美的库最后整合了，在面临各种业务需求之后不断引入新模块，也还是一个大而全的方案。在绝大部分场景下，还是有一整套标配模块比较好。你看ExtJS他也单独提供ExtCore模块，但不但竞争不过jQuery，连mootools和prototype都竞争不过，用它的人几乎都是用全方案的。&br&&br&3. 效率&br&&br&效率也分两种，一种是开发效率，一种是运行效率。&br&&br&我们前面提到，组件化，这是提升开发效率的一种手段，在组件化这个点上，各路框架的组织方式大同小异，反正最终都是组件树。&br&&br&具体到单个组件的实现上，我个人是倾向于MVVM流的，之前 &a data-hash=&790dccce26904cdcd11b0fad3bac37b7& href=&///people/790dccce26904cdcd11b0fad3bac37b7& class=&member_mention& data-tip=&p$b$790dccce26904cdcd11b0fad3bac37b7& data-hovercard=&p$b$790dccce26904cdcd11b0fad3bac37b7&&@题叶&/a&
做过对比，MVVM系的代码量会少一些，开发效率稍高一点。&br&&br&其中，Angular因为实现的特殊性，有作用域继承之类的双刃剑黑魔法，开发效率的不稳定因素要高不少，深刻理解的人用起来效率很高，不理解的用了到处是坑。&br&&br&再看运行效率，这里面，Angular是较低的那个，主要在于数据变更检测方式，但这也不是绝对的，在部分场景下，脏检测未必就没有优势，这个记得 &a data-hash=&f7f6a8faef3b8bedb53e7& href=&///people/f7f6a8faef3b8bedb53e7& class=&member_mention& data-tip=&p$b$f7f6a8faef3b8bedb53e7& data-hovercard=&p$b$f7f6a8faef3b8bedb53e7&&@郑海波&/a&论述过。&br&&br&运行效率的另外一面主要是创建和修改DOM，在创建上，大家是没有太大差异的，而在修改DOM的时候，React首创的虚拟DOM有很大优势，所以其他框架内部实现也在逐渐借鉴。&br&&br&（我之前有个对虚拟DOM的回答是有偏差的，稍后去更新）&br&&br&========&br&&br&如果看到这里，很可能你会疑惑，题目问的明明是学哪个好，我说这些是什么意思？&br&&br&我用这些篇幅说明了Web应用的业务开发中存在哪些麻烦，每种技术又是来解决什么痛点的，这样，你可以按照自己的需求去，结合业务场景进行分析，然后选择需要的挨个学下去。&br&&br&其实学API之类的很快，还是要把自己业务中的难点想清楚，带着问题去学，带着需求去学，学思想重于学使用，一定能事半功倍。
谢谢邀请，这个问题我要认真回答一下，尽量不带主观偏向。 我们学一个东西，通常两个目的： - 为了解决现有的问题 - 为了解决将来可能会有的问题 所以，在学这些东西之前，先必须了解，它们是用来解决什么问题的。 Angular，React，Vue，这三者其实面对的是…
&p&呵呵，伸手党的要求真是越来越高了，开源不好做啊。&/p&&p&我觉得吧，这本质上是个情商问题。如果题主是真心想学，那就好好提问： “我觉得文档中 render 函数的部分理解起来有些吃力，希望能有人帮忙解惑”，保证会得到完全不同的结果。然而你却选择了发泄你的负面情绪，把一切责任推给了文档。&/p&&p&善意的提问，我自然会善意地回答。但我也不是圣人，抱怨发泄性质的提问，我忍不住了就要怼的。对这种态度报以善意，只会让伸手党觉得自己理所应当是大爷，社区的环境只会更差。&/p&&p&---&/p&&p&给一些吃瓜群众的补充：Vue 的文档很可能是所有前端项目里最用心的，比较过就知道。看到这个问题的感受大概就跟你辛辛苦苦加班做完了项目，PM 一脸嫌弃地跟你说『怎么才做了这么点功能』差不多。我跟各位贡献者辛辛苦苦写 + 翻译的文档免费给人看，还要被人抱怨，不好意思这个锅我们不背。&/p&
呵呵，伸手党的要求真是越来越高了，开源不好做啊。我觉得吧，这本质上是个情商问题。如果题主是真心想学，那就好好提问： “我觉得文档中 render 函数的部分理解起来有些吃力，希望能有人帮忙解惑”，保证会得到完全不同的结果。然而你却选择了发泄你的负…
果然还是有这个问题，看来大家对八卦都很感兴趣，那我说一下吧。&br&&br&加入Teambition之前，我对TB原有的技术栈和将要做的改造都是有所考虑的，也是带着明确的技术倾向加入的（TypeScript，RxJS，Vue），这些不是无目的的，因为之前，我就认识曾经在Teambition工作过的寸志、题叶等，对这个场景有过一定程度的思考。&br&&br&Teambition主版本的技术栈是Backbone + JQuery + CoffeeScript，这个组合，从当时来看，可以理解，然而，3年过去了，整个前端领域发生了天翻地覆的变化，大清是肯定要亡了，问题在于两点：&br&&br&&ul&&li&康梁，还是孙黄？&br&&/li&&li&三民主义，还是锤子镰刀？&br&&/li&&/ul&&br&对于一个旧系统的改造，无非两条路：逐步改进；推翻重来。一般来说，逐步改进都是优于推翻重来的，因为赌多大就可能输多大。&br&&br&4月中旬，我入职半个月左右的时候，我逐渐倾向于重新做一套，原因在于两点：&br&&br&第一，原先数据模型层处理得不好，主要是：同步和异步的处理、数据的共享和更新机制，如果要改对，非常困难，而且从底层开始把同步改异步，很可能需要一路往上改到顶。在不换掉老数据层的情况下，有很多遗留问题几乎无法解决。&br&&br&我举个例子，有不少数据都是初始化的时候提前加载好，设置到Collection中，然后之后的所有操作全部同步调用，这样的问题在于，并不是所有数据都立刻需要，但如果你要把这些数据的请求改成用Promise之类做封装，有缓存就立即返回，没缓存就查询，会导致与之相关的所有业务代码都要变成异步的方式。&br&&br&另外，数据模型之间的监听关系也存在缺失，由于Teambition产品交互的特殊性，很多视图要共享一些业务数据，而且是全业务存在WebSocket推送，不把监听关系全部写对的后果是，可能你改了某个地方的数据，原先应当同步的十多个集合里面，漏通知了某些，那些对应的视图就不一致了。&br&&br&第二，Teambition有一个Mobile Web版，数据模型跟PC版是一致的，只是视图和业务逻辑比较简单一些，有机会先重构这个版本，验证完整个流程，然后从小到大反推PC版。这个过程是可以降低一些风险的。甚至，后面可以考虑把小企业用户和大企业用户的版本分开，把这个新版作为其中某一个的基础版本。&br&&br&对于新版数据层的设计，我是有整体思路的，只是部分细节的考虑还不完善，这些事情我跟团队的太狼说了，给他讲了RxJS的事情（最近我和他都写过对这方面的总结），还有我对整个这块东西的考虑，他非常给力，冒着差点不能毕业的风险，在学校拼命写了超多代码，把这个事情搞得比我想象中还要快。大家可以看看这个库的提交记录，感受一下战斗力：&a href=&///?target=https%3A///teambition/teambition-sdk& class=& wrap external& target=&_blank& rel=&nofollow noreferrer&&teambition/teambition-sdk&i class=&icon-external&&&/i&&/a&&br&&br&然后，5月份下旬开始，他的这块初步可用，我们就开始做新版Mobile Web，同时帮他踩坑。这个版本是用Vue + TS做的，当时vue-rx这个库还不太行，所以我们都是手动订阅数据流，然后往data里面设置。&br&&br&这段时间整体还是比较顺利的，然而到了6月份，出了个突发状况，原先从简聊回归到Teambition的部分同事对我当时的状况产生了误会，认为我长期把PC版丢着不管，去搞一个没那么重要的小版本，本末倒置，然后他们直接开始用React + Redux改进原先PC版的视图层。&br&&br&这个时候我比较尴尬，因为mobile的事情尚未结束，是丢不下来的，即使这块做完，PC版的发展方向也已经大大偏离我的预期了，这几位同事找我聊过一次，建议我把之前做的东西放弃，改用React + Redux。&br&&br&然后我挺苦闷的，想来想去，觉得这样不能接受，就提出了离职。这件事情并未跟团队中任何人说过，只有上层知道。老板向我询问这两种技术方案的关系，我回答了一句：三民主义和共产主义都能救中国，但两个不能一起上。&br&&br&反复争执对团队肯定是很不利，所以当时我的意思是，既然要我放弃之前做的方案，那不如我彻底离开，再招几个React方向的人进来，全部转换到这条路，也是能行的。但上层觉得这样不好，还是建议我们沟通，让那几位同事放弃他们的方案。这个时候，他们大概写了三周左右时间的代码，某一块功能接近完成的状态。&br&&br&公司上层建议我再沟通一下，可能事情还有转机。当时我的心态已经不一样了，后来想想，还是坚持一下吧。&br&&br&既然要沟通，就要讨论后面事情怎么做，尴尬的是，团队中只有个别人支持Vue，绝大部分人无明显倾向（因为原Teambition的开发人员都是没有接触过React的），部分同事强烈倾向于React，所以很难达成共识，而且当时讨论到一半，我倾向使用Vue，希望Mobile和PC版技术栈一致，得到的指责是不顾大局，只顾自己利益，RxJS也被认为不适用于Teambition应用场景，但我坚持认为它在这个场景下，明显优于Redux。&br&&br&争执不下的时候，太狼提议我们使用Angular2，这个妥协的选择被接受了，不少同事认为，使用大厂的产品会更可靠一些，我也不排斥这个选择，因为RxJS、TypeScript这两个东西在ng2里面更加被深度使用。（大家唯一分歧较小的地方竟然是开发语言的选择，除了个别同事希望用ES6之外，好多人都认同TypeScript，因为Teambition最复杂的还是业务逻辑层，用比较严格的限制还是有很多好处的）&br&&br&后来就开始搞ng2，当时正好有一个企业版新功能，然后就先做它，但做的过程中还是踩到不少坑，比如那个rc5版本的升级，又加回来了ngModule，导致大部分代码都修改了，这个东西我很不认同。&br&&br&另外一个出了挺多问题的东西是zone.js，我们那个功能是要集成在主系统里，所以是先启动主应用，然后再bootstrap ng2的，zone跟外面一些东西有些冲突，后来想办法解决了，然后在不同浏览器上又出现了一些问题，花了挺多时间的。&br&&br&这个部分做完之后，大家开始对ng2也不满意了，所以，最后又变成React技术栈了。不过，到这个时候，大家已经逐步意识到RxJS这套方案的好处了，我们开始那个数据层的库，其实是在做整个应用的全局数据状态管理，视图层状态是从它推导出来的，所以现在又引入了redux-observable来做中间的转换。&br&&br&另外，因为业务的发展，整体重构的可能已经减小了，所以只能局部优化，并且尝试把新版数据层逐步接入。后面一段时间中，最大的难点应该就在这里。&br&&br&在回到React体系之后，我基本上就确定一定会离开了。很多技术方案没有明显好坏的区分，都很优秀，但人是有口味偏好的，长期以来，我一直更认同MVVM框架们，认为在JS这种不纯的体系，一味追求纯函数、无副作用，未必是一个好的选择。在复杂场景下，把业务抽象到Rx管道中，视图层的事情则完全交给轻量MVVM框架，把MVVM框架整个视为一层Virtual DOM，一样会是一个好的解决方案。&br&&br&我认同在数据和业务逻辑层使用FP或者FRP以更好地抽象，并且覆盖全量测试，但在贴近视图这里，还是坚持自己的看法：在MDV（数据驱动视图）的情况下，没有必要对业务视图组件做测试，只需保证数据正确即可。在这一点上，我跟很多团队成员是有分歧的。&br&&br&短短8个月，经历了很多事情，终究选择了离开。正如另外一个回答说的，我不差钱，想离职就离职。一个工作十多年的码农，谈不上有钱，也绝不至于饿死，真那么在意钱，我年初就该去阿里啊。像我这种没有任何物质爱好的人，还是做点让自己开心的事情比较好，到这年纪还在一线搞代码，本身就是对这个职业充满热爱。三年前跟响马哥吃饭，我问他，为什么有nodejs，你还要搞fibjs？他说，技术人员有自己的偏好，写代码还不是为了按照自己喜欢的方式吗？我深以为然。&br&&br&Teambition的这些同事，朝气蓬勃，对技术有着很强的热情，虽然理念未必相同，但也能够从他们身上学到不少东西。我虽然比TB前端团队平均年龄大10岁左右，但我内心也是他们这样的人，我也有我的坚持，一样的心高气傲，不愿放弃自己的棱角。&br&&br&现在，在Teambition前端全面转向React体系的情况下，欢迎喜欢这条技术路线的朋友们加入他们，一起改变世界。&br&&br&-------11.28晚上补充--------&br&&br&今天一天看到这么多评论……，有一些事情大家不要过多猜测，我列这些出来的主要原因是要解释技术选型怎么会这么转换的，其中踩过哪些坑，供同行参考。整个事情，我觉得自己沟通方面的问题比较多，入职之前没有沟通清楚是架构师还是前端leader，入职之后花了很久才勉强搞清楚成员的技能等级，平时跟大家交流看法也不多，了解和熟悉业务的过程也比较慢，整个做事情也一直很tb的节奏有些不太搭。&br&&br&这里面不存在上级授权的问题，应该说上层还是寄予了较多期望，我自己在遇到困难的时候是那种比较闷的人，有不少问题是沟通不顺畅引起的，美玲总结得很好，应该还是因为我不太适合这个岗位，所以很勉强地做下去，对公司、自己、团队成员都有挺多伤害的。&br&&br&（以上言辞如果有不合适的，请联系我修改）
果然还是有这个问题，看来大家对八卦都很感兴趣，那我说一下吧。 加入Teambition之前，我对TB原有的技术栈和将要做的改造都是有所考虑的，也是带着明确的技术倾向加入的（TypeScript，RxJS，Vue），这些不是无目的的，因为之前，我就认识曾经在Teambition工…
更新：&br&1、由饿了么 UED （&a href=&/elemeued& class=&internal&&知乎专栏&/a&）设计的桌面端组件库已经开源，文档：&a href=&///?target=http%3A//element.eleme.io/%23/& class=& wrap external& target=&_blank& rel=&nofollow noreferrer&&Element&i class=&icon-external&&&/i&&/a&，仓库： &a href=&///?target=https%3A///ElemeFE/element& class=& wrap external& target=&_blank& rel=&nofollow noreferrer&&GitHub - ElemeFE/element: Desktop UI elements for Vue.js 2.0&i class=&icon-external&&&/i&&/a&。这套组件库是基于 Vue 2 的，我们也希望大家开始使用 Vue 2，一起来丰富它的生态圈。&br&2、下面提到的移动端组件都被整合进了 &a href=&///?target=http%3A//mint-ui.github.io/%23%21/zh-cn& class=& wrap external& target=&_blank& rel=&nofollow noreferrer&&Mint UI&i class=&icon-external&&&/i&&/a&，仓库在 &a href=&///?target=https%3A///ElemeFE/mint-ui& class=& wrap external& target=&_blank& rel=&nofollow noreferrer&&GitHub - ElemeFE/mint-ui: Mobile UI elements for vue.js&i class=&icon-external&&&/i&&/a&&br&======= 原答案 =======&br&饿了么。&br&从去年开始，有越来越多的项目在使用 vue。这些项目里面，有桌面端（比如 &a href=&///?target=https%3A//security.ele.me& class=& wrap external& target=&_blank& rel=&nofollow noreferrer&&饿了么安全应急响应中心&i class=&icon-external&&&/i&&/a&）也有移动端（比如 &a href=&///?target=https%3A//jobs-mobile.ele.me& class=& wrap external& target=&_blank& rel=&nofollow noreferrer&&饿了么招聘&i class=&icon-external&&&/i&&/a&），有面向用户的，也有后台系统。&br&实践方案的话，vue + webpack + vue-router + vue-resource。&br&就我个人而言，vue 的开发体验还是比较愉悦的。首先，文档非常友好，所以上手会比较快。其次，配合 webpack 和 vue-loader，每个页面都是一个 .vue 文件，写起来很方便。另外，适合做组件化开发（每个组件也是一个 .vue 文件，可以全局或者在需要的地方引入），如果遇到比较复杂的、父子组件间需要频繁通信的场景，可以用 vuex 搞定。&br&在写业务的过程中，团队的同事们抽象了很多公共组件出来，开源在 github （&a href=&///?target=https%3A///elemefe& class=& wrap external& target=&_blank& rel=&nofollow noreferrer&&饿了么前端 · GitHub&i class=&icon-external&&&/i&&/a&）上，大家有兴趣的话可以去试一试。这里我把这些组件分类介绍一下：&ul&&li&移动端：&/li&&/ul&vue-swipe：&a href=&///?target=https%3A///ElemeFE/vue-swipe& class=& external& target=&_blank& rel=&nofollow noreferrer&&&span class=&invisible&&https://&/span&&span class=&visible&&/ElemeFE/vue-&/span&&span class=&invisible&&swipe&/span&&span class=&ellipsis&&&/span&&i class=&icon-external&&&/i&&/a&&br&幻灯片组件&br&&br&vue-infinite-scroll：&a href=&///?target=https%3A///ElemeFE/vue-infinite-scroll& class=& external& target=&_blank& rel=&nofollow noreferrer&&&span class=&invisible&&https://&/span&&span class=&visible&&/ElemeFE/vue-&/span&&span class=&invisible&&infinite-scroll&/span&&span class=&ellipsis&&&/span&&i class=&icon-external&&&/i&&/a&&br&无限滚动，可以实现向下的无限加载。是一个 directive&br&&br&vue-loadmore：&a href=&///?target=https%3A///ElemeFE/vue-loadmore& class=& external& target=&_blank& rel=&nofollow noreferrer&&&span class=&invisible&&https://&/span&&span class=&visible&&/ElemeFE/vue-&/span&&span class=&invisible&&loadmore&/span&&span class=&ellipsis&&&/span&&i class=&icon-external&&&/i&&/a&&br&下拉加载和上拉加载。是一个 component&br&&br&vue-toast-mobile：&a href=&///?target=https%3A///ElemeFE/vue-toast-mobile& class=& external& target=&_blank& rel=&nofollow noreferrer&&&span class=&invisible&&https://&/span&&span class=&visible&&/ElemeFE/vue-&/span&&span class=&invisible&&toast-mobile&/span&&span class=&ellipsis&&&/span&&i class=&icon-external&&&/i&&/a&&br&toast 组件&br&&br&vue-indicator：&a href=&///?target=https%3A///ElemeFE/vue-indicator& class=& external& target=&_blank& rel=&nofollow noreferrer&&&span class=&invisible&&https://&/span&&span class=&visible&&/ElemeFE/vue-&/span&&span class=&invisible&&indicator&/span&&span class=&ellipsis&&&/span&&i class=&icon-external&&&/i&&/a&&br&indicator 组件，提示用户正在加载，自带 modal&br&&br&vue-msgbox：&a href=&///?target=https%3A///ElemeFE/vue-msgbox& class=& external& target=&_blank& rel=&nofollow noreferrer&&&span class=&invisible&&https://&/span&&span class=&visible&&/ElemeFE/vue-&/span&&span class=&invisible&&msgbox&/span&&span class=&ellipsis&&&/span&&i class=&icon-external&&&/i&&/a&&br&弹出框组件&br&&ul&&li&桌面端&/li&&/ul&目前正在编写一套完整的桌面端组件库，利用它可以快速搭建后台页面。将于近期开源。&br&&br&下面要隆重介绍的是前两天刚发布的一个工具。对于使用 webpack 打包的项目来说，不管是用 vue，angular 还是 react，开启一个新项目的时候都有许多脚手架的工作要做，比如写 webpack 的配置文件，安装依赖等等。这个过程有时会很繁琐，而且对新人不友好。为了解决这个问题，团队的小伙伴写了一个构件工具——&a href=&///?target=http%3A//elemefe.github.io/cooking/& class=& wrap external& target=&_blank& rel=&nofollow noreferrer&&cooking - 更易上手的前端构建工具&i class=&icon-external&&&/i&&/a&。上面列出的工作，cooking 都可以一键完成，能够极大地解放生产力。而且，它不仅支持 vue，angular 和 react 也是支持的。
更新： 1、由饿了么 UED （）设计的桌面端组件库已经开源，文档：，仓库： 。这套组件库是基于 Vue 2 的，我们也希望大家开始使用 Vue 2，一起来丰富它的生态圈。 2、下面提到…
&blockquote&某些把持话语权的所谓大V&/blockquote&&p&咦，大V是说我吗？说得好像我有能力操控知乎一样，哈，看看最近这些话题下排面前面的答案，我还差点就信了。&/p&&p&至少在知乎上，在较少涉及政治敏感的话题领域，话语权不是靠“把持”能得到的。某些人的习惯就是匿名之后然后空口污蔑，随口就把一个不错的产品和平台说得好像是助纣为虐的帮凶。哦对了，还有一个习惯是开口就定义了“整个前端圈子”，把自己打扮成只身抵抗暴政的模样。嘿，这也入戏太深了吧？&/p&&blockquote&很多想支持一下大漠的人，都必须匿名，想过原因么？&/blockquote&&p&想过。匿名就不用为自己的言辞负责了嘛。&/p&&blockquote&大漠的文章的确有很多错误，因言获罪和政治正确难道就是对的？&/blockquote&&p&犯了错误就要承担后果。都是成年人了，这道理还要人教？&/p&&p&什么“因言获罪”？他是被请喝茶了还是被拘留了？真的“因言获罪”的，是能连累到让所有程序员连JavaScript都打不出来。你们别太狂妄自大了。&/p&&p&什么“政治正确”？一个布道师出来胡口乱喷，坑自己老板、坑自己公司、坑自己社区、最后不出意料也坑了自己，我难道还要说：表演虽然拙劣，但情有可原，都是 vue || angular || google || react || 知乎 || 微博 || 小白 || 大V || 前端圈子 || 社会的错！&/p&&p&&br&&/p&&p&穷秋以这样一种姿态离职并删完所有文章，十之八九是谷歌给的压力，但应该也不会出来道歉了。&/p&&p&其实就算他出来道歉，还是会有一些人出于各种原因给他鸣不平啊。&/p&&p&&br&&/p&&p&但你们考虑过被污蔑“抄袭”的开源库的作者和所有contributors的感受么？辛辛苦苦写代码被人一句抄袭，虽然有点智商的一看都知道是胡扯，但是架不住总有少数匿名的和匿脸的在那儿嗡嗡嗡啊。心情大坏有没有？&/p&&p&你们考虑过无端被骂“小白”的感受么？我只是听说某框架容易上手，就先选这个开始学了，我招谁惹谁了，要被这样羞辱？&/p&&p&你们考虑过Angular社区其他人的感受吗？这种“推广”是唱哪出？大漠穷秋老师是被盗号了？好多人来问我vue是不是真的抄袭了ng，我该怎么回答？还有vue的粉丝骂上门来，怼回去吧，好像失了分寸，不做声吧，又咽不下这口气……&/p&&p&你们考虑过栾跃的感受么？好不容易做到大中华区主管这个位置了，是造了什么孽要出来这样低声下气的道歉？而且道歉之后，下属居然还不停手，继续变本加厉的发攻击帖？这不是打我脸根本领导无能吗？以后在公司还怎么混？&/p&&p&你们考虑过Google人事的感受吗？不解职吧，如此违背公司价值观；解职吧，万一被说是拿临时工顶包怎么办？反正今夏是好不了了。&/p&&p&你们考虑过广大吃瓜前端的感受吗？艹，明明是这后端api测都没测乱写一通，我给他开个工单，他撇下一句，就你们前端娱乐圈事儿多！&/p&&p&&br&&/p&&p&&br&&/p&&p&要之：穷秋攻击因为vue容易上手而选择vue的前端初学者，是为不仁；自己老板出来道歉他还乱发文章，给公司添乱，是为不忠；给Angular社区丢人现眼，对不起辛苦推广ng的社区同仁，是为不义；一篇一篇攻击文章出来，却对别人指出错误不予回应，是为无礼；自己技术水平根本跟尤雨溪不在一个水平上，挑错对手，乱起战端，是为不智；被人吊打，还不承认错误，反过来污人抄袭，无勇且不知耻。如此不仁不忠不义不智无礼无勇无耻，还有甚可洗的？&/p&&p&&br&&/p&&p&&br&&/p&&p&&br&&/p&&p&PS. 对最后这段话可以有两种理解。一个是我腹黑（骂人不带脏字）。一个是，作为跟大漠穷秋有过一面之缘的前辈（我就不谦虚了），给的忠告。采取哪种理解，各自随意。&/p&
某些把持话语权的所谓大V咦，大V是说我吗？说得好像我有能力操控知乎一样，哈，看看最近这些话题下排面前面的答案，我还差点就信了。至少在知乎上，在较少涉及政治敏感的话题领域，话语权不是靠“把持”能得到的。某些人的习惯就是匿名之后然后空口污蔑，随…
先声明，作为 Vue 的作者我有利益相关，但我尽量从客观角度说说我的看法。&br&&br&&b&主流并不一定只有一个赢家&/b&&br&&br&首先，我觉得框架间的竞争并不是零和游戏。虽然解决的核心痛点有重合，但适用场景还是有区别。比如 React/Vue 这样以 view layer 为核心，可以灵活选择整体架构和工具链的框架，和 Angular 2 这样大而全一站到底的框架，各有各适合的场景。Vue 因为不需要构建也能直接用，也能用在一些比 React 更轻量的场景中。撇开场景，也有开发风格的偏好问题。有些人用 React 更有效率，有些人用 Vue 更有效率，而 C#/Java 生态圈一大群人会觉得 TypeScript 和 Angular 2 让他们更有效率。最理想的情况是大家都找到最符合自己场景需求和开发偏好的框架，所以我觉得多框架的并存是合理且有意义的，不太可能出现 Angular 2 火了就没人再用 React/Vue 的情况。&br&&br&&b&技术角度&/b&&br&&br&React 和 Angular 2 都有服务端渲染和原生渲染的功能（Angular 2 只是号称会有，具体啥时候会有，好不好用还不知道）。这两个东西在对此有需求的场景下，是很有吸引力的，但实际上对此有硬需求的场景占多少百分比则是个问题。比如服务端渲染的前提是前端渲染层得用 Node.js 交给『全栈』去做，原生渲染的多端代码复用率会因应用实际需求而变化，制约它们发挥的条件还是不少的，因此我个人乐观地认为这并不会影响 Vue 在整个市场中占有一席之地。另一方面，手淘已经押宝 Weex，也不排除哪天我会搞个 Vue 服务端渲染。&br&&br&性能方面，这里不深入谈了，这几个主流框架都应该可以轻松应付大部分常见场景的性能需求，区别在于可优化性和优化对于开发体验的影响。这一点上我觉得 Vue 可能是最简单的，加好 track-by 就 ok 了。React 需要 shouldComponentUpdate 或者全面 Immutable，Angular 2 需要手动指定 change detection strategy，都有一定程度的侵入性。但是从整体趋势上来说，浏览器和手机还会越变越快，框架本身的渲染性能在整个前端性能优化体系中，会渐渐淡化，更多的优化点还是在构建方式、缓存、图片加载、网络链路、HTTP/2 等方面。顺道说一句，Angular 2 压缩后的大小是 500 多 kb，在移动场景反正我是不敢用。&br&&br&&b&开发体验&/b&&br&&br&这方面，我个人认为 Vue 是最容易上手，最具亲和度的。工具链方面最近刚发布了 vue-cli，1 分钟搞定 webpack 配置。Vue 组件格式只要你会 HTML/CSS/JS 就能写，你要用 coffeescript 或者 less/sass 也没问题。React 的 JSX 是道坎，但跨过去之后会有一定的生产力提升。社区工具丰富，但实在太多，配置工具麻烦。CSS in JS 也不是每个人的菜。Angular 2 目前上手配置也非常麻烦，官方正在写一个 cli，但体验如何要出来了才知道。它推荐的默认语言是 TypeScript，这个对于静态类型爱好者来说是个大优点，配合 WebStorm/VSCode 体验会很不错，但也不是所有人的菜。&br&&br&&b&社区生态&/b&&br&&ul&&li&React 是目前最成熟也最活跃的，但有一个问题就是过于频繁的方案迭代，几个月前的最佳实践可能明天就变过去式了，而 FB 官方对于最佳实践基本是采取让社区自行发展的态度，因此社区长期处于一个百家争鸣的状态，直到今年下半年才慢慢地开始合流到了 React + react-router + redux 的主流方案，并且这两天也开始讨论工具链的最佳实践。这些东西一旦稳定下来，会进一步巩固 React 的地位。&/li&&li&Vue 的社区固然比不上 React，但也不算太小。Gitter 聊天室里有 1300 来号人，国内听说也有几百人的 QQ 群，论坛上也还算有些活跃度。社区组件也在稳步发展：&a href=&///?target=https%3A///vuejs/awesome-vue%23libraries--plugins& class=& wrap external& target=&_blank& rel=&nofollow noreferrer&&vuejs/awesome-vue · GitHub&i class=&icon-external&&&/i&&/a& 当然比起 React 来说还是小巫见大巫，希望 2016 能更进一步。比起 React 来说，Vue 的一个好处就是提供了官方推荐的 Vue + vue-router + vuex + webpack + vue-loader 的全套方案，如果你不想三个月换一套，就跟着官方推荐走；如果自己有想法，那就自己整也没问题。&/li&&li&Angular 2 的社区，目前来说基本没有，到现在连文档都没写完呢，也没法有什么生态。更伤的是 ng2 和 ng1 的生态是完全割裂的。2016 年能怎么发展，要看 Google 的社区运营做得如何，但不管怎么说 Google 的影响力在那边，群众基数还是很大的...&/li&&/ul&&br&&b&用户来源&/b&&br&&br&这一块
&a data-hash=&cc0145aee04dd53cc6590edd& href=&///people/cc0145aee04dd53cc6590edd& class=&member_mention& data-editable=&true& data-title=&@徐飞& data-tip=&p$b$cc0145aee04dd53cc6590edd& data-hovercard=&p$b$cc0145aee04dd53cc6590edd&&@徐飞&/a& 老师分析得很具体了。当然了，在中国还有另一个制约条件，那就是 IE8，这三个框架里面只有 React 支持 IE8，所以这应该会对 React 在中国的份额有所帮助... 另外徐飞叔预测 2016 年底 Vue 能和另外两个在同一数量级，我觉得还是太乐观了，我个人觉得不太可能 =_=&br&&br&&b&说在最后&/b&&br&&br&看到有人说这个题是在拍马屁。React/Angular 的作者们都不上知乎，那只能认为是在针对我了，但我是理解不了问问题的人拍我马屁有什么好处... 我知道 Vue 最近在国内被提起的比较多，难免会有人觉得是不是吹太过了，对于有这样的想法的同学我有如下建议：&br&&br&1. 如果你没用过 Vue，去用一用，自然会有你自己的判断；&br&2. 如果你用过 Vue，觉得确实吹过头了，欢迎写文章有理有节地来批评。有批评我才能改进 Vue，我会非常感谢你。&br&3. 如果你用过之后觉得确实不错，欢迎你加入社区贡献一份力量，一起推动项目的发展。
先声明，作为 Vue 的作者我有利益相关，但我尽量从客观角度说说我的看法。 主流并不一定只有一个赢家 首先，我觉得框架间的竞争并不是零和游戏。虽然解决的核心痛点有重合，但适用场景还是有区别。比如 React/Vue 这样以 view layer 为核心，可以灵活选择整…
&p&这是钓鱼贴么？呵呵，楼下果然出现了：&/p&&p&- 答非所问推销自己利益相关框架的&/p&&p&- 明嘲暗讽 Vue 简单所以受众都是低端公司和培训机构的高端咨询师&/p&&p&- 连双向绑定是啥都没搞懂就在说 Vue 不适合大型应用的&/p&&p&- 在评论下面嚼舌根直接给人甚至用户群体扣帽子的&/p&&p&承认 Vue 比其他框架易用易学有那么难么？（注意，我这里回答了问题）&/p&&p&为了避免有些玻璃心的其他框架的用户偏题，重要的话说三遍:&/p&&p&&b&说 Vue 易学易用不等于说其他框架不好&/b&&/p&&p&&b&说 Vue 易学易用不等于说其他框架不好&/b&&/p&&p&&b&说 Vue 易学易用不等于说其他框架不好&/b&&/p&&p&当然有些人还是会特意去搜集材料来怼 Vue，说我吹 Vue 包治百病，欲加之罪何患无辞，爱咋咋地吧。&/p&&p&这两年做个框架真是人性的百态都看遍了，很有意思。&/p&
这是钓鱼贴么？呵呵，楼下果然出现了：- 答非所问推销自己利益相关框架的- 明嘲暗讽 Vue 简单所以受众都是低端公司和培训机构的高端咨询师- 连双向绑定是啥都没搞懂就在说 Vue 不适合大型应用的- 在评论下面嚼舌根直接给人甚至用户群体扣帽子的承认 Vue 比…
我就说一点... Patreon 并不是我唯一的收入来源。我现在赚得比在 Meteor 和 Google 都多。&br&&br&当然了，贵司如果想要买安心，赞助一个也是极好的。&br&&br&---&br&&br&稍微补充点关于切题的。&br&&br&首先，同样是个人项目，稳定度可以天差地别。有些人是玩票，有些人是靠项目吃饭，用『个人项目』一刀切地去评判，显然不合理。这里复制黏贴我很久以前的一个评论：&br&&br&&blockquote&大公司 vs. 个人项目，这个是个常见的担忧。我其实有时候觉得一个项目人多未必就好，你如果去 Vue/React/Angular/Ember 的 GitHub issues 转转，你会发现 Vue 的未关闭 issues/bugs 是最少的，而且开过 issue 的人都知道 Vue 的 bug 通常都会在一两天之内就 fix （对数据感兴趣的可以看看 &a href=&///?target=http%3A///& class=& wrap external& target=&_blank& rel=&nofollow noreferrer&&Issue Stats&i class=&icon-external&&&/i&&/a&）。我也参与 Meteor 的维护，深知一个庞大的项目在多人参与之后反而对于 issue 的定位、分配、修正速度有多大的影响，正因为 Vue 是我一个人的项目，我对任意一段代码都了如指掌，所以我修 bug 的效率是多人协作项目根本无法比较的。&br&&br&另一方面，敢不敢依赖个人项目其实完全取决于团队对风险的容忍度，以及觉得项目的开发者靠不靠谱。你看 Laravel / Express / Backbone / Babel / CoffeeScript / Browserify / Webpack / Less / PostCSS / jspm 其实都是一人主导的项目，大家不照样用得风生水起？所以非要拿这个说事儿其实也不全面的。Vue 还很年轻，严格来说我认真开始推 Vue 也就是今年下半年的事情，而且 1.0 发布后的 commit 里面 PR 越来越多，我相信外部贡献者的参与度只会越来越高。&/blockquote&&br&其次，个人 vs. 公司项目，也要看公司的项目在公司的布局中是什么地位。对于大公司来说，开源项目主要是两个意义：&br&&ol&&li&支持自家产品开发；&/li&&li&作为公司的技术公关，提高业界口碑，有利于招人。&/li&&/ol&这其中 (1) 是项目存在的前提，(2) 是开源的目的。很多公司的开源项目是从内部项目开一个分支出来，两边同时维护。如果项目成员忙于应对内部需求，项目开源的部分会立刻变成次要的任务。这一点最近 Dan Abramov 也提到过，React 核心团队其实也就 5~6 个人，很多时候 issue/PR 很久都没人看正是因为他们的优先级是先解决 FB 内部的产品需求而不是解决开源用户遇到的问题。更进一步，当一个项目连 (1) 都不能满足的时候，它会被毫不留情地咔嚓，YUI 就是一个例子，Angular 2 的改动其实是变相地咔嚓了 Angular 1，只不过反响太剧烈导致了负面口碑，所以不得不继续投入资源去维护。&br&&br&相比之下，Vue 的唯一目标就是让开源用户用得爽。这其中的区别，大家可以自己考量。
我就说一点... Patreon 并不是我唯一的收入来源。我现在赚得比在 Meteor 和 Google 都多。 当然了，贵司如果想要买安心，赞助一个也是极好的。 --- 稍微补充点关于切题的。 首先，同样是个人项目，稳定度可以天差地别。有些人是玩票，有些人是靠项目吃饭，…
高级黑啊...&br&&br&假如题主是认真的话，我建议你别纠结这问题。涉及偏好的问题要是真能说服别人，也不会有这么多编程语言和框架了。&br&&br&Guido van Rossum 说，just do a good job. 把事情做好，喜欢的人自然会喜欢。让所有人喜欢不可能，也不用强求。&br&&br&话说回来，这个问题炸出来的个别答案还是挺让我难受的。做 Vue 的初衷很单纯，不是为了赚大钱，不是为了成为大神，也不是因为我发现了什么不得了的创新点。我只是想做一个我自己会喜欢的框架。很巧，我把我想要的东西做出来以后，也有很多其他人喜欢，所以用户越来越多。我从没说过，也不认为 Vue 比所有其他框架都好（我一直的观点都是开发者偏好的多样性使得多框架/语言的共存有益无害，甚至是必要的）。有些答案指出的社区活跃度不如 React 等等，也是事实。除了开源会议上的演讲（大多是受邀），我也没进行过任何所谓的『营销』（我在知乎回答问题都尽量避免推销 Vue）。即使这样，还是会有人看不惯，对 Vue 的用户群体表示鄙视，甚至对我有着强烈的敌意。或许程序员这个靠脑力吃饭的群体，也多少会有『文人相轻』这样的习性。
高级黑啊... 假如题主是认真的话，我建议你别纠结这问题。涉及偏好的问题要是真能说服别人，也不会有这么多编程语言和框架了。 Guido van Rossum 说，just do a good job. 把事情做好，喜欢的人自然会喜欢。让所有人喜欢不可能，也不用强求。 话说回来，这…
如何看待宁可在知乎和百度提问也不去 github 开 issue 的用户?...&br&&br&---&br&&br&补充：题主确实去 github 开 issue 了，但是如我所担心的那样，无视了我苦口婆心写在 issue template 里面的 reporting guidelines，除了提供了个机型之外啥信息也没有... &a href=&///?target=https%3A///vuejs/vue/issues/4727& class=& wrap external& target=&_blank& rel=&nofollow noreferrer&&vue 2.x view render
fail · Issue #4727 · vuejs/vue&i class=&icon-external&&&/i&&/a&&br&&br&你说我一来没有你说的这个机型，二来你没有提供任何重现代码，连 Vue 的具体版本、用了什么插件、用了什么构建工具，用的是手机内置的浏览器、还是 webview、还是 Chrome，什么信息都没有，难道要我专门去买一台这个手机然后靠猜的来帮你重现吗？&br&&br&这里只好借题发挥一下，谈谈开 issue 的姿势问题。开 issue 的初衷，是为了解决问题；但这不代表你开了 issue 就等于把责任全丢给我了；我需要有足够的信息才能定位问题的根源，才有可能解决这个问题。但是这些信息、场景、上下文，只有你才知道，你不说我怎么可能猜得到？真的是拜托了，开 issue 的时候务必站在维护者的立场上思考一下，如果你是维护者看到这样一个 issue，你觉得你有足够的信息去解决这个问题吗？提这样一个信息不完全的 issue，除了浪费大家的时间真的没有任何意义。让你花点时间收集和提供详细的信息，不是为了方便我，而是为了解决你的问题啊...
如何看待宁可在知乎和百度提问也不去 github 开 issue 的用户?... --- 补充：题主确实去 github 开 issue 了，但是如我所担心的那样，无视了我苦口婆心写在 issue template 里面的 reporting guidelines，除了提供了个机型之外啥信息也没有...
已有帐号？
无法登录？
社交帐号登录