Efficiency-first versus the collaborative-friendly
Often when it comes to back-end code then the immediate answer would be to be as efficient as possible but, while that may solve today’s problems quickly when tomorrow’s problems arise it unearths a whole world of pain, especially if a different development team pick up the project.
Code can be extremely well written in terms of efficiency when crafted for a specific project. However, digital projects are rarely just one iteration. Business change, technologies change and ultimately what you need your software to do also changes.
There is no doubt that web pages and web applications should be snappy, so keeping your code as small as possible should definitely be at the forefront of your design; laggy JavaScript can ruin a user’s experience completely. But equally, you might not be the only developer to have to work on this file or functionality and invariably when a developer doesn’t understand existing code they break it, or duplicate it, or worse still, waste productive time re-writing it all.
Commenting code should be as important as writing the code itself. The important thing about comments is that not only does it mean it’s easier for someone to understand the code, but the comments can walk them through it, give them examples of parameters or explain any abstract functions and patterns. Equally, you can also explain any decisions you’ve made that might not be obvious.
Use good programming practices; JavaScript is a very loose language, but it doesn’t mean your code has to be loose too. Using tools like JSLint you can make sure that you don’t accidentally start using a variable without declaring it meaning that one day it will make no sense whatsoever to someone else picking up development.
If you have built a jQuery plugin try to continue to write in nativeJavaScript where possible; for example, loops are typical for loops rather than using jQuery .each loops. Most, if not all, selectors are written to best use native DOM operations such as getElementByID(), or on modern browsers use fulfeatures like querySelectorAll(). Any complex and non-native selectors should be broken down so that you use the nearest ID, element or class selector and simply .find() or .filter() within the collection. If you read up on jQuery performance, you’d be surprised by the difference it makes.
Put time aside for code re-factoring. As your code grows it’s very likely that you will repeat functionality, whether it’s duplicating some code in a multiple-condition block or repeating an action in two different functions. During this process you might also notice a better way to do what you’re trying to achieve and it’s also a very good opportunity to make sure you are caching.
One of the biggest benefactors in coding efficiency is caching. Caching is simple but effective. If you cache a selector, it saves you re-creating jQuery object repeatedly. Take this following code:
$("#myForm").submit(function(e){ e.preventDefault();
if ($(this).validateForm() ) {
$(this).find("input, select, textarea").attr("disabled", "disabled");
$(this).find(".errorMessage").hide();
$.ajax({
url:"submit.php",
data: $(this).serialize(),
success:function () {
$(this).find("input,select, textarea").removeAttr("disabled");
$(this).find(".successMessage").show();
}
});
} else {
$(this).find(".errorMessage").show();
}
});
Notice how many times we create a jQuery object using “this”. Instead, we could cache “this” as a jQuery object in a variable which would save us fromre-creating the object, like so:
$("#myForm").submit(function(e){
var thisForm = $(this);
e.preventDefault();
if (thisForm.validateForm() ) {
thisForm.find("input, select, textarea").attr("disabled", "disabled");
thisForm.find(".errorMessage").hide();
$.ajax({
url:"submit.php",
data:thisForm.serialize(),
success:function () {
thisForm.find("input,select, textarea").removeAttr("disabled");
thisForm.find(".successMessage").show();
}
});
} else {
thisForm.find(".errorMessage").show();
}
});
It might not seem a lot, but each slice of processing time saved soon adds up, imagine if this was inside a loop that was executed hundreds or thousands of times.
One of the things with creating a jQuery plugin is that when the plugin is instantiated it will return back the jQuery collection from the original selector. Why is this important? It’s important because we can do multiple actions to a collection without recreating the collection. So, it’s a bit like caching too, for example:
$(".successMessage").addClass("highlight");
$(".successMessage").slideDown();
$(".successMessage").css("marginBottom","20px");
3 lines of code could effectively become one:
$(".successMessage").addClass("highlight").slideDown().css("marginBottom","20px");
There’s nothing wrong with chaining to your cached objects either, just be careful of jQuery methods that don’t return the collection e.g. serialize().
If we put all that together we get well documented code that the next developer can pick up and understand, while also keeping our user’s experiences as streamlined as possible.
So, what is more important, focusing primarily on efficiency or making your code as readable and understandable as possible? Given the iterative nature of digital projects readable code is essential to future proofing your products. Just because it’s readable doesn’t mean it has to be bloated; minifying and clever programming can make that readable code extremely performance efficient.
Often when it comes to back-end code then the immediate answer would be to be as efficient as possible but, while that may solve today’s problems quickly when tomorrow’s problems arise it unearths a whole world of pain, especially if a different development team pick up the project.
Code can be extremely well written in terms of efficiency when crafted for a specific project. However, digital projects are rarely just one iteration. Business change, technologies change and ultimately what you need your software to do also changes.
There is no doubt that web pages and web applications should be snappy, so keeping your code as small as possible should definitely be at the forefront of your design; laggy JavaScript can ruin a user’s experience completely. But equally, you might not be the only developer to have to work on this file or functionality and invariably when a developer doesn’t understand existing code they break it, or duplicate it, or worse still, waste productive time re-writing it all.
Commenting code should be as important as writing the code itself. The important thing about comments is that not only does it mean it’s easier for someone to understand the code, but the comments can walk them through it, give them examples of parameters or explain any abstract functions and patterns. Equally, you can also explain any decisions you’ve made that might not be obvious.
Use good programming practices; JavaScript is a very loose language, but it doesn’t mean your code has to be loose too. Using tools like JSLint you can make sure that you don’t accidentally start using a variable without declaring it meaning that one day it will make no sense whatsoever to someone else picking up development.
If you have built a jQuery plugin try to continue to write in nativeJavaScript where possible; for example, loops are typical for loops rather than using jQuery .each loops. Most, if not all, selectors are written to best use native DOM operations such as getElementByID(), or on modern browsers use fulfeatures like querySelectorAll(). Any complex and non-native selectors should be broken down so that you use the nearest ID, element or class selector and simply .find() or .filter() within the collection. If you read up on jQuery performance, you’d be surprised by the difference it makes.
Put time aside for code re-factoring. As your code grows it’s very likely that you will repeat functionality, whether it’s duplicating some code in a multiple-condition block or repeating an action in two different functions. During this process you might also notice a better way to do what you’re trying to achieve and it’s also a very good opportunity to make sure you are caching.
One of the biggest benefactors in coding efficiency is caching. Caching is simple but effective. If you cache a selector, it saves you re-creating jQuery object repeatedly. Take this following code:
$("#myForm").submit(function(e){ e.preventDefault();
if ($(this).validateForm() ) {
$(this).find("input, select, textarea").attr("disabled", "disabled");
$(this).find(".errorMessage").hide();
$.ajax({
url:"submit.php",
data: $(this).serialize(),
success:function () {
$(this).find("input,select, textarea").removeAttr("disabled");
$(this).find(".successMessage").show();
}
});
} else {
$(this).find(".errorMessage").show();
}
});
Notice how many times we create a jQuery object using “this”. Instead, we could cache “this” as a jQuery object in a variable which would save us fromre-creating the object, like so:
$("#myForm").submit(function(e){
var thisForm = $(this);
e.preventDefault();
if (thisForm.validateForm() ) {
thisForm.find("input, select, textarea").attr("disabled", "disabled");
thisForm.find(".errorMessage").hide();
$.ajax({
url:"submit.php",
data:thisForm.serialize(),
success:function () {
thisForm.find("input,select, textarea").removeAttr("disabled");
thisForm.find(".successMessage").show();
}
});
} else {
thisForm.find(".errorMessage").show();
}
});
It might not seem a lot, but each slice of processing time saved soon adds up, imagine if this was inside a loop that was executed hundreds or thousands of times.
One of the things with creating a jQuery plugin is that when the plugin is instantiated it will return back the jQuery collection from the original selector. Why is this important? It’s important because we can do multiple actions to a collection without recreating the collection. So, it’s a bit like caching too, for example:
$(".successMessage").addClass("highlight");
$(".successMessage").slideDown();
$(".successMessage").css("marginBottom","20px");
3 lines of code could effectively become one:
$(".successMessage").addClass("highlight").slideDown().css("marginBottom","20px");
There’s nothing wrong with chaining to your cached objects either, just be careful of jQuery methods that don’t return the collection e.g. serialize().
If we put all that together we get well documented code that the next developer can pick up and understand, while also keeping our user’s experiences as streamlined as possible.
So, what is more important, focusing primarily on efficiency or making your code as readable and understandable as possible? Given the iterative nature of digital projects readable code is essential to future proofing your products. Just because it’s readable doesn’t mean it has to be bloated; minifying and clever programming can make that readable code extremely performance efficient.
Often when it comes to back-end code then the immediate answer would be to be as efficient as possible but, while that may solve today’s problems quickly when tomorrow’s problems arise it unearths a whole world of pain, especially if a different development team pick up the project.
Code can be extremely well written in terms of efficiency when crafted for a specific project. However, digital projects are rarely just one iteration. Business change, technologies change and ultimately what you need your software to do also changes.
There is no doubt that web pages and web applications should be snappy, so keeping your code as small as possible should definitely be at the forefront of your design; laggy JavaScript can ruin a user’s experience completely. But equally, you might not be the only developer to have to work on this file or functionality and invariably when a developer doesn’t understand existing code they break it, or duplicate it, or worse still, waste productive time re-writing it all.
Commenting code should be as important as writing the code itself. The important thing about comments is that not only does it mean it’s easier for someone to understand the code, but the comments can walk them through it, give them examples of parameters or explain any abstract functions and patterns. Equally, you can also explain any decisions you’ve made that might not be obvious.
Use good programming practices; JavaScript is a very loose language, but it doesn’t mean your code has to be loose too. Using tools like JSLint you can make sure that you don’t accidentally start using a variable without declaring it meaning that one day it will make no sense whatsoever to someone else picking up development.
If you have built a jQuery plugin try to continue to write in nativeJavaScript where possible; for example, loops are typical for loops rather than using jQuery .each loops. Most, if not all, selectors are written to best use native DOM operations such as getElementByID(), or on modern browsers use fulfeatures like querySelectorAll(). Any complex and non-native selectors should be broken down so that you use the nearest ID, element or class selector and simply .find() or .filter() within the collection. If you read up on jQuery performance, you’d be surprised by the difference it makes.
Put time aside for code re-factoring. As your code grows it’s very likely that you will repeat functionality, whether it’s duplicating some code in a multiple-condition block or repeating an action in two different functions. During this process you might also notice a better way to do what you’re trying to achieve and it’s also a very good opportunity to make sure you are caching.
One of the biggest benefactors in coding efficiency is caching. Caching is simple but effective. If you cache a selector, it saves you re-creating jQuery object repeatedly. Take this following code:
$("#myForm").submit(function(e){ e.preventDefault();
if ($(this).validateForm() ) {
$(this).find("input, select, textarea").attr("disabled", "disabled");
$(this).find(".errorMessage").hide();
$.ajax({
url:"submit.php",
data: $(this).serialize(),
success:function () {
$(this).find("input,select, textarea").removeAttr("disabled");
$(this).find(".successMessage").show();
}
});
} else {
$(this).find(".errorMessage").show();
}
});
Notice how many times we create a jQuery object using “this”. Instead, we could cache “this” as a jQuery object in a variable which would save us fromre-creating the object, like so:
$("#myForm").submit(function(e){
var thisForm = $(this);
e.preventDefault();
if (thisForm.validateForm() ) {
thisForm.find("input, select, textarea").attr("disabled", "disabled");
thisForm.find(".errorMessage").hide();
$.ajax({
url:"submit.php",
data:thisForm.serialize(),
success:function () {
thisForm.find("input,select, textarea").removeAttr("disabled");
thisForm.find(".successMessage").show();
}
});
} else {
thisForm.find(".errorMessage").show();
}
});
It might not seem a lot, but each slice of processing time saved soon adds up, imagine if this was inside a loop that was executed hundreds or thousands of times.
One of the things with creating a jQuery plugin is that when the plugin is instantiated it will return back the jQuery collection from the original selector. Why is this important? It’s important because we can do multiple actions to a collection without recreating the collection. So, it’s a bit like caching too, for example:
$(".successMessage").addClass("highlight");
$(".successMessage").slideDown();
$(".successMessage").css("marginBottom","20px");
3 lines of code could effectively become one:
$(".successMessage").addClass("highlight").slideDown().css("marginBottom","20px");
There’s nothing wrong with chaining to your cached objects either, just be careful of jQuery methods that don’t return the collection e.g. serialize().
If we put all that together we get well documented code that the next developer can pick up and understand, while also keeping our user’s experiences as streamlined as possible.
So, what is more important, focusing primarily on efficiency or making your code as readable and understandable as possible? Given the iterative nature of digital projects readable code is essential to future proofing your products. Just because it’s readable doesn’t mean it has to be bloated; minifying and clever programming can make that readable code extremely performance efficient.
Often when it comes to back-end code then the immediate answer would be to be as efficient as possible but, while that may solve today’s problems quickly when tomorrow’s problems arise it unearths a whole world of pain, especially if a different development team pick up the project.
Code can be extremely well written in terms of efficiency when crafted for a specific project. However, digital projects are rarely just one iteration. Business change, technologies change and ultimately what you need your software to do also changes.
There is no doubt that web pages and web applications should be snappy, so keeping your code as small as possible should definitely be at the forefront of your design; laggy JavaScript can ruin a user’s experience completely. But equally, you might not be the only developer to have to work on this file or functionality and invariably when a developer doesn’t understand existing code they break it, or duplicate it, or worse still, waste productive time re-writing it all.
Commenting code should be as important as writing the code itself. The important thing about comments is that not only does it mean it’s easier for someone to understand the code, but the comments can walk them through it, give them examples of parameters or explain any abstract functions and patterns. Equally, you can also explain any decisions you’ve made that might not be obvious.
Use good programming practices; JavaScript is a very loose language, but it doesn’t mean your code has to be loose too. Using tools like JSLint you can make sure that you don’t accidentally start using a variable without declaring it meaning that one day it will make no sense whatsoever to someone else picking up development.
If you have built a jQuery plugin try to continue to write in nativeJavaScript where possible; for example, loops are typical for loops rather than using jQuery .each loops. Most, if not all, selectors are written to best use native DOM operations such as getElementByID(), or on modern browsers use fulfeatures like querySelectorAll(). Any complex and non-native selectors should be broken down so that you use the nearest ID, element or class selector and simply .find() or .filter() within the collection. If you read up on jQuery performance, you’d be surprised by the difference it makes.
Put time aside for code re-factoring. As your code grows it’s very likely that you will repeat functionality, whether it’s duplicating some code in a multiple-condition block or repeating an action in two different functions. During this process you might also notice a better way to do what you’re trying to achieve and it’s also a very good opportunity to make sure you are caching.
One of the biggest benefactors in coding efficiency is caching. Caching is simple but effective. If you cache a selector, it saves you re-creating jQuery object repeatedly. Take this following code:
$("#myForm").submit(function(e){ e.preventDefault();
if ($(this).validateForm() ) {
$(this).find("input, select, textarea").attr("disabled", "disabled");
$(this).find(".errorMessage").hide();
$.ajax({
url:"submit.php",
data: $(this).serialize(),
success:function () {
$(this).find("input,select, textarea").removeAttr("disabled");
$(this).find(".successMessage").show();
}
});
} else {
$(this).find(".errorMessage").show();
}
});
Notice how many times we create a jQuery object using “this”. Instead, we could cache “this” as a jQuery object in a variable which would save us fromre-creating the object, like so:
$("#myForm").submit(function(e){
var thisForm = $(this);
e.preventDefault();
if (thisForm.validateForm() ) {
thisForm.find("input, select, textarea").attr("disabled", "disabled");
thisForm.find(".errorMessage").hide();
$.ajax({
url:"submit.php",
data:thisForm.serialize(),
success:function () {
thisForm.find("input,select, textarea").removeAttr("disabled");
thisForm.find(".successMessage").show();
}
});
} else {
thisForm.find(".errorMessage").show();
}
});
It might not seem a lot, but each slice of processing time saved soon adds up, imagine if this was inside a loop that was executed hundreds or thousands of times.
One of the things with creating a jQuery plugin is that when the plugin is instantiated it will return back the jQuery collection from the original selector. Why is this important? It’s important because we can do multiple actions to a collection without recreating the collection. So, it’s a bit like caching too, for example:
$(".successMessage").addClass("highlight");
$(".successMessage").slideDown();
$(".successMessage").css("marginBottom","20px");
3 lines of code could effectively become one:
$(".successMessage").addClass("highlight").slideDown().css("marginBottom","20px");
There’s nothing wrong with chaining to your cached objects either, just be careful of jQuery methods that don’t return the collection e.g. serialize().
If we put all that together we get well documented code that the next developer can pick up and understand, while also keeping our user’s experiences as streamlined as possible.
So, what is more important, focusing primarily on efficiency or making your code as readable and understandable as possible? Given the iterative nature of digital projects readable code is essential to future proofing your products. Just because it’s readable doesn’t mean it has to be bloated; minifying and clever programming can make that readable code extremely performance efficient.
