[dojo-contributors] Module formats for the browser

sam foster potatosculptor at gmail.com
Thu Mar 25 21:00:10 EDT 2010


Why is the server-centric project (where pre-processing/macros are the
norm) requiring the client-centric projects - where static,
non-processed files are the norm - to twist into funny shapes to
support this module format? Seems topsy turvy to me. It would be nice
to be pulling together, but lets keep this project's goals front and
center and build compatibility bridges where it makes sense.

>> but I believe there are several key reasons this is advantageous:
>> * All Dojo modules can be CommonJS compliant modules, and easily be
>> reused on any CommonJS platform.

While I see that this would be cool, and who knows maybe this will
turn out to be critical for the continued relevance of dojo. But right
now with how we've defined the focus and mission for dojo - this is
not a key advantage. Lets look at the use cases we need to support as
a toolkit, and the new emerging challenges (such as the increased
module granularity it looks like we'll need for viable mobile builds)
and see what problems we have that need solutions. Going into 2.0 is a
good time to re-evaluate the project mission and perhaps ditch some
sacred cows. If commonJs compliant modules gives us good leverage in
that perspective its worth considering. Otherwise this seems like a
solution that needs a problem to solve.

> But the dojo user's modules may not be CommonJS-compliant. It feels like
> we are setting up a "class" system where the user's modules are inferior
> or require extra work to reuse. I think one of the powers of Dojo's
> codebase is that we use the same tools, the same widget base classes as
> dojo users. Treating their code as "other" does not sit well with me.

I also think this is really, really important.

> This feedback is a bit strongly worded, ...

Its a bold proposal and warrants equally bold responses.

/Sam


More information about the dojo-contributors mailing list