[dojo-contributors] Prototype-al simplicity

Tom Trenka ttrenka at gmail.com
Fri Apr 7 12:56:13 EDT 2006


Dylan--agreed.

RE: dom, style and html; I was mentioning to Paul that some of what has been
placed in style.js (ok, the majority of it) is actually HTML-specific; I had
enough issues with it when writing svg.js that I ended up duplicating some
functionality there so that I could use it correctly.  Lots of stuff in
style should really be moved to html (I'm thinking in particular of box
model and measurement functions).

Also, at the risk of being contrarian to Dylan (I'm not but the suggestion
I'm about to make may have performance implications), might I suggest that
we don't split out functions that are obviously related, and simply return a
more informative object as the result?  For instance, instead of:

getViewportWidth getViewportHeight getViewportSize...we'd have this:

object getViewport

...where the return object would look like:
{ width:..., height:..., size... }

...and more in that vein?  I wouldn't have performance figures on that one
right off the top of my head, but getting information like that in one shot
as opposed to several will probably offset performance issues, if used
correctly.  From what I'm seeing, this kind of approach would also eliminate
an awful lot of code, particularly within style and html...

On dojo.io, the only suggestion I might make is to maybe pull the back
button handling into a separate, optional mixin?  Seems to me that even
though it's large, there's a reason for it--and with that one I'd hate to
pull any functionality to make it smaller.

trt


On 4/7/06, Dylan Schiemann <mail at dylans.org> wrote:
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Alex Russell wrote:
> > On Friday 07 April 2006 7:42 am, Paul Sowden wrote:
> >> On 7 Apr 2006, at 04:09, Bill Keese wrote:
> >>> How come it's so much bigger?
> >> Ok, here's an initial size breakdown: <http://dojotoolkit.org/
> >> ~psowden/dojolite.html> (DOM (Gecko!), please)
> >>
> >> Seems like dojo.io is the biggest offender.  It also looks like all
> >> the modules need squeezing to achieve results so I guess it kind of
> >> confirms the size problem is institutional.
> >
> > So one interesting result is that we can drop the dojo.graphics.color
> > dep entirely if we don't provide dojo.style.getBackgroundColor. Nothing
> > other than the effects namespace uses it in our code anyway.
> >
> > Should it be (re)moved?
>
> One thing we really need to keep in mind is that Dojo's use of an
> internal API should not be the only measure of whether or not something
> should be part of Dojo.  If it is a useful utility for people developing
> Dojo apps, then it is needed somewhere, perhaps just not with the Dojo
> core distributions.
>
> Also, in the case of Dojo, bloat and performance are not always tightly
> coupled.  We should be evaluating performance issues as well as bloat
> using our profiling capabilities, because frankly performance is even
> more important than bloat.  I don't mean this to stomp on all of the
> great effort people are putting into this.  I'm just saying, performance
> should not be overlooked in this review process.
>
> - -Dylan
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.1 (Darwin)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iD8DBQFENpbe8nLgh/JJsxERAnZRAKCebr9ryTpWpaWLGqtXFeAVI3DwUgCeLgjt
> imZQPedXlahzc7t3sEA5FjU=
> =V3i9
> -----END PGP SIGNATURE-----
> _______________________________________________
> dojo-contributors mailing list
> dojo-contributors at dojotoolkit.org
> http://dojotoolkit.org/mailman/listinfo/dojo-contributors
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.dojotoolkit.org/pipermail/dojo-contributors/attachments/20060407/c28f1533/attachment.htm 


More information about the dojo-contributors mailing list