Hi Petr Is it just loading time that you find is so slow or after widgets have been created? If I have a criticism of Qx's prolific DOM elements, it's that they can be created before they are needed - EG if I have 10 tabs, then the widgets for all 10 tabs are created during startup which really hammers the browser...and it's especially annoying if the user doesn't need to use all the tabs. There is a work around of not adding the widgets until needed (tried by someone else here with good results).
However, I agree that Qx is not suitable for classic web pages or those with only a little user interaction - the risk of slow responses or compatibility problems in the case of ancient browsers isn't worth it for the simple stuff. But "simple stuff" excludes the rich UI layer of Qx which is where the performance hit comes in; IMHO it would be good if Qx could divide into the core [non-UI] components including a cross-browser event model, with the rich API as a second, optional layer. To answer your questions: >1. Is qooxdoo slow? Not once the app is running >2. Is qooxdoo tooling uncomfortable for you? No. I detect a force-refresh sent by the browser and re-run generate.py before the page is served back to the client so that Ctrl-F5 in FF does the work and I only switch between browser and editor. >3. Are you prefer improving the speed over features at this time (mature, >version 1.2, 1.3)? I'm happy to carry on using jQuery etc for simple pages for now because I see the Qx features and stability as giving more benefit - classic web development is no more crap than it has always been. >4. Do you using qooxdoo for classic web-pages (to add some rich >functionality)? Nope. John On 30/08/2010 15:46, "Petr Kobalíček" <[email protected]> wrote: >Hi devs, > >I know that the title is gutter, maybe everybody know about that, but >qooxdoo is probably the slowest javascript framework available. When I >started working with qooxdoo 0.7, I feel that it is slow (and not only >me, this mark was also from other js framework forums - ExtJS for >example). At that time there were plans for qooxdoo 0.8 that said that >it will be faster, less DOM elements will be needed for GUI and >architecture will be cleaner. > >I think that only the 'architecture' goal was finished. The number of >DOM elements needed for equal application to 0.7 version is higher and >this means that also browser performance will be worse. My experiences >are showing that number of javascript code is not problem. Browsers >are using JIT compilation and other very interesting tricks to make js >working as fast as possible, but problem will be always DOM - It's >hierarchic structure and each element is VISIBLE. > >If you don't believe me, try very simple task - Try to write efficient >AABB collision detection in C/C++ (each browser need it to be >efficient in DOM). In small qooxdoo app it's not a problem (1000 divs >are acceptable), but imagine larger application with tens of tabs - >you simply get DOM hierarchy which have 10000 or more elements, and >this can't be never fast. I have not calculated how many DIVs are >needed for one widget, but I think that 5 are maximum for efficient >framework. > >Now I'd like to write why this is getting to be a problem for me. I'm >using qooxdoo about 2 years and I learned to do some things with it. >The object model is nice, widgets are good designed and I'd like to >use similar model in classic web-pages. But I can't. The qooxdoo code >is huge, speed is unacceptable and using generator to minimize js code >is not possible (I can't imagine using this tool for web-pages). > >So I'm using different frameworks for web-pages and web-apps. Okay, I >do not need super rich functionality in web-pages, but it's time >consuming to work with different tools for the same runtime >environment. > >What about other developers? > >1. Is qooxdoo slow? >2. Is qooxdoo tooling uncomfortable for you? >3. Are you prefer improving the speed over features at this time >(mature, version 1.2, 1.3)? >4. Do you using qooxdoo for classic web-pages (to add some rich >functionality)? > >Best regards >Petr Kobalicek > >-------------------------------------------------------------------------- >---- >Sell apps to millions through the Intel(R) Atom(Tm) Developer Program >Be part of this innovative community and reach millions of netbook users >worldwide. Take advantage of special opportunities to increase revenue >and >speed time-to-market. Join now, and jumpstart your future. >http://p.sf.net/sfu/intel-atom-d2d >_______________________________________________ >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
