用 React-Vue 不如用 jQuery

事情的起因是這樣的，有一個粉絲朋友跟我述說了她的焦慮：都 2024 年了，她的團隊還在用 jQuery 開發項目，她覺得自己距離 React、距離 Vue 好遙遠。覺得自己是被時代拋棄的棄子，她目前的狀態就是每天都活在極度的焦慮當中，每次聽到有人說行情不好，或者哪哪家公司又在裁員，都感覺心驚肉跳。

爲了從根上解決她的焦慮，於是就有了這個標題。我知道看到這個標題，很多人第一反應是不理解，jQuery 不就是遠古時代的產物嗎，不都已經被淘汰了嗎？它能比 React/Vue 更好？這不會是一篇標題黨的文章吧？

但，我要非常明確的是，這不是標題黨，而是在說一個客觀事實。接下來，我來給大家分析一下，爲什麼 jQuery 比 React/Vue 更好。

技術選型的核心目的

作爲一個前端開發，在搞技術選型的時候，一定一定要記住，我們有兩個核心目標，一個是能夠更高效更舒適的開發項目，而另外一個，就是要在開發項目的過程中，凝聚出屬於你自己的核心競爭力。第一個目標更多的是偏向於團隊，第二個目標更多的是要偏向於個人，你想要有一個持續的，健康的職業生涯，這兩者缺一不可。只是說，第二個目標只能憋在心裏，不能廣而告之。

然而事實上，許多人，不管是主動選擇，還是被動選擇，往往只關注了第一個目標，而忽略了第二個目標。有的人是憋着不說，有的人是壓根想不到。這就導致了，這些想不到的很多人，用 Vue/React 用久了，會感覺自己變成了一個廢物，演變成一年經驗用七年。

這種情況在 Vue 使用者的身上會體現得更加明顯。

當然，我不是在說所有人，而是大多數人

所以有的人雖然沒有剛纔那個同學那種焦慮情緒，也很熟練的在使用 React/Vue，但就是想要獲得一個 offer 還是非常困難。因爲他們雖然已經熟練使用 React/Vue 開發頁面，但這就是一個普通的頁面仔啊，工作了 five 年，沒有凝聚出核心競爭力，成了一個廢物。

因此在做技術選型的考慮上，在我的選擇序列裏，React 永遠都要比 Vue 更值得選擇，只因爲 React 離原生 JavaScript 更近，沒有創造更多的語法，沒有那麼多黑箱操作，自由度更高。這讓我有更多的機會在開發項目的過程中，做到提高開發效率的同時，還能兼顧自己核心競爭力的提升。

而在這兩個點的權衡上，jQuery 實際上可以做得更好。

我們陷入了 React/Vue 的騙局

React/Vue 最核心的東西，就是組件化。能借助 webpack/vite，在 JS 模塊中，把其他靜態資源當成模塊引入，從而在大型項目中，提高文件結構的可讀性和易用性。並利用數據驅動 UI 的方式，在一定程度上簡化了開發負擔。

但是，我們在學習 React/Vue 時，都被他們騙了。React/Vue 說，我們要構建一個大型項目，需要一個全局狀態管理器，我們應該把所有的狀態都放到頂層的 store 裏。於是 redux 成爲了入門 React 必學的技術棧。然而事實上，全局狀態管理，我覺得是一種弱智的，簡單粗暴的解決方案，他能夠讓你在思考組件拆分的時候，完全不考慮數據的歸屬問題，反正隨便放在哪裏都能輕鬆訪問。

以致於，大部分的前端開發，都是被這種騙局培養成了高效低能的開發者，不管你是用 React，還是用 Vue，有可能都沒有逃過這個騙局。當你還在和別人爭論 React、Vue 誰會淘汰誰的問題時，你可能還沒有發現，這兩個傢伙構建了一個非常堅固的信息繭房，把所有的前端都圈在裏面，然後合夥把你淘汰掉。

所以我認真的思考了一下，真的有很多數據需要全局共享嗎？

所以在很多年前，當我經驗逐漸豐富起來的時候，我在其他客戶端開發解決方案中，見識了更多的開發模式，然後我發現了這個騙局。我們大多數項目，並不需要全局狀態管理。甚至也不需要邏輯那麼笨重的數據驅動。

數據驅動的本質

當全局狀態管理沒那麼有必要的時候，也就意味着，我們的項目數據結構不會那麼複雜，所以數據驅動 UI 這個事情，帶來的好處，就顯得非常有限了。

在 React 中，你這樣寫

function Hello() {
  const [year, setYear] = useState(2024)

  function clickHandler() {
    setYear(year + 1)
  }
  
  return (
    <div>
      <div>hello {year}</div>
      <button onClick={clickHandler}>++</button>
    </div>
    
  )
}

當我們利用 jQuery 如何寫呢，看一下代碼

<script id="temp" type="text/x-jsrender">

<div>hello {{:year}}</div>
<button id="increament" onclick="hello()">++</button>

</script>

var data = {
  year: 2014
};

function hello() {
  data.year += 1
  template.link("#result", data);
}

var template = $.templates("#temp");
template.link("#result", data);

注意看，我們其實也可以利用了 jQuery 生態中的模板語言來代替 DOM 操作，達到類似的目的。我們可以相對清晰的知道當我要改變一個數據時，有兩個事情要完成，一個是改變數據，一個是重新修改 UI.

我們也可以縮小修改的範圍，從而達到最極限的性能，自由度非常高。

function hello() {
  data.year += 1
  $('#label').text(`hello ${data.year}`)
}

在複雜度和性能之間，我們可以自由的做出取捨。我們完全沒有必要在所有場景，都去花費那麼大的代價去考慮如何將數據與 UI 綁定在一起。不管是 Vue 的依賴收集，還是 React 的 diff，在這上面都花費了大量的心思，增加了巨大的心智負擔，關鍵邏輯還變成了黑箱操作。

React 的返祖現象

事實上，熟悉 React 新官網的朋友應該知道，React 已經開始出現返祖現象了。也就是官方文檔把 useEffect 定性爲一種逃脫方案。當我們發生點擊事件時，如果需要修改其他的邏輯，新官方文檔建議我們不要去修改狀態，而是直接把邏輯寫在回調函數里

// 官方文檔不推薦
useEffect(() => {
  loading && api().then(() => {})
}, [loading])

function clickHandler() {
  setLoading(true)
}

// 官方文檔推薦
function clickHandler() {
  setLoading(true)
  api().then(() => {})
}

我爲什麼要稱這種方式爲返祖現象呢，因爲你熟悉 jQuery 的使用的話，你就會發現這本身是再正常不過的邏輯了，但是新的官方文檔確要花費大量的篇幅去解釋爲什麼應該這樣做。這在我看來是非常詭異的事情。

然後呢，我又要花大量的心思去解釋我爲什麼不認同官方文檔的這種觀點。

當我們在 jQuery 中能自定義組件時

我們要達成的一個共識就是，單向數據流是一個被包裝出來的高大上概念。說白了就是函數的嵌套執行。

注意看這段代碼

function Parent(data) {
  const {pname, ...otherName} = data
  return (
    `<div>${pname}</div>${Children(otherName)}`
  )
}

function Children(name) {
  const {cname, ...otherName} = name
  return (
    `<div>${cname}</div>${Grandson(otherName)}`
  )
}

function Grandson(name) {
  return (
    `<div>${name.gname}</div>`
  )
}

是不是感覺很熟悉，很像 React。當我執行 Parent() 的時候，所有的子元素和孫子元素都會重新執行，從而數據就有了流向。當我要修改數據的時候只需要

function click() {
  data.gname = 'TOM'
  parent(data)
}

這就是數據驅動 UI。這就是單向數據流。

但是實際上，這不是 React 組件，他只是普通的函數，返回了一個字符串而已。因此，要非常注意的是，他也滿足了單向數據流的規則。但是他的寫法也只是函數里執行函數。

如果你要改變 data 時，只需要重新執行一下 Parent(data) 。這樣，我們的每一個子組件，都會重新執行。所以我想說的是，構建一個自定義組件確實太簡單了，我們當然也可以在 jQuery 的生態裏，基於模板自定義組件。

function renderBoldP(value) {
   return "<p><b>" + value + "</b></p>";
}

$.views.tags("boldp", renderBoldP);

React 的語法跟我剛纔的寫法非常相似。但是，React 最大的問題就是，嵌套層級太多了，以致於我們在執行頂層組件 Parent() 時，成本偏高。在 jQuery 中，就可以完全不用擔心這個問題，我們可以自由選擇層級，而不必把嵌套層級擴大到整個項目。有可能你只是想要修改一個小小的地方而已。

靈活，就是 jQuery 最大的優勢。

事實上，當你要研發大型高性能的前端項目時，React 和 jQuery 最終都會殊途同歸。我們也會想辦法在 React 中放棄自頂向下的 diff，然後把改動縮小在可控的範圍裏。但是在 React 中要做到這個事情需要非常深厚的功底，而在 jQuery 中卻非常容易。因爲我們並不需要去遷就龐雜的 diff 流程，只是簡單的執行一個目標函數而已。

當你需要雙向綁定時

當你想要在特定的場景裏需要雙向綁定時，jQuery 的生態裏也有非常多的方案來支撐這個場景。

$("#changeObjects").on("click", function() {
  $.observable(person).setProperty({
    name: "newName",
    address: {street: "New Street"},
    phones: [{number: "123 123 1234"}, {number: "321 321 4321"}]
  });
});

所以，當 jQuery 可以自定義組件，可以支持單向數據流，可以支持雙向綁定，這不就齊活了嗎？

趨勢是什麼

不要問未來的趨勢是什麼，問就是 jQuery。什麼所謂的 Vue3，Solid，svelte，都不是最終形態，他們通通都在走向返祖的道路，未來的趨勢就是 jQuery。所以如果你的團隊裏，還在使用 jQuery，正說明你們團隊在領先世界，這是我內心最真實的想法。所以你不需要過於焦慮，你要做的事情只是把 jQuery 用好，用透，去利用 jQuery 的生態構建一套開發效率很高的架構出來，然後回過頭來，你會發現，React/Vue 你只需要一天就能學會。

沒有一個團隊，會拒絕得了精通 jQuery 的人。因爲你 jQuery 用得好，很大程度上能代表你原生能力相對會強一些，基礎非常紮實。

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/aX_wldKGpWXY5z8RlD83Tw

猜你喜歡