No, it doesn't make sense.
jQuery is a bloated library. Everybody knows that. And everybody uses it because it's one the rare cross-browser libraries out there that just work (note that I didn't say framework).
If you don't need support for legacy browsers, you don't need jQuery.
Small needs such as QSA shortcut or an XHR helper are thin. They are easily added through such objects.
Then, if you like its API, go for it. But it's not needed.
I can understand that some people prefer:
$( '.table' ).addClass( 'active' );
To (using By):
[].forEach.call( By.qsa( '.table' ), function( table ) {
table.classList.add( 'active' );
} );
I find the second way more explicit, other will disagree. It's a matter of preference.
Also, if your code has any chance of being ported to legacy browsers later (or other non-webkit/sucky mobile browsers), use jQuery. It will reduce your headache later.
Related: https://softwareengineering.stackexchange.com/a/148536/42132
First off - it's impossible to use jQuery only, all jQuery does is add a $ object to your global scope, with a bunch of methods in it. Even more manipulative libraries like prototype aren't an alternative to javascript, they're a toolbelt to solve common problems.
The main advantages to adding jQuery to your toolbelt would be:
- browser compatibility - doing something like .attr() is much easier than the native alternatives, and won't break across browsers.
- simplification of usually complicated operations - if you'd like to see a well written cross browser compatible version of an XHR method, take a look at the source for $.ajax - for this method alone it's almost worth the overhead of jQ.
- DOM selection - simple things like binding events & selecting DOM elements can be complicated and differ per-browser. Without a lot of knowledge, they can also be easily written poorly and slow down your page.
- Access to future features - things like .indexOf and .bind are native javascript, but not yet supported by many browsers. However, using the jQuery versions of these methods will allow you to support them cross browser.
Javascript is no longer just a client side language, and because jQuery is so DOM dependent, it is a terrible candidate to move to the server. I highly recommend putting some time into understanding why you are using jQuery (asking this question is a great first step!), and evaluating when it is necessary. jQuery can be dangerous, a few of the main dangers are:
- code quality - jQuery has a huge community and a low learning curve. This is a perfect storm for lots of poorly written open source plugins.
- inefficiency - jQuery is easy to write inefficiently. For instance, using jQuery's each instead of for loops is unnecessary and could have a performance impact in some cases. Lots of good info about this stuff at JSPerf
- bloat - jQuery is a huge library. Much of the time, you'll use a small subset of it's features, and grab the whole library. There are some great alternatives that will give you subsets of the features, like zepto.js, and underscore.js - depending on your situation, you can save some bytes by choosing the right library for your needs.
Ultimately, jQuery is an incredibly useful and helpful library, when used properly. However, it is not an alternative to javascript. It is a library, just like zepto.js, YUI, Dojo, MooTools, and Prototype - one of which may be a much better choice for your current project.
Javascript is a misunderstood language, and is only recently being regarded as something more than a scripting language by most people. I really recommend reading up on it more, here's a few good places to start:
Edit 07/2014 - I noticed this post is still getting attention, so I added a bunch of links. These are in no particular order, but should be helpful.
- Ben Alman's blog - lots of good best practices here. I don't agree with all of them, but I learn new things from his blog all the time.
- Code Academy - basic javascript and jQuery training. Sometimes going back to basics helps.
- Javascript Garden - a post regarding the more tricky or misunderstood features of javascript. Please read this from time to time, until everything makes sense.
- Bocoup - these are training classes. If you're near one, go to it. Many of the best JS speakers and teachers teach these.
- Paul Irish's blog - not strictly JS, but plenty of best practices are written about here. Him and Ben's twitter feeds are both great to follow.
- Javascript: The Good Parts - often referred to as 'The Javascript Bible', this book by Douglas Crockford is an amazing place to start understanding javascript.
- Isaac Schlueter's Blog - Isaac is the creator of npm, and works on the node core. He writes a lot about the javascript community rather than about code conventions, but if you're really getting in to js it's a great read.
- Douglas Crockford's Javascript - If Brendan Eich is the father of javascript, Douglas is javascript's outspoken uncle. He is the author of the JSON spec, the javascript bible, and lots of amazing posts on javascript's quirks and meteoric rise.
- Brendan Eich's Blog - Brendan is the creator of javascript - he writes about all sorts of silly stuff on his blog, and while he has his faults as a person, his javascript posts are valuable.
- James Halliday's (@substack) Blog - Substack is arguably the most important node.js developer in the community - with around 400 (and growing every day) npm modules and a guiding philosophy of tiny, unix-like modules, everything he writes is worth reading.
- Max Ogden's Blog Max Ogden is another prolific node.js author, and is excellent at writing blog posts that teach you something. He's also the author (with others I believe) of javascript for cats.
- Javascript for Cats - This is a short tutorial that takes you through the basics of javascript from the perspective of a cat. If you're a beginner, read through this. It's fun, and teaches in an hour what many books take weeks to communicate.
- Nicholas Zakas' Blog Nicholas is the author of a few fantastic javascript books: Object Oriented Programming in Javascript, Maintainable Javascript, Professional Javascript for Web Developers, and High Performance Javascript. He focuses mainly on the client, but has a ton of best practices and performance tips.
- Guillermo Rauch's Blog - Guillermo is another prolific node.js dev, mostly famous for Socket.io and Mongoose. His blog (and his new book, Smashing Node.js are both great resources.
I'm sure there's lots more great resources I'm not thinking of or don't know about, other answerers should feel free to add to that list.
Best Answer
A high-level dissection of the code posted:
Html-element to embed a script in it
$ is the jQuery alias for getting the jQuery object which wraps almost all of the stuff jQuery can do. In this case we simply invoke the jQuery object with syntax similar to that of a constructor. This is shorthand for "pass in a css-selector and return all matched DOM elements wrapped as jQuery elements". So we select the element in the DOM with id=circle
This is (one of many) jQuery-ways to say when the element(s) - the previous selector could have returned a ton of elements - is clicked run the function passed into me. This function is called a callback-function. Basically subscribing to the onclick event of the DOM element.
.. the callback passed in...
Similar to the $("#circle")-statement. Select all paragraph-elements in the DOM as jQuery elements. (
<p></p>
)For all p-elements previously selected set the inner html of this elements to be "You clicked the circle". Note; You should almost never want to do this for security reasons - use .text() instead.
.. close the call back ..
.. Honorably mention; You forgot to close the click()-function :) The code as-is will still work though, since javascript is forgiving (For better or for worse, that's another story)
.. closing the script-tag..
As it has been stated, this is a really broad question even though it does not look like it. For all the above paragraphs you could probably write a page of what it really does under the hood, but that's the gist of it.
For your question "Does jQuery convert the resulting code to JavaScript?". Not really. jQuery is implemented in javascript, so you can simply think of it as a wrapper library. jQuery serves two main purposes: 1) Providing an API that works regardless of browser types. So for example, if Safari has some quirks working with the onclick-event but firefox follows the spec, jQuery will take care of this under the hood for you (Not the the Safari/Firefox example is purely made up, none of those should have quirks). And 2) provide QoL-improvements such as CSS-selectors, although those have since been implemented in ES5 or ES6, can't remember which. When jQuery came out you had to call document.getElementById() or a similar DOM-method to select elements.
At the risk of starting a religious war, jQuery has nowadays largely served its purpose. Most of the stuff that made jQuery popular is now implemented in recent ECMAScript-versions and most browsers are now updated to at least include the basic stuff. Personally, I only use it because it's a familiar API, as I used to work extensively with it, but it's not "as required" to use it as it once was.
Hope it helps :)