[dojo-contributors] response to James' proposal

[Tom Trenka]

I figured since there was an email thread response to what I proposed, I
should repeat the favor with others :)  So, without further ado, on to
responses to James' proposal:

A) and B):  Those are both great things, and I'm grateful for the work
you've done on it--its some pretty amazing stuff.

Allow me to clarify what I was saying about the build system, so that we're
all clear.  I *don't* have a problem with a build system being Java-based.
I'm not a big fan of Java but the reality is that I don't care--as long as I
don't have to think about, or get heavily dragged into, minute details to
install and run the system.  This is my primary criticism: the current
system is about as friendly as a bunch of Hell's Angels holding a variety of
bats, chains and crowbars.  I'm hearing now of 3 different efforts to
rewrite/rebuild the system, and all I can say here is that if it's not as
simple to use as that site for MooTools (or one of those kits, I don't
remember which one off the top of my head), we lose.

What I'd like to see is a build system that is:

1. completely self-contained and installable (if needed) in a single install
package, that is as simple as "click here to install".
2. about as easy to use as it can be.  In my mind, this means letting the
user (if this is a desktop prog) see a list of files, click on each one they
want to include in the build, and hit "build".  That's it.  (With additional
options that are settable, but not required to build something out of the
box).
3. If a website, present the user with a list of files that they can select,
and create the build for them.
4. If additional options/tasks are to be available, that it is as easy to
run as the build (thinking of unit testing here).

...the point here is that I'm not discussing implementation at all.  If we
go Java, that's fine--as long as it's self-contained and as easy to use as
something like Word.

re: the rest of the proposal:
I don't disagree with most of what you've written, although I don't think I
agree about the single CSS file concept.  You do make a good point about not
including Editor CSS; I'd almost suggest a compromise, where smaller CSS
definitions can live in a common file, but more complex ones can have thier
own (the editor in particular).  These are implementation details though; I
was hoping that we could start at a slightly higher overview level, and
drill into implementation details later on.

I also don't know that I'm talking about API differences as much as I am
about development approaches and philosophies...what I was trying to express
is that there is a definite conflict of philosophical approaches, and we
need to refocus ourselves in certain modules so that those conflicts
disappear.

I am also not talking about completely fragmenting the source into fully
separated libraries.  I'm suggesting that we make some primarily semantic
changes in the way we look at the code base, so that the *perception* of the
Dojo Toolkit is a lot more focused.  All the time I hear "what is Dojo", and
invariably people start pointing at widgets, then IO, and you can just *see*
(metaphorically speaking) the slight confusion in their eyes; you can almost
see the comic bubble over their heads saying "yeah, exactly what *is* Dojo,
anyways?"  Simply pulling modules out of the dojo namespace and into their
own would be enough of a change, or at least a beginning.  I believe pretty
strongly in containment (I wrote one of the first articles advocating the
namespace approach in JS) but I think we can--and do--take it too far
sometimes.  I don't want to overpopulate the global object with a lot of
variables either, but I think we can certainly allow for more than one.

I'll definitely agree with you that everyone wants fast, performant
widgets.  But I'd submit that exactly *how* performant is up in the air, and
that a lot more people would be willing to accept more features for slower
code; and I'd suggest that fewer people are interested in interface design
than we'd like to believe.  Not everyone is working for a company that is
creating web-based products; there's a huge audience out there developing
applications for internal use that has no need for extensive pixel-pushing,
and the Dojo widget system so far is *perfect* for this.

I guess the basic point here, for me, is *really* streamlining what we
have.  I don't care if it means refactor or rewrite, to be honest.  I would
like to make sure people are open to "rewrite", because I'd hate to see 5
rounds of refactor--only to realize that tearing down and starting again is
the only viable solution.

Hmmm.  This has turned more into a defense than a commentary; I'm sorry
about that.  I've several analogies in my head right now that are difficult
to get across without being in person, particularly since a number of them
are based in other disciplines...might be easier to do some of this
discussion at 3D2, if it goes.

trt
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.dojotoolkit.org/pipermail/dojo-contributors/attachments/20061211/fcc4bf7f/attachment.htm