next »

[perkiset]

Well, as advertised I took a couple jQuery books with me to the lake for the Turkey Day weekend. The first and most significant was jQuery In Action



The book was excellent, but not just for jQuery. In fact, Appendix A alone is worth the price of admission.

I'd not call it a seminal moment, but at least a seismic shift in thinking with regards to JavaScript because of Appendix A. I was 3 or 4 chapters into the book when there was a knockout area that said, if you're unfamiliar with any of these notions (objects, closures, etc etc) perhaps you should take in Appendix A before continuing. I thought, what the hell. I've got the time. MAN am I glad I did.

Turns out that I've been perceiving Javascript completely wrong. Although my code is strong and usage of the language is good, it is totally wrong. For example, I discovered that JavaScript is at once WAY more objecty yet completely un-OO all at the same time. The problem is that there are things that LOOK like everything other language with an OO syntax ... but they do NOT represent things the same way. Additionally, my notion of what functions actually are, or the idea that this code: function myFunc(parm, parm) actually creates a chunk of code named "myFunc" is utterly wrong. Imagine my surprise when I discovered that I was using a language correctly and yet blindly.

OK, perhaps that's a bit hyperbolic, but at the core, although I've been able to make some pretty impressive thangs with JS, I've been doing it without really understand what I was up to. Appendix A simply filled in a lot of the "Why the language does that" about code, closures, functional context and such. It's excellent.

Now back to the rest of the book  jQuery is a complicated tool that can provide quite an impact on the coder's workload. I can also see immediately that there are evangelicals out there that want to do everything with it, and I already see how it can be overused and abused. But with that caveat stated, this book does a great job of introducing the essentials of the library as well as real-world scenarios about it's usage - in as much as a book only 347 pages long can do.

What struck me immediately was how they grok exactly the steps I've had to take to make JS sing. The kind of long-hand code I've used to create client-side single-page apps with JS. In that way the book was great - it understood my position as a journeyman JSster and assisted me in a longstep into another way of thinking. The book seems very heavy on selectors, then moves rather quickly into other topics like animations yet completely avoids AJAX stuff. This is unfortunate, because I see a lot of benefit in the AJAX components of the library - especially the cross-browser AJAX compatibility.

The book was easily readable without being behind a monitor, which was nice. Many tomes really get stiff and dry unless you're using the examples - clearly a benefit, they went to pains to make sure that example screens and code were all there for taking in in a serial fashion.

I found it was best to put in 30-50 pages and then let that decant for a while. Although the prose is easy and smooth, it is not lightweight. Often, I found myself taking in a sentence or paragraph a few times because of the nonchalant or even cavalier way that some really important notions were popped out there. Taking a little time to let that steep really helped my overall comprehension.

All in all I gave the book about 3 days of really relaxedly taking it in. It was enjoyable and spun my gears about where jQuery belongs in my future coding, but again - the book did a marvelous job of filling in some holes I had in my comprehension of how JavaScript itself works, which in and of itself was worth the price of the book.

An excellent read and worth the money. A great addition to the library.

/perk

[oldenstylehats]

Thanks for posting the review, perk. I just bought a copy on Amazon. I've been using jQuery for a while, but know I haven't even scratched the surface. Also, while on the topic of books, any AJAX or SQL books you'd recommend?

[perkiset]

Hmmm... not off the top OSH. I pretty much gathered my Ajax chops online and via experience, similar to SQL. (That said, as stupid as it sounds, I carted around Teach Yourself SQL in 24 hours for a *long* time, simply because the stupid little examples were just GREAT memory jostlers). Similarly, I wrote phpMyIDE just so that I could figure out how to write stored procedures. I'm rather different that way.

In fact, the couple of Ajax books I've gotten my hands on were pretty useless - more marketing to the fact that a book at "AJAX!" on the cover than really helping me out. There are some real smarties here on the board on both topics, so don't be afraid to question away man.

[nop_90]

I have not read that particular book.
But i read other "In Action" books and they ussually are pretty good

For example, I discovered that JavaScript is at once WAY more objecty yet completely un-OO all at the same time. The problem is that there are things that LOOK like everything other language with an OO syntax ... but they do NOT represent things the same way.

Not to say I am an expert in OO, or anything.
But i did not really get a grasp on JS objects till i played with scheme and lisp.

JS OO (if u want to call it that) is based on prototyping system.
So basically there is no difference between classes and objects.
You basically create and object. Then "clone" it.
If u need inheritance u clone the object then modify it, and then clone that one.

JS has a lot of lisp/scheme hidden under the hood, with a C++ syntax in it to get you really confused.
With the name of java in the name to really fuk u up

Also by using the call method in JS, you can set the "this" in a function.
Which means u can have generic functions.
I have only found limited use for that right now but .....

[perkiset]

JS has a lot of lisp/scheme hidden under the hood, with a C++ syntax in it to get you really confused.
With the name of java in the name to really fuk u up

Exactly Nop. It's the inference that something is what it is not, that had be on the wrong track.

Also by using the call method in JS, you can set the "this" in a function.
Which means u can have generic functions.
I have only found limited use for that right now but .....

Heh ... and right here, you're already quoting it from the wrong place as I did. In fact, ALL functions are generic - a function is an object in JS. When you say

function myFunc() { }

...it is actually the equivalent of

var myFunc = function() {}

...note the subtle but very important difference: we old compiler people think about the function name as something that will be a "thing" in the compiled image and then linked to. In fact, the "myFunc" is just a variable name to hold the new object that is, rather than a string, number, regex or whatever, a block of code. The code that is executed when we say function myFunc() {} is actually

var window.myFunc = function() {}

This makes the very squirrely statement that a function's context is defined at invocation rather than construction a little easier to understand, since it is not a "hard and fast thing" - it is an object, contexted within the frame of the caller ... and gives more understanding to why there is the .call() and .apply() methods. And it explains why there are closures, which I had NO frigging idea were for until now.

It also explains why this code is trivial and right in scheme with the language:

function myFunc(str) { alert(str); };
var var1 = window.myFunc;
var var2 = var1;
var2('hello world');

It's a bit of a pretzel, but a good one.

[perkiset]

What I got is that closures represent the capability for a function to maintain local variable values regardless of context. This is important, because when you're building callback functions, the function would be in the context of the caller, not the way it was originally built were it not for closures. So using a reference to (this) when constructing the function, you can maintain a connection to the original context.

Interesting, the different object models you list, and I understand the difference better now. Of course, name-munging and such workarounds for the compilers made sense functionally before to me, but this model sort of spreads my brains about how it was really a concession so that you could compile Bjarne Stroustrup's ideas around OO in C.

Good stuff, thanks Nop.

[nop_90]

Woops i deleted my post. I was not happy with it
Anyway recap, lots of different ways to represent OO systems
Scheme/Lisp has like a zillion different ways of doing OO.
There is no "right" way to do OO, different OO models work better for different things.
A simple closure in JS

var adder = function(delta) {
   var sum = 0;
   var closure = function() { sum += delta; return sum; };     
   return closure;
}

var f = adder(10);
f() // result 10
f() // reuslt 20

var g = adder(5);
g() // result 5
g() // result 10

the sum in "g" and the "sum" in f are different.
So basically you can make what in python is called a "generator".

Also you could return an dictionary of functions.
That is how OO works when u do it with closures.

The more i know, the less i know 
Also I am thinking more that "language" is less important, more the techniques.
Problem with C++ etc, it gets you trapped in one way of thinking.
No reason with a little bit of trickery you could not implement closures in PHP.