66
67

Is jQuery dying?help (self.javascript)

SomeRandomBuddy が 投稿

I didn't realize there was any negative jQuery sentiment around, but after doing some light reading, I can totally see why. Is jQuery's popularity fading? What are its preferred alternatives, and why?

全 171 件のコメント
並べ替え:
ベスト
トップ新着論争中古い順Q&A

[–]nerfviking 64ポイント65ポイント  (3子コメント)

jQuery isn't going to go anywhere until businesses can realistically assume that the vast majority of their customers are on modern browsers. So it might be dying, but, much like Adobe Flash, it's going to be a slow death.

[–]leptons 1ポイント2ポイント  (2子コメント)

jQuery gave up support for some legacy browsers, so its benefit isn't what it used to be. https://jquery.com/browser-support/

[–]blangjemp 22ポイント23ポイント  (0子コメント)

But they're still maintaining the 1.* branch which continues support for older browsers

[–]waveform 2ポイント3ポイント  (0子コメント)

jQuery gave up support for some legacy browsers

I wouldn't say that exactly - if you need to support those browsers, simply use the latest jQuery version which does.

[–]greim 56ポイント57ポイント  (15子コメント)

Is jQuery dying?

As a resumé buzzword? Definitely. As a useful tool in your toolbox? Nah.

Some of the newer SPA frameworks reduce the need for jQuery since they handle DOM updates for you. I still use it in my React project, but only for reading from the DOM; never to mutate. For static websites, it's still quite useful and contemporary.

[–]reckonbeatsall 12ポイント13ポイント  (7子コメント)

I still use it in my React project, but only for reading from the DOM;

Could you elaborate on why you use jQuery to read from the DOM when using React? Couldn't you use refs and findDOMNode instead?

[–]greim 9ポイント10ポイント  (5子コメント)

To be honest, there's no strong reason my app couldn't be de-jQuery-ified, other than the few days of effort it would cost. Plus jQuery has some nice helper methods like is() and closest() that I'd want to backfill.

Ideally, someone would release a trimmed-down read-only subset of jQuery that dropped all the ajax, event handling and mutation stuff.

[–]Bummykins 11ポイント12ポイント  (1子コメント)

jQuery released a subset of jQuery that drops whatever you want. You can build a version with whatever you want. And someone made a build builder http://projects.jga.me/jquery-builder/

[–]greim 2ポイント3ポイント  (0子コメント)

I'll have to check into that again. Last time I looked, it didn't seem like mutation methods were a discreet "module" that you could drop from a custom build.

[–]fairfield 4ポイント5ポイント  (2子コメント)

zepto.js comes pretty close to what you're describing.

[–]one800higginspizza delivery boy 1ポイント2ポイント  (0子コメント)

Was going to suggest this. Judging by his comment, he could probably swap Zepto in place without any issues.

[–]greim 0ポイント1ポイント  (0子コメント)

Isn't Zepto's goal to achieve parity with core jQuery functions? I.e. still has DOM mutation capabilities? Those are what I'd specifically want to get rid of.

[–]gregersriddare 2ポイント3ポイント  (0子コメント)

He could. I'm just as curious as you.

[–]SomeRandomBuddy[S] 6ポイント7ポイント  (0子コメント)

I think this is a well rounded and informative answer. Thanks

[–]nex_xen 0ポイント1ポイント  (5子コメント)

With modern browsers, there is a school of thought which says jQuery is unnecessary: http://YouMightNotNeedjQuery.com

[–]greim 1ポイント2ポイント  (0子コメント)

The subtext is that jQuery's mindshare position has evolved beyond a convenience function multi-tool, into a pseudo-platform in its own right. It protects you from the flaws of the underlying platform so well that it fosters ignorance of it, which has bred a whole generation of devs who don't understand the web.

Whether or not that's true, I still think that some sort of DOM convenience function multi-tool is a useful addition to a web developer's repertoire.

[–]jcampbelly 0ポイント1ポイント  (3子コメント)

I look at some of the solutions posted, qualified by a conditional greater-than, based on IE versions, and with multiple nested branching conditionals, and my thoughts swing hard, with a thud, to: "this is precisely why I use jQuery."

When commodities (storage, memory, compute, power) are not unacceptably expensive, I consider jQuery to be a highly functional, thoroughly tested, documented solution to a class of problems that I would rather consider solved than attempt to reinvent. It's a valid solution to 90% of the work I need to get past to get to the actual problem a human being wants me to solve.

I agree that native javascript should absolutely be used where performance is critical (gaming, algorithms, etc). I agree that native javascript is best for libraries, where it's best to have no dependencies.

But for working with the DOM, AJAX, basic UI events, cross-browser behavior... thanks, but it's 2015 and I have bigger fish to fry.

[–]nex_xen 0ポイント1ポイント  (2子コメント)

When you look at the page with IE10 set in the filter, you see how many things it's trivial to do without a library. If you need to support IE8, jQuery is probably the way to go, but if not, it might not be doing all that much for you.

[–]jcampbelly 0ポイント1ポイント  (1子コメント)

Sure, the current generation of browsers is pretty good. That's a recent phenomenon, and a break in the clouds of a very old storm.

What strikes me is how compliant we have all become to IE's dominance of the pace of adoption in browser technology. It's the key decision we all must make when deciding on our technology because it's the lowest common denominator. That has always been the case. It's not getting better. Edge is not going to run on < Windows 10. Soon enough, we'll be back to limiting ourselves to the capabilities of legacy users running Windows 7 and IE 11. Microsoft is still consciously screwing over every web developer with that decision. It's unjustifiable and infuriating. Chrome and Firefox are better and have no problem crossing the OS boundary, even into Linux land. Clearly it's possible.

I decided a long time ago that the aggravation of that reality is something that I would gladly pay dearly to insulate myself from whenever possible. It's not that I haven't noticed or don't appreciate the progress of modern web browsers. It's that my time is better spent working on other problems than trying to backfill jQuery so I can feel better about myself.

[–]nex_xen 0ポイント1ポイント  (0子コメント)

I have a completely different attitude. Many people (including myself) can build things which target IE10+, which is decently standards compliant. Recent versions of Windows auto-update IE, meaning it's close to being as evergreen as any other browser.

If you're worried about being locked in to IE11, take a look at CanIUse.com, IE11 supports many, many things most people don't use yet.

[–]MrStubbs 30ポイント31ポイント  (4子コメント)

jQuery's popularity is waning because the DOM API's across browsers are getting better and more standardized. Powerful application frameworks like Backbone, Angular, Ember and React exist for building modern web applications, so for many teams it doesn't make sense to go with simple event driven DOM manipulation.

[–]spinlock 7ポイント8ポイント  (3子コメント)

FYI - Ember uses jQuery. But, it is using it less and less. Currently, only views rely on jQuery so I could imagine jQuery going away in 2.0 (because views are going away in 2.0).

I feel like the way Ember needs jQuery less and less is a good microcosm for how js devs in general need jQuery less and less.

[–]jbarket 6ポイント7ポイント  (0子コメント)

Similarly, Angular provides jqLite, which provides some of the most used functionality of jQuery.

[–]MrStubbs 6ポイント7ポイント  (1子コメント)

I believe that backbone uses jquery too.

[–]oldboyFX 15ポイント16ポイント  (2子コメント)

jQuery is fine. Becoming expert DOM manipulator in raw javascript won't make you a good programmer. Pure DOM manipulation is fairly trivial anyway, and jQuery is just a utility lib that makes the grunt work easier.

I see jQuery mainly as syntactic sugar and cross browser normalizing lib. It also does some clever behind the scenes grunt work such as removing data and event listeners from removed elements etc.

It's very useful depending on what kind of stack you're working with. I render everything serverside and then manipulate the dom manually, so jQuery provides lots of value for me. If I was working with something like React, there wouldn't be any reason to include it. As I said, dom manipulation is easy. It's like laying bricks at the construction site. Software architecture is the hard part.

Many developers are condescending to people who use jQuery. jQuery users are often seen as "lesser" developers. Ignore that. jQuery is just a tool, nothing more. It's also super popular and yes, most of the people who use it arent great developers. Just like most of the people who eat pizza aren't geniuses. That doesn't mean that everyone who eats pizza is a retard.

TL;DR - Get familiar with and try learning the native DOM api, but don't be afraid of using jQuery if it provides value for you, ignore the haters.

[–]untogethered 3ポイント4ポイント  (0子コメント)

Developers who rely on jQuery are worse than ones who use raw DOM stuff, IMO.

Using it isn't really a problem, but it's important to have a concept of what's going on underneath if you want your code to run well.

[–]eorroe 0ポイント1ポイント  (0子コメント)

I'd think you'd like NodeList.js over jQuery :)

Since it uses the Native DOM APIs

[–]jbarket 15ポイント16ポイント  (0子コメント)

It's not dying. It just doesn't fit into the current thinking that manually manipulating the DOM is bad. At it's core, it's a convenience layer for doing something that Angular, React, et cetera obfuscate away completely.

You'll see Bootstrap mentioned in a similar capacity these days, although not as frequently, as people begin to adopt CSS frameworks like Inuit, Susy, Bourbon, et cetera that leverage a different approach to providing the same kinds of features.

Neither one is dying, or even remotely close to going away. But if these trends continue, they'll continue to become less popular for new projects.

[–]parlezmoose 25ポイント26ポイント  (55子コメント)

$.ajax is still useful

[–]theQuandary 28ポイント29ポイント  (0子コメント)

Upcoming fetch API is on track to be standardized (and already has a polyfill)

https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API

[–]maremp 7ポイント8ポイント  (8子コメント)

One does not use whole jquery just to do ajax.

Edit: reference guide to replacing commonly used functions from jquery: You Might Not Need jQuery

[–]worldDev 23ポイント24ポイント  (0子コメント)

My observations dictate most people use whole jquery for just one feature.

[–]x-skeww 2ポイント3ポイント  (3子コメント)

Most websites which include jQuery only use a small subset of its features. But, to be fair, they might need some more in the future. E.g. when they add some new plugin to their CMS which comes with some JavaScript. The use jQuery as some sort of platform.

Also, XHR's API is probably one of the dumbest browser APIs. The Java/XML-like DOM APIs are already pretty horrible, but this one is on an entirely different level.

if (xhr.readyState === 4 && ...) {...}

Four. Of course. What else could it be?

Do you know why it's 0-4? It's because someone exposed enum values to a language which does not support enums. I'm certain the C++ code on the other side makes a lot more sense. On the JS side, however, we got those unnamed numerical constants which don't mean anything.

Thankfully, the Fetch API fixes this.

[–]maremp 1ポイント2ポイント  (0子コメント)

I know, that's really stupid. At least that is the syntax in IE8 or earlier, IE9 fixes it to check request.status and IE10+ makes it this.status, which kind of screws it up for ES6 arrow function which binds this reference.

When reading this I was thinking of Fetch API, thanks for mentioning it. Although the polyfill currently supports only IE9+, which still sucks for some legacy projects.

[–]jad3d 0ポイント1ポイント  (1子コメント)

Also it almost makes more to sense to include the whole thing as it's already cached on people's machines when you include it from a popular cdn.

[–]maremp 0ポイント1ポイント  (0子コメント)

There is also a big chance that a library like Fetch API polyfill is already included. Great thing about Fetch is that it will be possible to just drop loading the polyfill in the future when it will be implemented in all common browsers.

[–]arathael -3ポイント-2ポイント  (2子コメント)

Am I a meme nazi to point out it is "One does not simply..."?

I don't want to be a dick, but come on.. we're grown ups here.

[–]xredxditx 3ポイント4ポイント  (0子コメント)

Grown ups don't give a shit about memes

[–]maremp 0ポイント1ポイント  (0子コメント)

It wasn't meant to be from a meme.

One does not simply use whole jquery just to do ajax.

sounds stupid. If it were read as English, it would mean negative of simply, therefore it's hard. In this case, it's not hard to use jQuery for just ajax, it just isn't efficient since there are better and more lightweight solutions.

[–]MEAT_FIST 3ポイント4ポイント  (4子コメント)

IMO superagent does a better job at what $.ajax would accomplish. It's pretty cool.

[–]throwawayphpizza 1ポイント2ポイント  (3子コメント)

I recently started working with superagent and quickly moved over to axios because superagent doesn't support promises.

[–]kuenx 0ポイント1ポイント  (0子コメント)

I've used request and superagent and have only recently come across axios. I've used it in a project and it's pretty cool.

request and superagent support Node.js streams though. Can be a big plus depending on what you want to do.

[–]MEAT_FIST 0ポイント1ポイント  (1子コメント)

Can you elaborate on "doesn't support promises" ? I have used it many times with promises.

[–]BONER_PAROLE 1ポイント2ポイント  (0子コメント)

https://github.com/radiosilence/xr

[–]danheartsjs 1ポイント2ポイント  (0子コメント)

A plug for a friend that wrote more functionality to support REST using super agent. I present restwrapper! https://github.com/lyleg/restwrapper

[–]Ericth 1ポイント2ポイント  (2子コメント)

What's wrong with xmlhttp though? No dependencies or anything. Granted the syntax is a bit uglier and if you wanna go promises then you'll have to do it yourself.

[–]parlezmoose 11ポイント12ポイント  (1子コメント)

I always use promises. In 99% of projects jquery is there anyways so I might as well use it for ajax.

[–]Walter_Bishop_PhD 4ポイント5ポイント  (0子コメント)

Plus $.ajax is going to be adapted to use a proper Promise API in the next version, so it'll be doubly handy imo:

http://blog.jquery.com/2014/10/29/jquery-3-0-the-next-generations/comment-page-2/#comment-550576

[–]10097338 1ポイント2ポイント  (8子コメント)

There are a bunch of npm packages that accomplish the same thing without all the bulk of jquery. The most popular being request.

[–]mediumdeviationJavaScript Gardener 2ポイント3ポイント  (7子コメント)

without the bulk of jQuery

request

lol

[–]kenman 5ポイント6ポイント  (5子コメント)

Do you have any constructive criticism?

[–]itsananderson 1ポイント2ポイント  (1子コメント)

It's a somewhat fair point. request, while an awesome library, is basically the kitchen sink of HTTP. I've definitely seen cases where people use it when http.get( would be nearly as simple.

That said, Node has very different performance concerns, so a large library dependency isn't really a big deal.

[–]kenman 2ポイント3ポイント  (0子コメント)

Yeah, I was just looking for more than "lol".

[–]mediumdeviationJavaScript Gardener 4ポイント5ポイント  (1子コメント)

Only that if you want to recommend libraries to avoid the bulkiness of jQuery, than you should not recommend one that is several times larger than jQuery and is pretty much unusable on the client side, where jQuery is used.

Oh, and http://microjs.com/#Ajax

[–]x-skeww 1ポイント2ポイント  (0子コメント)

I recommend to use this fetch polyfill:

https://github.com/github/fetch

The Fetch API is already natively supported by Firefox and Chrome.

[–]mattdesl 0ポイント1ポイント  (0子コメント)

Haha seriously. It's hundreds of kb after browserify + uglifyjs.

Just use 'xhr' module and move on. :)

[–]johnnyvibrant 4ポイント5ポイント  (1子コメント)

In my opinion jQuery is just becoming more irrelevant, browsers are starting to actually become a little more standardised. Although Isnt this really the goal for jQuery, when it does becomes pointless to use then the developers who created it surely should be happy that their message has got across.

[–]jcampbelly 0ポイント1ポイント  (0子コメント)

For about 10 years, jQuery has served many roles for all major browsers and platforms. jQuery is what it is today because of hard work of dedicated, intelligent people, but also because of the abject failures of the browsers ecosystem. Those roles may be successfully fulfilled by most popular browers and platforms natively within a few years with minimal subtle differences and fewer alien, masochistic, psychotic APIs. It will be a good day when jQuery's source code dwindles to a bunch of aliases to native, standardized APIs. When that happens, it will not be to the browser ecosystem's credit, but their great shame.

It should not be forgotten that the jQuery team stepped onto a scene populated by hostile pricks like IE, genius progressives like Firefox and Chrome (who came later), a smattering of esoteric, isolationist psychopaths like Safari, and a handful of capable, well-meaning but minority elements like Opera, and the other less well known factors. They looked at what all of them were claiming to do, said "this sucks," and made a much better interface that worked consistently for all of them, then gave it away for free.

[–]xjohnseanx 5ポイント6ポイント  (3子コメント)

I think there is a general trend towards using a more declarative approach such as with React. Lots of imperative tools such as jQuery are harder to reason about and encourage you to manipulate the DOM directly. Functional programming and the flux architecture is a more controlled approach to making single page applications.

[–]temp4630985421 2ポイント3ポイント  (1子コメント)

I believe it's becoming obsolete. Basically everything jQuery does falls into one of three categories: duplicating native functionality with bugs and cross-browser differences fixed, creating new APIs for bad native APIs, and implementing features not handled by native APIs. The first is becoming obsolete as browsers fix bugs and get on track with the standards, and the second as standards bodies incorporate ideas from jQuery into native features (document.querySelectorAll, Promise, fetch). For the third, most developers now prefer a modular approach, loading a single-purpose library for each feature they want rather than a larger library that also contains features they don't want. This shift in preference is no doubt aided by the first two trends, which have made it much easier to create a single-purpose library without first patching the ground you're standing on.

[–]bart2019 0ポイント1ポイント  (0子コメント)

The latter is also possible using a plugin system, just as jQuery incorporates: rarely used features could be (should be) a plugin, which you only load into jQuery when you actually need it.

This reduces the chances of conflicting libraries.

Maybe that's just theory, and jQuery does contain too much bloat from the start. Maybe some stuff ought to be culled and put into a plugin.

[–]ikwaa 2ポイント3ポイント  (8子コメント)

As a front end developer specifically what is a better alternative?

[–]xtremebuzz1 1ポイント2ポイント  (6子コメント)

Right, I used to use angular, but once they dropped IE8 support and started moving to 2.x, I couldn't for business needs. If you need compatibility with IE8, I still don't know of a clear alternative.

[–]ikwaa 0ポイント1ポイント  (1子コメント)

Yeah I mean my current job we need to support older browsers. I feel stuck in the past there -_- I'd be curious what I should start learning on my own time that would be more desirable at other companies that are gravitating away Jquery though

[–]Elminster_Aumar 0ポイント1ポイント  (0子コメント)

Or...spend your own time finding an employer who pays for you to learn those things.

[–]gojukebox 0ポイント1ポイント  (3子コメント)

Angular 1.2.x is maintained specifically for those that need IE8 support, for a little while at least.

[–]xtremebuzz1 0ポイント1ポイント  (2子コメント)

Yup, aware of and using it. But I'd rather use jQuery with good design paterns than an old version of Angular.

[–]gojukebox 0ポイント1ポイント  (1子コメント)

Those are waay different libraries for waay different purposes. Comparing angular to jQuery is like comparing a blueprint, instruction manual and team of special laborers to a toolbelt.

[–]xtremebuzz1 0ポイント1ポイント  (0子コメント)

Good analogy. The blueprint and instruction manual, as you say, are definitely looser with jQuery, but there are established patterns that give you the same decoupling benefits of Angular 1.x.

The toolbox and laborers (are there, just as much as it they are there for backbone). You just have to put some thought into how you want to handle something angular abstracts for you (data binding for instance).

In the end jquery does far less for you out of the box than angular. But it also gives you more freedom (for better or worse). They are very different, butI wouldn't say they're use cases always differ that greatly.

[–]gojukebox 0ポイント1ポイント  (0子コメント)

Use libraries specific for what you are trying to accomplish, rather than loading a "kitchen-sink" of methods only to use a few.

There are much smaller libraries specific to DOM manipulation, AJAX, etc, without being all-inclusive.

Also, most everything can be accomplished without a JS library.

[–]slyf 1ポイント2ポイント  (0子コメント)

Is jQuery's popularity fading?

Yes, with the popularity of older IE going away and modern helpers existing right in the core then people are needing jquery less and less

What are its preferred alternatives

Plain old javascript http://youmightnotneedjquery.com/, but you can also use http://zeptojs.com/ if you like something minimal

One big thing I miss are the promises which IE does not support, but they can be polyfilled in various ways or a ton of folks are using Babel these days which has a nifty polyfill right there.

[–]_doingnumbers 1ポイント2ポイント  (0子コメント)

I try not to use it at all these days, it's not as important as it used to be.

[–]hurkle 1ポイント2ポイント  (0子コメント)

I'd also like to point out that for the hundreds of small / individual web agencies that crank out web sites for SMBs and NGOs and the like, jQuery is embedded deep into their toolboxes, whether they're doing WordPress/CMS stuff or just adding interactivity to a static site. Just slap me some jQuery in there and Bob's yer uncle.

However, for targeting unknown browsers, I often like to resort to vanilla JavaScript as a "substitute". Check caniuse.com to see how far down the browser support chain you can go and you'll be surprised at how far vanilla JS and good programming practices can take you.

With that said, for building SPAs, I'm all about the modern toolchains. But SPAs ain't websites, and jQuery will be around for a good while yet simply because of it's convenience (even if it's overkill).

[–]waveform 2ポイント3ポイント  (0子コメント)

Not according to Betteridge's law of headlines.

[–]sime_vidas 2ポイント3ポイント  (0子コメント)

Since all browser vendors have agreed to replace their engines with one perfect browser engine that is completely bug-free, implements all the Web APIs perfectly, and will be installed on every single computer and mobile device in existence (mandated by a new global, inter-governmental law, which will be enforced on the entire human population), then yes, jQuery is indeed dying.

[–]achen2345 6ポイント7ポイント  (11子コメント)

I suspect that jQuery became popular only because of querySelectors. The argument about solving cross-browser issues is a bunch of noise. There were a bunch of frameworks around before jQuery that did just this and had a much smaller API.

The bottom line is that (some) people are intimidated by the DOM and now querySelectors are available natively cross-browser back to IE9. jQuery is a victim of its own success and its dying as a result. It is on life support being sustained by a universe of jQuery plugins.

[–]fireball_jones 4ポイント5ポイント  (7子コメント)

querySelectors and returning a jQuery object so you could chain other jquery functions on to it. Something like $().width().addClass() gets a bit more verbose in plain JS.

[–]bart2019 0ポイント1ポイント  (1子コメント)

Don't forget that that snippet will never fail, let alone crash even if the DOM object you're after isn't found. That's a huge bonus of using jQuery.

[–]achen2345 0ポイント1ポイント  (0子コメント)

Don't forget that that snippet will never fail

never is a very strong word. I have seen jQuery like this fail IE8.

[–]achen2345 0ポイント1ポイント  (3子コメント)

That may be more convenient to write, but when I see code like that I can't help but think it just looks like you are trying to punish your users. Do you have any idea how much slower method chaining is compared to vanilla code? This stuff would absolutely choke IE8 which entirely defeats the point of using jQuery in the first place.

[–]akuma0 0ポイント1ポイント  (1子コメント)

Actually, no, I don't. Are you saying that calling a method on a returned object is more expensive in a significant way than calling methods on an existing object, passing in the returned object?

[–]achen2345 0ポイント1ポイント  (0子コメント)

In my experience with jQuery.... yes, absolutely. As far as method chaining outside of jQuery it completely depends upon the code, the depth, and the approach.

[–]edwinjm 0ポイント1ポイント  (0子コメント)

No, it's not slower.

[–]eorroe 0ポイント1ポイント  (0子コメント)

NodeList.js takes care of this with the Native DOM APIs

[–]jcampbelly 0ポイント1ポイント  (2子コメント)

It was popular for a lot more reasons than selectors. Things have not always been so good for javascript as they have been in the past few years. In addition to selectors we got $.ajax (thank god), $.Deferred (before there were promises), $.on (delegation is awesome), $.data (before there was a standard), mouseenter/mouseleave events (because mouseover wasn't doing what people expected), chaining, and way more than I can list here.

Cross browser inconsistencies are hardly noise... see:

[–]achen2345 0ポイント1ポイント  (1子コメント)

All of what you listed were popular and common in tools before jQuery became popular, so your list is not incredibly convincing.

[–]tobsn 5ポイント6ポイント  (1子コメント)

No.

Next unfunded question.

[–]dhdfdh 1ポイント2ポイント  (38子コメント)

The native APIs in the browser are now to the point where you don't need jQuery to do the work for you so jQuery's usefulness to those who don't take the time to learn how things work has been diminishing for quite some time.

[–]nerfviking 1ポイント2ポイント  (37子コメント)

Is using native APIs still a bunch of document.getElementByUngodlyLongFunctionName('whatever')?

I discovered jQuery 5 years ago and I've never gone back.

[–]achen2345 14ポイント15ポイント  (5子コメント)

I don't need a 65k library to alias a long method name.

[–]x-skeww 1ポイント2ポイント  (4子コメント)

https://mathiasbynens.be/demo/jquery-size

1.11.2 is about 33 KB (minified and gzipped).

[–]achen2345 0ポイント1ポイント  (3子コメント)

Alright, I can play that game. According to that chart 1.11.2 is 284k of actual code you are punishing your users with. Code you don't need full of methods that get chained together like a prison chain-gang to make your browser crawl like syrup. Now I like jQuery even less.

[–]x-skeww 1ポイント2ポイント  (2子コメント)

According to that chart 1.11.2 is 284k of actual code

That's the unminified version which is full of comments and long descriptive local identifiers.

It's 96 KB of code which is parsed and executed in the browser and it's 33 KB which is sent over the wire.

Modern JS engines are quite advanced. They will actually skip some work which they don't have to do. So, you don't really pay that much for functions which aren't used, because they aren't properly parsed and compiled until they are used.

You see, having some unused garbage lying around is a very common use case.

http://blog.chromium.org/2014/02/compiling-in-background-for-smoother.html

make your browser crawl like syrup

Reddit crawls like syrup? How about Stack Overflow and Wikipedia?

[–]achen2345 0ポイント1ポイント  (1子コメント)

Reddit is slow on very long pages. Stack Overflow is slow too, but I blame advertising for that.

[–]x-skeww 0ポイント1ポイント  (0子コメント)

Reddit is slow on very long pages.

Did you profile it? Did you try it without extensions?

I profiled this long page with Firefox, Chrome, and IE11. I didn't find any evidence that a significant amount of time is spent inside jQuery's code.

Can you show me a profile where jQuery is the culprit?

Well, there is fairly little time spent inside scripts to begin with. Secondly, it isn't slow for me. It takes about 2.5s to display the page and most of that is the server's response time.

[–]MrStubbs 2ポイント3ポイント  (27子コメント)

you would use document.querySelectorAll() to get a similar behavoir to jquery selectors.

[–]alamandraxPrincipal Engineer/UI Architect 7ポイント8ポイント  (10子コメント)

My main "problem" with document.querySelector... is the returned NodeList. I much prefer the jQuery wrapped result out of convenience more than anything else.

[–]GeZe8 1ポイント2ポイント  (0子コメント)

You could use the future query and queryAll methods which return an Elements collection, which is a subclass of Array.

[–]gregersriddare 0ポイント1ポイント  (7子コメント)

What's wrong with NodeList?

[–]alamandraxPrincipal Engineer/UI Architect 1ポイント2ポイント  (1子コメント)

Like I said, there's nothing wrong with it. It's the convenience of the jQuery wrapped result. I'm most likely going to chain multiple operations together anyway, so it's convenient.

[–]eorroe 0ポイント1ポイント  (0子コメント)

Check out NodeList.js I bet that's a wayyyy better NodeList?? :)

[–]tswaters 0ポイント1ポイント  (4子コメント)

What's wrong with NodeList?

typeof NodeList.forEach; // undefined

Granted, there's a few ways around that and even more with es6

[–]LeBuddha 0ポイント1ポイント  (0子コメント)

not inlined for readability, also not really trying to make a point about anything.

var forEach = Array.prototype.forEach;
var nList = document.querySelectorAll('p');
var doFunction = function(currentValue,index,array) { console.log('doFunction!'); };

forEach.call(nList,doFuction);

[–]iwishiwasrelevant 0ポイント1ポイント  (2子コメント)

function toArray() {
    return Array.prototype.slice.call( myNodeList );
}

Converting a nodeList to an array is very very easy, if you just need array like functionality. In ES7 you'll also be able to do Array.from() which will be even easier. No excuse there.

jQuery chaining IS convenient but generally speaking we're moving away from constantly mutating the dom directly. I personally find myself very very rarely doing so much manipulation that jQuery would be helpful.

[–]x-skeww 0ポイント1ポイント  (1子コメント)

Array.from is from ES6. Also, you can use an array literal with spread (also ES6) to get the same effect:

[...document.querySelectorAll('.foo')].forEach(...)

By the way, DOM Level 4 will probably fix this problem. ES6 allows subclassing of arrays. The current plan is to make NodeList inherit those array methods.

[–]eorroe 0ポイント1ポイント  (0子コメント)

Correction the new Elements collection, and here's a better NodeList

[–]edwinjm 0ポイント1ポイント  (1子コメント)

Actually, to get something useful (and use forEach, filter etcetera), you have to write this:

Array.prototype.slice.call(document.querySelectorAll(query))

It's becoming a bit masochistic, isn't it?

[–]eorroe 0ポイント1ポイント  (0子コメント)

NodeList.js takes care of that plus more

[–]nerfviking -2ポイント-1ポイント  (9子コメント)

That's slightly better, since at least it's a single function. Still way too wordy for such a common operation, though.

And yes, I realize I can write my own function to do a shorthand version of it. :)

[–]recrof 1ポイント2ポイント  (6子コメント)

https://jsperf.com/getelementbyid-vs-queryselector/28 might be interesting for everyone.

[–]nerfviking 0ポイント1ポイント  (0子コメント)

So, on Firefox 40.0.2, it's about a sixth as fast as querySelectorAll() selecting by ID and half as fast selecting by class. So if I'm going to be doing a large volume of selects by IDm it's a lot better to use vanilla javascript, but I suspect for most use scenarios it doesn't matter very much. (And if I'm really concerned about speed, querySelectorAll() isn't a great choice either.)

[–]looeee 0ポイント1ポイント  (0子コメント)

Its interesting, but all it really shows is that unless you are doing thousands of selections in your website then there will be no appreciable difference. Most use cases involve selecting a few elements and storing them as a variable (var foo = $(".foo") ), and if your case involves making tens of thousands of selections then you should probably not use jQuery.

For most people this is not a reason to avoid it though.

[–]cuddlyogre -1ポイント0ポイント  (3子コメント)

Wow. I had no idea jquery was that much slower than raw javascript. Why is that?

[–]recrof 0ポイント1ポイント  (2子コメント)

jQuery is written in javascript. getElementById/querySelector are native browser functions that are written in c++

[–]cuddlyogre 0ポイント1ポイント  (1子コメント)

I'm aware of that but I just figured jquery selectors were wrappers for the raw JavaScript. Is that not the case?

[–]recrof 0ポイント1ポイント  (0子コメント)

reading jQuery code will give you much more insight how complex it really is, even in modern browsers.

[–]hearwa -1ポイント0ポイント  (1子コメント)

That's what intellisense is for.

[–]nerfviking 0ポイント1ポイント  (0子コメント)

Or perhaps a precompiler. Intellisense may make it faster to write code, but it doesn't make your code more readable.

[–]brackin -1ポイント0ポイント  (3子コメント)

how would i learn about all these newer javascript methods?

[–]eorroe 0ポイント1ポイント  (0子コメント)

I'd check out NodeList.js then you won't need to go back

[–]SirHound 1ポイント2ポイント  (2子コメント)

Until I see a good mouseleave/mouseenter alternative, I'll still use it for events.

[–]cheese_wizard 0ポイント1ポイント  (0子コメント)

I think for really basic fixes here and there to gramma's flower shop site, a little jquery comes in handy. Say they already have some crazy ugly-minified plugin for their menus or something and they need a slight modification to it. Just slapping some document.ready with some DOM tweaks in there, maybe an ajax call or two. But don't build large apps with. I feel like it's a scripting language within a scripting language, and using typescript or something to build an angular app is going the other way.

[–]stephenhuh 1ポイント2ポイント  (4子コメント)

jQuery was created so that you can "write less and do more" -- that is doing DOM manipulation without something like jQuery is truly a pain in the ass. jQuery isn't dying. I suspect that it'll only get more compact to fit into modern front-end frameworks like jqlite in angular.

[–]evilmaus 0ポイント1ポイント  (0子コメント)

I imagine it hollowing out over time as browsers finally converge to the standards.

[–]eorroe 0ポイント1ポイント  (2子コメント)

NodeList.js takes the pain in the ass out of the Native DOM APIs

[–]jdalton 0ポイント1ポイント  (1子コメント)

It has no unit tests :/

[–]eorroe 0ポイント1ポイント  (0子コメント)

Yea Ik, I really should make some, any ideas with what? and man there's so much to it, its gonna be some long tests.

[–]inf4my 0ポイント1ポイント  (0子コメント)

jQuery is still used as a dependency in a lot of the frameworks that are now being utilized to build more ambitious web apps such as Ember (Angular can utilize it if available). It is still definitely a must know tool for modern web developers. Part of what is so appealing about using jQuery is they have spent years creating a compatibility layer for the DOM across multiple browsers. Most developers need to consider that web APIs don't always behave the same in Chrome, Firefox, IE, etc and across versions and jQuery has a lot of those cases handled for you.

[–]eorroe 0ポイント1ポイント  (0子コメント)

My preferred alternative is my library NodeList.js because its super light, very very fast. (Even faster than plain JS, in some ways, I'll leave that up to you to figure out why :D) and if you use this library. You will never have to deal with upgrading, updating or deprecation by me.

My library uses the browser as a dependency meaning:

Whatever methods/properties the browser provides, my library has. I've seen a lot of smaller versions of jQuery but tbh their pretty useless because the only provide so much, that might as well just use jQuery. Now compare to my library whatever browsers decide on it will get. So basically the browser vendors are doing the work for you and I.

This is purely for DOM manipulation, so for ajax I'd use the fetch API

[–]jcampbelly 0ポイント1ポイント  (0子コメント)

Nope. Storage, bandwidth, compute time, and battery life are commodities. Developer hours and project time-to-delivery are not. With one script tag, ~40KB of bandwidth, and a few milliseconds of compute time on any modern device at the leading edge of every page load, our project can be freed from writing, testing, documenting, and teaching 90% of the boilerplate functionality we need in any major web application.

That's a no-brainer to me and everybody else involved.

I haven't been persuaded by arguments against jQuery that involve:

  • People who rely too heavily on jQuery plugins. Why should I care about them? How is that jQuery's fault?
  • People who don't learn javascript itself "because jQuery." Why should I care about them? How is that jQuery's fault?
  • How polyfills can serve in the place of 1/Nth of jQuery and support x/N of its supported platforms. Why do I want something that does less? I care about building something useful in less time, commodities like money, storage, bandwidth, and compute time exist to enable that.
  • How you can stitch together A+B+C micro libraries with a pipeline tool to get 80% of jQuery. Work harder for less? See above.
  • How most web sites don't use it all. Well, I'm talking about web applications - so yeah, we use all of it.
  • How jQuery is slower than XYZ. I can identify when that's really important and optimize later.
  • How it isn't pushing the web forward to pile onto one cart. The web is doing fine. Why is that my problem?

None of those things matter enough to me, my project, my team, or my employer and I think that's true for a tremendously overwhelming percentage of people who consciously decide to use jQuery. Many of us really aren't in the business of ideological, philosophical, or platform purity, or simply writing javascript for the sake of writing javascript. Most of the time we're trying to make a tool to solve a problem other non-developer human beings have asked us to make, not just to satisfy our own selfish need for engineering perfection. How is it better for them if we decide to chose something different, not necessarily better, than jQuery? How is it better for them if we spend more of their time making something that is functionally identical?

[–]astoilkov 0ポイント1ポイント  (0子コメント)

I think the future is in things like this. A jQuery clone that does not have all the fixes but have almost all the API (in 250 lines of code).

[–]DJDarkViper 0ポイント1ポイント  (1子コメント)

I try to exclusively use Angular these days my self

But then something comes along, and it's always some jquery plugin that requires jquery and it perfectly matches exactly what I want to accomplish and the no jquery alternatives miss the mark ever so slightly enough to not warrant the time involved in getting it that way.

Thankfully that's going away slowly.

I don't hate jquery, nor am I avoiding it because it's trendy to do. I'm just trying to keep my JS load as light as possible because the amount of script writing dedicated to just the angular controllers and directives and its various extensions and plugins and such is enough to make me nervous about browser performance :p

[–]eorroe 0ポイント1ポイント  (0子コメント)

NodeList.js check it out, very light, and very powerful

[–]tebriel -1ポイント0ポイント  (0子コメント)

One can hope.