同问，为什么jQuery取消了uaMatch函数，以及browser属性。

Posted on Edited on In

一些原因导致我觉得，继续鄙视H5+JS阵营，会在未来吃很大的亏。于是我决定最近开始，每天晚上抽出至少1个小时的时候，详细学习这部分的东西。
我Down了一本老书《HTML5 Programming with JavaScript For Dummies》，在开始coding它第一个例子的时候发现他依赖的jQueryAPI uaMatch，已经被deprecated了，不仅这个函数，还包含它在之后版本里推出的为了取代它的browser属性。（也就是它已经过时了两次了）。

于是我摸到了   这里。
看到一个开发者和jq开发者的对话，jq开发者的意思大约有这么几点，随着许多不同浏览器开发商对H5标准的差异化实现，以及历代的版本问题，简单的浏览器名称和浏览器版本判断，已经不能满足现代的H5开发需求了，所以他们使用一个support属性，来包含许多对不同特性的支持情况的判断结果。看 这里。
至于移除unMatch的原因，也出于对jq体积，运行效率等多方面考虑，jq开发者也说，“您完全可以自己实现这个函数呀～”然后给出了代码，我Mark在这里：

1
2
3
4
5
6
7
8
9
10
11
12
13
function uaMatch( ua ) {  
     ua = ua.toLowerCase();  
     var match = /(chrome)[ \/]([\w.]+)/.exec( ua ) ||  
          /(webkit)[ \/]([\w.]+)/.exec( ua ) ||  
          /(opera)(?:.*version|)[ \/]([\w.]+)/.exec( ua ) ||  
          /(msie) ([\w.]+)/.exec( ua ) ||  
          ua.indexOf("compatible") < 0 && /(mozilla)(?:.*? rv:([\w.]+)|)/.exec( ua ) ||  
          [];  
     return {  
          browser: match[ 1 ] || "",  
          version: match[ 2 ] || "0"  
     };  
}

我因此也开始端正自己的态度，多年来，一直工作在Flash的sandbox中，应该出来透透气了，是否jq和Adobe一样，做这样的跨平台兼容和判断，已经非常疲倦了，索性开放这些判断出来给你们看，自己想实现什么就是什么吧，这无疑将H5+JS的开发门槛又提升了一些，我倒是无所谓，底子还行。

同期也在学Edge系列的东西。