contact us

Use the form on the right to contact us.

You can edit the text in this area, and change where the contact form on the right submits to, by entering edit mode using the modes on the bottom right.


San Francisco, CA, 94160
United States

Writing

Why I Hate `var self`

Jesse Atkinson

I hate var self. I hate it. I hate it and its sister var that. Let's not even speak of the black sheep of the family, var _this — lest we wish to conjur up other barbaric practices conducted by lesser JavaScript developers.

No no no. var self is for the weak. The unsure. The impotent. The wallflower shoegazers of the JavaScript world who are too scared to ask their code for a bloody dance.

"Why do you hate this thing that seems to permiate many JavaScript libraries penned by competent and skilled devs. Devs more skilled than you even!"

I'm glad you asked.

I hate var self because var self represents failure. A failure to use what the language has given you and intended for you to do. JavaScript gives you this. And this, as you well know, represents... well... this. The thing you're currently acting upon. When you assign this to a variable and then reference that variable in some scope below you are admitting all devs who will interact with this code in the future and yourself that you failed. You failed to give this thought. You've failed to leverage the tools JavaScript has so graciously provided you. Of course I'm talking about .bind and its cousins .apply and .call.

Let's go over an example. Here's a bit of code that leverages that. I'll assume we have access to jQuery, but this applies to even without. (Lets pretend, for example's sake, that we are doing somethign more complex with data here than simply passing it to doSomethingWithTheData. Otherwise we could pass doSomethingWithTheData as the callback function for done.)

var that = this;

$.ajax({
  type: 'GET',
  url: '/api/v1/auth/user/current/',
  contentType: 'application/json'
}).done(function (data) {
  that.doSomethingWithTheData(data);
});

Now lets rewrite this so that we do not have to store this in a variable using bind.

$.ajax({
  type: 'GET',
  url: '/api/v1/auth/user/current/',
  contentType: 'application/json'
}).done(function (data) {
  this.doSomethingWithTheData(data);
}.bind(this));

Lets make this even better. We'll assign the callback method to a named variable and bind the callback method to this. Finally we'll change that verbose $.ajax into the shorthand jQuery method for specifically fetching JSON.

var onDone = function (data) {
  this.doSomethingWithTheData(data);
};

$.getJSON('/api/v1/auth/user/current/').done(onDone.bind(this));

"But Jesse, I'm not familiar with bind. What browsers support bind?"

I'm glad you asked. IE9+ as well as any remotely modern version of Chrome, Firefox, and Safari. (See this link).

"Okay. Fine. But this is a seriously trivial discussion. Why do you care?"

That's a fair question. I will admit that it is trivial in the grand scheme of things. If you tell your manager you'd like to take next sprint to change all variable assignments of this they would rightly look at you like you were insane. However, when building a product part of building it is building it well. You can choose to ignore this advice. You can also write your entire app with mixed line endings, no whitespace, no comments, and bind every object to the global window. But chances are if you're still reading this it's because you care. You care about not only your product working but the code that you write to create your product being readable and maintainable, especially for other coders. My argument against var self stems from my hatred of confusion and discord and my love of legibility and clarity.

P.S. Ever have trouble remembering the difference between .call and .apply? Here's an easy way to remember. .call begins with the letter "c". You pass in all of the parameters to the method you invoke with .call using commas to seperate the params. I.E. foo.call(this, bar, baz, bing);. .apply begins with the "a". You pass in all of the parameters to the method you invoke with .apply using an array. I.E. foo.apply(this, [bar, baz, bing]);.

On Text Editors — Part 6

Jesse Atkinson

This is the last entry in a six-part series on my history of text editors.

What about Atom and BB Edit?

One you'll notice that I've completely skipped over Atom and BB Edit. Atom, if you don't know, is essentially Github taking Sublime Text, making it work entirely in a browser, and putting a little bit of their own stamp on it. It's a great text editor and a novel approach, but it is embarassingly slow and even more embarassingly a shameless ripoff of Sublime Text. Github, like many, are frustrated by the state of text editors and how each owner of them seems to abandon them. At least the owner of TextMate had the good sense to open source it and release it into the wild. If you like the look and feel of Sublime Text I'd say give Atom a shot. However, last I tried it out (roughly two months ago) it was a slow and sluggish beast.

BB Edit is absolutely fantastic. It's an incredible app with a long history of development and support. It's really well done. I recommend it whole heartily. However it veers sharply into the IDE territory which is not what I'm looking for. It's just not for me.

Conclusion

TextMate is, in my opinion, the most mature text editor out there. The fact that it is open source and free just speaks to how absolutely insane this industry, as well as the state of the tools we use to build it. is. I can wholeheartedly recommend Coda, VIM, Sublime Text, or TextMate to anyone. I think they're all excellent choices, but for me (at least for now) the choice is clearly TextMate.

On Text Editors — Part 5

Jesse Atkinson

This is the fifth entry in a six-part series on my history of text editors.

The TextMate Phase

Once the Yosemite beta came out in summer 2014, and I'd heard from trusted friends and co-workers it was actually pretty stable, I did something stupid and installed it on my work machine. I figured I'd be able to identify what parts of our app wouldn't work on Yosemite and potentially contribute to some RubyGems to get them ready for Yosemite.

Sublime Text ran awful for me on Yosemite. Mostly because one of the billion packages I had installed on it kept crashing it. In frustration one day I just switched to TextMate. Fully assuming I'd move back to Sublime Text once the packages for it got updated to run on Yosemite.

And then a funny thing happened. I never switched back. In the two or so years since the 2 alpha was released for free and open-sourced, TextMate got really fast, really good, and, dammit, it was pretty. This is an OS X-only app that was clearly made by someone with taste. Someone who is an OS X user, who knows what those of us who live and work on OS X want in an app, both from utility as well as design standpoints.

I enjoyed having an actual preferences pane. I enjoyed installing bundles with a GUI. Wait ... why didn't I start using this earlier? Oh yeah, because there were little things about it that drove me nuts. But turns out after a quick Google search, I found out how to enable and disable various bundles. The main thing Sublime Text still had that TextMate didn't have (at least not out of the box) was autosuggest when typing in a method name. However, I quickly learned that ⎋(esc) would autocomplete, and it did a pretty damn good job of guessing what I wanted it to autocomplete to.

Another huge benefit of TextMate was how damn good the multi-cursor support is. Sublime Text has it, but not like this. TextMate (as of this writing) feels like one of those apps that was made specifically with nerds like me in mind. It has all the things I care about in spades and the things it doesn't have I don't mind so much. I've been using TextMate 2, which has now gone into "beta" (it's stable, don't fear) for the past six months and haven't once felt the desire to switch back to Sublime Text.

On Text Editors — Part 4

Jesse Atkinson

This is the fourth entry in a six-part series on my history of text editors.

The Sublime Text Phase

After a month of interviewing and job hunting, I ended up at TuneIn. This meant moving from Detroit to the Bay area. I started off in VIM, but was eventually convinced by a friend to try Sublime Text again. The beta for 3 had just come out and was pretty stable. So, I checked it out. I was surprised by how much I liked it. After a day of using it, I didn't see any reason not to keep using it. So I did. Once again, I poured myself into the app learning everything I could about it. In fact, I even wrote a starter guide for it that I would give to friends who code or new employees who were unfamiliar with Sublime Text.

Sublime Text (particularly Sublime Text 3 beta) felt like the culmination of years-long frustration at the lack of updates to TextMate and the lack of sensible choices for devs who didn't want to use a fully-fledged IDE. I'd used Sublime Text on and off, but I was never able to use it full-time, day-in-day-out due to how my previous job was.

Sublime Text is, as of this writing, still probably the most versatile and potentially best text editor out there. It's incredibly customizable. It's cross-platform. It's lightning fast. And, it's... ugly.

It's that final point — an intangible one — that most devs seem not to care about. You can customize the hell out of Sublime Text's look and feel with themes. No matter how much I fiddled with it, it felt like putting lipstick on a pig. A very abandoned pig, I might add.

Still, Sublime Text was the best tool for the job. It worked really, really well. It was just not very polished. Then, along came the OS X Yosemite beta.

On Text Editors — Part 3

Jesse Atkinson

This is the third entry in a six-part series on my history of text editors.

The VIM Phase

I stayed at Team Detroit as long as I could. The problem was Ford thought we were all too expensive (remember that salary I got?). They decided to outsource all of their web development to Buenos Aires, Argentina. And this is when I learned a super-valuable lesson — make your boss like you.

My boss and I got along great. He pulled me aside one day and told me that I was going to be laid off soon. We all were. He didn't know when exactly, but I probably had three months at best. One of my favorite project managers from MRM was working at ePrize (now known as Hello World). I didn't really want to leave Team Detroit, but I had friends at ePrize and I knew I was getting laid off soon and didn't feel like job hunting, so I applied and got the gig.

One of the things that made me incredibly happy about the new job was this was the first job where I got a MacBook Pro. Previously, I was stuck on Windows machines: XP at MRM and 7 at TDI. Naturally, I was excited to get back to using my code editor of choice, Coda, rather than being forced to use Eclipse. In my absence of being able to code on a Mac for my day job, TextMate 2 alpha had been released into the wild. However, the new kid on the block that everyone was telling me to use was Sublime Text 2.

Excited, I began this new gig using Sublime Text 2. I read every article on all the tips and tricks I could find. The problem came when I realized ePrize had an incredibly asinine way of managing their codebase. Their codebase was remote and only remote. There was no pushing and pulling from your computer to a remote server. You had to connect to the remote server and work directly on it. Yes, I'm dead serious. Yes, I asked a lot of "Why is this this way?", but received no satisfactory answers. It was what it was. Most of my co-workers used a system of mounting the server as a drive and editing the files using Coda or Sublime Text 2. The problem was anytime two of us had to work on the same branch, we'd end up overwriting each other's work. You see, when you mount a drive and open a file on it your computer downloads and caches that file. When you save, it uploads the change. Next time you open the file it doesn't re-download it. It simply opens up the local copy it has. This is a problem if two people edit the same file. They will never realize that the other person has modified it.

The only sure way to avoid this is to actually work on the server. The cleanest, easiest, and most hassle-free way to accomplish this was with VIM. I'd never used VIM except to write commit messages. I knew very little. Since I refused to follow this asinine and reckless workflow, my co-workers and boss insisted on using, I had to double-down on learning VIM. And boy did I ever. Again, I read everything I could about VIM. I learned that tool inside and out, backwards and forwards. I became an evangelist for VIM. Singing its praises and looking down my nose at other, lesser developers who had to have fancy things like a UI in their text editor. Man, did it ever feel good to be superior!

And I was superior in one way:I was the only developer who never accidentally overwrote his co-workers code. This sort of thing was rare, but it still happened every few weeks. Someone would inevitably overwrite another developer’s code. They never did learn (I think you can see why I didn't stay there long).

However, I was not superior in many other ways. In that VIM is not actually better than Coda or Sublime Text or TextMate or any other editor. It's just extremely different. After a year of working at ePrize, I quit. I hated the job and decided to leave even without another job lined up.