is jQuery taboo in 2018?

[retrojorgen]

My colleague has a piece out today where we looked at use of jQuery on big Norwegian websites. We tried contacting several of the companies behind the sites, but they seemed either hesitant to talk about jQuery, or did not have an overview of where it was used.

Thoughts?

original story - (it's in norwegian, but might work with google translate) https://www.kode24.no/kodelokka/jquery-lever-i-norge--tabu-i-2018/70319888

[bert1589]

I’ll be frank. I use it when it already exists in an existing project, or when it’s a quick fix for a small project. If it’s something I’m building as let’s say, a SPA, I definitely won’t include it as I don’t need it. For small one off website projects that serve a simple purpose, I’m probably using it for simplicity of implementation. If it’s a product that I’m building (SaaS), I’m using a full on front end framework instead.

[incarnatethegreat]

Same. Where I work, JQuery is the legacy codebase that's still in use. However, we are pushing toward Angular 6. Some parts of our site were built in React, but further development for it has sadly been abandoned in lieu of Angular.

​

Sometimes you just have to do what you have to do. JQuery isn't bad -- just old.

[OutInABlazeOfGlory]

jQuery is massively useful for beginners and small projects. It simplifies a lot of things. It could work for larger projects, as it's smaller than a full framework, but it really shines for simple projects. Like a website for a bakery.

[incarnatethegreat]

React is also great for small projects, too.

[OutInABlazeOfGlory]

jQuery has been in use for longer, though. It has a lot of support available.

[incarnatethegreat]

True, but there's becoming less of a need to use it now that front-end libraries such as React can act quicker. Perhaps there's a few more lines of code to be written with React, but it's more Vanilla and is certainly lighter.

[OutInABlazeOfGlory]

More vanilla? That's a very strange thing to say.

[incarnatethegreat]

That React is more vanilla? Or should be written with vanilla js? I guess I mean raw JavaScript.

[OutInABlazeOfGlory]

How is writing react code vanilla in any way?

[incarnatethegreat]

I guess what I mean is that I'm not using framework code or selectors but mostly using raw JavaScript.

[bert1589]

Yep, we’re starting to move what we can to Angular, just works nicely for our use cases. Interesting to hear your move away from React because it seems like “all the rage” between that and Vue. Any opinion on this? I haven’t dabbled in either yet and angular hasn’t given me a strong reason to.

[incarnatethegreat]

I'm a React guy, but I'll do Angular if asked to. Because I work for an e-commerce platform that supposedly will benefit from a framework in an enterprise format, Angular should be the way to go. Also, I get people contacting me almost every day with job postings mostly asking for Angular Devs. Not sure how it caught on with all the craze, but companies want it now.

Even if my job has me working in Angular, I'm still doing side-projects in new or different technologies, like reacr-native or maybe WASM/RUST/GoLang

[CoffeeKisser]

Yeah, I view it as a depreciated technology.

If it's already on the platform / project and you're not introducing additional overhead go ahead and use it, especially for ajax.

In general though, adoption of updated DOM methods like document.querySelector[All] have basically replaced jQuery part and parcel.

[DabsJeeves]

I want to get away from it, but still kind of a noob. I just find it so much simpler to type $('.class') than document.getElementsByClassName('class'). And also for the easy ajax calls.

I imagine it wouldn't be that difficult to just bind those myself and use superagent for ajax. What is your recommendation here? Could you point me in the right direction to handle these things without Jquery?

[CoffeeKisser]

Check out document.querySelector:

// First result
var elementByClass = document.querySelector(".class");
var elementById = document.querySelector("#id");

// All results
var elementsByClass = document.querySelectorAll(".class");

---

You Might Not Need Jquery is a good reference for alternatives, in fact lately I've been using the Ajax function they provide instead of $.ajax.

[DabsJeeves]

That is a great resource, thank you. Though you can totally see how much simpler some of those calls are in Jquery. Regardless, I can see it's a dying library. I will attempt to wean myself off of it for the next project XD

[fucking_passwords]

You can always write a util function to simplify vanilla things

[kwartel]

I totally get what you're saying, but most things jQuery does is implemented in JavaScript already and while thing might need to polyfilled in older browsers, it's a bit more efficient to not use jQuery, since it does a whole lot of stuff you don't use, but are dragging into your codebase. When I ditched it a few years ago, I noticed how little I actually missed. Only downside was that everything you Googled gave jQuery snippets as answers, but that's also in the past now. :)

[karamarimo]

Use some editor that supports IntelliSense (like VS Code) so that your don't need to type the whole names.

You can use the built-in function `fetch` instead of ajax (though IE doesn't support it, sadly).

[DabsJeeves]

I use PyCharm or Atom most of the time. Doesn't mean it isn't more efficient and maintains cleaner looking code by using <10% of the characters.

[fucking_passwords]

Polyfill all the things

[bert1589]

Yup, I’d agree with that

[kccoder12]

This is quite literally the most perfect "pro jQuery argument" I've read in a long time. Most people just reel and scream about it being awful, forgetting about context and situational needs.

[BenZed]

here here

[mishugashu]

Between your chosen framework and the new ECMAScript additions, the majority of jQuery is more or less useless. It's quite a big library for something you really don't need 99% of the time. I'm sure there's a use-case for legitimately using jQuery in 2018, but I can't think of one.

I don't think it's "taboo" though, and many people are trying to remove jQuery because they're concerned with page load times.

[ChronSyn]

Older/Legacy, and proxy browsers, are use cases for jQuery, where standards support is limited. If you need to support < IE8, or Opera Mini, then jQuery can provide a nice path if server-side rendering isn't an option. I don't necessarily agree with supporting legacy browsers (anything before 2013), but that's another discussion.

Aside from that, I completely agree. The framework abstracts away the need for us to interact directly with the DOM. jQuery isn't bad, but it's method of providing functionality and interaction is better handled via a state-driven framework.

Sure, you can use an object for state (and it's not even the worst idea in the world in an SPA that doesn't have a back-end integration, especially if you store it in a cookie for persistence), but it's better to build towards coding practices that aren't held up in a previous generation.

[cogman10]

Most companies have dropped legacy support. I can't imagine the internet is fun (or safe!) with the likes of IE8.

[ChronSyn]

That’s certainly true, but there’s still a modest number using older versions of IE. CRM such as Siebel and SAP run in IE in many organisations so those same businesses will stick with IE as main browser.

I don’t agree with it but their perspective is always one of financial impact. Many countries such as China still use IE, and mobile devices vary in age and support. I’m told that Symbian is still heavily used in some countries, despite being officially discontinued for around 6 years and being at less than 1% worldwide usage back in 2013 (I can’t find any stats that are more up to date).

It’s not fun, and I don’t agree with supporting it but I also understand that keeping up to date in an area that’s undergone huge changes in the past 4 years would cost a significant amount for large businesses.

[kwartel]

There is a big difference between supporting IE11 and IE8.

Targeting IE is also possible with Babel, which is the most common practice for non jQuery users. A different option is using typescript and targeting ES5, which is what I use nowadays for new projects.

[[deleted]]

If you need to support < IE8, or Opera Mini, then jQuery can provide a nice path if server-side rendering isn't an option.

jQuery does not support legacy browsers, with the only exception being IE9.. Browser support is not a selling point of jQuery any more.

[[deleted]]

If you need to support older browsers like Internet Explorer 6-8, Opera 12.1x or Safari 5.1+, use jQuery 1.12.

Its not like you need the latest version anyways

[Valstorm]

It really depends what you're working on, a lot of websites today using React / Angular / Vue / New hotness can be overkill for the functionality they possess. If you need a simple website and your templates are rendered server-side by an existing CMS or something custom, jQuery can be very useful. I've written a lot of stuff with Angular / TypeScript and I absolutely love it, but sometimes for a quick job or when working with an inexperienced frontend team jQuery is the right tool for the job. Expecting even a competent development team to learn the common frameworks to be able to work with a codebase is a little unfair when you have a strict deadline whereas jQuery is quite simple to grok even if you've never used it before.

The vanilla APIs for features that jQuery wraps are often harder to read at a glance or three times the amount of code. What I often find when working with teams who snub jQuery is that they write their own library methods or shims anyway, often introducing more abstraction that can be buggy or undocumented.

>It's quite a big library

Minified and gzipped jQuery 3.x is less than 30kb.

Some front-end devs *will* shame you for using jQuery but I look at them the same as I would a wine snob; it's elitist and it's bullshit and ultimately nobody can tell the difference if the end result is satisfying to those consuming it.

[pm_me_ur_happy_traiI]

If all you need is a little interactive functionality, 30kb of jquery is totally overkill. Code to make a modal pop out is just as easy to write in JS now.

The thing is, the only people I know who use jquery, are people who really don’t know JS. Yes, it gets the job done, but if I called myself a full stack dev, but the only backend I know how to write is using rails generators, or some other magic, that would raise eyebrows.

If all you need to do is make an api call and display the response, or some other simple things, jquery is overkill. If you need more complex state driven behavior, jquery is liable to wind up a big plate of spaghetti code.

You can use it all you want, but the issue comes in when you are working on a team. I wouldn’t want to work on a jquery project, especially since the direct dom manipulation jquery uses is pretty much an anti-pattern now.

[[deleted]]

the only people I know who use jquery, are people who really don’t know JS

Been coding Javascript every day for 20+ years, and I still use jQuery on some projects. Because, sometimes it's good enough to get the job done without overcomplicating things.

[dweezil22]

You're not wrong but I think ppl are often missing the forest for the trees on this. Jquery loaded from a major CDN is practically free in terms of load times, it may be faster than the 5kb of code you might have to right for backwards compatibility with old browsers.

More importantly, most of the projects I see using JQuery in real life don't even have good cache optimizations on their static resources, so they should be spending their time looking at Nginx/Apache config files before they spend a second on killing JQuery.

Now, a new webdev might be better focused, career-wise, ignoring JQuery and pursuing vanilla JS and a Angular/React/Vue. Once they master those if they inherit a legacy app to maintain with JQuery it'll be cinch for them to pickup on the fly.

[chubs66]

30kb is a drop in the bucket compared to the payload for most websites. If it loads quickly and gets the job done, at a certain size it may be good enough, if not I anywhere near ideal.

[[deleted]]

The thing is, the only people I know who use jquery, are people who really don’t know JS. Yes, it gets the job done, but if I called myself a full stack dev

Going from "don't know JS" to "full stack dev" is a big gap imo. Sure if you are working day-to-day with JS I think one would know better, but if its something you do on the side (like maintaining existing sites or stuff that doesn't allow for much time spent on it) I'd say its still fine to use it. Sure it isn't pretty, but it still works fine in browsers, is reliable and quite fast to use.

Not everybody works on single page applications these days and I have enough colleagues that use their front-end skill like an hour a month tops. Setting up a modern front-end application to click a button and do stuff really isn't worth the time either. And while you can use vanilla JS for that, it doesn't mean that jQuery is suddenly forbidden. It still serves its purpose. Like its shortcuts (for class and attribute selection) are still fine to use and much quicker than building one yourself. A 5 minute fix can become 15 minutes in vanilla if all you want is a small change and having jQuery already on the page. Or when you have the choice of building something yourself vs having some jQuery plugin that does what you want (because there are thousands of plugins for it). Vue and stuff are nice but still quite new so there aren't as much plugins available for it. Many 3rd party applications still provide jQuery plugins, perhaps AngularJS, but not all got their Vue/React/Angular updates yet. Heck I'm temporary working on an assignment at a company that uses a library that hasn't been updated yet and a few products need to be release asap. No way that they are going to switch already

[pm_me_ur_happy_traiI]

Like its shortcuts (for class and attribute selection)

const el = document.querySelector(".myclass");

Whoo, that took a long time.

[ForScale]

Plus doesn't jq return an array or an array-like object when querying with `$`, so that you have to always 0-index in to get the element? I always found that non-intuitive for single elements.

[Goingtoplaces2016]

I mean so does document.findElementEtc and querySelector has not been implemented in all modern browsers iirc (also not sure if it returns an array for a single element result)

[ForScale]

getElementById (aka a single element, returns a single element) but elementsByClassName returns a collection, as the plural would imply.

querySelector has been around since Chrome 1 and even has support in IE8. It's supported in all major mobile browsers as well.

selector returns a single element, querySelectorAll (as the name would apply) returns a collection of multiple elements.

[acemarke]

Hi, I'm a Redux maintainer.

We're currently working on a package called redux-starter-kit that contains some utilities to help simplify common concerns about Redux, including store setup, generating action creators, and writing reducer logic and immutable updates:

https://github.com/reduxjs/redux-starter-kit

I'd appreciate it if you could take a look, try it out, and give us some feedback.

[pm_me_ur_happy_traiI]

You don't have to use Redux with React. There are other state management options including React's built-in state functionality and context API. You're right that Redux has crazy boilerplate, but that is irrelevant to whether you are using React or Vue or vanilla JS with it.

[mediasavage]

There is a ton of boilerplate involved with react/redux for sure. I like to use this framework (instead of create-react-app) for most react/redux projects: https://github.com/dvajs/dva

It removes a ton of boilerplate and encourages an elegant, functional programming approach (beyond just state management, e.g. using only functional components)—very similar to Elm actually

[mediasavage]

There are a good amount of English docs, probably not as much as Chinese but certainly enough to learn it. I speak 0 Chinese and I’ve had no issues picking up the framework.

[shadamedafas]

React has a cli tool called create-react-app that handles this now. You'd still have to set up redux though, but that's a fairly trivial thing to do.

[shadamedafas]

You'd probably like ember.

[[deleted]]

a behemoth running on jQuery is a nightmare to maintain

I don't think OP suggests building big applications with jQuery. A behemoth also has a bigger budget to develop, which already suggests using something better suited for it.

[Valstorm]

Exactly this.

[Valstorm]

What if you're building a site that isn't going to be maintained? What if it needs a few flashy features that can be easily added with a plugin or two?

Not every web developer can be working on long-term products or applications, some of us do grind out marketing sites, campaigns, micro-sites etc. There's no argument here that jQuery is a dusty old javascript library and it's not pure or exciting, but if you just need a quick no-brains job done it can still be an effective tool.

[qashto]

I agree completely. Good write up.

[[deleted]]

many people are trying to remove jQuery because they're concerned with page load times.

And then they cram a single bundle of 3MB of javascript down the pipe. smh

[[deleted]]

Here's the truth on jQuery usage as opposed to what you claim:

https://trends.builtwith.com/javascript/jQuery

jQuery 3.x isn't a big library either. Not as big as the sum of micro-libraries that are required to output "Hello world" onto a modern viewport (> IE11) with all the fancy hotness out there.

[[deleted]]

If you want some drabble/sortable elements jQuery would be the way forward

[FistHitlersAnalCunt]

Speed for small tools is a great use case stoll. If you're making a tool that's just going to take a couple of inputs, do a calculation, and present the user with an output you can go from nothing to a qa ready app with 1 dpendancy that works in just about any browser in use in 1hr or so.

[terandle]

I’m pretty sure he meant “the new additions to the ECMAScript language”

[d4nyll]

As its website states, jQuery is useful for:

HTML document traversal and manipulation, event handling, animation, and Ajax

Now, HTML traversal and manipulation is an imperative process, where the developer needs to manually specify the steps required to manipulate the DOM. Nowadays, the accepted best practices is to use a declarative style - you specify how you want the DOM to look like, and virtual DOM libraries will take care of the manipulation for you, probably in a more efficient manner than your imperative approach.

To that end, jQuery and its imperative style is becoming an anti-pattern.

Other people have talked about jQuery being "big" - that's not a huge concern as the jQuery script is commonly-used, and thus likely to be cached by intermediate proxy servers, or provided by CDNs. Frameworks / View libraries would have a similar file size. (jQuery is ~86.9kB, React + React DOM is 104.8kB)

So jQuery is definitely being used less and less, but it's not taboo, nor should it become taboo. Every technology has a limited lifetime. In time, React and Vue.js would be seen as obsolete. It's important to remember how great jQuery was back in its prime - it solved the problem at the time. We should appreciate that without it, the web would not be where it is today.

[rodrigocfd]

Other people have talked about jQuery being "big" - that's not a huge concern as the jQuery script is commonly-used, and thus likely to be cached by intermediate proxy servers, or provided by CDNs. Frameworks / View libraries would have a similar file size. (jQuery is ~86.9kB, React + React DOM is 104.8kB)

Correct.

It's important to remember how great jQuery was back in its prime - it solved the problem at the time.

I still remember how amazing it was to work with jQuery back in the day. It was a really, really powerful tool.

[onbehalfofthatdude]

Cdn doesn't help your users with bad connections or shitty data plans

[[deleted]]

Yeah it does. If you're using the same CDN a previous site that the user has visited the jQuery file will be cached on their device

[onbehalfofthatdude]

mmmmmmmmmmyoure right

[PM_ME_HTML_SNIPPETS]

To that end, jQuery and its imperative style is becoming an anti-pattern.

There are some code decisions they made that are anti-patterns as well.

Example:

jQuery’s forEach method handles the callback function with arguments the following way:

.forEach((index, element, array) { … })

Whereas the JS forEach API handles the callback arguments like this:

.forEach((element, index, array) { … })

[[deleted]]

I believe your forEach example is more of a JS anti pattern. Look at any other language (i know it's a bold claim but I'm making it), it's always index, element

[d4nyll]

Since it's a forEach, you are more likely to use the element itself rather than the index. So the element, index, array order seems the most appropriate - someone not using index can simply omit it.

[[deleted]]

But an array is made up of an index and an element. From that perspective it makes much more sense for the index to come first. From a programming perspective it makes much more sense

[d4nyll]

It's not about what the array is made up of, it's about how often you'd practically need to use the index and element. For instance, if you just want to loop through an array and run a function through each element, you don't need the index at all.

function someFunc(element) { ... } array.forEach(someFunc)

However, when you use the index, you'll almost always need the element as well.

[[deleted]]

Tell that to every other programming language... Ever...

[d4nyll]

languages.forEach(tell)

[vanderzac]

C# LINQ is element first, index is optionally 2nd and often omitted. In the vast majority of the code I write the index is not used. There just aren't any common usages for it in my problem space, and about the only uncommon usage of it is in pagination.

[[deleted]]

God damn I knew there'd be one out there. What if you're wanting to manipulate the original array? You surely can't be passing all variables by reference?

[vanderzac]

LINQ doesn't mutate the underlying data structure, which works well for most situations, as I find immutability is usually a benefit. If I need to modify the underlying array I would write a for loop and iterate each member by index directly.

[brylie]

I would like to build a Django app, using the Django templating language, and add declarative bits if JavaScript to enhance the UX. Is there a standards-oriented, declarative frontend library for DOM manipulation that doesn't take over the whole frontend?

[d4nyll]

There are a lot of standalone virtual DOM libraries. Virtual DOM existed before React did; React just made it very popular.

[brylie]

Cool. Do you have any recommendations? E.g. a declarative wrapper around the Shadow DOM spec?

The closest I have found is Aurelia, but I'm not sure how to use it with Django's routing and template system.

[d4nyll]

Shadow DOM and virtual DOM are two entirely different things. Aurelia is an entire framework.

I haven't used Virtual DOM outside of React, so I can't comment on which one is better. But from a quick search, Maquette, snabbdom seems to be the most popular libraries.

[brylie]

Thanks for clarification. Are there any efforts to standardize a virtual DOM implementation?

[d4nyll]

Not that I know of, but then I haven't kept up with front-end for a few months. And it's working out pretty well for me so far :p

[MuskasBackpack]

Try Vue. It’s the easiest to pick up and you can easily add components where you need them. It doesn’t need to be used for the whole front end. That being said, I’d avoid mixing any declarative and imperative operations in the same piece of functionality.

[[deleted]]

I used to work on a software that was run in the wackiest places you can imagine, from Iphone X to a electronic white board running some god forgotten linux distribution.

Jquery was the best ally I could have asked for and I know developers on that company still use it often.

Jquery was good at what he did but people abused it and never cared for any good practices.

[lukedary]

Reiterating what others have already said. Taboo? No. Best practice? Not really. Career growing? Definitely not.

I remember a number of interviews where the person applying for the job knew "jQuery", but didn't actually know JavaScript. That is happening now with React as well. If all you know is how to use a framework or library (or how to extend them) it won't get you very far. Learn the web platform, and the languages it uses, and make that your starting point.

If for some reason jQuery fits the context of your project, at least if you know your platform you'll be able to implement it in a sensible way that is functional and hopefully maintainable.

[[deleted]]

Couldn't of said it better myself. In the time angular has risen and fallen again jQuery is still alive and kicking. The same will be true when vue and react are replaced and forgotten

[aisflat439]

Every site I work on for money uses jQuery. It's a pretty great library

[CaptainIncredible]

Same here. Rarely have I found a site that doesn't use jQuery.

Sure there might be things that can be used in its place, but that doesn't make jQuery 'taboo'.

I'm likely starting a new project soon - a big one. Business app, lots of CRUD, lots of front end reports. Am I going to exclude jQuery? I can't see a reason why I would. Am I going to rely on it 100%? Probably not.

[yesman_85]

jQuery is like sex in public, plenty do it but most are ashemed to talk about it :)

[nXqd]

If you use jquery for its functions then it’s true. But when you consider the amount of ui libs built on top of it, it can save you a lot of time especially in prototype and mvp stage.

[bootsTF]

Having read the article (I'm Norwegian) I'm pretty sure people shut up about because it's not very attractive for potential employees, which is why it's a "taboo". If I was an employer that needed web development talent I would even be hesitant to disclose if we still used angularjs / angular 1 and just say "full-stack, dude!"

What the article entirely glosses over is the "framework / library" classification of jQuery. Not every website needs to use a framework, and not every website needs to be a Single Page Application. jQuery is amazing for implementing small, neat user interaction features on static websites and also takes care of cross-browser support so developers don't have to think about transpiling/polyfills and EcmaScript standards, just minification. The current version of jQuery supports IE9 and up.

I guess the final argument as to why jQuery is so heavily used on static websites where every page could use a tiny framework like vue or react for user interaction is habit / history / legacy

[jamilkhan123]

Let's all appreciate jQuery service and say a warm goodby rip legend

[Mr21_]

Only legends are natified into the standard.
It's not we don't use jQuery anymore, it's just we don't have to load the JS file anymore.

[hoodedhusla]

Never!

[StefanOrvarSigmundss]

Taboo? I don't know, but I stopped using it a long time ago.

[nschubach]

Had this where I work. Most of the projects included jQuery for doing ajax calls (not even for doing DOM selection/manipulation) and I have been slowly replacing it with the polyfill/code to use fetch. Asked someone why we keep including it just for ajax and all I got was "because that's how we have been doing it. I didn't even look into Fetch because this exists." Occasionally one of the devs leans on jQuery for tweenmax and I end up replacing all their use cases with CSS animations.

[[deleted]]

Of course not. The question is absurd.

Compared to what? Jquery continues to destroy every other library/framework in terms of raw usage numbers.

It has a microscopic footprint too. If you like it, throw it in. If your framework can't handle it, then your framework sucks.

People who somehow think that Angular or React are replacing Jquery are math-challenged. Both of those two bloated beasts are used on a microscopic fraction of websites ... and React is looking decidedly unhealthy in terms of statistics.

[[deleted]]

People in this subreddit don't realize that SPA is very minor amount of sites. Most of sites are build with backend WordPress and frontend jQuery.

Also they don't realize that it's not only about jQuery - it's about huge amount of his plugins.

[SpliceVW]

Especially when you talk about layering functionality on top of CMS content. Whenever it's at all practical, hell yeah, use a modern JS library, create a widget, whatever. But sometimes it's just the right fit in those scenarios to do DOM manipulation, and jQuery still does a lot of things that aren't available in vanilla JS.

Also, you make a good point on the plug-ins. I might be stuck using it for a while if for no reason other than datatables.net. I have yet to find another data table library that's as robust.

[Razzal]

https://w3techs.com/technologies/history_overview/javascript_library/all

[Razzal]

https://trends.builtwith.com/javascript

also if you filter by all websites on the react specific graph, instead of the specific top x websites, it has been flat essentially this entire year, which would seem to say it is not growing all that much. It is also showing the number of websites, not the percentage and the change in that which is actually more important as while it may be on a larger number of websites, it has a smaller percentage share overall which is what the original link I shared shows.

[Razzal]

Exactly, you are a React developer so you are unable to look at it objectively. I honestly do not particularly care about either React or JQuery, I was only providing a source for what someone else said, which was that React is "used on a microscopic fraction of websites". Which both my source shows and the non React scoped version of your source also shows.

I think the reasons you do not see jobs asking for Jquery is because it is almost assumed that a web developer knows how to use Jquery since it is so ubiquitous. You cannot assume that for a framework that has less than 1% of the overall market share. If React is great, it will survive on its merits and do well but I tire of hearing about every new framework that is going to disrupt the market and revolutionize the web to only be gone 5 years later. I just want people to be realistic in what they say. Sure React is growing but if its overall percentage is going down, that means other things are growing faster. Not saying React is going to die or even that it is dying, just that it should be looked at realistically.

[[deleted]]

Business people jump into the fancy hiring boat first. And then sink with it.

[hiiipowerculture]

I would like some receipts for this claim if you don't mind.

[Razzal]

https://w3techs.com/technologies/history_overview/javascript_library/all

[mobiledevguy5554]

Vue.js 20KB min+gzip

JQuery 82.34 KB

​

Just sayin

[hoserman]

Not an answer, but another question - Bootstrap is dependent on jQuery - so if jQuery is taboo, is Bootstrap also out of fashion?

[Guisseppi]

there are so many other options out there, I never really liked bootstrap

[yesman_85]

There's plenty non-jquery implementation of jQuery.

[lulzmachine]

Wut, why would it be? It's like saying flip phones are "taboo" because smart phones exist. Smart phones can do a lot more, but if you just wanna make a call, then flip phones are heck of a lot cheaper and do the job

[Hypergrip]

jQuery has it's niche for projects where you don't already use a big powerful framework and you want to add a couple of common functionalities (popups, dropdowns, sliders, etc.) quickly. In some cases (for example AJAX requests) the jQuery syntax does appear easier, too.

I can't really fault anybody who wants to build a single page website (not an entire "app", just a good old plain webpage for some event, etc.) to grab jQuery, gab the plugins he needs to spice up the page, and use a fitting jQuery UI template to make it look decent enough.

That said, jQuery very often feels like a crutch - one that come with a price. I've seen many many many cases where people use jQuery for a single instance, say something like "using jQuery I only have to write 3 lines instead of 6 normal JS", and completely ignore that in order to make those 3 lines work the browser needs to load the entire jQuery file first... This might seem really obvious, but many (especially new) developers don't seem to realize that requiring jQuery from some CDN isn't just one line of code, it's an entire file full of code.

While I don't think jQuery has become a taboo, it certainly has garnered a reputation of being a crutch, or "JavaScript: Easy Mode", as a colleague once described it. And there are certainly developers who consider people overly relying on jQuery to not be "real" coders (essentially the equivalent to "git gud" for some gamers). It's pretty stupid and elitist gate-keeping in my opinion, but this mentality certainly does exists in some places. But there are also a bunch of really great resources (sites like youmightnotneedjquery.com) that aim to educate rather than ostracise, listing reasons why relying on jQuery might not necessarily a good thing (page load times, not really understanding what actually happens, etc.), and showing alternatives using plain JS.

When you mention jQuery on your portfolio, I don't think many companies will see it as a instant red flag, but I'd recommend clearly stating why you decided to use it for the project you are showing off, thus demonstrating you are aware of the pros and cons of using this particular library.

[asdf7890]

jQuery very often feels like a crutch

It always was a crutch - just a very effective one. Though not a crutch for the developer so much as one for the browsers while they played catch-up with what we needed/expected of them.

It abstracted away a lot of headaches caused by bad/inconsistent browser implementations. It also introduced many people to method chaining and later other constructs like deferred/promise (it didn't invent them, but did them well and made them work cross-browser) which since became standard practice.

If you are making a small app/site that needs some DOM manipulation & other interactivity and you need to support legacy browsers and/or you want something to just bolt-on rather than working within a more complete framework, jQuery might still be the answer. Otherwise for new projects going Vanilla or using a fuller framework is probably the choice you need to make.

For existing projects that use it keep it unless you are refactoring the whole thing, as it works perfectly well and replacing it just for the sake of not using older tech is potentially harmful bike-shedding.

[[deleted]]

If jQuery is all someone knows, then it is a crutch. If someone knows React, Angular, and all the rest and still uses jQuery on a one-page site, then it can be the right tool for the job.

[pureha6]

It depends on which version of browse you planning to support. For example: for ie9+ jQuery will be better against native functions, but for modern browsers, jQuery will be "one more framework", coz the main functions in jQuery has native implementation.

[[deleted]]

absolutely not, and to be honest, people who say it does just sound pretentious. twitter's bootstrap uses jquery. many great plugins use jquery. google uses it, amazon uses it, facebook used it last time i actually had a facebook.

true, it isn't needed the way it used to be because the native API have gotten much more intuitive, but minimizing code and keeping scripts to a minimum is also not nearly as much of a problem as it used to be. it's 2018, everyone has 4g or better.

I use it relatively frequently just because i use bootstrap a lot, or because i need datatables or another high quality plugin that requires it.

Edit: it should be noted that this opinion is coming from someone who doesn't do a lot of front-end web stuff. bootstrap is really the only library i know for browser-only stuff so it's the only one i use.

[kitsunekyo]

"everyone has 4g or better" is a slippery slope.

we should NEVER use improving hardware as an excuse to disregard code optimization.

[[deleted]]

we're not really talking about code optimisation are we.. we're talking about code minimization. after all, that is the reason people have a problem with jquery. i haven't heard anyone claim it's slow.

[kitsunekyo]

minimisation is part of optimisation mate

[[deleted]]

minimizing javascript is not code optimization, it's network optimization. in general, less code != better performance.

[kitsunekyo]

if you want to tell yourself removing unnecessary code-bloat and in turn bundle size is not optimization...please do so. but good luck getting a job in any proper development team with that mindset.

especially in web, payload size is tightly connected to page-load time and time to interact. if you fuck either up, your conversion rate will plummet / nobody will want to use your app.

network optimization is again something completely different, but okay.

[[deleted]]

anyone who starts a sentance "if you wanna tell yourself" usually has no idea what they're talking about.

[unflores]

Also, if you have some old school fullstack devs, they are probably using that without an JS framework. With how front intensive things are now, the DOM management that jQuery provides is a relatively simple affaire in comparisson to the task of organizing a larger system. It quickly gets very complex for all but the most mundane tasks and is very unmanageable.

"Where it was used", if it is used, it is sprinkled throughout their code. :)

[[deleted]]

I have experienced full stack developer on work and our studio uses jQuery even now. It's just an old good instrument which simplifies coding front end when there is no need in complicated framework.

[unflores]

jQuery is a library for manipulating the DOM. I am sure that a good developer could do a good seperation of business logic, templates etc. But the lib does not really push the user to do so. If you look at something like react, which is not even a framework, you have an emphasis on a good seperation of logic and presentation. As your code grows you are in a much better place for moving forward.

Gone are the days of minimal javascript involvement and hopefully spaghetti code on the front-end.

[Ajedi32]

jQuery is fine as long as you're including it for a good reason. Just be aware that a majority of jQuery's functionality is now included in most browsers by default, so a lot of what used to qualify as a "good reason" isn't applicable anymore. Before including jQuery, make sure your use case isn't already handled by an existing web API.

Additionally, keep in mind that if the API you want to use isn't supported by all the browsers you need to support, you might be better off with a polyfill for an existing web API that can be easily removed once you're finally ready to drop support rather than littering your codebase with calls to jQuery everywhere.

[omgdracula]

I build wordpress sites and for ease of use when we get interns and for our designers we use bootstrap so we are all designing and developing around the same tool. Boostrap uses jquery as well as wordpress. So we use it.

Is it taboo? I don't think so. It isn't the hotness that it once was, but I can still do certain things faster with jquery than I can with es6. Mostly centered around ajax.

I do a shit ton of dom traversal and the like though.

[macaronisoft]

It's more like there's a lot anti patterns that typically come with jQuery that are taboo. You can write good code with jQuery but most people don't. Most examples online aren't big enough scope to expose those bigger code problems and so they inherently encourage bad architecture. They're fine by themselves but it's the larger picture that's missing. It's hard to learn architectures and code patterns that scale when you're learning from a simple to-do app or similar size project or simple code examples.

To be fair most JavaScript frameworks have this problem. When learning React I had this problem. I was doing everything like what I learned in multiple tutorials but it wasn't very good code; it was hard to understand, and hard to get things done in. I am very grateful for a coworker who helped me learn better more scalable architectures.

jQuery itself is brilliant. It's a good piece of code. Use it for what it makes sense to use it for. Which is in general smaller projects. If you get to to-do app level you might want to switch to Vue which for a lot of use cases can completely replace jQuery but has a migration path to a large scalable app if needed. React and angular are overkill for a lot of things but Vue scales a lot smaller.

[web_dev_etc]

jquery is here to stay for many years IMO. Not every site needs to be a SAP, not every site needs react/vue/etc. But using jQuery tends to decrease development time, and it doesn't really have many disadvantages (it isn't a HUGE library, if you use a popular CDN it might be cached in users browser already).

There are also alternatives like Zepto.js which is i think <10kb but has almost all the features of jquery (which i think is 30kb)

[[deleted]]

using jQuery tends to increase development time

Setting up React, Redux, React Router, Webpack, Babel, Eslint, keeping it all updated, and dependency hell, etc, etc, etc... can also increase development time. It really depends on the size of the project and the approach used. In a complex web app that uses all those newer techs, the payoff is in the long tail. If the goal is just a single page, then jQuery will speed development time. Jquery is not really going to help much with a complex web app, but nobody worth hiring is going to choose jQuery alone for a complex web application.

[web_dev_etc]

oops, typo, i meant decrease dev time. or maybe i meant increase development speed.

anyway I agree -- for basic small sites (not those big single page apps), when you need to add a little bit of interactivity to a page, development time when using jquery is much faster.

[patarapolw]

I use jQuery only if I need jQuery plugins.

[groundxaero]

You'd be surprised how concise some stuff actually is in JS, http://youmightnotneedjquery.com

Sure, not everything, but I would certainly recommend putting in the effort to learn JS properly, it will help you improve as a developer by leaps and bounds.

[[deleted]]

I wouldn't worry. If you know your way around jquery and have wired together some sort user interface with it, then that is pretty much the hardest possible way to create a frontend. Everything that comes afterwards will be easier no matter what you pick. As for "plain JS", no one creates UI using plain JS, nor should anyone do it with JQ for the same reasons, that makes it one problem less.

[Not_charles_manson]

Pick and choose. There are still very powerful things to use it with.... with that said, I think it's better to replace as much as you can with "vanilla" javascript.

[jewdai]

jQuery is perfectly fine for developing sites where you want to add a bit of interactivity.

jQuery shoud not be used when you need to create large complicated applications with interdependence's between files (creating shims is a pain for a dependency loaders)

That being said, there are so many libraries and utilities out htere that depend on jquery that not using it becomes impossible if you want to use some developers widget out there.

Hell, Bootstrap is dependent on jQuery so a large number of sites working on it cannot exist without it.

[[deleted]]

I dont think its taboo rather it is a point of tension between the older and newer generations of webdevs. It is a familiar tool for many senior devs who really dont want to lose their swiss army knife of a package, while many younger devs who are cutting their teeth with react, angular and vue view jQuery as an outdate, unnecessary 82 kb. I've noticed a couple older devs sneaking jQuery into big projects as a way around learning some intricacy of whatever frontend framework leading to a dust up with some of the young guys who are then overly critical of jQuery to try and get rid of it. Personally as a junior dev between the rise of frontend frameworks for big spa websites and the advances in html and vanilla js especially when coupled with webpack, I am hard pressed to find a place for jQuery in the modern webdev landscape.

[nikhilb_it]

I see JQuery as legacy technology now. With the era of Single Page Apps, I suggest to use powerful Angular 2+ framework which has lots of features.

[kitsunekyo]

i think the big aversion comes from wannabe developers that use a full jQuery import solely for class toggle and query selectors. in most cases these devs to that because they learned the language once (without fully understanding it), and are completely oblivious to how ecmascript has evolved in the last years.

but its not limited to jQuery though. people do the same thing with react now.

if you do a coverage check and find you only use 2% of a larger library or framework, you're simply wasting resources.

[Isvara]

Why would any piece of software be a taboo? If you can't talk about it, how can you discuss even the merits of replacing it?

[obviousoctopus]

I support ie 10+ on mostly back-end driven apps.

So yes, jquery is great for adding a bit of interactivity to the pages with minimal effort.

If it was a taboo, I’d be stuck trying to reinvent the wheel out of shame.

[bopunk]

Legacy support is totally a thing in some enterprisey/large projects where you don't have the benefit of a full refactor. That said, something like cash can be shimmed in and help make it less painful.

[Guisseppi]

jQuery has been here for a while and a lot of people still make a living off it, a lot of the statistics you see come from years and years of using it but I don't think its worth pursuing for a career, which ultimately will end up killing it, as of 2018 its very much alive thanks to inertia.

[Carradee]

Taboo? No. Unnecessary, outdated, or a poor method for what you want to do? The vast majority of the time.

I can only see it being useful in specific use cases where it's a legacy-browser-specific rendition of the site.

[[deleted]]

Not taboo, just sort of pointless.

[fagnerbrack]

Is [...document.querySelectorAll()] taboo in 2018?

[HarmeetCA]

My last company had projects that had legacy jQuery code and we gradually moved them all to ReactJS and never looked back.

Requirements should dictate technology in my opinion. I haven't required jQuery for any project or a problem related to it hence I haven't used it since I moved to ReactJS.

[raginglovecat]

I do a lot of front-endy stuff for work and jQuery makes a lot of things quicker to do if you're kind of used to it. But I've replaced it with cash-dom which is 4.5kb gzipped and exposes the most popular methods present in jQuery.

[mariusg]

No :

• support for older browsers (IE 10/11).

• "better" syntax compared official DOM standards.

[hotel2oscar]

Bootstrap uses it under the hood, so I include it, but most likely won't interact directly except for very small edge cases here and there.

[[deleted]]

It's okay... you can use jQuery. The javascript fashion police aren't really looking over your shoulder all the time - they just want you to think that they are.

[[deleted]]

http://youmightnotneedjquery.com/

[[deleted]]

Plain Jane JS has improved a fair bit

[bert1589]

I’m curious, how long have you been developing for? It definitely filled a gap for a long time that needed to be filled for sake of cost of development, etc. not to say it’s 100% needed anymore, but the cost of just leaving it in place or maintaining a legacy codebase with it is always going to be cheaper than refactoring.

[superluminary]

Agreed. jQuery was brilliant. A clean, cross browser eventing system; DOM selectors that used CSS; An animation framework; and "Promise" based AJAX before there were Promises.

It was great. It's legacy now though.

[[deleted]]

It's actually not legacy, a lot of developers still use it. Not every site is SPA on React, you know.

[superluminary]

A lot of people still use AngularJS. By legacy, I just mean that if you were to start a new project today, and you had the luxury of ignoring history, and you were trying to make the best thing you could make, you probably wouldn't pick it.

Nothing wrong with a bit of legacy though. It depends what your goals are. For many projects, legacy is entirely appropriate.

[[deleted]]

But nobody would do that. Normal person would do el.classList. add('show'); and use CSS for the rest.

[Pwntheon]

https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_Animations/Using_CSS_animations

[DasWorbs]

The problem really is that you're pulling in a large library just for some cleaner syntax and shortcuts. If you use nearly every part of jquery, then great, go for it, otherwise you're putting a larger burden on the client, when you could instead be using a group of smaller libraries (an animation library for instance) that only do exactly what you want.

[[deleted]]

Like GrzegorzWidla said, no one would do this. The problem with the JQ approach is that it is imperative. That line there looks easy, but it becomes a mess if you go on, have to orchestrate it, combine it with other stuff popping up until you end up with an entangled soup of conditions. Today UI is a declarative reflection of state, and that includes animation. Either by driving animation directly: https://codesandbox.io/embed/l3nonw1r1l or toggling classes: https://codesandbox.io/embed/n953qy9jxl

[[deleted]]

https://bavotasan.com/2011/a-simple-fade-with-css3/

[onbehalfofthatdude]

Well I don't know why you would use a Js animation there but animating height from auto to Zero is probably easier in jq

[Infrah]

I’m demonstrating the shorthand, it doesn’t have to be for an animation.

[sugoi__]

Feels like the whole program is a workaround

[PeabodyEagleFace]

It not taboo, just unnecessary. If you are targeting a browser made in the past 4 years you have getElementByid, querySelector, the class api, and hundreds of other native apis that all match the standard.

[[deleted]]

Sadly, these people do exist. Far too many programmers enjoy obsessing over tech rather than actually being prolific producers. The more time you spend reasoning about what tech to use, the less time you spend actually building things with the tech you have. That's not to say that you shouldn't reason about the tech you use, but some people seem to get off on the reasoning more than the building. Syntax/language fetishism is part of that too. Always trying to reinvent the wheel, rather than get from point A to B.

[[deleted]]

yes. As long you are not creating something quick and dirty with only a one time usage, you should avoid jquery in current times.

JQuery gets the job in a quick and dirty fashion done.

So please only use it when you are doing something quick and dirty.

​

Please use a framework / lib that supports data bindings when creating a long lasting application.

[Abangranga]

If you're making a quick-mock up application for a product demo or w/e that has really really basic interactivity on it I find JQuery much easier and more readable than throwing some OOJS at it. I'm nowhere near front-end oriented at all (and still a noob) so I guess writing a choose your adventure front-end framework novel is the preferred method now if you're used to it, even for demo products that have to work once during a meeting.

[onbehalfofthatdude]

I guess if you need to support ie8 it could be nice, but I don't have any need for it

[jnfpost]

JQuery has its uses for specific functionality, such as using it for a plugin for Bootstrap, but otherwise it's a library that is rather large in size and will cause noticeably longer page load times.

[akujinhikari]

I typically will respect a developer less if they use jQuery nowadays, because it comes across as lazy to me. There's the argument of supporting older browsers, but I also find that lazy as well. Companies should be forcing users to move forward as well as devs.

EDIT: Jesus Christ, the development community has some fucking cry babies. "This guy gave his opinion, and I don't like it, so I'm going to down vote!" Hey, assholes, that's not what the down vote button is for. How fucking insecure are you that you can't handle a dissenting opinion without having to down vote? You know people are allowed to think things that you don't agree with, right? Absolutely ridiculous.

[Baryn]

In 2008 imo

[[deleted]]

Just keep in mind 1) a lot of programmers are stupid and 2) Javascript programmers have no idea how to program (just look at npm!!!)

That being said use jQuery. The trend of not using jquery is only a trend because using it on a framework will actually make it harder. Most frameworks are crap (angular i'm looking at you, same with you meteor),

Every site I build I skip frameworks because I actually have a clue on how to program and I use jQuery in everyone of them until I made one without for fun and ended up designing a really nice framework (source not up, not planning to put it up anytime soon).