"qooxdoo Development" <[email protected]>
Re: qooxdoo is slow Hi. > Just look how many DOM elements are created for simple button, this is > really not about selectors. Of course, more DOM elements means more memory. But I would say it is not just normal but plainly unavoidable that complex applications take up a lot of memory. OTOH, more memory shouldn't impede speed. To give you an example: we have an app which uses probably several hundreds of widgets (nobody ever counted, I just made a quick estimate), and, the last time I looked, it creates quite a few thousands of DOM elements. However, it uses lazy initialization of each UI element (which is what I'd do in a rich client desktop app too). As such, almost no element is created when the application loads, and after startup elements are created only when they are needed. Once created, they are never discarded, unless the application is closed. While mem usage increases as more and more parts of the application are accessed, and more DOM elements are created, the speed of the application remains constant. Even when all parts of the application were accessed, and the browser east up to half a gig of mem, the speed is still the same as when the application starts. > 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). I don't know about that. Classic, mostly static web sites aren't that hip anymore. And more and more apps go web. Since qooxdoo seems to be the one and only beast of its kind out there, I guess it has no other chance than spread. Just the other day a colleague who has previously worked with JSP told me what she thinks of qooxdoo: you do the same thing ten times nicer and twice as fast in half the time, when using qooxdoo and JSON-RPC instead of JSP. From my experience, it's about the same with ASP.Net, struts, tapestry, JSF or whatever. Maybe it's half as much of a difference with wicket, but wicket has a much smaller widgets library. You can draw your own conclusion. > 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 don't think criticism is not welcome on this list, on the contrary. But simply restating that qooxdoo is slow because it creates too many DOM elements, and not giving an example of how this affects your app's speed can't get you much else than people telling you how they do it and that it works fast enough for them. Therefore, for me the question is still open: what exactly is it that works too slow in your applications? Under what circumstances? Maybe posting an example for the playground would help. Although I'm not a developer of qooxdoo, I can't imagine the developers being able to optimize qooxdoo for speed where you need it unless they can reproduce it. Nor can people on this list come up with suggestions for your speed problem unless they understand it. I suggested it before: you may be doing something in a different way that other developers using qooxdoo do it, which causes your speed problems. But unless you tell us about it, nobody can guess if there is indeed something you do differently, if it's just an application very heavy on the browser, or what other reason there might be for your problem. br, flj ------------------------------------------------------------------------------ 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
