Jeremy, > ...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).
I consider myself a decent JavaScript programmer (i.e. I know how to write it pretty well *without* a library like MK) and don't see that there really are many things that need improvement, to be honest. Maybe I am not doing enough interesting JavaScript hacking (I write it most every day though), but there are few things I end up adding to my projects that I would consider general purpose enough to end up as part of my personal JavaScript toolkit - are there some? Why yes. Are there things that might be a good fit for MochiKit? Yes, quite possibly. If they were rejected, would I get ticked off? Probably not - I recognize that everyone has their own styles, opinions, preferences, etc. and don't expect others to find value in the same things I do. I find value in discussions about politics, but I have many friends that don't - it doesn't mean I don't value their friendship or that I quite hanging out with them. > >> Is the lack of development necessarily indicative of a problem? > Absolutely, the health of any open source project is measured by it's > activity. According to whom? I think this is poor rhetoric - MochiKit is mature, and thus needs no more development. The human body reaches a point of maturity, at which point it stops developing - we don't continue to increase in height as we get past a certain point in life. Why should MochiKit be a busy hub of activity all the time? Activity does not necessarily mean meaningful growth. > >> what things is it missing? > Well there are two just in this thread alone: chainability and > additional element methods. The fluent interface is a preference, it is not necessary and I don't feel buys much of anything. > Another great example from JQuery is the onDOMReadyState pseudo-event. I second what Bob said about this, both about the value of it, but also about the fact that, if you want it, submit the patch. Do you expect to be able to simply walk into a place, offer the suggestion, and have it done for you? Open source thrives on *actual* contributions - ideas are nice to have, but have little value until implemented. > 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. And I am willing to bet that if such a need arose today, MochiKit would shortly have such a feature - but your personal preferences for aliases, the onDOMReadyState pseudo-event and a fluent interface hardly qualify as being in the same class as an XmlHttpRequest abstraction. There are some major qualitative differences there...apples and oranges. > >>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). "Hundreds," huh? Doubtful. And as for the "plug-in mechanism" you are referring to, I again point to Bob's comments. This is JavaScript after all, it isn't too hard to add your own code. I don't even understand what you are getting at with this comment, it is almost a non-sequitur. > >>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. Again, there must be someone to do the work - what work have you done as a means to your suggested ends? > 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. Well, here there are not as many users, so that group of "several different interested users" becomes maybe one or two here - and you were one of them. Why didn't you implement it? I would love to hear your answer. > this [group] categorically denies the possibility of anything that > doesn't personally appeal to you or Per. Nice of you to include me on the decision making process, but I don't have anything to do with that other than being a regular member of this group, no different than you. > 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. I think when you say "improvement" in this last statement you mean "changes I want, which I also want you to implement," because improvements do seem welcome here to me. And by the way, "if it ain't broke don't fix it" is a wonderful policy, as far as I am concerned. > I want a framework that takes advantage of all the latest developments > in the world of JS. You do know that the last official changes to the ECMA spec were made in 1999, right? Until another is made and there is wide-spread adoption, I don't see there being any "developments in the world of JS" in the way that you seem to imply. And again, if there are useful things that somehow come about, as earlier alluded to in the comments about the XmlHttpRequest abstraction, I am certain the few of us that use MochiKit will make sure such features are implemented. > That framework isn't Mochikit. Well, "hasta la vista" then - hope you enjoy using jQuery; may it be everything you, and the thousands of other people using it, want it to be. Who knows, maybe someday I will be using it as well - only it will not be because I feel MochiKit has grown stagnant or because my ideas aren't implemented; rather, it will be because of a conscious choice based on an actual need. Jason Bunting --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "MochiKit" group. To post to this group, send email to mochikit@googlegroups.com 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 -~----------~----~----~----~------~----~------~--~---
