[ng-dhtml] putting the build tool thing to bed
ng-dhtml at dept-z.com
Tue Sep 28 11:35:30 CDT 2004
>Yes. The original NW single-core-file build came about as a result of
>profiling (mostly done by MDA) which identified the multiple fetches
>(and more tellingly, the requests to check if-modified-since) as a
>major source of latency in app response. Given that onload can't fire
>until the browser knows that everything that is relevant to the
>display of the page (or thereabouts) is correctly gathered, reducing
>the ammount of HTTP overhead in order to get this done was a
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...
>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? 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...
>> > Essentially, unless you've done the release engineering on
>> > something like netWindows or burst, it's hard to grok how much
>> > goes into getting the right things in the right place in the
>> > right order. Build tools make that a process that I need to get
>> > right only once. This is a Good Thing (TM).
>> 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.
>> The strength of
>> what we're talking about doing is that it truly *is* portable,
>> without anything but a host application...the only way I personally
>> wouldn't have a problem with it is if all of these tools did the
>> builds/doc gen/etc on our server, accessible through a web browser,
>> as a customized build download tailored to the supposed developer's
>> needs (and the developer didn't have to know any of those tools,
>> there'd be a decent UI there to aid the process). And I would be
>> very leery of requiring any contributor--invited or not--to have to
>> learn a complete suite of tools just to contribute, say, a bug fix.
>I think that goes into my nice-to-have category. I'm very concerned
>with getting people up-and-running quickly (hence my decision against
>Make). OTOH, I do assume a base level of competence. Everyone on this
>list today is more than past that level, yourself included. I'll
>worry about the average programmer's ability to easily build the core
>when the average programmer starts producing high-quality patches for
>it. Until then, the average programmer gets my sumpathy when they
>start to use the toolkit, and we (non-average programmers) get my
>sympathy the rest of the time. I'm doing Dojo to make my life better
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.
More information about the NG-DHTML