Hi guys,

Here is my "contrib" :) to this discussion (will try to be the most concise
as possible but I admit there are so much to say).

Regarding the contrib manager:


* I agree that using an existing package manager could be a better choice
        * using npm or bower is in my opinion not so important (as there are
already plenty of code that can fit on server or client side, a lot of
package that are supposed to be "client" related but not linked directly to
bower etc... actually it's already a complete mess :) )
        * because there are some specific things in the way contribs are 
integrated
in qooxdoo apps, we could keep our kind of custom package manager that use
internally bower or npm. So we don't reinvent the wheel completely and save
time for the core developers ;)
        
Regarding the framework in its today version (desktop-centric view only):


* I agree on the fact that:
        * qooxdoo is very verbose. Actually it's the framework's strength and
weakness at the same time.
        * Theming for desktop apps can be frustrating
        * Using bindings for desktop apps isn't always suitable (even if I'd 
like
to) because all the widgets don't handle it fully or in the same way by
default
                * multiple selection aren't saved in form models, selection 
change and
combobox don't fit each other etc...
                * marshaling is time consuming (for instance: creating a model 
for big
virtual lists is not good enough - the way the table widget works is more
efficient in this case)
        * There are sometimes implementations inconsistencies for widgets that
could or should be unified (virtual ones and simple ones), they don't use
the same methods etc... Even if it's sometimes practically complicated it
would be better to uniform it
        * The build file size is important (even if it's not really so blocking 
to
me)
        * The time needed for re-building apps can be frustrating
        * The API changes between versions are sometimes frustrating too 
        * The Core developer road map isn't always clear so it's difficult to
anticipate what we have to code by ourself or not

[*] I realised the best is sometimes to create the form in one class and
specify the event logic in another one to avoid this kind of problem. About
bindings I also created what I call a form factory. I don't think it's good
enough yet to share with the community but it tries to be compatible with
most of the desktop widgets and tries to overcome some problems I encounter.
I suppose I'll share it with all of you
        
Comparing the "today" framework with AngularJS or Knockout etc...:


* AngularJS don't rely on the same kind of architecture (MVVM vs MVP) so
comparing it is a bit unfair. But indeed Angular has several advantages : 
        * Creating a form and binding it to a model with validation can be done 
a
lot faster that qooxdoo
        * More clearer separation between markup and logic because it's not only
"JS"
                * in qooxdoo, when having big forms with a lot of logic, it 
becomes
quickly difficult to read because all is located at the same side [*]
                * as Peter said we aren't anymore in a world dominated by IE6. 
In my
opinion, Java-inspired JS layout engines aren't anymore necessary in most of
the cases. CSS can do the job for us simpler because it's not so broken than
in the past globally.
* On the contrary, the clear disavantages of Angular are:
        * Its lack of UI uniformisation.
                * There are'nt any clear widget base yet or good practises 
"way-to-create"
directives. 
                        * Bootstrap isn't a complete base enough in my point of 
view.
                        * Comparing with the Polymer framework and the 
component approach it's
the same problem I guess. I have a feeling that everybody can "code" its
widget in the way he likes and then integrating contributions in our SPA can
quickly become a complete mess of code "a-la-jQuery"
        * Its lack of good UI set yet
                * I haven't found any completely promising table widget yet for 
instance
(Slicktable seems the best candidate so far and it's complete jQuery)
        * The way you declare the JS code isn't always "clean" in my point of 
view
        * I have a feeling the custom attributes used in the markup should be 
more
uniformised or should follow "good practises" before integration

The challenge of qooxdoo "next" - it's huge work indeed ;) :


* We have now three different approaches for building UI: web, mobile and
desktop.
        * About the web version:
                + you can integrate it with existing markup more easily (inline 
desktop
applications aren't good enough sometimes)
                - it lacks bindings to be MVVM competitive :) 
                - you don't have the power of the complete qx-class system 
(properties,
mixin etc...)
                - the default widget base is too small
        * About the mobile version:
                + theming is so easier to manage than in the desktop apps
                - the API is different from the desktop one
        * About the desktop version:
                + the widget base is particulary good
                - there are API inconsistency sometimes between nearly same 
purpose
widgets

* What I guess is - Martin stop me if I'm wrong - the Qx Team already tries
to unify the three bases in some way - and I must say I like it:
        * already integrated pointer events system
        * selection API refactor
        * widget factories
        * a plan for a new desktop widget core base - no more qx.html.* (qxweb
based ?)

* Also noticed:
        * lighter class system creation
        * new generator algorithm
                * cosmetic classes removal (qx.Bootstrap etc... ) nearly only 
needed for
the python-based generator
                * speed improvement 

* What I hope is plan to be done in future releases too:
        * simpler theming architecture for desktop apps (like in the mobile 
branch)
        * binding partial refactor too
                * creating a model can be time consuming and should be 
optimised (what
abour partial models ?)
                * binding uniformisation between all UI widgets
                
                
Let me finish this long list by thanking the core team for all the great job
accomplished so far. I still likes to create qx-based apps and I think the
core team already knows what must be done to make qooxdoo competitive again.
There is massive work to be done... It will take some times of course... but
I have good hope!

Best Regards,

Benoît.



--
View this message in context: 
http://qooxdoo.678.n2.nabble.com/qooxdoo-contrib-again-tp7586131p7586295.html
Sent from the qooxdoo mailing list archive at Nabble.com.

------------------------------------------------------------------------------
Comprehensive Server Monitoring with Site24x7.
Monitor 10 servers for $9/Month.
Get alerted through email, SMS, voice calls or mobile push notifications.
Take corrective actions from your mobile device.
http://p.sf.net/sfu/Zoho
_______________________________________________
qooxdoo-devel mailing list
qooxdoo-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel

Reply via email to