So swapping http://js.arcgis.com/3.6/init.js for http://js.arcgis.com/3.6compact/init.js in a test application increases the amount of http requests by 75... from 132 to 207....yet the total amount of data transferred is 1.5Mb in both cases (the increased number of requests makes up for the smaller size of the build itself).
I believe this speaks to the broader issue that if the CDN is the promoted way to refer to the API, than there should actually be sensible build layers provided that use idiomatic Dojo build practices to reduce HTTP requests.
AMD is a dependency management system which lends itself to good building, but if you don't build AMD slows you down.
I think the JS API team may need to look harder at the issue of build layers and what is best provided by a CDN (ie 4-6 larger files vs. 150 small ones). Also, building small AMD files into layers can reduce them 5-10% just due to inlining, reducing total bytes sent. This would likely be a win for server load also, as there would be less concurrent requests to negotiate.
Alternatively, providing the uncompressed source or even putting the API on github would provide immense benefit to both developers and the API itself. I have fixed several bugs in my own uncompressed source (when it was accidentally released a view versions ago), and I'd love for an easy way to incorporate these back into the community. Doesn't get much easier than a pull request.
Anyhow cheers, and looking forward to more action in this area.
I seem to recall Derek mentioning in a JavaScript API session at the ESRI UC this year that they are looking towards developing something that only loads what your code requires. No timelines, of course..
So swapping http://js.arcgis.com/3.6/init.js for http://js.arcgis.com/3.6compact/init.js in a test application increases the amount of http requests by 75... from 132 to 207....yet the total amount of data transferred is 1.5Mb in both cases (the increased number of requests makes up for the smaller size of the build itself).
Right, use a smaller build of the API but loading the same modules will result in more requests to load the same amount of JS.
I believe this speaks to the broader issue that if the CDN is the promoted way to refer to the API, than there should actually be sensible build layers provided that use idiomatic Dojo build practices to reduce HTTP requests.
We're long overdue on this. We've occasionally discussed creating additional build layers and making those available but we never finalized exactly what we wanted to do so we never did it.
AMD is a dependency management system which lends itself to good building, but if you don't build AMD slows you down.
I think the JS API team may need to look harder at the issue of build layers and what is best provided by a CDN (ie 4-6 larger files vs. 150 small ones). Also, building small AMD files into layers can reduce them 5-10% just due to inlining, reducing total bytes sent. This would likely be a win for server load also, as there would be less concurrent requests to negotiate.
Alternatively, providing the uncompressed source or even putting the API on github would provide immense benefit to both developers and the API itself. I have fixed several bugs in my own uncompressed source (when it was accidentally released a view versions ago), and I'd love for an easy way to incorporate these back into the community. Doesn't get much easier than a pull request.
Anyhow cheers, and looking forward to more action in this area.
The next thing that's going to happen in this area is a web app that will let you build custom versions of the API (the plan also includes an option for Esri to host your build(s), but you can also download and host yourself). This is what Steve (evtguy) is talking about when he mentioned stuff I talked about at the UC this year. No public timeline on this yet.
The API will not be in a public Github repo in the near future. If you've found bugs, please report them through support. If that's too much trouble, you can email me the bugs you've found and fixed: dswingley@esri.com.
