Archive for January, 2014

Front-end engineers have gone through a bit of a renaissance in recent years.

There’s been a wild and wonderful spurt in innovation that has completely changed what it means to be a front-end developer.

We now have a vast and wide array of tools available to us, allowing us to develop faster and smarter.

We now can push the limits of what a modern web browser can do, accomplishing things that two years ago seemed impossible.

Bottom line, right now is an amazing time to be a front-end developer.



Today there is almost zero friction to getting set up with a new project. Everything that you need to get started is only a few key strokes away thanks to some powerful new tools.

Git is the version control system of choice for most developers nowadays. It makes sharing code easy and frictionless. When you want to get going on a new code base you only have to run the simple git command of git clone and all the code and all of its history is downloaded directly to your computer.

NPM is the node package manager. It allows developers to package their nodejs code a self contained module and then share it with the community. There are npm packages that provide almost every type of functionality you can imagine, allowing you to leverage the work of the community. Each new project has their own unique set of dependencies they require for them to work. To get all these dependencies installed locally you only need to run npm install, which downloads and installs everything you need.

Bower is a package manager for third-party web libraries. Historically if your project requires jQuery be included you would have to navigate to the jQuery website, download the file, extract it, and move it into your project. Bower simplifies that process by giving you the command bower install which handles getting jQuery into your project.



Actually coding and developing your project is where most time is spent. Nowadays this is one of the most enjoyable parts due to the many wonderful tools available. These tools make dev’ing so smooth that I’d dare say it makes it fun. Scratch that – it makes it oodles of fun.

GruntJS is the most popular task runner amongst front-end developers. There’s already a huge community of grunt plugin authors that to date have written over 2,000 Grunt plugins, all of which are immediately ready for your use. Grunt allows you to automate rote tasks without breaking a sweat. For example if you need to compress all your jpg, gif, and png files you can use the imagemin grunt task .

CSS Preprocessors like LESS, Sass, or Stylus have made it easy to architect maintainable, extendable, and modular CSS. Among the many features that CSS preprocessors provide the two of most value are without a doubt nested selectors and variables. Having the ability to define a color variable in one location and use it throughout allows for a flexibility in CSS that did not previously exist, yet one that was sorely needed.

LiveReload changes the way you develop, as it brings a fluidity to your development flow that you didn’t realize you needed. Whenever you change a file that you’re working on LiveReload will notice that it changed and refresh your browsers so that you can immediately see your changes in place. No longer do you have to save a file, switch to the browser, and then refresh the page. With live reload after you save a file the browser will refresh itself, saving you time and grief.



When you’re ready to push some of your code into the wild it’s always a good idea to review it with your team and run it through some code quality and style tools.

A GitHub Pull Request is one of the handiest ways that you can rally your team around vetting your changes. After opening a pull request you’re given a page that allows you to clearly state what you changed along with a view that shows the changes you made. Coupled with a robust comment system, a GitHub pull request makes it easy for your team to review and give feedback on changes.

JSHint is a tool that programmatically finds errors in your code. It’ll prompt you if you have a function with two arguments, and the second argument is never used, or if you’re missing a semicolon where one should be. All these things ensure your code is in good shape, allowing your teammates to focus on other things that aren’t as nit-picky as JSHint.

JSCS is another tool that is great to have in your repertoire. JSCS is a JavaScript code style checker, focusing on the style of your code and not the quality. You define what code styles you want and when you run your code through JSCS it’ll alert you if there are any areas of your code that are not inline with your project’s expectations.



Getting your code from your computer out into the world is the best part of development, as it’s when you get to share all your work with the world at large.

Continuous integration is a practice that enables and encourages getting your code to production frequently and without fear of breaking anything. A CI server will automatically perform tests across all products, not just the ones you touched. If any tests fail alerts are sent out and any changes to production are halted, preventing regressions from reaching production. When all tests pass your changes are merged into the production ready branch, assets compiled, and production is updated.

This makes the entire process of getting your changes live easy, effortless, and safe. You can view the progress of the CI server as it chugs along, letting you be kept in the loop of what’s going on without having to push the process along yourself.


The life of a front-end developer has never been easier. Browsers are getting better every day, and the tools we have at our disposal have never been better.

No longer are we wallowing in the shadow of legacy browsers, but we’re barreling ahead to stretch what’s possible in the browser.

The processes outlined above lets you worry less about minutiae and just focus on development and the product.

The life of a front-end developer is pretty damn good.


Tony Haile Chartbeat

Today Fast Company announced the Most Creative People in Business 1000 – with Chartbeat CEO Tony Haile included in the ranks. The MCP 1000 is described as “an influential, diverse group of modern Renaissance men and women across the economy and around the globe. This is more than just a list: It is a rising community, an explosion of creative inspiration, the spur for so much breaking news across the quickly changing industries that Fast Company covers.”

Renaissance man, indeed. That baby-faced chap you know and love truly spends all day every day #disrupting and #innovating, fighting the good fight. Tony’s passion for building tools and solutions that equip publishers with business models to keep them around and thriving for decades to come is simply unmatched. Helping an entire industry change the way it does business through effective, sustainable metrics that measure the right goals isn’t something that happens overnight. Thankfully, years of polar exploring, circumnavigating the globe in a sailboat, and working with fifty Chartteam misfits every day forces one to be creative and resilient.

We couldn’t be prouder (or less surprised).

Check out Tony’s Fast Company piece on being the leader of Chartbeat or follow him on Twitter to get that British charm delivered to you in real time.

Tony Haile

At Chartbeat, we have the great privilege of working with thousands of the world’s online publishers, giving us access to one of the most interesting data sets ever. (Ever!) So, with 2013 wrapped up and 2014 now in full swing, we thought it’d be cool to do a little futurecasting… you know, use what we’ve learned from our own data studies—and from others’—to read the tea leaves. What will 2014 mean for data-driven journalism?

Yesterday, we hosted a webinar, “2014 Trends in Online Journalism,” with our good friends at the Online News Association. Joe Alicata, our Product Owner for Chartbeat Publishing, and Doug Benedicto, our UX Researcher, talked about everything from multi-platform news consumption to experimentation with content monetization. They also talked about how publishers are starting to focus on quality content and building loyal audiences.

If you missed the webinar—or just want to relive it—we’ve got the video for you below. If it’s just the slides you’re after, you can check those out over on Slideshare. We’d love to hear what you think, too: Which areas of online publishing do you think will be emerging, developing, or accelerating in the next year? Tweet us @Chartbeat. If you’re interested in a free trial of the new Chartbeat Publishing, send a note to



chartbeat annual report


2013 was a pretty fantastic year for online publishing. You hit huge concurrent numbers and created some amazing content that kept readers coming back for more.

As a thank you for including Chartbeat in your year, we wanted to pull together some aggregated data highlights for you to celebrate because, let’s face it, we couldn’t have done it without you.

Check out the 2013 Chartbeat Annual Report here.

Interior, startup office loft. Friday Afternoon.

SUIT: Hey dude, you know Feature X that we were asking for?

DEVELOPER: Do I ever! I spent all week working on Feature X, and you know, I’ve really started to take a special pride in how it’s turning out!

SUIT: What if—now hear me out—what if we didn’t do that at all. Let’s just cut it completely. Instead, we’re going to do Feature Y: we’ll graph this one thing against this other thing, and have it automatically annotate and blah blah foo bar etc etc…

This type of exchange is familiar to most developers, and particularly to those of us working in the startup world. The “suit” might be an executive, a product manager, or even a designer (it’s just more fun to call the person who’s telling you what to do a “suit” in this context1).

There are a few different ways this conversation can continue:

1. The developer refuses. She’s worked too hard on Feature X, and dammit, you’ll have to pry it from her cold dead hands!!!

2. The developer begrudgingly agrees to throw out her precious work and start again from scratch, but she’s really not happy with it. Deflated, she might not work as hard this next go-round, and the suit might not be quite as inclined to reimagine the product next time (even if it seems like the right thing for the product).

At Chartbeat, we aim for the conversation to continue something like this:

DEVELOPER: Yeah, we can do that. Actually, you know when I said I’m taking a special pride in this thing? It’s because I anticipated that you’d want to do several revisions of Feature X, and I built some flexibility into the code, so making Feature Y will actually not be so hard. I’m almost glad you asked for this change, because now I have the opportunity to amaze you with how fast I’ll churn this thing out!

Admittedly, that’s a completely contrived example and an exaggerated response. In real life, we’d probably try to see one version through and actually test it out with users before deciding to go in another direction (unless we’re in the extremely early stages of a product/feature). Also, a little bit of disappointment in lost work might be expected and is totally okay—we’re not robots. And from a development perspective, it’s not always best to spend extra time making code super-extensible/flexible if there’s a high likelihood that it will never be used outside of its original context.

Continuous Iteration

But my main point still holds: to end up with the best product we’re capable of creating together, we need to be able to change directions, and we should expect to change directions several times.

We don’t have (or want) the luxury of moving from “requirements gathering” to “specification” and then to “design” and “development” phases. All of those tasks are happening in parallel, all the time. As our user researchers and product designers continue their own iterative processes, the “ideal product” will become clearer and clearer. When presented with a new or revised product goal, the engineering team needs to be ready and able to quickly move toward that evolved goal.

Getting Technical

Today I’d like to talk about one way we enable this kind of flexibility through our engineering practices and technology choices. I work primarily on the front-end (the code actually running in your browser: HTML/CSS/Javascript), so that’s what I’ll be talking about2.

A few months ago, we were starting to build out a couple new products, and as is always the case when starting a new project, we had to decide whether to keep using our old tools, or make some changes. In particular, we had recently hired a number of front-end engineers who weren’t too keen on our Google Closure-based JavaScript code.

Closure: The Good, The Bad, and The Java

Closure has a lot of cool features, but its best feature by far is its compiler. Briefly, a compiler is the software that takes the easy-to-read code that you write and turns it into the small/fast code that runs in production. Closure’s compiler is extremely good at taking a large codebase—for example, our multi-product internal library along with the large standard library included with Closure—and pruning it down to only the code that is actually used by a program, and then smushing that code into an extremely small file. This feature has proven to be a huge win for our “pinger” code (the code that runs on our clients’ websites) since that code is downloaded about 10,000 times each second, and appeared on 71 million unique pages in the month of November. Making that code small is a win for everybody on the Internet, and the Closure Compiler does a tremendous job.

However, to achieve these awesome compilation characteristics, Closure requires the programmer to add a lot of special annotations to the code that are not normal to JavaScript coders. In effect, to the developer it “feels like writing Java,” which as we all know, is a terrible feeling3. Closure also suffers from a small and generally pretty inactive community, which makes it harder to find helpful resources and generally just less fun to use.

In the end (and after much urging from our newer hires), we felt that these drawbacks were significant enough that we should explore other options in the JavaScript space.

Weighing Alternatives

Several developers decided to spend a Hack Week (an every-7th-week tradition at Chartbeat) independently trying out a few different JavaScript frameworks/libraries that we thought looked promising. At the end of the week, every person who had tried AngularJS4 seemed to think it had a lot going for it. In a meeting of our front-end developers that went on for way too long, we hashed out the pluses and minuses of making a switch to Angular.

Changing technologies would mean a new learning curve—a short-term drop in productivity—for all of our front-end developers, so it wasn’t a decision we took lightly. On the other hand, those who had tried Angular during Hack Week were excited by its possibilities—we felt it would enable the creation of better features, with nicer/better code, and would boost productivity once we got over the initial hump. At the end of the meeting, we had decided to use Angular for our new projects moving forward, and even to abandon a Closure-based alpha version of one of our new products and rewrite it using Angular.

We continue to use Closure to maintain our legacy codebases and for our pinger code (where the benefits of Closure’s advanced compilation/compression are really huge) but all new projects are now using Angular.

AngularJS: Making HTML into an Application Language

In my mind, the biggest benefit of using Angular is its usage paradigm, derived from its core philosophy that HTML is a document language and what we want it to be is an application language. In short, where most other frameworks have you write vanilla HTML and then, through some code process, grab pieces of the document and “attach” behaviors to transform the static HTML document into user interface components, Angular in essence allows you to extend HTML by creating your own HTML tags for your user interface widgets. The tagline on the Angular homepage sums this paradigm up nicely: “HTML enhanced for web apps!”

To illustrate the difference, under the more traditional paradigm, we would probably create our graph by having some placeholder for it in our HTML document, like:

Then, in our JavaScript code, we’d have to explicitly find that piece of the HTML document, and insert a graph drawing into it. Our graph might have labeled X and Y axes showing, 3 different lines of different colors tracking different properties over time, etc. All of the configuration for this graph would probably be embedded in the JavaScript code: everything from the very existence of this graph—we have to know to actually find it on the page and insert the drawing!—to how many lines, what data the lines should graph, which axes to draw and how to label them, etc. Any changes to the graph will likely involve finding and changing JavaScript code, and will almost certainly require a “programmer” type of person.

Not Your Grandfather’s HTML

Using Angular, we’d have an HTML document more like this (simplified a bit here):

If you’re thinking, “that’s not HTML anymore! What are these graph, line, and axis elements?”—well, that’s the point, Angular allows us to “extend HTML” to create those elements! In our JavaScript code, we would write code (called Angular “directives”) to implement the graph, axis, and line components. Those components would provide generic graphing capabilities, and they would receive their configuration from the attributes in the HTML document—for instance, the line with name="typical-week"  above would know that it needs to plot the data contained in model.series.typicalWeek , as configured by the line-data  attribute. Our JavaScript code doesn’t even really have to know that the visitor graph exists! We have turned HTML into an application language that’s allowing us to piece the view of our application together in a really nice way, by placing and configuring our user interface components directly in the HTML.

3 Graph Variations
3 different stream graphs using the same model data but different HTML templates. The model contains several data series, and each template displays a different stream graph by choosing a different set of series.

Now, I’m glossing over a number of technical details here, but hopefully this gets the general idea across. The flexibility gains over a traditional setup should be pretty clear: when a suit decides we should blow away a graph and create a different one with different info, it’s entirely possible that we only have to change the HTML to make it happen! The level of technical proficiency required to do this kind of change is now lower as well—it’s much more likely that a designer (or even a suit!) can actually make the change without a developer and prototype or explore new ideas. This kind of flexibility would be possible without Angular of course, but Angular especially encourages it by its very philosophy of “HTML enhanced for web apps!”

Closing Thoughts

This post has just scratched the surface of what our front-end engineering team is doing to increase and streamline our responsiveness to shifting goals throughout product development. One final note regarding this continuous iteration process: make sure you hire the right people. Our developers, designers, and managers have a mutual respect and trust in each other’s abilities. Without that trust, constantly shifting goals can very easily lead to frustration and disappointment.

More in-depth technical information will be appearing on our engineering blog more frequently, so make sure to check that out in the coming months if you’re interested in the details!

  1. As developers we just love to think of ourselves as rebels, although if I’m being honest about suits here, it was actually the development team at Chartbeat that had a tradition called “Menswear Mondays.” It involved blazers. Also, our CEO seems to only have one outfit, and it’s not a suit, but jeans, a white button-down, and cowboy boots. It must be a… British thing? []
  2. Our back-end engineers also have all sorts of cool stuff going on. For instance, Vadim embedded a Lua interpreter in our real-time database so that we can quickly prototype new APIs! []
  3. Especially when you don’t have Eclipse to make the experience flow nicely. Yes, I programmed Java for a while. Don’t flame me, bro. []
  4. For more on Angular, checkout the official site and this blog post from our own Harry Wolff. []