First off, I do <3 Mochikit. I wasn't trying to bash it, I just
wanted to share my opinion of it with someone who seemed to be in a
similar position.
>> part of the reason changes are looked at with suspicion is because
>> a lot of suggestions are not in keeping with the intent of MochiKit.
Suspicion is one way to describe it; I'd lean more towards "outright
hostility" (although said hostility is generally civil and polite,
which is more than I can say for a lot of lists). And as for the
intent of MochiKit, I thought it was to "make JavaScript suck less."
It does that to some degree right now, but do you really think it's
impossible for JS to suck even less? I don't (JS sucks a lot, and I
say that even though it's one of my favorite languages).
>> Is the lack of development necessarily indicative of a problem?
Absolutely, the health of any open source project is measured by it's
activity. As a JS implementer I need to know that the (JS framework)
horse I bet on is going to respond to my future needs in a timely
fashion. I have great confidence of that with JQuery because it has
an extremely active development community; try comparing the activity
on their list:
http://groups.google.com/group/jquery-en?lnk=srg
to the activity here and you can see why I don't have similar
confidence in Mochikit. Alternatively you can compare the membership
of the groups, the # of Google results for searches on "MochiKit" vs.
"JQuery", the # of commits to either library in the last year, ...
whatever metric you use, Mochikit always comes in last compared to not
just JQuery, but every other major JS library (prototype, YUI, dojo,
etc.) as well.
>> what things is it missing?
Well there are two just in this thread alone: chainability and
additional element methods. Another great example from JQuery is the
onDOMReadyState pseudo-event. But again, it's not just the feature by
feature comparison between frameworks that matters; five years ago I
could not have predicted the need for an XmlHttpRequest abstraction,
but that's obviously a very essential feature for a JS library today.
If my company had adopted some framework based solely on it's feature-
set back then, and that framework had never added an XmlHttpRequest
abstraction, I'd be up a proverbial creek without a paddle. I'd have
to convert all of our code to use a new library or else use two
libraries (and have a giant download footprint); either way I'd be
kicking myself for not choosing an actively developed framework.
>>I don't see the library itself as missing anything.
There are still hundreds of opportunities to make JS suck less, but
Mochikit is missing all of them while libraries like JQuery either
respond to them directly (by adding new stuff to the library) or
indirectly (via something like JQuery's plug-in mechanism).
>>Is this because they wouldn't add a few aliases for you?
Hardly. I personally have proposed not just that but several other
enhancements, and of course I'm not the only one who has made
suggestions, yet almost no improvements have come out of any of that
feedback.
Contrast my thread proposing an onDOMContentReady pseudo-event here
(my most popular suggestion ever) with the similar thread in the
JQuery group. Here I got "that'd be cool if you do all the work and
submit it ... but if you don't the idea will die with you" (and due to
my disenchantment with MochiKit, it did).
In contrast, that group had several different interested users who
came together, discussed the technical merits and disadvantages of
various implementations, and then ultimately added a very cool feature
their library. That never would have happened if the JQuery admin(s)
had created a culture of fear surrounding changes. There is a world
of difference between how that community responds to new ideas (even
the ones which are ultimately "shot down") and how this one
categorically denies the possibility of anything that doesn't
personally appeal to you or Per.
Of course I'm exaggerating a bit, but still the leadership of any
community sets the culture of that community, and here the culture is
"if it ain't broke don't fix it." That sort of culture is great for
stability, but it's not very conducive to improvement.
Ultimately, Mochikit is good enough for you and your company. That's
great, but I'm not going to bet my company's JS future on your
company's needs. I want a framework that takes advantage of all the
latest developments in the world of JS. I want a framework where new
ideas are welcomed and entertained, even if they are later ultimately
rejected. I want a framework that is constantly seeking to make
JavaScript suck less.
That framework isn't Mochikit.
Jeremy
On Aug 26, 3:34 pm, "Jason Bunting" <[EMAIL PROTECTED]>
wrote:
> Jeremy,
>
> > Mochikit is VERY resistant to change, and if you try to suggest
> > changes people will basically tell you "why don't you go use that
> > other library if you like their features so much."
>
> I think the fact that MochiKit is resistant to change is a Good Thing - we
> can't make changes for every Tom, Dick and Harry that think it needs some
> feature. As far as I can tell, part of the reason changes are looked at with
> suspicion is because a lot of suggestions are not in keeping with the intent
> of MochiKit.
>
> > As a side note, that line of thinking (coupled with the lack of any
> > real development) has convinced me that Mochikit is far too stagnant
> > for my company's business needs. As a result, I'm currently in the
> > process of researching how to migrate us to jQuery.
>
> Is the lack of development necessarily indicative of a problem? When fruit
> matures on a tree, it stops development and is picked and eaten. I think
> MochiKit is mature and I have absolutely no problems with it, what things is
> it missing? I rarely find things I need that MochiKit doesn't already
> provide (unless, of course, you are looking for widgets and such).
>
> > So, I don't mean to be yet another voice saying "give up and go use
> > jQuery", but in my experience that path will be MUCH more rewarding
> > than trying to convince the Mochikit maintainers to change ... well,
> > anything.
>
> Is this because they wouldn't add a few aliases for you? If so, that's a
> poor reason to leave. I am really curious as to what you see missing -
> granted, a better community of users would be nice, as far as developing
> reusable widgets and such (I develop niche stuff and have to roll my own
> regardless), but other than that, I don't see the library itself as missing
> anything. As your last goodwill effort, provide some useful feedback.
>
> Jason Bunting
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
