原型到 jQuery：心态迁移？答案

【问题标题】：Prototype to jQuery: Mindset migration?原型到 jQuery：心态迁移？
【发布时间】：2010-08-28 21:41:46
【问题描述】：

这不是关于并排的技术比较，而是关于如何“在 jQuery 中思考”与“在原型中思考”。

几年来我一直在大量使用 Prototype，而 jQuery 直到大约一年前才开始大量使用它。

使用 Prototype，我可以编写一些相当优雅的代码；我的老板曾经检查过我的大量代码，并说这是他读过的第一个乐于阅读的 Javascript。我理解——并且从一开始就非常理解——几乎本能地理解 Prototype 想要做什么，并且知道如何使用它。

我的 jQuery 代码要多得多，我怎么能把它说出来，“workmanlike”。我觉得我每一步都在与 jQuery 作斗争。我必须（尝试）强迫自己坚持下去，而不是陷入“原生”JS，我知道我可以更快地敲出干净的跨浏览器代码。更多地使用它会使它更令人沮丧，而不是更少。

这不是（或至少不完全是）对可用功能不熟悉。我经常知道我需要使用一个给定的函数，但它的使用方式似乎真的很奇怪。这通常表明我走错了路。

我越想这个，我就越想尝试以原型的方式使用 jQuery。

肯定有一些眩目的闪光还没有发生在我身上。尤其是如果你对两者都进行了很多工作，你发现方法上最根本的区别是什么？从一种切换到另一种时，您需要如何调整心态？

不要害怕说出令人眼花缭乱的事实，因为它可能只是那令人眼花缭乱的闪光......

【问题讨论】：

我也有同样的感觉，我也经历过原型处理得很好的跨浏览器兼容性问题（但在一些非常模糊和罕见的情况下）
“我必须（尝试）强迫自己坚持下去，而不是陷入“原生”JS”——这不是一个下降，这可能是一个改进。如果您认为没有库可以更好地完成特定任务，那么您可能是对的。

标签： javascript jquery prototypejs

【解决方案1】：

我经历了这种转变。一遍又一遍地告诉自己的主要事情是，jQuery 首先是让 DOM 操作更容易和更安全的跨平台。 jQuery 中没有“reduce”（我认为原型曾经称其为“inject”）。为什么？因为维护者认为它对于 jQuery 的主要任务并不重要。

因此，当您编写代码以完成自己的工作时，Prototype 的基本对象扩展会逐渐渗透到您的编码风格中，好吧，这在普通的 jQuery 中几乎不会发生。（但是，请参阅可爱的 Underscore.js 库，了解一种以 jQuery 友好的方式获得其中一些功能的方法。）

对我来说，这让我更容易弄清楚如何在 jQuery 上进行构建。这只是一种不同的东西。现在，jQuery 是非常可靠的，它确实使 DOM 操作和 HTML 争吵很多比你从纯 Javascript 中得到的更好。（我认为 Prototype 也做得很好，但是 jQuery 非常专注于这个问题。）

【讨论】：

【解决方案2】：

我能给出的最好建议是“拥抱this”。在 jQ 中，您几乎总是在谈论迭代包含在 jQuery 对象中的集合。调用 set 的方法之一对 set 的所有元素执行该方法，无论是 1 还是 100。该方法总是会返回 set 的相同实例（除了获取属性的访问器）。在交互的上下文中，this 是您正在操作的集合中的项目的值 - 通常是原始 DOM 元素，但它可能是对象属性或数组项目的值。

【讨论】：

“在 jQ 中，您几乎总是在谈论迭代包含在 jQuery 对象中的集合。”这无疑是有帮助的，并且可能只是让这个问题变得不那么严重：“调用集合的方法之一对集合的所有元素执行该方法，无论是 1 还是 100。”这（呵呵）肯定会让人更难理解别人的代码。似乎没有任何明显的“嘿！这是对集合的迭代”构造，例如 Prototype 的 each()，这让我抓狂。
$.each 用于迭代非 jQuery 可遍历对象（数组、匿名对象、其他结构），$('selector').each(functionToPerform) 用于将非 jQuery 函数应用于集合。但是您所要做的就是查看选择器以了解集合的内容是什么。

【解决方案3】：

为什么你需要以不同的方式思考？与其让你的风格适应出现的每一个框架或语言，不如让框架或语言本身适应你的喜好。然后，您所要做的就是接受这样的想法：可能有比您已知的更好的编写或构建代码的方法，当这些方法出现时，客观地分析它们，然后将它们包含在您的存储库中。

选择几乎从来不是全有或全无。这两个框架都提供了很好的产品，您可以同时使用两者中的技术来构建出色的应用程序。

【讨论】：