In the two previous posts we saw how jQuery might slow down your Web application and how its programming model was viral and easily led to tighten coupling between the JavaScript code and the page markup.

In this post we’ll go one step further and see why using jQuery will not help you to write complex applications code.

If you look back on the code of the list widget written in the first post, you’ll find that a lot of concerns are entangled in these few lines of code (markup parsing, objects state handling, events handling, business logic, etc.). Actually, I’m more responsible of these mistakes than jQuery, but I keep thinking that jQuery does not help to avoid this kind of mistakes.

Why? Because of its chaining API and its selector based approach, you are encouraged to both use the DOM as your object state and to write all your code — despite it addresses different concerns: state management, interaction management, etc. — in a same place.

Actually you can use jQuery to write a web application. A lot of developers do so and it works. What I wanted to point in my last three posts is that you have to be careful of the way jQuery may lead you to write code, so don’t forget important development principles such as separation of concerns.