Qooxdoo vs. Trunk

Question

I used Backbone.js and LOVE it.

I recently came across qooxdoo and honestly? It seems even better ( for OOP code design )!
Full support for OOP (love of inheritance [ this.base ], namespace, etc.).
I have not gone too deep yet, so I was looking for a comparison with Backbone.js without any success.

So, if you used both - what can you say about qooxdoo regarding Backbone.js?

I'm not talking about features such as “saving the model” (saving / deleting ajax calls) in Backbone, as well as functions like the user interface in qooxdoo ( qx.ui.form.Button ), but rather a coding structure and maintainability.

Answer 1

My experience with Backbone.js is that it is limited, but it is great for building heavy web applications. The ability to sit with any user interface makes it extremely flexible. In terms of code maintenance, the organization of Backbone code really depends on the developer. Using other libraries (require.js) definitely helps in the organization, but it takes a lot of effort and requires prior planning.

Qooxdoo, on the other hand, is a completely different beast. Thanks to its own type system, Qooxdoo really goes up to the classic language sitting on top of javascript, which requires a good code organization. This does not mean that you cannot write unorganized code with it, but it simplifies the organization of large projects.

Since qooxdoo is more a language than a framework [without it, of course, with its rich user interfaces and data components that are very good), you can literally do something with it, recreating all the benefits of Backbone, easily adding in good features - much certain classes (of all types, models, controllers, views, etc.) - And create [excellent] documentation from these classes to load!

Ability to define interfaces, classes, mixins, inheritance, properties, access modifiers (!), Etc. (...) in the classical sense (ala Java / C # / ...), remaining inside very well defined file / class names, really raises qooxdoo above everything else. In fact, its type system is so good that it even separated it from the user interface components that will be used autonomously in browser applications or on a server with node.js / rhino applications. This is starry.

Anyway, I am very prone to qooxdoo, so in my opinion with salt. :)

Answer 2

I used both. For small applications that look more like web pages with some features in them than really heavy applications that just use a browser for their user interface, qooxdoo is redundant. For most intranet applications I came across, which have a rich user interface, several different forms, heavily use many different user interface controls (table, tree, combos, split panels, tabs, etc.). Qooxdoo is the best choice. / p>

Not that you cannot build any of them with one or another. Qooxdoo simply simplifies work with large code bases, provides good but unconditional support for the MV (C | P) architecture, has good support for various types of backends (REST, RPC, with JSON or XML) from the box, excellent support for unit testing, separation of problems re. themes and functionality - a lot of useful things when you make a large and complex application, but not very useful and too heavy for small applications.

There, one particular weakness in the basis of barebones bands makes it an especially poor choice for large projects - its models are not hierarchical (i.e. model members who are models themselves not cascading events or JSON serialization - they are considered as simple Java objects by highways). The Qooxdoo property system and the built-in JSON serializer do not have this problem. OTOH, there are several basic plugins specifically designed for this problem.

OTOH, lately, qooxdoo has cut out various pieces to make it easier to use the right subsets of qooxdoo in small web / mobile apps, making them available separately. Therefore, studying qooxdoo and building an ecosystem around it is probably more reasonable / more economical for developing a corporate intranet.

Another aspect to consider is popularity. Most web developers have not heard of qooxdoo, given that 1 & 1, a proponent of qooxdoo development, does not invest in qooxdoo marketing at all. So selling qooxdoo to your development team can be difficult, even when it’s a smart technical choice.

Answer 3

I am writing a great qooxdoo application and I am pleased with the result. Qooxdoo is well suited for this (I don't know many other frameworks for this).

It's not so easy to get started, but qooxdoo developers offer great learning tools: a playground, a demo browser, api viewer, inspector, test browser. The Qooxdoo team is very professional and usually responds quickly when you post a question here or through a mailing list.

It is very easy to contribute, they welcome their input with open hands.

The main problem of the structure is popularity. This is unknown to many people. The structure is large and some parts of the code are old and need more user reviews.

Fortunately, you just need to create the derived class and write / override methods to help you (and send a pull request :))

Answer 4

Please find the comparison below, according to my understanding: -

Backbone.js:

• Lightweight library compared to Qooxdoo.
• Easy to run (if you know javascript).
• There are many other documents and examples in the documentation.

Qooxdoo:

• A big library
• It’s not easy to start
• Fewer documents and examples compared to backbone.js

I was a Qooxdoo developer. But the truth is Backbone.js is better in many problems. Especially for small applications.

Good luck