I would argue jquery has been more instrumental to the success of the web than javascript. It was the stroke of pragmatic genius riding the back of a half-baked language ( a prototype-based language trying to ape the style/name of Java, solely as a cheap cash in of its popularity).
AJAX and the Web 2.0 hype around 2005 are responsible for the success of the last few years. There were also YUI, prototype.js, ExtJS before anyone used JQuery. But thanks to the popularity of JQuery around 2010 we got at least two JS functions in HTML5 browsers. And the browsers got more compatible with the HTML spec. Before you had to write for IE, Firefox and Webkit with fallbacks for various bugs. Since around 2013 vanilla Javascript is enough, and JQuery popularity is declining. There are React/Angular/Ember/etc nowadays but hopefully soon ShadowDOM will be supported by most HTML5 browsers.
Just to clarify: YUI and ExtJS both came out after jQuery, jQuery came out in 2006, and jQuery is actually more popular now than it was a year ago (or in 2010 - see the figures cited in the blog post).
I still use jQuery very heavily in projects not already built on frameworks. It's way easier for me to add a new module or function to a monolith like that by writing a little jQuery than trying to overhaul the whole project to use Angular/Ember/React/Vue/Mithril/whatever.
Thank god for jQuery for this exact reason. It's been a refreshing constant in the exhausting mess that is the JS framework world, and the fact is that most software is "monolithic."
jQuery is a dependency of Ember. Angular (at least 1.x) requires either jQuery or its own subset, jqLite. Cross browser incompatibility is still a thing and jQuery remains a very good tool for abstracting the differences.
1990-95 is pre-Netscape -- that's kind of pre-history.
(I too am old enough to remember the internet before the web. You really had to work hard to goof off at work when all you had was nntp, archie and gopher.)
I did too, on SunOS. I remember the early days when renavigating to a page would just pull up the cache version and not refresh automatically -- I didn't understand why wsj.com wasn't publishing new content daily.
Dynamic Drive was how I learned Javascript back in the day! Pulling apart how the author of a script had written it, to see how to get the snowflakes drifting down my page become leaves instead ;)
Not weak, but every browser had their own non spec API functions to traverse the DOM in various ways. JQuery offered an easier cross browser API, whereas otherwise one would have to handle various bugs and different API functions.
Particularly events. I think there are technically 3 different ways to create event handlers, one for each of the major js engines of the early 2000's.
For the simplest cases, yes, but even there you could easily find oddities with things like cancellation, bubbling, timing with regards to other events, support for various element types, etc.
Here's a whole list just for click, which is probably the most standardized event handler, and doesn't even go back before the IE5.5 era:
to double down, touch events on mobile browsers are in a different order than mouse event in regards of onclicks, so that a touchend and mouseup fire at the opposite side of the click event on some mobile browser but not all.
I don't think that's accurate (or fair, really). Jquery was one in a list of dozens of libraries that did similar things at that time, but ajax/interactivity had been part of the web mindset for years before jquery existed. Jquery just won the library war.
jQuery was important not just because of the feature set, but because it completely dominated the industry. jQuery and its ecosystem of plugins created a single community for JS developers. A lot of subsequent work wouldn't have been as successful without that strong community in place to spread ideas.
The other thing it did well was change the thinking about how JavaScript should interact with the DOM. In the past you'd have libraries that made DOM access easier, but they largely followed the same conventions as the underling APIs. jQuery broke from that and completely re-envisioned the API layer. The underlying APIs were treated as an implementation detail; this approach is something that subsequent libraries have adopted too.
Yep, I'm surprised jQuery isn't older, as I do recall using dojo and prototype before 2006.
jQuery was a huge timesaver, as was dojo, mootools, prototype, etc and not having at least one of these libraries would have sucked. And although jQuery "won" it could have easily been any other javascript library.
Even if these libraries somehow didn't exist, there was tons of cross-browser snippets plastered across the web that dealt with most of the common problems (ajax, event listeners, etc).
What drew me to jQuery over Prototype in particular was the fact you could use css-style selectors to get and operate on several elements at once. This often reduced several lines of code in a loop to a couple chained methods.
Prototype first came out in Feb 2005. Dojo 0.1 was Aug 2005, and 1.0 (first stable, after a total rewrite) was Nov 2007.
I do remember using Prototype with script.aculo.us and thinking it was pretty neat to add some effects to my server-side-created web apps, but that they'd largely stay server side. The first time I saw jQuery, that was when I thought "Yeah, okay, we can actually start building some serious client-side interactions here" instead of just server-generated HTML pages.
jQuery took me from hating (but tolerating) javascript to actually enjoying client-side web development.
It won because it has a great API and excellent documentation.
jQuery is pretty much the only library or framework made 10+ years ago I can use and still feel like "this is actually well-designed". Frameworks generally obviate the need for it, but if a framework isn't an option and if I'm going to be writing more than 100 lines of code (otherwise I'd suck it up and use plain JS), I always still use jQuery.
JQuery is a brilliant library. No, really. It's designed to make DOM manipulations easy, and it does that REALLY well. I'd go so far as to say that it probably has one the the best interfaces of any library ever.
Then we have some great opportunities requiring 15+ years of JQuery experience in your area. As you're able to dress yourself these are not remote roles. =)
Slightly unrelated -- John Resig's "Secrets of the JavaScript Ninja" is such a well-written book. It allowed me to not only understand but also appreciate JavaScript. I believe understanding JavaScript as a functional language is key to being a good JS developer.
So it's been 10 years of jQuery being a preferred way of interacting with the DOM API...where are the changes to the DOM API to make the DOM easier like jQuery? Sure we got a few new things like querySelectorAll(), etc but nothing that makes things quite as elegant to create as jQuery's API.
Why wouldn't the HTML standards committees follow the trend and improve the API?
Edit: removed 'chainable' as a descriptor of jQuery's API as I didn't mean to focus on it; was simply just calling its API chainable but it's led to confusion.
Actually, I don't think the chainable API is terribly important.
The things that keep jquery alive and well in mind are:
* A convenient way to add to the DOM. While SELECTING elements has gotten way better than the Bad Old Days, ADDING elements is still painful. (one element isn't bad, but if you're trying to add, say, a UL with a number of LI elements, it's...tedious.)
* A good wrapper for Ajax calls. Not that there aren't better, but jquery has a perfectly good one. Heck, I've jqueryified a page to test calls I'm making outside of jquery because doing a call via console is...tedious.
* Promises. We'll soon have them native (and better), but for a long time jquery has been super convenient for this.
if you ask me, it's impressively well designed. it looks so boring and straight forward yet somehow nearly all "simple" http libraries (not to mention builtins) in nearly all popular languages are more convoluted.
I'm really greatfull for the new Fetch API. For now we need to use a pollyfill for it which just uses XHR underneath. Safari and modern versions of IE/Edge are lacking support.
> Actually, I don't think the chainable API is terribly important.
jQuery's API is chainable; that's all I meant by it. Their API overall just simplifies everything. I'd like to see the standards committees take ideas from development trends and work to simplify the DOM API.
Honestly as far as AJAX goes I really think HTTP needs to be put into the JavaScript standard itself; not just the HTML standards. It's hard finding good libraries that can make HTTP calls in the exact same way in both the browser and node (which is important to me because much of my library type code can run in either environment). I had to write this myself and while my implementation is limited it makes my life easier.
I've recently switched from jQuery to mustache to create elements for DOM insertion; I like that a lot, especially because it works linearly like a good old library, instead of being a huge ass framework - it's a good fit for the programming model.
IMO the important part is that the DOM API is now consistent across browsers. I don't really have any problem using document.getElementById instead of $, the issue was handling events and so on. These days, addEventListener works in every browser. New additions like classList.add/classList.remove are just bonuses.
As for the chainable syntax, I'm honestly in two minds about it. It's incredibly powerful, but some of the worst JS I've ever seen has been written in endless jQuery chain statements.
jQuery has a nice efficient event delegation mechanism, that lets you listen for events on elements that don't even exist yet, by specifying selector patterns and listening on the root element with a few global event handlers, instead of adding listeners to every leaf element as it's created. It does all the bookkeeping and event handling in one place, so it saves a lot of memory and time. So not only does it work consistently across all browsers, but it also doesn't suck!
The success of jQuery, React, Angular, etc. makes it mostly unnecessary. There is no need to avoid JavaScript wrappers to the DOM API, and lots of good reasons to have them. External libs are more flexible and fixable than web platform APIs. Very few people need to write directly to the DOM API nowadays and the ones who do don't need more abstractions or a bunch of renamings. Those things generally just complicate the code in frameworks and libraries because they create multiple code paths for years.
> External libs are more flexible and fixable than web platform APIs.
This isn't true. If you're only talking about jQuery then fine, it has a performance hit to its usage but it's not that big of a deal. But React, Angular and some of the frameworks out there? They abstract a lot more away from the DOM and can cause some serious performance issues (even if you're not careless they all incur a performance hit which can be noticeable in mobile web browsers if you're not careful).
Many have had to rewrite portions (or entire) web applications when they hit certain scale and use far more native DOM APIs than before just to get the necessary performance. Atom is one example but there are plenty more.
So no improvements to the DOM API are not unnecessary; in fact I think they are a bit necessary. You wouldn't have nearly as many people abstracting away from it if it were far more approachable and there is nothing wrong with making it easier to use.
Renaming wouldn't be a good idea (best to keep the existing API and create a DOM 2.0 API for backwards compatibility) plus it wouldn't really solve any problems anyway.
For me I'd need to do some research to create a good, comprehensive list but some of the things off the top of my head:
- Simplified ways for creating HTML elements. jQuery's way is nice and I think chainable, while a double edge sword in some cases, can make this a little nicer (doesn't have to be chainable to the extent that I can make 10 elements in one line but being able to set the properties in the creation step would be nice). In fact even allowing a simple JS Object to be used for setting properties in the creation step would be handy.
- Templating needs to be built in. Practically every single framework has its own way of templating and they all suck to a degree because you have to take the huge tradeoff of either doing the templating server-side, loading the HTML then replacing the values or loading the JS then generating the HTML. All of it is slow. A browser native solution could be orders of magnitude faster than dealing with the last two and makes it easier to leave the front end as purely static versus having some dynamically generated items.
- HTML and ECMAScript committees needs to get together and create clear separations of functionality between what the HTML and the ECMAScript standards provide. AJAX was great but this is an HTML standard; HTTP needs to be baked directly into the ECMAScript standard since JavaScript can run anywhere now. Eventing too needs to be moved from HTML standards (as far as the eventing itself is described; the events individual elements use most certainly should stay in the HTML standards) and build eventing right into ECMAScript. Right now node and the browser both provide their own event handling.
Obviously those items are far more nuanced than my real fast list but you asked me to give you answers to a hard problem :). I could make them far more detailed and nuanced with some time and research (I have other ideas but I need to investigate them more).
That's exactly my thought as well. Even if you look at some of those sites like: http://youmightnotneedjquery.com/ the main thing they highlight to me is how incredibly superior jQuery's API still is for many basic operations. It's kind of sad 10 years later the standard DOM API is so clumsy and there is no significant update in sight that I'm aware of.
I remember sitting in a tiny conference room at Monster.com during the first Boston BarCamp in 2006 and listening to this kid from RIT give a talk to maybe 15 of us about his new library called jQuery. I think I asked some dumb question about if method chaining allowed for conditionals.
Somewhat unrelated but reminds me of this: I enjoyed skimming through Resig's personally-annotated version of the first public release of jQuery (annotated April 2015 of the release in 2006 [!]).
jQuery is the BMW M3 of libraries. It handles all the hard stuff for you in such a way that when you use it, you look like a superhero capable of anything. It's one of those rare tools that makes almost everyone better at what they do just by the fact that they're using it. And everyone can find a way to use it in their own style. Just a completely brilliant piece of software that has inspired me (and many others) for a decade.
I'm still waiting to meet John in real life and thank him out loud for jQuery. One of these days.
I personally got into web development with jQuery. Some years I go it was a must, now a days, I find it unnecessary and I don't use it any more. Is this just me or is transition people is doing ??
I can think of two main areas that jQuery is useful in which have diminished in importance over the years
a) smoothed over differences between browsers. With the web being taken more seriously by everyone, the browser implementers are much more careful about all following the same standard so with every year that goes by there are fewer cross browser quirks to worry about (it's still a major pain today though)
b) providing convenience methods for manipulating the dom and working with data etc. I think jQuery has less of a role to play since ES5 and ES6 are how javascript is written nowadays and have more advanced features than js did in jquery's heyday. Also, for advanced client side apps, frameworks like angular and ember also provide such features.
I think as we've moved into "web apps" rather than web pages with some dynamic content, jQuery is being replaced by /react/ember/angular/etc. Still a great library that served it's purpose for a long time.
jQuery was popular because of the cross-browser functionality it offered, since having to read about all the different quirks was a huge time sink. Also being able to use a selector $() to grab DOM nodes was _huge_. So easy and convenient.
I think once web apps starting getting larger and larger, jQuery became more and more of a hinderance (since it offered no framework for structuring apps).
jQuery was popular because it was easily grokked by people who were more designers than developers. It had lots of competition early on, my favorite being MooTools, many of which were far better designed and had equal cross-browser support. jQuery was simply more accessible to people without a solid programming backgroud.
Had the world gone with one of the many other options back in the day, I think we might be in a better place already.
I don't see what this adds apart from sour grapes.
It would help if you told us what insight we missed about MooTools that would have made the world a better place? Why jQuery has made it such a miserable one?
I'm not trying to be sour, sorry, I'm just pointing out that jQuery didn't win due to some special superiority that it has. It is in no way better than any of the competition that it had in the early days. jQuery works, of course, but it didn't do anything special in terms of functionality or capabilities. It had everything to do with the audience it appealed to early on.
jQuery's understandability is part of its superiority over MooTools. When I was first looking for a Javascript library years ago, it was better documented than other libraries, it was more readable (particularly method names), and didn't lean towards OOP (I admit I personally hated Java).
MooTools and other libraries might possibly be more powerful if you are developing in Javascript in general, but for web development I primarily care about DOM manipulation, and it was much easier to pick up jQuery than anything else at the time. It's a mistake to think that languages should win out simply based on functionality and capabilities, without taking into account things like ease of use and learning curve.
From the perspective of a passionate user of Ember, jQuery is still relevant. The DOM API may be more consistent between browsers today than it was in 2006, but it is still needlessly verbose:
document.getElementById(id)
vs.
$('#' + id)
Let's not forget the lack of chainability in DOM element method calls:
el = document.getElementById(id)
el.method1()
el.method2()
vs.
$('#' + id).method1().method2()
Yes--to me at least--conciseness and elegance matter, now more than ever. A better DOM API does not mean the end of jQuery. In a similar vein, ES6 does not spell the end for CoffeeScript.
On the other hand, `$('#'+id)` fails when the ID contains dot or other characters that have special meaning in a CSS selector, and `$(selector)` is overloaded with `$(html)` causing common XSS injection issues in apps misusing it. jQuery's “Do What I Mean” philosophy jas introduced as many of its own bugs as it ever fixed in browsers; I wish there were a happy medium.
I'm still looking forward for programmatically generating custom jQuery builds from the download page. We Inertially include the whole build for minor things sometimes. Say I want to just use Events, Selector, or Utilities and Ajax.
True... but by pulling jQuery from Google's CDN for example, you theoretically save page-load time anyway. If multiple sites pull from the same CDN, then it's already cached in the user's browser.
I remember when it was announced - I just happened to be in the right place at the right time. It was announced in a smallish room, maybe about 25 people. At BarCamp, if I remember how it worked, everyone who showed up was required to talk about a subject. It was as community-driven an event as any I've ever been to. Lots of amateur presenters.
There was a guy there that John Resig had shown jQuery to the night before, and the guy was just raving about it. And when John showed off jQuery, it just was damn impressive.
Wish I could remember more, its a bit of a hazy memory now! :)
I do love that John's blog doesn't actually use jQuery itself (likely because it's not needed in this instance). Or any javascript for that matter, other than analytics...
There's a lot of nifty front-end JS frameworks these days, or popular front-end and back-end JS implementations, so I can see how it's easy to miss what made/makes jQuery great.
I think that it's hard to truly appreciate jQuery unless you were actually attempting to write code for web applications that dealt with a lot of JavaScript at the time. 2005 and 2006 was a nightmare for writing front-end behavior on web-based applications.
This wasn't because JS was particularly awful to write code in. Internet Explorer, the king of browsers at the time, routinely exhibited totally unexpected behavior with little to no tools to discover how to fix things. While this may sound like a personal attack against Internet Explorer, it's the truth of the matter. Other browsers had quirks, but none were as important as the quirks discovered in the most popular browser at the time.
The things that you wanted to start doing to make your app "Web 2.0" like transitions, CSS animations, AJAX behavior, big DOM manipulations, and so on, were totally possible with JS. You just had to write a lot of it and pray to whoever you wanted when you went to test it in IE.
One of the big catalysts for getting something better than vanilla JS to play with wasn't just to make writing the code more pleasurable, it was to make it easier to GSD. Two camps came out in this regard. You had folks who were abstracting away the JS a lot more, creating more of their own syntax and language for everything; a framework built in JS. Then there were folks like jQuery who were creating what a lot of people considered a library, in that it felt like you were utilizing a lot of the same vanilla JS you knew and loved, but with some wrappers and helpers.
I mean, AJAX was a big and cool "aha" moment when you first saw it and played with it. But the first time you got to do things like:
* Identify an element without verbosity like document.getElementById()
* Attach an onclick to elements reliably and in a cross-browser safe way
* Change the color, replace some text, and fade in or shake or whatever was cool at the time in a single line of code that worked everywhere
... things like these were also very, very cool.
And because jQuery was well-documented, and didn't change the language and feeling of using a lot of JavaScript too tremendously, it was, and continues to be, an invaluable tool in so many belts. There are tons of good libraries built on top of jQuery that continue to evolve with standards and trends.
Overall it's stood the test of time well, and has saved countless hours of development time; two important qualities in great software.
I strongly believe that jQuery by itself is almost always easier to use than any JS framework or combo of libraries. The fact that these frameworks often are incompatible or at least look down upon jQuery is odd and dare I say disrespectful.
I think what a lot of folks frown upon about "jQuery" (sometimes without realizing) is using the DOM as your data model. I.e. state is only stored in text, attributes, tags, etc. - and apps quickly turn to crap due to the complexities of back and forth data binding, etc. It's not really about jQuery, just that style of coding.
jQuery is great and conceptually quite simple - select an element of your page and do something to it in a line or two. It's a shame that the React/Angular stuff doesn't have that kind of simplicity. I'm not sure if that's inherent to the problems they deal with or not.
Suggestion: read his book "Pro JavaScript Techniques" (2006), it explains how JQuery works. Even if you don't use JQuery, one can find several good code snips and advises.
JQuery got created about 10 months before I started doing professional web-development so it was there for my whole career, but I never used it, I just read a book written by its maker.
Till 2011 I had to use a framework that was a bit like GWT in PHP, because the company just had PHP and C coders and no one wanted to pay a switch.
2011 I started with JS and read stuff like "The Good Parts" and "Professional JavaScript". I wrote a JSON-HTTP-API and rewrote the whole UI in ExtJS.
Then I took a sabbatical in 2014 where I played around with Crafty, Phaser, D3 and continued my masters degree where I had to use Ember for a few projects.
Last year I dropped in a young project that was using React.
Funny thing is, all the time JQuery felt really old to me, so I never considered using it.
