It depends on what you mean by "real developer". If you are a PHP guy who just needs some plugins on his page, you're good not knowing what's in the black box. If you plan to put JavaScript on your resume, not knowing how jQuery works under the hood is not going to cut it.

Look at it in reverse. I decide not to learn C#, even though I have an idea of how they work. Do I need to know how to query a database? No, I can leave that to someone else and concentrate on JavaScript and call those ASPX APIs. But I don't plan to put C# on my resume.

I think it is a matter of being pragmatic and not reinventing the wheel. If you don't need anything different than the tools you are using provide, I think it is ok to just use the tools. If you want to learn how things are done under the hood and you have the source code you can always have a look. If you want to learn to do it from scratch and you have the time, it is ok to take the time to think how you would implement it and work on your approach. If you need something more than what the tool (library, framework) provides, you can either extend it (if you have the source code) or go for something completely different (Monthy Python pun not intended). Anyway... real developers use Vi.

Yes, you should, a lot of times when debugging you will have to dig deep into libraries/frameworks you're using, to resolve some problems, and internal knowledge of how things work will help you.

Definitely. Not to the extent that you've basically in your mind got every piece of jQuery mapped out, but you should at least build the ability to jump into the source code and see what is going on, and know the base concepts. For the same reason it is advocated to learn C but develop in something higher level - you need to know what pointers and memory management are to adequately grasp why the things you are developing are reacting in certain ways. I generally crack open the source code whether or not I'm having troubles, I think seeing and dealing with other people's code is one of the most beneficial (and humbling) habits a developer can have.

Jquery's ease of use comes from the combination of two anti-patterns:

http://en.wikipedia.org/wiki/Inner-platform_effect

http://en.wikipedia.org/wiki/God_object

Jquery has essentially abstracted the API's of web browsers so much that they've created a complete duplication of them inside a god object. Generally "real developers" try to identify and avoid the use of anti-patterns in their software.

Your comment is purely academic at its best and pretentious at its worst.

There is a good real life problem for jQuery style and your so called anti patterns are in fact the main feature and sole point of existence for jQuery.

Once could argue that jQuery God object replaces not one half assed implementation of DOM God object, but at least four (IE DOM, FF DOM, WebKit DOM, Opera DOM).

I agree that in a fair world jQuery wouldn't even exist. Any problems that it brings to the table I will gladly solve, sice my brain has a lot of better stuff to do than to memorize all the bugs and quirks of all the stupid browser engines out there.

So while you real developer bunch smugly program your assembly, I will gladly carry the flag of an untermensch programmer and just ship the goddamn product. I know my co-workers and clients like me for not coming up with a new framework for every job I do.

The OP asked, from an academic standpoint, whether jQuery should be used. My answer is no, and I gave the reasons. To extrapolate further, JQuery is for "developers" who don't know what a subroutine is. Designers love it because they can cut and paste unrelated snippets of code without worrying about architecture. People who overuse JQuery generally avoid any type of architecture in whatever they're building. And although it's possible to ship a product with half-understood jQuery snippets it does not necessarily make that person a real developer.