Learning Advanced JavaScript(ejohn.org)
ejohn.org
Learning Advanced JavaScript
http://ejohn.org/apps/learn
15 comments
So...If this was from a workshop, is there an audio track?
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.
Oh those social media experts. What would we do without them?
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".
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".
These are slides from a presentation I believe. Does anyone have the original audio or video?
Nevertheless, they are fantastic. If anyone has links to similar presentations for other languages, I'd love to take a look.
Nevertheless, they are fantastic. If anyone has links to similar presentations for other languages, I'd love to take a look.
I found where it's from: Web 2.0 Expo in NYC (9/2008) - maybe someone has the audio?
http://ejohn.org/blog/adv-javascript-and-processingjs/
He also has it as a download: http://ejohn.org/files/learn.zip
Definitely going to look at his books now...
Oh his work here looks good too: http://jspro.org/code/
http://ejohn.org/blog/adv-javascript-and-processingjs/
He also has it as a download: http://ejohn.org/files/learn.zip
Definitely going to look at his books now...
Oh his work here looks good too: http://jspro.org/code/
#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.
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.
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.
This is only true for properties created as new properties on the existing prototype
Which is what #67 says.
It is not true if you assign a new object to the prototype
Which is a completely different thing.
Which is what #67 says.
It is not true if you assign a new object to the prototype
Which is a completely different thing.
"Which is what #67 says."
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".
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.
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.
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.
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.
http://ejohn.org/apps/learn/#13
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
And yet it does.
Can anybody think of a justification for this absurd behavior?
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 }
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.
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.
You're right. I didn't see it was the recursive function that throws the exception.
>> "If you want a function to call itself..."
Or just use the arguments.callee property which allows you to call the function from itself without worrying about names.
edit: oops, just seen that's on a later slide.
Or just use the arguments.callee property which allows you to call the function from itself without worrying about names.
edit: oops, just seen that's on a later slide.
Except in ES5 strict mode :-/
You can still do it, and without a Y combinator or anything like that too:
var ninja = {
yell: function () {
var yellLocal = function(n) {
return n > 0 ? yellLocal(n-1) + "a" : "hiy";
}
return yellLocal;
}()
}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.
Firefox 3.5.3, Firebug 1.4.2
Firefox 3.5.3, Firebug 1.4.2
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...
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:
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:
Math.exp = function(p) {
return this.pow(this.E, p);
}
assert(Math.exp(1), "Works");
assert(Math.exp.apply(Math, [1]), "Works");
var obj = {};
try {
Math.exp.apply(obj, [1]);
} catch(e) {
assert(false, "Doesn't work.");
}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...
John, you rock
Not only is this a great read, it's easy on the eyes, excellent contrast and font size.
white or coloured font on a black background is never easy on the eyes
personal preference I guess. I like it, and so most of my dev environment is dark themed
I disagree. I go blind looking at bright white backgrounds all day.
It also happens to be an excellent tutorial regardless of colors used.. =)
It also happens to be an excellent tutorial regardless of colors used.. =)
Yellow on black is the most visible combination of colors.
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.
Especially if you're astigmatic.
Java's Script - a new language?
Is that a joke? I really can't tell...
It's the longhand version of Java. You have to feed it into OCR, but it generally works provided your handwriting isn't too messy.
This is a great big collection of surprising things you can do with javascript. I'm not so sure it's a good thing it's being released.
These are probably idioms you want to avoid writing in code if possible. Learning how to read them is probably useful some times.
These are probably idioms you want to avoid writing in code if possible. Learning how to read them is probably useful some times.
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.
A prime example of useless JavaScript. Why not simply use HTML for a simple website like this? I did not see any benefit from JavaScript on that page.
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).