今天是我第三次放弃了Vue...

[fvcenet]

先自我介绍一下，兄弟99年从业，从asp年代摸爬滚打至今仍在一线敲代码，这么多年手里过去的项目也有千八百个了；我呢每个时代都有每个时代的纠结；但总的来说都不如现在的纠结大
后端的：asp、php、.net、java 和前端的 css 、JavaScript一直以来都像自己的伙伴一样，做什么项目伸手就来；在我眼里什么语言已经不重要了，客户要啥我就给他用啥做，问题都不大。

可能是因为从业时间太久了，自己的编程习惯、项目架构方案早就自成体系，也相当成熟，干活儿也不那么伤脑子；

随着目前大前端带动的各种框架越来越火，我还是努力让自己安静去学习那些优秀的框架，例如 vue

坦白的说，每次我基本能用一天时间阅读它的文档，说真的也不难，也很好理解，但是我就是不习惯，为啥呢？

归根结底一句话：我凭啥要按住性子去习惯它的语法？

如果以项目实现为最终目的，我真没觉得包括vue在内的第三方框架有啥好的，因为我骨子里觉得世上没有包治百病的药，即便它是一把十八般武艺兼备的瑞士军刀，在各自的场景下它也未必比我的小工兵锹管用。



现在我结合我在网上看到的其他人的问题，整理可以下几个问题，欢迎各位大拿讨论：

1、无论把vue说出花来，你也不能否认它最终还是要操作DOM的；这时候问题来了——有人说vue操作DOM性能损失小。
我想说： jQuery采用JS原生的getElementByID/Name/Class/TagName等函数操作DOM，性能损失应该不算大。
VUE采用双花括号进行数据绑定，原生JS里面应该没有对应的操作，需要采用RegExp进行匹配，再进行数据替换。
如果从性能而言，我认为vue性能损失更大。

2.Vue的响应式数据绑定，即View里的数据发生变化，Model里的数据会相应变化，看起来很神奇，但真正适用的场景有多少？Model里的数据变化后，会立即和后端交互，那样服务器的压力有多大？大部分时候，只有用户提交表单的时候我们才需要从View获取数据并发送至服务器端，对于实时搜索反馈结果的功能，jQuery的change事件都很容易实现。

3.前后端分离，三层架构，为的就是高内聚低耦合，采用分层的结构，能够让业务逻辑更清晰，代码更易于重构和维护。因此，前端才会将页面样式尽可能都放在.css文件中，将Scripts放在.js文件中，而HTML文件中只保留dom元素。但vue/angularJS的这种数据绑定方式，在html文件中留占位符{{}}，有点类似于把script代码嵌入到了HTML文件中，让文件显得十分混乱。
想想一个场景：美工交给我一个干干净净的html页面模板，我只需要为每个DOM设置一个唯一ID即可，然后通过JS和CSS文件完成各种渲染。这个页面可能会在我们的php项目中使用，后期又有可能在我们的java项目中使用，由于这是个干净的html文件几乎0耦合，可以方便的在各个系统中移植。如果换做vue呢？这个html文件充满了很多这样的{{占位符}}，想想这是一件多么可怕的事儿。

4、说说咱们常用的post和get；无论是当前的JavaScript原生还是jQqrey都可以方便的进行ajax操作，vue不知道出于什么因素考虑，它的ajax操作居然是分离的，需要另外一个库支持，目前用的最多的好像是axios这个玩意。
我呢多多少少有点代码洁癖，我是很不习惯在页面上加载一大堆.js文件的。一般我的页面加载这么几个东西就足足足够了

publicStyle.css ---- 自己多年来编写的css框架
Style.css ---- 当前项目的差异化css
jQurey.js ---- Jqurey库（根据情况，jQurey现在用的的确不多了，因为当前原生js已经很不错了，尤其是不用兼容IE浏览器Jqurey的确没有太大价值）
public.js ---- 自己多年来写的各种常用方法库




今天我第三次通读了vue文档，不可否认它是一个优秀的框架，但并不代表我认同它，已经准备用它做个项目了，无奈还是放弃了。无任何诋毁和质疑，纯属讨论。

其实我发这个帖子也在反思自己是不是一叶障目，或者老了人变的固执了，诚意欢迎各位兄弟敲打敲打我。

[加油馒头]

99年编程收入很高的哦，20年开发，赚了有3-5百万了吧

[可乐996]

使用vue只是一种选择，不应该成为一种束缚。开发一个项目可以使用各种语言，不需要非得再一种语言上把自己限定死。比如，开发这个项目我就必须要使用vue,那样就是为了vue而使用vue了，vue只是提供了另外一种开发模式的选择，比如我要计算1024*8524，我可以使用计算器，可以自己写个程序计算，还可以手动计算。习惯了手动计算，给你说用计算器算，你肯定不习惯。使用vue也一样，变成一种束缚只会让你越来越不想用vue

[fvcenet]

引用 37 楼 jiangyongbing008 的回复:

照你这么说，MVC也不用用了，全部用servlet或者HttpHander这种直接操作就完事了。用什么MVC呢，还把你的请求解析，然后反射出controller，不又多了好多操作？想想你用mvc的理由

您的帖子我必须得回一下，因为又无意中戳到了另外一个问题上；


对于前后端分离的概念，事实上我在大家普遍接受之前，我已经向这方面发展；说到MVC我感觉我把路给走岔了；

【题外话】
早期我们这一茬站长出身的程序员，很多都不是科班出身的，没有什么强有力的理论基础，发帖这么多兄弟我能感觉到很多都是正规军大厂的员工，我这么多年一直在做CMS；叫框架也好、叫系统也罢、叫后台也行；反正就是这么个东西，为啥我很反对用别人的框架，从业这么多年，很多事情把我坑惨了；

用了别人的框架或程序，相当于把命交给了另外一个人；多年前别的小组给政府做项目，项目经常被黑；不说你也猜得到，是因为用了第三方免费的程序，出现了安全漏洞；结果呢，对方还是个个人，要了个天价... 我们都晕了

后来就自己写cms，你想啊一个cms我们写了快20年，对比早期的风讯、apscms、phpcms等等，和现在的dede、帝国；我都深入的研究和学习过，这些名噪一时的系统有些甚至还有可笑的注入漏洞。

这些年尤其是政府网站，上线之前有非常专业的软件进行检测， 他们系统生成的数百项检测报告的细致程度，我作为软件作者都咋舌；

绕远了，说回MVC这个话题，之前MVC火爆的时候我也在反思，为啥我觉得它这个思想并不先进呢；先说说我的项目结构吧——

【管理端】
[master] ........... 网站后台管理目录（全部都是html）通过ajax去请求[code]

【控制端】
[code]................ 这个文件夹里是全站的逻辑程序（这部分逻辑程序我用asp.net、php、java、python都写了一遍）

【用户端】
[html] ........ 后台动态生成的全站实体html页面 （栏目页、详情页等等）
index.htm .... 后台动态生成的首页文件


上面的目录结构非常清晰了，无论用户希望用什么语种开发他们的网站，我们只需要换掉[code]包就行 其他前后台的html页面模板全部通用。

网站部署呢也非常灵活，即可以按照传统的一体化部署，例如：

前台： www.abc.com
后台：www.abc.com/master

也可以分离部署：
后台：master.abc.com
前台：www.abc.com

但凡是访客能看到的网页全部都是 http://www.abc.com/202001/001.htm 无论是从安全性还是速度等，这都是最好的解决方案，甚至数据库崩了网站都不会停。（新浪、腾讯、搜狐不都是这样嘛。）


很多人说我这也算MVC，但实际上我明白这和大多数人认为的MVC不是一回事。

事实上前一阵子我学习vue我是想把后台部分【master】重构一下；因为【master】不暴露给访客，仅仅是管理员在用，我觉得jqurey或原生js完全够用，也没多大工作量，整个后台系统所用到的各种js特效也就三五百行吧。

前台呢，都是后台动态生成的html文件，用或不用vue意义已然不大了，我也深入的看了腾讯网易新浪等门户站点的页面，好像也都是自家的各种js类包，也没什么vue之类的东西；


我也在反思，是不是由于互联网行业细分了，我们干的活儿和各位师兄弟干的活儿不同，所以对各种框架的需求也不同呢？


再次感谢上面的各位兄弟的回帖，每一个字我都仔细的看了，再次感谢大家的帮助。

[风轻云淡180518]

引用 6 楼 d02540311 的回复：

我是第n次放弃了Vue这种东西，还是jQuery来的痛快，满足各种需求。我的工作经历和楼主差不多，可以多交流一下。

vue好用啊

[_念_]

大佬，虽然你是前辈，但是真的不要这样子，很容易带歪小白的！ vue也好jq也好，都只是工具，和你自己的库没有任何区别。都是服务于人，提高工作效率。 这些工具库，都是前辈们经验的积累，我们之所有有现在的条件和环境，都是前人不断努力的结果。不应该带有有色眼镜去看待。 不管是什么东西都有两面性，vue有它的优势，也有不足。它只是一个阶段的产物，就想像q一样，jq盛行十多年，其中有无数的精华，都是无数大佬的心血。同理vue也是，虽然vue是尤大大写的，但是他并不是凭空捏造的，都是建立在无数前辈的基础之上的，是对前人精华的总结和延伸。 你可以不用它，不喜欢它，但是请善待它，因为这是别人心血的产物，并且是具有很高价值的产物。 css框架也有很多，我们平时所用的组件，还有平时所用的小技巧。都和vue、ng、react类似，只不过这三大框架更加的完整，功能更多，仅此而已。

[哎算了]

我也搞网站十五六年了，说实话至今还在用ASP,我就是因循守旧怕学新东西，吃老本吃了十几年，因为自己一手码起来的程序得心应手，只要是普通网站，基本上最多半天就搞一个，全是复制粘贴，改改界面。 后台把想到的功能基本上都做了一遍，以后用到都是在此基础上改改。 对方很多小项目足够用了。但是今年我决定用用现在流行的框架，比如BOOTstrap，这些功能封装的很好，什么分页，修改，删除等等，通过AJAX跟后台数据交互都通过JSON。 相对以前表单交互，确实提升一个档次，因为代码量减少，页面干净，效果还很不错，而且可以自适应，我是停惊讶这种改变的，当然用以前办法也可以模仿78分像，但是没有现场的方便。 目前最大改变就是PC端项目在急剧减少，没看百度股价一直跌嘛，未来趋势各种运用都要出移动端，但是开发原生APP又太吃力了，还分安卓和苹果，对于广大互联网从业人员有点难，如果有一个框架和技术可以打通，H5技术就是最好的替代。 针对手机端开发，不用框架的话，你去针对手机各种兼容和使用开发一套成本太高了，而且互联网都是年轻人天下，现在年轻人学习网站制作技术，很多直接跳过HTML,CSS,JAVASCRIPT等，学也是一带而过。直接上来撸框架，所以框架必须简单，必须有各种信手拈来的组件库。 回来新老交替这个历史规律，我们这一批越来越边缘化，很多我们同龄人已经不写代码了，以后跟他们这一批一起混IT,起码圈子人数压过你。 很多技术不是过时，只是懂底层愿意去写原生的人越来越少了。

[nayi_224]

去jquery推vue本来就是一些大厂搞出来的，他们已经把自己这样做的原因说的很清楚了，都很在理。但是这并不适合所有人，再加上一堆小白成天在哪胡吹就让人很烦。 相信不少程序员并不是出于技术选择的vue，而只是迫于形势。

[虎子8]

我来回答一下吧
问题1：
如果你这么讲，请你找出一个能够真正提高性能的框架。 所有框架说的高性能都是相对的， 肯定是没有原生的高啊。
问题2：
你用反了啊，没人说Modle变化就化发请求啊， 一般是发了请求才改变modal
问题3：
你说的是前端渲染，组件式开发，不仅仅是占位符的问题。 不能直接用美工的html。 但是组件化开发其实效率更好，复用性更好
问题4：
真的没人逼着你用axios，原生ajax你也可以啊
var xmlhttp = new XMLHttpRequest();

真的放下你的偏见，好好去理解一下。

[scscms太阳光]

萝卜白菜各有所爱，本无可厚非。但非要觉得自己的私藏库比vue,react等还要溜就算了吧。
工作中你不跟其他人合作可以乱搞，但你去大公司多人合作你非要说：同志们丢了vue，丢了react。请用我珍藏多年的xx裤！　想想会是什么样的场景？

[朽木自雕xmzd]

作为一个学习vue不久的小白来说，vue确实比较简单容易上手，并且使用了 组件 这种模式，给我的使用感觉就是对于一些重复性很高的需求，完全可以写成一个组件，然后像搭积木一样就可以完成一个项目。对性能问题，打开网页没啥感觉，seo不行可以服务端渲染。并且vue写出来的项目 可维护性、可读性都比较高。而对于jquery来说，一旦项目过于庞大，你可能都找不到你想要的东西在哪，维护成本高、可读性差。

[仰望星空的代码]

序号对应楼主问题序号。 1、采用jQuery的页面所有的事件处理都是操作dom而且没有任何的中间层做处来尽可能的减少对dom重绘的影响。 Vue.js框架是以数据进行驱动。Vue.js在绘制渲染dom之前做了一个虚拟dom来映射真实dom，每当数据有更新时采用虚拟dom的diff算法计算出需要更新的dom节点。在这个过程中Vue.js做了大量的处理来保证尽量缩小需要重绘dom的范围。这本身就比jQuery处理的精细很多。 其实，只有复杂页面或者有大量内容的页面才会体现出两者的性能差异。真正谁快，可以做一个测试，比如，渲染1000个li看看jQuery快还是Vue.js快。 2.Vue.js中的响应式数据绑定只是前端的处理与服务器可以说没有关系，或者说关系不大。页面中的所有交互产生的数据改变只有真正需要请求服务器时才会进行请求，即使jQuery的chang事件处理也并不是都请求服务器的吧，比如，select选项改变，view的数据改变了，对应的保存select选项值的model也就改变了，此时并不一定需要请求服务器。只有真正需要获取数据，或者保存数据时去请求服务器，其他时刻全部在前端本地页面完成处理。 3.前后端分离的意义在于明确前后端的职责，前端开发只负责前端业务交互，后端接口只负责数据处理与存取数据库，二者配合但是不耦合。 传统的开发模式组织代码的方式是按照角色进行的，比如：asp.net mvc的controller文件放到controller文件夹，view的HTML文件，css文件，js文件都各自放到自己的文件夹，然后在HTML中调用css、js文件。如果要对一个页面进行进行修改需要涉及到css、js、HTML的修改那么必须在多个地方进行文件查找与切换，开发中比较费时费力。另外，如你所说想要移植，那么移植的时候只拿走HTML而不要css、js吗？如果是三者全部拿走那么Vue.js的实现应该也没有问题啊。 就在今天不久之前我也是按照传统方式来组织代码的，可是前段时间看到一个组织代码的概念：按照功能组织代码。然后，我发现一切就不一样了。 按照功能组织代码就是一个功能模块的代码全部放在一起，一个文件夹中，整个功能开发过程都在这一个文件夹中完成。把这个功能作为一个独立的模块，与其他功能完全分离，完全解耦，完全实现自己的高内聚。 高内聚，低耦合是软件开发一直追求的理想模式。把各个功能模块各自分离，聚合自身，以一个js文件作为入口和出口。其他模块如果依赖这个模块，只需要导入该模块入口js即可，不用再单独引入css、HTML文件。 采用前后端分离模式后后端开发人员完全不关心前端，前端完全不关心接口如何实现。当然，如果采用了前后端分离，但是却是由同一个人开发前端和后端的话理解起来其实并不比传统的开发模式好多少。 4、Vue.js没有把ajax跟jQuery一样集成到一起，而是让开发者自己选择实现ajax的方式，只不过Vue.js官方推荐的是axios而已，开发者完全可以自己使用或者实现其他ajax库或者工具。比如，你可以使用自己写的public.js，这是完全没有问题的。不仅对于ajax如此，对于css也是如此，你完全可以采用自己辛苦凝结而成的publicStyle.css框架作为整个项目的css框架，在不同的组件中编写该组件自己差异化的css。 项目中引入了Vue.js只是给了一种前端开发框架的选择！当然，这个选择是不错的一个选择！ 补充：现在前端开发还有一个概念：服务端渲染。说白了就是传统的asp.net、jsp的变相实现。只不过这些东西全部交给了前端开发人员开发实现，接口开发人员不再管了。

[jiangyongbing008]

引用 52 楼 scscms太阳光 的回复:

萝卜白菜各有所爱，本无可厚非。但非要觉得自己的私藏库比vue,react等还要溜就算了吧。 工作中你不跟其他人合作可以乱搞，但你去大公司多人合作你非要说：同志们丢了vue，丢了react。请用我珍藏多年的xx裤！　想想会是什么样的场景？

xx裤给我整笑了

[jiangyongbing008]

引用 52 楼 scscms太阳光 的回复:

萝卜白菜各有所爱，本无可厚非。但非要觉得自己的私藏库比vue,react等还要溜就算了吧。 工作中你不跟其他人合作可以乱搞，但你去大公司多人合作你非要说：同志们丢了vue，丢了react。请用我珍藏多年的xx裤！　想想会是什么样的场景？

或者博主如果觉得自己的私藏裤很好用，完全可以开源出来，让大家试一试，到底是哪个好？

[霓石榴]

快来水快来水

[霓石榴]

快来水快来水

[霓石榴]

快来水快来水快来水

[sha虫剂]

新的框架只是为了更快速的开发效率，底层终究都是原生的东西，不过vue确实是不够灵活，相比较起来react的更加灵活一点，我觉得楼主可以了解一下react

[chinaskysun]

没用vue之前，自己写个ajax翻页，复用的功能代码都要20多行，再加上动态改变的，就更多了， 用了vue，只需要改两个地方，一个是数据内容，一个是翻页url，工作效率大幅提高。 我只想说，楼主nb大了，20年800个项目，平均每年40个项目，9天一个项目，在如此高速的项目开发使用的缺是效率低下的库或者干脆就不用库，佩服啊~~~

[边境加飞jfmiao]

没毛病 重要的是把功能实现了 

[a58309113]

美工交给我一个干干净净的html页面模板，我只需要为每个DOM设置一个唯一ID即可，然后通过JS和CSS文件完成各种渲染。这个页面可能会在我们的php项目中使用，后期又有可能在我们的java项目中使用，由于这是个干净的html文件几乎0耦合，可以方便的在各个系统中移植。如果换做vue呢？这个html文件充满了很多这样的{{占位符}}，想想这是一件多么可怕的事儿。

不论是php 还是java 还是.net 还是其他后端，只要是后端渲染都离不开占位符， 怎么占位符就成了vue的专属？

VUE采用双花括号进行数据绑定，原生JS里面应该没有对应的操作，需要采用RegExp进行匹配，再进行数据替换。
如果从性能而言，我认为vue性能损失更大
说明你对vue不了解，至少对前端工程化不了解，通过vue-loader 打包后 根本没有RegExp匹配，最最最主要jq已经完成了历史使命，现在这个时代真的不再需要jq了。。。