Hello, On Jan 29, 2008 12:19 PM, Rahul Sharma <[EMAIL PROTECTED]> wrote: > Recently I evaluated Qooxdoo and extJS and chose Qooxdoo. While I see many > snippets targeting Sebastian, let me add: > a. In our evaluations Qooxdoo was termed far superior. > b. As already mentioned the programming style of Qooxdoo is far superior. > c. API Viewer, demo, samples, testrunner offers so much that you can really > adapt them to build your own applications. Amazing help documents. > d. From the opinon of my 15 member strong team, anything they have asked got > resolved promptly, no one had to wait. > e. Qooxdoo's build system is its core jewel. > f. ExtJS just has a BLUE color, even Qooxdoo supports ExtJS theme. What big > deal? > g. I had fresh college grads in my team and they built Qooxdoo based web-apps > in no time. It was so easy for them to understand, no one ever asked qooxdoo > related questions. > h. You just edit a "js" and press F5 on your laptop. No matter whether you > are at work or home, connected or not connected. That has been one of the > biggest time savers. > i. I don't think any javascript framework can match Event handling that > Qooxdoo provides. > j. I did some performance metrics on already developed Qooxdoo and ExtJS > samples (respectively developed by those teams). In my tests Qooxdoo was > clear winner.
Could you provider your test results? It's very interesting. Thanks, Siarhei > k. Future vision and roadmap should be one of the biggest things when you are > trying to select a toolkit. This is where Qooxdoo excels, there roadmap is > very well defined. > l. Last but not the least Qooxdoo is internally used by projects like Eclipse > RAP and for Borland Delphi. How can you beat that? You don't even know how > many people would be using Qooxdoo "indirectly". > > ________________________________ > > From: [EMAIL PROTECTED] on behalf of Sebastian Werner > Sent: Fri 1/25/2008 4:04 PM > To: qooxdoo Development > Cc: [EMAIL PROTECTED] > Subject: Re: [qooxdoo-devel] Thoughts on ExtJS vs qooxdoo > > > > > thron7 schrieb: > >> What I would value is more timely feedback from qooxdoo developers on > >> bugs. When 0.7.3 was done it seemed that there was a flurry of bug fixing > >> and then a release made as soon as possible with little testing - not > >> even a beta release. However, there are some important problems that > >> require more deeper testing over a period of time. Use the community! > >> > >> It would be much more useful to have bugs in 0.7.3 fixed as soon as they > >> have been logged (if they are considered important enough!) so > >> application developers can use SVN rather than having to apply patches. > >> Also, the bug and testing environment etc are much fresher in the > >> reporter's mind so it's easier to give feedback. Then, you've got many > >> people testing that bugs have been fixed properly. > >> > >> At present, without any feedback on critical issues (like > >> http://bugzilla.qooxdoo.org/show_bug.cgi?id=764 for example) it can > >> appear that you take no interest in supporting developers. Even an > >> acknowledgement of an issue, allocation to a particular developer or > >> release and setting priority, would be enough to show that you take are > >> concerned. > >> > >> Someone looking to use qooxdoo, and seeing what recent bugs had been > >> reported would currently find only 1 out of 15 in 11 days which has had > >> any feedback from the core developers. > >> > >> Perceptions like these are so important when deciding whether to use a > >> package. And you want people to use qooxdoo... the subject of this thread > >> is proof enough that there is good competition. > >> > > Hugh, > > > > you address a valid point here, and thanks for sharing it with us. > > Responsiveness is a big thing in communication, and this shows both on > > the mailing list and the bug tracking system. And I agree with you that > > timely treatment of a bug has a lot of advantages (freshness, testing, > > feedback cycles, ...). It's just that a lot of our work is > > 'feature-driven', trying to implement new ideas and concepts. And - > > you're a developer yourself - you need to *focus* on things if you want > > to see them through. This holds true for both implementing features and > > fixing bugs. So we tend to do one thing first, and then the other - > > that's where the "flurry of bug fixing" before release comes from. > > Interleaving both is a stretch, and - given our current targets and > > resources - I'm not too optimistic we can change a lot here (I have > > spent half days just to validate a specific bug on a certain platform... ). > > > > Maybe we can manage to assign and categorize bugs more quickly, so there > > is some kind of acknowledgment. Doing betas before release is another > > good suggestion (We were just *too* keen to get on with 0.8 this time > > :). And again, maybe other people can help out (this is getting some > > kind of mantra). You're doing this, picking up on bugs and give them at > > least an initial treatment, maybe a couple of others can join in so bug > > reporters feel recognized. > > Great answer Thomas, > > however I have to add some notes. I don't think that it is realistic, > that with the current (human) resource situation, there will be beta > versions before minor updates. Regarding major releases like 0.7, we > normally have some pre, alpha, beta versions out to give the community > the possibility to test them and give feedback. This is important for > major versions as these generally modify large parts of the existing > code base while minor versions ideally just made a few corrections or > additions. > > Sebastian > > > > > > =Thomas > > > > > > ------------------------------------------------------------------------- > > This SF.net email is sponsored by: Microsoft > > Defy all challenges. Microsoft(R) Visual Studio 2008. > > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > > _______________________________________________ > > qooxdoo-devel mailing list > > qooxdoo-devel@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > qooxdoo-devel mailing list > qooxdoo-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel > > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > qooxdoo-devel mailing list > qooxdoo-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel > ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ qooxdoo-devel mailing list qooxdoo-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
