Removing jQuery for performance reasons justified?

Question

I am on a new project and our job is to rewrite an e-commerce website that is having performance problems on mobile devices.

We are re-writing the javascript based on a more object-oriented/modular architecture which I think is great! However my team lead said that we should remove all the jQuery calls and replace with javascript like so domElem.querySelectorAll(query) , which has better performance. I understand jQuery does some kind of caching in the background which can create memory issues.

I am a little sceptical of this, firstly because it seems like a case of 'premature optimization', that is, we should find the bottle-necks first before we re-write anything. And secondly I haven't found anything on the internet that says that jQuery has significant performance problems.

The current website does have a lot of overlapping dom branch queries which I think creates a lot of redundancy. That is there is too much querying happening, and on our new architectual approach we are restricting our object/module to fewer dom queries and more targeted dom queries which is great. This does need to be re-written.

But whether or not we use domElem.querySelector(query) or $(domElem).find(query), I can't see there as being much of a difference. Is my thinking right?

Answer 1

Some tests are done here (check other revisions as well). Good detailed discussion is done here over pros and cons of using jquery over javascript.

Also want to point out that jquery doesn't do any caching of selectors.

Answer 2

The thing we often forget because of using Javascript frameworks all the time is that jQuery is not a framework.

Obviously, if you do the exact same one-operator action using the jQuery '$' object and using a direct DOM method like getElementById, the latter will be noticeably faster as jQuery itself is written in Javascript and does a lot of background stuff.

However, nothing (except code readability) prevents you, as a developer, from combining jQuery with plain Javascript: using plain Javascript wherever possible and only using jQuery functions that provide complex functionality and take some time to write and optimize from scratch. There are a lot of those in jQuery: providing browser-independent css, serializing object and doing lots of other cool stuff.

It depends on the application but usually performance troubles are related to badly-designed algorithms, not the use of jQuery.

In any case, if your application does a lot of DOM-manipulation, it may be worthwhile to re-write it using plain Javascript and test. Keep the library, just don't use it for simple operations you can easily write without it.

If your application is heavily-reliant on jQuery functions with complex functionality, removing it is out of the question.

I myself use this combined approach: everything simple written in Javascript with jQuery functions for stuff that is difficult to implement.

Also, a good place to dig around if the app has troubles with performance is the DOM-manipulation. Those operations are very heavy compared to almost everything else in Javascript. You may be able to cut down on time by rolling several operations into one, building finished objects with one constructor, instead of creating empty ones and assigning properties one-by-one, etc.

Sorry, if the answer is a bit vague but it's difficult to be precise in this case without seeing the code and running tests.

Answer 3

Let me quote Uncle Bob about this discussion "Architecture is about intent, we have made it about frameworks and details"

Premature optimizations needs to be considered carefully.

• They often result architectural decisions that are not easily revertible.
• They introduce code optimizations that are usually specific to the problems they solve, which makes the code less abstract thus hard to maintain, and more complicated thus prone to more bugs.
• They tend to be prejudice and not objective, sometimes without any real comparison to other alternatives.
• The problems they are trying to solve tends to be overestimated, to the degree of non-existent.

I'm not a big expert on Web development but if possible, you should always push this kind of decisions to the end by separation of concerns, and good abstraction.

For example over the parts that generate the java-script code you can have an abstraction of JavaScriptWriter, and use different frameworks. This way you can use JQuery at the beginning, test the system and only then replace parts you know to be inefficient.