However, strict mode is what it sounds like — strict. It can be difficult to learn the new variants and rules. Fortunately ES5 offers other modes that can be used that are more accessible to average coder.

stern mode

Very similar to strict mode. It runs bad code, but tells you all the ways you screwed up and threatens that it won’t run the code next time.

permissive mode

Pretty much let’s you do whatever you want. It’s not happy when you use `with` or `eval`, but doesn’t do anything about it. It will occasionally throw errors, but they are unpredictable and passive aggressive. `switch` and `break` have been removed for being too confrontational and replaced with `praise` and `accept`.

A new exception is introduced for this mode: Fit(). When the feeling is the code is given too much lenience, it’s best to:

throw Fit();

coddle mode

Writes your code for you while you eat snacks.

This mode also includes new exceptions. Up() can be used if the code is taken to extreme. There is a special Party() exception which also returns a special promise. That way you can chain exceptions:

throw Party().then( throw Up(); )

While these new modes are helpful, the TC39 committee realizes they are still to restrictive to be useful is some cases. For ES6, the plan is to release subsections of each from which you can pick and choose. It will be called…

Wait for it…

ala mode

These are not your run of mill, average plugins. These are the best of the very best. the cream of the crop, the cream of mushroom, the cream of tartar. We don’t have time for mediocrity so they are stricken. Dead to us.

1. Image Carousel – Converts a series of pictures into a a 3D spinning carousel.
2. Carouselify – Carouselify your images!
3. Carouselifyer – A plugin that carouselifies your images
4. Carousel Carouselifyer - Carouselifies carousels, so that while images are spinning in carousels, the carousels are spinning around each other. A very eye catching effect!
5. makeAwesome - A plugin that adds awesome things to your page. Images will zoom in and out and open in modal dialog boxes, lists will animate into place, inputs will be really huge, and buttons will of course…. blink.
6. makeAwesomer - The successor to the weaker, much less awesome makeAwesome, is makeAwesomer, which includes features lacking from makeAwesome, like creating awesome carousels.
7. makeUsable - A plugin that adds usability to your website. It will automatically generate widgets that can handle your 10 megabytes of XML data. One of its key modifiers is removing power-sucking, eyeball-bleeding, user-confusing carousels from the page. It has the added benefit of removing zooming images and blinking buttons.
8. marginalizer – All developers are looking for ways they can be marginalized. This plugin makes it easy!
9. Poopin’ Unicorns – Finally, a way to quickly and easily add unicorn Easter eggs to your webpage. Note: Voted Best jQuery Plugin of 2004!
10. Make It Pretty for Me – Go ahead and write crappy code, do your layouts in nested tables within nested tables, position elements with non-breaking spaces, and generate code with dynamic IDs and no class names – no problem! Just install this plugin and it will style everything perfectly, just as you had it in your mind when you were generating your HTML in Eclipse. No need for a whiny designer.

To see the remaining plugins, click the link below!

Link to the remaining 999,999,990 plugins

Twitter has recently announced they are killing their AJAX-heavy UI, and rolling back to a server-centric design. The reason they cite is “time to first Tweet”. With their AJAX UI, the page would need to load, the JavaScript would need to load, execute, examine the URL, request data and wait for it, then finally render the Tweet list. They estimate it took almsot 5 times longer to get to the first Tweet with AJAX as opposed to served HTML. Twitter built a web app, when they really should have built a web site.

In my perspective, there are two basic designs for web development:

Web apps

• Gmail or Google maps would be the prime examples. Google Search would now be considered an app as well.
• They should be AJAX heavy, and a single page, because you don’t want to continually reload the JavaScript.
• The server is used only for data and provides APIs. While that API may return JSON, it really should return anything that the client requests. If the client wants a comma delineated list, the server should be able to convert its output on demand.
• Typically, web apps do not use SEO and do not have ads.
• You can make ads work on an ajaxified page, but this may require some extra knowledge on how the ad network accepts requests, and then you may need to hack the embed code they provide. Google Search can do it because they control the ads. In other words, it’s something that really needs to be considered before you build it.

Web sites

• A blog or a news site would be an example
• Should be server heavy and serve pages for SEO and ads, and should be JS light, since that JS needs to load on every new page.
• Don’t confuse an AJAX-heavy web app with a web site that has a lot of (or too much) JavaScript.
• Needs to be read by both a browser and search engine crawler. Even though Google claims to be crawling JavaScript, the content needs to be available without it.

There are variations of the two, like Facebook, which has a lot of pages and is AJAX-heavy.

Considerations

Sometimes the decision is not so easy though. You may have ideological developers to contend with. These developers could be over zealous JavaScript crazy freaks who want to build the entire site dynamically with JavaScript. But often the ideology originates from CS graduates who have been “doing it this way” for 15 years and see no reason to change — or don’t know why they should.

A web app should be a single page for a reason. The back end should focus on data, business logic, and workflow. If it’s a complex UI that can put a significant burden on their code. What if there are tabs within tabs? Don’t forget to maintain the browser history. That Back button needs to work.

Web apps can also get too large. I worked on an app with 3 megabytes of JavaScript, which probably should have been broken into a couple of pages. The code did lazy load, but when it was all loaded you were using a lot of memory.

When Club AJAX was first launched, it used AJAX to load the pages. This didn’t work very well for SEO, and there was no easy way to include ads (not that I ever wanted ads… Bob!). The site also wasn’t easily expandable. For all its warts, WordPress, with discrete pages, was really the way to go.

Finally, it’s a very small segment of users, but some do turn their JavaScript off. This would pretty much eliminate any shopping site from being a web app, unless you can justify turning away a small percent of revenue. But JavaScript is always turned on by default, so those users know how to turn it back on. If it’s a very interactive site, like maybe with dynamic charts, it could cost you more to accomodate those users.

Conclusion

While there are two primary architecture styles, web app and web site, most projects are a hybrid of the two. Even the current version of Twitter pushes the initial set of Tweets to the page in the markup and provides the rest via AJAX. And it’s rare today to find a web site that does not have some degree of JavaScript, and often enough to consider it an “app”. Ad networks and SEO are both evolving too, so there are increasingly fewer reasons a web app can’t do it all.

Web development is evolving to be more client-side oriented. But even in cases of server-heavy sites, the front end developer needs to be more involved in the design and architecture. They tend to bring a more user-focused point of view to the project while back end devs tend to bring a more data-centric point of view.

However, PayPal’s decision to hire Mr. Crockford was not an easy one. He went through a grueling interview process. Club AJAX has managed to get ahold of the transcript of that interview, and we have posted the top ten questions Mr. Crockford was asked.

Top Ten Douglas Crockford PayPal Interview Questions

1. Would you be willing to learn JavaScript?
2. Have you ever used JSON? (Don’t worry, you just eval some text.)
3. Do you know JSLint? If not we have a Wiki to explain it to you. I hope you use semi-colons.
4. We do brown bag lunches with as many as ten people. Can you speak in front of such large crowds?
5. We see your PayPal rating is not above 95%. Could you explain?
6. If you were a fish, what kind of fish would you be?
7. We can’t pay market rates… would you be interested in stock options?
8. Did you come to us through a recruiter?
9. Do you see yourself, say in 5 years or so, using a real programming language?
10. The opening is for someone who knows JavaScript, CSS, HTML5, Node.js, Flash ActionScript, SEO, UI and UX design, mobile UI design, PHP, MySQL, Sharepoint, Microsoft Team Foundation Server, C# and SQL, C++, Java, Groovy, Spring, GWT, and Oracle DB with an expertise in database indexing — but currently we store all our data in Excel files… do you know Excel?

We met when you were 1.5, and started dating when you were 2.0. We enjoyed making fun of my clueless ex, Internet Explorer. IE seemed great at the time, but you showed me the error of my ways. IE was selfish and wanted to do everything its own way. You truly believed in collaboration and gratefully accepted suggestions. When you brought Firebug to the party, I became deeply committed to our relationship. Before Firebug I had no idea how difficult my life was, or the abuse of “error on line 0 character 0″; or blank, failed, pages and the silent treatment. You were very up-front with my errors, and kept life spicy with tabs, smart bookmarks, and an Awesome Bar that was truly awesome. Sure you didn’t load pages as fast as the other browsers, but I’m not greedy and the most important thing in my life was never… “cache”. Life was never boring, and at the nearest hint that it was, you would whisper in my ear, “I have a new AddOn…” And boy oh boy, I’ll never forget the first night with that Greasemonkey.

Soon after, other browsers began vying for attention. Safari spawned Webkit, Opera was talking about an HTML5 thing, and Chrome had a hot V8 engine. I honor my commitments, and planned to spend the rest of my career with you. I know the grass is always greener, and it’s important to love the one you’re with, and many more cliches, songs and metaphors.

But relationships are a two way street.

At first, I thought the fact that you didn’t play well with Flash was funny. I mean, you and I are all about HTML5, right? You put Flash in a (sand) box, kneed it in the groin, and we laaaaaa-ughed!

However, I work with video a lot. I understood your attraction to Ogg Vorbis, I really did. But nobody else wanted to play with your hippy friend. Later, I was as excited as you when your rich Uncle Google introduced WebM to everybody. WebM was so charming and intelligent — all the developers were swooning. But WebM had skeletons in the closet and just didn’t make good on its promises. Then WebM was stood up by none other than… Flash. You know you’ve hit rock bottom when the town drunk stands you up.

I’m glad to see you are opening up to the idea of H264. Your ideals were great, but we can’t live on a commune eating tofu forever. Don’t get me wrong, no love is lost on H264, or as I call it, H666, that patent troll who comes to every party claiming someone stole its idea for chip dip. Thanks to you and your rich uncle, H264 was afraid nobody would play, and so agreed to never charge admission. It’s time to help the web move on and think about other things. H264 may be evil, but it’s not kittens in the microwave.

Firefox, I can overlook all those things. You’ve been making it tough, but that’s okay — life is tough. But something serious has come up. I noticed you had memory problems since 3.0. I thought it might get better over time, but you’re 11 now. Your memory is starting to interfere with our relationship.

Which leads to a confession I have to make. A developer has needs. I’ve been seeing your cousin Chrome on the side.

My wandering eye started with video. Choppy, stuttering, almost unwatchable video. Yes, it was in large part due it playing through that mentally challenged plugin, but you didn’t leave much option, did you? Oh sure, you use HTML5 to play WebM and Ogg beautifully… but you know what pages use WebM and Ogg? NONE OF THEM!

Recently at a party when you were chatting with your highfalutin W3C friends about whether video should have a fullscreen API, or whether images should be allowed in canvas cross domain, Chrome cornered me in the bathroom. With trembling fingers, I began opening webpages that had videos. And guess what?

I liked it.

I never meant for it to happen. It was just one of those things. I became witness to a new world where a video would play from beginning to end without a stutter. Even more exciting, I discovered that I could actually smoothly scroll pages again. Don’t pretend to be shocked Firefox, you know what I’m talking about! How you give me the cold shoulder and freeze everything while you battle your memory-management Tourette’s Syndrome as I try and scroll a page that is still loading. Which as mentioned, you take your sweet time to do.

Sorry. I didn’t mean to get angry. I tried looking the other way. I tried reading email while you were busy being busy. But it’s gotten so bad that people are starting to blame my code for being slow. I hate to say this, but Firefox, it’s not me… it’s you.

We’ve had some good times. I never thought of myself as the type who needed a trophy wife, but Firefox, I deserve better. Chrome is hot, available, and every time I look, I see her heaving that ample bosom.

But don’t worry — we’ll continue to see each other since we share 20% custody of users.

By the way, there is someone named MP3 I’d like you to talk to…

Sincerely,
Mike

Built by Rapiscan, thanks to help from from a six billion grant from the federal government, this new, simple device uses a completely unobtrusive set of electronic sensors that detects the slightest shift in brain activity and translates it into alphanumeric data.

The futuristic technology is on display in the following image which depicts a high-end developer writing code by only thinking.

Of course, this technology is brought to you by the same trusted company that builds the trusted and completely safe Backscatter X-Ray machines that are installed in every neighborhood airport. Continuing with that track record of complete safety, the new keyboard-less input device keeps you completely protected with state of the art grounding straps:

The next step for the Rapiscan keyboard-less input? To take your thoughts which may not even be thoughts and translate them into thoughts and then translate that into perfectly legible language.

There is an undocumented feature in HTML5: “IE6 mode”. After all the pain and suffering all these years, all we had to do was:

<script>
"IE6 mode"
</script>

Here is how Club AJAX looks in IE6 without the feature:

And here is how it looks when I add the simple code as shown above:

When you send a Photoshop document to another designer, pay some attention to how the layers and groups are named. It’s really hard managing the file of someone else where everything in it is named Layer 2, Layer 2 copy, Layer 2 copy 8, etc., etc. The first thing I generally do is start toggling the visibility of each to figure out which is which and naming things accordingly. But ironically, this has even burned me in the past. The sender actually had the nerve to complain that I wasn’t able to send the file back with changes because it no longer matched his “layer structure”.

And you know, I guess I also disrupted the communication as now we can’t refer to Layers in the file: “Look at Layer 13 copy 12. No, no, the other Layer 13 copy 12 in group 3 copy 6.”

I’m just saying, garbage in, garbage out. Show some professional courtesy before you send that PSD.

We will also do ajax news.

Who the Hell Would Ever Use this F@#ing Language Anyway?

The title of this section is dedicated to a one-time Club AJAX attendee who looked at the next example and was so frustrated at how little he understood it, he started blurting out obscenities. Needless to say, he is now sentenced to life, doing Java.

So, to paraphrase Jack Nicholson… wait until you get a load of this:

“Waitaminute!” I hear you say. “I applied the context to the function, and onTimeout fired — why didn’t this.x resolve? And who the hell would ever use this language, anyway?”

I empathize, really. But remember, you don’t know how to paint without knowing about the color red, and you can’t really say you know JavaScript unless you know about context and all of its pitfalls. When you are able to understand this concept, it will elevate you from just a guy who writes some JavaScript to outright NINJA!

Before we can decipher why the previous example doesn’t work, let’s change it up so we can better break down the issues.

Example #2 basically substitutes otherMethod for setTimeout, so we can side step that particular nuance for now. This example shows a similar situation: we are passing a method to another method and trying to invoke it. However, this.x is still undefined. The reason for this is kind of tricky.

Yes, we used this with onTimeout. But we only used this in order to find onTimeout, we didn’t use it to invoke onTimeout. If we didn’t use this, we would get an error saying the function onTimeout is not found, which makes sense, because that would indicate we want a function (as in, var onTimeout();), but what we really want is a method. So we use this, to get the method, and pass it to this.otherMethod.

The Reason

Ironically, if m() or otherMethod() invoked this.onTimeout, it would work. But when we retrieved the method we sort of “extracted it” from the object, and passed it as a variable, of a function if you will. It’s no longer a method, it’s just a function with no call object bound to it. So we need to re-bind this, which we can do with the call() method:

Is “this” Broken?

We fixed it, but I sense dissatisfaction in you, young Skywalker. “Why should I jump through these hoops? This language is broken!” I agree that this aspect is at the least confusing and seems just plain wrong. But there is a reason for this behavior, believe it or not. Remember, JavaScript functions are just data and can be passed around as such.

Okay, if you don’t believe me, perhaps you’ll believe Brendan Eich from this Talk:

[The reason for the keyword "this"] is I wanted functions, which are the main idea in JavaScript, to also be methods; and for them to be methods, they had to have a receiving object who’s property was the value of that function.

That explanation was a bit… recursive. Perhaps a simple exercise will help. In Example #4, one object copies a method from another. What should be logged, 10 or 20?

If you answered 20, you’d be correct. Even though o.m was copied as data, it was still invoked on the last line with the o2 object, which set its context. But you may see what the issue would be if a copied method carried its context around. Then the answer would be 10, derived from the original object. That would make JavaScript look even more broken.

The following is another example of the use of call(). You can borrow a method from one object and apply it to another object temporarily:

In Example #5, o.changeProps(1); invokes as normal, but the last line, o.changeProps.call(o2, 1); calls that same method, yet invokes it within a different object. Admittedly, this example is a bit contrived and is probably making you squirm from all the best practices it violates. But it does show the versatility of the language and exactly how call works.

Now that we have a better understanding of context and how to fix it, we can readdress the problem in Example #1. However, we can’t use call() to fix the context, because that would have to happen within the setTimeout function and we can’t change native code. Well, we could, but that would be like trying to waterproof a screen with a toothpick. Because the same problem will arise again and again, in callbacks, connections, and myriad other places. We have a better way.

Bind

The problem can be fixed with the new bind method in JavaScript.1.8.5. And in spite of the complexity of the problem, the solution is really quite simple:

Now that this is bound this.setTimeout, we can pass it around and it won’t lose its context. And that’s it! Fixed! Good night nurse!

What’s that? Does this work in what other browser? Hm, I promised some sort of ninja status, didn’t I? That would necessitate some sort of explanation.

Bind Under the Hood

First of all, no, this does not work in that browser, but we can home brew a utility method that does, which we will add it to the prototype object of the Function constructor. Ever added the forEach method to Arrays? We’re doing the same thing here except with the Function’s prototype.

What we need to do is take our existing function and the context passed, and create a newly bound function. We are not going to return the bound function directly because if we did, it would fire immediately, which we don’t want. We are passing the bound function as data to be invoked later. Therefore we need to return another function that has the bound function inside it.

You’ll notice that the function is bound with apply() instead of call(). This is because our utility code has no idea how many arguments may be passed, and apply() handles a variable amount… of variables.

Include the Simple Bind Prototype early within your code, and Example #6 will work — in all browsers.

But Extending Native Objects is Bad

Oh, so you’re one of those purists who believes you shouldn’t mess with native objects eh? That’s okay, I’m concerned about that too. The tide is shifting a bit in the JavaScript library developers community that it’s okay to extend native objects (not host objects) — as long as those extensions are to fix gaps in weaker browsers with standardized functionality. And of course if it’s your code, you can do whatever you want!

And… what you want is to not extend the native object? That’s actually a good thing here, because the wrapper-implementation is a little more clear in how it works as there isn’t the confusion of what “this” is, as in Example #7.

If using the wrapper implementation, you would change the code from setTimeout(this.onTimeout.bind(this), 1);
to:
setTimeout(bind(this.onTimeout, this), 1);

The bind method passes the argument object, which is quite handy on callbacks. The following example is a recreation of a callback mechanism, which demonstrates how variables are passed:

The Mozilla Implementation

You may have taken a peak at the Mozilla bind page, which would be only natural since I linked to it. I didn’t recreate their functionality because it’s a bit complex. Our solution handles 95% of what you would ever do with bind(), while theirs handles new concepts like binding to instance constructors and Arrays. But feel free to experiment!

Conclusion

Congratulations. If you made it this far into the blog and haven’t reached for a bottle of aspirin, bottle of alcohol, or a noose, that means you’ve managed to absorb one of the hardest concepts in JavaScript. Context is the key differentiator between JavaScript and all the other major languages.