Frontend Mashup

Raluca Oanca-Boca
Full Stack Developer @Self-Employed

PROGRAMMING

Many of the web programmers need the rendering time of a web page to be as short as possible. One is confronted with this problem first of all when one has to choose the tools to work with on a new project.

At the beginning of a new project it is always difficult to choose the tools that will ease the work of each team member. We have to be careful when we choose these tools, since they will be used until the end of the project, but also in the deployment process. In this article I am trying to highlight the operations that form the automation of the frontend. They are: the writing of css with a pre-processed framework, the minification and testing of css, as well as the minification and testing of the js and, also, their automation under the form of processes both for the local development environment and for production.

For the initial prototype project we have used the PHP programming language as backend, without using any other framework, and as a frontend framework we have chosen AngularJS. When it comes to choosing a styling language, we can choose one of the following: LESS, SASS/SCSS or Stylus. These are preprocessed styling languages, which have an advantage compared to the pure CSS language. The main advantages are: the possibility of having variables, inheritance, nesting and mixins. After making the wanted choices, the challenge is to be able to combine these tools so as to ease our work first of all, the work of a development operator, and also have a page rendering time as short as possible.

The following things are available to us: nodejs, ruby, but also the package manager based on nodejs: npm. As a good practice in using the package manager, a package.json file is used in the root directory of the project.

In this file, we will list all the packages we need, as well as a few of the dependencies for the local work environment. After creating this file or after modifying it, we have to run the order:

npm install

Following the order, the node_modules directory is created, after which we need npm - g install grunt - cli

Ruby programming language will be installed and a few of its dependencies, among which: sass, sass-globing and compass.

sudo apt-get install ruby-full

sudo gem install sass compass sass-globbing

Once we have them installed, we can begin to build our Gruntfile.js file, which is also created on the same level as the package.json file. We need this file since, every time the grunt order is run, it will take this file into consideration.

The configuration part of the order is done through the configuration file as well as through some of the initial commands.

The following step is to load the initial tasks which depend on the customized tasks.

After loading the initial tasks, we will use the compass task for our project. If we run the grunt compass:dev order, we will see that all the used sass files will be chained in the destination scss file. It will be then transformed in css format with expanded display format. For the production work environment, the style is compact.

For the chaining of the js files, we have used the uglify task. For the local work environment, we have chosen the option that after the chaining of the files, the result be expanded, and for the production work environment, we wanted it to be minified.

We have a problem if we wish to change any sass or js file, through modifications we want to make. For these, we have created the watch task, which will verify any sass of js file, after which it will transform or minify them, depending on each case. This task is useful for the local work environment.

Towards the end, the goal is the registration of the customized tasks for the different work environments. In this line, one can also notice the browserSync task, which is based on the watch task, so that any modification we make will be automatically seen on the web page, without any need of manually reloading the page.

One difference that can be noticed is that in the production work environment I have chosen to run the order in the end to add a hash at the end of the file and thus avoid a cache problem. In the same time, we can also make a versioning.

For testing the css, we can use the PhantomCSS for which we have chosen to write tests using CasperJS. For the testing of the js, we can use Karma for unit testing and Jasmine for behavior testing.

"karma-chrome-launcher": "^0.2.0",
"karma-jasmine": "~0.1.5",
"karma-script-launcher": "~0.1.0",
"karma-firefox-launcher": "~0.1.3"

For coding standards, we can use grunt.loadNpmTasks ('grunt-contrib-jshint'); but I preferred using a pre-commit hook for git.

By using a single command, we can automatize our work in a local environment as well as in a production one. At the same time, we are using the DRY principles, we get fewer errors and we can make changes more easily.

In conclusion, the advantage is represented by the fact that we will no longer have to add every css or js file, but in the end, by using grunt, we will just have one file that should be added in the HTML page.