Introducing the Ushahidi Platform Front-End Stack

In a series of blog posts over the past few weeks we have learned about the radical changes under the hood within the Ushahidi Platform, evolving from an initial set of libraries to a whole new set of libraries. Over the past months, as we were building the application, we experienced a series of limitations that brought into question our choice of libraries. So we decided to take what we learned and completely rebuild the app. This post is the first in a series that will focus on our front-end tools and libraries of choice, or as I like to call it, the front-end stack. This post also assumes you have an understanding of the tools and libraries mentioned. If you don't, you can familiarize yourself with them by visiting the links below.

First, let's take a look at where Ushahidi Platform currently stands.

Ushahidi Platform entered public beta with the following front-end stack: Foundation: A responsive front-end frameworkGrunt: A Javascript Task RunnerBower: Package/dependency managementRuby Sass: A CSS PreprocessorCompass: A Sass Framework Our css preprocessor of choice was and still remains Sass. This is nothing against Less or Stylus, Sass is just the preprocessor that I am most familiar with and the one that has the biggest community (more plugins and libraries FTW!).

Now let's take a look at where Ushahidi Platform is headed

The new Ushahidi Platform front-end stack will consist of these libraries/tools: Bourbon: A mixin library for SassNeat: A lightweight semantic grid framework for Sass and Bourbon.Bitters: Scaffold styles, variables and structure for Bourbon projects.Refills: A starting point for common UI elementsGulp: A streaming build systemBower: Package/dependency managementNode-Sass: a library that provides binding for Node.js to LibSass After months of building and experiencing limitations, our initial choices didn’t fit what we needed, so we decided to:

abandon Foundation for Bourbon, Neat, Bitters and Refills

switch from Grunt to Gulp

drop all Ruby dependencies

switch from Ruby Sass to LibSass (via node-sass)

drop Compass

Let's explore each of these choices further.

Abandoning Zurb Foundation

In the beginning stages of UI design/development, we wanted to choose a framework that would speed up development and carry a majority of the weight in terms of UI elements and functionality. We decided to go with Foundation. Foundation is a responsive, mobile-first, front-end framework built on Sass, and the newly updated Foundation 5 brings many great features and upgrades. It is important to note that as an open source technology company, Ushahidi is rooting for Foundation, it just didn't work for our application. My co-worker Woody put it best:

"We have been unable to use Foundation widgets as intended, because the Javascript was not designed to operate with a single-page application. To the credit of Zurb, they are addressing this in the near future with Foundation for Apps, but it won’t be soon enough for us to use it."

Realizing that we needed a change was the first step; the next step was to decide what to replace it with. We knew that we wanted a semantic grid, an extensive library of Sass mixins and a good set of base styles, as these were things we loved about Foundation. We realized that Bourbon, Neat and Bitters provided these. Then we discovered Refills, which provides a great starting point for common UI elements, meaning that we can use some of those elements as they are, then override and restyle as needed. So, we replaced Foundation with Bourbon, Neat, Bitters and Refills. These are all created and maintained by Thoughtbot.

Switching from Grunt to Gulp

When Grunt came onto the scene, it was a game changer. Grunt is a task runner that automates the never-ending abundance of repetitive tasks necessary for efficient front-end builds. For example, running a simple command in the command line like grunt could:

minify your files

optimize your images

compile Sass to CSS

test and lint your JS

and so on, building out a production ready code base. Pretty sweet. (The list of available plugins is never ending.) Now let me say that I love Grunt and it has been invaluable to front-end development, but the Ushahidi Platform was experiencing very slow build times, and our Gruntfile.js was becoming increasingly confusing to read and maintain.

Then Gulp came on the scene

Gulp is a direct competitor to Grunt that promises faster builds using streams and a simpler, more intuitive API. This was very promising for us in that it potentially solved both our problems: slow build times and an increasing difficulty in maintaining our JS file. So we decided to give Gulp a try and the initial test were so beneficial that we have adopted it into our new code base. It is, without a doubt, infinitely faster than Grunt and the JS file is a lot easier to read, write and maintain.

Dropping Ruby Dependencies

Switching from Ruby Sass to LibSass

We didn't want any Ruby dependencies, but we LOVE Sass. Luckily there is a non-Ruby version called LibSass. From the LibSass website:

Sass was originally written in Ruby. Ruby's great, but people started having a couple of issues. First, we want everyone to enjoy Sass, no matter what language they use. Why restrict everyone to using Ruby? In addition, Ruby can be kind of slow. Lowering compile time for users is important. Enter LibSass

So, no restriction to Ruby and faster? Sign us up!!!

Dropping Compass

Compass is a Sass framework, built on top of Ruby, that provides mixins and tools for speedier and cleaner code. This is great, but as we were rethinking our stack, we realized that Compass was overkill. We weren't using it to its maximum potential, and we realized that Bourbon could provide us with all the mixins we needed and replace Compass all together. Also Bourbon is lighter and faster than Compass, which is always a win. It was/is also important to minimize dependencies and our preference was to remove Ruby dependencies altogether. So out goes Compass and in comes Bourbon.

What's Next

This is a basic introduction to the new front-end stack of Ushahidi Platform. We have learned about where we started and where we are now, as well as why we ended up here. Stay tuned for the second post in this series, where we will dive deeper into how we use each of these libraries/tools. If you would like to follow along as we rebuild the v3 web client you can do so at https://github.com/ushahidi/platform-client If you have any feedback on using any of the tools that were talked about in this blog post, please leave a comment below or message me on Twitter @middle8media, I’d love to hear any insights or questions you have.