Most of this tutorial is taken from my upcoming book 'Secrets of the JavaScript Ninja' which can be found here: http://jsninja.com/
I don't think this was explicitly stated on the slides but you can double click the code slides and you'll be able to edit and re-run them. I tossed this tutorial up after the talk and haven't really had a chance to improve upon it.
Sort of related: Remy Sharp built http://jsbin.com/ which is based off of the construction of this tutorial (using the run-and-show style together with double-click-to-edit).
Nope. In all honesty, it was one of the worst-targeted talks that I've ever given. I had given a similar talk at OSCON (highly technical crowd, audience) and was asked to give it again at Web 2.0 Expo. If you're not familiar with that conference it's highly not technical - lots of social media experts and managers. I was given a room that could've housed 300+ and there was maybe 20-30 attending - and that number rapidly decreased as I worked to explain the complicated aspects of JavaScript. In the audience were people who had, obviously, never coded JavaScript before (based upon the questions they were asking - this talk is not designed for that). By the end there was maybe a dozen people left and they came up and told me how much they enjoyed my talk and how informative it was - so at least it wasn't for naught. I know that the content is good and that I'm able to deliver it effectively but I won't be giving it again until I know that I'll have an audience that appreciates the content.
I was at this talk, and loved it, but you are definitely right about the audience of the conference. I was disappointed as I was hoping it would be a highly technical conference, but instead of it was filled with social media "experts" as you said and lots of buzzwords and hype.
Great (best I can remember but I have bad memory) machine assisted teaching.
I could see many textbooks/subjects maths, physics, anything that fits the pattern "look at this" -> "what do you think will happen" -> "this! is what happens and why".
#67 "Prototyped properties affect all objects of the same constructor, simultaneously, even if they already exist"
This is only true for properties created as new properties on the existing prototype (Ninja.prototype.swingSword = ...). It is not true if you assign a new object to the prototype (Ninja.prototype = { 'swingSword' : ...}).
The existing objects will only see new properties added to the object which was constructor's prototype at their creation time.
The terminology is confusing. The property named "prototype" on the constructor is not necessarily the same as the actual prototype object of an instance created with the constructor. There is no standard way to retrieve the prototype object of an instance, but in Mozilla you can get through the non-standard '__proto__' property.
The 'prototype' property on the constructor indicates what will be assigned as the prototype of instances created in the future with that constructor. The property can be changed, but that does not affect existing instances created with the constuctor. It would probably be less confusing if the 'prototype' property was called 'assignPrototype' or something like that.
The prototype (ie. __proto__ property) of an instance cannot be changed according to the standards (although some non-standard implementations allow that). That is, it cannot be changed to point to a different object, but the prototype object itself is mutable, and when you change it it will affect all instances sharing the prototype.
It is not uncommon to think of constructors as equivalent to classes, however technically prototypes and constructors are independent. You can create instances with different prototypes from the same constructor, and you can create instances with the same prototype from different constructors.
Nope, it says exactly what I quoted ("prototyped properties"). It also provides an example that happens to be of the later kind (properties set on existing prototype.)
"It is not true if you assign a new object to the prototype
Which is a completely different thing."
Completely different from everything that falls under "prototyped properties"? I disagree.
All in all, my point is that if you don't know exactly how it works then there is a chance you might be misled by this #67. I am not arguing that it is "wrong".
It says "all objects of the same constructor", which can be losslessly translated to "all objects with the same prototype that were created using JavaScript's retarded way of trying to look kind of like a class-based OO language when really it's not at all".
If you change an object's prototype, that object is no longer "of the same constructor". "Ninja.prototype = { 'swingSword' : ...}" is, in fact, a completely different, far more dramatic action than "Ninja.prototype.swingSword = ..." You shouldn't at all have the expectation that the two are anything alike.
It says "all objects of the same constructor", which can be losslessly translated to "all objects with the same prototype that were created using JavaScript's retarded way of trying to look kind of like a class-based OO language when really it's not at all".
It's rather "expanded using knowledge about Javascript object model plus subjective opinion about JS being retarded" than "losslesly translated".
Given that said knowledge is the knowledge that the slides are meant to convey, we have some circular reasoning here.
I didn't say JS was retarded, I said the particular way it tries to look like a class-based OO language even though it isn't was retarded.
Given that you were critiquing #67 as though you thought you already understood the information, I felt it was fair game to call you out for being wrong about it. Apologies.
This is exactly the kind of thing that makes Javascript so disappointing. ninja is an object, that has a slot yell. yell refers to a function/closure. Samurai is a _new_ object, with a _new_ slot, that _independently_ refers to the same function that yell in ninja refers to.
And yet, when ninja is deleted/collected the function yell disappears. This is insanity. In javascript
function(n) { blah }
should be a simple expression that creates a heap object, and heap objects should live until it becomes unreachable, at which point it may be collected. So unless _function_ is not an ordinary expression that creates a first class object, this cannot _possibly_ go wrong.
And yet it does.
Can anybody think of a justification for this absurd behavior?
I believe you misunderstood the behaviour of the code. The ninja.yell function is a proper object, it does not disappear and samurai.yell refers to it all the time.
What goes wrong is this: when it tries to call itself recurively by using ninja.yell, ninja already refers to null. That's when it fails.
The moral of this slide is "If you want a function to call itself, better give it a name and refer to it by the name instead of relying on bindings that are outside the scope of the function." This has a followup in the next slide, where exactly this happens.
Weird. Every time I hit "run" it would flash something and then go back to the homepage. I turned on Firebug and broke on next command (once it got out of stupid jQuery interval) it seemed to work. Refreshing again and again and it seems to work, but now it's broken again.
After reading the tutorial, I took pleasure in reading the source code of that page. A great tutorial and a very nice UI implementation with JavaScript - Resig is a js hacker indeed.
this was great. exactly what I have been looking for. I still have a few questions though...
function largest(){
return Math.max.apply( Math, arguments );
} <-- why is it necessary to run this function in the context of "Math". I don't get this...
I would guess that it's just good programming practice to feed a function the context in which it would normally be called -- which for the Math.max function is the Math namespace object.
It probably makes no difference what context the Math functions are executed in, since they are probably backed by native code implementations that don't rely on context, but one could imagine some JavaScript implementation taking a shortcut and doing something like:
thank you. i suppose this makes sense, i guess i don't understand objects / functions as well as I thought. I thought that Math was like a static thing from other languages, where you wouldn't ever create a new Math() and therefore the this operator wouldn't make sense...
Is this a preference? I've tried in the past to dig up research actually proving the "most visible combination" through experimentation. I've always assumed that road signs are the combination of colors they are because some empirical research proves it. Never found anything though.
A 'bind' function is very useful for callbacks. It's awkward to write object oriented javascript without it. So it's quite useful to understand how binding works.
You can find more information about it here: http://ejohn.org/blog/adv-javascript-and-processingjs/
Most of this tutorial is taken from my upcoming book 'Secrets of the JavaScript Ninja' which can be found here: http://jsninja.com/
I don't think this was explicitly stated on the slides but you can double click the code slides and you'll be able to edit and re-run them. I tossed this tutorial up after the talk and haven't really had a chance to improve upon it.
Sort of related: Remy Sharp built http://jsbin.com/ which is based off of the construction of this tutorial (using the run-and-show style together with double-click-to-edit).