The Jollof PHP framework story

On the December 3rd 2016, 2 days after my birthday and on a very cool evening, sitting on the couch of my living room and wondering whether if i could ever be like the software engineers i looked up to whom resided outside Africa. I stumbled on the thought of building out a simple PHP framework (that resembles Laravel) from scratch. Why ? because i was bored and didn’t have anything better to do ? because i wanted to re-invent the wheel and waste precious time ? because i thought i was the shit 😅 ? Not at all . Those weren’t my reasons! I embarked on this because i wanted to prove to myself that i had what it took to build developer tools and build the confidence to be involved with open-source work at a high level (one day become a code maintainer). So, i decided to challenge myself.

Prior to 2016, as far back as 2012, I had always been fascinated by the works of many others before me: Like John Resig (jQuery ), Fabien Potencier (Symphony), Paul Irish (Modernizr) to mention but a few. I would spend hours and hours reading through the codebases of these awesome projects and wonder how they had managed (in their spare time) to put together such cool stuff outside of their 9-to-5 daily work cycle. These guys all inspired me and with that inspiration i decided to do something small of my own. So, in this article, i will share a little story of why and how i built JollofPHP.

Motivation & Merit

As i sat staring at my laptop computer (a rickety Dell Inspiron Mini i had owned since my 200 level — 😁) that evening in December, an idea came to my head to build a CLI tool in PHP. Earlier in the year (July 2016), the famous Prosper Otemuyiwa had already released the Linda Ikeji CLI tool and it was really a delight to install it and watch it work. It was exciting to be very honest! So, i wanted to replicate the same feat (well, not entirely the same) but similar. In the meantime, i also had little things i wanted Laravel 4.x/5.x to be able to do at the time (which JollofPHP can do presently by the way). I wondered that it would be nice for Laravel to include the ability to minify HTML on the fly after being compiled (someone had made this proposal in 2013 but Taylor Otwell felt it wasn’t necessary at the framework level) by a view template OR launch a local copy of the Laravel documentation or Laravel application in a browser directly from the CLI with the configured server URL whenever the server was started with php artisan serve command (all of which JollofPHP can do presently as well).

Initially, i was afraid that my request(s) will not be considered if i dropped an issue in the issue tracker for Laravel framework project repo. I had earlier noticed that the author (Taylor Otwell) was quite critical of what he allowed to be merged into the framework codebase. Fast forward to 2018 and it turns out i was right, i submitted a pull request to enable the setup of middlewares in routes that were registered dynamically (i.e. inside of a service provider) as part of the request/response cycle which got speedily struck down in a couple of hours by Taylor Otwell himself (he said it was gnarly 😅☹️ — couldn’t argue with the chief code maintainer; so ela + hot tears!).

So, my instinct to build my own small, simple framework in 2016 had some merit from this point of view. Also, like I said, more importantly, i wanted to prove to myself that i could create a project that could potentially be used as a tool used by many software engineers.

Getting to work!

So, i began to write some code. One line after another, day after day and in 3 days, i was done with the CLI tool. I said to myself; “That wasn’t so hard ?”. Suddenly, i was looking for ways to add more things to it. It was at this point things got really hard! The amount of work left to be done was great. Around this time too, i was working on a JavaScript state management library called Radixx (an experiment initially but later morphed into a real thing i wanted to build and share — which i did build completely but never launched) and a documentation site for it. There were days when i wanted to throw in the towel especially when i was working on the custom view templating render logic. I must say that i learnt a lot about modular code by writing the code for JollofPHP. It actually boosted my confidence in building open-source software tools many years later now like: adonis-queue, adonis-extensions, URISanity, react-busser.

I also learnt a lot about algorithmic thinking and debugging as a result of attempting to build this project. These were very important skills in my career going forward. These skills have helped me become a better software engineer over the years. One thing i tried not to do was copy code or reuse code from existing projects or libraries that performed a similar task to what i was building. Why ? well, because i wanted to really understand the details of what was going on under-the-hood. In hindsight, it was a decision that was a little over-the-top 😅 and that i regretted!

I would later on (in the course of building) reverse this decision as it was making building other software components of the framework take a longer time and more effort and stress. It was one of my first lessons in open-source software development. The ability to leverage the work of others to speed up development. It doesn’t mean your work is lazy or unoriginal. It just means that you prioritise your time and the impact you want your work to have.

Taking Off ?

The JollofPHP project started as nothing more than way to learn but quickly escalated into something much bigger. I spent much of December building not just the CLI part of the project but the several core parts as well. The request module, response module, database query builder factory, the view template system e.t.c. It’s important to state that JollofPHP was nothing more than an experiment to me. I never saw it as something that could rival Laravel or Symphony. However, i had taken the time to draw out a roadmap for this experiment of mine. I wanted to see how far i could push it. Moreover, in my mind, publishing the code on GitHub and talking about it to anyone who care to listen was only a “first step”.

I honestly thought it was going to attract lots people who would want to collaborate and build further but it only attracted a few persons like: Adewale Abati, Stephen Igwe, Ikechi Michael and Shalvah Adebayoh were drawn to the project. Eventually, they seemed to lose interest in the project after a while — no fault of theirs.

I believe this happened because, my day job got a lot more tedious as i worked at an early-stage startup at the time called Mobile Forms. As my job took up more of my waking time, i never really found the extra time for the JollofPHP project (as i started chasing a comfortable life instead — 😂).

So, you’d ask: What did i gain from “stressing” myself to build this thing called JollofPHP especially since it was never meant to be more than an experiment ? Well, i gained confidence. I gained confidence in my abilities to think through a software problem and solve it.

Winding down…

Early in the year (January 2017), i hurriedly made a logo for the project by myself (you can see it on the only image on this article above) and i gave a talk (or speech) about JollofPHP. A senior software engineer ([full name redacted]) who encouraged me to give the talk was more excited about the project than i was. It was truly surprising and exhilarating at the same time (he even printed shirts and wanted to buy a domain for the project — jollof.io). Many weeks after the talk, the euphoria around JollofPHP died down. The support also dried up over time as i spoke less and less about it (SAPA was seriously dealing with me in real-life 🤣!).

A lot of other things were happening quickly and ferociously on the open-source software and tooling scene and i became a lot more concerned with keeping up with all these things than working on JollofPHP.

Conclusion

The JollofPHP was never meant to be a long-term project. In the end, it was just a proof-of-concept. I was well aware that a lot of people wanted it to be more than an experiment but i didn’t have what it took to commit to it in that manner.

I am glad that i got to prove to myself that i could do it. In fact, it has become one of my selling points when job hunting. I brandish it like a badge of honour and it works because it shows technical recruiters that i am a capable software engineer. I am always proud of it!

You too can build something that you can be proud of. Todo apps and calculators alone may not get you that internship job you so desperately want but a solid contribution to open-source software or building one yourself can put you up there and give you somewhat of an unfair advantage over other applicants.