是mootools替代jquery + backbone / spine / sprouteCore

时间:2012-02-22 19:03:20

标签: javascript jquery backbone.js mootools

我是java开发人员,现在我也在研究JavaScript。几年前,当我开始学习JavaScript时,我试过的第一个库就像大多数人一样jquery。但它让我的生活变得更加艰难,过了一段时间我开始编写相当大的JavaScript应用程序。使用jquery并没有为我聚集在一起。我有很大的代码库,没有太多的结构。这是使用选择器更新HTML块的方法块。 然后我尝试了mootools并且不经意地作为一个java开发人员,它吸引了我很多。而且我能够编写具有巨大代码库的可管理Web应用程序。

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

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

1 个答案:

答案 0 :(得分:41)

  

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

你从哪里得到的?关于javascript的最大的好处就是它是如此松散的类型(看我在那里做了什么) - 你可以通过各种方式编写相同的东西。还有很多方法可以抽象它并重新打包它 - 这可以从简单的new Array() vs []到你构建应用程序的方式。

如果你喜欢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属性(如BindsImplements)。完成。他们说,写下你所知道的,而不是一无所获......

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

Ember.js我发现moo-ish稍微有点作为界面虽然它也没有完全点击。坦率地说,骨干设置起来不那么麻烦。

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

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

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

SeanMonstar发布了由Mozilla Flight Deck使用的Shipyard - http://seanmonstar.github.com/Shipyard/。虽然它不是原生的mootools,它的mootools-ish与mootools类等 - 只是不扩展本地人,所以一个很好的选择。

顺便说一下,试试irc.freenode.net #mootools或邮件列表,你总能得到一个好的答案。

无论如何,对MVC来说足够了。关于MooTools的观点已经无数次了。仇恨者将是仇恨者。那些喜欢它的人不会回头看。如果你是一个来自OOP背景的程序员,或者正在寻找能够很好地融入模式的东西,请帮个忙,坚持下去。激动人心的时刻已经到来。 1.5的路线图:AMD,2.0(aka,Prime)主机对象原型可选。这些一直是评论家眼中最引人注目的两个话题。没有更多'脏'原型,所以人们可以继续使用for ... in循环错误的非对象和没有hasOwnProperty检查。无论如何...

其他需要担心的事情可能很重要。比如,'社区的规模'。我认为拥有一个健康的社区是一件好事,但即使你看看jquery,实际贡献者与用户的数量也很少。质量CODE与良好效果的比例很差。你可以使用的插件 - 很多都没有很好的写入或死亡和不受支持。当你划清界限时,它不如你想象的那么迷人!

我并不是说mootools或其他框架没有这些问题。可以公平地说,MooTools的人们,特别是核心开发人员是相当私密的,而不是他们所做的事情。它可能会发出错误的印象,我不知道。它当然不是jQuery。 最终 - 如果您拥有资源和技术诀窍,请使用最有效的和可扩展的内容。甚至有些人使用咖啡因并发誓。我该判断谁...

为了充分披露 - 你会发现在招募时很难找到一个体面的mootools dev。不容忽视......