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

David Schontzler schontz at gmail.com
Tue Sep 28 00:12:54 CDT 2004

I was sorta wondering the same thing, re: building interpreted code. I
was kinda assuming we were talking about doing things like removing
line breaks and/or combining files. I guess I wouldn't much like
installing Java+Ant+SVN+Python+Docutils+Rhino just to combine files

So what exactly is the planned use of the build tools? What's being built?

On Mon, 27 Sep 2004 23:54:33 -0500, Tom Trenka <ng-dhtml at dept-z.com> wrote:
> > Martin Cooper wrote:
> > |> Whoa. I can see the docs now: "To build Dojo yourself from source,
> > |> first install Subversion, Java, Ant, Python, Docutils and Rhino.
> > |> Then, on the following week, ...". ;-)
> >
> > Well, there's a difference between different user types:
> >
> > - - maintainers of the project
> > - - contributers to the project
> > - - people who want to hack on the code, but don't care about
> > the docs and build system
> > - - users who grab a copy of the built code and markup
> > widgets using xml.
> >
> > So most of these tools are to make our lives (maintainers and
> > contributors) easier, and are unnecessary for most "users".
> Forgive me for sounding stupid here, but I think Martin has a point.
> *We're talking about Javascript here*.  Personally, I'm not really
> convinced that we're not getting extremely "tool-happy", and I'm
> also not convinced about the need for server-side development
> in conjunction with the kit.  My feeling on this discussion (to date)
> has been to keep my mouth shut, since most of the devs here seem to
> be a lot more familiar with these development tools than me...but
> I have to say, I haven't had many problems doing high-powered dev
> using 2 tools: VI and a browser.  (I'm not just talking about JS
> here, but also ASP, ASP.NET (although the debugger in VS.NET is
> pretty handy), PHP, Cold Fusion, Windows Forms (same thing about
> the VS debugger applies here), etc. etc. etc.
> Source control, yes.  A test framework; ok, although I'm still of
> the opinion that it's more work than necessary. But to force a
> typical user/dev to learn *all* of the same tools that we are
> talking about using seems to be a bit much.
> Especially for an SDK that is completely interpreted, and not
> compiled.
> Does this seem unreasonable?  Frankly, if I were someone looking
> for a robust JS SDK, and I took one look at what I'd need to even
> begin using it, I'd hit Google again and look for something else.
> Having to learn all of these tools (even in part, to be a contributor)
> seems like a very high learning curve.  I feel embarrassed even now
> that I have to keep bugging Alex for "after school classes" just to
> get up to speed on the Source Control system; that I have to have
> head-butting arguments with Joyce because I can't quickly follow
> something like s9y well enough to know that it's extremely flexible...
> etc. etc. etc.
> Now translate that to those who might want to actually dev with this.
> I'm sorry guys, but SDKs don't get adopted because they are powerful.
> They get adopted because someone with relatively little experience
> can pick it up quickly.  I've made a career so far on picking things
> up quickly; if I'm struggling (and we haven't even written any code
> yet!), what does that say about, say, a Flash guy with no formal training
> needing to move his/her work to the next level?
> ...I'm not sure how I got back on hammering on this topic again...probably
> because I have neopyhte-ease-of-use-UI-design on the brain (Alex knows
> what I'm referring to here)...sorry for the rant.  But I would seriously
> prefer to keep the use of tools to the absolute minimum.
> Exactly why is it we need a build tool for an interpreted API again?
> _______________________________________________
> NG-DHTML mailing list
> NG-DHTML at netwindows.org
> http://netwindows.org/mailman/listinfo/ng-dhtml_netwindows.org

More information about the NG-DHTML mailing list