Fortunately, people usually have a variety of different plugins to choose from. But even if you only use one, figure out whether it's worth using. Never introduce bad code into your code base.
Do you need a plug-in?
The first thing is to figure out whether you need a plug-in. If you don't need it, you'll save both file size and yourself time.
1. Is it better to write it yourself?
If the function is very simple, write it yourself. Plugins for jQuery often bundle various features, which can be overkill. In this case, it often makes more sense to write any simple functions by hand. Of course, there is some measure of the amount of work involved.
For example, if you need more advanced features, jQuery UI’s accordion is a good choice. But if you just need to open and close the panel. If you're not already using jQuery UI on your website, consider jQuery's slideToggle() or animate().
2. Are you already using a similar plug-in?
It’s very tempting to find that a plug-in doesn’t solve everything you need and look for another plug-in to make up for it. But including two similar plugins in the same application is definitely a bloated JavaScript. Can you find a plugin that covers all your needs? If not, can you extend one of these plugins to cover everything you need? Likewise, when deciding whether to extend a plugin, weigh the benefits versus development time.
For example, jQuery’s lightbox is a great way to display pop-up photos in a gallery, and simpleModal is a great way to display modal information to the user. But why does your website use both methods? You can easily extend one to cover both needs. Better yet, find a plugin that covers it all, such as Colorbox.
3.Need JavaScript?
In some cases, JavaScript is not necessary. CSS pseudo-selectors, such as hover and CSS3 transitios functions, can cover a variety of dynamic effects, far faster than JavaScript solutions. In addition, many plug-ins only provide styles; I feel that using markup and CSS may be better.
If you need to display dynamic content and require conditional prompts, jQuery Tooltip is essential. However, if you only need hints in a few places, it's better to use pure CSS (see this example). For static prompts, you can go one step further and animate them using CSS3 transitions, but don't forget that the animation will only work in certain browsers.
When reviewing any plugin, a series of warning signs indicate that the plugin is of poor quality. Here, we'll look at every aspect of plugins, from JavaScript to CSS to mark-up. We'll even consider how to distribute plugins. Any warnings present in a plugin will exclude your plugin from consideration. If you're lucky enough to have multiple plugins to choose from, these caveats can help narrow down your choices. However, even if there is only one option, it is better to give up if you see too many warnings. You can reduce your headaches in advance.
4. Strange option or parameter syntax
When using jQuery, development engineers are concerned about how the function accepts parameters. If a plugin developer uses special syntax, it's reasonable to believe that they don't have much jQuery or JavaScript programming experience.
Some plugins accept a jQuery object as a parameter, but do not allow chaining of the object, for example, $.myPlugin( $('a') ); instead of $('a').myPlugin(); This is a big warning.
Code:
$('.my-selector').myPlugin({
opt1 : 75,
opt2 : 'asdf'
});
$('.my-selector').myPlugin({
opt1 : 75,
opt2 : 'asdf'
});
$.myPlugin({
opt1 : 75,
opt2 : 'asdf'
}, $('.my-selector'));
$.myPlugin({
opt1 : 75,
opt2 : 'asdf'
}, $('.my-selector'));
5. Little or no documentation
Without documentation, it is very difficult to use a plug-in, because this is the first place you think of when looking for answers to questions. Files come in various formats, and proper documentation is best, but good code comments can be just as good. If there is no documentation, or it's just a simple example to blog about, then you may want to consider other options. Good documentation shows that the author of the plugin cares about users like you. It also shows that they have researched other plugins and know the value of good documentation.
6. Poor support record
Lack of support means it will be difficult to get help when problems are discovered. What’s even more concerning is that it indicates that the plugin hasn’t been updated in a while. One benefit of open source software is that it attracts a lot of attention and helps you debug and improve it. If the author does not talk about these people, the plugin will not be updated.
When was the last time the plugin you were considering was updated? When was the last time you answered a message? Although not all plug-ins need to have a strong support system like the jQuery plug-ins website. Be wary of plugins that are never updated.
Having historical technical support records and the author responding to bugs or strengthening requirements is a green sign. Having a support forum further indicates that the plugin is well supported, if not the author at least there is a forum to help you resolve issues.
7. No compressed version
Although a fairly minor warning, if the creator of the plugin doesn't provide a minified version from the source code, then they probably aren't paying much attention to performance. Of course, you can do the compression yourself, but this warning isn't a waste of time: it's a hint that the plugin may contain more serious performance issues.
On the other hand, offering compressed, packed and gzipped versions for download is a sign.
8. Need a strange Mark-up
If a plug-in requires mark-up, then the mark-up should be of high quality. It should conform to the semantic sense and be flexible enough. In addition to poor front-end technology, strange mark-ups can also make integration more difficult. A good plug-in can cover almost any mark-up you use; using a bad plug-in is like jumping through hoops.
In some cases, strict mark-up is necessary, so its use should be allowed within a certain range. Basically, the more specific functionality, the more specific mark-up needs. Fully flexible mark-up is the easiest to integrate from any natural drop-in jQuery option.
9. Overuse of CSS
Many jQuery plug-ins include CSS, and the quality of css is the same as JavaScript. Too much CSS is definitely a bad sign. But what is "over" depends on the purpose of the plugin. Display-focused plugins, such as lightboxes or UI plugins, require more CSS than simple animation-driven plugins. Good CSS styles make the program easier to modify to suit your theme style.
10. No one else uses it
The number of jQuery users is huge and the most decent plugin will probably have something they wrote about it, even if it's a "50 jQuery [fill in the blank]". For example, if you make a simple Google search plug-in and you get few search results, you may want to consider other options, unless the plug-in is brand new, or you will find an engineer who specializes in writing plug-ins to modify it.
11. Use and observation
The best way to test a plugin is to simply run it on the server and see the results. First, does it break some rules? Be sure to take a look at the JavaScript code snippet. If the plugin includes a style sheet, look for layout and styling errors on each page.
In addition, how is the effect of this plug-in? If it's slow or the page loads lagging, consider another plugin.
12. Use JSPerf for performance appraisal
Take your plug-in presentation to the next level and test it with JSPerf. Benchmarking runs a set of operations multiple times and returns the average execution time. JSPerf provides an easy way to test how fast a plugin runs. This is an important way to pick two almost identical plugins.
13. Cross-browser testing
If a plugin has a lot of CSS, be sure to test the styles in all browsers you want to support. Remember that CSS can come from both external stylesheets and internal JavaScript.
Even if the plugin doesn’t have any CSS, check for JavaScript errors on all browsers anyway (at least on the earliest version of IE you support). The core of jQuery already handles most cross-browser issues, but plugins tend to use some amount of pure JavaScript, which tends to break the rules of older browsers.
14. Unit testing
Finally, consider further cross-browser testing – unit testing. Unit testing is a simple way to test component plugins, supporting any browser or platform. If the plugin author has included unit tests in the download package, you can bet that the plugin will work across all cross-browsers and platforms. Unfortunately, very few plug-ins include unit test data, but that doesn't mean you can't use the QUnit plug-in to perform your own unit tests.
With minimal settings, test whether the plugin’s methods return the expected results. As long as one test fails, don't waste your time on this plugin. In most cases, performing unit tests is a bit of a waste of time, but QUnit can help you determine the quality of your plugin.
Conclusion
When evaluating the quality of a jQuery plug-in, first evaluate the code quality. Is JavaScript optimized and error-free? Has the CSS been adjusted and valid? Is the naming of mark-up semantic and flexible enough? These questions all boil down to the most important question: Is this plugin easy to use?
The core of jQuery is optimized and error-checked, supported not only by core team members, but also by the entire jQuery community. While it's unfair to hold jQuery plugins to the same standards, there should at least be some of the same review standards.
![[Web front-end] Node.js quick start](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
