[Kajayacht]

One of the things I don't think it accounts for in talking about the downfall of something like jQuery is that as time goes on, the questions have already been asked.

So of course there's going to be less questions asked about jQuery in 2017 versus 2009, because if I need to figure out how to select elements based on an attribute rather than a class or id, it's already there.

[codingdave]

On the same note, the older frameworks solved older problems. jQuery was the killer framework because it handled browser compatibility back in a time when people not only needed to support IE8, but IE6, and few companies felt comfortable telling people to just update their browser. Well, those days are past, so that problem is no longer a reason to choose a framework, and when you take that out of the picture, jQuery just isn't so needed.

The same path is likely on all frameworks - they were designed to solve specific use cases, and as the entire industry matures, different solutions will embed themselves in the industry in different ways, reducing the raison d'etre for each framework, over time.

[shams93]

Yeah with jquery we were composing templates server side. Compared to Vue trying to do a SPA in jQuery is a season in hell. It can be done but it's brutal and fragile.

[eitland]

> It can be done but it's brutal and fragile.

Actually many who did jQuery were proud of it.

Some of us made rock solid sites or improved exiting ones quite a bit using a technology known as progressive enhancement.

Let me tell you what is fragile: the cool things I make today that won't even try to work if I disable Javascript. :-)

Edit: and given what we have seen over the last few days now would be a good time to reconsider if every website really needs to be able to run Javascript.

[djroomba]

I miss progressive enhancement, when/why did it die.

[bronson]

Did progressive enhancement ever catch on? It made for some great Rails 2 tutorials but I don't remember seeing it much in the wild.

It's going away because you basically have to write everything twice and it's hell to keep consistent.

[Can_Not]

If you need your website to work without JS, Nuxtjs is an amazing VueJS framework for SSR or static prerendering.

[pascalxus]

I'm quite surprised at this conclusion. I've always felt that doing SPA with jQuery was the easiest thing I've ever done in my development career. It's so easy to get something set up and running. And it's a breeze to figure out and read the code too: even when it's 10s of thousands of lines of code.

Is it just me, or are many of the newer frameworks actually harder to use? I tried Angular 1 about 4 or 5 years ago and it seemed like a complete disaster. Recently, I've been working on Vue and this seems a bit better.

[bronson]

Depends on the SPA. If you're trying to do something relatively simple, where the events and state clearly map to the UI, jQuery isn't too bad. It's even fun.

Once your SPA goes through an iteration or two with a few different programmers, you find your events have nasty ordering dependencies and your data becomes inconsistent all on its own. You have no idea why because you can't reproduce any of these issues on your own. You have to watch other people interact with your app just to reproduce bugs ("why the hell would you double click a link?") and git bisect becomes the most productive tool in your toolbox. Most project discussions end with a shrug. You yearn for the days when it was possible for a single human to ever understand the entire app, but that was six months ago and management steadfastly refuses to fund a rewrite. You look wildly around for any sign of hope...

As for Angular, agreed, but I'd rather work with it than a bunch of jQuery. React and Vue are quite pleasant.

[Albert_Camus]

>And it's a breeze to figure out and read the code too: even when it's 10s of thousands of lines of code.

Not at all. The issue with an application written in jQuery is a lack of sane state management. Forgetting to initialize (or re-initialize) values, not expecting things to be executed in a different order, and just poor organization in general led to mountains of runtime errors.

Nowadays we use Elm. The difference is night and day. I wrote a post on this topic a few months ago: https://charukiewi.cz/posts/elm/

[always_good]

> And [jQuery is] a breeze to figure out and read the code too: even when it's 10s of thousands of lines of code.

> Is it just me

Probably.

[pjmlp]

For the majority of my web development that verb is in the present tense.

[lolive]

I am not at all a front-end developper. But isn't jQuery the DOM API done right? [Which is a good thing, but only the beginning of the journey.]

[sim0n]

DOM APIs have much improved since jQuery first arrived, so while that was the case originally, it's become less true over time. It's definitely still less verbose though, for example:

  $('.my-component div').css({ background: 'yellow' })

vs.

  Array.from(document.querySelectorAll('.my-component div')).map(node => {
    node.style.background = 'yellow';
  })

[esprehn]

The modern DOM API has forEach on NodeList so you can skip the Array.from.

  document.querySelectorAll('.my-component div').forEach(node => node.style.background = 'yellow');

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

[scottmf]

Why use map instead of forEach?

[tvalentius]

If you only want to translate(map) each element in to another set of value, using Map is much more simpler and readable than forEach

[grumblestumble]

Actually, this is incorrect. You're abusing map here. The purpose of map is to map an existing array onto a new array. You're using map here to mutate properties on nodes in the original array, and creating a new Array, which has the length of the initial array, where each value is the return value of `node.style.background = 'yellow';`

forEach is much more indicative of what you're actually doing here, which is running through an iterable and mutating properties on each node.

Simple rule of thumb: if you're not using the results of `map`, you shouldn't be using it.

[scottmf]

The code loops through an array, has side effects and returns nothing so forEach would be more descriptive IMO.

As for simple/readable it’s the same code but s/map/forEach.

[dandelany]

Yes, in a way... it’s certainly (IMO) nicer to use than the DOM API. But “done right” used to mean not just “nicer to use” but “actually implemented correctly” (unlike major browsers at the time). Now that the DOM basics are pretty well-standardized, it’s mostly just “sugar” which isn’t necessarily worth the extra bundle size.

Another, bigger factor is that most modern frameworks use some form of templating and binding which means that you have less need to modify/interact with the DOM directly.

[pjmlp]

I wish those days were past.

Need to target IE 11 and FF ESR currently.

[nicoburns]

Yep! Same for React. It has a much smaller API surface area than Angular (and goes wrong it mysterious ways less often!), so fewer people will be asking questions about it.

From my perspective, it appears that React is still very much in ascendancy.

[dentemple]

From my anecdotal experience of just watching SO's React queue, most questions about React that show up (that aren't repeats) are almost always regarding how it's used with some library in the ecosystem.

React-router, Redux, Webpack, Material UI, etc.

So even though the API itself small, there's still an endless number of questions out there for people to ask!

[_ea1k]

The chart seemed to show React to be growing very quickly as well.

[lettergram]

Indeed! In fact, after I spent time using react and angular for two separate products, I actually switched back to mostly rolling my own JQuery (usually).

It just works, and takes up much less of my mindshare than trying to learn various frameworks every time I roll a new site (which incidentally is every 3 - 6 months). There is always more support for it (with all the questions being answered), and the API never changes. I actually develop faster, although typically I’m using web frameworks with templating backends - such as Rails (Ruby), Django (Python), Flask (Python), and Revel (Go)

[jamra]

I did that on a product as well. It went pretty well. The issue is with more complicated UI. The more complicated it is, the faster JQuery breaks down. That being said, it's better to have a bit of a spaghetti JQuery than to try and retrain unwilling programmers in Angular.

[mythrwy]

jQuery doesn't have to be spaghetti though. It gets that rap I think because most people that used it weren't good/experienced enough to organize bigger code. It can/usually does turn into a mess though but is faster to bang small things out in for me anyway.

[jamra]

It doesn’t have to be spaghetti. You are right. However, when you change state in multiple places, they either have to be aware of each other or you need some kind of state management. The benefit of libraries like React are that they abstract view rendering and take care of DOM diffing. The benefit of frameworks like Angular is that it manages state in addition to what React does.

On simpler projects, JQuery is more productive. But my main point is to program where it is comfortable and practical. The better academic choice is not necessarily the better choice. View your programming resources as people and make the pragmatic choice.

[slig]

Agreed. It'd be nice to have graphed the number of pageviews of each tag as well.

[Waterluvian]

Just made me think about a great metric as a developer: understanding how popular each SO page is about your library. Ie. "X is still catching up everyone, it's a very busy page. We have done a good job making Y more obvious, people aren't searching for it anymore."

[jcadam]

Right, jQuery is good and mature, and I can usually find what I need in the documentation. It will never die.

I don't use jQuery by itself these days, of course. I'm using it in combination with mithril.js (not as popular as React, but similar in concept) at the moment.

[Cthulhu_]

Similarly, JQuery questions remain higher than the other ones in that chart; does that mean JQuery remains popular, or that JQuery is hard and people need a lot of help for it?

Speaking for myself, it was often easier to copy / paste SO answers (in jquery) than try and figure things out for myself. I can imagine a lot of beginning developer start with jQuery and go to advanced frameworks after that.

[wwweston]

In addition to the possibilities you listed, it might mean:

* most sites aren't SPAs, and progressive enhancement of a document with light interactivity via jQuery is a development model that's a good fit for those sites

* progressive enhancement of a document is an easier development model to move into from having started to author HTML & CSS than many of the SPA frameworks (note that this is also true of PHP), and many training materials that bring people into web authoring use js+jQuery as the next step

* many sites aren't rewriting their codebases particularly frequently, and anything used there remains relevant longer.

[myth_drannon]

StackOverflow's job posts show the same trend. Jquery is required less and less http://www.reallyhyped.com/?keywords=angularjs%2Creactjs%2Cj...

[lakechfoma]

But again probably less <this is losing popularity> and more <this is no longer cool to tag>. That's a really nice tool though

[myth_drannon]

That's a possible explanation too. No one wants to say that the job is mostly maintaining large Angular codebase in addition to a small internal tool written in React that only senior stuff is allowed to play with...But hey we are a React shop!

[Kajayacht]

I think part of that is that jQuery is pretty universal and it's probably assumed that if someone says they know JavaScript, they know jQuery. Or, I at least assume that when I'm doing interviews.

[myth_drannon]

I think that would apply more to an Html than Jquery

[collyw]

Surely they could have used the number of times questions were viewed rather than asked.

[itcmcgrath]

"Of course there's going to be less questions"

Yet there are counter examples that show that can't be the complete story: http://sotagtrends.com/?tags=[jquery,python]&relative=false

[dmitriid]

You could argue that jQuery covers handling (a part of) DOM APIs which are updated only rarely.

Once you know what $().append().on().trigger() does, there's not that much left to know about jQuery. And most everything can be understood from docs.

Python, however, is a continuously evolving language with an ever expanding number of libraries and areas of application.

[kbenson]

Python is just an outlier when looking at this. Here's[1] a larger set of languages and frameworks, and given the premise it's not hard to guess the JS frameworks from the graph.

1: http://sotagtrends.com/?tags=[jquery,angularjs,c,c%2B%2B,rub...

[emodendroket]

Looking at the regex tag would suggest this logic doesn't necessarily hold.

[qaq]

Very good point and this obviously can skew the results greatly. Working in a fairly senior mid-size team I don't remember any of my colleagues asking any question on SO either so results could be also skewed by composition of user base and how good the docs are for a given proj.

[aalleavitch]

Yeah, it’s not like these sites have stopped using jquery altogether: my site uses React components but I still write a couple lines of jquery here and there for basic uses.

[iambateman]

This intuitively makes sense, but I'd like to see some control data. Has the volume of PHP questions (for example) fluctuated much over time?

[itcmcgrath]

http://sotagtrends.com/?tags=[jquery,python]&relative=false

[emodendroket]

That seems like a pretty compelling counterpoint.

[jonnycomputer]

ha, i came here to say this. I'd rather see web traffic results.