![]() |
Subject: Re: Dojo downloads, why not split in dojo/dijit/dojox Newsgroups: gmane.comp.web.dojo.devel Date: Wednesday 2nd September 2009 02:10:14 UTC (over 8 years ago) -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Micheil Smith wrote: > Adam Peller wrote: >> Can't we just include a layer with each distribution? Fine-tuning >> with the build tools is generally a good idea, but at least this would >> give a good default. Users who get hundreds of individual xhrs by >> default get a very bad impression of Dojo. > Something that could be done to about the amount of XHRs we make, is to > inform We don't have to make XHR's at all. > the user that no, we're not actually requiring heaps of downloads / > bandwidth, but > actually to make sure that they know that dojo is broken up into many > smaller files > for better code management whilst developing. We are distributing something in hundreds of pieces and then asking the user to wait while it assembles itself on each load. And I don't see this leading to better code management for the user (it is handy for us behind the scenes, of course). There are two ways to improve and they are not mutually exclusive: an online builder that delivers a single file or a much faster ad-hoc loading process (which has been developed). > > As for a build tool, it'd be a great idea to see someone write a > modified version of > shrinksafe / buildutils that actually builds a copy of dojo.js and > compiles together > the individual require()'d files, so that if you're using say.. > dojox.grid, you'd have a > resulting file: dojox.grid.min.js and then just tell the require() > method that this is > were all the code to dojox.grid.* is, so it only requires one file. This > could be done > with the help of some sort of file index (read maybe manifest), which > could be > placed into the top of dojo.js ISTM you are describing the current builder, but I could be missing something. And I don't see the need for extraneous meta data. The builder shouldn't need any (and doesn't AFAIK). -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkqd1AYACgkQWSc16XLwaR0pUACfUhYjVvkVAHs//tBOL1EoeL/w RLcAoMtstjKD/dJ3rJWGFKY4VrMi5ik6 =T8rn -----END PGP SIGNATURE----- |
||