mootools 是 jquery 的替代品吗？骨干/脊椎/ sprouteCore

Question

我是全职 Java 开发人员，现在我也从事 JavaScript 工作。几年前，当我开始学习 JavaScript 时，我尝试的第一个库是 jquery，就像大多数人一样。但这让我的生活变得更加困难，过了一段时间我开始编写相当大的 JavaScript 应用程序。它不是我使用 jquery 组合在一起的。我有庞大的代码库，但没有太多的结构。它是使用选择器更新 HTML 块的方法块。 然后我尝试了 mootools，作为一名 Java 开发人员，它显然对我很有吸引力。我能够编写具有庞大代码库的易于管理的网络应用程序。

据我了解，Mootools 不被认为是编写 JavaScript 的首选方式，因为它模仿传统的 OO 而不是默认的基于原型的 OO 语言。所以现在为了真正理解javascript和与世界同行的愿望，我决定尝试其他方法，所以我再次回到jquery，并意识到只有jquery是不够的。因此开始研究当前的趋势框架，如backbone、spine、ember.js、sprouteCore。奇怪的是，我发现这些框架的核心只是试图通过构造函数并创建类对象并重用此类对象来创建实例对象来模仿传统的 OO（例如 mootools）。那么

• 我错过了什么吗？
• mootools方式真的错了吗？
• Mootools 项目非常活跃并发布了新版本/功能，但我不知道 看到很多人在互联网上谈论它，也没有与骨干/脊椎等进行比较。

Answer 1

据我了解，Mootools 不被认为是编写 JavaScript 的首选方式，因为它模仿传统的 OO 而不是默认的基于原型的 OO 语言。

你从哪里得到它？ javascript 最伟大的一点是它的类型非常松散（看看我在那里做了什么）——你可以用多种陈词滥调的方式编写同样的东西。还有很多方法可以抽象它并重新打包它 - 这适用于从简单的 new Array() 与 [] 到如何构建应用程序。

如果您喜欢 JavaScript（或者只是知道它但暗地里讨厌它），那么 MooTools 会很好。 API 大部分是原生 js 或 ES5 规范，或者（很少）是一个感觉“自然”的额外实用程序。值得注意的例外是Class。事实上，您可以通过将对象传递给返回实例的特殊构造函数 Type 函数来抽象处理原型继承，这一事实是......哦等等。它看起来不同，但它的功能听起来很像普通的 javascript。只是更简单——为什么您不喜欢这样呢？

如今，客户端 MVC 热潮和这种“开发应用程序的新方式”已经取得了很多成果。突然之间，jQuery 的人们获得了自来水的奢侈！我曾就此问题与很多的 MooTools 开发人员进行过交谈，并且（并不）令人惊讶地发现，大多数人认为 MooTools 很少需要类似的东西。我倾向于同意他们的观点。唯一的漏洞是带有模板的视图控制器，但解决方案相当少。

问题是，您不能直接将 MVC 框架与 MooTools 进行比较，它们是不一样的。完全没有。您可以比较所谓的模型构造函数与类。

我现在花了一些时间研究各种 MVC 框架解决方案和模式，看看我们的新应用程序是否可以塑造成“最佳实践”形状。

基本上，我尝试了backbone.js（带或不带mootools适配器），发现在MooTools之后使用起来很尴尬——感觉就像是退了一步。当我说使用时，我并不是说我不能使用它，而是扩展和构建它感觉很尴尬。我确信这只是取决于经验，但还没有阅读所有的骨干模式示例。

我遇到的典型问题 - 想要有一个特殊的 Model 属性，告诉它使用 localStorage 来获取/保存。不太明显 - 示例往往表明您可以将 Backbone.sync 路由到其中一个，但不能同时路由到两者。我必须实际装饰该函数并扩展它，保留原始引用，以防模型不需要 localStorage。不是最好/最明显的维护模式，让我依赖他们的更改而不破坏我的代码。

在 MooTools 中，我只需扩展我的 Model 类，并且可以定义自定义 Class Mutator 属性（如 Binds 或 Implements）。完毕。他们说，写下你所知道的，而不是无用的......

另一个问题 - 它与数据紧密耦合，你不能重用像类这样的模型 - 例如，用户模型加载用户并通过用户编辑视图呈现。然后，您想要创建一个新客户，突然之间，您无法重用旧对象，因为旧对象只能渲染相同的视图，但具有空值。我认为这也归因于我的经验不足或糟糕的架构。

我发现 Ember.js 作为一个界面稍微有点像 Moo-ish，尽管它也没有完全点击。坦率地说，主干设置起来比较麻烦。

还有其他尝试。 Composer 是其中之一 - 再次为 mootools 服务，但它太努力成为骨干，并且是由相对较新的人编写的所以我不会称其为成熟的框架。淘汰赛等等。从字面上看，每天都有新的。

Garrick Cheung 发布了一个名为 Neuro 的框架，该框架具有巨大的潜力。

我写了 Epitome - 一个基于类和事件并封装在 AMD 模块中的完整 MVP 实现，请随意查看。它还附带了一个构建器、文档构建器和许多帮助您入门的小东西。

SeanMonstar 发布了 Shipyard，由 Mozilla Flight Deck 使用 - http://seanmonstar.github.com/Shipyard/。虽然它不是原生的 mootools，但它是带有 mootools 类等的 mootools - 只是没有扩展原生，所以是一个很好的选择。

顺便说一句，尝试 irc.freenode.net #mootools 或邮件列表，您总会得到一个好的答案。

无论如何，MVC 已经足够了。关于MooTools的观点已经被提出过无数次了。仇恨者终归是仇恨者。爱它的人不会回头。如果您是一位具有 OOP 背景的程序员，或者正在寻找能够很好地呈现模式的东西，请帮自己一个忙并坚持下去。激动人心的时刻即将到来。 1.5 的路线图：AMD，2.0（又名，Prime）主机对象原型可选。这是批评者眼中最大的两个贬低点。不再有“脏”原型，因此人们可以继续在非对象上错误地使用 for ... in 循环，并且无需 hasOwnProperty 检查。无论如何……

其他需要担心的事情可能很重要。就像“社区”的规模一样。我认为拥有一个健康的社区是一件好事，但即使你看看 jquery，实际贡献者与用户的数量也很低。代码质量与美观效果的比例很差。你可以使用的插件——很多都写得不好或者已经死了并且不受支持。当你划清界限时，它远没有你想象的那么迷人！

我并不是说 mootools 或其他框架没有这些问题。公平地说，MooTools 人员，尤其是核心开发人员，相当注重隐私，很少公开谈论自己的工作。我不知道，它可能会给人留下错误的印象。它肯定不是 jQuery。
最终 - 如果您拥有资源和专业知识，请使用最有效且可扩展的方法。甚至还有一些人使用coffeescript并对其深信不疑。我有什么资格评判......

为了充分披露——你会发现在招聘时找到一个像样的 mootools 开发人员要困难得多。不能忽视...