In my last post, Yeoman, Backbone, and a Smarter Client, I discussed diving into the new development-minded technologies that have flooded the JS proverbial toolbox. The first project I put together with said tools is MaxWell, a single-page web app for graphing your point totals in ESPN’s Fantasy MaxPart games (think Pigskin Pick’em and ESPN’s march madness game, Tournament Challenge). Yeoman and the Yeoman Backbone generator were used to bootstrap the application. RequireJS is used to manage dependencies. The application itself lives inside a Backbone framework. Grunt is used to build the webapp and prepare it for deployment. Finally, the app is deployed using git and it lives on GitHub pages.
I have just gotten started using the Octopress framework for blogging, and I love it. The setup process is unbelievably well-documented, and if you’re familiar with Git and Ruby projects, you’ll pick it up fairly quickly. The only issue I had early on was pushing my new blog up to Github for version control. It’s a little tricky since the first step is cloning from Brandon Mathis’ Octopress repo, but the fix is relatively simple.
I have gone through a number of tutorials on newer front-end tools like AngularJS, Grunt, and Backbone. Nothing compares to building something of your own, though. After dipping my toe into the water numerous times before, I dove into the deep end and started combining these tools on my own.
I normally feel fairly well-versed in Git, which is to say, I can commit code, I can see what’s happening, and I generally know enough to not screw anything up. I thought my Git Fu was tight enough that I at least had a good grasp on all that could be done with the version control system until I came across a project that used submodules. In Git, a submodule is a connection from one repository to another. Say, for instance, you’re working on a suite of similar products. You want each one to have its own repository. That makes plenty of sense. But suppose each of these products shared a common messaging platform. Instead of maintaining this same code across the suite of products, which would defeat a lot of the purpose of setting up a VCS, you can give it its own subrepo, and have each product in your suite set up a submodule to reference that repo. All seems well and good, but there are a few gotchas to keep in mind.
As I’ve started diving into more client-side heavy web apps, I’m finding myself constantly asking why any given tool was developed. Lots of web technologies can look cool, but what problem is each trying to solve. Bower was one that mystified me, even as I let Yeoman go ahead and install it in my latest project. It describes itself as a package manager for the web. As a user of npm, I was aware of various packages and tools that can be installed, but I did not understand what packages Bower could be capable of handling. What problem is Bower trying to solve?