New jQuery announced!

[Matt Kruse]

When I propose a library to a client, they want to see something
well-known and widely used, and I have some understanding for
that. Since they cannot judge the thing itself, they have to
judge "by proxy".

I have the same experience. Some clients have an "approved" list of
3rd-party libraries that may be used. Even if I wanted to use "My
Library" instead of jQuery I couldn't.

I keep thinking about a partly or mostly compatible jQuery
replacement, something that would look superficially like
jQuery, but would work better under the hood.
The idea would be to point out jQuery's shortcomings, but at the
same time offer jQuery users a very simply upgrade path. The $
name makes this particularly easy, as people would not have to
change their jQuery-based code.

I have wanted this for a while. In fact, I own myjquery.com which was
going to be for that purpose. But I have never done it.

The main argument against this is that it's the jQuery _concepts_ and
core API that are flawed. Not just some of its internal workings.

The overloading of functions, in particular, is seen by many to be bad
design. And if you want to replicate the flawed API, you're going to
end up in the same traps that jQuery is criticized for to begin with.

I think it would be good to strip down the API to be reasonable and
offer less functionality than the default jQuery. Make it the selector
engine (which I also find very useful) with some commonly-used core
functionality on top of it. Remove half the methods and remove the
overloading from the other half.

A lot of existing jQuery code probably wouldn't work with the new
library, but that wouldn't be the point. Instead, you'd have a better
starting-point to work from, and a smaller learning curve to go to a
leaner, faster, more robust library. Plugins would very likely not
work, but that's a good thing. Almost all jQuery plugins are junk

Matt Kruse

 

[David Mark]

I have the same experience. Some clients have an "approved" list of
3rd-party libraries that may be used. Even if I wanted to use "My
Library" instead of jQuery I couldn't.


I have wanted this for a while. In fact, I own myjquery.com which was
going to be for that purpose. But I have never done it.

The main argument against this is that it's the jQuery _concepts_ and
core API that are flawed. Not just some of its internal workings.

Yes. it is an infantile design (so no maturation is possible).

The overloading of functions, in particular, is seen by many to be bad
design.

For what should be obvious reasons.

And if you want to replicate the flawed API, you're going to
end up in the same traps that jQuery is criticized for to begin with.

Exactly. What is this perverse fascination with the name "jQuery".
It's mud at this point.

I think it would be good to strip down the API to be reasonable and
offer less functionality than the default jQuery.

There are already better alternatives (as you well know).

Make it the selector
engine (which I also find very useful) with some commonly-used core
functionality on top of it.

Are you not paying attention? Did you see that the selector engine is
just as screwed up as attr (in much the same way?) They have no idea
how to fix any of it either.

Remove half the methods and remove the
overloading from the other half.

A lot of existing jQuery code probably wouldn't work with the new
library, but that wouldn't be the point.

A lot of existing "jQuery code" doesn't work with jQuery. They shave
more off with every upgrade.

Instead, you'd have a better
starting-point to work from, and a smaller learning curve to go to a
leaner, faster, more robust library.

What library would that be?

Plugins would very likely not
work, but that's a good thing. Almost all jQuery plugins are junk

Of course they are. You can't dress up a pig.

 

[Matt Kruse]

Are you not paying attention?  Did you see that the selector engine is
just as screwed up as attr (in much the same way?)

In a few cases, it may give wrong results. I have never encountered
them. It's very useful for everything I've used it for. Grabbing
groups of objects and doing some action on them is a common
requirement, and I happen to like the
$('grab stuff').doSomethingToAllItems()
way of handling it. It's handy, concise, and easy to write.

Of course they are.  You can't dress up a pig.  

Can you put lipstick on it?

Matt Kruse

 

[David Mark]

In a few cases, it may give wrong results.

Gee, which cases? You do realize you would never know about any such
cases unless they were mentioned here?

I have never encountered
them.

So programming for you is exploring other people's bad code?

It's very useful for everything I've used it for.


Grabbing
groups of objects and doing some action on them is a common
requirement, and I happen to like the
$('grab stuff').doSomethingToAllItems()
way of handling it. It's handy, concise, and easy to write.

It's nothing. You sure as hell don't need jQuery to do that.

Can you put lipstick on it?

You could, but it would still be a pig.

 

[Garrett Smith]

I have the same experience. Some clients have an "approved" list of
3rd-party libraries that may be used. Even if I wanted to use "My

[...]

I have seen companies that use *only* jquery. A very common interview
question nowadays is "what is your favorite library?"

I recall an interview with this very question, followed by 20 minutes of
the interviewer telling me how great jQuery is. I failed to bring
relevance back by asking things like "what sort of problems can I help
you with?"

That was a really bad interview. To me, it seems closer to fanaticism
than technical discussion or problem solving.

I'm OK with a client that has legacy code or crap code. Virtually all of
them do.

The difficulty is getting the client to recognize the consequences of
continuing down the path they are on and learn something better. The
clients with the worst code tended to have more bugs, higher stress, and
more code that didn't make production.

I have wanted this for a while. In fact, I own myjquery.com which was
going to be for that purpose. But I have never done it.

The main argument against this is that it's the jQuery _concepts_ and
core API that are flawed. Not just some of its internal workings.

Trying to adjust jQuery would not go very far towards building an API
that provides efficient, useful, and transparent API. jQuery encourages
a very inefficient style of programming:
1) Wait for ready
2) Traverse the dom using css query selector
3) taking one or more actions on the result or first item

Traversing the DOM is slow. I can lock up the browser, even if for only
a millisecond. Browser UI should not be locked up.

Listening for a bubbled event is much more efficient. If the event
callback is interested in the target that the user took action on, then
the event can be handled accordingly.

The overloading of functions, in particular, is seen by many to be bad
design. And if you want to replicate the flawed API, you're going to
end up in the same traps that jQuery is criticized for to begin with.

jQuery should be cleaned up so that it is clearer what it is doing. The
oldSizzle being called, the attr function being called with "curCSS". It
is too complicated. Most of the methods are way way too long. The code
is hard to follow.

Overloading is a cause of a lot of the needless complexity in jquery.
REmoving the overloading might not be possible at this point, however it
would be possible to extract smaller methods.

For example, jQuery.prototype.init method is actually a constructor. I
can't see the benefit in having a public, indirect constructor in the
prototype. Is jQuery.prototype.init intended to be called from anywhere
else? It seems much more suitable to have the constructor hidden in
scope and renamed to something like 'JQuery'.

The body of the init method is too long. It should be cleaned up into
several small functions.

The first method, init, could be refactored and cleaned up.

I think it would be good to strip down the API to be reasonable and
offer less functionality than the default jQuery. Make it the selector
engine (which I also find very useful) with some commonly-used core
functionality on top of it. Remove half the methods and remove the
overloading from the other half.

The amount of code required to get css query selectors to work in
non-supporting browsers does not make up for a few calls to simple
traversal functions.

Better alternatives to dom traversal itself include event bubbling and
CSS descendant selector, depending on the problem.