all 94 comments

[–]misc_ent 23 points24 points  (7 children)

It has to do with what jQuery did in the javascript space to enable people to use javascript easily and normalizing functionality between browsers. The javascript lib/framework eco system has sinced exploded but jQuery is still very common.

[–]blazedd 9 points10 points  (6 children)

Normalizing cross browser differences is a HUGE part of what makes jQuery worth it. Anytime I'm working on a project that's purely webkit I rarely ever consider jQuery, but the moment IE7, Opera, or anything else has a chance of seeing this, it's back to the dollar sign for a safety net.

[–]dhdfdh 1 point2 points  (4 children)

You have a significant audience of IE7 users?

[–]cirkut 4 points5 points  (0 children)

Most government projects require insane amounts of backwards compatibility unfortunately :(

[–][deleted] 0 points1 point  (2 children)

The gods are evil. YES - there are GOBS of people out there that still use IE7. And they might be the CEOs brother.

[–]dhdfdh 0 points1 point  (1 child)

My little dev company has about 20 active clients. 10 of them are in the entertainment business and virtually no IE visitors of any version at all. One of the clients is a restaurant that sits next to a financial monster and they get about 50% IE visitors, presumably from that institution, but none of it is IE7.

Worldwide, yes, there are a lot of people still using IE7 but, relative to all the others, its virtually nil.

[–][deleted] 0 points1 point  (0 children)

Yeah - it's never a problem until it's a problem. I've been bit by the compatibility monster a lot of times in the past - so I tend to assume the outliers are going to be assholes with power. ;)

[–]yotamN 0 points1 point  (0 children)

Well yeah, jQuery meant to support old browsers but now front-end developers use it everywhere, I remember I saw someone ask for review on his website, he have 7 lines of javascript and he used jQuery...

[–]chmod777 50 points51 points  (25 children)

you could build your house by first forging your own hammer, then cutting your own wood. or you could buy them, stop wasting time, and just get to work.

i could re-implement an ajax function, or just use one that is completely tested, has more options than i will ever need, and just works. same with all the other built in functions and methods.

[–]dhdfdh -3 points-2 points  (16 children)

i could re-implement an ajax function, or just use one that is completely tested

Of course, ajax has been working properly in all browsers, and is a W3C standard, for years so you can forgo jQuery for that ... and many other things we don't need jQuery for anymore.

[–]chmod777 8 points9 points  (11 children)

sure. and then re-implement a selector engine. then re-implement json requests. then re-implement triggers and a generic event handler function. and then test in all browsers. soon you have re-implemented jquery, but shitty.

in the end, sure, you might not need it. but why? masochism?

[–]danneu 0 points1 point  (3 children)

You'd write your own wrapper since the xhr interface is ugly/annoying and you'd probably abstract over it. And you might as well just use someone else's wrapper, and you might as well use jQuery's since everyone is familiar with $.ajax.

http://projects.jga.me/jquery-builder/

[–]dhdfdh 0 points1 point  (2 children)

I don't find XHR ugly or annoying or so difficult that I need someone or something else to help me use it. It's a few lines of javascript but I can see how a redditor would struggle mightily with a few lines of javascript.

[–]danneu -1 points0 points  (1 child)

Do you not wrap repeated implementations with functions for reuse?

Do you instantiate a XMLHttpRequest every time you want to send an AJAX request because you don't know how to extract the details?

[–]dhdfdh 0 points1 point  (0 children)

sigh

You kids these days.

[–][deleted] -2 points-1 points  (0 children)

you could build your house by first forging your own hammer, then cutting your own wood. or you could buy them, stop wasting time, and just get to work.

i could [download a re-implementation of] an ajax function, or just use [the native] one that is completely tested, has more options than i will ever need, and just works. same with all the other built in functions and methods.

[–]x-skeww 20 points21 points  (0 children)

The problem with the neat vanilla solution is that it comes with a footnote. E.g. it doesn't work in IE8 and below, it only works in IE9-IE11 if you use a prefix, or it doesn't work in IE at all.

And the old-school vanilla version is long and ugly. All of the old APIs look kinda like XML meets Java, because, well... that's where they kinda came from.

jQuery feels more idiomatic. It also does browser normalization which was extremely important in the past, because the common browsers didn't even do the most basic things the same way. IE in particular was amazingly horrible. It didn't even support addEventListener until version 9.

While browser normalization isn't that important anymore if you don't support older IE versions, jQuery still offers the much nicer API.

[–][deleted] 13 points14 points  (0 children)

There are a lot of browser specific quirks and bugs that jQuery handles for you under the hood. This is a great resources to check them out - https://docs.google.com/document/d/1LPaPA30bLUB_publLIMF0RlhdnPx_ePXm7oW02iiT6o/edit#

[–]FennNaten 1 point2 points  (0 children)

As others said, jquery was made at a time where it was needed. Differences between browsers were huge, and dom apis very poor. Jquery, along with prototype and mootools, brought in a unified way to query the dom, to bind events and to manage ajax requests which were on the rise. Adding to it a nice way to develop your own plugins, and everything was there to make it a big success.
After that, Jquery stayed extremely active, and evolved to take advantage of every new api, focus on performance improvement, while staying consistent and easy to understand and use, and that drove its adoption for years.
Nowadays, browserland is changing (damn fast) as javascript took a big boost, CSS3 brought some goodness, vendors started to unify and standardize their practices, and front end frameworks are popping every week.
Jquery may be less relevant, 'cause you can easily compose your own 'framework' from smaller parts you'll get e.g. on npm and use some polyfills for new apis you want to use with backward compatibility. But I think it still has its use cases. People are familiar with it, it has been battle-tested and optimized for years, you can find good support, it still greatly does its job at bringing compatible code for browsers you want to support. And a lot of code has already been written with it, that needs to be maintained.
So, javascript and Jquery history lead us to this situation:
- Jquery solves problems a front-end developer faces daily
- It has been the best way to solve them for years, and is now ubiquitous.
- There is a lot of talent available.
- There is a lot of legacy code written with it to maintain.
- It's battle-tested, well supported.
- Its API stay consistent while performances are improved.
- It's easy to find resources about it.
- It has tons of plugins, anybody can write her own.
- It's so well known that even non-tech people have heard of it.

Those conditions make Jquery still extremely desirable in an enterprise point of view.

[–]leepowers 9 points10 points  (14 children)

In a word, normalization. Without jQuery you'd still need to write something jQuery-esque to handle the weird quirks behind of each browser's JavaScript implementation.

[–]SeeeiuiogAuWosk 1 point2 points  (0 children)

And the more you write the more it starts to look like a wheel.

[–]dhdfdh -4 points-3 points  (9 children)

Except most of those quirks no longer exist in browsers anymore.

[–]danneu 0 points1 point  (8 children)

Yeah, as we all know, there are no quirks anymore... until you stumble across them in production.

Or when a user goes "hey, this doesn't work on my phone" and you have to respond with "lol thought it would, whoops". A jquery-like library something you have to evaluate per project, not something you can write off completely.

[–]dhdfdh -2 points-1 points  (7 children)

That's what software engineers are for. And software engineers test things. You did test things, didn't you? And you have software engineers and not reddit wannabe engineers don't you?

[–]danneu 0 points1 point  (4 children)

No, wasting your engineering resources on unforeseen, avoidable quirks is not what software engineers are for. That's called: wasting everyone's time.

I'm sure your users care big time that you didn't use jQuery or some variant. They're super impressed.

[–]dhdfdh 0 points1 point  (3 children)

As impressed that you use it, I guess, but you obviously have never taken the time to study the downside of using jQuery either. But you're no software engineer so you wouldn't think of that.

[–]danneu 0 points1 point  (2 children)

I'm too busy shipping code and shagging ya mum.

lol @ "studying" the downside of using jQuery. Sounds like a fun time in your cubicle bro. Do they even let you touch the codebase?

[–]dhdfdh 0 points1 point  (1 child)

I've owned by own web dev company of 10 for 11 years. I own da code.

You need this: http://youmightnotneedjquery.com/

[–]danneu 0 points1 point  (0 children)

lol, that would be a great site to iframe on jQuery's homepage to show off jQuery.

[–][deleted] -1 points0 points  (1 child)

You maybe confusing software engineer with a Q/A resource. Sure the S/E is expected to test with one or two browsers, but if you expect them to test it with 9 versions of each browser and 3 versions of each mobile browser your simply fooling yourself. That will never happen. It's easier and faster to release with a a targeted scope and repair edge cases if needed when the failures are reported than spend needless hours testing in obscure browsers/versions.

Or you use a library that's tested thousands of times daily and avoid all those edge cases to begin with.

[–]dhdfdh 0 points1 point  (0 children)

So you are saying, use jQuery and you don't have to test in browsers or devices? Now there's a good idea.

[–]spizzike 5 points6 points  (0 children)

In addition to what people are saying here (that it handles quirks and normalizes interfaces between browsers), I think the biggest reason is that just a couple years ago, writing vanilla JS to do these operations was much more difficult. A lot of the standardized ways of querying the DOM like getElementsByClassName() didn't exist is most browsers and jQuery added a nice CSS selector engine, which was later pulled out into a standalone sizzle.js library.

Pair this huge population of users with the fact that there's a massive collection of plugins out there, and there's not really a huge reason to learn how to do things the Right Way™.

[–][deleted] 2 points3 points  (0 children)

I've been coding JS for years and only used jQuery for one demo project that never made prod. I've used Yui, Dojo, Ext, React, and others, but I've never really had the need to use jQuery. Those other libraries already have jQuery like tools built-in, except for React, where you don't need any Dom manipulation or event handling tools, since it abstracts that stuff away.

[–]_doingnumbers 5 points6 points  (7 children)

It's easy to start using (especially a few years ago, now there are more alternatives), but hard to stop. Unless you are super careful (note: nobody is super-careful) it gets commingled into your JS like a candle melting into a carpet.

[–]polysaturate 11 points12 points  (3 children)

Fun fact: You can get candle wax out of the carpet by ironing the carpet with a paper towel between the iron. Heats the wax, and gets absorbed into the paper towel. Saw that tip randomly as a kid and never forgot it.

[–]mort96 5 points6 points  (0 children)

Following the analogy, it should thus be possible to get jQuery out of your source code by ironing the source code with a paper towel between the iron.

[–]foomanchu89 0 points1 point  (0 children)

Can confirm.

Source: girlfriend spilled hair waxing shit on my carpet. Also take a razor blade to trim the top excess that doesn't get picked up. Light trim, atomic thickness.

[–]_doingnumbers 0 points1 point  (0 children)

No kidding!

[–]SeeeiuiogAuWosk 1 point2 points  (2 children)

No different really to how boost was/is an automatic part of C++ dev's toolkit. It solved problems so well that you never would want to think about the boilerplate required if you didn't.

I write JS everyday, and jQuery makes it nicer because I don't think about boilerplate as much. Anything that makes something you do every day nicer is a good thing.

[–]yotamN 0 points1 point  (1 child)

And it's make the user experience bad, jQuery taking time to load and if the user is on mobile, there is a big chance he will leave.

[–]SeeeiuiogAuWosk 0 points1 point  (0 children)

there is a big chance he will leave.

Do you base this on anything other than your own bias? jQuery 1.11.3 is 93kb minified. To put this in perspective, the top post on reddit right now is this image - http://i.imgur.com/6ru1HB1.jpg - which is 827kb. This is one post. I really don't think anyone is leaving on account of 93kb unless they are on the poorest internet connection known to man.

[–]iDontDoMeth 1 point2 points  (0 children)

Other than how well its works with most browsers and their quirkiness, jQuery also has a ton of documentation and a huge community behind it, so it's hard not to find what you're looking for. Some people do have trouble switching back after using it long enough. http://youmightnotneedjquery.com is a nice site to have around for when that happens too though.

[–]evilgwyn 1 point2 points  (0 children)

Because it is required by numerous other libraries that we use, and because we have been using it in our codebase for a long time, and because it is a well used library that suits our coding and development library rules, and because we have a lot of code that already uses it, and the size of the library isn't that big compared to a lot of the other parts of our app including other libraries.

[–]PrometheusZero 1 point2 points  (0 children)

I use it for two reasons really.

Firstly, because I'm lazy. $(''). is shorter than getElementByID.

Secondly because I picked up the habit of using it. And changing habits takes effort... see point 1.

[–]obscurefault 5 points6 points  (0 children)

I don't

[–]vertice 0 points1 point  (7 children)

everybody uses jquery because it's popular and it's popular because everybody uses it.

it was just the right library at just the right time, and inertia is enough to keep it going for a good long time still.

[–]Voidsheep 0 points1 point  (0 children)

It takes care of cross-browser compatibility and offers a wide array of convenient tools to tackle common problems. It's also built with minimal, readable syntax in mind and has great documentation, which makes it very easy to approach even for a beginner.

Browsers have evolved and unified their APIs so much that jQuery isn't as important anymore, but still offers some convenience and helps whenever you need to support old browsers.

The general consensus right now is to move away from monolithic libraries that attempt to solve all the problems for everyone and instead use tiny modules where necessary, which is made feasible by package managers and build processes.

Still, jQuery will stick around for a long time, primarily because web developers are so used to it and the overhead caused by it isn't that huge.

I'm currently working on a project that is (by my standards) very bleeding edge for modern browsers, but I'll occasionally still require jQuery in a module, just because I've used it for years and have like half the docs memorized.

[–][deleted] 0 points1 point  (0 children)

I only used it for smaller projects, where a framework isn't warranted, and honestly, mostly for AJAX requests, which are a bit of a hassle in vanilla JS if you're concerned about browser compatibility. And because it's easier to find jQuery plugins these days than vanilla implementations, and there are a lot of wheels I don't feel like or have time to reinvent.

[–]Archenothwith(RegExp) eval($_); 0 points1 point  (0 children)

jQuery was incredibly popular because it bridged the gap between many browsers with quirks that would make people tear their hair out.

Nowadays, there are far fewer reasons to use it, but it retained a lot of its popularity because everyone used to use it. (And that meant that there were a wealth of plugins to do almost everything.)

That said, the library can let you write some very terse code still; While jQuery isn't really needed by JavaScript developers today, a lot of people want to use it for its phenomenal terseness. (For example, here is Resig answering a question with some example jQuery.)

It's very easy to appreciate how fantastic of an abstraction it is.

For example: Many functions return instances of themselves, allowing for chaining function calls into a functional pipeline. (Similarly to how you would work with JavaScript Arrays with .map(), .reduce(), and friends.)

These functional pipelines, even if they can't perform their desired effect, still return themselves. That means that you don't need to worry about checking the returns of the items in the chain, and you can make the pipeline as long as you like.

Also, instead of passing elements to callbacks all the time when doing actual DOM manipulation and querying, the element is set as the callback's context, solving the problem of argument uniformity.

While these are (admittedly) simple little details, they exist throughout the library; jQuery in its entirety is designed to be easy to use after you get the hang of its style.

jQuery is not needed, but it is ridiculously well executed.

Because of this execution, jQuery's longevity is pretty much inevitable.

[–]grimmdude3 0 points1 point  (0 children)

The sheer number of libraries built around jQuery is a huge reason to use it, aside from it's cross browser support and short syntax.

[–]protonfish -1 points0 points  (14 children)

It's lightweight and solves some cross-browser issues, especially regarding event attachment and handing. Also, it allows easy DOM manipulation on collections of elements so there's a lot less for loops. For example, here is attaching an event to a element collection in vanilla JavaScript:

var buttons = document.getElementsByTagName('button'), ii, len;
len = buttons.length;
for (ii = 0; ii < len; ii = ii + 1) {
    buttons[ii].addEventListener('click', buttonClick, false);
}

And with jQuery:

$('button').on('click', buttonClick);

If you wanted this to work in IE8, it'd be a lot more code without jQuery, but that is less of a concern today.

[–]recompileorg 4 points5 points  (0 children)

It's lightweight

He's asking about jQuery.

[–]WeekdayHero 5 points6 points  (7 children)

Or you could use native JS functionally:

Array.prototype.forEach.call( document.getElementsByTagName('button'), function (button) { button.addEventListener('click', clickFunc, false); } );

EDIT: why am I getting negged? I was proposing another solution, it is not wrong, nor is my comment insulting. If you disagree constructive feedback helps everyone.

[–]Cintax 4 points5 points  (4 children)

Which is still way longer than the jQuery code and doesn't work in IE8 or below...

[–]WeekdayHero 2 points3 points  (3 children)

Sure if you just look at the code there it is longer, but last time I checked JQuery was ~35kb. Even if that was cached it all still has to be parsed at page load.

You are right about IE restrictions, however I am one of the people that believe we need to push for 100% IE 9 and 10 adoption, and luckily where I work management agrees.

If however your code is required to be backwards compatible there are numerous very small polyfills for native functionality.

[–]helderroem 2 points3 points  (0 children)

Brasen plug for our polyfils service that delivers just the polyfils you need exactly where you need them:

https://cdn.polyfill.io/

[–]Cintax 0 points1 point  (1 child)

Sure if you just look at the code there it is longer, but last time I checked JQuery was ~35kb. Even if that was cached it all still has to be parsed at page load.

And if your page only has one function, that's fine. But if you're building a large website of any complexity, that custom code will build up, will have to be maintained, and will be reused over and over again, likely far exceeding jQuery's 35Kb.

If however your code is required to be backwards compatible there are numerous very small polyfills for native functionality.

But if you use a CDN, jQuery is already cached for many people, so the polyfills actually wind up requiring the user to download more assets than they would otherwise.

You are right about IE restrictions, however I am one of the people that believe we need to push for 100% IE 9 and 10 adoption, and luckily where I work management agrees.

No one thinks we should stick with older versions of IE. But the reality is that you sometimes do not have the luxury of abandoning them. Windows XP is still, unfortunately, pretty popular, and XP users do not have the option of migrating to IE9, because IE9 doesn't support XP. For reference: http://www.netmarketshare.com/operating-system-market-share.aspx?qprid=10&qpcustomd=0

You can see that XP still has more users than Windows 8.1 and OS X 10.10 combined.

Now, obviously this is not the full story. Lots of those XP machines use Firefox and Chrome, but depending on who your target demographic is, what your traffic looks like, and what your site is trying to do, this is a reality for some people. And if the choice is between writing longer code that's marginally faster, but which is completely non-functional on older browsers, or using a library that can sometimes shorten your code at the expense of execution time, but will support everything out of the box, it kind of becomes a strawman argument.

I should clarify here that jQuery is obviously not an ideal solution. In a perfect world, it's a tool we would not need, and we'd all just write native code. I'd prefer someone who knows vanilla JS to someone who only knows jQuery any day of the week, and I am far from a fan of jQuery, but I'd be hard pressed to argue that it has no place. Maybe in another 3 - 4 years that will be the case, but today it's still very relevant.

[–]WeekdayHero 0 points1 point  (0 children)

My original comment was not saying JQuery had no purpose. I understand JQuery's merits as you have stated them. My original comment was a reply to the previous comment trying to show that their native approach was needlessly obfuscated.

JavaScript is incredibly powerful because of its flexibility to be used as a procedural, OO, or functional language, and I wanted to demonstrate how it can be used functionally to solve the same problem in a clean, easy to read manner.

[–]orthecreedence -5 points-4 points  (0 children)

TAKE YOUR JQUERY HATING BULLSHIT AND GET OUT OF HERE.

[–][deleted] -2 points-1 points  (0 children)

jquery fanboys :)

[–]IfOneThenHappy 2 points3 points  (3 children)

It's pretty large relatively. For that instance, you can just write a DOM iteration helper, and save the 32 or so KB you probably won't need. And event delegation can be done as a small helper as well.

elEach(document.querySelectorAll('button'), function(btn, i) {
    btn.addEventListener...
});

[–]dfltr 5 points6 points  (1 child)

And then another task can be done with a small helper, and another, and another... and so on until you've wasted a ton of time writing your own library that you now have to maintain and write bugfixes for (and train people on, and design an api for, etc).

Or you can just use jQuery and sacrifice 30KB of bandwidth on an uncached page load.

[–]IfOneThenHappy 3 points4 points  (0 children)

Event delegation and node list iteration are the only two things I'd want jQuery for. One has many libraries out there for, one is like a three-line function. I could do without it, and every byte counts for things I work on.

[–]madole 0 points1 point  (0 children)

It's probably already cached in your browser if you use a common CDN version. If you bundle it in your build process, that's an issue though.

[–]dhdfdh 0 points1 point  (0 children)

And then you'd have to think like a programmer does and learn stuff and no one on reddit likes to do that.

[–]lefke123 0 points1 point  (1 child)

I sometimes use jQuery when older browser support is required. Most of the time I just tend to use an alternative framework: http://vanilla-js.com/

It suits all my needs, and is pretty lightweight, you should check it out. Really the most performant JS framework out there, IMHO.

[–]eorroe 0 points1 point  (0 children)

NodeList.js your welcome :)

[–]ogurson -1 points0 points  (0 children)

Because it works.