I thought the biggest advantage of this library back in the day was css selector access of DOM nodes (back when we only had getElementById, getElementsByClassName, and getElementsByTagName). This has been rolled into the Javascript document api via document.querySelector, and document.querySelectorAll.
Also there are browser compatibility issues that jQuery solved but a lot of these are solved with smaller footprint libraries like lodash.
Also for me, along with I'm sure many others, keeping state within the DOM has fallen out of favor of more comprehensible state management inside of JS (like React Hooks, Redux...etc.)
What is the current use-case for jQuery? I'm curious from hearing it's current users answer this.
>…Javascript document api via document.querySelector, and document.querySelectorAll
The jQuery API is still (and probably aways will be) far superior to the native DOM (terser, composable, more expressive, etc).
>…smaller footprint libraries like lodash
jQuery is ≈30k gziped and most likely already cached from CDN.
>…has fallen out of favor of more comprehensible state management inside of JS (like React Hooks, Redux...etc.)
Managing state is hard. There shouldn't be much of it in any single view. IMO, React doesn't bring much to the table in this regard while adding a lot of complexity and heft. Vue is a bit better, but still, I'd much rather use jQuery if given the choice.
If you're building something like Spotify/Slack, I can maybe see the need for virtual DOMs, etc. If you're sprinkling interactivity to your webpage, which is arguably what most of the web should be, jQuery is probably as good as it will ever get.
> jQuery is ≈30k gziped and most likely already cached from CDN.
This part isn't so true in reality anymore, due to revised browser caching systems[1]. Doesn't mean you shouldn't use jQuery, just that part of the benefits of a centralized CDN are no longer a factor and it's a lot more sensible to self-host.
Right you are. But jQuery is around the same size as Vue, and that's the lean alternative to React. So the “jQuery is bloat” argument still doesn't make much sense.
A single retina hero banner is larger than most JavaScript libraries/frameworks.
One thing that doesn't help jquery's case is that it and its plugin ecosystem isn't modular, making it impossible to trim the code size below the minified size via dead code elimination or even es6 partial imports. It would be nice to see more fluent DOM apis like jquery, but having 1st class support for es6 modules so you can import only the functionality you need in your final bundle
The reality was you where almost never getting a cached version anyway. There are so many versions of jQuery in use over so many CDNs that the chance of a user already having the exact version and cdn that you use is almost nothing.
We looked into this several years ago and found that most of our users had likely encountered and cached the several most popular versions on CDNs. There was a power law distribution in effect.
In the last five years, the release schedule has slowed, so there was a convergence onto fewer versions in the wild, but at the same time, users were visiting fewer sites that used CDN versions (and fewer sites in general.)
Thanks for the article. I was just telling someone that jQuery was most likely already in the browser cache so don’t worry about it. Guess I need to go back and say I was wrong...
There's still a huge benefit to using CDNs, despite caching being dead - they are almost certainly faster then whatever is hosting your site. If your site is relatively light and has a lot of traffic (especially international), pulling libs from a CDN could significantly increase the amount of requests you can process on the same server hardware and regardless of that, decrease the load latency for your users.
We used to use google.com for hosting jquery for us. Then when google.com started being blocked by the great firewall our site broke (it was pretty popular in China). It took a while to find out what went wrong, especially with the language barrier.
Back then we decided it's just better to self host. Less things can go wrong.
> IMO, React doesn't bring much to the table in this regard while adding a lot of complexity and heft.
Strongly disagree with this. In any complex web application with a lot of components, specially ones where a lot of fixed components can live for a while, React is definitely a massive improvement over vanilla JS or something like Backbone which allows wild west.
Imagine state coming from sockets, rest APIs etc with updates being either pull or push. A user might do an action which changes the state in some other component, keeping track of the components gets hard if the state is distributed. Also, centrally managed state with things like Redux allows for good caching of API data which can make a SPA considerably fast.
While I love plain HTML pages which need little or no JS, a lot of applications are better as SPAs.
I'm exactly arguing against this Webpack, Typescript, React, etc approach to web development. I'm more productive in PHP + jQuery, a lot due to familiarity, of course, but I'm also a huge believer in a simple stack.
If you've 20+ mutually dependent inputs, maybe you need a better UI, not a complex state management framework.
If your browser is ultimately executing an untyped crazy dynamic language, is it worth trying to shoehorn types into it, only to later transpile it back?
Not to mention JSX.
It all seems so crazy to me, but this ship has long sailed.
> It all seems so crazy to me, but this ship has long sailed.
Nope. And it's why Svelte is something that I've been hard adopting because it looks the closest to old-school JS/CSS/HTML while still bringing some of the same capabilities over that I love from React and VueJS. It also runs without a VDOM or a constantly running event loop - both things are incredibly attractive to me.
Although it's not a perfect solution (nothing is) I would strongly suggest you checking into Svelte as it looks more like traditional web development vs. highly complex Webpack + TS + React + eslint + Babel etc etc-based development.
The ship hasn't sailed. Your instincts to be weary of such a complex, constantly re-invented toolchain to get traditional development tasks accomplished are a natural response to the craziness that these tools bring to the table.
I really, really hate the JS toolchains like "Webpack + TS + React + eslint + Babel etc etc" that you mentioned.
I rather like Svelte.
But honesty requires that we recognize that Svelte also uses Webpack/Rollup + TS + Svelte etc etc.
I like the idea of Snowpack. But if A.svelte and B.svelte both use C.svelte, Snowpack has to do a lot of redundant work to provide A.js and B.js with Svelte.js and C.js all converted again and again from ts then baked into both A.js and B.js. That's a lot of server work and a lot of client work and a lot of network work.
So you still want a webpack or rollup or what have you to bundle and tree-shake and codesplit for production. I don't know why this irritates me more than running any of my other code through a compiler. But it always has.
I've been running Svelte with esbuild and it's incredible, and doesn't bring along all of the above overhead. I get to target modern browser stacks which is a huge plus that keeps a large amount of complexity out of my toolchain.
I saw the Svelte presentation a few years ago when it was released and my jaw hit the floor hard. That was some cool radical thinking. I haven't used it beyond playing with a few examples, so I can't really tell for sure if it holds up. Everything looks great on the demos.
Unfortunately it hasn't caught on, though it maybe be too early to call.
At Work, we‘re building web applications that need to be accessed by hundreds of editors with thousands of pages. Most of them share an essential bundle of components. Are you telling me a project that complicated can be built using just jquery?
I couldn‘t disagree more. It‘s a user portal managing thousands of different interactions and workflows, based on the users existing information. Most of them can be edited live with a content-management-system by an editor. These workflows are very hard to reason about with just jquery or nor js at all.
It can, sure, but having coding conventions is essential, which those frameworks/linters help to enforce.
But we've been doing projects with millions of pages way before React :)
Checkout Wikipedia, which, by the way, uses jQuery, of course. And PHP.
>Also, what‘s bad about typescript?
It tries to turn the very dynamic JavaScript into something it will never be and no amount of contortion can hide it. Unless it stops being a superset of JavaScript in the future, but I don't see that coming.
Wikipedia is a largely uniform, read-only, static experience. These days people want app-like experience on the front-end. Can‘t manage them with jquery.
The bit about typescript is true at runtime. However, Typescript is also good documentation for developers.
Do you need SPA for everything there? Because if server side rendering/logic is “allowed” with only a few interactive bits here and there written in jquery, than it can be absolutely done as that was/is the case a “few” years back.
I work on an app that is half react and half rails templates. Every time something has to change on one of the rails templates it becomes a process of explaining to the project manager that we can't easily make this change which would have been trivial elsewhere because this specific page is using server side rendering.
Its become such a large problem that we have scheduled in a task this year to remove all server side rendering from the app.
Server side rendering almost always means implementing the same feature twice, once on the server so it loads correct, and then a second time on the frontend so it changes as the user modifies it.
I work on an app that is half react and half rails templates. Every time something has to change on one of the rails templates it becomes a process of explaining to the project manager that we can't easily make this change which would have been trivial elsewhere because this specific page is using server side rendering.
Its become such a large obstetrical that we have scheduled in a task this year to remove all server side rendering from the app.
For when I’ve wanted to sprinkle interactivity, this is what I’ve turned to lately. It’s quite brilliant, and more declarative than most solutions.
But React is still necessary in my day to day job, as our web application is incredibly complicated in terms of feature set and customisation. They both have a place.
I'm on the same boat, super productive with php/twig/jquery.
But recently my boss gave my a side project without any specific requirements, 10 charts and 2-3 tables with their associated crud.
I made everything with react + php, and oh my god that site is super fast. It's eye opening!
For me, ExtJS redefined what's possible on the web a full decade before React/Angular & co, and it's sad that Sencha is now part of a heartless corporate graveyard.
Native apps definitely have advantage in some areas.
But web apps give the ability to ship an app to more platforms and not be restricted by app store border control. Spotify had an Ubuntu client which never worked well, but as their web app improved I got almost the same experience as I would have on OS X or Windows web app. This gives equal chance to other platforms and to app developers as well as they don't have to play by rules like 30% cut.
As long as we can ensure web browsers can be kept open on major platforms(the only exception right now is iOS), it gives more freedom and choice to non platform developers. I would be really happy if PWA support in web browsers keeps improving going forward and need for dedicated apps gets eliminated for most things.
"The jQuery API is still (and probably aways will be) far superior to the native DOM"
The jQuery API really is so well done. I stopped using jQuery, but implemented a simple script (jSugar.js) that exposes many basic jQuery things but is really just a wrapper for native DOM operations. It only operates on individual DOM nodes. Any looping should be done using your JS loop of choice (forEach, for loop, which, etc).
The script started out really small. I've slowly added more and more as I need more functionality for some projects.
> The jQuery API really is so well done. I stopped using jQuery, but implemented a simple script (jSugar.js) that exposes many basic jQuery things but is really just a wrapper for native DOM operations.
Self-hosting is no longer the performance drain it used to be now that HTTP/2 is a thing, as soon as the browser parses the page, the JS file is only 1 RTT away. Using a CDN for a single asset like jQuery requires a DNS lookup, TCP connection and TLS negotiation - that's 3 RTTs plus unknown latency from the user's resolver before the HTTP request is even sent. The performance difference in the single request scenario is likely negligible and the benefits of not relying on a 3rd party can outweigh the latency savings.
I used to write a lot of JQuery, and I've switched to Vue three years ago. Occasionally I have to go back and write more JQuery, and it makes my head hurt.
edit: why the dowvotes? are we not allowed to share our experiences now?
I know we're not supposed to discuss voting but people downvoting someone simply because that person said something disagreeable, yet still within the rules of Hacker News, is becoming a serious problem in my opinion. I'd like it just fine we get rid of downvotes altogether.
Trying to write any kind of complex interactivity with JQuery event handlers is a serious pain in the butt, and it's so hard to go back and read.
I did the same as you; moved on to Vue and haven't looked back. My frontend code is so much cleaner and easier to debug. I've built a large library of components, so often times adding a new page only takes a couple hours re-using those instead of writing a bunch of new JQuery from scratch.
JQuery is great when I need to make (non-contentful) changes to the DOM. But I refuse to use it for managing the state of my app or putting content in UI components.
Smaller footprint in my mind doesn't refer to download size which is minimal in either case but the footprint or impact on a project. IMO It is way harder to move off of jquery once it has been fully utilized throughout the project than to swap a single function to/from lodash once a core API has a better way of handling it. Using JQuery demands you buy into the whole ecosystem whereas Lodash is modular.
Also as others have mentioned caches are individually isolated for each domain now to prevent tracking/data leaks.
Firefox and Safari use partitioned caches, and Chrome is following with the feature behind an experiment flag for now. The argument that it's probably cached from a CDN is just about dead.
Just last month I decided to toss a quite arbitrary `=>` in my javascript (I still write `function (args) { code }`), and shipped it. Immediately got a _TON_ of user complaints.
Turns out, we sent a link in a newsletter, and most folks were reading those in Outlook, and that evidently just opens links internally, and that is still IE11. We don't ordinarily support IE11, but given that this is a specific info page shown there, for this we make an exception, and... => doesn't even work there.
Thus, another year goes by, and another year where I am 100% convinced it is totally not worth my time or effort to investigate newer options.
I'm honestly confused about why jQuery is considered 'bad'.
It's a dependency - yeah, 30k or so. This complaint (that it adds load time) boggles my mind; in this day and age of 10MB+ load pages, and the choice is to complain about a 30k library? Some javascript-library variant of the Total Perspective Vortex may be warranted to try to make sense of this.
A more interactive (as in, between server and browser), more stateful integrated model? Oh, yeah, totally, I can see that, but that 'formula' surely isn't the go-to strategy for every web page out there, right? Most of the pages I write work perfectly well via a 'server generates data, server throws it through a template and sends it to browser, client downloads jquery and some javascript for that page which adds interactive elements', and wouldn't be any 'nicer' if it was a much more javascript-native fully state-shared amalgamation. When I do need that live-updating stateful interaction model, sure, don't need jQuery. But that 30k is the least of my worries if that happens.
It's not that simple. It used to have a more capable renderer, they rolled it back to the Word one (no animated GIFs!) and have since upgraded again. So Outlook 2007-2016 is really crappy, versions before and after that, a bit less so.
Your use of the word "still" is a little misleading. IE _was_ the default email rendering engine until 2007 when Microsoft made the inexplicable decision to move to Word 2007 instead.
My theory is still that it was about using Word as a component to write replies. However, if they delayed the HTML->Word conversion to that point, everyone would complain to MS "Reply is broken!"
By using Word as a viewer the email is broken right on delivery and users now complain "The email you sent me is broken!"
jQuery's strength is the CSS selector based approach, where CSS, HTML and JS all "speak the same language", but it also its greatest weakness, your JS code gets too tightly coupled with the structure of the HTML, which makes it harder to refactor.
Good code management can solve this, like using a class or class like construct (e.g. jQuery plugin) to create independent components. But jQuery misses a lot of features to be a truly component based solution. jQuery UI widget is somewhat closer but still missing features like other component based solution has, e.g. no built in template library.
One of the most common things in JS is to attach listeners to HTML elements, however the most common way when doing so in jQuery is that you have a bunch of selectors and then some listener code, but that type of statements is not self explanatory, you have no function name to describe what it is doing or any other context. You see all these registrations of event listeners scattered across the project. What do they do? Are they in use? Hard to tell because searching your source code for a CSS selector is very difficult. That is why jQuery based projects usually have tons of leftover code from the last refactor, no one dares to touch it.
Many component based libraries out there lets you register a method name on the HTML element directly. Much better. If you can't find the method/function name referenced in your code, you can delete it.
It is true that you can add event listeners inline on your HTML element, but that is not how jQeury is usually written, because it is selector based.
I do think in some cases SPA make sense, but in many other cases just using a bit of jQuery/vanilla js to add a bit of interaction is enough. Server side rendering is way easier to do and is often faster to load for the client.
> When you just want to add a small bit of interaction to a mostly-static site, jQuery can help.
For very small amounts, perhaps, but honestly, even then I think it has limitations. As an anecdote, about six months ago, I needed to add a couple of dynamic forms to a static site. The forms were a simple contact us, and a mailing list sign up form, and only needed to handle the states of Open->Submitting->Thanks|Failed->Open, while preventing double submissions, etc.
I wrote the first one in jQuery (site was already using it due to the theming), and making sure handled all the various edge cases, and fixing one bug didn't cause another was far harder and time consuming than it should be.
Out of frustration, I wrote the other form in VueJS, and hacked the whole form in about an hour or two. My take away was that anything involving state in jQuery can get overly complicated very quickly.
Vanilla has always been able to do what jQuery can, otherwise jQuery wouldn't exist. It all depends on what your threshold for abstraction and verbosity is. That is going to depend on what you are doing and who you are.
Well, yes. Every JS library can be written in vanilla JS. The point of jQuery, React, etc. is to make it easier for the programmer to reason about what is going on while avoiding bugs.
> This has been rolled into the Javascript document api via document.querySelector, and document.querySelectorAll.
Have you actually compared the two methods in a real website? It's like saying why use Ruby when you can use Java. The Javascript document API is super verbose. No thanks.
Conversely, looking at how you do it through jQuery after seeing how it is in Javascript gives me the same reaction.
The fact that jQuery is usually assigned to the dollar sign definitely doesn't help, especially for beginners. The amount of questions I've answered that stemmed from a fundamental misunderstanding of how Javascript works, all because they learned jQuery instead of Javascript, is pretty significant.
I remember when I was in uni that the $() must've had a special meaning or something. I was pretty convinced that the $ was some tough mathematical operator or computer science concept that I didn't yet understand.
When I learned that it was simply a function invocation that returned a jQuery object so you could chain it, I was absolutely shocked about the simplicity of that statement.
Beginning developers sure like to project their cognitive insecurities onto programming. Or at least, I did :)
There's so much magic in programming that as a beginner, it's hard to know which magic you should dig deeper into, vs which is such a treacherous rabbit hole you're better off cargo culting.
It think this is true of many technical things. Statistics, sailing, car mechanics, photography... What I love about HN is it often gives clues as to which are the interesting rabbit holes.
I disagree. There's nothing about React, Vue or any other framework that I'm aware of that does anything similar to jQuery's dollar sign. The only magically-looking abstraction I can think of is JSX, and that's not only not mandatory but very obviously something that's off the curve. Unlike the dollar sign, which just looks like a special construct of the language.
I use the native APIs all the time, they are not that complicated or overly verbose. Easily memorized with practice IMHO. Also they are all extremely well documented on MDN.
Personally I use the native APIs because they aren't that hard to use (most of them, anyways) and I tend to be OCD about bundle sizes, but to each their own, I suppose.
Yeah, oh so many years ago I realized that I use just a small subset of jQuery, and just rewrote those bits, to avoid having to inject whole of jQuery into all pages that I browse (I had some global https?://* userscripts, so I was basically injecting jQuery into every single page and frame).
1.3kB compressed. Much better. :) And I avoided having to rewrite my extensions with platform APIs. That was before FF killed all the joy in writing userscripts for me, because I was no longer able to install and update them just by copying them to mozilla folder and had to invoke a lot of clicking ceremony to just get my 20 scripts or so from git into firefox past the webextension limitations on storage/access to mozilla folder.
Everyone will have different set of methods they use. Point of this is that if you need some method you can just add it in in 4-5 lines or remove one you don't need. So it's not the best fit for NPM. It's good fit for good old copy/paste into a project, if you're optimizing for size/memory use. :)
Your example does not work. querySelectorAll returns array and you can't write `array.classList.add("...")`, because array does not have that property. You need to iterate over that array. And that's exactly why jQuery is so much more convenient over native API: you can just treat collections of elements like an element and jQuery will iterate for you if necessary.
Another jQuery advantage is pseudo-selectors which don't exist in CSS.
There are plenty of convenient one-liners in jQuery which will expand to plenty of lines in native API. That said, with modern API and JS features it's not that bad either.
Yeah this gets me every time. You can .forEach a NodeList, but can't .map. I usually end up wrapping it in an array and calling map on it like [...theNodeList].map(...)
I think the fact that your very simple example (which is already longer and more complicated in your version) doesn't work shows the advantage of jQuery
There's a ton of other functions you need like element.addEventListener, insertAdjacentElement, XMLHttpRequest (when you need progress) etc. etc.
At that point you might as well save yourself and the person after you a major headache and just use jQuery whose API everybody knows.
Can't say I've ever heard that as an issue before..
Also I think the main point was there are so many better frameworks that manage the DOM better than jQuery as the need has evolved. I'll always have fond memories of jQuery but I don't see it as my go-to anymore, by a long shot.
I never understood why people say “We’ve solved your jQuery problem” by introducing getElementsByClassName() or even querySelector(). When I come back to my older app, $(“.my-class”) is still much nicer. jQuery gets out of the way, the class gets syntax-highlighted, and .focus() can’t create an NPE.
It's annoying that it returns a NodeList which doesn't have some common array-y methods and the like. While these aliases are certainly convenient, the jQuery semantics are much nicer and more intuitive IMO.
That would be very confusing for unsuspecting reader. Please use something different, I would suggest `qs` for `querySelector` and `qsa` for `querySelectorAll`.
This method is not so much for multi-dev codebases but for single devs working on their personal or low-tech sites and are having a hard time letting the $('some-selector') syntax go.
I help teach an introductory programming class to high school students. We still use jQuery to teach basic programming concepts, because it helps students add basic interactivity to a web page without a) the overhead of learning a full framework like React, or b) exposing them to the insanity of web APIs. Check out the curriculum if you're interested: https://github.com/itscodenation/curriculum-20-21
If you just want to add simple interactivity to a web page, jQuery provides a really nice API to do just that. Sure it's not the ideal thing to build a whole SPA on, but it has its place.
I've written a number of small apps for testing at my company with basically jquery+html+rust backend "web server" and it works quite well if you're not trying to get too fancy.
I think it’s like Lisp, or rather the reaction to Lisp.
In a world without jQuery every site / devshop uses their own little set of conventions and polyfills (analogous to macros) to add useful abstractions.
In isolation, these are neat. En masse though it means that each site has their own meta language (conventions) which have to be memorized before you can contribute to the code base. Languages like Ruby and Lisp suffer from this too: there are so many minute variants across code based that it becomes hard to truly view them as the same language. jQuery, in the context of JavaScript, is a standardisation track for all those little language additions.
Personally, I just use the native APIs. I don’t work with enough people across enough sites to benefit from standardisation. You will probably find a big overlap between proponents of jQuery and professionals — especially contractors — who work with many other people on many different codebases.
Or just people who have a poor memory, or who are not very self consistent. I love things like jquery (and Django and other opinionated frameworks) because it saves me the hassle of having bike shed trivial details for myself and then remember them later. And naming things is one of the two hard problems etc...
You wouldn’t believe in the amount of solid applications using jQuery out there. It’s still widely adopted, specially when you are maintaining legacy applications.
While I personally don’t use it in my day job anymore (Mostly React nowadays), I still know a good number of people that use jQuery in my local community.
Worth noting: Legacy doesn’t mean bad. Just software that sustained the tough test of time.
I'm trying to wean off of jQuery to reduce dependencies, but it makes me appreciate jQuery all the more. The native JS API is quite a bit more verbose and cumbersome to use, and my absolute biggest gripe with it is that it doesn't even build on modern JS features. It's not compatible with for...of, map, filter, find, etc, which seems really strange for a relatively recent vanilla JS API.
They cannot. If they do and remove the old getelementbyname, etc, then it will be breaking change.
If they just add $ notation, then there will be redundancy / inconsistency with existing api. Furthermore it will break / confuse apps which use jquery.
Then it's far easier to just include minified jquery into your apps when you want to use it, and you have more control about it's version, etc.
I'm not saying to use $, but the elegance/composability of jQuery could have been implemented as they updated the API. And deprecating getelementbyname etc could have been done over a long period.
It is literally the first thing I add to every personal project I build, and it's included with a lot of things I work with professionally. Jquery just makes life easier.
This. I can just prototype something so gosh darn quickly in jQuery and I'm so used to it by this point that between that and advancements in CSS it's incredibly awesome.
When I need a to write a small web service, I usually just grab a python micro-framework and do the work. Not much complexity and not a lot of setup required. When I need to do something more elaborate that needs structure because it will get extended over time, I will take my time to setup something like Django... but it would be too much unnecessary work do to that for small web services.
The same applies to front-end.
When I need a few quick HTML pages that need some quick DOM manipulation, I usually just grab jQuery and do what we have been doing for years. Whenever I know that something will get extended over time and needs structure, that is when I take the time to setup React/Redux and all the build scripts necessary to make it work.
Just personal preference, but I am sure I am not alone...
Yep. I still use it for side one-off projects here and there. For me, there's just something so convenient about being able to make a html page that you can drop in a quick CDN link for jquery and not have to worry about compiling, webpack, create-react-app etc. I'll still use React when something is a larger project with a ton of moving parts, but otherwise I stick with jquery.
As for why I'm not using the native DOM api's...I could, but haven't gotten around to learning that syntax since I'm very used to jquery (being specific, if I want to do things that are more complicated than selecting an element + changing its properties, the native API is more complicated). jquery is just a nice default.
I hear you. Personally I think learning the native APIs isn't so bad once you take the plunge. They are easily memorized with practice. Imagine not needing to go for that CDN link (or depending on some 3p for your website to work correctly)
Well, Wordpress and Drupal still uses jQuery, they auto load it by default and there is no reason not use at this point, unless you specifically building React or some other custom thing on top of either of them.
"What is the current use-case for jQuery? I'm curious from hearing it's current users answer this."
I still see it used for file upload/download, as the fetch api doesn't provide a reasonable way to show progress if the channel is using gzip or deflate. The ajax functionality is also still popular for a compact way to deal with different types of errors (app errors vs connectivity errors).
For me personally, it's partly familiarity and also still compatibility. I know that if I use jQuery, then (for the parts it covers) I don't have to search caniuse.com.
But then, I'm not a front-end web developer, so I optimize for different type of projects.
There were other things like the "Ajax" (remember that word?) API, but that one's also been matched by a native API (fetch())
> keeping state within the DOM has fallen out of favor of more comprehensible state management inside of JS
Not everything needs a whole reactive templating library. There's absolutely still a usecase for mostly-static sites to do imperative DOM manipulation.
The usecase for jQuery itself these days is dodgier, since as you point out most of its big features are native now. It should still help with browser compatibility (not necessary for modern-ish browsers, but many sites don't want to limit themselves to modern-ish browsers), its APIs are arguably still a little nicer in some places, and it does have a significant ecosystem of plugins so there's probably some value in having that stuff integrate together. But personally I would have a hard time justifying a whole library just for slightly nicer APIs unless I was doing something significantly complicated, and at that point I would just use React.
jQuery is like WordPress. There may be other more streamlined, purpose-built solutions out there, and they all have their uses, but sometimes ease of setup is the thing you're optimizing for, sexiness be damned.
When you have a vast, mature ecosystem and a decade and a half of community knowledge to draw upon, even the most obscure use cases tend to have a precedent somewhere. Being able to jump right to a StackOverflow answer to exactly what you're trying to do is, in my opinion, a highly underrated feature of legacy web technology.
> This has been rolled into the Javascript document api via document.querySelector, and document.querySelectorAll.
The official replacements for the stuff jQuery does tend to be verbose and non-orthogonal, as compared to the much more unified and consistent API of jQuery.
I write a lot of B2B apps that have tabular data views. For all of its quirks, DataTables (https://datatables.net) does a great job and with the right plugins offers all the features my customers expect (re-ordering/resizing columns, column based search, fixed headers, fixed columns, item selection, etc.) DataTables requires jQuery.
Lots of other vanilla JS table plugins out there but I can't find one with all of those features that work when they are all on.
I dropped it a long time ago for similar reasons to only using selectors. It was not worth adding the extra request and execution time for what was really now a vanilla feature.
>"Also for me, along with I'm sure many others, keeping state within the DOM has fallen out of favor of more comprehensible state management inside of JS (like React Hooks, Redux"
In my opinion using React / Redux combo for state management is a poor choice. So to each their own. The arguments like: everyone else including my cat does that do not make really it any better in my eyes.
> there are rowser compatibility issues that jQuery solved
Current browser support[1] isn't really _that_ great. I know it used to be, but I'm not sure that's a legit selling point these days. Not that it's bad, but I hear that argument come up a lot.
I still use it all the time because document.querySelector is nowhere nearly as good as $, and it's extremely verbose to create a nested tree of nodes in vanilla JS.
I've really forgetten how to do things without jQuery. If anyone knows a framework that is less verbose than jQuery please tell me!
I would not start a greenfield project based on it today, sure, but it is used by a truly staggering amount of sites today, so having it get updates in the form of security fixes and some additional functionality benefits a large part of the web.
I use it extensively to maintaining our apps ui which has coded with old fashioned Backbone, Underscore and Jquery. our UI is working and we do not see need to re-engineer/refactor it to go to newer frameworks just for the sake of it.
WordPress ships with it, so using jQuery often doesn't require any extra footprint. I still prefer vanilla calls for admin-only code, but jQuery has better compatibility for user-facing pages.
I use it primarily because it provides an easy interface for ancestor, descendant utilities. But I'm also not doing this in a FT setting, just for side projects.
There are still a ton of legacy sites that use it. New development? Don't know, but the last 2 companies I worked for had massive systems written in JQuery.
Still use it because the code base is still full of it and don’t want to have multiple patterns. Plus the plugins are really useful and the syntax is nice.
You get a girl by going places where girls congregate at a similar or higher percentage to guys. Took me a while to figure that out... Anyway, I understand sarcasm, too.
Super cool. I really like that you can also reply using this service to each individual inbox. Like a universal inbox but not married to any specific client/app. Maybe suggest making that a little more easier to learn on your marketing homepage.
For your current users, are you seeing them use this more like the demo gym owner video or for other use cases? Thanks
So many cases. Some are using this on hundreds of sub-domains. I hope to launch SMTP and regex support soon. Then... it has final form, power level over 9000.
Their price completely covers every user signed up at any scale. If they lose all but 1 customer, that customer can keep the lights with just their subscription.
The other is that company has such a large warchest it'd be impossible to run out of money.
I would not start this business if I could not keep it going. Period. Even beyond my lifetime. I keep things simple - when I started I had so many struggles, and wish something like this existed. I have contingency plans in place if something happens. My philosophy is outlined in the documentation for Lad.
Yeah, Google Translate via the npm package "mandarin" I made @ https://www.npmjs.com/package/mandarin. I planned to hire curators to go through the JSON files and clean it up - though I'm incredibly surprised that open source contributors have come forward (sometimes for their first time doing a PR) to submit fixes to locales. I give them free service for several years for their help.
jQuery has the kindest, most warm hearted, whimsical release notes.
During the pandemic last year:
> We hope you’re staying healthy and safe while so many of us are stuck at home. With a virus ravaging the planet, we realize that jQuery may not be a high priority for you or the sites you manage. When you do have a moment, we recommend that you review this new version and upgrade.
Some fun:
> I’ve never gotten to say this on a jQuery release, but May the 4th be with you! A short time ago in a galaxy exactly like this one, we released jQuery 3.5.0.
Release notes are also very well thought out and their philosophy is to "move slowly and not break things". I admire that. They go to great extent to provide help about how to deal with breaking changes. Ends with a section thanking the contributors.
> their philosophy is to "move slowly and not break things"
The world needs more of this. I'm tired of seeing tooltips that don't disappear and thus get in the way and long GC pauses on Firefox, because nobody bothered to test their bloated React app in Firefox.
Speaking of nice developers, Reaper DAW developers are giving away temp license and in return only asks the user to wear mask. Warmed my heart to see it.
The one I have meant was "jQuery in action", at the time that left a bigger impact as far learning is concerned. The jQuery team had promises and other things long before they became part of the standard API, he explains how they made it work.
However, secrets of a js ninja is very good as well, touches newer things like generators and es6, es7 features.
Frontend has been a pain in the ass for me for quite a while as someone trying to learn frontend development.
jQuery's concise syntax beats everyone, I hope Javascript can adapt it someday, truly a KISS design gem. However I do need write code to do data-binding myself, which is important for interactivity.
Vuejs can be used to replace jQuery however it does not have the simple syntax, you do get data-binding for free without using its full-blown SPA framework. However you do need master a lot more concepts comparing to jQuery.
React/Angular are both overkill for 90% use cases, unless you're doing a serious SPA that is.
For me it's between jQuery and Vuejs these days, I learn both, one reason I worry about jQuery is that it's losing some steam and the development is not very active. Still I'm excited about this new release.
I remember the first time I used VueJS after being a long time JQuery developer. It was incredible how much power VueJS and similar frameworks put in your hand using such simple concepts. Not having to add event listeners to everything and manually re triggering things is revolutionary.
I was building dynamic UIs with ease that would have been massive and bug prone jobs in jquery.
do you use the full spa framework, or just use vuejs like jquery(use script to include it in each page)? whenever you have to do vuejs full SPA framework it comes with quite some concepts which takes (a lot) time to digest and stay up to date.
For that project I just imported it on to a single page to build one particularly complex (for me) feature. It was a little news letter builder which generated a JSON string for the config and saves it to the db. The backend could then use that config to send emails.
I was getting nowhere with jQuery. My final solution in vue was tiny compared to just setting up all the event listeners on the first try.
> one reason I worry about jQuery is that it's losing some steam and the development is not very active
It’s super mature which I like. Compare to Vue 3 which is now GA yet lots of related components like Vuetify are quarters behind in supporting v3. Lots of exciting features for sure but also lots of churn.
jQuery taught me how to write JavaScript frameworks. John Resig, the founder of jQuery, wrote a book called "Secrets of the JavaScript Ninja" was back then really a mindbender.
Function.prototype.toString() is really the craziest thing I know to date regarding JS. Heavily used in earlier versions of jQuery according to the book.
I once used it for a proof of concept for computer worm type message on a sort of message board. Used to re-generate the source code to be added to new messages.
My guess is a slimmed-down API with most or all support for older browsers removed, perhaps something similar to Zepto.
There is still something to be said for the usability of jQuery's API for direct DOM manipulation, as opposed to the more verbose API offered by the DOM itself.
I love modern reactive frameworks, but for DOM manipulation the jQuery-style API is great.
Some problems are much easier to solve working directly with the DOM (eg: drag and drop). The problem is that you either have control over the DOM, or let someone else do it (React, Vue, etc).
> The problem is that you either have control over the DOM, or let someone else do it (React, Vue, etc).
Someone needs to implement a (higher or lower) level of DOM access than what's offered by the current API -- something that would allow React's virtual DOM to be the actual DOM, whether that means allowing direct API access to the underlying tree data structure, or simply implementing the internal React VDOM API on top of the current DOM API.
I think jQuery is amazing, but one thing that I've found over the years is that the real killer for it was CSS animations becoming simpler to use and more widespread in terms of support.
The final thing I used to reach for jQuery for was animation support, but that need is by and large gone now. AJAX/JSONP is good there, but to be honest it's not something that needs a wrapper these days.
Glad to see the library is still updated, though - for sites that might not have a budget to upgrade, knowing it's still got support must be nice.
CSS animations are a pain-inducing non-starter for thousands of recurring use cases.
Example: Using Javascript to SHOW a modal, but then relying applying addClass('animate') using CSS animations to transition that modal (eg: bottom of screen to center, while fading in) are nearly impossible without tons of hackery. The animations do not render.
YES this 1000X - I love React and choose to use it regularly and willingly. I am forced to use Angular quite a bit for my day job. While both of these libraries have their place not everything needs to be a single page app. Using server side rendered pages and sprinkling a little JS to add some DOM scripting and dynamic UX should not require adding React or Angular. It many cases using jQuery is good enough.
I no longer use jQuery nowadays due to React/Stimulus but one nice thing about jQuery is ability search for an element in a DOM note and append html. You can do it with raw JavaScript but jQuery API is light years ahead.
A lot of people throw shade on jQuery, but it’s extremely powerful and versatile. I’ve built entire apps with just jQuery, Foundation, and POJO classes (and other smaller libraries as needed sprinkled in). This stack is certainly not appropriate for all apps, but for small projects it’s far easier to manage than the overkill that is React or Angular. Sure, you don’t get generators and built-in spec testing or other Enterprise-friendly goodies, but for simple apps that use a REST API, jQuery sure as hell provides a nice set of tools. And while modern browsers support the query selector methods that sort mimic jQuery, this starts to get awfully tedious if you want to do complex DOM manipulation and you’ll find yourself writing functions that start to look a lot like jQuery. Why reinvent the wheel in order to save a few kb of space and pride yourself on having a “100% jQuery-free app!” when modern apps already load much larger libraries or minify and package the entire app’s code?
I started studying web development 2 years ago and I never feel the need to reach for jQuery. From the very beginning I wanted to get a solid knowledge of front end technologies without libraries or frameworks. After working for some time in this field I do feel the need for stuff like Bootstrap, Tailwind, Vue/React, but not jQuery.
What's is selling point considering that DOM manipulation and HTTP requests has improved over the years in vanilla JS?
I've read through most of the comments and I see a lot of:
I'm used to jQuery syntax
$ is shorter than document.querySelector
jQuery provides better support for older browsers
First two aren't really meaningful to me, and for the last one, I'd say if you care about browser support you are probably compiling your code anyway.
I'm not familiar with using jQuery but I work with people that use it and I've realized it promotes some bad practices like:
Repeated DOM node selection due to the ease of use of $(selector)
Manipulation of CSS that should be done in CSS
jQuery is not JavaScript. Some people use it as a crutch and it shows
So my main question, if someone is comfortable with vanilla JS, does it make any sense learning jQuery?
If you’ve been doing web dev for 2 years you can pick up jQuery in an evening. Go do it. You might never need it but learning is fun and understanding what jQuery is instead of hearing about it’s flaws on HN is a good idea.
I sometimes look at react, and these modern frameworks and wish they had a same nice API as jQuery. I still profoundly remember how much simple it was compared to Prototype.js, and how simple it was to do a zebra stripes on table. I am still looking for that next piece of revolutionary simple library that will bring the joy of jQuery with modern concepts and simplicity.
I super love jQuery. The proliferation of SPA is super unfortunate, maybe one day the pendulum will swing back to server side HTML with lighter JS for progressive enhancements.
jQuery solved (and solves) a lot of browser inconsistencies (fewer now than before) and I guess a lot of older codebases still rely on it, so I am glad to see it is still moving forward. However, jQuery has a built in problem in modern web development, as the DOM-functions that now makes it obsolete, as in it does not solve the more complex problem of state management and scoping of components. For some sprinkling on top of server side rendered web pages I guess it still has some value if you need to cater for older web browsers, but for those who build applications that handles state and components for the current setup of browsers it is not needed in your toolbox any more when bootstrapping new projects. However, it helped us getting to a point where we could rely on solid libraries and focus on building better user experiences. I am glad it still gets updated but will probably not write "jQuery-code" anymore in my professional life.
It’s definitely on the way to becoming legacy tech, but jQuery was a great library back in the day, like, history book great.
It played a big part in the Web 2.0 days, could be argued that if it wasn’t for jQuery we wouldn’t have the modern web at all, or if so, it would be a lot worse.
Are CSS Frameworks like Bootstrap still using jquery? Otherwise I don't see the use case of it now that we have so many JS frameworks plus Javascript as a language has changed so much.
I think it is still widely adopted in CMSs like Drupal and Wordpress and they have a big market share. Jquery will not die soon even if it is not the first choice for starting a new project. It's been years since the last time I used it.
Absolutely. Starting most new projects with something like React/Vue is complete overkill and jquery makes adding small incremental JS functionality to your app a breeze.
I can't speak for React, but I found adding VueJS was perfect for adding JS functionality incrementally to a section of a site. See my other comment on this thread on using it to create a dynamic contact form to an otherwise static site.
jQuery is also an amazing educational tool for teaching people to program in steps, learning the native DOM methods and then being introduced to jQuery has been really fun to see light bulbs going off for new students.
I thought the biggest advantage of this library back in the day was css selector access of DOM nodes (back when we only had getElementById, getElementsByClassName, and getElementsByTagName). This has been rolled into the Javascript document api via document.querySelector, and document.querySelectorAll.
Also there are browser compatibility issues that jQuery solved but a lot of these are solved with smaller footprint libraries like lodash.
Also for me, along with I'm sure many others, keeping state within the DOM has fallen out of favor of more comprehensible state management inside of JS (like React Hooks, Redux...etc.)
What is the current use-case for jQuery? I'm curious from hearing it's current users answer this.