[ng-dhtml] putting the build tool thing to bed

Alex Russell alex at dojotoolkit.org
Tue Sep 28 13:28:32 CDT 2004

Hash: SHA1

On Tuesday 28 September 2004 9:35 am, Tom Trenka wrote:
> [snip]
> >Yes. The original NW single-core-file build came about as a result
> > of profiling (mostly done by MDA) 


> OK.  I can see that.  Was this profiling done using Apache, or did
> he do it with multiple server configurations?  I'm not doubting the
> results here (one can notice the issue you're talking about with,
> say, any of the Bindows example apps for instance), but this is a
> major, major architectural decision that looks like it will
> determine quite a bit of the actual development approach...

So I'm going to leave the webapp performance tuning and metrics 
tutorial to MDA as he's the recognized expert in the field among us. 
Regardless, multiple performance profiling experts have independently 
verified this as a non-trivial source of latency for projects I've 
been on, so we're going to deal with it.

> >Likewise, on the product I've been working on for the last 9
> > months (PowerAnalyzer), much work was done in order to ensure
> > exactly this: that initial HTTP requests were always gzip
> > encoded, that as few subsequent 200/ok were required later on,
> > and that overall latency was reduced by putting things into
> > externally referencable (cacheable) files. HTTP overhead isn't
> > the only thing in play here, but given the option of having our
> > users put 30 <script url="..."/> tags in their page in order to
> > get fast caching and good ordering (and thereby removing
> > dependency satisfaction from the purview of the toolkit),
> > allowing the toolkit to manage dependencies inefficiently, or
> > still allowing the toolkit to manage dependencies yet be
> > contientious of network resources, I'm going to choose the 3rd.
> Are you assuming here that dependency file loading would be done
> using the script tag append method?  

With whatever is available in the environment. For CLI environments, 
that's very often load(["url"]), in the browser, it's usually 
document.write() (or after onload, document.createElement("script")) 
or an eval of an XMLHTTP fetch response. How it works under the 
covers is somewhat immaterial. What IS important is that we be able 
to use the toolkit in testing without needing the build environment, 
but that when you DO make a build, that it can help you optimize for 
your particular common dependency set (as well as other env-specific 
things like namespace prefixing).

> I did have quite a few issues
> with that (especially when there was a firewall involved), and
> ended up using document.write, which (IIRC) caches the file in
> question as well (since it becomes part of the document).  No? I
> don't see any reason why we need to wait for onload to load
> required files, after all...

I guess I don't recall ever suggesting that it was necessaray in a 
browser environment. Perhaps I mis-spoke.

> [more snip]


> >> As I've mentioned before, I solved this already for f(m),
> >> without using anything on the server beforehand.
> >
> >Are you building docs from source? Are you running automated unit
> >tests? What shell does your tarball/zip creation code rely on? Or
> > are you doing all that by hand?
> By hand, and I was referring here only to the loading dependency
> issue, not the doc generation or testing framework.  I did not
> build docs from source, and I created packages--by hand--using
> WinRAR.  Then again, I was not preparing or releasing f(m) as an
> actual, licensed enterprise SDK; I released it as a
> proof-of-concept.  So many of the concerns we have here with dojo
> did not apply to f(m).  Although they could.

And when they do, you and those you're working with are going to want 
a tool to make all that junk go away to as much of an extent as it is 
possible for everyone.

> [snip again]


> As long as we keep in mind that what you (the general you, not you
> specifically, Alex) might consider to be making your life easier
> may be something completely different from anyone else.  Which is
> really a major point I'm trying to argue here, for the most part.

So I want to make very clear that making my life easier isn't my only 
goal in Dojo, nor is it my motivating goal: my personal goal for Dojo 
is to produce a complete, multi-environment toolkit that allows 
people to develop rich app UIs with as little decision overhead as 

That philosophy (reducing the cost to decide to use Dojo) permeates 
this entire discussion, and it's the reason I'm going with Ant. It's 
the reason I want to generate docs from source ('cause it's the 
easiest way to get complete docs, which people need in order to 
choose us), and it's the reason why I'm paying attention to both mild 
users and huge deployments in the end-user scenario. If my goal was 
only to make my life easy, I'd be doing something other than this for 
a living = )


- -- 
Alex Russell
alex at dojotoolkit.org
alex at netWindows.org F687 1964 1EF6 453E 9BD0 5148 A15D 1D43 AB92 9A46
Version: GnuPG v1.2.4 (Darwin)


More information about the NG-DHTML mailing list