Skip to content
Ankur Anand edited this page Oct 12, 2013 · 3 revisions

Frontend Stack

Giving a head start for Pragun. So essentially there is one thing we are trying to do here with this project and that is that everything is going to be a module. Modules are nothing more than functions, but functions divided on the basis of logics

For example generating a bar graph is one module, that is given the data and it returns a bar graph.

So we are going to divide the whole projects in such modules. Now there are two main issues with modules :

1. How does the module know what it needs

say a bar graph module needs D3.js, so we would have to include d3.js in any html page that has the barGraph module.

But that makes it difficult to manage so many files and knowing what to include on a single page. Here comes the AMD pattern of modules. It's a simple concept that a module is gonna ask for whatever it needs in its definition.

require(["d3","jquery","bootstrap"], function(util) {
    //say a function needs d3, then its gonna ask for it in the require statement
   //and require would make sure that the function is only executed when the dependencies have loaded
});

Now AMD pattern is pretty easily done by a library called requireJS, which takes care of all the loading of files when required.

**Another advantage of this is that every module is completely independent. All you need to do is to use a module, is to use a module and not worry about other JS being loaded or not. It helps us loading a module when its required asynchronously.

For Example: Loading a modal module only when the page requires a modal. This way the modal module JS is not loaded on the page load, and since that is not loaded, bootstrap-modal.js is not loaded as well. This saves 2 files being loaded on the page load, making the website faster.

read more here...

2. Modules communicating between each other

For example : A infographic module needs data from the data module.

One way of using it is that infographic module calls some functions of the data module. But this leads to some problems, and the system starts becoming complicated as modules are becoming dependent on each other. Another pattern of doing it is through using a mediator. So infographic module would ask the mediator module for data. mediator module would ask the data-module for data and then return it to infographic module. This way in future, lets say our data module changes, so our infographics module does not need to change, and only the mapping in the mediator module would change. Also this way many infographics modules can ask for data from many data modules.

read more here ...

These were the basic concepts behind the design.

Javascript Design Pattern
  • Use PJAX ( push state with AJAX, what medium does )
  • Use JS Templating ( for generating HTML with JS )
  • Build a custom MVC structure based on AMD module pattern
  • Base modules on a event driven architecture
  • Use mediator pattern for communication between modules

Tools of the trade

  • PJAX
  • Handlebars
  • RequireJS
  • analytics.js( for logging )
  • bootstrap( through the AMD pattern, include what is to be used rather than the whole file )
  • Modernizr ( For feature detection )

CSS/LESS system

  • Would try to make the system on atomic design principles
  • preboot.less
  • normalize
  • bootstrap ( just need it for the forms. Alternatives ? )
  • Look at new stuff for this ??

BUILD SYSTEM

Using a Build system for automatic minification, concatenation, and hashing of files etc. Automating tasks on the frontend.

  • Grunt
  • Bower