Well stated Rey.
These are steps that I believe will help jQuery be adopted by the mainstream
audiences.

  1. A plugin repository that is completely coordinated.  Like WordPress
  Themes or plugins.  It needs to have:
     1. Ratings
     2. Number of downloads
     3. Documentation
     4. Examples
     5. Naming pattern
     6. Links to competing or related plugins (or dependancies)
     7. Sites that use the plugin
     8. Comments
     9. A standard way of submitting new plugins.
     10. A pattern for all the above that is repeated for every
     plugin
  2. A more fleshed out Demo site of the core, like Moo has done.
  3. A site with comparisons of how to achieve goals in different
  libraries. (I started, but haven't had time to dedicate)
  4. Approximate speed parity with others (with a plugin or a "fat
  jquery"), but somehow the issue needs to be diffused.
  5. More PR.  Specifically, John and jQuery are symbiotic.  Each one
  has coattails on the other.

These things make a difference.
Does the j in jQuery stand for John?

Glen


On 6/14/07, Rey Bango <[EMAIL PROTECTED]> wrote:


Hi Joao,

> I find it interesting as well. Scriptaculous is the "killer app" that
> makes Prototype even more appealing, and as far as I know, Scriptaculous
is
> the leader in stability and features as far as FX libraries go. :-)

Its definitely the most well known effects lib and thats because they've
capitalized on the Prototype's "first to market" position. It does have
some nice features.

> jQuery is doing good, though.
>
> jQuery has many strong points to it as well. The core of jQuery is
> very good and provides plenty of features. Where I think jQuery lacks
support is in
> super-ultra optimization which might be required sometimes. And while
the core can
> be optimized, the plugins are another matter as well. The lack of
> performance can be exacerbated as everything is "chained". :-)

Hmm. I'm not quite convinced on this argument. The performance issues
aren't due to lack of optimization. The core team has really tweaked
every aspect. As I mentioned during the selector test suite thread, the
biggest roadblock to improving selector speeds is file size. That's
being looked at as I type and we're looking at all alternatives to
improving DOM selector speeds. That's really the only area that I've
heard mentioned in terms of performance and only when these test suites
are published. Since I monitor the lists daily, I'm in tune with a lot
of the problem areas and I haven't seen anyone mention jQuery as a slow
performer.

In terms of the plugins, that's really up to the individual plugin
authors to evaluate and tweak. If you look at several of the plugins
written by jQuery team members, they're very optimized and suffer no
performance issues. Again, its based on specific experience levels and
some folks will produce better code.

> Ultimately, jQuery doesn't have a "killer" application like
> Scriptaculous, and I think that to create something like Scriptaculous
requires a break of
> culture as far as "chain-only" solutions go in jQuery.

We have Interface but in terms of brand recognition, Scriptaculous
definitely has the edge. Feature for feature, Interface provides the
same functionality as Scriptaculous and there are things in the works to
improve a lot of the functionality.

Also, you keep mentioning "chain-only" and I guess I'm having a hard
time understanding that comment, especially when Prototype and Moo
followed jQuery and now offer chaining as a well promoted feature.
Chaining is a huge reason why people have chosen jQuery and why other
libraries followed suit. Where do you see chaining as a performance
issue? If you have specific examples, I would love to see them so I can
pass it along to the core group and have them work on that.

> I could put some blame in the emphasis on file size which is
> cultivated in the jQuery community as well, as the code of plugins can
be slightly more painful
> to digest.

I hear ya but we do want to empower the community to build the things
that they explicitly want while we maintain a solid foundation for them
to build upon. Again, its an approach taken by almost every major lib
and its been fairly successful to date across all projects.

> That said, I am still trying to find something better than jQuery, as
> other alternatives try to hard to go in the other direction though
(bloat, worse
> community support, slower development cycles, worse code all around).

Well, jQuery makes a very compelling case for itself and the team is
working on making it better. I think you can go with the "grass is
greener on the other side" approach and constantly be searching or you
could settle into enhancing jQuery, which you seem to like, and
contribute code, plugins and demos to the effort. Its not always about
looking for the something better. Sometimes, its about making something
thats already good even better. :)

> Doesn't anyone have the definitive approach to JavaScript
> programming? :-)

Good luck on that! LOL!

Rey...

Reply via email to