I may have turned into a little wimp, but this actually made me a little misty eyed.
Sometimes when I'm working with React or Ember on a large project, and have to do quite a bit of work for a small feature, I fondly remember the days of just banging out a two-liner with JQuery that would do the same thing.
You know what I really liked about it? It was an "inverse" angry developer opinion. Rather than the overly negative "this thing sucks and everyone should stop using it" it was positive and upbeat.
I do think that data bindings in angular or the methods of working with mithriljs or react bring a lot to the table that you don't get from using jQuery, but I do respect what jquery gave us.
Well, while frameworks require a bit of boilerplate, it makes large projects MUCH more maintainable. Back in the bad old days, yes, you could bang out a bunch of features very quickly in JQuery, but as the size of the site increased there were lots of opportunities for disparate sections of code to interfere with each other. Additionally, there are serious performance concerns using jquery for any significant number of DOM mutations, which most of the major frameworks solve. Finally, you can't just arbitrarily mutate the DOM in these frameworks, so you can't use jquery willy-nilly if you're using them.
Some frameworks reduce boilerplate by implementing features for you in their way so that tiny trivial tweaks require reverse engineering the framework and maintaining your own fork of the framework. Hopefully generators that scaffold boilerplate instead of hiding features in the framework stay to pick up more.
Some of us still do. The whole world has not moved on to client side frameworks contrary to popular opinion on HN.
(I probably actually will move on at some point... when the dust settles and there are clearer options. And when I can go through some tutorials and have stuff all work. And when there isn't a huge huge library I don't need to to a few little things. In the meantime I proudly like jQuery and it works really well for the amount of JavaScript I need. Which amount incidentally is never on a server.).
With some frameworks, you must adhere to the rule:
"Doing it the [insert framework here] way"
Most frameworks try to change your beliefs about how and why you should do things, and they are differentiated by how different/better they are from then going through the "pain" (in their words) of using jQuery.
Personally I like the way Vue.js approaches things, it's like a nice mix of syntax readability and singe state/unidirectional data flow.
Nice meditation on one of the defining frameworks of the modern web. I don't see robust front-end frameworks like React as ever really making jQuery redundant – for the non-app, document-paradigm web, these solutions make for over-engineering, while pure JS still leaves (ever fewer, granted) gaps. For certain purposes, jQuery will remain the best fit for some time to come.
Heh. I still use jQuery for pretty much every project.
There is a server-side port of jQuery which is absolutely fantastic: https://github.com/cheeriojs/cheerio This allows you to render jQuery based views on the server or client with the same code.
All the latest JavaScript view libraries are a huge pain to work with. Sharp learning curves, punishing APIs, and extremely unexpected performance issues. jQuery just works.
I'm 34, been developing web stuff for over 10 years now, and started using JQuery back when John Resig was still personally meeting & greeting people who were using JQuery at meetups.
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.
I think even people that are older sometimes forget how terrible it was to develop with JavaScript before things like Prototype and jQuery came on the scene. Just moving from alert() to console.log() was a revelation.
I'd just like to go back and show 15-year-ago me Firebug or Chrome/Firefox's DevTools and inspector. It's pretty stunning how far the tooling has come and what you can do with it.
Heh, nearly that far back I was wishing I could install Venkman in IE.
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.
Man, it was 2006 (10 years ago!) when Firebug, Drosera [1] and Web Inspector [2] were all released. There were definitely a lot of people eager to have some tools to make front end web dev easier back then.
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.
Well, I'm 40 and prefer using front end frameworks (angular, mithril, react) to jQuery nowadays. Additionally, there are times when I find (for little things) native javascript is quicker and more useful.
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).
Two important things about JavaScript that enables easy "asynchronous programming" are:
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.
I absolutely agree with you about the importance of first-class functions and closures for async programming.
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.
As often as I program in JavaScript myself, and warn other people about the "this" binding problem (it's really hard to explain to newbies, but important), I get nailed by it all the time myself. I just can't seem to remember to go out of my way every time and use "var self = this;" or call bind, and it's quite easy to miss it when visually inspecting code. It's the first thing I look for when things goes inexplicably wrong. The second thing is variables changing out from under closures in loops.
I am looking forward to the time that most major browsers support => and let.
Ahh.... lovely, thank you. So what I'm referring to as "asynchronous javascript" is technically a colloquialism used to describe the event-driven callback-y nature of the code.
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")
Notice how the lines of code complete out of order. I think it's really useful to think of that as asynchronous code. It appears I'm using async as a term interchangeably with non-blocking... which may not be correct. So it may be the case that my nomenclature is off, but I'm sure I got that from somewhere. Perhaps a lot of people were referring to node as async in the early days, I'm re-watching this: https://www.youtube.com/watch?v=ztspvPYybIY now, but it doesn't look like Ryan Dahl uses the term async.
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.
I am 22, and I have used jQuery. I loved jQuery, and it was a fascinating library that solved a lot of problems. It is still a great library, if one needs to support legacy browsers.I also think that jQuery influenced the DOM API to some extent; good things were adopted, bad ones were improved.
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'm 24, but I grew up supporting IE6 and remember trying to get cross compatibility working for the mess that we called 'browsers' back then. It's been great to see the evolution of Javascript over the last 10 or so years, it's fairly obvious how many of the new features we take for granted came from jQuery originally.
I do avoid jQuery now though, I can't remember the last time I used it.
If you were writing JavaScript 8 years ago, a library like jQuery was pretty much essential to help patch over the enormous numbers of browser bugs and differences between the various IEs, Firefox, Safari and Opera.
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).
I've had exactly this type of conversation with a young junior dev. "AJAX requests are easy - just use the Forms API." They have no idea that in 2005 I read a whole book on 'how to make an AJAX request'.
A lot of what is now called Native comes from Javascript — every time we use `querySelector(All)`, for instance, it’s because of jQuery’s influence. Which makes me a bit less nostalgic than this author: every time I use qsa I think “Thanks, jQuery”, but I don’t need to use jQuery itself anymore…
I've always had a dissatisfied opinion about jQuery, I much preferred Mootools. When coffeescript turned up, it seemed to hop on the back of jQuery. Doing a lot of the things Mootools already did and leaving gaps where jQuery was king.
Now I use typescript and no libraries at all. It isn't too difficult to write a utility object that can handle whatever depreciations or abstractions are fluctuating.
If you are writing a library of any kind and expect your clients to install jQuery for the benefit I'd say you've added too much bloat.
I wish he would have said why he doesn't need it any more. Heck, I just paid $30 to code school last summer to take the jquery courses and now I use the heck out of it on everything...
The big front-end JavaScript frameworks like React and Angular are architected in a way that no longer require jQuery for DOM querying or manipulation.
They also smooth out browser quirks which is less of an issue now with Modern browsers than it was at the dawn of jQuery which was another USP it had that propelled it to popularity.
Well I figured that. I was more interested in how he moved away from jquery. I've looked into Angular many times over the years. But sadly, I find more people complaining about it than praising it. Looking into React now.
Wow, great! Don't stop learning. There are a whole bunch of cool js tools that people have mentioned here, take a look at some of them!
But the biggest thing that I have learnt over the last few weeks was "browserify" it's really useful for all sorts of things. Take a look at 'npm' and how it installs all sorts of gubbins for you. You may never use it, but for things like coffee script, sass (I assume you know about bootstrap css?) npm will install them for you. browserify will transpile them for you.
John Resig is one of the kindest, gentlest, most wonderful people I've ever met. I think this is heavily reflected in jQuery itself. Thanks for everything JR and jQ! <3
Wonderful letter. I agree wholeheartedly. I learned web development 15 years ago and I stopped for a long time. When I came back about 3 years ago, jQuery for me was such a beautiful and pleasant reintroduction. I kept thinking to myself "I can't believe this! You mean I don't have to use those insanely long and unintuitive native js Dom calls anymore?!"
I'll just offer another perspective. for me jQuery was a major stumbling block to me learning JavaScript. And without JavaScript, you can't write very much jQuery either.
I'm young enough that there's a generation of jQuery-loving developers above me, and the whole generation younger than me is enamoured with the newer frameworks. But for me it wasn't until I stopped looking at jQuery and focused on proper JavaScript that any of it made sense to me.
The thing I find remarkable the more I learn Js is that the 'level' of the language seems perfect for the problems you're working with. jQuery makes things abstract and high-level enough you'll never figure it out - and any lower level and JS would be a lot harder to learn. The more I get into it the more perfectly suited to the task it seems to be.
Here's an alternate POV. jQuery is fading from the spotlight not just because there are better ways of handling the DOM, but because the mindshare and code ecosystem that grew up around it got completely blindsided by modern module-loading/packaging systems. The same is true of Angular I think but to a much lesser degree.
Longevity and robustness of jQuery is hard to match. 10+ years for a software project is amazing. Hopefully, in next few years pure ES6 (and later ES7) will give us that joy that's been missing.
jQuery was invaluable 5+ years ago, but luckily it's not needed for most modern web projects, unless you need to support old IE browsers. Even then, it's worth seeing how many calls you really need to make that are not supported across your target browsers.
> but luckily it's not needed for most modern web projects, unless you need to support old IE browsers.
I disagree. While I am building our actual app in Angular, our landing page and that still uses jQuery for things such as ajax requests. There's no need to pull in any major framework like Angular for such tasks.
I would say the landing page is exactly the case where jQuery is not needed anymore. Yes, it's convenient to use, yet for a mostly static page with a few XHR calls, some DOM interactions and whatnot - it's a bloat, actually. 12-16 months ago it would be a sabotage in most cases, but once it's all OK to forget about IE8 - you really can put the good ol' DOM-AJAX-animation JS libraries to rest.
From personal experience: just few days ago I've made a landing page. Focus was on mobile and performance so no jQuery, modernizr, lo-dash, and so on. We only grabbed some syntatic sugar from microjs.com so we could write $(el).remove() instead of el.parentNode.removeChild(el);, etc.
Turned out a nice, little page with all the usual bells and whistles only really needs a 12KB of JavaScript code (uncompressed). We actually missed lo-dash more than jQuery.
In age of "modern browsers'" ubiquity, and Angular/React/Ember/MV* libraries doing the heavier stuff, the support for older IEs is really the last selling point of jQuery. And that goes away soon.
Unless you're using the unversioned ("latest") jQuery version on your CDN, the browser cache hit rate will be way less than 95%. I've seen some estimates at less than 20% (can't find the link at the moment).
And for various reasons, it's not a terribly good reason to use the "latest" jQuery version with no version, unless you're prepared to deal with sudden code breakage.
> then there's a 95% your users already have it cached.
In reality, there's a less than 5% chance that your users will have the right version cached, but a 95% chance that your users will notice when the public CDN is over capacity.
React isn't really a framework like Angular or Ember. Remember that it's view only - it doesn't handle ajax calls, routing, error handling, async code, etc.
I'd argue you are pulling in a large library that has much more functionality and bloat than you actually need. For ajax, I'd prefer something like axios which uses es6 niceties like Promises and is much more targeted in its usage.
jQuery was originally a bridge for the gaps between browsers for lots of basic functionality. These days, all modern browsers give you a decent starting point with plain js, meaning there's not a whole lot of things that you really need jQuery for. Secondly, you mention that you are using angular, which already provides its own $http and $resource libraries for ajax... which I think shows even further that you don't actually need jQuery.
You load all of jQuery for just Ajax? I'd just use `fetch` or one of the many small Ajax utilities plus `querySelectorAll`—though I'll admit I don't know their browser support status.
No I use it for more than that, the landing page is built on Bootstrap, so I have modals and other fun stuff that Bootstrap + jQuery bring to the table.
I completely disagree. Need to write a bit of javascript for a page, or a small app? I'm never gonna go the angular or the react route. I'm just gonna do that in 5 minutes using jQuery.
You misunderstand. I'm definitely not suggesting using Angular or React for a page or small app. Quite the opposite. I'm suggesting using just Javascript, with no libraries.
As other posters have written here, you can easily now do just about everything on "Vanilla JS" as you can using jQuery. In my experience, the possible exception to this are animations which require significant boilerplate. However, most common animations are now extremely trivial to accomplish using CSS.
I haven't used jQuery for new project in 2 years, unless I have to support less than IE9 (and even then, I make sure I really need it first).
> you can easily now do just about everything on "Vanilla JS" as you can using jQuery.
jQuery is vanilla JavaScript. As a full stack JavaScript developer, it pains me that people think that something written in JavaScript isn't vanilla JavaScript. It is.
* A lot of plugins/libraries require jQuery, so by using jQuery you can use those plugins.
* It's easier to hire junior devs that can write good enough jQuery, compared to native JavaScript.
* As a very mature library, there's lots of documentation out there for standardising the way you do things. This makes it easier for other devs to pick up your work.
> A lot of plugins/libraries require jQuery, so by using jQuery you can use those plugins.
I'm seeing more and more mature "Vanilla JS" libraries for common tasks I used to use jQuery plugins for. But yes, if you must have some plugin, then you have to use jQuery. In that case, it's probably not worth the time to re-write the plugin in Vanilla js unless you have some specific bandwidth constraints among your users.
> It's easier to hire junior devs that can write good enough jQuery, compared to native JavaScript.
Sadly, you're probably right about this. I'm a little uncomfortable with the term "native" JavaScript since that makes some devs think it's some kind of OS hacker-level of difficulty, when in fact, most jQuery equivalents in modern JS are quite similar to...jQuery.
> As a very mature library, there's lots of documentation out there for standardising the way you do things. This makes it easier for other devs to pick up your work.
Sure, I can see this being true. I guess if you have to hire and train a bunch of relatively middle-of-the road junior developers, jQuery is a good choice at the moment. But even if I were in your position, I'd still try to push them to get used to writing in vanilla JS. This is good not only for your project, but also for them, since more and more employers, even mediocre employers, will start expecting potential frontend dev employees to be able to write vanilla JS.
Sometimes when I'm working with React or Ember on a large project, and have to do quite a bit of work for a small feature, I fondly remember the days of just banging out a two-liner with JQuery that would do the same thing.