Hello, just want to chime in. I disagre with Jean-Baptiste about what needs to be done to trigger greater adoption. Personally I think Python is a great choice for a build system and I had no problems at all with this as a newcomer to Qx. There are btw probably more companies in France using Qx that what you may think (we are one of such companies), for a simple reason that was already outlined: from a technical perspective, Qx rocks.
I think that's actually one of the reason that it's hard to find paid consultancy on Qx: the framework is so good, and the support on the ML is so good, who needs to pay a consultant ? ;) Greater adoption will be achieved only through time, IMHO; jQuery has better adoption just because it's not used for the same things, and a lot more people need some extra JS on a mostly server based web system than a full blown OO JS library for a RIA. Qx is better compared to GWT (also a great library, btw) and GWT is more known because Google has probably 1000 times the marketing power 1&1 has on the development community (since Google produces an incredible amount of good stuff for developers). But if you compare for example Qx to Zapatec (also a JS RIA commercial library - I used it in my previous company, it's expensive and a total piece of crap), I am not sure Zapatec is more known than Qx. The only thing I wish for Qx is faster development, faster bugfixing. Especially with bugs that have patches. There is one bug on the bugzilla that has a patch and is absolutely essential for us, but it is still not applied upstream. But hey, man power is limited. The build system is also a bit weird at times but for a newcomer, everything works out of the box, so I dont really think there needs some improvement there. Cheers Jean-Noel On Mon, Sep 13, 2010 at 6:31 PM, thron7 <[email protected]> wrote: > > >>> I think projects also can grow too fast (meaning not as >>> carefully designed/tested/etc). >> >> Growing too fast ? Are you serious ? That's not current qooxdoo problem ! >> You may have information I don't have, but according to me, qooxdoo is not >> growing fast enough. > > I think there are different issues: > > (a) A greater market recognition of qooxdoo, e.g. in the French market, > so that you find it easier to get acceptance to chose qooxdoo for a > customer project. > (b) A greater qooxdoo user community. > > (b) might derive from (a), but they are still two separate issues. > > In case of (b), I'm re-stating what I have said before, and what is in > line with Fritz' remark: We're on the brink of what we can handle > manpower-wise. If e.g. the mailing list traffic would grow by, say, 30% > and we would still try to provide the same level of support there, that > might mean we had to entirely stop implementing new features in qooxdoo! > Or cut down on testing. Or cut down dramatically on documentation. Or > cut down on support otherwise. Just consider that. > > T. > > ------------------------------------------------------------------------------ > Start uncovering the many advantages of virtual appliances > and start using them to simplify application deployment and > accelerate your shift to cloud computing > http://p.sf.net/sfu/novell-sfdev2dev > _______________________________________________ > qooxdoo-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel > -- Jean-Noël Rivasseau Directeur (1) 778 786 3460 / (33) 01 82 88 05 26 Kameleoon - morphing the web http://www.kameleoon.com/ ------------------------------------------------------------------------------ Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing http://p.sf.net/sfu/novell-sfdev2dev _______________________________________________ qooxdoo-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
