Take this simple quiz to find out. Do you…
- Break up and organize your code into small, easily digestible files?
- Keep only one canonical copy of third-party libraries?
- Use a deployment workflow, to concatenate and minify automatically?
- Automatically generate documentation?
- Unit test your business logic?
Lemme guess—sometimes, no, not really, no, and only when something breaks.
There’s never been a better time to learn to treat it that way.
Welcome to the Pro Workflows Series, part 1
Part 1: Break up & organize your code
Here’s an example from my app, Freckle (before and after):
A place for everything, and everything in its place. It’ll be easy to find the code you need.
|Easy to find code||A bazillion script tags|
|Easy to skim||Annoying to distribute|
|Easy to jump around your codebase|
|Easier to grow|
As you can see, the benefits are many… and the downsides have to do only with the fact that, well, now you have a bunch of small files. It’s not fun maintaining a bevvy of script tags in your project.
The good news: This is a problem we can fix directly.
Breaking Up Ain’t Hard to Do: Tools
There are two approaches for solving the “too many script tags” problem:
- Client-side loading tools
- Server-side concatenation tools
Read on for the skinny on each approach, the best tools to use, indicators and counter-indicators.
Client-side loading tools
The best tool: LAB.js. It loads your script files in parallel (while honoring dependencies), so it should offer improved performance over what its author calls “script tag soup.” And did I mention it’s prettier than script tag soup, too? And by far easier to maintain. (See that code sample below!)
When to use: If you absolutely can’t use a server-side tool, then you should use LAB.js. Or, if you’re deploying an app to an environment where speed is truly not an issue (e.g. an internal or local application, where everyone has super-high bandwidth and/or a short hop to the server).
Counter-indications: If your code uses
document.write() or you use a framework with “unsafe DOM-ready detection.” Or if load-time performance is very important.
<script> $LAB .script("framework.js").wait() .script("plugin.framework.js") .script("myplugin.framework.js").wait() .script("init.js"); </script>
Server-side concatenation tools
The approach: Create
The best tool: Sprockets. Sprockets is a Ruby-based pre-processor that your deployment workflow will love. No deployment workflow? Sprockets also comes in other flavors: a Ruby on Rails plugin (official), and a couple PHP ports (unofficial), for concatenating on page request.
Bonus: use Sprockets to store just one copy of third-party code (like your fave library) on your computer, and reuse it in all your projects by “remote” inclusion. Finally, Sprockets can automatically minify and gzip your code after it does its concatenation thing.
When to use: You’ve got command-line fu, and especially if you already do have a deployment workflow (or deploy rarely). If you can use the Rails or PHP plugin for your dev time, or if you feel like porting its (simple, clear) functionality to your own language of choice. You need the absolute best loadtime performance.
Counter-indications: You don’t care about download performance, or it’s simply too aggravating to add Sprockets to your workflow for whatever reason. If you are allergic to Ruby (and PHP).
On the command-line:
This sample shows off the “reuse” of a single Prototype.js library, to boot.
Load or Concatenate: Which one’s for you?
Now you’ve got the run-down on both approaches, are you still unsure which is the right choice for you? Maybe this will help:
require() functionality. You can just slot in those
require() statements where you need ’em.
Either way, however, the pay-off for a clean, compartmentalized code base is worth it… pardner.
Next week: How to use Sprockets. Subscribe so you don’t miss a thing!