
Is jQuery still relevant? (2014) - thelgevold
http://www.syntaxsuccess.com/viewarticle/is-jquery-still-relevant
======
AznHisoka
If i had to build an app in a week and my life was on the line, i would use
Jquery and ignore any other javascript frameworks.

~~~
foota
I think react makes a good case for the `kidnapped by Jeff Bezos to work on
applications` situation. I find the simple way that you can just render things
and not have to worry about DOM manipulation to be very freeing.

~~~
untog
Agreed. Once you know React it's incredibly quick to throw something together
(especially if you use Material UI or similar). jQuery is definitely simpler
but the props/state model of React means fewer bugs slip through the cracks
when you're in a hurry.

(and my usual disclaimer - if you're going to use React for a quick project,
you can probably use Preact and save the extra bloat)

~~~
sAbakumoff
Top 100 run-time dependencies of react apps in terms of number of usage :
[https://airtable.com/shrfmD9l5rAW4Z03N/tbls8DesxQZT7VH0p/viw...](https://airtable.com/shrfmD9l5rAW4Z03N/tbls8DesxQZT7VH0p/viwpuP25nIgGBO9eV)
jQuery is in 15th position.

~~~
untog
Hey, I never said people are doing it right.

React completely removes the need for jQuery if you're using it correctly,
because you should rarely if ever touch the DOM, and jQuery is... a DOM
manipulation library.

~~~
sAbakumoff
jQuery nowadays is much more than DOM manipulation lib. In the latest version
it gives the promises that are compatible with Promises/A+ spec. It has the
powerful ajax calls functions.

~~~
oddstorms
They all moved on so they have no idea how good it is.

~~~
sAbakumoff
I mean instead of adding polyfills for "fetch" api and "es6 promises" that
brings a gazillion dependencies with them, one can simply add jquery package
that has ZERO _runtime_
dependencies([https://github.com/jquery/jquery/blob/master/package.json](https://github.com/jquery/jquery/blob/master/package.json))
and have ajax calls, promises and much, much more out of the box. I love
jQuery.

~~~
untog
Or you could add a fetch polyfill with zero dependencies:

[https://github.com/github/fetch/blob/master/package.json](https://github.com/github/fetch/blob/master/package.json)

And a Promises library with zero dependencies:

[https://github.com/stefanpenner/es6-promise/blob/master/pack...](https://github.com/stefanpenner/es6-promise/blob/master/package.json)

This is not as difficult as you're making it out to be.

~~~
sAbakumoff
It's still 2 dependencies in your project versus 1 dependency.

~~~
untog
1 dependency that's 34.6KB minified. That's a lot more than the two separate
dependencies, and besides, once you've gone to the trouble of adding a
package.json to add one dependency, adding one more is a very small step.

~~~
sAbakumoff
where 34.6KB size came from? I don't get it

------
overcast
I've moved away from jQuery for most everything, because I was really only
using it for selectors, and various other things that can be done in vanilla
browser JS. However if you want to play with UI frameworks like Bootstrap and
Semantic UI, you're going to be using it, and that's not a bad thing. Time and
place for any library. Out of fashion, doesn't mean out of relevance.

------
meesterdude
I love me some jQuery. While I don't ALWAYS reach for it in a project - I
usually do. It can add nice behavior to webpages with just a sprinkling of JS,
and not a lot of boilerplate, and not having to worry about browser edge
cases.

For the two dozen or so various medium/large sites i've worked on; Jquery,
underscore and d3 give me everything I want and then some.

But it's certainly not the "cool" kid anymore. It's an important fundamental
that you can use to do a lot with - but sites with more heavy use of JS will
probably gravitate towards a more structured framework like angular

------
chenster
Outside the framework, jQuery also has tons of free and powerful plugins that
we can't simply overlook in our day to day application development. We used
jqgrid for all of our datagrids. It's insanely powerful.

~~~
vinhboy
datepicker... for me.

~~~
sAbakumoff
jquery also gives me promises and ajax calls.

------
redthrowaway
Will jQuery ever _not_ be relevant? It's still the easiest way to accomplish
most basic tasks, and 90% of the websites out there make use of it in some
fashion or another. There are now a plethora of frameworks for building front
end web _apps_ , but for basic scripting I don't see anything replacing jQuery
anytime soon.

~~~
wongarsu
jQuery was built in a time when doing a simple ajax request required 2-3 code
paths just for cross-browser compatability, and some of those code paths
fairly verbose. Today most basic tasks are short and easy with just standard
APIs that every browser understands out of the box. The need for jQuery has
certainly diminished (usage not so much).

~~~
chenster
Not just for cross-browser compatibility, it's other main benefit is a DOM
manipulator.

------
yichi
If you are planning to ditch jQuery, make sure you consult this:

[https://docs.google.com/document/d/1LPaPA30bLUB_publLIMF0Rlh...](https://docs.google.com/document/d/1LPaPA30bLUB_publLIMF0RlhdnPx_ePXm7oW02iiT6o/edit)

~~~
nostrademons
Make sure you also consult browser marketshare numbers and decide exactly what
you need to support:

[http://caniuse.com/usage-table](http://caniuse.com/usage-table)

Many of the examples in that doc are Android < 4.1 (0.06%), IE < 9 (0.48%),
Firefox < 24 (~0.1%), etc. Even IE 9-11 is only 4% of the market these days.

The browser-compatibility story is _dramatically_ different from when JQuery
was created in 2006. All of the major browsers have been auto-updating for
several years now.

------
edgarvm
Most of problems pointed by the article are related to javascript and the DOM
model, JQuery just provides a very useful function set and interoperability
between browsers.

------
wwweston
jQuery _may_ not be enough to structure your application. This is actually
debatable -- there's many applications for which treating the document _as_
your model is a perfectly acceptable approach, and it can scale just fine
assuming some thoughtful discipline -- but some applications don't lend
themselves particularly well to the kind of resource-oriented practice
involved and having a separate model can make sense too.

jQuery is less necessary than it used to be in order to get reasonable tools
for working with the DOM and other browser APIs... but then again, depending
on your need for marginal utility and tolerance for personal attention to
corner cases, you never really _needed_ it. If you were determined, you could
always custom code a micro library that covered _most_ of the overlap between
what jQuery did and what your app needed. It's just that it often gave you the
gift of not having to pay attention to those cases. It still can.

Things jQuery will _always_ be relevant for: an example.

It might be the single most thoughtful yet pragmatic abstraction that I've had
the pleasure of regularly working with in the last decade. The basic idea of
using selectors to navigate the DOM was a key jump in productivity, the
fluent-chained interface was thoughtful and a massive boost. It almost never
leaked -- I can count on one hand the number of times in 10 years something
weird was going on underneath the hood that I had to pay attention to (Angular
exceeded this measure inside of a few months). And strangely enough, every
other library that was its contemporary when it was born seemed to think that
the problem with front-end development was JavaScript's lack of classes &
traditional OO, if the amount of library that was focused on adding them was
any indication. jQuery recognized how much of the pain was really coming from
_bad browser APIs_ , and how much productivity could come from building better
ones, combined with idioms/concepts from the functional side.

------
tim333
Still seems to be #1 in useage by a long shot
[https://w3techs.com/technologies/overview/javascript_library...](https://w3techs.com/technologies/overview/javascript_library/all)

~~~
lucideer
I think a much more relevant (but ultimately completely unmeasurable) metric
is the number of websites currently rolling out (i.e. "upgrading to" or
building afresh on) jQuery. The vast majority of sites in any statistic like
the above are always going to be older no-longer-very-actively-being-updated-
beyond-maybe-some-security-patches frontends.

An interesting indicative stat would be number of installs of the very latest
jQuery versions.

------
scarface74
I have a situation where a full framework was overkill but using Jquery was
causing an unmaintanable mess when creating a dynamic UI. I took a middle
ground. I came in and introduce Handlebars to the work flow. We still use
Jquery, but our ui is created with simple intuitive handlebar
templates/compiled functions.

When we do start building more complex web apps, we decided on Ember since it
uses Handlebars as its templating engine.

------
franciscop
I created a library to manipulate the DOM in a simplified way inspired by the
question, how would I build jQuery if I had to do it today?

Superdom [https://superdom.site/](https://superdom.site/)

------
mattezell
Perhaps I'm just lazy or missing something... While I don't often use it
directly, I do find that adding a ref to it makes my life easier when I'm
working in AngularJS.

------
sebringj
I don't think so. jQuery was intended to be a cross-browser approach to
JavaScript that just works. It does but if you check out MDN docs, you'll find
that now days, vanilla just works really well and ES6/7 have great features.
Modern browsers have aggressive updates that are simple to apply. It isn't the
same anymore. Also, doing actual apps is way easier with React or Vue, even on
small scales.

------
supersan
Not to mention that even AngularJS 1.x still bundles jqLite and switches to
full jQuery if you include it first.

------
aforty
"None of the popular patterns promote the tight coupling between view and
code."

Not sure how relevant this is either. React barely differentiates between view
and code, opting to put everything in one place.

