Do we need another JavaScript library?

[Chris Brown]

The failure of E4 and it's packaging system has got me thinking about
the current offerings in terms of JavaScript libraries.

I work on a project (an API) which has a huge JavaScript code base and
we have been through the full cycle. We started off without using a
library, instead deciding to roll our own. This went on for around six
months with the library becoming a mini-project in its own right. We
then came to the conclusion that we were just repeating what had
already been done in other libraries and maybe we would saved time if
we just used on of those, and that would counter the negative side in
which we were effectively choosing the framework to use on behalf of
our API users. We looked through the various offerings. We basically
had three requirements -

- Must be lightweight (goodbye Prototype, Dojo)
- Must not try to mimic the constructs of another language
(goodbye Prototype and Dojo again)
- Must have clear easy to absorb documentation (goodbye YUI,
goodbye Dojo yet again)

It was a shame Dojo does so badly on all of the above as it has some
very compelling features, the GFX (VML, SVG) library alone would have
saved us a lot of time, but that code alone was way too fat, we tried
ripping it out and thinning it down but it had so many deep rooted
dependencies to other parts of the framework that once again we
decided it would be much quicker to just write our own.

So we ended up choosing JQuery, we then proceeded to port our entire
code base over to JQuery which went very smoothly at first. The
problems came when JQuery didn't quite fit what we needed and we
needed to dig into the guts of it and change things, this often took
far longer than if we had written the whole feature from scratch, then
there would be a new release of JQuery with features we were
interested in, we then had to add our new personal touches to the new
release, tests started going red etc etc, you know the story.

Anyway to cut a long story short we once again did a full about turn
and decided that using a 3rd party framework for a project of this
size was a bad idea and went back to our own library once again. This
is not to say that we object to using a third party library, we just
object to using any of them in their current format. which gets me on
to the point of this post - Do we need another JavaScript library?

For me personally I care about:

-True modularization (i.e. no core that 'must' be present for all
modules)
-A proper packaging system (non runtime) that can detect the
dependencies and only include those
-Something that is truly open so anyone can add to it, it's up to
the end user if they use it or not

I do not care about:

-I don't want JavaScript pretending to be Python, Ruby or Java
-Unobtrusive JavaScript
-Having some magic $() God class that everything must go through
-Everything being so tightly coupled to the DOM

With the things I don't care about, people would be free to add those
features, but as there is no 'core.js' as such, it will be up to me
whether or not I or my packages choose to utilize them. So I suppose
what I am suggesting is a non-runtime package system that will allow
me to build applications or packages that build on the work of others.
There will be no rules, if six people want to add Ajax packages fine
that's up to them, but it's up to me whether or not I choose to use
them. To aid people in their decisions it would also be nice to have a
strong community element where packages can be rated and commented on,
in order to easily sort the good from the bad.

Is it only me or would something like this also appeal to others?


-

[Justin Bozonier]

If I'm understanding everything you've said correctly, it sounds like
what you really need is a better designed javascript code base. I
would abstract jQuery away from my other classes using a proxy
pattern.

If you feel like there are some fundamental portions of jQuery that
are broken I would recommend contributing to the project and not
starting your own.