先自我介紹一下，兄弟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檔案，不可否認它是一個優秀的框架，但并不代表我認同它，已經準備用它做個專案了，無奈還是放棄了。無任何詆毀和質疑，純屬討論。
其實我發這個帖子也在反思自己是不是一葉障目，或者老了人變的固執了，誠意歡迎各位兄弟敲打敲打我。
uj5u.com熱心網友回復：
VUE中的雙花括號應該是決議為一個文本節點TextNode。更新文本節點的內容性能是最優的。uj5u.com熱心網友回復：
不管什么能用就行uj5u.com熱心網友回復：
深有同感+++uj5u.com熱心網友回復：
殺雞用剪刀，殺牛用砍刀。各有各的適用場景吧。uj5u.com熱心網友回復：
現在的這種js框架，我從來不用，我從業也20多年了，在很多年前，我自己的模板體系就已經實際應用了uj5u.com熱心網友回復：
我是第n次放棄了Vue這種東西，還是jQuery來的痛快，滿足各種需求。我的作業經歷和樓主差不多，可以多交流一下。uj5u.com熱心網友回復：
,看你們站在哪個層面看問題吧，如果只是JS表面層，你可以這樣說，但到了大佬層，你們的想法很可愛
uj5u.com熱心網友回復：
你拋棄了，我撿起來。你虐vue千萬遍，我待vue如初戀。
uj5u.com熱心網友回復：
單從開發效率來說，vue還是要比JQuery要快些的uj5u.com熱心網友回復：
事實上是現在越來越多追求的是與時俱進，公司發展都需要人員配合，一個框架火與不火用與不用都取決于公司內部，如果公司內部其它人都用vue框架，為了專案整體后期測驗運維來說 不可能讓一個人用原生其它人用框架uj5u.com熱心網友回復：
Vue的強大在于，它簡單的讓很多人可以彎道超車。我仔細想了一下，Vue的優勢在什么地方。
所有的框架其實終極目的都只有一個，就是專注業務層。你不需要去注意底層的性能和實作方式，而是將注意力完全放在業務的實作上。
因為底層實作和性能，大佬們已經幫你搞定了。
Vue的確很簡單，核心思想也就是圍繞MVVM來做的一套JS框架。我很多時候也在想，我自己利用原型，利用JQ，一樣可以操作Dom，一樣可以MV匹配。但是我做不到它的效果，或者說性能。
比如要渲染一個Dom結構，用JQ也很簡單，甚至用原生JS就可以做到。但是Vue有頁面快取：如何避免重復渲染和重復加載，如果我用JQ去寫，估計要炸了。而且類似Vue框架，近代前端框架的組件系統的確可以讓代碼的結構變得簡單，可讀性和復用性提高。
另外Vue和webpack的契合性很好。不用Vue沒關系，總不能不用webpack。
uj5u.com熱心網友回復：
加油加油加油uj5u.com熱心網友回復：
我也不習慣vue，但也沒有排擠，畢竟是主流了。其實用vue給我感覺跟后臺的模版插值差不多，代碼層面其實比jq要更清晰的，但比不上jq靈活，例如做一些模塊聯動，jq真的很方便!uj5u.com熱心網友回復：
沒錯兒，這個東西并不是必須的。uj5u.com熱心網友回復：
前端菜鳥，從ES3走來。現在用TS+React多一些，VUE沒有研究。
個人覺得React家族最舒服的優點就是Redux。
我之前寫JS用到一些公用方法了怎么辦呢？寫個全域物件，需要的功能都綁上面，修改，訪問都的暴露的。
下班吃飯了，不寫了，歡迎補充，哈哈哈。
uj5u.com熱心網友回復：
剛接觸 也放棄了
uj5u.com熱心網友回復：
markmarkmarkuj5u.com熱心網友回復：
Model里的資料變化后，會立即和后端互動，那樣服務器的壓力有多大？誰告訴你的？
uj5u.com熱心網友回復：
業務邏輯復雜到一定程度，用jquery寫就是在吃屎。。。只能依靠vue react angularuj5u.com熱心網友回復：
不容易，繼續加油uj5u.com熱心網友回復：
vue的性能不是說操作dom快。而是通過計算可以盡可能避免不需要更新的domuj5u.com熱心網友回復：
加油，機會還很多，慢慢來uj5u.com熱心網友回復：
敲了20年代碼是什么感覺？uj5u.com熱心網友回復：
加油。。。。。。。。。uj5u.com熱心網友回復：
入職以來，看到很多資深老哥，問的那些問題真的感覺不可思議。看來，大而全真不如小而精，那些沒有驗證的“我覺得”，明顯謬誤我就不去糾正了。把控好質量，積累出可靠的組件庫，新開專案，就是一通粘貼就完事兒了。就光前端、后端誰也不必等誰這一點，難道不比傳統方式強？另外，你沒感受到的原因，我在想，是不是因為你們并沒有自己一系列的風格明顯的產品，全是外包？如果全是外包，那確實不建議用前后端分離，因為最重要的一點就沒了——積累的組件庫。
我們目前參與的專案，原專案多年的積累，120w代碼，重構用React，預計能減少三分之二代碼量，預計專案周期1年，現在的進度估計撐死半年就完事兒了，為什么快這么多？因為上一個enduser端的專案積累了大量可重用的組件。這次重構，直接少了三分之二代碼，可維護性提高多少？效率提高多少？越是大型專案，它的作用越是驚人。
技術永遠是向前發展的，曾有一次面試，面試官一副抱著jQuery自認為至寶的樣子，他們的專案規模也就不言而喻了，懂得自然懂。
uj5u.com熱心網友回復：
用vue開發效率快，復雜操作方便，學了vue再去使用uniapp同一套代碼開發編譯成app，小程式，h5都很方便uj5u.com熱心網友回復：
實作功能為主。框架也是工具，強行靠不合適uj5u.com熱心網友回復：
vue就是把后端的模板引擎搬到前端了，而且還有seo問題uj5u.com熱心網友回復：
說了這么多，有我直接套模板快嗎？
uj5u.com熱心網友回復：
都是混口飯吃，這個不會基本就找不到作業了！
uj5u.com熱心網友回復：
1，前后端分離的概念你沒摸清楚，不是檔案分離，是概念和模式分離，這是系統性的分離。首先，從業人員的資料，埠呼叫耦合度降低。其次，web開發中的一個很基礎，很重要的概念，api！介面能被模塊式編程的方式中獨立出來。2，這些框架是對Js或者說所有其他編程語言所提倡的模塊化和各種設計模式的實作。可復用的組件，互動資料和運行時資料的分離，實時狀態管理，等等這些都是編程思想的進步，模塊化和組件化是趨勢。就像目前的微服務一樣，做好一個，到處使用。
你對新技術的感覺不是覺得它笨，更多應該是害怕，最終有一天編程可能會像拼字游戲一樣簡單。
uj5u.com熱心網友回復：
這個主要取決于 專案的框架了， 如果這個專案是用VUE， 那你寫的東西就必須支持VUE了。 特別是多個部門或多個外包團隊聯合開發，只能選開發快， 團隊人員都熟悉的框架了。uj5u.com熱心網友回復：
Model里的資料變化后，會立即和后端互動，那樣服務器的壓力有多大？就你這句話，我有自己得看法，v-model 和全域變數雙向系結，你輸入框 不斷輸入 不斷改變v-model 系結的變數的值，但這也只是前端的那個變數得值，和后端互動沒關系把？ 你前端變數的值怎么變。我不發請求過去怎么會給后端帶來壓力
就比如我 前端就能完全不用后端，就靠你v-model 系結的那個變數，來作為過濾器的過濾條件，實作對前端資料的過濾，沒有任何請求，我輸入框的值也一直在變,沒有任何請求，拿來的對服務器的壓力?
<el-input v-model="filterText" :placeholder="$t('refersetting.HereInputKeyWord')" clearable maxlength="2000" />
<el-tree ref="refTree" :https://bbs.csdn.net/topics/data="data" :props="defaultProps" highlight-current :filter-node-method="filterNode" @node-click="getChildTree" :expand-on-click-node="false" default-expand-all>
data(){
return{
filterText: '',
}
}
watch: {
filterText(val) {
this.$refs.refTree.filter(val.trim())
}
}
methods:{
filterNode(value, data) {
if (!value) return true
return data.label.indexOf(value) !== -1
},
}
這是我 vue+ element 對樹形控制元件的過濾，我輸入框的可以改變個無數次，它都對我的后端沒有任何壓力
uj5u.com熱心網友回復：
無論把vue說出花來，你也不能否認它最侄訓是要操作DOM的；這時候問題來了——有人說vue操作DOM性能損失小。jQuery采用JS原生的getElementByID/Name/Class/TagName等函式操作DOM，性能損失應該不算大。
你可以去看看 vue 操作Dom 是不是 提到了虛擬dom？你確定Vue 通過操作虛擬dom 最后同步dom，和你用js直接操作Dom，性能損失不算大?
難道不是，差距很大么？，
比如你要對10 個按鈕 進行dom 元素操作，你用js 去操作 那就是要操作10次把？
Vue 是你對虛擬dom 操作10次，最后把你之前的10虛擬dom的操作一起同步到dom，這個行為是只操作了1次dom
1比10 不是么？難道我學的vue 和你學的不是一個？
vue 操作虛擬dom 比你直接操作dom 要性能好很多把？
還有vue 中 v-model 你就是變出個花來，也不會對后端有影響把？給后端服務器帶來壓力哪個檔案講的？會立即和后端互動？你這些話不像是看過檔案講出來的把=--=
uj5u.com熱心網友回復：
說這么多，其實你就是不愿意接受新的事物。vue做的這些事，都是為了前端組織架構清晰明朗，模塊功能單一。竟然覺得引入一個anxios都影響你的什么精神潔癖，那么你寫代碼從不引入嗎？使用jquery操作dom達到了一萬行，你讓別人來看你代碼，人家絕壁想罵人。寫了二十年這點道理都不懂uj5u.com熱心網友回復：
照你這么說，MVC也不用用了，全部用servlet或者HttpHander這種直接操作就完事了。用什么MVC呢，還把你的請求決議，然后反射出controller，不又多了好多操作？想想你用mvc的理由uj5u.com熱心網友回復：
，大佬說的是，頂一個
uj5u.com熱心網友回復：
大哥，你Out了。要不斷學習新內容，以時俱進！放棄jquery，PHP與Jsp吧。國人多用Vue，但是我推薦你使用React，特別是Hook，一旦你掌握后，你會愛上它的！uj5u.com熱心網友回復：
從來不用第三方框架的路過，包括jquery都不用uj5u.com熱心網友回復：
99年編程收入很高的哦，20年開發，賺了有3-5百萬了吧uj5u.com熱心網友回復：
使用vue只是一種選擇，不應該成為一種束縛。開發一個專案可以使用各種語言，不需要非得再一種語言上把自己限定死。比如，開發這個專案我就必須要使用vue,那樣就是為了vue而使用vue了，vue只是提供了另外一種開發模式的選擇，比如我要計算1024*8524，我可以使用計算器，可以自己寫個程式計算，還可以手動計算。習慣了手動計算，給你說用計算器算，你肯定不習慣。使用vue也一樣，變成一種束縛只會讓你越來越不想用vueuj5u.com熱心網友回復：
您的帖子我必須得回一下，因為又無意中戳到了另外一個問題上；
對于前后端分離的概念，事實上我在大家普遍接受之前，我已經向這方面發展；說到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之類的東西；
我也在反思，是不是由于互聯網行業細分了，我們干的活兒和各位師兄弟干的活兒不同，所以對各種框架的需求也不同呢？
再次感謝上面的各位兄弟的回帖，每一個字我都仔細的看了，再次感謝大家的幫助。
uj5u.com熱心網友回復：
vue好用啊uj5u.com熱心網友回復：
大佬，雖然你是前輩，但是真的不要這樣子，很容易帶歪小白的！vue也好jq也好，都只是工具，和你自己的庫沒有任何區別。都是服務于人，提高作業效率。
這些工具庫，都是前輩們經驗的積累，我們之所有有現在的條件和環境，都是前人不斷努力的結果。不應該帶有有色眼鏡去看待。
不管是什么東西都有兩面性，vue有它的優勢，也有不足。它只是一個階段的產物，就想像q一樣，jq盛行十多年，其中有無數的精華，都是無數大佬的心血。同理vue也是，雖然vue是尤大大寫的，但是他并不是憑空捏造的，都是建立在無數前輩的基礎之上的，是對前人精華的總結和延伸。
你可以不用它，不喜歡它，但是請善待它，因為這是別人心血的產物，并且是具有很高價值的產物。
css框架也有很多，我們平時所用的組件，還有平時所用的小技巧。都和vue、ng、react類似，只不過這三大框架更加的完整，功能更多，僅此而已。
uj5u.com熱心網友回復：
我也搞網站十五六年了，說實話至今還在用ASP,我就是因循守舊怕學新東西，吃老本吃了十幾年，因為自己一手碼起來的程式得心應手，只要是普通網站，基本上最多半天就搞一個，全是復制粘貼，改改界面。后臺把想到的功能基本上都做了一遍，以后用到都是在此基礎上改改。
對方很多小專案足夠用了。但是今年我決定用用現在流行的框架，比如BOOTstrap，這些功能封裝的很好，什么分頁，修改，洗掉等等，通過AJAX跟后臺資料互動都通過JSON。
相對以前表單互動，確實提升一個檔次，因為代碼量減少，頁面干凈，效果還很不錯，而且可以自適應，我是停驚訝這種改變的，當然用以前辦法也可以模仿78分像，但是沒有現場的方便。
目前最大改變就是PC端專案在急劇減少，沒看百度股價一直跌嘛，未來趨勢各種運用都要出移動端，但是開發原生APP又太吃力了，還分安卓和蘋果，對于廣大互聯網從業人員有點難，如果有一個框架和技術可以打通，H5技術就是最好的替代。
針對手機端開發，不用框架的話，你去針對手機各種兼容和使用開發一套成本太高了，而且互聯網都是年輕人天下，現在年輕人學習網站制作技術，很多直接跳過HTML,CSS,JAVASCRIPT等，學也是一帶而過。直接上來擼框架，所以框架必須簡單，必須有各種信手拈來的組件庫。
回來新老交替這個歷史規律，我們這一批越來越邊緣化，很多我們同齡人已經不寫代碼了，以后跟他們這一批一起混IT,起碼圈子人數壓過你。
很多技術不是過時，只是懂底層愿意去寫原生的人越來越少了。
uj5u.com熱心網友回復：
去jquery推vue本來就是一些大廠搞出來的，他們已經把自己這樣做的原因說的很清楚了，都很在理。但是這并不適合所有人，再加上一堆小白成天在哪胡吹就讓人很煩。相信不少程式員并不是出于技術選擇的vue，而只是迫于形勢。
uj5u.com熱心網友回復：
我來回答一下吧問題1：
如果你這么講，請你找出一個能夠真正提高性能的框架。 所有框架說的高性能都是相對的， 肯定是沒有原生的高啊。
問題2：
你用反了啊，沒人說Modle變化就化發請求啊， 一般是發了請求才改變modal
問題3：
你說的是前端渲染，組件式開發，不僅僅是占位符的問題。 不能直接用美工的html。 但是組件化開發其實效率更好，復用性更好
問題4：
真的沒人逼著你用axios，原生ajax你也可以啊
var xmlhttp = new XMLHttpRequest();
真的放下你的偏見，好好去理解一下。
uj5u.com熱心網友回復：
作為一個學習vue不久的小白來說，vue確實比較簡單容易上手，并且使用了 組件 這種模式，給我的使用感覺就是對于一些重復性很高的需求，完全可以寫成一個組件，然后像搭積木一樣就可以完成一個專案。對性能問題，打開網頁沒啥感覺，seo不行可以服務端渲染。并且vue寫出來的專案 可維護性、可讀性都比較高。而對于jquery來說，一旦專案過于龐大，你可能都找不到你想要的東西在哪，維護成本高、可讀性差。uj5u.com熱心網友回復：
蘿卜白菜各有所愛，本無可厚非。但非要覺得自己的私藏庫比vue,react等還要溜就算了吧。作業中你不跟其他人合作可以亂搞，但你去大公司多人合作你非要說：同志們丟了vue，丟了react。請用我珍藏多年的xx褲！ 想想會是什么樣的場景？
uj5u.com熱心網友回復：
xx褲給我整笑了
uj5u.com熱心網友回復：
或者博主如果覺得自己的私藏褲很好用，完全可以開源出來，讓大家試一試，到底是哪個好？
uj5u.com熱心網友回復：
序號對應樓主問題序號。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的變相實作。只不過這些東西全部交給了前端開發人員開發實作，介面開發人員不再管了。
uj5u.com熱心網友回復：
快來水快來水uj5u.com熱心網友回復：
快來水快來水uj5u.com熱心網友回復：
快來水快來水快來水uj5u.com熱心網友回復：
新的框架只是為了更快速的開發效率，底層終究都是原生的東西，不過vue確實是不夠靈活，相比較起來react的更加靈活一點，我覺得樓主可以了解一下reactuj5u.com熱心網友回復：
沒用vue之前，自己寫個ajax翻頁，復用的功能代碼都要20多行，再加上動態改變的，就更多了，用了vue，只需要改兩個地方，一個是資料內容，一個是翻頁url，作業效率大幅提高。
我只想說，樓主nb大了，20年800個專案，平均每年40個專案，9天一個專案，在如此高速的專案開發使用的缺是效率低下的庫或者干脆就不用庫，佩服啊~~~
轉載請註明出處，本文鏈接：https://www.uj5u.com/qianduan/32090.html
標籤：非技術區