编写 JavaScript 抽象 - 这是理智的吗？
我编写了一个运行 Prototype & 的 JavaScript 应用程序。脚本化的。我正在考虑将其作为开源产品推出我希望它也能够在 jQuery 上运行——我通常在大多数其他应用程序中使用 jQuery，除了这个应用程序最初构建的网站。
我最初考虑构建两个独立的应用程序，但维护它们会很耗时。相反，我正在考虑构建一个库抽象层来检测页面是否正在运行 jQuery 或 Prototype，然后调用适当的方法。我不会抽象整个库，只是抽象适用于我的应用程序的功能——即选择器、事件和事件。影响。我的应用程序的核心代码不到 500 行，因此我不需要担心太多。
因此，我不会调用 $('id')，而是调用 LA.$('id') （LA 代表库抽象），它会调用 $('原型中的 id') 和查询中的 $('#id') 等......
这听起来合理吗？我想不出任何技术障碍，尽管我预计以前有人尝试过这样做。我在搜索中找不到类似的内容。
I've written a JavaScript application that runs off Prototype & Scriptaculous. I'm thinking of rolling it out in as an open source product & would like it to be able to run on jQuery as well — I typically use jQuery for most of my other apps, except the site this app was originally built for.
I was originally thinking about building two separate applications, but maintaining them would be time consuming. Instead I'm considering building a library abstraction layer that detects if the page is running jQuery or Prototype and then calls the appropriate methods. I'm not going to abstract the whole libraries, just the functionality applicable to my application — namely selectors, events & effect. The core of my app is under 500 lines of code, so there isn't too much I need to worry about.
So instead of calling $('id') I would call LA.$('id') (LA for Library Abstraction) which would call $('id') in prototype and $('#id') in query etc…
Does this sound sane? I can't think of any technical hurdles, although I would have expected someone to have attempted this before. I couldn't find anything similar in my searches.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
我预计，如果您仅部分支持这些库，那么没有人会选择使用它，因为他们必须完成支持，并且您可能会发现维护它会很麻烦，因为会有添加更多功能的请求。
如果您的应用程序如此小，为什么不直接切换到 jQuery，并对其进行标准化，就像 MS 所做的那样。
您可能会遇到版本问题，因为如果有人使用它，并且他们使用的是旧版本的库，并且有一些 API 更改，那么他们会希望您添加对该库的支持。
I expect that if you support the libraries only partly then no one will choose to use it, as they would have to finish the support, and you may find that maintaining it will be a headache, as there will be requests to add more functionality.
If your application is so small, why not just switch to jQuery for it, and standardize on that, as MS has done.
You may run into problems with versions, as, if someone uses it, and they are using an older version of a library, and there was some API change, then they will be wanting you to add support for that library.
我相信 Ext.Js 做了类似的事情。他们有一个“适配器”的概念，它允许您将 Ext.JS 放在任何底层库之上，并且它会正常工作。关键的区别在于，他们使用的是一对一的模型，您可以在其中说出您想要使用哪个库，然后它将各个点连接起来，而我相信您是想说“我不知道哪个库可用”但无论你找到什么，都可以使用它”。
我不认为这很疯狂，但是尝试找出要使用哪个库可能会很有趣，特别是如果两个库都可用的话。
I believe Ext.Js does something similar. They have a concept of "adapters" which allow you to sit Ext.JS on top of any of the underlying libraries and it will just work. The key difference is that they are using a 1-to-1 model where you say which library you want to use and it joins the dots, whereas I believe you're trying to say "I don't know which one will be available but whatever one you find, go use it".
I don't think it's insane, but you might have some fun trying to work out which library to use, particularly if both are available.
Web 开发框架（Prototype、jQuery 等）本身被设计为现有各种浏览器之上的抽象。您要求框架做一件事，无论浏览器如何，它都具有相同的结果（理想情况下）。因此，在这里，您提出了一个抽象之上的抽象。大概是因为您希望人们能够使用您的工具，无论他们为其网站选择什么框架。虽然这听起来是一个有趣的想法，但我个人不得不猜测从长远来看它不会成功。很大程度上是因为你不知道未来会怎样。 Prototype曾经是第一大使用框架，现在jQuery已经超越了它。也许一年后另一个框架会非常流行，如果您想支持该框架怎么办？您可能需要添加大量条件代码，此外，还要强制将其加载到使用您的工具的浏览器中。
我说要么选择一个框架来支持并坚持使用，要么维护单独的库。理想情况下，如果您可以编写某种构建器脚本，那就真的很酷。这将允许您在某些列表中设置框架规则，并且脚本将根据某些核心脚本和规则列表为每个框架构建单独的脚本。老实说，我不确定如何最好地完成这样的事情，但它会有效地为您提供您正在寻找的抽象能力的抽象，而最终用户却看不到它。
Web development frameworks (Prototype, jQuery, etc.) themselves are designed to be abstractions on top of the various browsers that exist. You ask the framework to do one thing and it has the same result (ideally) regardless of the browser. So, here, you are proposing an abstraction on top of abstractions. Presumably because you want people to be able to use your tool regardless of what framework they have chosen for their site. While it sounds like an interesting idea, I would personally have to guess that it would not work out in the long run. Largely because you do not know what the future holds. Prototype used to be the number one use framework, now jQuery has surpassed it. Perhaps another one will be very popular in a year, what if you then want to support that framework? That can be a lot of conditional code that you have to add, and in addition, force being loaded into the browsers of those using your tool.
I say either pick a single framework to support and stick with it, or maintain separate libraries. Ideally, it would be really cool if you could write some sort of builder script. This would allow you to set framework rules in some list and the script would build separate scripts for each framework based on some core script and the rules list. I honestly am not sure how to best accomplish something like this but it would effectively give you that abstraction on abstraction power that you are looking for without it being visible to the end user.