Mallory van Achterberg stommepoes at stommepoes.nl
Thu Mar 21 12:52:02 GMT 2013

On Thu, Mar 21, 2013 at 11:41:47AM +0000, Smylers wrote:
> Mallory van Achterberg writes:
> > Ah, jQuery, something I try to avoid except when I can't.
> > http://www.doxdesk.com/updates/2009.html#u20091116-jquery
> Thanks for that. Is there any decent combined documentation for
> JavaScript + jQuery, pointing to whichever of the two is superior for a
> particular task?

No, but if you want to know what's slower in jQuery, find the 
discussion forums over at their main servers, where people tend
to point these things out. api.jquery.com
In general the jQuery documentation isn't bad, and often like over
at Python docs some functions are spelled out in an example (how one
would build this function) so you can see how some of these functions
are implemented.

It's slower in that, for every time you do a
$(#foo) call, that's still Javascript in the browser converting to 
and whenever you've got $(this), you're re-calling a new this each time
(so you'll see lots of people do
var $(this) = $this
which looks weird until you know why).

By the way, I consider myself knowing a wee bit of Javascript and
even less of jQuery. In fact I'm mostly knowing "I need to do x" and
DuckDuckGO "how to do x in jquery" to find the name of the right
function. Then I read up more on the function to learn its caveats.
StackOverflow sometimes also has people mentioning good tidbits about
particular functions.

> I've been liking using jQuery for little bits of (optional) user
> interface polish, but keep being caught out by not knowing proper
> JavaScript (or Dom).

If you want to use straight JS, knowing the DOM and browser quirks
is essential. Like that when you do form.elements, webkits won't
count the fieldset as a form element while everyone else will. So
the numbers won't match if you're counting them.

I do use always the Core library ("library" is a big word there) by
Simon Willison and others, used by SitePoint way back when, simply
to make "this" work in IE and targets/event listeners. When I write
straight JS I mean.

> Sometimes I'm surprised by jQuery not having a way of solving a
> particular task, only then to discover that JavaScript itself has a way
> of doing it (so jQuery doesn't need to). But it doesn't seem much fun to
> learn all of JavaScript, including the awkward parts that I don't need
> to know because jQuery does them better, in order to find these.[*1]
> Indeed, it seems to defeat much of the purpose of a nice easy-to-use
> abstraction layer if to use it you need to first know the awkward
> low-level way.

The jQuery guys themselves are big JS nerds of course. I think it's
okay for them to assume users know JS: jQuery is like using a calculator
to Get Shit Done after learning how to do long division on paper.

That said, there are a lot of "developers" on the front end who say they
"do Javascript" and by that they mean they only know jQuery. More than
I know, but not one bit of plain Javascript.

> > So there ends up being lots of plain Javascript in my jQuery when
> > $work says "here we do jQuery".
> Which things would you say are better in JavaScript? What should I
> learn?

Normally people would say, learn Javascript before using jQuery. Some
basic JS concepts can bite you even through jQuery, where other times
jQuery does stuff completely different.
Example: when you grab a bunch of items, say list items in a list, in
JS, you have a node list. Which is array-like but not an array.
Using stuff in jQuery like .children() or whatever usually does give
you an array. This affects which methods you can use on your list if
you're switching between the two.

Still regularly seeing newbies calling a function from within a loop
and then getting surprised when only the last item in the loop got
the change... which is in Javascript 101 and jQuery doesn't prevent
the need for a closure or something there (rename your iterator 

Sometimes Javascript is just quicker because I'm avoiding making new
jQuery objects (which is what you normally do with everything to
get the syntax and DOM shortcuts you like).
> > Instead of, say, jQuip.
> Oooh, what's that? Should I be using it instead of jQuery?

jQuery is large. Most devs don't care if it's a bit large,
until they start trying to send that crap to mobile or users
with crappy bandwidth... and if you're only calling the whole
of jQuery to get around small IE bugs or use a plugin, maybe
jQuip is the answer (or any of the mobile JS frameworks).


More information about the london.pm mailing list