jQuery is considered harmful
Heh, I always wanted to write one of these "X is considered harmful" posts.
Before I begin, let me say this: I think that jQuery has had an incredible impact on web promotion . He gave the opportunity to developers to do things that were previously considered unthinkable. I forced browser manufacturers to implement many features natively (without jQuery, we probably would never have had document.querySelectorAll). jQuery is still needed by those who cannot rely on modern buns and are forced to maintain relics like IE8 or worse.
Nevertheless, no matter how I sympathize with these poor guys, they are in the minority. Today there are already tons of developers who do not need to support old browsers with their meager market share. And let's not forget those who are not professional developers: students and researchers, not only all this cross-browser compatibility, they often don’t need anything except a single browser! Probably, you expect that in academic circles, everyone is happy to use the newfangled buns of the Open Web Platform? And it's not close, jQuery is just everywhere there. Why? Because jQuery is all that they know, they simply have neither the strength nor the time to follow the web updates. They don't need a reason to use jQuery, it just has to be used. Despite this fact, and the ability to do all these things natively, I still think that this is not the main reason to avoid jQuery.
Definitely I am not the first who pays attention to the fact that almost everything that jQuery can do today is native JavaScript. So I will not repeat and just give a few links:
')
Also, I will not waste time talking about file size and how much faster native methods work. This is all already chewed. Today I want to draw attention to something else.
To avoid extending the prototypes of native objects, jQuery uses its own wrappers over these objects. In the past, extending native objects was considered a huge disadvantage, and not so much because of potential collisions with other extensions, but rather because of permanent memory leaks in IE6. This has been the case since the $ ('div') call returns us not a reference to an element or a list of nodes, but a certain jQuery object. This means that the jQuery object contains completely different methods than the usual reference to the home element or list of nodes.
Nevertheless, these links all the time climbs out in real projects. No matter how jQuery tries to abstract from them, you still have to constantly operate on them, even if you just wrap these links in $ (). For example, a callback context in the case of calling the jQuery method .bind () will be a reference to the house element, and not to the jQuery collection. It is also worth noting that you often use libraries from different sources, some of them need jQuery, and some don't. All this leads to the fact that at the output we are waiting for a hell of a mixture of native elements of the house, lists of nodes and jQuery objects .
If the developer adheres to the naming convention of jQuery objects (adding $ in front of the variable name) and ordinary variables containing references to native elements, then this certainly smooths the problem (although people tend to forget about any conventions, but let's assume that we live in an ideal world). Be that as it may, in most cases, the developers have never heard of such conventions, and as a result, it is extremely difficult for their people to understand them. Each attempt to edit such code entails a lot of errors in the style “Oh, damn, this is not a jQuery object, forgot to wrap it in $ ()” or “Damn, it was not the home element that forgot to take it through $ (..) [ 0] ". To avoid embarrassment, developers often end up starting to wrap everything up in $ (), just in case. Reading the code after, you can see that the same variable wraps around $ () many times. For the same reason, it becomes very difficult to refactor this code so that it does not use jQuery. So in essence we get a hopeless situation .
Even if you strictly adhere to the naming convention for variables, there is still often a situation when you need to call a native method for a home element or run a function from code that does not depend on jQuery. And after some time, your code will be already scored from top to bottom with the translation of objects from jQuery into native and vice versa.
Suppose, after some time, you decide to add a couple more features for such a program, and in most cases you will end up wrapping all the new links to the house elements and collections in $ () again. After all, you can not always know exactly in which case you need this or that link. So again, it is a hopeless situation that also applies to all future code!
Take any random script with jQuery dependency and try to save it from this dependency. Run away. You will see that your main task is not to convert methods to native ones, but to generally understand what the hell is going on here.
Of course, many libraries today require jQuery, and as I tweeted recently, trying to get rid of it completely would be like some kind of digital veganism. And yet this does not mean that you need to continue to use it. Libraries can always be replaced in the future when their versions are not using jQuery.
In addition, many libraries are written so that they do not require the presence of $ variable as a synonym for jQuery. Just call jQuery.noConflict () to pick up the $ variable and find the best use for it. For example, I often use these helper functions when inspired by the Command Line API :
In addition, I think that if you have to type jQuery instead of $ each time, then you will think twice, do I really need it? IMHO of course.
Also, if you really like the jQuery API a lot, but you want to avoid bloating code, consider using Zepto .
Before I begin, let me say this: I think that jQuery has had an incredible impact on web promotion . He gave the opportunity to developers to do things that were previously considered unthinkable. I forced browser manufacturers to implement many features natively (without jQuery, we probably would never have had document.querySelectorAll). jQuery is still needed by those who cannot rely on modern buns and are forced to maintain relics like IE8 or worse.
Nevertheless, no matter how I sympathize with these poor guys, they are in the minority. Today there are already tons of developers who do not need to support old browsers with their meager market share. And let's not forget those who are not professional developers: students and researchers, not only all this cross-browser compatibility, they often don’t need anything except a single browser! Probably, you expect that in academic circles, everyone is happy to use the newfangled buns of the Open Web Platform? And it's not close, jQuery is just everywhere there. Why? Because jQuery is all that they know, they simply have neither the strength nor the time to follow the web updates. They don't need a reason to use jQuery, it just has to be used. Despite this fact, and the ability to do all these things natively, I still think that this is not the main reason to avoid jQuery.
Yes, most likely, you do not need him ...
Definitely I am not the first who pays attention to the fact that almost everything that jQuery can do today is native JavaScript. So I will not repeat and just give a few links:
')
- Do you need jQuery?
- You probably don't need jQuery
- You definitely don't need jQuery!
- 10 tips on how to write in javascript without jQuery
- …and so on. Just google “you don't need jQuery” and you will be overwhelmed with tips.
Also, I will not waste time talking about file size and how much faster native methods work. This is all already chewed. Today I want to draw attention to something else.
... but it's still not the reason to stop using it.
To avoid extending the prototypes of native objects, jQuery uses its own wrappers over these objects. In the past, extending native objects was considered a huge disadvantage, and not so much because of potential collisions with other extensions, but rather because of permanent memory leaks in IE6. This has been the case since the $ ('div') call returns us not a reference to an element or a list of nodes, but a certain jQuery object. This means that the jQuery object contains completely different methods than the usual reference to the home element or list of nodes.
Nevertheless, these links all the time climbs out in real projects. No matter how jQuery tries to abstract from them, you still have to constantly operate on them, even if you just wrap these links in $ (). For example, a callback context in the case of calling the jQuery method .bind () will be a reference to the house element, and not to the jQuery collection. It is also worth noting that you often use libraries from different sources, some of them need jQuery, and some don't. All this leads to the fact that at the output we are waiting for a hell of a mixture of native elements of the house, lists of nodes and jQuery objects .
If the developer adheres to the naming convention of jQuery objects (adding $ in front of the variable name) and ordinary variables containing references to native elements, then this certainly smooths the problem (although people tend to forget about any conventions, but let's assume that we live in an ideal world). Be that as it may, in most cases, the developers have never heard of such conventions, and as a result, it is extremely difficult for their people to understand them. Each attempt to edit such code entails a lot of errors in the style “Oh, damn, this is not a jQuery object, forgot to wrap it in $ ()” or “Damn, it was not the home element that forgot to take it through $ (..) [ 0] ". To avoid embarrassment, developers often end up starting to wrap everything up in $ (), just in case. Reading the code after, you can see that the same variable wraps around $ () many times. For the same reason, it becomes very difficult to refactor this code so that it does not use jQuery. So in essence we get a hopeless situation .
Even if you strictly adhere to the naming convention for variables, there is still often a situation when you need to call a native method for a home element or run a function from code that does not depend on jQuery. And after some time, your code will be already scored from top to bottom with the translation of objects from jQuery into native and vice versa.
Suppose, after some time, you decide to add a couple more features for such a program, and in most cases you will end up wrapping all the new links to the house elements and collections in $ () again. After all, you can not always know exactly in which case you need this or that link. So again, it is a hopeless situation that also applies to all future code!
Take any random script with jQuery dependency and try to save it from this dependency. Run away. You will see that your main task is not to convert methods to native ones, but to generally understand what the hell is going on here.
Pragmatic path to pure JS
Of course, many libraries today require jQuery, and as I tweeted recently, trying to get rid of it completely would be like some kind of digital veganism. And yet this does not mean that you need to continue to use it. Libraries can always be replaced in the future when their versions are not using jQuery.
In addition, many libraries are written so that they do not require the presence of $ variable as a synonym for jQuery. Just call jQuery.noConflict () to pick up the $ variable and find the best use for it. For example, I often use these helper functions when inspired by the Command Line API :
// , CSS {expr}. // {container}- function $(expr, container) { return typeof expr === "string"? (container || document).querySelector(expr) : expr || null; } // CSS {expr} . // {container}- function $$(expr, container) { return [].slice.call((container || document).querySelectorAll(expr)); } In addition, I think that if you have to type jQuery instead of $ each time, then you will think twice, do I really need it? IMHO of course.
Also, if you really like the jQuery API a lot, but you want to avoid bloating code, consider using Zepto .
Source: https://habr.com/ru/post/259223/
All Articles