i am rohn

thoughtfully linking code

Common Backbone Pitfalls

I use Backbone.js at work for front-end work and have found it to be a very pleasurable framework to work with, however I can’t disagree with this post; there are many areas where you can code yourself into trouble. I think Backbone really shines when you pair with it with an application architecture like Marionette or Chaplin. An application architecture will help you by reducing boilerplate code, zombie killing, event cleanup, and more. Choose Backbone, but pair it well.

Ignore Git Globally

An easy to understand introduction to global .gitignores. And for some samples check out this github repo.
This is a great alternative (and the right way of doing it) to adding OS specific files to every project’s .gitignore file. No longer will my coworkers need to roll their eyes at me when I add .DS_Store to our .gitignore in the repo (and maybe I can get them to stop littering the repo with Thumbs.db files too).

The official github help page.

Promises… Promises… Promises…

JavaScript is asynchronous and event-driven. Operations that take a lengthy amount of time are non-blocking - you don’t want to call a function and block until it completes. Instead you provide a callback, which is executed (or invoked) when the lengthy function completes. This is efficient and friendly, avoiding the need for threading, but gets a bit harder to implement when you have a series of operations that need to be executed one after another. This is where the Promise pattern comes in.

Avoiding This

If there’s one thing I’m hearing repeatedly while attending the FrontEnd Masters Workshop Series is that it is much more important to write readable code than to be worried about cute coding tricks or hyper-efficient code. Don’t misunderstand, performance is important - or as Kyle Simpson says, “performant by default” - but not at the expense of maintainable code.

Backbone.js With Pow

I found myself in a situation where I needed to serve a static site (in reality a Backbone.js webapp) through my running Pow! installation. The solution was extremely easy to find but I thought I’d list it here anyway.

The documentation indicates that your folder structure must include a public folder inside your project folder. This would have conflicted with the directory structure of the application that I’m contributing to, so I simply wrapped my project folder with a company folder, which in turn holds the public folder:


or another way to view that is: