XPath 还是 querySelector？
XPath 可以做 querySelector 可以做的所有事情，甚至更多，那么您什么时候会选择后者呢？ 我还没有看到任何比较两者的速度基准，所以现在我根据语法简洁性进行选择，这似乎有点武断。
编辑：我可能应该声明我正在为 Firefox 编写 Greasemonkey 脚本，因此我不担心跨浏览器兼容性，并且宁愿不包含任何库。
XPath can do everything querySelector can do, and more, so when would you ever choose the latter? I haven't seen any speed benchmarks comparing the two, so right now I'm choosing based on syntax conciseness, which seems kind of arbitrary.
Edit: I probably should have stated that I'm writing Greasemonkey scripts for Firefox, so I'm not worried about cross-browser compatibility, and would rather not include any libraries.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
你使用的是什么浏览器？ 在 Safari（或 iPhone）中，querySelector 和 querySelectorAll 比 XPath 快得多。 IE根本不支持XPath，IE6和IE7也不支持querySelector。 最快的跨浏览器选择器引擎是 Sizzle，由 John Resig 创建。 Sizzle 也是 jQuery 中使用的主要选择器引擎。 它在适当的情况下使用 querySelector，在 querySelector 不可用的情况下使用普通的 DOM 方法。
What browser are you using? In Safari (or the iPhone), querySelector and querySelectorAll are much faster than XPath. IE doesn't support XPath at all, and IE6 and IE7 don't support querySelector. The fastest cross-browser selector engine is Sizzle, created by John Resig. Sizzle is also the main selector engine used in jQuery. It uses querySelector where appropriate and normal DOM methods where querySelector is unavailable.
就功能而言，最好的选择是使用包含选择器引擎的库，其中许多库（例如 MooTools、Dojo、Prototype）已经在内部使用 XPath 来执行某些类的查询。 您应该可以信赖一个好的图书馆为您选择禁食方法。
XPath 可能能够完成 querySelector 可以做的所有事情（我认为这个说法有点可疑，但这不是重点），但是并不是所有浏览器都支持 querySelector 和 querySelectorAll，所以我们实际上应该将 XPath 与本机 DOM 查询进行比较方法（即 getElementsByTagName、getElementById、querySelector、标准遍历和过滤方法等）。
使用本机 DOM 过滤方法需要了解浏览器的怪癖和限制，并且对于复杂的查询很快就会变得不切实际，除非您使用库（例如 jQuery 或 MooTools）来实现找出不一致之处。 通常选择本机 DOM 技术（无论是通过 jQuery 之类的代理，还是自定义实现）而不是 XPath 的原因是它们确实提供了比 XPath 更多的灵活性。 例如，如果您想过滤已检查的输入、“隐藏”元素或禁用的输入，XPath 会出现不足，但 jQuery 会为您提供 :checked、:hidden 和 :disabled 伪类。
In terms of functionality your best bet will be to use a library that includes a selector engine, and many of them (e.g. MooTools, Dojo, Prototype) are already using XPath internally to execute some classes of queries. You should be able to count on a good library choosing the fasted method for you.
XPath might be able to do everything that querySelector can do (I think this statement is a bit suspect, but that is beside the point) but querySelector and querySelectorAll are not supported by all browsers, so really we should be comparing XPath to native DOM querying methods (i.e. getElementsByTagName, getElementById, querySelector, standard traversal and filtering methods, etc.)
Using native DOM filtering methods requires knowledge of browser quirks and limitations and quickly becomes impractical for complex querying unless you use a library (e.g. jQuery or MooTools) to iron out the inconsistencies. The reason that native DOM techniques (whether through a proxy like jQuery, or custom implementations) are often chosen over XPath is that they do offer much more flexibility than XPath. For example, if you want to filter for checked inputs, "hidden" elements or disabled inputs XPath comes up short but jQuery gives you :checked, :hidden and :disabled pseudo-classes.
如果您还没有学习 XPath 而只了解 CSS 选择器，那么您只会使用 querySelector。 除此之外，即使对于简单的查询，XPath 语法也可能更加复杂。 因此，如果您不需要 XPath 提供的功能，那么使用 CSS 选择器可能会更容易。
您应该注意两件事：
You'd only use querySelector if you haven't learned XPath yet but only know about CSS selectors. Other than that, XPath syntax can be more complex even for simple queries. So if you don't need the power provided by XPath, it might be easier to use CSS selectors instead.
You should be aware of two things:
CSS 语法之所以出色，有两个原因：
举个例子：采用这个 css 选择器：
h1.header > a[rel~="author"]其最短的函数式 XPath 等价将是
//h1[contains(" "+normalize-space(@class)+" ", " header ")]/a[contains(" "+normalize-space(@rel)+" ","author ")]…这更难读和写。
如果您改为编写此 XPath：
//h1[@class="header"]/a[@rel="author"]…您将错误地错过像
...
当您确实需要时 em> 不过，XPath 是唯一的选择，除非您想用代码手动遍历 DOM（这会变得非常快）。
就我个人而言（我是 Greasemonkey 的维护者之一），我使用非常小的
on.js满足我所有节点切片需求的库 - 它为我提供了 XPath（当我需要时）和 CSS（我几乎一直使用它）的组合 - 主要是因为它让我可以分离出来所有涉及挖掘我需要消化的页面部分的代码都放入脚本标头中，以便我的代码得到所需的所有内容，并且可以真正对网页做一些有趣或伟大的事情。Web 浏览器针对快速运行 javascript 进行了非常严格的优化，如果我是你，我会建议你使用任何能让你作为开发人员最高效和快乐的东西，而不是让浏览器运行最少代码的东西。 不过，
on.js的一个额外好处是，它会自动帮助脚本在您认为的节点所在的页面上根本无法运行。 ，结果不是，而不是破坏页面。CSS syntax is awesome for two reasons:
Case in point: take this css selector:
h1.header > a[rel~="author"]Its shortest functional XPath equivalent would be
//h1[contains(" "+normalize-space(@class)+" "," header ")]/a[contains(" "+normalize-space(@rel)+" "," author ")]…which is both much harder to read and write.
If you wrote this XPath instead:
//h1[@class="header"]/a[@rel="author"]…you would incorrectly have missed markup like
<h1 class="article header"><a rel="author external" href="/mike">...</a></h1>When you really need XPath, though, it's the only option, unless you want to walk around the DOM manually with code (which gets hideous fast).
Personally (and I am one of the maintainers of Greasemonkey), I use the very tiny
on.jslibrary for all my node slicing needs - which gives me a combination of both XPath (for when I need that), and CSS (which I tend to use almost all the time) – mostly because it lets me separate out all the code that deals with digging up parts of a page I need to digest, into the script header so my code gets served all the stuff it needs, and can be all about actually doing fun or great things to web pages.Web browsers are very heavily optimized for running javascript really fast, and if I were you I would recommend using whatever makes you most efficient and happy as a developer, over what makes the browser run the least amount of code. One of the side benefits of
on.jsin particular, though, is that it automatically helps scripts often not get run at all, on pages where the nodes you thought were around, turn out not to be, instead of destroying the page.