I’ve been thinking about using Codeigniter as the back end for a couple of single page applications where the front end would be implemented using BoilerplateJS architecture. I wanted to create the basic structure for such a project and share it. Today I came across this question and thought I’d do this project and share it. Surprisingly putting together BoilerplateJS and Codeigniter was a breeze.

Most of the BoilerplateJS code will reside in a public folder in the Codeigniter root folder. The index page of BoilerplateJS will be in views folder and will be loaded by a controller when necessary. After some path modifications in the BoilerplateJS index file and requirejs route configs, everything started to work perfectly. All the server calls that were simulated by JSON text files are now actually served from a Codeigniter controller. I also used CodeIgniter Rest Server to implement the REST API.

The project is at:

As I mentioned in an earlier post, Single Paged Applications provide several advantages to the user. They provide a smooth and fast user experience.

Having worked in a large scale single paged application development project and co-authoring BoilerplateJS, I’ve realized Single Page Applications are easy to de-couple and modularize. For me, development wise, it is very easy to manage Single Paged Applications.

You may start your desktop application or web application with a clean code base, with a nice modularized architecture with a good separation of concerns. But I have seen many applications where the code starts to get messy as the development progresses. Given you have the right tools and follow good practices, a Single Paged Application is best type of application for a clean and maintainable code base.

Unlike traditional web applications, the presentation logic and the main logic of the application are highly de-coupled.

On a Single Page Application, the server-side will be responsible for:

  • Handling CRUD (Create, Read, Update and Delete) operations
  • Executing different operations and workflows (these may include changing states of entities, updating database records)
  • Authentication and Authorization (this should always be done on the server side to ensure that the requests are legitimate)
  • Validation of web requests
  • Providing an interface for the client application to perform operations (typically done via a REST API)

With the help of proper frameworks the above tasks can be handled easily on the server side. Entities that are related could be treated as modules. Aspect Oriented Programming techniques can be used for authorization.

The client side will be responsible for:

  • Populating and rendering the UI with proper data
  • Access the server via AJAX
  • Perform client side routing
  • Perform client side validation

If a proper REST API is defined, back end developers and front end developers can work simultaneously on the project easily. And since the front end and the back end are de-coupled by the REST API it is easy to change these layers without significant modifications.  Scaling up the back end or providing a new interface can be done with minimal impact.

This kind of separation where the server is treated as a service provider and the presentation logic purely done on the client side with JavaScript, makes the application design very straightforward and clean.

During the past weeks I was involved in developing BoilerplateJS, a JavaScript reference architecture for large scale web applications. BoilerplateJS was developed based on RequireJS modules. I was involved in setting up unit testing for BoilerplateJS. One of our main requirements was to mock RequireJS module dependencies. After a lot of searching I came across testr.js. Testr.js can be used with almost any unit testing framework.

Assume that we have the following setup:


Index file contains the links to the scripts. Note that you have to import testr.js after importing RequireJS.

<script type="text/javascript" src="./libs/require.js" data-main="tests"></script><script type="text/javascript" src="./libs/testr.js"></script>

My dependency1.js file contains:

define([], function(){
	var dep = function(){
		this.getText = function(){
			return 'Original Dependancy';
	return dep;

It contains a getText() method which returns a string.
Lets assume that module1.js has used the above dependency as follows:

define(['dependencies/dependancy1'], function(Dependancy1){
	var module = function(){ = function(){
			var d1 = new Dependancy1();
	return module;

You can see that when the run method of Module1 is called, it calls the getText() method of the dependency. Therefore if you execute the run method of Module1, you should see ‘Original Dependancy’ on the console.
Our aim in this scenario is to replace dependancy1 with a mock object during run time.
Our tests.js file contains:

require(['module1'], function(){

	var fakeDep = function(){
		this.getText = function(){
			return 'Fake Dependancy';

	var Module1 = testr('module1', {

	var m1 = new Module1();;

Here, we create a fakeDep object that has the same methods as the original dependency, and then passes it to testr function with the related file path. Now, instead of loading the original dependency, testr.js loads the module with the provided fake dependency. When you run the above index.html, you will see the fake dependency being executed and ‘Fake Dependancy’ being printed on the console.

I joined 99X Technology as an intern and as a technology enthusiast, looking for opportunities to learn new things and to make cutting edge solutions. Soon I was introduced to a new world of JavaScript where it is used not to do small website hacks and data validation, but to build full-fledged software products.

Our clients demand software solutions that are cross platform, and solutions that support all types of devices. Our realization is that web applications that are dynamic and responsive would be the ideal solution for such situations. And we believe that JavaScript has the potential to cater these situations. There are plenty of libraries that are out there to address many individual aspects of JavaScript application development. But what lacked were some kind of architecture and a set of design patterns to address common problems that JS developers are facing.

Inspired by some of the great presentations such as Nicholas Zakas’ “Scalable JavaScript Application Architecture” and with the experience of few large scale JavaScript projects at 99x, development for a reference architecture for single paged web applications with JavaScript was started. Me and two other interns at 99X, Himeshi and Asanka were lead by Hasith (a wonderful guy with a wealth of knowledge and experience), were involved in this project, which is now released as BoilerplateJS.

BoilerplateJS is a reference architecture intended to be used in large scale web applications. It combines a set of industry leading JavaScript libraries and a set of great design patterns. BoilerplateJS would be the starting code for your JavaScript project, where you can add in and remove parts according to your requirements.

Every decision and every line of code that ended up in BoilerplateJS were carefully reviewed and made in the best and the simplest possible manner. Careful thought went into making BoilerplateJS loosely coupled, and flexible.

My intention of this post was to give a sneak peek in to the development of BoilerplateJS. More information about BoilerplateJS is available on And do have a look at Hasith’s blog post at