Petr,
I have been using qooxdoo for a few years now and all along I have been
looking at other possible solutions. So far, nothing even comes close to
comparing to qooxdoo. Yes, qooxdoo creates a lot of DIV's, no one is
disputing that, but that alone does not mean it's slow or that they need to
be reduced. I found out early that if you pool your objects, then when you
need them again they render incredibly fast. I was able to speed up my app
almost 100% by pooling my objects. And it also had the nice side effect of
reducing memory leaks. So, what I am saying, is that just because you see a
lot of DIV's, don't immediately think that this makes the toolkit slow and
that there aren't ways to make things faster.
We use qooxdoo to create a browser version of our Windows program. When you
compare the 2 apps now, they have the same look and feel, you just can't
easily do this with the other toolkits. And in some places in our app, the
browser version is faster then the Windows version, so I have no complaints
at all right now on speed. If your app is running slow, post some examples
to the list and let us help you determine what is really causing your
slowness, your issue might not be completely the fault of the toolkit.
Jim
On Tue, Aug 31, 2010 at 5:12 AM, Petr Kobalíček <[email protected]>wrote:
> let me summarize this discussion:
>
> 1. TaskSpeed is not relevant benchmark for this topic. I'm talking
> about speed of qooxdoo and not some css selector stuff which is
> irrelevant. The speed killer is count of needed DOM elements per
> application/widget, not javascript size or css selector speed.
>
> Just look how many DOM elements are created for simple button, this is
> really not about selectors.
>
> 2. Qooxdoo will be never for classic web-apps for speed/size reasons.
> I can accept that, but the qooxdoo community have to accept that
> qooxdoo will never spread (for me this is not problem at all).
>
> 3. I will never post here another qooxdoo critique mail. I have
> feeling that critique is not welcome here and I really tried to be as
> objective as possible.
>
> I can understand that qooxdoo can't be good for everything, but really
> think that the performance should be improved, this is all I wanted to
> say...
>
> Best regards
> Petr
>
>
> ------------------------------------------------------------------------------
> This SF.net Dev2Dev email is sponsored by:
>
> Show off your parallel programming skills.
> Enter the Intel(R) Threading Challenge 2010.
> http://p.sf.net/sfu/intel-thread-sfd
> _______________________________________________
> qooxdoo-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
>
------------------------------------------------------------------------------
This SF.net Dev2Dev email is sponsored by:
Show off your parallel programming skills.
Enter the Intel(R) Threading Challenge 2010.
http://p.sf.net/sfu/intel-thread-sfd
_______________________________________________
qooxdoo-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
