[ng-dhtml] putting the build tool thing to bed
alex at dojotoolkit.org
Tue Sep 28 13:28:32 CDT 2004
-----BEGIN PGP SIGNED MESSAGE-----
On Tuesday 28 September 2004 9:35 am, Tom Trenka wrote:
> >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 at dojotoolkit.org
alex at netWindows.org F687 1964 1EF6 453E 9BD0 5148 A15D 1D43 AB92 9A46
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (Darwin)
-----END PGP SIGNATURE-----
More information about the NG-DHTML