我使用过Backbone.js并爱上了它。
最近我偶然遇到了qooxdoo并且老实说？它似乎更好（用于OOP代码设计）！
完全OOP支持（喜欢继承[this.base]，命名空间等）
我还没有深入研究它，所以我一直在寻找与Backbone.js的比较而没有任何成功。
所以，如果你同时使用了两者 - 关于Backbone.js，您对qooxdoo有什么看法？
我不是在谈论Backbone中的“模型持久化”（保存/删除ajax调用）以及qooxdoo（qx.ui.form.Button）中的UI等功能，而是编码结构和可维护性的
答案 0 :(得分：10)
我对Backbone.js的体验是有限的，但它非常适合创建数据量很大的Web应用程序。能够在其上面放置任何UI使其非常灵活。至于代码维护，Backbone的代码组织确实依赖于开发人员。使用其他库（require.js）肯定有助于组织，但仍需要很多努力和前期规划。
另一方面，Qooxdoo是一个完全不同的野兽。 Qooxdoo以其自己的类型系统为核心，真正将自己提升为一种坐在javascript之上的经典语言，这需要良好的代码组织。这并不是说你不能用它来编写无组织的代码，但它只是让组织大型项目变得更容易。因为qooxdoo更像是一种语言而不是框架[sans，当然，它的丰富的用户界面和数据组件非常好]你可以用它做任何事情，重新创建Backbone的所有好处，同时轻松添加很好的功能 - 强定义的类（所有类型，模型，控制器，视图等） - 并从这些类生成[优秀]文档来启动！
能够在一个非常明确定义的命名空间内定义传统意义上的接口，类，混合，继承，属性，访问修饰符（！）等（...）（ala Java / C＃/ ...）文件/类结构，真的让qooxdoo高于其他所有东西。它的类型系统实际上非常好，它们甚至将它与UI组件分开，以便在浏览器应用程序中单独使用，或者在具有node.js / rhino应用程序的服务器上使用。它很棒。
无论如何，我对qooxdoo非常偏见，所以我的意见很多。 ：）
答案 1 :(得分：2)
我用过两者。对于小型应用程序，更像是具有某些功能的网页，而不是真正沉重的应用程序，恰好使用浏览器进行用户界面，qooxdoo是过度的。对于我遇到的大多数内部网应用程序，它们具有丰富的UI，几种不同的形式，大量使用许多不同的UI控件（表格，树，组合，分割窗格，标签视图等）.qooxdoo是IMO更好的选择。< / p>
并不是说你不能用其中一种构建任何一种类型。只需qooxdoo可以更轻松地处理大型代码库，为MV（C | P）架构提供良好但无限制的支持，对各种后端类型（REST，RPC，带有JSON或XML）提供良好的支持。框，优秀的单元测试支持，关注点分离。主题和功能 - 很多有用的东西，当你做一个大而复杂的应用程序，但对于小应用程序来说不那么有用和太重。
准系统主干中存在一个特别的弱点，使其成为大型项目的不良选择 - 其模型不是分层的（即模型中的成员本身不会级联事件或JSON序列化 - 它们被视为通过主干的普通Java对象）。 Qooxdoo的属性系统和内置的JSON序列化器没有这个问题。 OTOH，有几个主干插件专门针对这个问题。
OTOH，最近，qooxdoo已经删除了各种部分，以便在较小的网络应用程序/移动应用程序中轻松使用qooxdoo的正确子集，使它们单独提供。因此，学习qooxdoo并围绕它构建生态系统可能是企业内部网开发的更明智/更经济的选择。要考虑的另一个方面是受欢迎程度。大多数网络开发者都没有听说过qooxdoo，因为1＆amp; 1 - qooxdoo开发的支持者 - 根本不投资qooxdoo营销。所以将qooxdoo卖给你的开发团队可能会很难，即使它是更聪明的技术选择。
答案 2 :(得分：1)
我写了一个很大的qooxdoo应用程序，我对结果感到满意。 Qooxdoo非常适合（我不知道很多其他框架）。
启动并不是一件容易的事，但qooxdoo的开发人员提供了一些很好的工具来帮助学习：游乐场，演示浏览器，api查看器，检查器，测试浏览器.... Qooxdoo团队非常专业，当您在此处或通过邮件列表发布问题时，他们通常会快速回答。
贡献非常容易，他们欢迎您的贡献。
框架的主要问题是受欢迎程度。许多人都不知道。框架很大，代码的某些部分很旧，需要更多的用户反馈才能得到改进。
幸运的是，通常你只需要创建派生类和写/覆盖方法来帮助你（并发送拉取请求:)）
答案 3 :(得分：0)
根据我的理解，请在下面找到比较： -
<强> Backbone.js的：
<强>的Qooxdoo：
我是Qooxdoo的开发者。但事实是 Backbone.js在许多问题上更好。特别适用于小型应用程序。
祝你好运！