Ian Cropper


Someone else wrote most of your project

Any given Tuesday

Developer A: “Hey, can you take a look at this?”

Developer B: “Yeah"

Developer B: "…. hmm.....Have you tried using evil.js?”

Developer A: “No, what is it?”

Developer B: “It’s just a JavaScript library that will do exactly what you’re trying to do. It’s on GitHub. I’ll send you the link.”


Developer A:

 > bower install evil.js --save


And that’s often all the scrutiny a third-party library would get.

A Case Study

In 2010, even a company as big as Twitter fell prey to the effects of poorly written or untested 3rd-party code.

Known as the “onmouseover attack", users were able to insert scripts into a submitted tweet as part of an href link that would later be run as script when loaded on the page.

It was easy and would look something like this:

<a href="http://thisisatest.com/@"onmouseover="alert('test xss')"rel/" target="_blank" ="">http://thisisatest.com/@"onmouseover="alert('test xss')"/>/a<>/span< 

The parser being used would choke on the "@" symbol and read the rest of the "URL" as executable script.

 The result was that hovering over a link opened up a user to inadvertently liking the post or even re-sharing the post. Within minutes, posts using the exploit received thousands and thousands of likes and shares.

Some developer, somewhere, at some point wrote a URL parser and may have thought: 

"Why would there ever be an '@' inside of an href?"

Then later, without much research, some developer at Twitter thought:

"Hey, I found a URL parser in the bower repo!"

3rd-Party Code is everywhere and is largely unassessed

A study conducted by Coverity that surveyed 336 American and European Software companies produced some stunning findings

  • 90% of all the companies use third-party code (it's probably actually more shocking that 10% of companies write everything from scratch)
  • 65% reported that customer satisfaction has been impacted by third-party code
  • 44% of the companies were testing third-party code compared to 69% of the companies saying they test internally produced code
  • 35% of the companies conducted risk assessments on third-party code compared to 70% saying the assess risk for internally produced code
  • 35% of the companies manually code review third-party code compared to 68% that perform manual code reviews on internally produced code.

It's not just JavaScript

Last year I wanted a way to easily give developers a foundation for unit testing in a .NET project. So I built a nuget package for it. It was very specific to the company's framework and would need a bit of extra work to get it working on someone else's framework. 

And all that's not even to mention the fact that it never really made it past version 1.0.1.

None the less, it's been downloaded from nuget.org 137 times.

Bottom line: It's not hard to get a package on a repository like npm, maven, nuget, or bower.

more than just security


While security is a big risk of 3rd party code, it's not the only risk. Sometimes 3rd party code is just bad, or fragile. Or sometimes it depends on other 3rd-party code that's run by an open-source activist who may-or-may-not suddenly decided to remove all of his repositories

Frustrated after threats of a legal battle over the name of one of his modules, Azer Koçulu decided to remove his modules from the NPM repo entirely. In most cases no one would notice....in this case, thousands of apps stopped working because they depended on a module that was no longer there.

It's easy to assume that if 3rd-party code exists all nicely wrapped in a repository like Maven or Nuget, that the developer has thoroughly stress-tested their code (especially if they have a cool vector-graphic logo) but it's a risky assumption.

Speed / Bandwidth

There are plenty of tools out there that will help remove unnecessary code before prod, but just because something is necessary doesn't make it a good option, and at the very least, it's something developers should be aware of.

In a comedic example, Babel–the heavily used JavaScript transpiler–included an ASCII art image of Guy Fieri in the source code. While this is a fairly inert example, there are plenty more cases of 3rd-party code that, for example, will automatically run a whole host of expensive processes that will affect the end-user experience.

Are we supposed to write everything from scratch then?

Hell. No.

3rd-party code saves time, money, sanity, finger pads, keyboard expenses, marriages, children, baby animals,  .... It's great.


you are expected to use discretion.

Are you including jQuery because you need to query the DOM once? Maybe you ought to rethink that.

Considering a library from online with 1.5 stars and is at version 1.0.5? Let's keep looking.

Found something that would totally work but hasn't been updated since 2012? You're asking for it.

Don't go and reinvent the wheel with every project, but use the same scrutiny, assessment, and discretion you would use if you had written that code yourself. 

Getting better at your language by learning a new one

When I was 14, I somehow convinced my parents that it was a good idea for me to be an exchange student in Brazil. To that point in my life, it was the biggest and most monumentous thing I had ever done. I had never flown alone, I had never learned a new language, aside from Canada, I had never even been out of the country. Looking back, I had no idea what I was thinking.

I guess I just never actually expected there to be so many....Brazilians.

Arriving in Brazil and meeting my host family, my easy-going nature helped me to keep calm, but I was scared. I know going in that my host parents didn't speak English, but the realization of it finally hit me and I had no idea what I was going to do.

It took me 3 months before I finally had enough of a grasp on the language to hold a conversation and understand what they hell people were saying, and that was the point that I really started seeing that I didn't even understand English.

In order to learn Portuguese, or any Latin-based language, you must spend a lot of time learning verb conjugation.

"Verb What"?

Verb Conjugation.

It's like understanding when to use "I saw" vs " he sees" or "I am going" vs "We are going". Growing up having spoken English, I had never realized that there were similar rules in English. I just spoke English. I never thought about conjugation, I never even thought that such rules existed. When I spoke, I wasn't asking "I wonder why sometimes I say "I eat" and other times I say "we have eaten".

During that time in Brazil, I learned more about the English language than I ever did from and "Language Arts" class in school. I could speak English, but I didn't understand it.

"Umm, Isn't this more of a programming based blog?"

Damn right it is.

A while ago I had an interview. I was very excited about the prospect of working for this company. Since I claimed that I was an expert in JavaScript, the interviewer over the phone said it would be fine if we did some programming questions in JavaScript. The question he asked was as follows.

"Write me a function that when used as such:


I get the following output:

"why hello there friend"

Now I had studied up on currying functions and understood that in javascript, it was totally valid (and awesome) to have something like this

sum(3)(5); //=> 8.

All you had to do was return a function that accepted another parameter.

function sum(a){
	return function(b){
		return a + b;

But I had never looked into how to do this indefinitely.

I didn't get the job, but that question stayed with me for years. I researched how to do it online and the best solution I found was this.

function curry(fn) {
    return function() {
        var args = arguments[0];
            return fn.apply(this);
        var child = fn.bind(fn, args + " ");
        return curry(child);

But even that wasn't exactly what the interviewer was asking for.

The moment.

A while back, I started teaching myself Scala. Not just how to program OO stuff in Scala, but actual Scala programming. If you don't know, Scala is a programming language that is very well known and widely used for it's awesome functional-programming capabilities.

It was during one particular lesson about higher-order functions that I had that same moment as I had in Brazil when I realized "I'm learning so much about English". But in this case, "I'm finally understand JavaScript!".

Remember that interview question? Lets solve it again now that we understand more about JavaScript.

function curry(word) {
    console.log(word, " ");
    return curry;
curry("hello")("web")("dev")("team!"); //=> hello web dev team!

So what are you trying to tell me?

Even if you have been programming in some language for 5 years solid and you think you understand it, you will understand it more if you teach yourself a new language. And I don't mean just learning the new syntax, I mean really learn the language.

Already know Java? Learn Lisp.

Already know C#? Learn Python.

Already know JavaScript? Learn C++.

If you're that person that has been using primarily a single language for the past 5 years, then you're me as a kid: just speaking English because you've always spoken English, not knowing why the rules exist or that they even do exist but speaking it anyway.

Truly learning a new language will teach you more about the languages you already code in faster and deeper than any course on that language..

Can we all chill out with prototype?

I've been guilty of it, you've been guilty of it. Every JavaScript developer has been guilty of it. Using prototype everywhere

Look, I get it. We are told to never put functions and variables on the global namespace unless we have a damn good reason for it. Just having a var with no namespace and not attached to a prototype, it can feel dirty, but people please, let's use some discression. 

Have you ever inherited a project and EVERY. SINGLE. FUNCTION. in the JavaScript was attached to an object's prototype? Think about it for minute.....there it is, yes, you remember now. In order to  combat this terrible trend, lets start with some foundation.

What is prototype?

Protoypes are intelligent beings that live within all objects. 

Crap, no those are Midi-chlorians. Prototypes are similar though. Every object in JavaScript contains a prototype. Try it out. Open up the console and paste this in.

var obj = {test: "onetwothree"};

Not convinced? Then try this.


"Wait, even an empty string has a prototype?"

Sure does! If you expand the result, do you see all those properties and functions attached? They're attached to the prototype. Think of them as values attached to an object that every other object inherits from. 

So every object in JavaScript has a prototype. The most notable exceptions are:

  1. Integers
  2. undefined
  3. null

Now before you go thinking "oh, so primitives", no I don't mean that. Try it out. In the console, write:


Then write


I won't go further than that, but it's just interesting to keep in mind. Now where were we?

Oh yeah, So every object in JavaScript has a prototype. So when you create an object and assign something to it's prototype, your'e giving that object something that is accessible only through that object. It's through using prototype that we get the awesome advantages of inheritance in JavaScript. I'll save the inheritance discussion for another time though since this is a post about patterns. The important thing to remember is that once a value is assigned to an object's prototype, it can be accessed within the object using the syntax:


Here's a simple example:

var util = function(){};
util.prototype.getAllDivs = function() {
	return $('div');
utl.prototype.addBorderToAllDivs = function() {
	this.getAllDivs().css("border", "1px solid black");
var u = new util();


The most important part of this post

Look really closely at the code above.

I want you to ask yourself this question: "Does getAllDivs need to be a part of util's prototype?"

WONDERFUL! YOU DID IT! NO! The answer is NO! It doesn't! 

Then why the hell do we write code like this? The answer is, because we love to be able to write the line 


With that "this" in front of the function call, we know that the function belongs to the object. We like that. It looks good, there's a sense of security there. But this is wrong wrong wrong. I once hacked an online game of Risk because the developer had put everything on the prototype. So when I found the function

.prototype.isAdjacentTo = function(){
  /*[lots of checks and other function calls]*/

I just overrode it to be

.prototype.isAdjacentTo = function(){return true;}

And I was able to attack anyone from anywhere. I tried to convince the other players that I had earned so many points that I had been granted special abilities, but it didn't quite work out. The moderators didn't have any sense of humor.

How can we make that code better?

Let's take advantage of an awesome tool that's super easy to use in JavaScript: a self-executing function that creates a closure.

var util = function(){};
    var getAllDivs = function(){
        return $('div');
    util.prototype.addBorderToAllDivs = function() {
        getAllDivs().css("border", "1px solid black");
var u = new util();

BAM! exact same functionality, we still have a clean global namespace, and we didn't expose getAllDivs to the rest of the world.


Make sure you think of the "private" variables and functions inside the closure as singletons. The values of these fields will carry over between objects that use them. For example:

<pre class="line-numbers"><code class="language-javascript">
var util = function(){};
    var count = 0;
    util.prototype.incrementAndGetCount = function() {
        return ++count;
var u = new util();
u.incrementAndGetCount(); //=> 1
var u2 = new util();
u2.incrementAndGetCount(); //=> 2

What do I do with this new found knowledge?

You think with it. Rather than just slapping everything on an object's prototype, take a minute and think if it actually needs to be there. 

Remember, prototype is great for inheritance, so if something will never be extending the object, or an object's property will never be used outside of the object itself,  then maybe you don't need that value on the object's prototype.

How does AJAX work?

don't ask questions, just use $.ajax

Have you ever stopped to wonder "what the hell is going on there?" I love third-party libraries. There's no sense in reinventing the wheel every time you want to do something. AND, third party libraries help out a TON to prevent developers from implementing their own who-the-hell-knows-what for each task as it arises. However, when using a tool that does as much as $.ajax, it's probably important to have some idea of what's going on.

Quick! To 2006!

You might have missed it, but we just celebrated the 10th anniversary of $.ajax. In February of 2006, jQuery had ajax built into it and thus, we were relieved of every having to use the xhr object. 

"'xhr'? that sounds even cooler than 'ajax'".

It does indeed. If you thought Ajax sounds cool because it was named after Homer's Greek champion, I would congratulate you on knowing your literature, but smack you for not knowing your trade. "Ajax" stands for "Asynchronous JavaScript And XML". (Yes, it is very rare that the "And" actually makes it in the acronym.) 

XHR on the other hand stands for "Xml Http Request".

Remember, Ajax itself is not a tool, it's a process by which calls from the client are made to a server asynchronously. Ajax is the activity, XmlHttpRequest is the tool. Think of Ajax as "driving" and xhr is the car. It's what your dad used when he was writing JavaScript. And in the spirit of handlebar mustaches, flannel shirts, straight-blade razors, and Celtic tattoos all coming back into style, I wouldn't be surprised if the hipsters bring back using plain ol' XHR as well (cause jquery is just too mainstream).

Let's not get too far before providing the official Mozilla definition.

"XMLHttpRequest is an API that provides client functionality for transferring data between a client and a server. It provides an easy way to retrieve data from a URL without having to do a full page refresh. This enables a Web page to update just a part of the page without disrupting what the user is doing.  XMLHttpRequest is used heavily in AJAXprogramming.
XMLHttpRequest was originally designed by Microsoft and adopted by Mozilla, Apple, and Google. It's now being standardized at the WHATWG. Despite its name, XMLHttpRequest can be used to retrieve any type of data, not just XML, and it supports protocols other than HTTP (including file and ftp)."

Let's compare

So lets start with what we know and love. jQuery. Though ajax in jQuery isn't set up with real Promises, it carries a promise kind of feel where you can chain bits of functionality together. Today, we write an ajax request like this.

var xhr = $.ajax({
url: "path/to/url",
  method: "POST", //or "GET"
  data: {data1: "foo", data2: "bar"}
   //...do stuff if the call succeeds
   //...do stuff if the call fails
   //...do stuff if the call fails or succeeds

And there you have it! Simple ajax that works without you having the think about anything. You don't even need to know what the hell it does and it still works for you!

Now let's see how this would work without jQuery.

var xhr = new XMLHttpRequest();
xhr.open('POST', "path/to/url");
xhr.onload = function (response){
if(xhr.statusCode == 200){
 //...do stuff if the call succeeds
}else {
 //...do stuff if the call fails
//...do stuff if the call succeeds or fails
xhr.setRequestHeader('Content-Type', 'application/json');

If you're thinking "only people who worry about garbage collection and pointers would use that" I wouldn't totally disagree with you. BUT! In defense of those people, they do tend to be able to ninja things together that others might not think possible. AND, those people tend to write much much better code than you because they understand how things work in the background.

But How does it work?

Oh, right, your original question...

JavaScript is perhaps most beloved for it's non-blocking I/O powers. It does an amazing job telling other things to perform tasks while it moves on to other things. 

"Go take care of this job for me and let me know when you're finished."

This is made possible by JavaScript's event queue. It's essential a first-in-first-out collection of tasks that need to be taken care of. hen you set up an XHR object, you assign it data and you give it a function to perform upon completion. JavaScript's order of execution is centered around an event queue. As each task is completed, it move's on to the next task in line. (This is where the 'A' in Ajax comes from.)

So when the script hits the line "xhr.send([data]);", the browser kicks of an HTTP(s) request to the server with a special header added.

X-Requested-With: XMLHttpRequest

I don't want to go into the details of all the things this header does, so I'll just say for now that it allows the browser and server to determine which requests are page requests and which are Ajax requests which in turn allows for the policing of Cross Origin Request Sharing and prevention of Cross site request forgery.

Once the server has successfully sent back a response, either an error or a success, the onload function is placed in the event queue to be evaluated with the response from the server at the next possible opportunity.

To learn more about JavaScript's event loop, check out this explanation.

But What does Ajax even solve?

To get a full appreciation for Ajax, we have to go back. All the way back to the 90's, so grab your hair oil and scrunchies, cause it's gonna get real.


If you remember using AOL or MSN Messenger, then you probably also using Netscape Navigator. It was a dark, dark time. A time full of static content, 90 degree angles, solid colors, and inline styles. 

To combat the drudgery and allow web pages to be more engaging, Netscape introduced "LiveScript" which allowed for more dynamic content. This was still the 90's though, so don't think it was anything too impressive, cause it was basic.

This was back in 1995. While Netscape is loosing market share, Microsoft's Internet Explorer is growing in popularity. When the dotcom bubble finally burst in March of 2000, research and development budgets dried up along with the jobs and no one really cared about dynamic content anymore. That is, except for a multi-billion dollar company headquartered in the Pacific North-West.


By the time the bubble had burst, there were already scripts being used within web pages, so don't go thinking that Microsoft picked up the Client-side scripting flag and charged on alone. What it did do though was create a protocol by which scripts within the web-page could interact directly with the server. Prior to this new development, if you wanted to get more data from the server, you had to request a totally new page with new data.

This would have sucked if all you wanted to do was view a new image from a gallery. 

making it ubiquitous 

Google's Gmail was one of the very first services to really take advantage of this new XMLHttpRequest technology and make it mainstream.

Even back in 2004, even with hundreds of emails getting sent to you, you would have no idea without refreshing the page. Ajax allowed Gmail to update part of the page without refreshing the whole site [src].

The XHR object changed web development more than anything else up to this point. Modules in a page can not be loaded lazily. Simple pieces of information can be posted immediately, typeaheads are possible, multi-leveled dynamic forms are possible. Yes....yes indeed. We do love Ajax.


So now you know why Ajax is so damn important and how it works; which means you know more than 90% of your coworkers.