Hi all, Re: "One big build file" - when you develop on a local disk, this is much less relevant than when you use a web server backend. There are over 400 files in an average application and each one causes a request to the server; if I refresh the app I'm working on now there are 474 requests, 99% of which are "304 not modified" responses.
This adds up to 15 seconds of network comms for source builds, and is frustrating - in this case it would be much better to have all Qx scripts as a single or a few files (ideally defined by config.json). It probably makes Qx look really slow and clunky when you first use it. John On 13/09/2010 17:59, "Jean-Baptiste BRIAUD -- Novlog" <[email protected]> wrote: > >On 13 sept. 2010, at 18:47, Stefan Volbers wrote: > >> Hi Jean-Baptiste, >> >> if I may intercept in this discussion: >> >Sure, you're welcome ! > >> I don't believe that qooxdoo'd get a better 'market share' if the >>python >> build system'd disappear. >Optional rather than mandatory like now. That's all I would like. >I don't want the build to disappear. >How would we have the optimized version then ? >> You may not know that prior to qooxdoo 0.8 (or was it 0.7?) the build >> system relied on 'make' instead of python, which was a disadvantage for >> the windows platform, as one had to make use of cygwin to get access to >> gnu make asf. >I was thinking about a version of qooxdoo that doesn't need build at all. >Make is not a good choice for qooxdoo, as you said, its a problem for >Windows. >Only multiplateform should be OK. >Python is fine as long as there is a way for newcomers to avoid any build >at all. > >Download one js big file, preoptimized as mush as possible, and play with >qooxdoo. >No need for Python, no need for a build. > >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 ? > >*** No constraint to start and the power just when you need it. *** > >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. > >> >> I cannot tell whether qooxdoo's adoption significantly increased since >> switching to python (or even dropped). In fact, I don't really care, as >> I can see the advantage of using qooxdoo, and myself, I am gonna adopt >> the build system anyway. >> >> Regarding the discussion so far: >> You claim that qooxdoo has bad adoption since it makes use of a python >> build system; >no. >I think qooxdoo would have better adoption with an optional build (python >or not). > >> also you claim the build system is too slow for your work >> flow. >That's true for us but it is another discussion since "we are special". >Even if I'm French, I hope I'm not arrogant enough to ask the community >to 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. > > > > > >-------------------------------------------------------------------------- >---- >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
