
Over the past two years, I have spent a lot of time thinking about how to design accessible color palettes. I first became hooked when I discovered the [IBM V1 Color Library](https://www.ibm.com/design/v1/language/resources/color-library/). They defined the color palette by hue (red) and had 10 shades (1, 10, 20,...90). The absolute value of the difference between two shades had a special value. If that value was greater than or equal to 50, those colors had a contrast ratio of 4.5 or greater. That meant the color pair was AA accessible.

I wanted to know how they achieved that property. I spent a lot of time trying to analyze the relationships between the colors in RGB and HSL space. I did not find any pattern because that was the wrong space to analyze. I needed to think in contrast space. I came to think of color as the ratio of the white contrast to black contrast. I even made a tool to help find colors in the "[Hue Saturation Ratio](https://codepen.io/pspeter3/full/BOPOBR)" space. However, the tool was not as useful as I had hoped.

Almost a year later, I discovered the United States Web Design System. They also defined their color palette by hue and shades which had special values. Unlike the IBM Color Library, they supported even more special values. A value of 40+ had a contrast ratio of 3+, 50+ had a contrast ratio of 4.5+, and 70+ had a contrast ratio of 7+. Those contrast ratios are the common ones defined by the WCAG for accessibility. As a developer, knowing the accessibility of a color pair is invaluable. I wanted to know how they achieved that property.

I remembered that you compute contrast ratio from luminance. The contrast ratio of two colors is `(MAX(L1, L2) + 0.05) / (MIN(L1, L2) + 0.05)`. The luminance for white is 1 and the luminance for black is 0 for a max contrast ratio of 21. Using that information, I started to think of the problem as a set of constraints. Each shade must be within a bounds of luminance. Working from both white and black, I started to discover the bounds of shades. Eventually I discovered the following tables.

## Luminance Bounds

| **Shade** | **Upper Bound** | **Lower Bound** |
| :-------- | --------------: | --------------: |
| 0         |          1.0000 |          1.0000 |
| 10        |          1.0000 |          0.6500 |
| 20        |          0.6500 |          0.4750 |
| 30        |          0.4750 |          0.4000 |
| 40        |          0.3000 |          0.2875 |
| 50        |          0.1833 |          0.1750 |
| 60        |          0.1056 |          0.1000 |
| 70        |          0.0667 |          0.0500 |
| 80        |          0.0500 |          0.0250 |
| 90        |          0.0250 |          0.0000 |
| 100       |          0.0000 |          0.0000 |

## Average Contrast Ratio

| **Shade** | **White** | **Black** |
| :-------- | --------: | --------: |
| 0         |      1.00 |     21.00 |
| 10        |      1.25 |     17.50 |
| 20        |      1.75 |     12.25 |
| 30        |      2.17 |      9.75 |
| 40        |      3.06 |      6.88 |
| 50        |      4.58 |      4.58 |
| 60        |      6.88 |      3.06 |
| 70        |      9.75 |      2.17 |
| 80        |     12.25 |      1.75 |
| 90        |     17.50 |      1.25 |
| 100       |     21.00 |      1.00 |


Accessible Contrast Shades


Last week, I was talking with Jim Brikman about the JavaScript Promises/A+ spec and how Scala really nailed asynchronous programming with their Futures interface. On Friday morning, he sent me an initial example that brought the niceties of Scala to JavaScript, but the code didn't match the Promises/A+ spec - something which I felt was important for working with other Promise libraries.

So in an attempt to better understand the spec (and just for the fun of it), I decided to write my own implementation to try and write something faster than what was already available in the community. I started by reading through [http://modernjavascript.blogspot.com/2013/08/promisesa-understanding-by-doing.html](http://modernjavascript.blogspot.com/2013/08/promisesa-understanding-by-doing.html) to learn how to implement the spec and I ended up with concurrent, a performant Promises/A+ library with Scala awesomeness: [https://github.com/pspeter3/concurrent](https://github.com/pspeter3/concurrent).

## Promises/A+

Initially, I tried to implement the spec by downloading the community test suite [https://github.com/promises-aplus/promises-tests](https://github.com/promises-aplus/promises-tests) and running my code against it. The tests were a bit overwhelming at first, and I had a hard time figuring out how they were related. After reading (and re-reading) [http://promisesaplus.com/](http://promisesaplus.com/), I decided to try to use the node [EventEmitter](http://nodejs.org/api/events.html#events_class_events_eventemitter) class. I figured the event emitter could track all of the events, call them in order, and ensure each callback would only be executed once. This took care of most of the spec, but made it difficult to ensure as the EventEmitter started complaining about memory leaks.

Backtracking to a simpler approach, I created a chain of callbacks like the example on the [Modern Javascript blog post](http://modernjavascript.blogspot.com/2013/08/promisesa-understanding-by-doing.html). I realized that separating success and failure callbacks wasn’t optimal because a callback was necessary whether or not onFulfilled or onRejected was a function - keeping the two functions separate kept half the callbacks in memory regardless of if the promise was fulfilled or rejected. After some tinkering, fixing a minor infinite loop bug (only in the background of each promise), and some [simple logic changes](https://github.com/pspeter3/concurrent/commit/4896bd367132dbaf077e603dd99e3f55fe11aaa6), I was ready to test.

## setImmediate

From the start, I wanted to design a library to work specifically with node.js that blocked the event loop as little as possible. While some libraries resolve promises in the same event loop, I decided to spread them out to execute one callback per event loop. I knew this would have some performance cost, but hoped that it would prevent any promise from blocking the event loop.

Traditionally, developers have used process.nextTick for scheduling callbacks. One downside of nextTick is that it lumps all of the callbacks on the next event loop (unless they exceed the maxTick limit, in which case they go to the following event loop). Alternatively, setImmediate queues each function over all event loops so only one callback runs per event loop. Consequently, concurrent isn’t as fast in sequential tests, but has the potential to prevent an I/O bound system from stalling under heavy load (I haven’t benchmarked this yet, but hope to soon). Other benchmark results for concurrent can be found here: [https://github.com/pspeter3/promise-perf-tests](https://github.com/pspeter3/promise-perf-tests)

## Scala

I work a lot with Scala and Play! at LinkedIn, and I really enjoy how the API deals with asynchronous events. The functional approach and ability to chain futures together makes it incredibly easy to design and modify complicated asynchronous dependency graphs. Given that Futures in Scala and Promises in JavaScript are somewhat similar, I decided to add as much Scala sugar as I could - just to see what happened. The results were pretty good, but lacked the same magic as many of the Scala versions. Scala’s pattern matching and partial function application enables it to make static typing (traditionally not as expressive) more expressive than its dynamically-typed equivalents. The Futures class still works well though, and the documentation can be found [here](http://pspeter3.com/concurrent/future.js.html).

## Collections

Finally, I liked how the [async](https://github.com/caolan/async) library supports ES5 collection iterators for dealing with larger data sets across the event loop, so I decided implement them with concurrent as well, and built them using the setImmediate discussed above. This led to a performance tradeoff - it’s not as fast as other libraries resolving on the same event loop, but is less likely to block the event loop and thus starve I/O. Benchmarks of map and reduce are in the performance test results: [https://github.com/pspeter3/promise-perf-tests](https://github.com/pspeter3/promise-perf-tests).

## TL;DR

I created a performant Promises/A+ library using setImmediate and a lightweight Promises implementation that doesn't block the event loop. Then I added Scala syntactic sugar and ES5 iterators to make the library easier to use. Finally, I made sure it worked with other Promise libraries and the browser so developers could easily use it wherever they want.


Concurrent: A Performant Promises/A+ Library with Scala Awesomeness


To give some context before I start, I primarily work on application servers, starting in Ruby with [Rails](http://rubyonrails.org/) and [Padrino](http://www.padrinorb.com/) and now working with [Express](http://expressjs.com/) and [Play!](http://www.playframework.com/). I wanted to learn how to make single page JavaScript applications to display the data I returned from my RESTful backends. Here is what I found so far.

## Backbone

[Backbone](http://backbonejs.org/) seems to be the C of client side frameworks. It gives you the bare minimum above the ES5 spec with underscore and then provides an eventing system for components to interact on the page. I found that Backbone was the most effective when used for progressive enhancement. The dependency on jQuery or Zepto and not specifying how data should be rendered makes it easy of Backbone to literally become the backbone for your jQuery event handling. Views in backbone essentially become the controllers and handle client events and bind it with the models and the collections.

Actually using Backbone for a single page application became harder. How to manage the code base and router is not intuitively clear. The biggest issue is managing [Zombie Views](http://lostechies.com/derickbailey/2011/09/15/zombies-run-managing-page-transitions-in-backbone-apps/) and the instances in memory of every model, view and collection. That being said, Backbone's light footprint when using Zepto, Lodash, Backbone and JST is pretty awesome. One trick I found for adding mixin functionality was the code below:

```js
/**
 * Takes a Backbone object and calls extend with all of the traits merged
 * @param {Object} clazz The Backbone Class
 * @return {Object} The extended backbone class
 */
var withTraits = function (clazz) {
    var args = [].slice.call(arguments).slice(1);
    var traits = {};
    _.each(args, function (trait) {
        _.extend(traits, trait);
    });
    return clazz.extend(traits);
};

// Assume you have an object Commentable
var Post = withTraits(Backbone.Model, Commentable, {
    url: "/api/v1/posts",
});
```

## Ember

[Ember](http://emberjs.com/) was my next framework that I tried out. I want to start out by saying that I think Ember is an amazing piece of technology. When you first start out, everything just works. You type a little bit of code and all of a sudden you have a webapp. However, all of this comes at a cost. Ember's footprint is rather large and has hard dependencies on jQuery and Handlebars. While Handlebars is understandable since most webapps use it as the templating language of choice, not being able to switch out jQuery for Zepto makes it a hard choice for mobile. Once Ember downloads and starts running, it actually inflates all of those little lines of code into memory through various auto-generated support objects. This is fine but I worry about the performance on mobile. The Ember teams seems to be aware of this and is working hard to improve performance for Ember.

The one downside in the Ember story right now is how you actually connect data to it. The Ember team claims you don't need Ember Data but all of the documentation assumes it. There are a bunch of 3rd party modules out there but they assume a lot about the structure of your backend and force you to massage your data into that format. This works fine out of the box for most SQL backends coupled with Rails apps but starts to become problematic when you have nested documents with MongoDB. Having Ember Data be ready for production and be flexible in receiving data from the backend will help out Ember a lot.

Finally, I think Ember is amazing and probably the right choice for larger teams working on a large scale desktop only application. That's probably fine too. If you have an application that large, it's probably worth building a native mobile app which mitigates the concerns for Ember on mobile.

## Angular

[Angular](http://angularjs.org/) is my last stop on the journey and seems to be awesome. Initially, I was terrified because none of my jQuery/Zepto plugins worked. How was I supposed to use Bootstrap or Foundation? After exploring and playing around with Angular, I found myself not really wanting to write Bootstrap or Foundation markup and just do my own thing. As a result, my apps have been smaller than anything I wrote in the other two frameworks.

Angular is definitely a weird framework and involves a lot of new concepts which can be intimidating for developers who are not JavaScript experts. That being said, I think it represents where the web is going. With ES6 and Object.observe, Backbone and Ember's getters and setters just seem antiquated because of the native event binding. Web Components seem to be more powerful directives given that they have their own CSS scope and finally the `<template>` tag seems to have the Angular data binding syntax.

## TL;DR

All of the frameworks are awesome and have their own use case. Backbone is great for adding structure and progressive enhancement to an already existing page, Ember is great for large scale desktop applications, and Angular is just fun once you get the hang of it.


Phips Peter

@pspeter3

Recent Posts

Accessible Contrast Shades

Concurrent: A Performant Promises/A+ Library with Scala Awesomeness

Journeying Through the MVC Jungle