这更多的是风格和偏好的问题，尽管也可能存在性能方面的考虑。
如果您正在使用一个框架（为了论证起见，假设为 jQuery，尽管它可以是任何框架）并且您需要编写一个新函数。这是一个简单的功能，您可以轻松地完成它，而无需使用框架。
无论如何，使用该框架是否有优势，因为它已经加载到浏览器的内存中，具有易于访问的 DOM 映射等？或者普通的 js 总是会解析得更快，因为它是“原始的”并且不依赖于框架？
或者这只是一个品味问题？
This is more of a question of style and preference than anything, though it's possible that there might be performance considerations as well.
If you're using a framework (say jQuery for the sake of argument, though it could be any framework) and you need to write a new function. It's a simple function, and you could easily accomplish it without using the framework.
Is there an advantage to using the framework anyway, because it's already loaded in the browser's memory, has a readily-accessible map of the DOM, etc.? Or will plain-vanilla js always parse faster because it's "raw" and doesn't depend on the framework?
Or is it simply a matter of taste?
发布评论
评论（6）
答案将在很大程度上取决于您正在努力实现的目标。一般来说，如果您使用框架来实现可以使用“普通”JavaScript 完成的任务，那么至少可以保证函数开销带来较小的性能损失。这种性能损失通常是名义上的，在考虑框架的其他优点（开发速度、更清晰的代码、易于维护、可重用代码等）时可以忽略不计。
如果您绝对必须拥有最高效的代码，那么您应该尝试编写高度优化的纯 JavaScript。如果像在大多数现实世界场景中一样，您不关心几毫秒的性能差异，请坚持使用您的框架以保持一致性。
The answer is going to depend greatly on what you're working to accomplish. In general, you're guaranteed at least a minor performance penalty for function overhead if you use a framework to achieve something that can be accomplished using "vanilla" JavaScript. This performance penalty is typically nominal and can be disregarded when taking other advantages of your framework into mind (speed of development, cleaner code, ease of maintenance, reusable code, etc).
If you absolutely have to have the most efficient code possible then you should try to write pure JavaScript that's highly optimized. If, like in most real world scenarios, you're not concerned about a handful of milliseconds in performance difference, stick with your Framework to maintain consistency.
当您解决纯JS问题而不是让外部代码为您解决问题时，总会有一些东西可以学习。从长远来看，它更可维护，因为它是您的代码。它不会改变。你知道它做什么。这就是解决自己的问题的价值真正发挥作用的地方。如果您对 mdc ， msdn 和 ecmascript Spec ，Cross-Browser脚本变得更容易处理。当然，微软有自己的想法和自己的DOM，但这就是乐趣（阅读：挑战）的地方。
纯JS中的跨浏览器脚本确实提高了您的解决问题的能力以及对语言的理解。如果仍然有一些事情让您感到困惑，那么 jQuery 可以加入其中并弥合心理鸿沟，可以这么说。开着豪华车到处兜风固然很棒，但如果你不知道如何在轮胎漏气时更换轮胎，那又有什么用呢？最好的jQuery开发人员是那些非常了解JavaScript并知道何时使用jQuery以及何时使用普通JS的人。
有时候，你只需要卷起袖子，做一些艰苦的工作。没有一个 jQuery 插件可以解决所有问题，而且 jQuery 也无法让您避开各种浏览器提供的所有怪癖。即使您必须出汗才能使其正常工作，也可以用自己的代码完成工作非常有意义。
使用许多不同的工具完成奇异的任务是完全可以接受的。您只需要知道何时何地使用它们即可。
There's always something to learn when you're solving problems with pure JS as opposed to having external code do it for you. In the long run, it's more maintainable because it's your code. It's not going to change. You know what it does. That's where the value of solving your own problems really comes into play. If you do your research on MDC, MSDN, and the ECMAScript spec, cross-browser scripting becomes a lot easier to process. Sure, Microsoft has their own ideas and their own DOM, but that's where the fun (read: challenge) is.
Cross-browser scripting in pure JS really heightens your problem-solving ability along with your understanding of the language. If there still are things that confound you, then jQuery can come into the mix and bridge the mental gap, so to speak. It's great to drive around in a luxury vehicle, but what use is it if you don't know how to change a tire when it goes flat? The best jQuery devs are the ones that know JavaScript well and know when to use jQuery, and when to use plain JS.
Sometimes, you just have to roll up your sleeves and do some hard work. There isn't a jQuery plugin for everything, and jQuery can't hide you from all the quirks that various browsers have to offer. Getting the job done with your own code is very rewarding, even if you had to sweat it out to make it work.
It's perfectly acceptable to use many different tools to complete a singular task. You just need to know when and where to use them.
根据我对 jQuery 的理解，它实际上并不在内存中维护 dom 的映射，而只是具有用于遍历 dom 的跨浏览器方法。某些浏览器中的某些内容自然会比其他浏览器更快（例如 Firefox 中基于类的选择器将比 IE 中更快，因为 IE 没有 getElementsByClassName 的内置函数，而 Firefox 有）。如果您不需要框架方法来执行操作，我会说继续使用本机 JS，因为这通常是您选择的框架将使用的。
From my understanding of jQuery it doesn't actually maintain a map of the dom in Memory and just has cross browser methods for walking the dom. Somethings will natually be faster in some browsers over others (such as a class based selector in Firefox will be faster than in IE because IE doesn't have a built in function for getElementsByClassName and Firefox does). If you don't need the frameworks methods for doing things I would say go ahead and use the native JS as that is generally what you chosen framework will use.
我会说用框架来做，只是因为它会带来项目内部的一致性。如果你在任何地方都使用该框架，即使是在很小的功能中，它也会更容易维护。
至于其他因素，这实际上取决于您想要做什么。
I would say do it with the framework, just because it will bring consistency inside the project. If you are using the framework everywhere even in small function, it will be easier to maintain.
As for the other factor it really depends on what you are trying to do.
我一直在从事一个 javascript 密集型项目。我发现几乎每次我的代码中出现跨浏览器错误时，它都在我有这样的代码的地方：
并且香草在所有浏览器中并不完全相同。我喜欢 jQuery 的一点是（大多数时候）它隐藏了浏览器的差异，并且它的功能在所有浏览器中都是相同的。
I've been working on a javascript-heavy project. I've found that almost every time I had a cross-browser bug in my code, it was in a place where I had code like this:
and that vanilla wasn't exactly the same across all browsers. What I love about jQuery is that (most of the time) it hides the browser differences and its functions work the same across them all.
如果您通过 ID 选择元素，那么纯 Javascript 会更快。然而，它并没有提供 jQuery 所提供的任何选择细节 - 例如，在一次调用中按类选择多个元素。
看一下这个链接：http://www.webkit.org/perf/slickspeed/ 运行速度测试。它是 jQuery 的旧版本，但原始速度方面的结果不言而喻。
就我个人而言，我倾向于在所有事情上都使用 jQuery - 它使代码更简洁，而且它几乎消除了跨浏览器 JS 支持问题，这一事实在我的书中值得任何性能开销。
If you're selecting elements by ID then plain Javascript is faster. It doesn't, however, provide any of the selection niceties that you get with jQuery - selecting multiple elements by class in a single call, for example.
Take a look at this link: http://www.webkit.org/perf/slickspeed/ which runs a speed test. It's an older version of jQuery, but the results in terms of raw speed speak for themselves.
Personally, I tend to use jQuery for everything - it keeps the code cleaner and the fact it pretty much dispenses with cross-browser JS support issues is worth any performance overhead in my book.