我的原创第 140 篇
2024 年的第一篇文章，就从技术选型说起吧。
事情的起因是这样的，有一个粉丝朋友跟我述说了她的焦虑：都 2024 年了，她的团队还在用 jQuery 开发项目，她觉得自己距离 React、距离 Vue 好遥远。觉得自己是被时代抛弃的弃子，她目前的状态就是每天都活在极度的焦虑当中，每次听到有人说行情不好，或者哪哪家公司又在裁员，都感觉心惊肉跳。
为了从根上解决她的焦虑，于是就有了这个标题。我知道看到这个标题，很多人第一反应是不理解，jQuery 不就是远古时代的产物吗，不都已经被淘汰了吗？它能比 React/Vue 更好？这不会是一篇标题党的文章吧？
但，我要非常明确的是，这不是标题党，而是在说一个客观事实。接下来，我来给大家分析一下，为什么 jQuery 比 React/Vue 更好。
1
技术选型的核心目的
作为一个前端开发，在搞技术选型的时候，一定一定要记住，我们有两个核心目标，一个是能够更高效更舒适的开发项目，而另外一个，就是要在开发项目的过程中，凝聚出属于你自己的核心竞争力。第一个目标更多的是偏向于团队，第二个目标更多的是要偏向于个人，你想要有一个持续的，健康的职业生涯，这两者缺一不可。只是说，第二个目标只能憋在心里，不能广而告之。
然而事实上，许多人，不管是主动选择，还是被动选择，往往只关注了第一个目标，而忽略了第二个目标。有的人是憋着不说，有的人是压根想不到。这就导致了，这些想不到的很多人，用 Vue/React 用久了，会感觉自己变成了一个废物，演变成一年经验用七年。
这种情况在 Vue 使用者的身上会体现得更加明显。
当然，我不是在说所有人，而是大多数人
所以有的人虽然没有刚才那个同学那种焦虑情绪，也很熟练的在使用 React/Vue，但就是想要获得一个 offer 还是非常困难。因为他们虽然已经熟练使用 React/Vue 开发页面，但这就是一个普通的页面仔啊，工作了 five 年，没有凝聚出核心竞争力，成了一个废物。
因此在做技术选型的考虑上，在我的选择序列里，React 永远都要比 Vue 更值得选择，只因为 React 离原生 JavaScript 更近，没有创造更多的语法，没有那么多黑箱操作，自由度更高。这让我有更多的机会在开发项目的过程中，做到提高开发效率的同时，还能兼顾自己核心竞争力的提升。
而在这两个点的权衡上，jQuery 实际上可以做得更好。
2
我们陷入了 React/Vue 的骗局
React/Vue 最核心的东西，就是组件化。能借助 webpack/vite，在 JS 模块中，把其他静态资源当成模块引入，从而在大型项目中，提高文件结构的可读性和易用性。并利用数据驱动 UI 的方式，在一定程度上简化了开发负担。
但是，我们在学习 React/Vue 时，都被他们骗了。React/Vue 说，我们要构建一个大型项目，需要一个全局状态管理器，我们应该把所有的状态都放到顶层的 store 里。于是 redux 成为了入门 React 必学的技术栈。然而事实上，全局状态管理，我觉得是一种弱智的，简单粗暴的解决方案，他能够让你在思考组件拆分的时候，完全不考虑数据的归属问题，反正随便放在哪里都能轻松访问。
以致于，大部分的前端开发，都是被这种骗局培养成了高效低能的开发者，不管你是用 React，还是用 Vue，有可能都没有逃过这个骗局。当你还在和别人争论 React、Vue 谁会淘汰谁的问题时，你可能还没有发现，这两个家伙构建了一个非常坚固的信息茧房，把所有的前端都圈在里面，然后合伙把你淘汰掉。
所以我认真的思考了一下，真的有很多数据需要全局共享吗？
所以在很多年前，当我经验逐渐丰富起来的时候，我在其他客户端开发解决方案中，见识了更多的开发模式，然后我发现了这个骗局。我们大多数项目，并不需要全局状态管理。甚至也不需要逻辑那么笨重的数据驱动。
3
数据驱动的本质
当全局状态管理没那么有必要的时候，也就意味着，我们的项目数据结构不会那么复杂，所以数据驱动 UI 这个事情，带来的好处，就显得非常有限了。
在 React 中，你这样写
代码语言：javascript复制function Hello() {
const [year, setYear] = useState(2024)
function clickHandler() {
setYear(year 1)
}
return (
<div>
<div>hello {year}</div>
<button onClick={clickHandler}> </button>
</div>
)
}
当我们利用 jQuery 如何写呢，看一下代码
代码语言：javascript复制<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.
我们也可以缩小修改的范围，从而达到最极限的性能，自由度非常高。
代码语言：javascript复制function hello() {
data.year = 1
$('#label').text(`hello ${data.year}`)
}
在复杂度和性能之间，我们可以自由的做出取舍。我们完全没有必要在所有场景，都去花费那么大的代价去考虑如何将数据与 UI 绑定在一起。不管是 Vue 的依赖收集，还是 React 的 diff，在这上面都花费了大量的心思，增加了巨大的心智负担，关键逻辑还变成了黑箱操作。
4
React 的 返祖现象
事实上，熟悉 React 新官网的朋友应该知道，React 已经开始出现返祖现象了。也就是官方文档把 useEffect 定性为一种逃脱方案。当我们发生点击事件时，如果需要修改其他的逻辑，新官方文档建议我们不要去修改状态，而是直接把逻辑写在回调函数里
代码语言：javascript复制// 官方文档不推荐
useEffect(() => {
loading && api().then(() => {})
}, [loading])
function clickHandler() {
setLoading(true)
}
// 官方文档推荐
function clickHandler() {
setLoading(true)
api().then(() => {})
}
我为什么要称这种方式为返祖现象呢，因为你熟悉 jQuery 的使用的话，你就会发现这本身是再正常不过的逻辑了，但是新的官方文档确要花费大量的篇幅去解释为什么应该这样做。这在我看来是非常诡异的事情。
然后呢，我又要花大量的心思去解释我为什么不认同官方文档的这种观点。
5
当我们在 jQuery 中能自定义组件时
我们要达成的一个共识就是，单向数据流是一个被包装出来的高大上概念。说白了就是函数的嵌套执行。
注意看这段代码
代码语言：javascript复制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 流程，只是简单的执行一个目标函数而已。
6
当你需要双向绑定时
当你想要在特定的场景里需要双向绑定时，jQuery 的生态里也有非常多的方案来支撑这个场景。
代码语言：javascript复制$("#changeObjects").on("click", function() {
$.observable(person).setProperty({
name: "newName",
address: {street: "New Street"},
phones: [{number: "123 123 1234"}, {number: "321 321 4321"}]
});
});
所以，当 jQuery 可以自定义组件，可以支持单向数据流，可以支持双向绑定，这不就齐活了吗？
7
趋势是什么
不要问未来的趋势是什么，问就是 jQuery。什么所谓的 Vue3，Solid，svelte，都不是最终形态，他们通通都在走向返祖的道路，未来的趋势就是 jQuery。所以如果你的团队里，还在使用 jQuery，正说明你们团队在领先世界，这是我内心最真实的想法。所以你不需要过于焦虑，你要做的事情只是把 jQuery 用好，用透，去利用 jQuery 的生态构建一套开发效率很高的架构出来，然后回过头来，你会发现，React/Vue 你只需要一天就能学会。
没有一个团队，会拒绝得了精通 jQuery 的人。因为你 jQuery 用得好，很大程度上能代表你原生能力相对会强一些，基础非常扎实。
