On Tue, Aug 26, 2008 at 6:34 PM, machineghost <[EMAIL PROTECTED]> wrote: > > 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).
Yes, it's certainly possible, but it does what we want it to do... if it didn't, you'd see a lot more commits from us. >>> 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. If you want something popular with a vocal community and lots of new developments, you're in the wrong place and that's been the situation for a long time. I don't think anyone here would try and convince you otherwise. >>> 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. Chainability probably is not going to happen, but onDOMReadyState certainly should at some point. If you really like chainability, you should probably be using jQuery. That's what it's good at, but I personally don't care much for that style. jQuery is a perfectly good library for what it intends to do, if it does w hat you want it to how you want it to be done, why not just use it? MochiKit is here because it solves a lot of problems that we had a couple years ago before jQuery existed. Were it around in 2005 I might've just used it instead of writing my own, but dojo and prototype were not really worth using at the time. I have no real vested interest for you to use MochiKit. I'm not involved with any kind of consulting, I don't intend to write any books, not particularly interested in speaking at any more conferences about JS, etc. It helps me and my company out when people contribute code, file bugs, etc. because this is the library we use. In other words, I don't really care if you use MochiKit or not. > 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). All JavaScript frameworks have "plug-in mechanisms"... you can add whatever code you want to the runtime system. From what I recall, jQuery's plug-in mechanism is just there to make it easy to inject things into jQuery's namespace such that it's chainable, which is not something MochiKit needs. MochiKit is more of a collection of libraries than a framework in that sense, because you don't need a plug-in mechanism, you just add more code. >>>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). If someone implements onDOMContentReady then the patch would almost certainly be accepted. If nobody implements it, then it won't happen. We're certainly welcome to it though. Clearly if we needed it bad enough then we'd have done it ourselves by now, but it's more of a nice-to-have than a need-to-have (at least for me). Ideas without code are only useful if there are bored programmers sitting around willing to write code for you for free; I don't think we have many of those here :) > 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. Then what are you still doing here? Surely your effort would be better spent on other mailing lists if you don't intend to contribute something other than complaints about MochiKit... -bob --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
