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

Tom Trenka ng-dhtml at dept-z.com
Tue Sep 28 09:55:49 CDT 2004


>By including in your distribution package only what you need. Sure, 
>you can manually cat all the file togeather (and hope that all the 
>dependency satisfaction code still works right), but it's a much 
>eaiser thing to get right inside the build process.
>
>And so now you ask why I'd want them all in one file? Becuase HTTP 
>setup/tear down is a significant cost, and we're all about reducing 
>adoption costs. We will be providing a "standard" set of files 
>packaged togeather, but it even makes that easier to do it through 
>the build process.

Do you have proof of this?  You've mentioned this before.  I've personally spent a year in coding hell, dealing with a system that was predicated on that exact assumption; so instead of pushing just what was needed down the pipe, they shoved all of it at once--because they were overly concerned about HTTP socket setup and tear down.  And never once did I see any definitive proof that pushing something all at once, down one socket connection, is more efficient than letting the browser mechanisms in place handle that.  In fact, I showed said "persons responsible for creating that hell" on several occasions how bad the performance of what they did was, and how much better something performed when it was written using the basic interfaces given already (i.e. loading something by just putting the damn element in the HTML document).  In some cases I actually got something like a 500% increase in performance over what they were doing, simply by using the given mechanisms and doing most of the actual comm asynchronously.

I'm not saying it isn't a nice option.  I'm saying that it's unnecessary, and would fall under a "nice to have" category as opposed to a "requirement" category.

>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.  There are going to be name dependencies no matter what happens, no matter how hard you try to avoid it or apply a set of tools to minimize it.

IMHO, *any* dependency on a tool that is *not* JS-based (and therefore truly portable) is a BAD thing (TM).  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.

And I'd be real leery of trusting a custom build that didn't have it's own regression testing for that particular build configuration.

Just some thoughts.

TRT
 
             



More information about the NG-DHTML mailing list