We can then initialise this as an Angular application by calling angular.module(). This will become the scope of our application. Therefore our myApp will not be able to influence HTML outside of this container.

var myApp = angular.module("myApp", []);

Now that the application has a variable, myApp, we can add a controller to it and create a new variable containing the user data:

Therefore $scope.users now references our original array of user data.

Going back to our HTML, we can now back a reference to the controller:

Within this div element we can now access the users variable. Therefore we can create an unordered list element, and by using ng-repeat create a loop of list items. AngularJS uses {{ }} to be able to access properties of the current object in the loop.

The issue here is that unless another developer is aware, applying font-weight:bold; to the “alegreya” font-family will result in the browser applying it’s own faux-bold styling rather than using the custom “Alegreya-Bold.otf” type-face. Likewise with italic styling.

The browser’s interpretation of bold/italic will never be as nice as the custom designed type-face.

Below is an example of the browser’s interpretation of italic vs the “Algreya-Italic.otf” file:

Browser Italic:

Type-Face Italic:

The best way to avoid this is to use the same font-family name for each definition.

A cache-buster is a unique string which is appended to a URL in the form of a query string.

It is generally not read by the server-side and is used purely to form a unique URL. For example:

/Scripts/foo.js?v=1

This is often used on client side files such as Javascript, CSS and Images in order to force a browser/cache-system to retrieve the latest version of a file from its source.

When a webpage is downloaded, any associated files are also downloaded and stored in the browser’s cache. This is for performance purposes so that the webpage doesn’t have to download the files every time the page is refreshed.

However, as a developer, if you are to make a change to any of those files, you need to ensure the client will download the latest version.

Therefore the cache-buster query string can be updated so that the browser doesn’t recognise the file in it’s cache and downloads a new version.

Here a different types of cache-buster methods you can use:

Static Cache-Buster

When the file is updated, all references to the file could be manually updated to increment a version number.

For example:

<script type="text/javascript" src="/Scripts/foo.js?v=1"></script>

Becomes:

<script type="text/javascript" src="/Scripts/foo.js?v=2"></script>

However this isn’t a clean solution because this task will have to be carried out every time the file is updated. And in cases where its forgotten, browsers will potentially still use an older version of the file.

Date/Time Cache-Buster

The current date/time could be appended to the reference so that every call to the webpage will return a unique cache-buster. For example this can be done like so in .NET MVC:

The down-side to this method is that a change could be made to the application which creates a new version number even when a change to the file has not been made. In which case the browser would download the file again when it already has the file stored locally in cache.

Hashed-Content Cache-Buster

My preferred method of cache-busting is to create a hash of the content and use this as the cache-buster.

In case you haven’t already heard of it, jsFiddle is a web application which allows you to enter HTML, CSS and Javascript into different windows and render the output. It’s a great tool for testing various front-end concepts, and then “fiddles” can be saved and shared.

Because of this feature it’s a popular tool on StackOverflow for demonstrating issues/solutions.

One feature I’ve come across is the ability to quickly create elements in the HTML window by using CSS selectors. This makes jsFiddle even more quick and easy to create demos!