Cover image from How to explain APIs in plain English by Kevin Casey.

Original post on hashnode posted July 10, 2021.

Previous Outreachy article: Everybody struggles.

So I explained the project I'm working on (at Ushahidi), to my eldest brother who is a school teacher. It went well 😌, at least I think so because he nodded his head in agreement to whatever I was saying, lol. For this week's Outreachy blog post, I am to explain my project so that even a newcomer to the community I'm contributing to can understand. I'm also going to try to explain so that anyone with no prior coding experience will be able to understand. You can let me know if I did well or not in the comments.

About the Ushahidi project

I mentioned in my first Outreachy article that I'm working on the project - "Improve performance on the Ushahidi Platform-client". What does that even mean? 🤷🏽‍♀️ Let's break the project title into two parts: "Ushahidi platform-client" and "improve performance". Ushahidi is a not-for-profit organisation that build open source software. The main software application developed at Ushahidi is the Ushahidi Platform. With this application, users can collect, manage and analyse data from their communities. Ushahidi was founded in 2008, and since then the platform has become an essential tool for addressing social, political and public health challenges and fostering meaningful change. Read more about Ushahidi community and the Ushahidi platform on Ushahidi’s about page. The platform-client is just the name given to the part of the Ushahidi platform that users are able to interact with, when opened up in a web browser.

According to wikipedia, (web) performance has to do with the speed in which web pages are downloaded and displayed on the user's web browser. Even if you have never interacted with Ushahidi's platform-client, you may have visited some websites or pages that took so long to load. You'll agree with me that it's not a pleasant experience. For the duration of this internship, the goal is to create a better experience for users of the platform-client, with focus on the following:

  • Decreasing the bundle size of the javascript.
  • Code splitting and lazy loading.
  • Finding and removing unused dependencies.
  • Finding light replacements for heavy dependencies.

Background

Developers will usually not write all javascript code inside a single .js file (or all css code inside a single .css file in the case of css etc.), as it makes code very hard to read and maintain. While separating code into their various files helps code maintenance, it impacts performance negatively when rendering the application in the browser to the user. To tackle this, we use a “bundler” to generate just one file (referred to as a bundle) which contains all the code from those numerous files. This bundle, which is in the format that browsers can consume, is what is loaded in the browser. This improves performance in smaller applications, but can quickly become a problem when the application grows bigger.

Having one bundle with all the application’s code in it means that even code that the user doesn’t need (yet) will be downloaded when the page loads. We can use a bundler like Webpack to split that one big bundle into smaller logical chunks/bundles, which we can then load (only) when we need them. The process of splitting is called code splitting (or bundle splitting according to some articles I visited), while loading on demand is called lazy loading. Learn more about these concepts from the article - All you need to know about code splitting. The platform-client already had Webpack configured and that one big bundle generated as described earlier. I only provided that background to help understand what my mentor and I are working on.

Most times developers don't write all the code they use by themselves. Instead of having to write some part of our code from scratch, we may find that someone has already created a library that solves that problem. In our application, we can have many of such libraries. It's tempting to keep adding more of such libraries, but this comes at a cost. Some of these libraries even depend on other libraries to function, the size may be massive. Three options exist to tackle this problem: Write your own code from scratch, find smaller alternative for the library, or import only the part of the library that you need.

It is also possible to forget to remove libraries that are no longer used in the application, especially when the project/codebase becomes large. Finding and removing the unused libraries, finding a solution for large ones, splitting and lazy loading all aim at reducing the size of our bundle.

All Outreachy blog posts

So that's the summary of what the project entails, and I hope it's explanatory enough. My next article will be about my experience with code splitting and lazy loading and how weeks 4 - 7 went. I have added links to all Outreachy blog posts here in one place so that they're easy to find:

Find me on Github, Twitter and/or LinkedIn.

Next Outreachy article: Modifying expectations.