Being A Frontend Developer For A WeekEndClermont-Fd Area, France
I noticed that the only things a frontend developer needed was a smart
API, and a good documentation. As a backend developer, you have to provide
both. The frontend developer depends on you.
Also, don’t force your frontend guy to use your tools. Yeah,
Assetic is a wonderful toy for PHP
developers, but it’s not a tool for frontend guys. There are better tools to
Grunt. Let your frontend developer manage his own
stuff. For example, in a Symfony2 project, I would recommend to put all JS/CSS
files into the
web/ folder rather than into the
folders, so that the frontend guy doesn’t have to browse the whole project to
find a specific file.
But this is not the purpose of this post. Let me explain why and how I wrote TravisLight, and the tools I discovered.
As working on a project is the best way to learn, I decided to write a Backbone.js application using the Travis-CI API. TravisLight was something I always wanted in order to manage my own open source projects. I needed a tool that was simple and clear. That was the perfect project to start, especially for a weekend.
Instead of using Underscore.js, I used Lo-Dash which is an alternative to Underscore.js delivering consistency, customization, performance, and extra features as they say. I also used RequireJS, and Moment.js. In order to manage all these dependencies, I needed a tool, so I took a look at Bower, from the Twitter guys.
Bower, A Package Manager For The Web
Bower is a package manager for the web, in
other words, a package manager for JS/CSS libraries. Even if it’s more
a package downloader for now, it’s worth using it to avoid versioning
Bootstrap, etc. All you need is a
component.json file that looks like:
bower install installs the dependencies into a
So, I started to work hard on my application. Each time I needed a new library,
bower install <lib> --save to install it and update the
In TravisLight, I mainly use Grunt to package the application. Packaging the application means:
- compiling the CSS files;
- using the compiled files into the HTML markup;
- copying the required libraries.
Compiling the CSS files in TravisLight is a two-step action. First, all images in the CSS are embedded using the grunt-image-embed plugin:
Then, the CSS files are minified using the grunt-contrib-mincss plugin:
Now, I just have to compile the HTML to use these compiled JS and CSS files. It’s achieved by using the grunt-targethtml plugin:
index.html file looks like:
target dummy is the default piece of code, used in development. This is a nice
way to keep a single HTML file with the ability to switch from development to
production (or whatever environment you want).
That was an issue I was unable to solve until I found this plugin.
Last but not the least, the
is the one I used to copy some files to the
grunt package performs all these tasks. See the TravisLight’s
for more details, especially the aliases.
Testing A Backbone.js Application
npm install installs both Mocha and Chai in the
Now, you need a
test/index.html file to run the test suite in a browser:
First, Mocha and Chai are loaded, followed by jQuery and RequireJS. Then, a
setup.js file is loaded. It contains the Mocha and RequireJS configurations,
and two global variables
expect that will be used in the test
I decided to follow the BDD style, but it’s just a matter of taste.
Here is an example of test file for the TravisLight’s
You can look at the
directory for more
I am a big fan of Travis-CI, and I wanted to put TravisLight on it. Thanks to Grunt, it couldn’t be easier!
grunt mocha runs the test suite using PhantomJS:
$ grunt mocha Running "mocha:all" (mocha) task Testing index.html...................OK >> 19 assertions passed (0.14s) Done, without errors.
Not bad. However, Travis-CI needs to be configured using a
node_js environment on Travis-CI, and the
application requires a set of libraries installed through Bower:
Travis-CI will run
npm install first, and then
npm test. This second command
has to be configured in the TravisLight’s
Generally speaking, I think working on frontend applications changed my mind regarding APIs. Also, working on a real project, even a small one like TravisLight, allows you to understand things faster than ever.