Tag Archives: JavaScript

David, a dependency management tool for Nodejs projects

Posted on by
12 Replies

I made a thing. I noticed that there wasn’t a way to visualise which of my Nodejs project dependencies were out of date. I saw a library called police which looked pretty awesome, but I wanted to provide a bit more of a service – A quick and easy way for developers to advertise that their project was up to date, in the same way that Travis provides a “badge” that always shows the current build status for your project.

Badges are great, everyone like badges. The Travis badge is an admission by the developers who work on the project that they’re committed to keeping their code base in working order for both consumers of the software and developers alike. Travis proves that their project works by ensuring it can be built successfully and that it passes any unit or integration tests the developers have written. Consumers and developers can see the build status of the project at a glance, without having to clone or checkout the code.

The David badge shows that the project developers are committed to maintaining and improving the project, keeping it up to date, secure, efficient and (hopefully) bug free by keeping abreast of changes in the code the project depends upon.

Of course, an “out of date” David badge can be a indication of a low level of project activity and a hint at the level of support you’re likely to get should you encounter a problem (not much).

Clicking on a David badge will normally take you to the project status page, which lists project dependencies, the version required by the project and the latest version available in the NPM registry. It gives you an idea of the complexity, size and scope of a project and most importantly, it shows developers what dependencies need updating! Here’s some examples

David is written in JavaScript, it uses Nodejs and NPM (of course). It was built from the GRUNTEND base with the Express web application framework.

Check out David here: david-dm.org

JSIO Performance Results

Posted on by
Reply

Below are two graphs plotting the number of images on a page against the total KB transferred by Chrome 13 for both a page with JSIO and without JSIO (which I, for some reason have called a “plain” page).

I build websites for a living, so I have a lot of folders of images from various websites lying around which form the two data sets for the graphs. I’d like to think of them as a typical set of website images, but you may argue that they are typical for the websites that I build.

I knocked up a script that when given a folder of images, will output a “plain” HTML page, a JSIO HTML page and a JSIO resources file with the following numbers of images on them: 2, 4, 6, 8, 10, 20, 30, 40, 50, 60, 70, 80, 90, 100, 200, 300, 400, 500, 600, 700, 800, 900, 1000 and 1100. Before generating any of the pages, the order of the images were randomised to better represent a web page’s inclusion of different images for different purposes.

Chrome 13 was used with the developer toolbar to determine how many requests were being made and the actual KB transferred (with slight rounding errors) by the browser. In my opinion I would say that Apache was set up to serve image and javascript content typical of many servers on the internet in that images were not gzipped but javascript files were; the register, bbc, for example.

What is interesting to note is that the number of bytes transferred by JSIO are consistently lower than the bytes transferred by a plain HTML page…but not by a lot. The file size inflation due to base64 encoding seems to cancel out a lot of bytes the gained from making fewer requests. However, it is obvious that JSIO won’t actually lose you any bytes, but it isn’t going to save you a substantial amount. That said, saving bytes isn’t the only benefit of JSIO, remember that one of JSIO’s goals is also to alleviate some of the problems surrounding the creation and use of image sprites – which it does also do very well.

The graph below is just for fun, it plots the number of requests made by JSIO pages against the number of requests made by plain HTML pages. Note the JSIO pages make a constant 4 requests (index.html, jsio.js, jsio-resources.js and jsio.gif) independent of how many images are on the page:

JavaScript Image Optimiser (JSIO)

Posted on by
2 Replies

So, I’ve embarked on a new mini project. It is kind of inspired by image sprites.

Image sprites are a great idea, but come with a whole bunch of issues that make them a bit of a pain to work with.

Firstly, most of the time you have to use markup to create an element in html to “hold” the image you wanted to display from your sprite. This is because if you actually set a sprite as the background image for a large html element you’re likely to see other images in the sprite as well. Because of this, you actually lose useful functionality that CSS gives you, like the ability to position, repeat and scale an image. Also, the markup you’ve created to hold the image exists for style purposes, which is bad.

Secondly, sprites can be a massive ball ache to maintain. If you’ve closely packed your images in a sprite for maximum efficiency and then one of your images needs to change size, you’re either going to have to move ALL images surrounding the image you have to update (and obviously then change all background-position properties for the images you’ve moved) or leave a space and put the updated image in a new position in your sprite.

How do you know which images in a sprite are used and which ones are dead? Since your images are referenced by coordinates, this sort of clean up becomes a nightmare and is actually a bit lot of a nightmare to create image sprites in the first place.

The goals of the project are to

  1. Reduce the number of http requests (and their associated header traffic) to the server and hence reduce the time it takes to load all images on a website and bandwidth footprint the site requires
  2. Create a solution that’ll alleviate some of the problems surrounding the creation and use of image sprites
  3. Do something cool

The JSIO project website has a pretty good explanation of how it works so I won’t bore you with the details here. However, as a brief overview, it packages all your image data in data uri format and you reference particular images by their filename rather than their coordinates.

The site actually uses the HTML5 file api to generate your resources file for you, which makes creating and maintaining your JSIO “sprite” really really easy.

I read *somewhere* that data uri encoded images can be up to 1/3 larger than corresponding image files, however with gzip encoding they can be only 0-3% larger (or less). My thesis is that for a site with many small images, JSIO could be more efficient and easier to maintain than having separate files or even an image sprite.

…I’m yet to prove or disprove this and I’ll be conducting some tests whose results I’ll post up here (even if they do prove JSIO to be useless).

Disclaimer: This is the first ever ALPHA release of JSIO – it works on the latest Firefox and Chrome but I haven’t even checked it in IE yet. It probably won’t work in IE yet. Also, the website needs some work for optimal display on mobile devices.

The difference between using single quotes and double quotes as string delimiters in JavaScript/PHP

Posted on by
8 Replies

I like to keep all my string delimiters in languages such as PHP and JavaScript consistent. I consistently use single quotes for a couple of good reasons, so when I encounter someone else’s script that uses double quotes the OCD in me makes me change them all to single quotes…but that is a different problem.

If you’re coming from a language such as C# or Java then note that in PHP and JavaScript there is no such thing as a character datatype – as such, you can use either single or double quotes to delimit strings.

If I could only give you one reason why I consistently use single quotes then I would have to go with this:

If you ever (God forbid) need to write HTML in a string, you don’t need to escape the double quotes around attribute values. Instead of:

    "<div id=\"foo\" class=\"bar\">foobar</div>"

You write:

    '<div id="foo" class="bar">foobar</div>'

…which is lots less characters to type and I’d say more readable. Also, I more frequently use double quotes in my JavaScript/PHP strings than single quotes so it really does make sense.

The other reason is that if you use double quotes, PHP will actually parse the contents of the string to find variables and escape characters (\n, \r, \t etc.) which it’ll replace with the variable value or correct escape character respectively. So for example:

<?php

    $baz = 'bar';
    echo "foo\n$baz";

?>

Will print:

foo
bar

Whereas:

<?php

    $baz = 'bar';
    echo 'foo\n$baz';

?>

Will print:

foo\n$baz

So if you don’t need any of this functionality in your string, you’re making PHP do some extra work for no reason.

jQuery plugin to associate label “for” attribute with form controls that have dynamic id’s

Posted on by
3 Replies

For whatever reason, you can’t associate your labels with your form controls implicitly by wrapping both the label text and the control in a <label> element:

<label>
  Email address: <input type="email" name="email" value="" placeholder="you@example.com"/>
</label>

You’ve had to explicitly state the form control you want the label to be associated with:

<label for="email">Email address:</label>
<input id="email" type="email" name="email" value="" placeholder="you@example.com"/>

…but your framework has other ideas, it decides to commandeer your precious “id” attribute and change it from a simple and beautiful “email” into a junky “dnn_ctr1163_RegistrationForm_email”. *cough* DotNetNuke *cough*, but also *cough* Wicket *cough* and probably a whole load of others.

The problem is now that your label is no longer associated with your form control, and there isn’t a simple fix, like, for example, change the for attribute to read “dnn_ctr1163_RegistrationForm_email”, because the numbers in the id change each time you refresh the page. The ID is dynamic, and you are receiving accessibility black stars.

So, luckily I noticed that often the id will change, but the framework will leave your originally intended id somewhere in there. I’ve written a jQuery plugin to look at label for attributes and try to find the form control you intended to associate it with before your server side framework so rudely changed it.

How to use

  1. Download the plugin and add it to your page
  2. Select the labels you want to re-associate and call the function eg. $(‘label’).fuzzyFor();

TODO

The plugin finds matches by looking for input, select and textarea elements in the document and checking to see if the for attribute in your label element appears in the id attribute of the form control. At the moment if more than one match is found, it just uses the first (which is probably good enough for most). However, it should probably do something a bit more clever and use the form control that is closest to the label (I’m reasoning that you normally put your label’s close to your controls).

Array.toString

Posted on by
Reply

I was recently trying to debug some code that returned an array of arrays. In Actionscript and seemingly most (if not all) ECMAScript implementations, when calling toString on an array object it passes back a comma separated list of elements in the array. This is no good if you have nested arrays because:

    [1, 2, 3, [1, 2, 3]].toString();

…returns:

    "1, 2, 3, 1, 2, 3"

So it appears as a flat array, whereas the underlying object is something entirely different. So if you happen to be quickly debugging using trace (ActionScript) or alert (JavaScript) the object can appear to be something it is not.

If you want the Array object to return a string of comma separated elements contained in square braces then run this snippet somewhere before you start creating new Array objects:

    Array.prototype._toString = Array.prototype.toString;
    Array.prototype.toString = function() {return '[' + this._toString() + ']';}

Now:

    [1, 2, 3, [1, 2, 3]].toString();

…returns:

    "[1, 2, 3, [1, 2, 3]]"

Much better!

Modernizr progressives or exceptions?

Posted on by
7 Replies

Modernizr, what an interesting tool you are. How do I use your class names in my CSS files? You’ve given me a choice and I’m not sure what to use:

.multiplebgs div p {
  /* properties for browsers that
     support multiple backgrounds */
}
.no-multiplebgs div p {
  /* optional fallback properties
     for browsers that don't */
}

There are two ways to view this, bottom up, and top down. They both have their advantages and disadvantages, and I’m going to attempt to highlight these for you, so you can make your own decision.

Bottom up

For the “bottom up” way of doing things, we define a lowest common denominator. A set of styles that will work with all the browsers your website is designed to target. The intersection of all the features of all your browsers, if you want to put it that way. From here, we use Modernizr to progressively enhance the user’s browsing experience for browsers that support particular features. An example may help:

a.btn {
  background:transparent url(../img/btn-red.gif) no-repeat scroll 0 0;
  padding:5px;
  display:inline-block;
  width:40px;
}
.borderradius a.btn {
  background-color:red;
  background-image:none;
  border-radius:5px;
}

The advantages being:

  • A clearly defined baseline that works on all browsers we’re coding for
  • If we aren’t able to determine client features (because for example, Modernizr is not available: the CDN is down, or the client doesn’t have JavaScript enabled) we know that the baseline styles will be used and will ensure the site looks acceptable regardless

The disadvantages are:

  • We end up writing more and more CSS as we utilise new features that become available
  • It doesn’t encourage a particularly forward thinking coding practice. You’re essentially coding for the browser with the lowest feature set
  • If you want to change the baseline styles because of a redesign or perhaps your baseline is raised, you’re probably going to have to change overridden styles in the progressive enhancement style blocks as well

Top down

The “top down” approach is where we define styles for new browsers, and then use the “no-” prefix classes to define exceptions for browsers that don’t support the feature we’re exploiting. e.g.

a.btn {
  border-radius:5px;
  background-color:red;
  padding:5px;
  display:inline-block;
  width:40px;
}
.no-borderradius a.btn {
  background:transparent url(../img/btn-red.gif) no-repeat scroll 0 0;
}

We’re forward thinking, assuming everyone viewing our site is using these great new features and coding in fallbacks for the exceptions to the rule. Our view is that one day, all browsers will support the styles we’re using…and we’re adding in exceptions for in the mean time. The advantages are:

  • We end up writing less CSS, as we don’t have to override properties we’ve previously declared that the browser doesn’t understand
  • Our mindset is altered slightly, encouraging us to make use of and exploit new browser features that allow us to code and prototype faster
  • As our browser baseline increases, it’s really easy to remove exceptions that are no longer used

The disadvantages are:

  • We’re totally relying on Modernizr and the browser having JavaScript enabled. Without JavaScript the “no-” prefixed classes are not added to the <html> element and the browser is left trying to style things that aren’t supported or use style declarations that don’t exist (as far as the browser knows).

Well, sort of. You could always use the “no-js” class on the <html> element which Modernizr normally removes and replaces with “js” (to indicate JavaScript is available). You’d define your styles as above, but then define a lowest common denominator style set, for when you don’t know what features a browser does or doesn’t support. That’s kind of overkill though.

So, that’s basically it. When I first thought about it my gut reaction was to sit in the bottom up camp, but after thinking about it, and considering the audience for the project I’m working on it makes more sense to use the top down approach. Especially now that I’ve written it down like this. I’m hoping it’ll help others to make the right decision.

iframe automatic height adjustment using HTML5 cross domain web messaging

Posted on by
61 Replies

Yesterday I was working on a site that needed an iframe embedded in the page whose content came from a completely different domain. I try to steer clear of iframes at all costs normally so forgive me if what I’m about to say is pretty obvious.

I didn’t want the content in the iframe to appear as though it was in an iframe, so obviously I stripped off all the default browser styles…well, the border. I wanted the iframe to be as high as the content it was containing so that no scroll bars would appear.

So what I did was just give the iframe a height, however when the user navigated to a different page within the iframe, the height I had previously set was too big or too small.

I instantly thought “right, JavaScript will sort this out for me!” and proceeded to quickly code up a function that would inspect the scrollHeight of the content in the iframe and adjust the iframe height accordingly.

No! Said cross domain policy. I had momentarily forgotten all about that. Since the iframe content came from a different domain, I wasn’t allowed to access the document object of the iframe (or vice versa).

Here is how not to do it

Firefox says “Error: Permission denied to access property ‘document’” and other browsers similar.

I started searching for some kind of workaround.  Of course there isn’t really one…except I did find an interesting hack for Firefox. Which is – an iframe document can alter the url fragment of the parent window’s location object! ha madness.

The idea is that the document in the iframe alters the url fragment to read:

http://freestyle-developments.co.uk/blog/?p=150#138

Where 138 is the height of the iframe document (obviously you could be a bit more fancy and send other parameters and name them e.g #height:138 but for simplicity I’ve just set the value). The parent then reads this value and sets the iframe height accordingly:

var iFrameHeight = parseInt(location.hash.replace('#', ''));

So…yeah, that’s pretty interesting, but not really a solution. Check out the example implementation here.

Anyway, what to do? HTML5 web messaging to the rescue! Sweet! HTML5 web messaging is cross domain messaging done right. Not only does the messenger choose who should receive messages, but the recipient also chooses who to receive messages from.

The idea is that after the iframe document has loaded, it sends a message to the parent window telling it what it’s scrollHeight is. The parent listens for messages, and sets the height of the iframe when it receives a message.

A couple of things to note:

  1. There has to be communication between the two documents. i.e. the document on the external domain needs to actively send this message. Which can be a complete show stopper if you have no control over the document on the external domain
  2. This isn’t going to work on IE < 9. I tested the implementation linked below is working on FireFox 4 (Beta 7), Safari 5.0.2, Chrome 8, Opera 10.63 and Internet Explorer 9 Platform Preview 7. Which is a pretty good spread to be honest

Check out the example HTML5 web messaging implementation here.

JavaScript Namespace

Posted on by
1 Reply

I normally put my JavaScript function/classes/other things in namespaces. Namespacing your JavaScript is good, it avoids conflicts between scripts on the page and keeps the global namespace clean. I could go into more detail, but luckily it has been done for me.

Declaring namespaces, and checking they exist before using them is a bit of a pain. You might find yourself doing something like:

if(!window.com) window.com = {};
if(!com.mycompany) com.mycompany = {};
if(!com.mycompany.mypackage) com.mycompany.mypackage = {};

…and then add things to it like:

com.mycompany.mypackage.myfunction = function() { return 138; };

To make things worse, if your webpage includes a different script that uses slightly different namespace, say "com.mycompany.mypackage2" you’ll have to check again that the objects "com" and "com.mycompany" already exist.

The following function allows you to use a namespace, without having to manually go through the throws of checking each "space" exists and creating an empty object for each level.

/**
 * I declare a namespace if it doesn't already exist.
 *
 * @param {String} ns The namespace to create/use
 * @param {Object} parent (Optional) The parent object onto which this namespace will be attached.
 * @return True if the namespace was created successfully.
 * @type Boolean
 */
function namespace(ns, parent) {

	if(!parent) {
		parent = window;
	} else {
		// Parent must be an object
		if(typeof(parent) != 'object') {
			return false;
		}
	}

	var names = ns.split('.');

	if(!names.length) {
		return true;
	}

	var name = names[0];

	if(!parent[name]) {
		parent[name] = {};
	}

	if(names.length > 1) {
		names.shift();
		return namespace(names.join('.'), parent[name]);
	}

	return true;
}

…and is used like so:

namespace('com.mycompany.mypackage');
com.mycompany.mypackage.myfunction = function() { return 138; };