I never understood why certain books who are covering a framework or a very particular aspect of programming must start with what is basically a short tutorial about the programming language they are using. Maybe it's just me but I always assumed that someone who buys a book about JQuery already knows Javascript and if he doesn't a short tutorial just isn't enough. Take a look for example at [Hacking - The Art of Exploitation](http://nostarch.com/hacking2.htm), a great book that deals with stuff like buffer overflows, network sniffing and shell code injection but starts with a tutorial about C...
Maybe it's just me but I always assumed that someone who
buys a book about JQuery already knows Javascript and if he
doesn't a short tutorial just isn't enough.
There were many to come to Ruby by trying Ruby on Rails first, and I think there are many to discover Javascript by having to accomplish something with jQuery. Of course that's not the ideal way to learn things, but your assumption is often wrong.
Do you really think these people properly learned Ruby by reading a Rails-specific book with a 10-page overview of Ruby?
There's some good business in picking up Rails projects when a client discovers they've hired someone who really only knows how to wire up pre-coded plugins to auto-generated MVC code, and cannot custom-code special requirements.
I refused to learn JavaScript until JQuery came along. Why would I want to waste my time on some unevenly supported scripting language that (pre-AJAX) was mostly used for silly animations or client-side form validation? JQuery has since made learning JavaScript enjoyable.
I learned javascript and jquery at the same time, and it turned out to be a lot more efficient for my purposes rather than learning pure javascript first. So for newbies I think there is benefit in including the general language tutorial first
Ditto, I learned javascript via jquery and didn't understand the difference until I decided to put a few weeks aside to go through the spec with ES4 in hand. Highly recommended.
The question here is, it is a tutorial on C or programming? If it is a tutorial in C I can see the point in it. I, for example, now what a buffer overflow is, but don't really know C. So if I want to read that book and understand the code samples, a short tutorial would help a lot.
I've never touched JQuery. I learned Javascript, and by the time I was comfortable enough with that I didn't really want to have to be bothered with an unfamiliar syntax. If I've ever needed to accomplish something repetitively, I've written my own little (and probably very badly-optimised) JS library - that's definitely helped me understand more about JS than using JQuery ever would.
Counterpoint: I understand Javascript and the DOM all too well, and coding my own "poorly-optimized" library for things that could be handled in one line of jQuery strikes me as a huge waste of time.
OK, I won't be self-deprecating on HN in the future then... it's not poorly optimised. The point I was trying to make is that I learned far more about how Javascript works by learning the language first and thoroughly than I ever would have by learning how to use JQuery. My particular area of work means that cross-browser compatibility isn't a problem - hence writing my own library that might not be compatible with older browsers is not an issue, and it is also better for my own edification.
Upvoted. I hope I didn't come across as blasting you. I agree that hand-coding your own Javascript is the best way to learn, and a front-end developer should know pure Javascript as well as jQuery. That said, for real-world applications, a stable third-party library is a better idea.
Suppose you want your website to behave consistently in the latest three versions of the four most popular browsers. You have two choices: 1) try to do it yourself, 2) use a Javascript library.
Option 1 has the following drawbacks: a) you'll need to set up an environment in which to test 12 different browsers, b) you'll need a few years to learn the nuances, annoyances, and bugs in 12 different examples of badly written software.
Option 2 has the following drawbacks: a) you'll need to know where to find the library documentation, b) you'll need a few days to learn how to use the library.
The likely outcome of option 1 is that you will eventually get your site to behave consistently in the two or three browsers you have tested. The likely outcome of option 2 is that you will spend your time working on interesting things.
Given that you know nothing about where I work or the nature of my work, that's a strange assumption to make. Not everyone is writing public-facing web apps designed for IE5 and up.
Ok fine, so you write inward-facing web apps designed for Chromium 7 and below. Still I feel sorry for the the poor chap having to maintain your library which, you mentioned before, served mostly so that you could learn Javascript better rather than what should've been a driving factor when making the decision - the business case.
I maintain the library! I work for such a small organisation, and this library is deployed on such a tiny web app, that the fact it wasn't built using JQuery or whatever is utterly inconsequential.
You might be better off in the long run. I have this nagging feeling that JQuery was a light-hearted joke about deprecating loops and local variables that just got out of hand.
