We're Making Ushahidi Better, Faster, Smarter: A Javascript Journey

Ushahidi
Mar 20, 2018

We’re going to make Ushahidi better, faster, smarter.

It’s one of those annoying Silicon Valley tech company phrases that usually has zero meaning or intention behind it. But not in this case! I promise, or at least I hope.

About six months ago, our dev team started a discussion about rewriting the Ushahidi platform client. We were all in agreement: it’s broken beyond repair. But how did we get here? How did we get this sloth (it may be cute and we love it, but it is slow) of a codebase?  It was a long time coming.

via GIPHY

Ushahidi platform client is built on Angular 1.5.6, which of course was a perfectly acceptable choice of frameworks at the time it was built. But since then, Angular has come out with version 2, and 3, and on, and on. Our codebase hasn’t developed along with the framework. In the very near future, functionality on which we rely will stop working; libraries will become completely incompatible. On top of our outdated framework, we also lack any form of state management. This is forcing us to do an inordinate amount of requests to our API, which costs our users dearly. We’re also polluting the root scope with nearly every feature and it’s getting messy! We did implement routing, which was a minor miracle, thanks to one of our talented devs, Romina. But it was done in desperation, a bandaid on top of our state management and Angular wounds.

Then a series of super intense, fast-paced, don’t-look-back, no-time-to-breathe sprints, like Uchaguzi and (the lovingly named) 2chaguzi happened. And we knowingly built code on top of a foundation we knew would disappear. The result of those few sprints looked a little something like this:

And our resulting codebase looked a little bloated and unwieldy like this:

I know I sound like a doomsday prophet and I’m sorry! I had to bring you down so I can build you back up again. Because we were at rock bottom. We couldn’t keep adding to this house of cards any longer! We had to migrate to a new, modern front-end framework, with all the bells and whistles, and simplify our codebase to address these major structural and architectural issues. We came up with two main objectives:

Improve usability in low bandwidth settings (which in turn, will improve usability for all users);

Improve ability for developers to build and deploy new code.

This front-end rewrite is going to involve a lot of changes. Way too many changes to go into in one little blog post. So I’m going to tell you a little about how we decided which front-end javascript framework would replace Angular 1.5.6.

First we had to lay out our options:

Angular 2+

React

Vue

Preact

Many others that we considered for about a minute

Then we had to decide what the main criteria were for our decision:

Ease of migration from Angular 1.5.6

Companion frameworks: routing, state management, etc…

Build tools

Dev tools

Templating

Ease of learning

Support for mobile development

Development roadmap

Popularity and activity in community

Level of opinionatedness

Testing framework

Size & performance

Server side rendering

We started our doing research on each of the above points. How would each framework option fare in each of these categories? I’ll tell you what we found: All of our options are great! None of them appeared better than the others in any meaningful way (for our purposes). Angular, React, Vue, and Preact would all do the things we need to build a well-functioning client. We wanted to be objective about the whole thing and pick the framework that was the clear winner in the majority of these categories. But there was no clear winner.

So how would we eliminate them? I’ll paraphrase our CTO, Robbie, who said, “why should we be objective about this when we’re the ones who have to develop using this framework every day? If we dislike coding with Angular, why should we even consider Angular 2?” In a world where we’re constantly pushed to evaluate objectively, this hit me like a ton a bricks. It was so obvious! And with that, Angular 2+ was off the list.   

Given this new-found freedom to evaluate our choices subjectively, we decided to run a little experiment. We would build three prototypes, one in each of our remaining framework options. Then we would choose which one we subjectively liked best. The prototype would include state management, basic routing, one API request, a list view of data, and a simple filter for the data. The UI for each ended up looking something like this:

Here were my key takeaways:

Vue.js

Woah! Impressive. I was so against this from the beginning. I didn’t want to be the alternative kids just because. But Vue.js really impressed me. The most significant takeaway for me was just how easy it was to learn. The documentation is fantastic! It’s a really happy medium between Angular and React, which allows you to be totally non-commital to either model. After finishing that prototype, I was ready to book my ticket to the vue.js conference in New Orleans and slap a Vue.js sticker on my laptop.

React.js

I’ve always liked React. It just clicks for my brain. This was my clear favorite before the experiment started. I got a little down about it (and myself) in the process though. I thought that, despite not having used React for over a year, I could just create a little app without having to read up on anything. I was very wrong. After getting over my expectations of myself, I went back to the documentation and re-taught myself the basics. Once I did that, I was able to remember why I love coding with React. Mainly I really enjoy component-based architecture; again, it just clicks for me. I began to get excited thinking about how we could re-architect our front-end with reusable components, and suddenly the world seemed like a place of endless possibilities. There’s just something exciting about the prospect of organization and simplicity. And I happen to like JSX--or at least I don’t mind it. I know some people don’t like all that HTML in their Javascript, but I disagree!

Preact.js

Well, if I liked React, then why wouldn’t I love a more lightweight version? For the baby app we built, Preact had all the same pros that React had. I could basically copy the above paragraph here and replace all instances of React with Preact. Seemed like a pretty great option.

Conclusion

They’ll all work for what we need! So what should we choose? We decided that component-based development was the way to go and size would be pretty important. So we chose Preact! And off into the sunset we rode.

via GIPHY

Just kidding. We continued developing with Preact, like an extended trial period. And Preact didn’t make the cut. The longer we used it, the more we realized it wasn’t right for us. Our biggest problem? The lack of community and resources. It’s just different enough from React that you can’t simply transfer the solutions directly from React documentation or Stack Overflow questions. We quickly saw how much of our time was being spent scouring the depths of the internet for solutions to obscure Preact problems. Testing was a mess too, and we’re already fighting an uphill battle against our lazier selves to follow TDD. We think Preact is a great option for a small project or for a larger team with the time to contribute to the ecosystem. But that’s just not where we’re at right now. So we’ve come to the final* conclusion that we’re going to migrate our frontend framework to React.js. What it really came down to, in the end, was which framework** we enjoyed coding with most. And that was React.js. Now all there is left to do is rewrite the Ushahidi platform client.

* We reserve the right to change our minds again and again and again.

** I know it’s technically a library. Please don’t get mad at me.