I change the title so I detach myself to the discussion as explained in previous emails. I'll stick to the technical side.
Thomas, You asked good questions on the "all in one big file + build is optional" ideas. Here are some elements to try to answer as much as I can. On 14 sept. 2010, at 09:58, thron7 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. Yes. > 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. Why ? No build doesn't mean nothing, just no build, or more accurately : optional build. Optional build is not the same as no build at all. Why not put the code in class files in source/class folder ? All you need is a runtime mechanism to load that classes from that folder. I don't have the precise design in mind right now but it sound like doable. That mechanism would be enabled only when build is not used. this is very important the same code could be used with or without build. Otherwise, the optional build lack interest. > So you need to put it into the > index.html, directly and all of it. No. I don't like that and I think there is no need for arguments, it is obviously bad practice. > And you need to order it correctly, > so that class > dependencies resolve. I'm not sure about dependencies. What about a class A that use a class B that use the class A ? With current build, how this is addressed ? > What about application startup? Will be slower without build than with build, you can't have all the advantage. Without build you'll have simplicity, with build you'll get the horsepower. This would let people to get the horsepower only when they need it and after they checked qooxdoo is cool. Also, there are particular cases where no build is useful and cool. Leaving choice is cool too, when possible. > So you have to add > more code at the bottom of the class code that fires up qooxdoo's > application start. I think no with the dynamic loading mechanism. > The use of own images will be impeded, as there is no > build step to create resource information for them. > Not sure about images, what would be the problem ? > 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? > You already guide the newcomers in the proper way to use qooxdoo. You'll spend less time to explain the optional build way to use qooxdoo as it is obviously simpler than the build way of using qooxdoo. Only after yellow belt you would explain the build system. It will be quicker because yellow belt people would already know qooxdoo. More, white belt people won't have to bother with build at all. => less support. >> 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. Yes, it will not work with the bad assumption of all in index.html but that never was my goal. > 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? Let's clarify that point : no build is probably not for production. It will allow people to try, to test, to have freedom, to handle special cases (like us) : more flexible. Production constraint could be postponed after people check qooxdoo is the right choice. Then, when you are OK with qooxdoo tech choice, when you have some code to host, then only, you would use the build to optimize the resulting code. I think this is the best order to apply constraint rather than upfront constraint when possible. I know it is not always possible after more decades of programming. > >> 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!"?! > Why would you "loose" people ? Build is always there and always needed to have fit code rather than fat code. No worry, the no build is a new flexibility, nothing to remove. >> 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 :). This sound really interesting. What would produce that service and from what ? > >> 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. You don't have all the fact and data and I know what I'm doing. Anyway, this is only one little argument, the good reasons to have an optional build are explained before. > > 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. I started but need help, despite some innuendo on the ML, I'm not waiting without acting, you know that already at least from our contrib. ------------------------------------------------------------------------------ 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
