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
> 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
It's slower in that, for every time you do a
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).
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
> I've been liking using jQuery for little bits of (optional) user
> interface polish, but keep being caught out by not knowing proper
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
> of doing it (so jQuery doesn't need to). But it doesn't seem much fun to
> 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
> > $work says "here we do jQuery".
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 need for a closure or something there (rename your iterator
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