I'll pitch in my opinions: On 12/11/06, Kevin Dangoor <[EMAIL PROTECTED]> wrote: > Dojo has more features than any other JavaScript toolkit that I've come > across (it also has the infrastructure to support that -- flexible build > system, new inline documentation tool). Perhaps it's slower, I haven't seen > any quantitative comparison.
I love the dojo core (io, event, infrastructure) and some of the addons (storage) but am displeased with dojo.widgets. I've never been a huge fan of the invasive style dojo's widgets are based on, but I can live with that. What's soured me on the implementation is that every widget I've tried has been based on design decisions opposite to my preferences*. The goal seems to be implementing a windowing toolkit for any DOM/CSS environment. This leads to widgets that work poorly standalone but reasonably well together. The occasional widget I use from the library is usually very heavy due to the widgets infrastructure it's built on, integrates poorly with non-dojo elements on the page, is difficult to customize, and is often buggy (I'm looking at you, ComboBox). I generally wind up having to rewrite substantial parts of the widget in order to get something I'm happy with. As far as speed, I can't decide if dojo widgets are slow or if I'm not using it correctly. It seems to work well enough on the dojo site. I am currently fond of the YUI widgets, which I find to be very well written with design decisions I agree with. I plan on porting them to MochiKit at some point in the near future. * <soapbox> My philosophy is that we need to develop interaction patterns that work well on the web. We've been living with interaction patterns invented for a simpler computing environment. These patterns aren't necessarily the best patterns, but it hasn't been worth throwing away familiarity to experiment with new patterns. The rise of ajax apps gives us a clean break in user expectations and therefore the opportunity to invent new patterns. The next 3-4 years is a very exciting time if you're interested in interaction design. I'm not going to waste the opportunity by copying the desktop poorly. The humanized[1] blog provides more detail. He uses 'humane' like the python community uses 'pythonic'. I don't agree with everything the Raskins come up with, but I do agree here.</soapbox> [1] http://www.humanized.com/weblog/2006/11/06/web_20_is_converging_towards_the_desktop_good/ > MochiKit 1.4 (with either the Scriptaculous port or Karl's newer Animator > library) seems to do just about everything the others (proto+Scriptaculous, > jQuery, moo) do. jQuery has the CSS selector thing, but if it's truly useful > I'd imagine that Bob would consider a patch to add it to MochiKit. I believe that Bob has turned this idea down with the justification that MochiKit plays just fine with an external CSS Selector lib. I've been happy with Dean Edwards' cssQuery[2], but I'm not sure if it's the fastest approach anymore. I believe that the dojo.behavior implementation is still using Alex Russell's hack rather than Edwards' suggested improvements[3]. I glanced through the jQuery docs and they seem to be using the cssQuery (i.e. slower) techniques, though I didn't actually trace the code path. [2] http://dean.edwards.name/my/cssQuery/ [3] http://dean.edwards.name/weblog/2006/03/faster/?full > MochiKit's bigger, if you're using an all-in-one MochiKit.js, but MochiKit's > also modular if you want to use it that way. I need to get around to setting up a clever web page like mootools[3]. For downloading MochiKit. It'll still be big compared to other frameworks, but that should make it a good bit simpler to use modularly. [3] http://mootools.net/download/ As for jQuery vs MochiKit: I'll admit that I haven't used jQuery, but it does have a terse API and doesn't prototype hack, so it's worth a shot. The single page to collect all the addons is a particularly good move. On the downside, I do wish they'd chosen something with fewer conflicts than $. I'll have to experiment with using it for sprinkle-on-js pages since I like the API better than moo. MochiKit tackles some bigger problems (comparison, deferreds, signals) that are important to me when I'm doing client-side app development. I'm pretty happy with MochiKit for general use, but it is on the heavy side when all you want is just ___. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "TurboGears Trunk" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en -~----------~----~----~----~------~----~------~--~---
