Andrew is a product-centric web developer with a lot of opinions. He has been with companies from the SitePoint family since 2006 — first at Flippa for 6 years, and now with 99designs

Andrew's articles

  1. Using GNU Make as a Front-end Development Build Tool

    The popularity of CSS preprocessors like Sass, and task runners like Grunt have made a build process an accepted part of front-end development. There’s no shortage of options or opinions in the task-runner/build-tool space, with the most popular being Grunt and Gulp. I write a decent amount of JavaScript at work and in personal projects, […]

  2. Flight is the Right Choice for Your Existing Website

    At the beginning of 2014 I’d never even considered using Twitter’s Flight JavaScript component framework, yet here I am unequivocally stating that it’s the right choice for your existing website, which I probably know nothing about. I’d better explain myself while you ready your pitchforks for the comments section.

    Let Me Paint You a Picture

    Flight is what Twitter is made with. Flight doesn’t get much press because its specialty isn’t fancy single page app demos with data binding, but for real world web apps built on primarily server-side codebases. Its design is entirely, and solely, components and events. There are no instance variables. There is no magic. Data components fire events to broadcast data, while UI components listen to data events and in turn fire their own UI events.

    Flight components are exceptionally decoupled, in no way “take over” your page (unlike Angular’s ng-app), and are by their decoupled nature very easy to test, to migrate to/from, and to refactor. The cognitive load of inheriting maintenance of existing Flight components or refactoring existing components is dramatically lower than what is possible with Backbone or Angular and you don’t end up leaking or duplicating domain logic into your app like you do with Backbone or any JS framework which includes models.

    Why Flight?

    Your team has been working on a website for a few years. It’s primarily driven by a server-side technology — Ruby, PHP, Python, .Net — and that’s where you’ve solved the real domain-specific problems. Many of these solutions are the reason for your site’s success. Along with these server-driven features, you’ve continually added more JavaScript enhancements for improved interaction, snappier interfaces, that sort of thing. Maybe it started as jQuery spaghetti gluing together other people’s plugins. Maybe there’s some jQueryUI in there or Backbone, Angular, or Ember that performs well enough in their isolated corners of the site.

    As these enhancements age and multiply, you start to notice a disturbing trend. While your business logic primarily lives on the server-side with its test suite and QA tooling (RIGHT?!), more and more is having to be replicated in the JavaScript layer. You don’t want to double up, but you have logic in your UI now and it needs to make the right decisions. Similarly, the custom components and formatting helpers you have accrued on the server need to be replicated on the client side to turn your API responses into correctly formatted views.

    So now you’re at a crossroads. Do you continue down this path, replicating logic across two codebases and risk them getting out of sync, or do you decide to refocus your energies on an API-backed “thick client” approach with one of the big JavaScript application frameworks?

    What about a third option – one that allows you to avoid rewriting your core business logic and view layer while giving you an extremely loosely coupled, lightweight JavaScript methodology that is highly testable, easy to understand and refactor, and most importantly allows to you gradually move from your mishmash of existing JavaScript features. What if this same alternative was just as easy to migrate away from if you one day decide it’s no longer the right fit, all the while allowing you to easily innovate by getting new ideas in front of your users quickly and with confidence that they’ll work as intended?

    Option three sounds good to me. So how does Flight propose to deliver these lofty promises?

  3. Social Bookmarking vs. Visual Clutter

    Some of our recent blog posts have ended up on the front page of Digg and, garnering a massive influx of traffic. Traffic spikes to webmasters are like the first taste of candy to a child — once you’ve had that taste, you want more, more, MORE!. Ahem. You get the picture. Following this, […]

  4. The Day Digg Ate Itself

    It’s been an interesting 24 hours for the darling of user-driven content, digg. Upon removing an item regarding the discovery of the processing key that unlocks AACS copy protection (used in both HD-DVD and Blu-Ray discs), digg was overwhelemed by a flood of angry users, submitting and digging more stories containing the now-legendary hexidecimal string. […]

  5. Losing REST over Ajax Errors?

    All too frequently, I see Ajax examples where the response is handled like this: (pseudo-code used for demonstration purposes) xhr.onreadystatechange = function() { if ( xhr.readyState == 4 ) { if (xhr.status == 200) { // Process returned data (eg: Parse XML). // Check status of result depending on custom/ad-hoc error detection. // — most […]