javascript - mootools 是 jquery +backbone/spine/sprouteCore 的替代品

Question

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

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

我错过了什么吗？

mootools的方式真的错了吗？

Mootools 项目非常活跃并发布新版本/功能，但我没有
看到网上很多人在谈论它，也没有对比 Backbone /脊椎等。

Answer 1

As per my understanding Mootools is not considered a preferred way to write JavaScript because it mimic conventional OO over default prototype-based OO language.

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

如果你喜欢 JavaScript(或者只是知道它并且暗地里讨厌它)，那么你会很好地使用 MooTools。 API 主要是原生 js 或 ES5 规范，或者 - 很少 - 一个也感觉“自然”的额外实用程序。突出的显着异常(exception)是 Class .并且您可以通过将对象传递给特殊的构造函数来抽象处理原型(prototype)继承的事实 Type返回您的实例的函数是...哦等等。它看起来不同，但它所做的几乎听起来像普通的 javascript。只是更容易——你为什么不喜欢那样？

如今，客户端 MVC 的繁荣和这种“开发应用程序的新方式”正在发生很多事情。突然之间，jQuery 的人们得到了自来水的奢侈!我已经就此与很多 MooTools 开发人员进行了交谈，并且(不)惊讶地发现大多数人认为 MooTools 很少需要这样的东西。我倾向于同意他们的观点。唯一的漏洞是带有模板的 View Controller ，但有很多解决方案。

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

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

基本上，我尝试了backbone.js(有和没有mootools 适配器)，发现在MooTools 之后使用很尴尬——感觉像是退步了。当我说使用时，并不是说我不能使用它，而是扩展和构建它感觉很尴尬。我相信这只是经验，还没有阅读那里的所有主干模式示例。

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

在 MooTools 中，我只需扩展我的 Model 类，并且可以定义自定义 Class Mutator 属性(如 Binds 或 Implements )。完毕。写下你知道的，他们说，不要白费...

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

Ember.js 作为一个界面，我发现它稍微有点莫名其妙，尽管它也不太点击。坦率地说，主干设置起来不那么麻烦。

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

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

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

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

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

无论如何，MVC 已经足够了。关于 MooTools 的观点已被无数次提及。仇恨者将成为仇恨者。喜欢它的人不会回头。如果您是一名具有 OOP 背景的程序员，或者正在寻找能够很好地呈现模式的东西，请帮自己一个忙并坚持下去。激动人心的时刻就在眼前。 1.5 路线图:AMD，2.0(又名， Prime)主机对象原型(prototype)设计可选。这一直是评论家眼中的两个最大的话题。不再有“脏”原型(prototype)，因此人们可以继续在非对象上错误地使用 for ... in 循环，并且没有 hasOwnProperty检查。反正...

其他需要担心的事情可能很重要。比如，“社区”的规模。我认为拥有一个健康的社区是一件好事，但即使您查看 jquery，实际贡献者与用户的数量也很少。质量代码与好看效果的比例很糟糕。您可以使用的插件 - 很多插件写得不好或已死且不受支持。当你划清界限时，它没有你想象的那么迷人!

我并不是说 mootools 或其他框架没有这些问题。可以公平地说，MooTools 的人，尤其是核心开发人员是相当私密的，对他们所做的事情不那么直言不讳。它可能会发送错误的印象，我不知道。它当然不是 jQuery。
最终 - 如果您拥有资源和专业知识，请使用最有效且可扩展的方法。甚至还有那些使用 coffeescript 并以此发誓的。我是谁来评判...

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