我编写了一个运行 Prototype & Scriptaculous 的 JavaScript 应用程序。我正在考虑将它作为一个开源产品推出，并且希望它也能够在 jQuery 上运行——我通常将 jQuery 用于我的大多数其他应用程序，除了这个应用程序最初构建的网站。
我最初考虑构建两个独立的应用程序，但维护它们会很耗时。相反，我正在考虑构建一个库抽象层来检测页面是否正在运行 jQuery 或 Prototype，然后调用适当的方法。我不打算抽象整个库，只抽象适用于我的应用程序的功能——即选择器、事件和效果。我的应用程序的核心代码不到 500 行，所以我不需要担心太多。
因此，$('id')我不会调用LA.$('id')（LA for Library Abstraction），而不是调用$('id')原型和$('#id')查询等......
这听起来合理吗？我想不出任何技术障碍，尽管我曾预料到有人曾经尝试过。我在搜索中找不到类似的东西。
我希望如果您仅部分支持这些库，那么没有人会选择使用它，因为他们必须完成支持，并且您可能会发现维护它会很头疼，因为会有添加更多功能的请求。
如果您的应用程序如此之小，为什么不直接切换到 jQuery 并对其进行标准化，就像 MS 所做的那样。
您可能会遇到版本问题，因为如果有人使用它，并且他们使用的是旧版本的库，并且有一些 API 更改，那么他们会希望您添加对该库的支持。
我相信 Ext.Js 做了类似的事情。他们有一个“适配器”的概念，允许您将 Ext.JS 放在任何底层库之上，它就可以工作。主要区别在于他们使用的是 1 对 1 模型，您可以在其中说出要使用的库并将其连接起来，而我相信您是在尝试说“我不知道哪个库可用但无论你找到什么，去使用它”。
我不认为这很疯狂，但是尝试找出要使用哪个库可能会很有趣，尤其是在两者都可用的情况下。
Web 开发框架（Prototype、jQuery 等）本身被设计为在现有的各种浏览器之上的抽象。您要求框架做一件事，并且无论浏览器如何，它都具有相同的结果（理想情况下）。因此，在这里，您提出了在抽象之上的抽象。大概是因为您希望人们能够使用您的工具，而不管他们为他们的网站选择了什么框架。虽然这听起来像是一个有趣的想法，但我个人不得不猜测，从长远来看它不会奏效。很大程度上是因为你不知道未来会怎样。Prototype 曾经是排名第一的使用框架，现在 jQuery 已经超越了它。也许一年后另一个会非常流行，如果你想支持那个框架怎么办？这可能是你必须添加的很多条件代码，
我说要么选择一个框架来支持并坚持使用它，要么维护单独的库。理想情况下，如果您可以编写某种构建器脚本，那将非常酷。这将允许您在某些列表中设置框架规则，并且脚本将基于某些核心脚本和规则列表为每个框架构建单独的脚本。老实说，我不确定如何最好地完成这样的事情，但它会有效地为您提供您正在寻找的抽象能力的抽象，而最终用户不会看到它。