1. 05 Oct 2014

    How We Use AngularJS: Part 1

    By: Jason Bishop


    In mid-2013 I fell in love with AngularJS. This is an important fact for me to mention before going further. I am absolutely biased towards this framework. As with all technologies, I do however encourage readers to carefully look at alternatives (Ember, the Backbone economy of tools, Knockout, etc.) before making a decision for any production code. This purpose of this post is not to convince you that AngularJS is the right tool for you; rather, the purpose is to explain why AngularJS is the right choice for us - and possibly for other people who find themselves in a similar situation! If you’re looking for a rundown of each framework, check out any of these resources:


    As a front-end developer and designer, JavaScript is one of the main programming languages I use on a daily basis. For the larger part of my career, I’ve had the luxury of great frameworks like Prototype and jQuery to smooth over some of the rough edges that come with executing JS inside of a browser environment.

    Some years ago, very intelligent thinkers began to bring aspects of MVC sensibilities to client-side code. This resulted in a proliferation of apps with rich, dynamic user experiences, the technical functionality of which was largely unaddressed by previously existing frameworks. For a while, Backbone was probably the best-known of these libraries (and perhaps still is). It gave front-end programmers access to a rich data model and interacting with server data became that much easier.

    Meanwhile, other tools were being built which encouraged JS-heavy projects. Node, of course, allowed web apps to be written entirely in JS for the first time. Today, JS apps come fully-equipped with test suites, scaffolding scripts, package managers, component libraries, and more. Some of the more popular tools include RequireJS, Bower, Yeoman, Jasmine, and the like.

    Front-end developers were now in a position to choose from a variety of resources with which to craft interfaces. In the case of Backbone alone, front-end developers may choose from tools like Chaplin, Marionette, and more (https://github.com/jashkenas/backbone/wiki/Extensions,-Plugins,-Resources).

    Enter AngularJS, a library which offers a common tradeoff: tons of rich functionality in exchange for flexibility.

    The Case For AngularJS

    So why AngularJS over other libraries? Isn’t Backbone the tried-and-true solution? Isn’t it preferable to be in a position to choose just the right tool for just the right use case all of the time? If not Backbone, why not Ember? For some developers and teams, those tools will be the right solution. For us, it’s AngularJS.

    #1. AngularJS makes choices for us and we like that.

    Developers, product managers, and other technologists are opinionated folk. Forming consensus is a challenge. Making the choice to use AngularJS means we can avoid conversations about solutions for data binding, dependency injection, and much more. We can spend more time engineering and less time in meetings.

    #2. Software engineering is a collaborative effort. AngularJS helps keep everyone on the same page.

    AngularJS contains a rich set of functionality meaning we have to turn to fewer libraries to get the same amount of work done. When new features, such as filtering, are implemented in the front-end, AngularJS provides a predictable mode of implementation. One result is that when another developer touches that piece of code, it’s purpose and function will become immediately apparent without detailed investigation. Adding new developers to the team is also significantly easier, since they only need AngularJS as a prerequisite as opposed to a stack of JS tools.

    #3. AngularJS has traction.

    According to many metrics, the popularity of AngularJS is on the rise (http://www.google.com/trends/explore#cat=0-5&q=angularjs,%20backbone.js,%20ember.js,%20knockoutjs&date=today%2012-m&cmpt=q). At the time of writing, Stack Overflow has a deep repository of AngularJS information, moreso than other popular clientside MV*’s (see: http://stackoverflow.com/tags). One might argue that AngularJS is simply trendy or that it incites the most ire amongst users online. Putting speculation aside, there is an indisputable bottom line: people are using it. This has many favorable effects, for example: 1) ease of hiring; 2) ability to hand off code and be reasonably certain that the recipient can work with it; 3) codebase longevity and overall community support; 4) availability of information online. Backing from Google doesn’t hurt, either.

    #4. We love its feature list and overall power.

    AngularJS is an extremely powerful library to build with. Implementing things like real-time search, template caching, and data binding, can be done elegantly and sustainably in seconds. Features like directives and animations are also neat add-ons that are well-addressed by AngularJS.

    #5. We love Rails. AngularJS loves Rails.

    Our full-stack and back-end developers spend a majority of their time writing Ruby on Rails code. It’s core to our business and, from a personnel-standpoint, institutionalized for now. Where other JS frameworks (I’m looking at you, Backbone.) only become very powerful when coupled to many other libraries while being managed by various JS-specific tools, AngularJS simply plays nicely with Rails. We don’t want to introduce additional technologies to do things like asset management when Rails already does that for us. Using AngularJS in a Rails project just requires a link to the Google CDN (although we use the AngularJS Gem). On a stack leveraging Backbone, other tools, such as Bower and Yeoman become much more attractive. For us, we want to stay within Rails’ ecosystem.

    What We Don’t Use AngularJS For

    As a sidenote, I thought it might be relevant to include use cases we prefer not to use AngularJS for:

    • Anything we want crawled by a search engine, for example, brochure sites. These sites aren’t often that interactive from a UI standpoint and AngularJS introduces unnecessary complexity in a use case that has been sufficiently solved by other tools. And the reality is that many people want to use no-frills WordPress (and are good at it).
    • Simple, non-feature-rich interfaces. We’ll just use a generic ERB for that.
    • Widgets or other small, discrete, embedded interfaces. For most widgets, including a framework is probably overkill. If it is a feature-rich widget, is it really a widget? Sometimes the answer is yes; oftentime the answer is no.
    • Projects with other MV*’s already in use. We think it’s probably better to not inject AngularJS into a project already using another library which provides overlapping functionality. This is because AngularJS in many ways functions as a self-contained state machine and managing that state outside of AngularJS can become cumbersome. In short, a general rule of thumb is: make your other front-end JS subordinate to your AngularJS code.

    Stay tuned for Part 2, in which I discuss how we set up our AngularJS projects!

  2. 08 Jun 2014

    Have You Ever Gotten a "$routeParams is Empty" Error Before?

    By: Mitchell Lane

    Here's a quick note that might help some people save some time digging for an answer.

    If you find yourself with a $routeParams that is empty or doesn't seem to work and there aren't any obvious errors causing problems, check to see if the call to $routeParams is being called from a controller inside ng-view. $routeParams only works inside ng-view.

  3. 17 Mar 2014

    On Bitcoins and Pull Requests

    By: Mitchell Lane

    Nightsprout now accepts Bitcoins!

    Starting this month, Nightsprout is now accepting Bitcoin payments through BitPay, an Atlanta-based Bitcoin payment solution provider.

    What does this mean for you? Simply put, we can now invoice and accept payments in Bitcoins! Whether you're an existing client or a prospective new one, send us an email at admin@nightsprout.com to learn more and/or begin to use Bitcoins. Changing payment systems does require some special action on our part, so make sure to let us know if you're interested.

    Pull Request Reviews as a Service

    Also starting this month, we're rolling out a new service -- Pull Request Reviews as a Service! We've talked to a lot of people who have requested something like this from us in the past and we've decided to formalize it as an offering.

    Pull Request Reviews as a Service is relatively straightforward. Nightsprout will get involved in your GitHub Pull Request workflow. Whenever a Pull Request gets opened on your projects, we'll review the code and point out potential technical and arcitectural issues that we see. There are quite a few benefits:

    • Technical Quality. We put an impartial extra set of eyeballs on your code, checking for technical issues and ensuring best practices.
    • Architectural Review. When we review a Pull Request, we'll consider the future implications of the code and how they fit with your business goals. If we notice any issues, we'll have a discussion to make sure everything is considered.
    • Mentorship. If your team is more junior and lacking someone in a mentorship role, we can provide guidance and initiate teaching moments through Pull Requests to help develop your team.
    • Risk Mitigation. Code reviews allow Nightsprout to get familiar with your codebase without doing active development on it. If you do have the need to engage us in active development down the line, we'll already be familiar with your existing codebase and ready to hit the ground running!

    We're offering Pull Request Reviews as a Service starting today in Ruby on Rails, AngularJS, JavaScript, and CSS/SCSS. If you're interested, drop us an email at admin@nightsprout.com to learn more!