Every time I use jQuery after helping my friends battle Reactive monsters, I am so eternally grateful that I have such a productive and satisfying tool at my disposal. It requires zero bike-shedding and almost every imaginable edge-case is solved before I start. If it ends up sucking, it's because I made it suck.
Just to abuse metaphors, I believe that jQuery is a "bicycle for the mind" in the true Steve Jobs sense. If you don't love it, please knock yourself out or try an edgier SPA. Spend all of your free time learning how Hooks just made everything you were excited about obsolete.
The pool is warm and the weather is lovely, friends.
I find this comment fascinating. I actually love your passion for the lib - I think any tool that makes a person feel productive is a positive thing. But it also makes me realize just how diverse the front end ecosystem is. Since moving to more reactive, state based frameworks I haven't even thought about DOM manipulation in so long - that to see people discussing the merits of one system over another is pretty wild.
>Since moving to more reactive, state based frameworks I haven't even thought about DOM manipulation in so long - that to see people discussing the merits of one system over another is pretty wild.
Not all websites are SPAs or need fancy interactivity, some are rendered server side and jQuery does simple manipulations,
Also there are many good UI components for jQuery and I seen the big frameworks wrapping 6this components.
I assume people who don't think about DOM manipulation and the performance toll it takes are responsible for how slow the web is today and, what's even worse, how that waste of CPU has been pushed from the server to the client.
I assume the web is slow today due to packing a couple megabytes of libraries, and adware / tracking malware, into each page load. More so than two milliseconds of jank in how you constructed that SELECT pulldown.
I don't believe that contemporary webdev's main problem is how we construct a SPA. I think it's the assumption that everything needs to be a SPA.
There's downsides with every approach though. While taking a "render HTML and manipulate DOM" approach falls down hard when the DOM mutations become frequent or complicated enough that they take a performance toll, the alternative most commonly peddled, "ship JSON and let the client render everything" has increased in massively increased JS bundle sizes and horrendous initial load performance on many sites.
I suppose there's the alternative of "ship HTML and forget about Javascript for the most part", but very, very few people are following that nowadays, and besides which, JQuery supports a "Javascript not required" progressive enhancement model far far more than most other front-end frameworks.
I wrote a spa at my last job using jQuery. It rendered page fragments on a php backend, detached the current fragment, saved it, then appended the new fragment. If a fragment was already downloaded it would hydrate by ajaxing some json.
It was extra work and sometimes brittle but it was also my first "big" web project. Even though it didn't use all the cool new libs and build tools I still learned a lot from it.
That's brilliant! Have you had the opportunity to play with Turbolinks 5? It sounds like there will be some crossover with what you have already done, but if you're intellectually curious, you might pick up some good tricks, too.
TL5 just happens to pair beautifully with a tiny library called Stimulus, which would be YAF except that it's a) by the same team as TL5 and b) that team is also behind Rails, so there's some claim to legitimate best practices.
Can you please point me to some evidence of how bad DOM manipulation actually is ? Its worked just fine for all my professional use-cases so far. Enlighten me!
While I respect that this comment is an expression of your lived experience (after all, I used the word believe so this is fair game) I am compelled to point out that when you say "of what you would need with jQuery", what you really mean is "what I would need with jQuery".
You know how there's ~3 kinds of Excel users? You have your formatted rows and columns types, people like me that can use SUM(), call APIs and know what pivot tables are... and then there are those ninjas that can implement ray-traced dungeon renderers in a cell. https://www.youtube.com/watch?v=iCeOEQVUWZ0
I'm not exactly claiming Carmack-level jQuery proficiency, but comments like yours make me wonder (optimistically) whether you've forgotten all of the amazingly useful things that jQuery can do. Ajax, selectors and CSS transitions are the Nickelback of creative possibility.
As a final note, I am excited that things which once required jQuery are now being solved by the browser and the evolving EcmaScript standard. Ideally, jQuery continues to get smaller and smaller. However, it's intellectually dishonest to claim that all of the non-jQuery techniques are as ergonomic to implement as jQuery idioms. Proof:
I do really like fetch and async/await in general, and working in React has taught me lots of cool tricks to bring back to my real projects. I think everyone should try to build something real with React, just to understand how lucky they are to have the option not to use it.
youmightnotneedjquery.com is often held up as an example of why jQuery is obsolete, but if you look at the examples a bit more closely, you'll notice problems.
I spent all of five minutes glancing through the example list and noticed their `replaceWith` doesn't provide the functionality that jQuery offers -- it doesn't take into account event handlers bound to DOM elements. Also, their `extend` does a shallow merge, not a deep merge. Furthermore, the YMNNJ examples are often far more verbose and less expressive than the jQuery examples.
I don't particularly understand the rush to rip jQuery out of everything. It seems like a lot of people are doing it just because it's the trending thing to do. There are some things that jQuery does very well -- even in today's world where modern web dev is dominated by SPA components.
I'm the maintainer of https://github.com/elliotnb/observable-slim and https://github.com/elliotnb/nimbly -- the latter of which is an SPA component framework whose core requires jQuery. It uses jQuery to update DOM nodes with `replaceWith`, merge deeply nested objects with `extend`, among other things. Nimbly components are not required to use jQuery -- only the framework core uses it. Aside from the eliminating the extra 69KB footprint from adding jQuery slim min, I don't see any reason to rush to rip jQuery out of the Nimbly core. On the contrary, using jQuery helped us get the framework built faster and helped us keep the code expressive and easy-to-follow.
> youmightnotneedjquery.com is often held up as an example of why jQuery is obsolete, but if you look at the examples a bit more closely, you'll notice problems.
Surely that's their entire point? They provide the link as evidence that
> it's intellectually dishonest to claim that all of the non-jQuery techniques are as ergonomic to implement as jQuery idioms
> Surely that's their entire point? They provide the link as evidence that.
I'm not following your point. The point of YMNNJ is that you can use their examples to quickly replace bits of jQuery code. I've identified that a few of their examples (possibly more) are not equivalent replacements -- demonstrating that jQuery is indeed needed.
Your second quote doesn't come from me. It's misleading the way you quoted it in response to my post.
> I'm not following your point. The point of YMNNJ is that you can use their examples to quickly replace bits of jQuery code.
That doesn't mean that's how the person you responded to uses it.
> Your second quote doesn't come from me.
The second quote comes from the comment you responded to, I'm pointing out that its author specifically used YMNNJ to demonstrate that not using jquery can be significantly less convenient and ergonomic than using it.
I took masklinn's comment to mean that your point in sharing the youmightnotneedjquery.com was to show evidence of problems using vanilla JS instead of jQuery, not that that's the point of the site existing.
The site has plenty of examples of vanilla requiring writing multiple lines compared to one jQuery line, which I took to be your point regarding "ergonomics." EB66 seems more focused on a subtler point regarding the site, that their vanilla examples don't do everything the jQuery version does.
This is a bit disingenuous without actual numbers: jQuery minified is 83 KiB, 30 KiB transferred with gzip. The new slim version knocks that down to 70 and 24 KiB, respectively.
For almost any website that has actual use-cases for it, it's not going to be the data bottleneck. Plus most websites have way more severe bloat elsewhere to worry about
This gets posted a lot but there are so many versions of jquery on so many different cdns that very rarely is it the case. I saw some research on it and it was in the single digit percentage of times.
> I'm not exactly claiming Carmack-level jQuery proficiency, but comments like yours make me wonder (optimistically) whether you've forgotten all of the amazingly useful things that jQuery can do. Ajax, selectors and CSS transitions are the Nickelback of creative possibility.
It's been several years since I last used jQuery, but what are those other useful things that are hard using Vanilla.js? (Legitimate question, not being sarcastic here)
Great question! I hope that I can give a good answer. When I stopped to think about how to answer, I found myself challenged to compose my thoughts because I have to unpack specific features from the context I use them in; the context frequently informs the way I use various patterns and jQ functions together to achieve an end result.
However, there are some jQuery functions that I use all of the time:
$.closest() and less frequently, $.parentsUntil()
Not just $.siblings() and $.next()/$.prev(), but $.nextAll() and $.nextUntil()
$.getJSON()
$.toggleClass()
Deep extend via $.extend(true, {}, objA, objB)
jQuery's custom event triggering is A+
$.delay()
$.end()
Consider this a solid starting point for further exploration.
Great answer likewise! Some of those are really cool indeed!
Deep copy/deep extend is a must in every programming language ever. I have no idea why 90% of the environments I ever programmed with make it so damn hard to deep copy data. In javascript it is kind of comical. [1]
Traversal utilities like closest/parentsUntil/nextAll/nextUntil is something I miss in most standard libraries. No for DOM manipulation, but for traversing lists and such. Until/while idioms are par for course in imperative contexts but I miss them in functional programming contexts. Not that they're that hard to implement with a couple lines :)
Delay is further proof that the jQuery API design is nothing short of amazing. I wish more APIs were like that. The only thing that comes close to me, albeit in a completely different domain, is LINQ.
I had no idea about End. That's point-free programming black magic. [2] Love it.
Building on what you said, I would love to see more powerful node traversal functions make their way into every environment I work in. It's something worth making a push on. Moving around a tree can be a joy, and it unlocks many solution domains that might not cross your mind if you're not thinking about them.
One traversal mechanism I'd love to see but I've never seen implemented coherently is... given my relationship to ancestor X, iterate through all my antecedent peers under x. This would make processing some kinds of structured data far simpler.
End really is one of those hats-off bits of magic, and it's one of the first things that come to mind when any of the frothing haters pen statements that preclude anything good coming from method chaining. It'd be even better if ES supported Ruby-style send syntax eg. array.map(&:to_s). And yes, I put it last because I was going for clever.
You know what drives me even more crazy than ES' lack of deep copy/extend? How is it possible that ({k: 1} === {k: 1}) is false? I find this to be maddening. Thank goodness for lodash.
> One traversal mechanism I'd love to see but I've never seen implemented coherently is... given my relationship to ancestor X, iterate through all my antecedent peers under x. This would make processing some kinds of structured data far simpler.
That sounds really simple to achieve with with a (lazy) function that returns a list containing all ancestors of a tree, and then a "until" or "up to" function that returns everything from that list until a certain condition is met.
Those are things that should be included alongside Map and Reduce :)
> How is it possible that ({k: 1} === {k: 1}) is false? I find this to be maddening. Thank goodness for lodash.
Oh, I strongly agree. And lodash should be the standard library of the language. Not only of Javascript, but most languages out there.
> End really is one of those hats-off bits of magic, and it's one of the first things that come to mind when any of the frothing haters pen statements that preclude anything good coming from method chaining.
About End (and point free style in general), I understand why people might dislike it, but then again, I think it comes down to familiarity. After ten years of exposure to LINQ, Haskell, underscore/lodash and FP in general I also find it super hard to follow code that uses for/do/while in overly clever ways (my own C code comes to mind).
I think I find it easier to see code as a "graph" rather than assigning something to a temporary variable, and that's what End allows me to.
I don't get it. Why would you not want this? And when you're used to it working, how could missing so common and logical not be maddening? When does the maddening kick in... before or after I have to install lodash for comparing objects?
Are you busting me on semantics? Do I literally have to check into a mental health care facility after not being able to natively compare simple ES objects to satisfy you?
I guess it's not maddening to me because I was used to this from C. Two pointers which resolve to the same value and type will still not be equal in an equality expression if they reference different addresses. But to me it's good that {k: 1} !== {k: 1}, because if this evaluated to true I would have no way of determining an object's true identity, which is often more relevant than the value it contains.
You make a (several) good points. I primarily work in Ruby and it's true that comparing a potentially complex object like a hash based on whether it serializes identically essentially means that you're comparing by value instead of reference. Depending on what you're doing, that's either really convenient or a nightmare. Ruby seems well adjusted to tasks where accessing a hash as a value is a feature and not a bug.
And for those times where you're interested in comparing instances of a hash, every instance of an object has an object_id getter:
a = {k: 1}
b = {k: 1}
a == b # true
a.object_id == b.object_id # false
Of course, this is a lot of typing, so Matz also gave us:
a.equal? b # false
Ultimately, this is what I love about the diversity of a pluralist language ecosystem. The polyglots will always win.
Don't forget some of the higher-level utilities like $.Deferred (which imho is still easier to use than promises) and $.Callbacks . Those two were always criminally underrated and underused imho.
I feel as though that if you need regex selectors, there is something wrong with the structure of your HTML.
Can you tell me which use case you would need to do this? I don't think there is anything wrong with this functionality, but it seems like if you needed it, that your HTML is needlessly complex.
I'm not the parent poster, and I'm not sure if these are the regex selectors they had in mind, but nonetheless.
An example use case: the person writing the HTML ≠ the person writing the selectors. Browser extensions like Stylus, for example. If the HTML author did not bother to add a specific class you need, you have to resort to ugly methods.
In fact, this is a scenario I deal with regularly. I have a Chrome extension for video download sites that scans the current page for metadata (title, performers, release date, etc.) and decorates the download links with `download="…"` attributes, so that I can download a file with a properly formatted filename. I manually adapt this extension to every site I need, and quite often I need things like `a[href^=/model/]` † to distinguish links to performers from other links to get their text content. It's clearly not a situation the site authors worry about, and that's fine as long as I have a way to do this myself.
† This particular selector can be done without jQuery if you don't care about backcompat. In browser extensions, you usually don't. But it's still an answer to your question about when such selectors are needed.
---
Since I'm talking about this, that same browser extension can demonstrate some other complications brought on by React and CSS-in-JS:
1. CSS-in-JS turns class names into unreliable gobbledygook, so extracting metadata means more regex selectors and abominable DOM hierarchy selectors (`section>div>div:first-child>div` because nobody bothers with semantic <h2> or even .title anymore).
2. React makes DOM elements vanish and reappear instead of just hiding them, so that `download="…"` attribute I want to add has to go through a MutationObserver instead of just running once on page load.
Your point #2 is one of the main reasons React is far-less creatively flexible than DOM manipulation. I'm surprised that this doesn't come up far more often.
The examples in the site already look quite outdated. We now have `fetch()`, `.attachEvent` is all but dead, plus all the ES6 features like arrow functions, destructuring, spread... and reactive UI means you'll rarely, if ever, need to call DOM tree modifying methods yourself.
The best part, "Reactive UI" being a paradigm, you have many other options besides React+JSX, for example https://github.com/jorgebucaran/hyperapp. At a fraction of the size of jQuery, which one is the 'monster'?
I can't speak for the others, but when I talk about Reactive monsters, I am talking about needless complexity - both in setup and in usage.
I believe that the relative size of one library vs another (even outside of the reality of caching CDNs) is an unhelpful distraction from the bigger discussion around who should consider using which tools for which jobs, when.
The applications I'm working on are typically for people with usable broadband connections. If you build your site/app correctly, the pictures that are embedded in your content are often bigger than any of the libraries you could choose. However, it's the general responsiveness of your experience that people will judge your speed or "nativeness" by.
I do agree that the examples on the site are somewhat outdated, but the fact remains that there are a lot of nice things to say about that dang left column, with its predictable, intuitive and impressively terse invocations.
I worked for ~8 years using jQuery. It was an immense step forward in the early years, but these days I find the complexity of imperative code and juggling state from multiple sources a lot worse than the ‘complexity’ of a 100-line diff & patch algorithm that lets me simply redraw the whole world from state. And in the event I need to manipulate the DOM, the native APIs are now good enough, a couple extra lines are worth not having an extra dependency - jQuery’s (and zepto and so on) utility is diminished.
It might be the case that how I use javascript is Nickelback-level coding; however, it pays the bills and to be frank, I don't miss using jQuery. I don't need my day job to validate my creativity.
I don't use React/Vue/Flavor-of-the-month UI library for my day job; however I don't use jQuery either.
I am not trying to shit on what can be accomplished with it; however, I debug a lot of code that adds it in where ES6/vanilla javascript does the same thing. I guess I prefer verbose javascript over using jQuery... not trying to knock on it, but it might be worth looking at other tools for the long term.
Edit: To be clear, I am not advocating to rip out jQuery fron existing apps. In a lot of cases, jQuery and jQuery plugins are helpful, but most of the code that I am paid to debug ends up being rewritten in vanilla js because I feel comfortable using that. I stopped using jQuery a while back because I opted to use a UI library a while back and worked hard to avoid jQuery ever since even though I don't use UI libraries at my current job.
Use whatever tool floats your boat and doesn't piss off the rest of your team. It's possible to ship spaghetti code in any flavor you want. I happen to (currently) work on things where the level of complexity of the UI is simple enough to use vanilla JS and not need a UI framework.
And what do you do about accessibility? Working with jQuery makes sure you have a baseline default that's always accessible. Also, jQuery is not backed by a terrible organization with a questionable record, even evil intent.
I love jQuery and will switch for vanilla JS only when it's okay to do so, like when support on old browsers isn't that much of a priority.
I use vanilla js for WCAG compliance; however, I only need to focus on IE11+ for most work because TLS 1.2 support is mandatory for the sites I support.
I don't understand why this comment was down-voted; this is a completely reasonable perspective. Plus, it reminds me that I'm lucky in the projects I typically get to work on, that they still allow for creative coding in many moments.
If coding is your day job and you work on corporate applications, it's likely that you're on a team big enough to start discussing how things like React might be necessary and valuable.
If you're building a linear CRUD application, you probably still don't need Reactive frameworks, but you're in the right ballpark to be talking about it. Otherwise, history will not be kind.
> Ajax, selectors and CSS transitions are the Nickelback of creative possibility.
And the jQuery Ajax methods are super-handy. POST with the fetch API is long-winded; while the jQuery promise-handling sucks, it was enough to make me use $.post() in the current project.
I've gotten pretty far with Mithril and polyfills (mainly for JSON support) targetting IE7.
If you're worried about backwards compatibility, then jQuery is the right tool; however, if less than 2% of your users are using an unsupported version of Internet Explorer, I would spend more time flashing a message instructing these users to upgrade.
I migrated from jQuery to React, never going back and I wouldn't use jQuery for a new project.
I agree that jQuery is ok for simple things, however I'd probably prefer something more light weight, like Bliss.js instead. jQuery's 30kb bundle size does make pages load slightly slightly slower on mobile phones, in comparison to Bliss (about 3kb last time I checked).
Migrate from jQuery to React. You make it sound trivial but it is essentially a complete new way of developing the front-end. Not necessarily a SPA, but certainly a front-end with more interactivity than a few buttons and dialogs.
In my experience React front-ends are more driven by separate data retrieved and stored at the server, while jQuery front-ends are mostly server-side rendered and jQuery is used for some degree of dynamic flexibility.
Have you considered authoring code without either of those tools? Then you can independently add in the appropriate tool to adjust for efficiency. Thinking in terms of the tooling first is premature optimization. Focus on the end product first, and the correct tooling (if any) will be clear.
I honestly don't think that dev workflow is even possible with most frameworks. It's not like you can take an existing website and add interactivity or extend the existing interactivity with React.
The current landscape of web tools is pretty much that you have to call your shot from the beginning or suffer a rewrite later.
That is certainly true once a framework is chosen, but before that you can prototype in many directions and extends in pieces. Extending a site to use a framework is not all or nothing.
jQuery and SPAs don't have to be mutually exclusive.
At my work, we've been building SPAs with jQuery long before Angular or React even existed. More recently, we've built our own JavaScript SPA framework whose components can be written with vanilla JS or jQuery. Most of us prefer to use jQuery for our components because the syntax is often more expressive and concise than vanilla JS.
Another vote for React here. I wouldn’t let jQuery anywhere near an app I was responsibility for. It’s a great and really well thought out tool for doing things that I absolutely never ever want to do in any non-trivial app I work on.
You seem to assume that jquery isn’t already cached by the client. Given the widespread usage, while granted may be shrinking, the “bundle” may never be downloaded again; Assuming that’s the case, the download is moot, and more favorable, verses the SPA with some cache busting mechanism (that may release once per week or once per hour).
This is very rarely true, and often cited. Too many sources to get reasonable gains for cached jQuery. There was a good article breaking down exactly why this is a few years back. Mobile but someone else can probably share.
As cited elsewhere in this thread, jQuery is in use on >75% of the web. The only way you don't have jQuery cached is if you don't regularly use the web.
Other sites' use of jQuery only helps if everyone is loading the same URL, which they're not. There are too many versions in too many places. I think I know the article they were thinking of, where someone tested how common it was for different sites to load libraries from the same place, it was not great.
jQuery.com doesn't mention linking to it, only downloading, and references to their CDN and other CDNs is at the bottom of their Download page. They focus on the download option probably because people generally want to have more control of their sites and would rather have "their" jQuery file be loaded from the same CDN as their site's other assets.
Actually I did not have in mind the download time, but the time required to parse and JIT compile the jQuery code.
This was, I don't remember, something like 30 or 100 ms, for jQuery — on my core i7 laptop (according to Chrome Dev Tools). Might mean ... maybe 200 ms? half a second? on an a few years mobile phone.
> almost every imaginable edge-case is solved before I start
I think you are comparing apples and oranges. Jquery is absolutely awesome for automating parts of your pages, and/or adding substantial interactivity.
If you are building an actual SPA, as in application (think gmail and the like) you wouldn't want to use jquery.
The only thing I don’t like about jQuery is that commands fail silently when a selector finds zero results.
More often we expect something to happen, and the cases where the results might be empty are obvious enough that adding a “fail silently” flag in those cases wouldn’t be a hardship.
Biggest category of bugs I had to help people with, aside from performance regressions from abusing reflow.
As hardships go, I’ve had worse with other frameworks. But if I could g9 back in time or if I were trying to make a workalike...
> The only thing I don’t like about jQuery is that commands fail silently when a selector finds zero results.
The set-operatic approach of jquery is one I absolutely love about it, though it does lead to unforeseen behaviours in edge cases (sometimes performance concerns running code on nothing or on way more than expected) it's leads to extremely convenient and fluent code, much more so than the explicit iterations of the normal DOM.
> More often we expect something to happen, and the cases where the results might be empty are obvious enough that adding a “fail silently” flag in those cases wouldn’t be a hardship.
Extending jquery to assert a lower bound (and even an upper bound as well) wouldn't be a hardship either.
A few years before I encountered jQuery, I found an experimental programming language that tried to do away with the distinction between variables that contained 0-1 values and those that contain 0-n. In this language, all operations were set operations. When your data model changed from 1:1 to 1:n (classic example - user:address is probably the concept I’ve seen mis-modeled the most often).
So when I saw jQuery for the first time, I’d already been primed for this concept. I’m a little surprised it’s been used so infrequently.
How is using jQuery more satisfying and productive than using something like React?
You spend 10 times more time writing so much more code having to make the UI 'react' to the changes that you wish to see.
With React/Vue/Angular it's just a case of adding a conditional.
With jQuery you've gotta do something like
jQuery('.this').hide();
jQuery('.that').show();
jQuery('.thisotherthing').show();
Gets really confusing, hard to test and hard to maintain.
Then when you want to do things with fancy selects and dynamic option choices and all that good stuff it just gets even more unruly.
With modern JS frameworks you declare a state and your UI reflects your state. Rather than with jQuery having to manage both the state and the UI all at the same time.
I'm forced to use nothing but jQuery at work so I'm quite competent with it so it's not from lack of experience. It provides nothing but pain and misery.
Eh. "10 times" is certainly possible, but it's not inevitable. Maybe the strongest load bearing statement in the GP is "If it ends up sucking, it's because I made it suck."
> With jQuery you've gotta do something like jQuery('.this').hide();
Sure, at some level, you're going to have define a relationship between your data and some display element (`jQuery('.this')` above), mechanisms for managing presence & visibility among other characteristics (`.hide()` in this case), and wiring that to state.
React is a set of shortcuts and conventions for doing this. It's a decent solution and saves on thinking about how to organize code for this task, and more important saves on bad thinking about how to organize an application (a savings that multiplies the larger the team working on it and range of experience within).
But it's certainly possible to write plain old JS (augmented with jQuery for convenience, if you like) where you define that relationship between your data and display element and accompanying mechanisms once and all the data->UI flow is encapsulated in functions where you don't worry about DOM specifics.
There's some marginal increase in verbosity, and you have to be the person who enforces the conventions (which is usually where this falls down), but OTOH, you get a little more control over how the semantics of your application are encoded. YMMV.
Or if you're looking to throw in a conditional, toggle takes a boolean argument:
$('.this').toggle( foo === undefined );
Really it depends so much more on whether or not you're designing a single page app or have some interactive elements on an isolated webpage. Use the correct tool for the correct job.
Actually didn't know toggle took a boolean argument, cheers, I'll probably end up using that.
But it's not just that. You've got to account for stuff like updating classes on elements, updating text (e.g you might have a dropdown and when you change that dropdown it updates a summary bar), managing configuration of various components on a page (like options within a select dropdown, available dates in a date picker) etc. etc.
All becomes a lot easier using something like React/Vue and they even throw in dev tools to make it easier furthermore.
This is the good old imperative-vs-declarative debate. jQuery is "(I think) I know what the current state of the UI is, make these changes", React is "I need the UI to be in this state, you figure out how to get it there".
In my experience, with jQuery you spend a lot more time making sure each and every event handler puts all UI elements in a correct state, often repeating yourself or calling the same helper functions. With React, all that computation is concentrated in render(), making it easier to reason about. And if you need to add a new UI element, reviewing all jQuery event handlers will again be a lot more work.
Of course, this assumes you are working on a real SPA with a lot of dynamic state, not on a reddit clone where all you need is a reply button to hide/show a textarea and a hidden field to track the parent post id.
Sometimes you just have a single element to show/hide on an otherwise static or very simple page. It's satisfying to make that work in minutes with just a couple lines of code, which you can craft/tweak in your browser dev tools console if you like.
Well it gets more complex when there’s more business rules. Like if you have 1 checkbox checked need to show this one bit but if you have 2 need to show all of them. It’s just an example.
Trying to scope it all gets a bit unruly too. Your example would target every element on the page. If you have nested components it’s a nightmare.
I keep walking into shops and look at a god-awful mess on the screen, with complex builds, state, unit-tests, and all kinds of other stuff that come together to create an app. Then I look at these same apps and realize that there's something like a 20-to-1 ratio between all of that and the simplest possible solution, which many times (but not all) involves JQuery.
Hey, if whatever works for you is awesome, please carry on. But if you're behind schedule, the SPA is too slow, the users say it's buggy, most of your devs couldn't manipulate the DOM directly if they were forced to, and the lead just spent until midnight getting the build working right, then you might want to start examining some of your development and architecture choices.
I love tools and abstraction frameworks -- right until the time they start taking over more time, effort, and learning than just pounding a solution out in something like JQuery would.
I'm glad the update is out. Looking forward to playing around with it some ... the next time I need something as full-featured as it is. With greenfield development, we start with zero stuff and carefully justify each addition after that.
I still write applications where I don't need modern frameworks like Vue/React at all. These apps follow traditional framework generating HTML, it makes so much sense to just add jQuery to enhance the user experience by sprinkling JS snippets.
I believe there is a use case of every technology. There are use cases where React/Vue makes sense, similarly, there are still use cases where jQuery can be useful.
I still write applications where I don't need modern frameworks like Vue/React at all.
jQuery is not an alternative to React or Vue. It's an alternative to vanilla JS.
When you're writing something that doesn't obviously need everything a reactive app framework like React offers the question you need to be asking isn't "Do I need React or do I only need jQuery?", it's simply "Do I need jQuery?". These days, unless you need to support very old browsers, most of the time the jQuery code isn't that much simpler than writing plain old JS.
JQuery is an alternative to React or Vue. JQuery is philosophically another approach to solving the same problem. JQuery offers you functions to call without telling you how to write your program. JQuery is a philosophy about respect, and about not knowing better, because you actually know that you don't.
React and Vue are geared towards solving a specific part of that problem.
Without a very good reason, most developers shouldn't be trying to solve the problems Vue and React solve in jQuery/JS. Of course, some will want to and nothing's stopping them, but I wouldn't recommend it for _normal_ projects.
I've found that I generally prefer using Vue when sprinkling JS snippets over static or server rendered HTML.
Vue is definitely lighter than jQuery, and the reactive model with components tends to work better. Also you don't need any building process (Babel, Webpack, etc) unlike React. You can perfectly write your templates in the DOM.
That said, for some use cases I still prefer using vanilla or a Cash (a jQuery replacement).
I feel like so many people lamenting jQuery might be remembering the pain and frustration of dealing with the monstrosities people built with the library rather than the library itself.
As libraries go I think jQuery's one of the nicer ones I've used. I don't use it now, but it's pretty good software in my books and I'm glad it was there when I needed it.
This is so true. jQuery is really a fantastic library, but it gets dragged in the mud because of the applications of it. What people forget is that the adoption of SPA's preceded the widespread use of modern SPA-centric frameworks that we use today (duh). jQuery was the defacto standard library for web development before this transition, and naturally devs crowbarred together SPA behemoths using it. It turns out that it was not the ideal tool for that job, but it WAS (and still is) the perfect tool for the kind of lightweight interactivity that it was originally designed for.
Sorry for repeating your point in so many words, but the hate towards jQuery really gets me down.
The hate for jQuery has to be from people who never used Prototype and Mootools, and think that React and Vue have existed since the beginning of time. jQuery was very useful back in those days, and pretty much everyone but David Mark agreed.
If you have jQuery on your website alongside Google Analytics, you’re loading two jQuery libraries without you knowing due to Google using it too on their analytics script.
Is that the same JS used for Analytics? I think that's just for GTM. Here is the analytics script I see more often and it doesn't have jQuery: https://www.google-analytics.com/analytics.js
<script src="https://www.googletagmanager.com/gtag/js"></script>
<script>$</script>
ReferenceError: $ is not defined
<script>jQuery</script>
ReferenceError: jQuery is not defined
There is so much we can be grateful for jQuery. It was the first JS platform (plugins) and had a huge impact on the DOM API. Without jQuery there would not be any BackboneJS, AngularJS etc.
jQuery got its niche today. Still the best for simple one-off landingpages.
I prefer jQuery syntax than javascript. It's the only thing I miss about jQuery.
I also think there's a lot of people still using jQuery simply because they're scared of SPAs, the learning curve involved and how they basically change the role of a front end dev to more of a fullstack dev.
I once considered myself a front end dev but these days I'm using SPAs, running NodeJS, pulling & managing data from REST APIs, sending / retrieving stuff from a database, managing NoSQL database, using serverless functions, working with websockets and GraphQL etc..
Am I still considered a front end developer? Because I know front end developers who still carve a living out of HTML / CSS / jQuery alone. They'd be toast when it comes to present day job interviews for example for front end positions. It just seems like we need to split 'front end developer' in to about 3 or 4 levels to better represent people's skillset / what's expected of them.
I'm not necessarily scared of SPAs (I actually work with React myself), but I do believe them to be overkill in lots of cases. One nice thing about them is you can enforce a hard boundary between frontend and backend. Although with some discipline you could do the same with a single backend framework.
> Keep in mind we will still support the positional methods, such as .first, .last, and .eq. Anything you can do with positional selectors, you can do with positional methods instead. They perform better anyway.
Except half of the point of css selectors was that you strongly encouraged your coworkers to use similar selectors for style and behavior. Now you have two implementations of the same thing and over a long enough time horizon that always breaks.
JavaScript has moved on considerably over the past decade, but any time I have to write any JS I still yearn for the simple syntax of jQuery.
Obviously, the abstractions were what made jQuery what it is, and what made it so powerful, but I wish that vanilla JS were to take a leaf out of jQuery's book and adopt some of its syntax ideas.
Always. It was powerful for its time in terms of capabilities and I got so much done with it. We still have some old apps running Jquery in production with no issues. I miss it sometimes haha
Last year I started a fairly big new web app after a few years away from web development and started out wanting to not use JQuery since I knew that was what the cool kids where doing. But everywhere I turned I kept bumping into libraries or widgets I wanted to use that wanted to pull in JQuery as a dependency. And most of the times any JQuery-free alternative I could find wasn't as feature complete or didn't quite work the way I wanted it to. Eventually I just gave up included JQuery.
I dont hate jQuery but I just find it useless for modern web dev. If you can ignore internet explorer you can do everything jquey did with just vanilla js.
I tried vuejs recently for a little interactive page on my website and found it revolutionary compared to jquery.
> If you can ignore internet explorer you can do everything jquey did with just vanilla js.
There are still lots of people who can't sadly.
That said while yes you can do everything jQuery does in vanilla JS (jQuery is written in vanilla JS after all) you often end up with more code than using jquery which means more to read through, more to understand.
So saying it is useless is a bit harsh, it may be useless for you but it's not for many and if you look at what the jquery folks are doing with deprecations you can see they are refactoring jquery to use the vanilla js stuff that was added in large part because of jquery so it'll likely definite itself out of existence at some point anyway.
Whenever I review legacy (PHP) code from say 2010/2011 with lots of jQuery, I realize what a relief it is to use frontend frameworks / libraries. There was a reason why those frameworks were developed. And that does not go away just because it feels right when I spin up a Django project and start using jQuery to make my views / templates more dynamic. Eventually when that project grows larger, I realize that going that path won‘t cut it.
I always find it weird that everyone is bashing jQuery nowadays and offers Ract/Vue as replacement - isn't React/Vue working with blank slate and injecting page content into container? jQuery usually works as "enhancement" for page content actually returned from server
Are you all building websites like that? Returning blank page from server and then filling all content on client side?
I use Bootstrap 4.3 for my side project and I still find myself enjoying jQuery.
It's a great library and I am thankful for the people who have made and contribute to it. I've used it during my web development career years ago before client side rendering was a thing.
I believe if they were to meet their goal of modernizing it, jQuery will be going on much longer regardless of other framework out there.
Love Jquery -- but hate Jquery slim build. Let's say you create a widget that expects jquery animate or ajax for some functionality. You publish your widget and users who use your widget like it and then they try to optimize page load time by using Jquery slim. And all of a sudden , some parts of your widget are working and some are not.
Remember when knowing JQuery put you at the forefront of frontend development? Actually, in those days, "frontend" wasn't really a thing yet. JQuery just made you a more competent web developer.
I really like JQuery! It is just a library in which you call functions. It does not tell you how to write your code. It is not one of those frankenmonster frameworks that sucks you dry and tells you what to do.
I am not going to name what obnoxious framework it is about, but I am waiting for another year or two before they unceremoniously abandon that stuff and start hyping the next Messiah framework.
Tools affect how you think. If you have got a hammer then every problem is a nail. If you have got a screwdriver then you don't realise that it might be a chisel you need, or a tyre lever or a paint stirrer.
jQuery is a layer of extra stuff on top of javascript. It was great in the days before standards compliant browsers as it spared you from having to learn the quirks of every different browser and you could get on with the task in hand knowing that your code would work.
But this came at a price of not knowing how to do things with javascript. Javascript has changed. You can now actually select stuff pretty easily and do those animations with CSS instead of with some jQuery. HTML5 means you can use the native form validation things and you don't need to validate on the frontend with some jQuery code. Then when you submit the form you can use fetch instead of the once incredible jQuery ajax wrappers.
Sometimes well meaning tools that make everything easy are only any good if you know how the well meaning tool works. An analogy, a server with a 'cpanel' control panel. Great in principle but there is a sea of icons and you have to know how to do things the special 'cpanel' way. Which is fine, but if you know the command line and what to type on it then you are going to be done before you have found the icon in the intuitive interface of cpanel. Plus, if you don't know what you are doing, things are documented for doing stuff the command line way, they aren't if you are doing it with the special icons. The longer you spend mastering 'cpanel' the less likely you will learn the command line way and therefore not feel comfortable without it.
As mentioned tools are great but they affect how you think and how you solve problems.
So it is not a question of not being hip. We just don't need the arm bands and extra guard rails any more.
>So it is not a question of not being hip. We just don't need the arm bands and extra guard rails any more.
You say that, but the current state of the art is to use a package manager and a workflow with a compilation step to import packages with arbitrarily deep dependency trees just to do simple things like add numbers together or add whitespace to a string, and using frontend frameworks to do the same DOM manipulation JQuery was doing years ago, but with a virtual DOM abstracted over the actual one.
I agree with you in principle, but to me, everyone seems to be moving in the wrong direction, and as a result, the JQuery model (typically "include one library, maybe two for UI and another for the plugin") is starting to look sane.
Absolutely. UI via jQuery involves heavy use of method chains each having loops and possibly nested loops. There are more direct ways to achieve UI code that execute faster, have less code to maintain, and deliver less across the wire. Those are all qualities that can be objectively measured.
Conversely, my own code is battle tested and stable and is any code that is well tested, based upon the standards, and works across supported browsers. When I read "battle tested" as a justification for a large abstraction library it sounds like you aren't testing your code thoroughly cross-browser.
> Conversely, my own code is battle tested and stable and is any code that is well tested, based upon the standards, and works across supported browsers. When I read "battle tested" as a justification for a large abstraction library it sounds like you aren't testing your code thoroughly cross-browser.
It's less a justification for a large abstraction library and more a statement to its persistence since, what, 1997?
And what's wrong with loops anyway? What kind of programming are they teaching y'all that simple primitives are so out of fashion?
jQuery often breaks in IE, because instead of using a timer to determine long running code IE uses 5 million instruction count. Simple jQuery implementations would blow past 5 million instructions on load in a fraction of a second. I encountered this failure often when I used to work at Travelocity.
>When I read "battle tested" as a justification for a large abstraction library it sounds like you aren't testing your code thoroughly cross-browser.
Most developers nowadays only develop in and test in Chrome, but things still seem to work. Either cross-browser testing really isn't necessary, or whatever they are using instead of jQuery is doing the same work to patch inconsistencies between browsers.
> Most developers nowadays only develop in and test in Chrome
Fail. I have no sympathy for laziness. If you are getting paid to do this work this is a core responsibility. Worse is that it isn’t hard to get right.
Most of its functionality is built into every modern browser. As the 3.4.0 release notes observe, for example:
> "Now that many of these selectors have made their way into modern browsers, it’s almost time to say goodbye to Sizzle. [...] When we remove Sizzle, we’ll replace it with a small wrapper around querySelectorAll"
jQuery does have a nice interface. Fortunately, it's almost exactly the same as the native JS/DOM interface that every browser offers for free these days.
I'm confident that they would appreciate a pull request for your suggested updates. It remains a frequently cited resource for these sorts of discussions; if you feel it no longer reflects the status quo, it's important that you consider being part of the solution.
Just to abuse metaphors, I believe that jQuery is a "bicycle for the mind" in the true Steve Jobs sense. If you don't love it, please knock yourself out or try an edgier SPA. Spend all of your free time learning how Hooks just made everything you were excited about obsolete.
The pool is warm and the weather is lovely, friends.