Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Javascript > New jQuery announced!

Reply
Thread Tools

New jQuery announced!

 
 
Matt Kruse
Guest
Posts: n/a
 
      12-23-2009
On Dec 23, 8:09*am, Hans-Georg Michna <hans-
(E-Mail Removed)> wrote:
> 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
 
Reply With Quote
 
 
 
 
David Mark
Guest
Posts: n/a
 
      12-23-2009
On Dec 23, 10:49*am, Matt Kruse <(E-Mail Removed)> wrote:
> On Dec 23, 8:09*am, Hans-Georg Michna <hans-
>
> (E-Mail Removed)> wrote:
> > 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.


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.

 
Reply With Quote
 
 
 
 
Matt Kruse
Guest
Posts: n/a
 
      12-23-2009
On Dec 23, 10:14*am, David Mark <(E-Mail Removed)> wrote:
> 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.

> > 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. *


Can you put lipstick on it?

Matt Kruse
 
Reply With Quote
 
David Mark
Guest
Posts: n/a
 
      12-23-2009


Matt Kruse wrote:
> On Dec 23, 10:14*am, David Mark <(E-Mail Removed)> wrote:
> > 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.


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.

>
> > > 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. *

>
> Can you put lipstick on it?


You could, but it would still be a pig.
 
Reply With Quote
 
Garrett Smith
Guest
Posts: n/a
 
      12-23-2009
Matt Kruse wrote:
> On Dec 23, 8:09 am, Hans-Georg Michna <hans-
> (E-Mail Removed)> wrote:
>> 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


[...]

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 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.
>


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.
--
Garrett
comp.lang.javascript FAQ: http://jibbering.com/faq/
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Microsoft expanding it use of jQuery & involvement with jQuery lorlarz Javascript 6 03-25-2010 10:14 PM
jQuery Query about comparing jQuery references Aaron Gray Javascript 20 07-27-2008 01:53 PM
JQuery and ASP.NET. shapper ASP .Net 0 11-21-2007 11:45 PM
jquery .js file = windows authentication dialogue? Darrel ASP .Net 2 11-12-2007 01:35 PM
Anyone using JQuery witth ASP.net? darrel ASP .Net 2 09-06-2007 01:22 PM



Advertisments