###Mirrored from quickleft.com###
So with that out of the way, how do you figure out your growth plan for your project? When do you add Grunt or Gulp? Speed is always a priority for a developer, so if you slow down to add tooling and don’t see benefits, you’ve made the wrong choice.
####Unnecessary Code Running on a Page
You keep adding plugins, and kicking them off inside a giant
$(document).ready function. “But this page doesn’t have modals! Why does that even run here…” you say. Well, a solid solution here is to explore options for organizing your code to run by page. I’ve had success in the past using just the
Backbone.Router from Backbone to determined what parts of my code need to be set up. The downside here is introducing a dependency that you possible don’t use elsewhere, but the upside is cases where pages behave the same way, and you want to let them share as much code as possible.
team.js files that only pick and choose from the core file what functions get run on those pages. The downside here is that you are serving more files, but it is easy to organize.
####Developers Keep Breaking Things
Testing means you need a way to run them, which is often an npm script or Grunt task. If this isn’t part of your project, testing usually means you need to add some infrastructure, but it’s worth it to make sure your code is running as expected. Testing integrates nicely into a modern deployment workflow that includes continuous integration.
####My Page Loads Too Slowly
####I Reorder My Script Tags, Hoping Things Will Work
Script tags are generally loaded asynchronously, and evaluated as they are received. One slow connection can mean that your scripts are evaluated in an unpredictable order. For unassociated jQuery plugins this isn’t an issue, but as your code gets more complex the resolution order of your scripts becomes key to your site functioning.
####Writing HTML in jQuery is Error Prone
It is very common to see DOM manipulation look like:
$domNode.html("<div class='" + item.class + "'>" + item.name + "</div>");
and then call them like this:
$domNode.html( JST.itemRow(item) )
####No One Writes Code The Same Way
Some people like semicolons, and some heathens do not. Tabs vs. spaces is a conflict as old as computers, and don’t get a developer started on how to name things. This can be exacerbated by lots of people on a project, recent new hires or departures, and a long-lived codebase.
Luckily, a working agreement to use a style guide can address a lot of those problems, as can an automated linting process.
We find JSLint to be too strict and pedantic, so our projects will usually use JSHint and have a
.jshintrc file that specifies how code for this project will be written. By default we will also follow idiomatic.js on our projects, and adjust our base
.jshintrc to reflect those style choices.
Our editors can be set up to show errors as you type them, and our CI process will fail builds if the hint process doesn’t pass. This makes it predictable and easy to work on a project, and takes the human element out of most style arguments.
I presented this framework at jQuery Portland in 2013: