Hi Thomas, I don't know if some of your arguments are valid. Qooxdoo is different to all javascript libraries available. I'd like to say here that qooxdoo is not java and it will never be. Qooxdoo packages are not needed at all and I don't know if restricting users to have exactly "one" politically correct file structure is right. How others are doing it? Others which are using dojo, extjs or smartclient? There are using packages too, but conception is different.
Also the one-big-js file is not so big as it seems. How many qooxdoo classes are compiled in usual qooxdoo application? Qooxdoo all-in-one is about 1.2MB. My experiences are that if you use table, list and tree widgets then qooxdoo size will grow up to about 1MB. 200kB is really not big price to have comfortable debugging, deployment, and to not worry about qooxdoo-generator. > What about the people we lose *because* of the single file, as they say > "Uh, qooxdoo is *so ridiculously fat*, you can't really use it!"?! Qooxdoo is fat, you should make peace with it;) Best regards Petr On Tue, Sep 14, 2010 at 9:58 AM, thron7 <[email protected]> wrote: > >> Download one js big file, preoptimized as mush as possible, and play > with >> qooxdoo. No need for Python, no need for a build. > > You need to think this through. Where would application code go? As you > don't use the build system, you can't put it into class files under some > "source/class" root directory. So you need to put it into the > index.html, directly and all of it. And you need to order it correctly, > so that class > dependencies resolve. What about application startup? So you have to add > more code at the bottom of the class code that fires up qooxdoo's > application start. The use of own images will be impeded, as there is no > build step to create resource information for them. > > As you might see, this is an entirely different programming model. Maybe > this is still acceptable from your point of view, but who will support > this? Who will be guiding all the newcomers in the proper way to use it? > >> Now after few months, one can without changing a line of code switch >> to qooxdoo with a build and the same code will run more quickly. >> Isn't that great ? > > It will not work, as all of your code is in a single index.html. You > have to cut out the individual classes and put them into their proper > path, matching name spaces. Yes, it's doable, but when will you do it, > given that the application has long been put into production? When you > have 20 application classes? 30? 50? > >> Unfortunately, you currently have to bother with python toolchain >> even before you know qooxdoo is cool. That's one big reason that, I >> think, prevent a better qooxdoo adoption. > > What about the people we lose *because* of the single file, as they say > "Uh, qooxdoo is *so ridiculously fat*, you can't really use it!"?! > >> no. I think qooxdoo would have better adoption with an optional >> build > (python >> or not). > > One thing I personally would find as interesting as a single big file > would be an online build service :). > >> do like us ;-) To be honest, there is a link : that qooxdoo big file >> would be what we want to speed up the overall thing. > > We've been through that, and I tried to tell you that I wouldn't expect > much performance gain from that, but never mind. > > And if you are so convinced, why don't you just do it?! The means are > all there. Go ahead, create your single qooxdoo library, and then tell > us what the outcome was. > > 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 > ------------------------------------------------------------------------------ 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
