Lessons from EAF

3. Compile styles and scripts

When we built the ElseApps Framework we learnt a lot of lessons. This series of short articles discusses some of the key learnings from our framework development. I’m sure most of them will be lessons other developers have already learnt, but many of them weren’t in our vocabulary when we started into the project.

One of the issues in web development is ensuring users have the current version of Javascript and CSS files, but still benefit as much as possible from client-side caching. Alongside this stands the desire to minimise duplication among scripts and styles, especially an issue in a large and complex web application.


For both scripts and styles, EAF adopts a similar approach. URLs include a filepath that is a timestamp of the most recent edit. This ensures the browser requests a new file when necessary rather than continuing with the older, locally cached version. The web application’s .htaccess file redirects all requests for CSS and JS files to a processor which serves up the required content.


From here the paths for scripts and style diverge.

Javascript files are handled by code which invokes two third party classes: Ryan Grove’s JSMin, and Jspp. Despite our best efforts we can’t identify the author of the latter class, but it has three very useful features, all of which are implemented by commented directives at the top of each file:

  1. We can include other javascript files in the base file.
  2. We can define variables to be used in the included javascript files and have these variables replaced with real values at runtime. This allows us to make more scripts into reusable generics.
  3. We can choose whether or not to minify each included file.

Jspp caches each included file as a pre-compiled atom whose name includes the compilation timestamp, and serves up the desired mix – with runtime variables – when the user requests a javascript file. The performance impact is minimal, but the additional flexibility is superb.


CSS files are compiled from a combination of LESS source files and CSS atoms using Leaf Corcoran’s lessc parser class. As with Jspp, we’ve enhanced this class to accommodate our core + custom file structure.

The result of this approach is that a developer can deploy changes to the ElseApps Framework knowing that the user will always be served up the most recent version of all JS and CSS files.

In the next lesson from EAF we’ll discuss abstracting data by type.

Lessons from EAFF: 1 2 3 4 5 6 7 8