I've been converting a lot of our internal code back to MochiKit instead of Prototype/Scriptaculous. I didn't mind use those two, so long as I took care not to use anything else. I was previously using Prototype/Scriptaculous pretty heavily with some lightweight / leftover use of MochiKit (1.2-ish), which at the end I was using primarily for sortable tables and custom table building widget (nothing too exciting, it just allowed adding / removing rows of textareas).
One day, I was playing with `zc.resourcelibrary` in Zope 3 as a means of dynamically managing / importing javascript and other resources based on items in use on a page. And it suddenly re-arranged my import order, which caused MochiKit.DOM's ``$()`` to overwrite Prototype's. But at this point, Prototype had added a lot functionality to node elements returned by $(). And so when MochiKit's $() replaced it, accidentally, code started blowing up. This was when I decided it might be good to go back to pure namespaces. I suddenly stopped liking how Prototype was extending every core object within Javascript. Sure it's cute, and if you stay within a closed universe it can actually be quite useful. On top of that, I was growing disgusted with the memory leaks in the event system, and when profiling some of our code I noticed some idioms that I had adopted that were wasting resources, significantly. So I started moving back to MochiKit 1.4; I turned off the exporting of names. I started using MochiKit.Signal and fell in love with MochiKit.Iter all over again. Now I'm at a point where I'm wanting a couple of widgets. I'm impressed with where Dojo stands now, compared to a year ago when using Dojo was an excercise in frustration. I'm also impressed with YUI. Dojo may win out as it has a so-called 'rich text editor' which actually seems to work in Safari, and I'd love to kill off our (customer's) dependence on TinyMCE. I also like that MochiKit is written with Dojo's packaging system in mind. Being able to defer loading of rarely used modules until absolutely needed by particular widgets on particular pages is still something I'd like to bring under control. BUT! At that point, what starts getting redundant? I love MochiKit.Signal, but Dojo and YUI have their own event system. I've fallen back in love with MochiKit.Async, but again both Dojo and YUI have their own XMLHttpRequest-handling systems. I know that Dojo has taken on more than a few elements from MochiKit, but in their own code/ hierarchy. Is it possible to be a MochiKit user most of the time, and a Dojo or YUI user some of the time? Or would it be the other way around? I could imagine going with Dojo/YUI and changing our use of MochiKit to be more limited to things like Base, DOM, Iter, and maybe Style, and for Events / XMLHttpRequest ditching MochiKit and going to whatever big-widget-toolkit offers. Does anyone have any experiences to share? I'm looking for stories about collisions (event management systems bumping in the night; name collisions), performance, load time, good combinations (what parts of MochiKit worked out best with another library; or just what other widget-y libraries have worked well with MochiKit), bad combinations, etc. Thanks, Jeff Shell --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "MochiKit" 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/mochikit?hl=en -~----------~----~----~----~------~----~------~--~---
