Sebastian Werner wrote:
-- snip --
Hi Sebastian,
Wasn't trying to make advertising for a sort of competing js library :-) .
Yes, I know that this shrinks down to around 40KB when zipped -- but
I'm pretty sure for this concrete example, that YUI's libs would be
smaller.
-Chris
They have optimized their library for this special use case, we have
not. I guess if YUI layout fits your need it is currently the better
choice for this job. Maybe this changes in the future :-)
Best Fabian
There's a strong reason why we're so excited about qooxdoo and seriously
researching making the switch :-)
And the reason is what? Can you share it with us?
Sebastian
I'll give it a shot.
YUI was originally designed (as to my knowledge) as a javascript library
to enhance existing html web sites. I'm guessing that the project
resulted from Yahoo wanting to add various js widgets to their existing
pages/projects, and have their users who didn't have js enabled still be
able to access any required elements (such as form fields). A key
concept of YUI is to start out with the most minimal set of files to
obtain a given functionality -- you only need to download 2-3 core files
at times, if you're only using a small area of YUI for some page element.
Starting from this base YUI seems to have grown organically, and the
resulting library is a bit of a hodge-podge of various phases of
construction -- old components use often very different concepts to
newer ones (obviously the newer components are a lot cleaner and easier
to understand for the developer). The YUI team know this of course, and
one of the main goals for their upcoming YUI 3.0 release is to
dramatically re-organize and simplify how the entire library works -- to
make it easier to use and understand. Here's the corresponding quote
from the YUI Blog: ( http://yuiblog.com/blog/2008/08/13/yui3pr1/ )
Five Goals for YUI 3:
We've talked to thousands of YUI users over the past 30 months, and
based on that feedback we've set five design goals for the next
generation of the library. What you've told us is that YUI 3.0 should be:
* lighter (less K-weight on the wire and on the page for most uses)
* faster (fewer http requests, less code to write and compile,
more efficient code)
* more consistent (common naming, event signatures, and widget
APIs throughout the library)
* more powerful (do more with less implementation code)
* more securable (safer and easier to expose to multiple
developers working in the same environment; easier to run under
systems like Caja <http://code.google.com/p/google-caja/> or
ADsafe <http://adsafe.org/>)
With this early release, we've made progress toward most of these
objectives --- and we believe we have the right architecture in place
to meet all five as we move to GA over the next few quarters.
Finally, the current state of YUI allows for fairly quick and easy
integration of "stand alone" widgets into an existing web site. For
complete apps (like our CMS front end) it quickly becomes a bit tangled.
That said it was a good choice for us to go with YUI last summer when
starting our project, as at that point in time qooxdoo didn't quite give
us what we were looking for (ie the ability to have a real complete
desktop sytle app + simple stand alone widgets to add to normal html pages).
YUI is definitely easier to get started with -- add a couple of pre
minified .js files to your web page and browse through their very good
docs, and you can have a quick hack working. qooxdoo requires a bit of
up front investment with your advanced tool chain -- definitely worth it
for real projects, but a bit of a hurdle for quick curiosity. Our tools
use Ant to do some of the things that the qooxdoo tools handle, but the
concept of your fully integrated tool chain is super appealing (once its
figured out properly by us).
I think that YUI 3 & qooxdoo 0.8 are both taking big strides in the same
direction. YUI 3 is still quite a way off -- can't imagine that it'll
see the light of day before next winter -- whereas you already have your
release candidate out the door.
We really like the very clean and structured way that qooxdoo is put
together.
I've only spent a few hours digging with qooxdoo, but already have a
semi-functioning Flow layout class and a modified Window sub class
working -- very rewarding to see how quickly things come together and
how clear the class structure of the framework is.
Really looking forward to being able to take advantage of the slick
qooxdoo event system (never really completly figured out YUI on this
front), and things like Mixins and the Testing setup. Focus handling is
also very slick.
The reason we would like to switch, is that we think we can build a
better version of our app based on qooxdoo. YUI has a lot of strengths,
but also some weaknesses, and for our project we feel that qx is a
potentially better fit.
Hope this is what you were hoping for as an answer :-)
-Chris
PS. I think that YUI 3 & qooxdoo 0.8+ will be able to live together very
well, allowing developers to pick and choose between the best bits!
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
qooxdoo-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
