Shortlink

Issues with standalone jQuery/jQuery Mobile

Scanning the code of my recently concluded project using jQuery and jQuery Mobile threw light on a number of issues with using these two libraries in a project. Yes, there are lot of positive points of using jQuery/jQM but let’s jot down few negative points.

  • There’s no built-in design pattern/strategy to write jQuery code in our applications. It lands up looking like a C-program finally.
  • The mobile applications use the single HTML file architecture. Maintaining the UI code in a single file as you would do in jQM is certainly very bad and painful in the long run.
  • You have to put in effort to segregate the JS code in different files, based on the functionalities.
  • The previous point makes it difficult to use a library like QUnit for testing.
  • After modularizing the code in different JS files, you have to include these scripts using the script tags in your single HTML file and mind you, in the correct order.
  • If you add all these JS files in HTML, say you have split your jQuery code in 10 files, the browser will send 10 requests to load every file, which is pretty horrible.
  • jQuery Mobile does not provide any facility to develop templated/reusable UI. For instance, if you want to have a footer on every screen, then you need to think of a pattern to not duplicate this piece of code.
  • jQuery leads to an explosion of global variables in the application.
  • jQuery mobile is very simple, but still ill-suited for building enterprise applications. You would anytime prefer using Sencha Touch for that.

In summary, it’s very difficult to maintain the application build using vanilla jQUery and jQueryMobile.

Off late, we have been stressing our clients to use jQuery and jQueryMobile with frameworks like Backbone.js and require.js. Backbone takes care of the segregation of your code into views and models. Require JS takes care of the dependency management, optimizing the loading of JS files and also organizing the code into modules. If you have to create maintainable jQuery code, you’ll have to use these libraries alongwith.

The moral of the story is, never use jQuery/jQM alone in your project. Use it with Backbone/require or even KnockOut.js.

Shortlink

Powerpoint training or Coding workshop?

During one of the conferences a couple of years back in Bangalore after an hour and half of my talk(!!!) on Flex MVC, one of the organizers quipped, “Oh, this is not a presentation, it’s a workshop”, much to my dismay. It amuses me everytime, when the organizers ask to follow a particular format and design in their slides, when you want to scream, “I’m not going to use slides at all”

To all the clients that have interacted with me before a training programme, there are few points that I have always emphasized.

  • I’m not a power point guy. Will not bore you, by running you through presentations
  • Will make you code so much, that after the training, you can get started working with your project comfortably.
  • If you’re not interested in coding, don’t attend my training

It makes me wonder how you can talk about Flex MVC for one and half hours without writing even single line of code. Technical trainings/talks/code workshop or whatever one chooses to call, will be a snoozefest if you keep showing slides for more than five minutes.

Slides are best used to show pictures, diagrams or animations to explain a concept even better. Showing code in a slide is another useless routine.

Even if you aren’t interested in seeing code in a technical talk, you’re bound to get exhausted just by seeing slides that pop in lines and lines of text with some weird animations.

A lot of top notch technical speakers/trainers that I have interacted with, it doesn’t matter you call the event a training or workshop because they know only way of deliveing a technical lecture, by writing code. They make the talks interesting by playing with number of tools, languages and of course, by writing high quality code.

Somebody had said long before, “Code speaks more than words:)

Shortlink

Unit testing JavaScript – III

In the earlier post, we discussed using QUnit to unit-test JavaScript. We didn’t have any UI in the example. Let’s build a simple UI to call the Calculator’s add and subtract functions. Let’s use jQuery to construct the UI as shown below.

The calculatortests.html file is shown below.

<!--calculatortests.html-->
<!DOCTYPE html>
<html>
<head>
	<script src="jquery-1.7.2.js"></script>
	<script src="calculator.js"></script>
</head>
<body>
	Number 1<input type="text" id="num1"><br/>
	Number 2<input type="text" id="num2"><br/>
	<input type="button"  value="Add" id="addBtn"><br/>
	<input type="button"  value="Subtract" id="subtractBtn">
	<h1 id="results"></h1>
</body>
</html>

Hitting the Add/Subtract button will display the results in h1 element. The Calculator.js file with the UI functionality is shown below:

$().ready(function(){
	$("#addBtn").on("click",function(){
	var results = add(parseInt($("#num1").val()),parseInt($("#num2").val()));
		$("#results").html("Sum is " + results);
	});
	$("#subtractBtn").on("click",function(){
		var results = subtract(parseInt($("#num1").val()),parseInt($("#num2").val()));
		$("#results").html("Difference is " + results);
	});
});
function add(a,b){
	return a+b;
}
function subtract(a,b){
	return a-b;
}

We’ll now create a calculatortests.js that has the test for add and subtract functions. This file will also have the test to display the results in h1 element when the buttons are clicked.

test("Addition",function(){
	equal(4,add(2,2),"2+2 is 4");
});
test("Subtraction",function(){
	equal(4,subtract(6,2),"Difference of 6,2 is 4");
});
test("Addition with UI",function(){
	$("#num1").val(4);
	$("#num2").val(12);
	$("#addBtn").trigger("click");
	equal($("#results").text(),"Sum is 16","Results contains Sum is 16");
});

What’s interesting is the test “Addition with UI”. We set the values in the textboxes explicility and programmatically trigger the click event of the button. We test if the h1 element results contains the expected output.

Let’s include calculatortests.js,qunit.js, qunit.css and also a div element with id as “qunit in the calculatortests.html. Executing the page gives you the following output.

As you can see, testing jQuery code using qunit is pretty easy as well. The “trigger” function does the magic. How about having some AJAX calls in our code?Let’s look at it in the next post.

Shortlink

Unit testing JavaScript – II

In the earlier post, we discussed the need for unit testing JavaScript code. Continuing further, let’s write a simple piece of JavaScript code and test it using QUnit library.

To begin with, let’s create a file calculator.js and have two functions add and subtract as shown below. You can ignore the UI for the time being.

function add(a,b){
	return a+b;
}
function subtract(a,b){
	return a-b;
}

Let’s create a calculatortests.js file where we’ll use QUnit to test the add and subtract functions. QUnit provides simple syntax to test the functions. We’ll use the simple function “equal” for asserting the results of add and subtract functions. The code to test the add and subtract functions are shown below.

test("Addition",function(){
		equal(4,add(2,2),"2+2 is 4");
});
test("Subtraction",function(){
	equal(4,subtract(6,2),"Difference of 6,2 is 4");
});

Every test runs independently similar to the unit testing nomenclature. The test function accepts the name of the test and a function that is executed as the test. The equal function is similar to the assertXXX methods in JUnit. That’s it!!! Let’s set up the whole stuff and execute the tests.

Let’s create a calculatortests.html with the the following files included, qunit.css, qunit.js, calculator.js, and calculatortests.js. For QUnit to publish the results in the page we need the following div element in the html file.

<div id="qunit"></div>

The calculatortests.html file is shown below.

<!DOCTYPE html>
<html>
<head>
	<link rel="stylesheet" href="qunit-1.9.0.css">
	<script src="qunit-1.9.0.js"></script>
	<script src="calculator.js"></script>
	<script src="calculatortests.js"></script>
</head>
<body>
	<div id="qunit"></div>
</body>
</html>

Running the calculatortests.html file will give you the following output, that contains the results of the tests.

As we can see, testing javascript code using QUnit is pretty easy. In the next post, we’ll toss up some UI code and test it using QUnit.

Shortlink

Unit testing JavaScript – I

Unit testing in JavaScript is an overlooked concept. With the increase in use of JavaScript in applications, testing JavaScript code has become an imperative task. A number of developers who use JavaScript, particularly jQuery ignore testing the JS code. They still resort to manual testing.

Requirements evolve/change almost everyday in projects, and so does your code. JUnit/NUnit test cases act as our guards that complain when the Java/.NET code behaves the way it shouldn’t. We use unit testing a lot (even if you don’t practice TDD) atleast for the sake of automating testing. Somehow this isn’t the case with JavaScript.

My experience with JavaScript in projects has always been unpleasant, because after the code base starts growing, things begin getting out of control. One small change in the functionality, you will be left starring at the code for hours not knowing whether the change you have made will affect other portions of the application or not. While we realize the importance of having unit tests in C# and Java applications, we don’t see the same in JavaScript.

If the UI of your application and communication and data exchange logic are completely implemented in JavaScript, the job will be a nightmare when you don’t have solid test cases backing up your JavaScript code.

There are a number of JavaScript test libraries like Jasmine, JSUnit, QUnit etc., which can be readily used in applications. I have been a fan of QUnit for it’s sheer simplicity. It has been of immense use particularly when jQuery is used.

In the next post, we’ll discuss writing test cases using QUnit.