Re: jQuery
Mallory == Mallory van Achterberg stommep...@stommepoes.nl writes: Mallory (so you'll see lots of people do Mallory var $(this) = $this Mallory which looks weird until you know why). And backwards. I'm sure you meant: var $this = $(this); -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 mer...@stonehenge.com URL:http://www.stonehenge.com/merlyn/ Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc. See http://methodsandmessages.posterous.com/ for Smalltalk discussion
Re: jQuery
On Mon, Mar 25, 2013 at 08:40:36AM -0700, Randal L. Schwartz wrote: Mallory == Mallory van Achterberg stommep...@stommepoes.nl writes: Mallory (so you'll see lots of people do Mallory var $(this) = $this Mallory which looks weird until you know why). And backwards. I'm sure you meant: var $this = $(this); Indeed. Even as I spent this evening changing someone's $thises to $thats, I didn't even think.
Re: jQuery
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? 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). 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. 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? Instead of, say, jQuip. Oooh, what's that? Should I be using it instead of jQuery? Thanks Smylers [*1] Also, I tried JavaScript at some point circa 1999, and I think I may be allergic to it. -- http://twitter.com/Smylers2
Re: jQuery
On Thu, Mar 21, 2013 at 11:41 AM, Smylers smyl...@stripey.com 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? 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). I like Bear Bibeault's jQuery in Action (but it may be a little behind the times these days). You should also get a copy of Javascript - The Good Parts by Douglas Crockford. My guys seem to like Angular.js as well. Cheers, Ben
Re: jQuery
On 21 March 2013 12:04, Ben Evans benjamin.john.ev...@gmail.com wrote: You should also get a copy of Javascript - The Good Parts by Douglas Crockford. +1 JavaScript isn't so bad if you ignore the DOM stuff, so get your head around JavaScript first - THEN then DOM bit - I found that really helped, they are two separate things. Leo
Re: jQuery
On 21 Mar 2013, at 12:04, Ben Evans benjamin.john.ev...@gmail.com wrote: You should also get a copy of Javascript - The Good Parts by Douglas Crockford. Yes and no. Crockford has some interesting opinions. Particularly when it comes to what makes good quality javascript (jslint is fundamentally broken IMO). My guys seem to like Angular.js as well. AngularJS has the bizarre glory of daftest release names i've ever seen: https://en.wikipedia.org/wiki/AngularJS#Releases /j
Re: jQuery
On 21 March 2013 12:31, James Laver james.la...@gmail.com wrote: AngularJS has the bizarre glory of daftest release names i've ever seen: https://en.wikipedia.org/wiki/AngularJS#Releases I suspect increase-gravatas [sic] is a reference to Iain M. Banks' famous gravitas-related Ship Names[0]. [0] http://everything2.com/user/sam512/writeups/Culture+ships
Re: jQuery
On Thu, Mar 21, 2013 at 11:41:47AM +, 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
document.getElementById('foo')
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
variable).
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?
http://readwrite.com/2011/11/28/jquip-puts-jquery-on-a-diet
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).
-Mallory
Re: jQuery
On Thu, Mar 21, 2013 at 12:31:53PM +, James Laver wrote: On 21 Mar 2013, at 12:04, Ben Evans benjamin.john.ev...@gmail.com wrote: You should also get a copy of Javascript - The Good Parts by Douglas Crockford. Yes and no. Crockford has some interesting opinions. Particularly when it comes to what makes good quality javascript (jslint is fundamentally broken IMO). My guys seem to like Angular.js as well. AngularJS has the bizarre glory of daftest release names i've ever seen: https://en.wikipedia.org/wiki/AngularJS#Releases /j Good Parts is still an essential book to read, even if it's a lot of Crockford opinion. Like, I *do* like ++ incrementers, and miss them sorely in Python. For JSLint haters, there's JSHint. jshint.com -Mallory
