Future of MochiKit
mills
I have been evaluating MochiKit for an upcoming project. It looks
great, but I'm a little concerned about its status. Compared to dojo
and prototype, there seems to be little activity. I don't want to have
my project heavily dependent on a library that is not being developed
much anymore. Are future enhancements planned? What is the road map
for this project? How many developers contribute to this project?
Thanks
Bob Ippolito
The status of the project is that between 1.3 and 1.4 we took on a
huge body of new functionality which took longer than expected to
document and get right. svn trunk is pretty complete and stable (has
been for months) and is usable in production. Because it took on all
of this new functionality, none of the developers know and use all of
the library anymore (e.g. I don't currently use anything in
DragAndDrop, Sortable, or Visual) so it's harder to know what the
overall status of everything is and it makes it harder for me to
confidently do a release.
From your "future warm fuzzies" requirements it sounds like you might
be more comfortable with Dojo. They have a lot more vested interest in
releasing more often than we do and building a huge community around
it. None of the MochiKit developers are doing consulting (to my
knowledge anyway), so there's less reason for us. If Dojo was at its
current state two years ago I would've used it rather than writing my
own library. At the time MochiKit started, Dojo was just a svn
repository with no documentation and a lot of code.
MochiKit is practical code, extracted from real projects, written by
the people who built those projects. Our roadmap is to incorporate
whatever generic functionality that we've built in our own projects
that would be useful to other people. There's no overall goal other
than to maintain the high quality of the implementation and
documentation while we grow new functionality.
It's also hard to say that MochiKit "isn't really being developed"
when there's a huge body of new code. There just haven't been any
releases. The 1.4 release is imminent, but all of us are also very
busy with our own companies.
Compared to Prototype it appears inactive? I don't think you're paying
much attention to Prototype :) And what's their roadmap for future
enhancements? It's nice that they finally got around to writing
documentation after two years, but I have fundamental and practical
problems with the way that library extends JavaScript objects.
-bob
Arnar Birgisson
On 2/28/07, Bob Ippolito <b...@redivi.com> wrote:
> none of the developers know and use all of
> the library anymore (e.g. I don't currently use anything in
> DragAndDrop, Sortable, or Visual) so it's harder to know what the
> overall status of everything is and it makes it harder for me to
> confidently do a release.
Maybe then it's reason to keep a designated "maintainer" for each
module, a person that has a say in wether a particular module is ready
for releases, resolves or delegates bug reports etc.
This module "maintainer" would be named in the docs to give them a
sense of responsibility and to prevent them from wandering away from
the project without notice.
I for one am ready to adopt the Selector module.
Arnar
Bob Ippolito
That's a good idea, but not really the problem. It's a communication
issue. The (de facto) maintainers don't periodically tell me what the
status of the modules are, and I don't often ask them because it's not
often that a release is on my mind these days. I'm busy mostly writing
server-side code most of the week. For this project I haven't spent
much time on this iteration of UI because MochiKit already did
everything I needed it to do :)
If you would like to be the maintainer of the Selector module, email
me privately with the output of 'htpasswd -n arn...@gmail.com' for
your chosen password and I'll give you commit privs.
-bob
mills
On Feb 28, 11:24 am, "Bob Ippolito" <b...@redivi.com> wrote:
>
> MochiKit is practical code, extracted from real projects, written by
> the people who built those projects. Our roadmap is to incorporate
> whatever generic functionality that we've built in our own projects
> that would be useful to other people. There's no overall goal other
> than to maintain the high quality of the implementation and
> documentation while we grow new functionality.
Are contributions welcome?
>
> It's also hard to say that MochiKit "isn't really being developed"
> when there's a huge body of new code. There just haven't been any
> releases. The 1.4 release is imminent, but all of us are also very
> busy with our own companies.
I understand about being busy.
>
> Compared to Prototype it appears inactive? I don't think you're paying
> much attention to Prototype :) And what's their roadmap for future
> enhancements? It's nice that they finally got around to writing
> documentation after two years, but I have fundamental and practical
> problems with the way that library extends JavaScript objects.
I haven't been paying much attention to any JavaScript libraries until
recently (prior to this project, I was doing desktop solutions). I'm
just doing some background research now, hence my initial post. It's
hard to evaluate the status of a project other than looking at the
activity on the mailing list, updates to the website, and general
noise about the project on the web. From that I determined prototype
might be more active than MochiKit. It appears I'm wrong ;-)
Bob Ippolito
> >
> > MochiKit is practical code, extracted from real projects, written by
> > the people who built those projects. Our roadmap is to incorporate
> > whatever generic functionality that we've built in our own projects
> > that would be useful to other people. There's no overall goal other
> > than to maintain the high quality of the implementation and
> > documentation while we grow new functionality.
>
> Are contributions welcome?
Yes. I'd estimate that about half of MochiKit at least started off as
a contribution. I won't accept just anything though. It has to either
be something I see immediate value in, or something that the community
(mailing list) gets behind.
I'm definitely not going to take anything else for MochiKit 1.4 though
:) Contributions should be released as "add-ons" until that happens.
> > It's also hard to say that MochiKit "isn't really being developed"
> > when there's a huge body of new code. There just haven't been any
> > releases. The 1.4 release is imminent, but all of us are also very
> > busy with our own companies.
>
> I understand about being busy.
>
> >
> > Compared to Prototype it appears inactive? I don't think you're paying
> > much attention to Prototype :) And what's their roadmap for future
> > enhancements? It's nice that they finally got around to writing
> > documentation after two years, but I have fundamental and practical
> > problems with the way that library extends JavaScript objects.
>
> I haven't been paying much attention to any JavaScript libraries until
> recently (prior to this project, I was doing desktop solutions). I'm
> just doing some background research now, hence my initial post. It's
> hard to evaluate the status of a project other than looking at the
> activity on the mailing list, updates to the website, and general
> noise about the project on the web. From that I determined prototype
> might be more active than MochiKit. It appears I'm wrong ;-)
You should probably also take a look at jQuery. It's kinda like
Prototype in style, but it doesn't screw around with the built-in
objects so it causes less problems. I don't like the way that
idiomatic jQuery code is written, but that's because I don't like
excessive().method().chaining().especially().when().mutating().state().
From an overall technical/practical standpoint it seems worth looking
at, though I can't say I've done more than look at the code (and
ignore all of the fanboys that scour blogs/digg/reddit and sing jQuery
praises).
-bob
Matthew Kwiecien
Don't get me wrong, Dojo is nice, but they seem to have the philosophy that "REAL programmers don't document! If it was hard to write it should be hard to understand!"
> Maybe then it's reason to keep a designated "maintainer" for each module
-matt
dsmath
Help" tab on their front page?
Or the link to API docs:
http://dojotoolkit.org/api/
Or manuals linked from the wiki (also linked to from the home page):
http://manual.dojotoolkit.org/WikiHome
I guess this pales in comparison to prototype's extensive external
documentation (2 mini-articles):
http://www.prototypejs.org/learn
Bob Ippolito
all. I've seen their API docs and it's nice they got somewhere but
that sort of API docs doesn't feel very usable to me. It is and looks
automatically generated, and it *really* shows.
Some of the manuals are good, but they're not comprehensive. They
write code much faster than they write docs... which is good for them
because they get the functionality that they need, but it's not really
so good for end users.
-bob
dsmath
Let there be no doubt I am comparing Dojo with Prototype (on the
documentation side) and not Mochikit. Mochikit has beautiful docs -
which is what made it so approachable to me.
Dojo is already importing parts of Mochikit wholesale. Are there any
communication channels between you and the Dojo guys Bob? It seems
Dojo could benefit by borrowing some more stuff wholesale from
Mochikit. For example, doXHR is soooo much nicer for my purposes than
dojo.io.bind which confuses the heck out of me me because the callback
takes three args!!! ick!
Though I am very happy with the new dojo.rpc module and JsonService
which returns - you named it - a Deferred!
Matthew Kwiecien
Whereas the only thing that would make MochiKit docs better would be more examples.
dsmath
that time too - but for other reasons ... I was looking at the widgets
stuff then. I'm in the process of reevaluating dojo, and I have to
say I'm starting to like it - definitely over prototype. They're
moving in the right direction and pushing out a lot more docs. Even
at the source code level. Check out the flash module (which enables
bidirectional communication between JS and Flash) as an example:
http://dojotoolkit.org/dojo-api/trunk//src/flash.js
On Mar 1, 6:40 pm, "Matthew Kwiecien" <mkwiec...@gmail.com> wrote:
> I dunno how it is now, but last time I looked for documentation (I think
> somewhere around 3/4 of a year ago), "sparse" would be the most flattering
> word that I could apply to them.
>
> Whereas the only thing that would make MochiKit docs better would be more
> examples.
>
> On 3/1/07, dsmath <drew.smath...@gmail.com> wrote:
>
>
>
>
>
> > Hu? No documentation for dojo? Did you happen to notice the "Get
> > Help" tab on their front page?
> > Or the link to API docs:
> >http://dojotoolkit.org/api/
>
> > Or manuals linked from the wiki (also linked to from the home page):
> >http://manual.dojotoolkit.org/WikiHome
>
> > I guess this pales in comparison to prototype's extensive external
> > documentation (2 mini-articles):
> >http://www.prototypejs.org/learn
>
> > On Feb 28, 12:39 pm, "Matthew Kwiecien" <mkwiec...@gmail.com> wrote:
> > > >If Dojo was at its current state two years ago I would've used it
> > rather
>
> > > than writing my own library.
>
> > > Boy am I glad you chose to write your own. :)
>
> > > Don't get me wrong, Dojo is nice, but they seem to have the philosophy
> > that
> > > "REAL programmers don't document! If it was hard to write it should be
> > hard
> > > to understand!"
>
> > > > Maybe then it's reason to keep a designated "maintainer" for each
> > module
>
> > > Seconded, sounds like a good idea to me.
>
> > > -matt
>
> --
>
> | Matthew Kwiecien
> · Webhosting | Design
> | delihosting.com | neoteria.com
Bob Ippolito
it. Brad Neuberg in particular has been doing a spectacular job at
documenting his research and efforts.
-bob
On 3/1/07, dsmath <drew.s...@gmail.com> wrote:
>
Karl Guertin
> DragAndDrop, Sortable, or Visual) so it's harder to know what the
> overall status of everything is and it makes it harder for me to
> confidently do a release.
The amusing thing about this is that you're listed on the blame for
the majority of the lines in these files, though I know Thomas
maintains them. I was one of the people pushing for Scriptaculous
stuff to be included, but a year later I no longer feel that the
Scriptaculous implementations are the best approach to the problems
they solve*. There would be little love lost from me if they were
dropped from the framework and turned into an extension.
* yui/yui-ext (preferring yui-ext) is my favorite solution for widgets
and I like animator for animation.
Thomas Hervé
On 2 mar, 04:39, "Karl Guertin" <grayr...@gmail.com> wrote:
> On 2/28/07, Bob Ippolito <b...@redivi.com> wrote:
>
> > (e.g. I don't currently use anything in
> > DragAndDrop, Sortable, or Visual) so it's harder to know what the
> > overall status of everything is and it makes it harder for me to
> > confidently do a release.
>
> The amusing thing about this is that you're listed on the blame for
> the majority of the lines in these files, though I know Thomas
> maintains them.
I guess that mainly comes from automatic changes (like the id* stuff)
or the merge itself. Not that I want to claim any proud for this
code :).
> I was one of the people pushing for Scriptaculous
> stuff to be included, but a year later I no longer feel that the
> Scriptaculous implementations are the best approach to the problems
> they solve*. There would be little love lost from me if they were
> dropped from the framework and turned into an extension.
>
> * yui/yui-ext (preferring yui-ext) is my favorite solution for widgets
> and I like animator for animation.
Yes, today animator is a *great* solution, especially for doing custom
effects. Scriptaculous is very useful if you just want to put a quick
effect, and that works well (be fair, very well for me, with lots of
feedback from different browsers). Unfortunately the API is not so
good.
--
Thomas
Cliff Wells
> and I like animator for animation.
Is this what you are using in production?
http://gr.ayre.st/~grayrest/animator/animator.html
Cliff
Karl Guertin
> Is this what you are using in production?
Yeah, in a few places. The bug I mention at the bottom doesn't affect
anything that I do, so it works well enough for me.
(sorry for the dup Cliff, I always forget to CC the group)