I'm pretty firmly in the "You don't need JQuery camp", and the reason is that you don't need JQuery now. It was an amazing piece of software when it came out; it made rich JS development not only practical, but easy, without worrying about cross-browser issues. But it succeeded. Resig's goal - from very early on, at least as soon as he started to working at Mozilla - was to get JQuery baked into browsers, and he's largely done that. We got querySelectorAll. We got a unified event model that all browsers support. We got FormData. We got a consistent box model, and consistent getComputedStyle() behavior. We got animations and transitions, and the native versions even run on the GPU for fast mobile performance.
As a result, most of the problems that JQuery solved just aren't problems in modern web development. Cross-browser issues are minor and getting smaller every day. Selectors are baked in. Animations and transitions are CSS one-liners, rather than needing to spin up a setTimeout loop and manually calculate the delta in the property each tick.
That doesn't deny the historical significance of JQuery, or just how much it improved web development back in 2007. But we build apps for the world we live in today, and today, JQuery gives you some minor programming convenience in exchange for 30K of download size and a bunch of layout thrashing if you use its CSS or dimensions methods.
Forgetting to say "thank you" to people who helped us a lot is something that happens more than often in IT.
I still remember when I heard of jQuery. It was in 2007 and it was so amazing.
Yes, I admit, the 'alert()/console.log()' was amazing :)
JQuery and Firebug deserve a lot of credit for bringing some sanity to JS/web development. Sure things have moved on now, but they were ground breaking.
I never worked with Venkman but I recall all too well the hellish time I had debugging JS back around the turn of the millennium. IE was laughable, if there was an error in a script somewhere it would often just say error on line -1.
[1] https://webkit.org/blog/61/introducing-drosera/ [2] https://webkit.org/blog/41/introducing-the-web-inspector/
I think the sea change for me was not using front end frameworks, but when I first started trying to play with nodejs.
As soon as I started working with that AND started coming to understand the async nature of javascript, my entire world shifted underneath me.
In hindsight, I'm amazed that I managed to remain employed for so long while NOT knowing that javascript was async. Oh well. Such is life.
Anyways, I've definitely said "you don't need jQuery" on numerous occasions. There are plenty of places where it is the best and cheapest solution, but other times when it isn't (or isn't available).
1) First order functions that you can pass around.
2) The fact that those functions can be closures over the local scope, so it's easy to pick up from where you left off.
Two big mistakes in the design of JavaScript that work against easy "asynchronous programming" are:
1) That "this" is not lexically bound in the local scope (technically it's a magic "keyword" that's dynamically bound by the interpreter), even though in most cases capturing "this" lexically is what you really mean to do.
To mitigate that problem, you have to do silly stuff like "var self = this;" to copy dynamically scoped "this" into lexically scoped "self".
2) Each { block } doesn't have its own variable scope, so variables you bind inside loops that repeatedly create closures (like callbacks for a list of menu items) have their value changed out from under them to the last loop iteration when those closures are called later on.
To mitigate that problem you have to wrap another function(){ ... }(); around the loop body to capture the values for each loop individually.
Both problems cause subtle hard to find bugs, even when you know about them and are expecting them and programming defensively to avoid them. And both problems were bad naive design decisions that many other languages had previously gotten right.
But modern bleeding edge JavaScript now has "=>" fat arrow functions that bind this lexically, and "let" that declares block scope variables. (But that's not supported in all browser yet.)
Yay for progress! Worse may be better, but once you've wiped out the competition and taken over the world, there's no reason to keep it worse on purpose.
However, I disagree with your number (1). First, you shouldn't have to use "var self = this;" very often, unless this is your preferred style. Many JS libraries will let you pass in the context as the final argument in a function call. And if you can't do this, you should look to `bind` and `apply`, they're very handy for handling contexts [1].
I do strongly agree with your (2). But if I'm not mistaken, the latest versions of many browsers do support block scope already. I know Chrome does, and Firefox and Edge may as well.
1. http://javascriptissexy.com/javascript-apply-call-and-bind-m...
I am looking forward to the time that most major browsers support => and let.
I'm not sure I'm still against referring to javascript as asynchronous or at least as having asynchronous methods for the purposes shorthand and quick communication.
Consider the code (or paste it into a chrome console)
function _done(){ console.log(arguments) }
var db = window.openDatabase("dbfoo", 1, "test db", 5e6)
db.transaction(function(tx){
tx.executeSql('CREATE TABLE t1(a, b PRIMARY KEY);', _done, _done)
})
console.log("i happen before the line above me")
Anyways, looks like I'll have to train myself to use the right word for it. Thanks for pointing that out without making me feel dumb or being all insulting and internet-y. :) I really appreciate that.
EDIT: Hmmm... additionally, to be fair: it appears that some agree that it is OK to refer to parts of javascript as async http://stackoverflow.com/a/16524240/398055 so it might not be perfectly accurate, but it isn't wildly inaccurate either.
However today, I don't think it's as useful—I am not saying it isn't useful—as it once was. The overhead to support multiple modern browsers is usually very low, and often it's even none.
I also believe most of the problems people point about jQuery is that at some point a lot of confident, but bad developers, started using it and somehow jQurey unjustly gained that bad reputation.
I do avoid jQuery now though, I can't remember the last time I used it.
My experience is definitely that developers under 25 are much less likely to understand the historic context that jQuery came from, and hence have less respect for what it achieved (and continues to achieve).