5 mistakes you may make in your front-end JavaScript

Writing front-end code in JavaScript can be tricky. The quality of your code not only affects the visual appearance of your app, but also the whole feeling and responsiveness of the GUI. Getting it right is important.

It can take new developers months, or even years, to learn all the pitfalls and best practices involved in writing a JavaScript front-end from scratch. There are plenty of good tutorials out there, but mostly they focus on JQuery or micro-optimization.

In the process of building the KeyLines data visualization SDK (and supporting our growing range of customers) we’ve built up quite a list of tips and recommendations.

So, this blog post is our top 5 tips based on mistakes we see in other people’s code.*

*Although, in their defense, we have made all of these mistakes at some point too.

1. Use dictionaries for lookups

When you are filtering using a JavaScript dictionary, it is much more efficient than a lookup with an array.

Filter criteria like this:

   function criteria(item){
   return dict[item.id];
 }

Is going to be a lot faster than filter criteria like this:

   function criteria(item){
   return contains(array, item);
 }

If an array is needed anyway, it’s still going to be quicker to perform a single iteration on the array to produce the dictionary, rather than using the contain function:

var myArray = [ …list of items… ];
var dict = {};
for( var i=0; i< myArray.length; i++){
  dict[myArray[i].id] = true;
}
... and then do the filtering here.

2. Limit the number of fetches

This sounds obvious, but it’s surprising how often we see it. Your code is going to be more efficient if you limit the number of fetches performed.

If, for example, you have a list of IDs to iterate over, it is much more efficient to fetch those items once and iterate through them than to do a getItem for each iteration step. This is because each time you perform a get request, there’s a ‘checking’ cost. While it can be small for a single request, it can hit the performances when done repeatedly.

So this:

   var items = chart.getItem(idList);
 for( var i=0; < items.length; i++){
   var item = items[i];
   // etc...
 }

Is faster than this:

   for( var i=0; i < idList.length; i++){
     var item = chart.getItem(idList[i]);
     // etc...
   }

3. Changing properties in loops

When changes have to be made to an entity, it’s always better to collect all the changes once and call a single set function, in particular for an anything animated.

For example, avoid this:

chart.each({type: 'link'}, function (link){
   chart.setProperties ({id: link.id, a1: true, ...more here... });
});

This is much better:

  var changes = [];
   chart.each({type: 'link'}, function (link){
     changes.push({id: link.id, a1: true, ...more changes here... });
   });
   chart.setProperties(changes);

4. Know when to use Regular Expressions

Changing properties with the precise ID of an item can sometimes be quicker than triggering a ReGex search. Taking an example from a KeyLines application:

If you have a network and you want to apply a consistent pattern across your chart, a Regular Expression is your best option.

If, however, you want to apply multiple patterns across your chart, a RegEx will kill your application performance.

Choosing the right approach for your particular use is key.

5. Don’t forget that animations are asynchronous

Our final common pitfall is when people use animations as though they are synchronous functions. They are not.

If you want faster computation, call the animations in a logical and efficient order.

Taking another example from KeyLines… If you want to perform a new layout each time you filter data in your chart:

Don’t do this:

chart.filter(…);
// The layout will run considering also the filtered items
chart.layout(…);

Instead, do this:

// Layout will be called now at the end of the filtering animation
// optimizing the displacement of the items as well
chart.filter(criteria, {}, doLayout);

function doLayout(){
  chart.layout( … );
}