[HN Gopher] jQuery 3.6.2
___________________________________________________________________
jQuery 3.6.2
Author : gslin
Score : 123 points
Date : 2022-12-14 18:14 UTC (4 hours ago)
(HTM) web link (blog.jquery.com)
(TXT) w3m dump (blog.jquery.com)
| irrational wrote:
| I'm aware of "You might not need jQuery", but has anyone created
| a comprehensive list of everything jQuery offers that is not
| available through native JS/CSS?
|
| I guess I should specify, not available as easy as jQuery.
| Technically anything that jQuery does can, obviously, be done
| natively, but I remember there were some things that were much
| much much easier to do in jQuery than natively. Some of those
| easy patterns have been adopted into native, but surely not
| everything.
| hinkley wrote:
| Once upon a time someone asked me this question, and it lead me
| back to my only real complaint about jQuery, and a momentary
| urge to create a smaller version with a few behavioral
| differences.
|
| The CSS selector bit was always the strongest portion to me.
| Getting that into your project allows you to get more work and
| involvement in the system from your 'just a frontend person'
| people, and reluctant backend people working on the UI.
|
| Add to this the ability to apply CSS selectors to your
| ancestors, which has been lacking from DOM for far, far too
| long.
|
| But the last leg of that stool is the list comprehension
| semantics. Being able to implement "select all" or "clear all
| checkboxes" in one line of code. The only problem with this
| functionality is that it fails silently on a bad or out-of-date
| selector, and I think that was a mistake, but one that is hard
| to fix in retrospect without creating another library with
| different defaults. I think by default that such a call should
| fail, with an override for that 1 in 20 case where you just
| don't care.
|
| I'd also like to see either fewer frameworks or more frameworks
| that have thin veneers over common libraries, like jQuery.
| People underestimate the psychological safety people get from
| feeling that they could leave a job or ecosystem whenever they
| want. We behave as if stuckness leads to complacency, but your
| best coworkers see complacency as a warning, and will choose
| half-considered actions (like jumping ship) as a viable
| alternative to the status quo. People who get unstuck can
| become your enemy instead of just an ex-user as well, feeling
| they need to 'rescue' others from your dirty clutches.
|
| The following is more stream of consciousness than something
| I've thought about, so someone who has thought about it longer
| can probably clever out a good answer. In later versions it's
| tried harder not to get itself into reflow loops, but since I'm
| not an active user anymore, I don't know if that's so much a
| standalone feature as it is fixing bugs in the abstraction.
| There's probably other ways to fix such problems too, something
| more like zip() semantics, where you take a selector, run all
| of the get() operations, look at the answers, and only then
| mutate the list. Perhaps there's a two argument API in there,
| or maybe a fluent interface would flow better.
| brudgers wrote:
| Jquery runs existing jquery code, and people who have written
| jquery code for many years can leverage their expertise and
| experience.
| neilpanchal wrote:
| We still use jQuery + jQuery UI on our website because it is
| basically battle tested through 15+ years.
|
| https://jqueryui.com/
|
| It is easy as hell. What's there to not like? I don't care to
| be called names or being old fashioned.
|
| I also don't care about "right" tooling for frontend. As far as
| it works, it is robust and it is going to be around for many
| years, I am fine with it.
| no_wizard wrote:
| The JS Foundation oversees the jQuery project as a steward
| and has it listed as "end of life or near end of life" for
| jQuery UI. I'd suggest for bug fixes & security updates to
| quite likely look elsewhere
|
| [0]: https://openjsf.org/projects/
| yread wrote:
| bug fixes & security updates? That's the beauty of jQuery:
| you don't need those. It's done
| jmholla wrote:
| I don't think jQuery UI's move into maintenance mode is not
| that much of a concern. They are not the only clients.
|
| The foundation lists jQuery under its Impact Projects which
| are described as:
|
| > Impact projects are on a sustaining cycle of development,
| maintenance, and long-term support. These projects are used
| commonly in enterprise production environments and have
| large, well-established project communities.
|
| > ...
|
| > They receive ongoing financial and marketing support from
| the Foundation, and are expected to cross-promote the
| foundation along with their activities.
|
| This seems to me like they expect to continue to support
| jQuery for the foreseeable future.
| progmetaldev wrote:
| I think if you understand the inner workings or jQuery, it's
| still nice to chain multiple operations together and keep your
| user code smaller than pure JS. It's also helpful that so many
| devs have become familiar with jQuery over time, rather than
| bringing on someone that needs to parse all of your vanilla JS
| (everyone seems to have their own way of doing things).
| whatshisface wrote:
| It has changed a lot over time. Now native JS even has query
| selectors!
| simion314 wrote:
| Still not all selectors that are in jQuery , I think :header
| is not yet native, not the selectors by attribute value.
| lycos wrote:
| I believe querySelector/querySelectorAll supports all
| native CSS selectors, including attribute selectors. But
| jQuery does hahve custom selectors as well (at least last I
| used it, which is over 10 years ago)
| robgibbons wrote:
| You can select by attribute value. Even "starts with"
| selectors eg:
| document.querySelectorAll('[name^="starts-with-this"]')
|
| or "containing" selectors:
| document.querySelectorAll('[name*="contains-this"]')
| bastawhiz wrote:
| Anything involving multiple elements in a single operation.
| $('.foo').hide() requires something silly like
| Array.from(document.querySelectorAll('.foo')).forEach(el =>
| el.style.display = 'none');
|
| Being able to select something, then chain operations on those
| nodes is really where jQuery shines, IMO. All of the non-DOM
| stuff (e.g., AJAX) is fine with vanilla JS these days.
| bufferoverflow wrote:
| You don't need _Array.from_ this works fine:
| document.querySelectorAll('.age').forEach(el =>
| el.style.display = 'none')
|
| But I didn't have to do anything like that in years. With
| reactive frameworks you just bind visibility and styles to
| variables, refs or some central state.
| Spivak wrote:
| I think that was to handle older browsers.
| https://caniuse.com/mdn-api_nodelist_foreach looks pretty
| good but it didn't used to.
| pitaj wrote:
| FYI, the collection returned by `querySelectorAll` has a
| `forEach` method, so no need for the `Array.from`
| jonotime wrote:
| By day I code in react, but I'm working on a side project where I
| needed to use a specific already developed calendar widget. Found
| the one I needed and it was written in jquery. I started trying
| to get react and jquery to get along, but in the end I ended up
| scrapping react altogether. This of course was not my initial
| intention.
| diob wrote:
| Why couldn't you use both? I've never had issues with them
| together.
| tofuahdude wrote:
| Really depends on how they're being used.
|
| If they're independently managing their own parts of the DOM,
| it can work (though still a dev headache imo).
|
| If its a "react app", ie react is managing the entire dom,
| having two representations of the dom is a v bad idea in that
| one can make changes that the other is unaware of. Or visa
| versa.
| wetpaws wrote:
| Tbh this is not a problem of react
| duxup wrote:
| I feel like React and JQuery approach things so differently
| that it almost never should be a question of "Should I use
| React or JQuery?"...
| simion314 wrote:
| JQuery had the ideas of creating independent and reusable
| components, most of the new frameworks encourage a more ugly
| architecture IMO, though React (the first versions I used)
| was also good at promoting the idea of independent
| components. I prefer the idea where a component has no idea
| about the parents or global state and can only raise events.
| no_wizard wrote:
| you might like web components. Their main communication
| mechanism is leveraging custom events
| synergy20 wrote:
| There is jQuery 4.0 in the works(95% done), not sure what new
| feature it brings. https://github.com/jquery/jquery/milestone/7
| it's updated a while ago though.
|
| alpine.js could be an alternative to jQuery.
|
| wonder if jQuery is still used for new projects these days.
| szundi wrote:
| Main reason to use jQuery for small projects: the learning curve
| is like a dot.
| texxtxxet wrote:
| CSS variable values are trimmed of whitespace [according to
| spec]?
|
| > _Return undefined for whitespace-only CSS variable values_
|
| I've gotten in the bad habit using of CSS vars for dynamic text,
| this will shoot me in the foot some day.
| DaiPlusPlus wrote:
| > I've gotten in the bad habit of CSS vars for dynamic text
|
| Can you elaborate on this trick?
| texxtxxet wrote:
| Setting the `content` of a pseudo-element (like :before) to a
| variable with a text value (--sale-text: '50% off!').
|
| I update the value of `--sale-text` to change all elements
| with that given classname to "25% off!" instead (for ex).
| CM30 wrote:
| Sorry if this sounds naive, but... do people still use jQuery for
| new projects? I was genuinely surprised to see it was getting
| releases anymore, given how much of its functionality can be done
| with native JavaScript now.
| jabart wrote:
| Bootstrap 4 uses jquery, bootstrap 5 was released (not beta)
| May 5, 2021. So, anything started with Bootstrap 4 would use
| it.
| kypro wrote:
| I've not used it in a new project for a long time, but I often
| still work on projects with legacy jQuery code.
|
| The main reason to still use it imo it is simply that a lot of
| devs are familiar with the API and they have really good docs.
|
| While I prefer vanilla JS for JS-light projects, I'm also aware
| of some cross-browser weirdness and combability issues you
| might run into with a vanilla JS project. The nice thing JQuery
| is that you know it will work as expected on the all browsers
| it supports so you don't need to worry about cross-browser
| testing your code. It also makes certain things easier to do
| like basic JS animations.
|
| The main reason care about the latest releases is that they
| patch security issues from time to time.
| collyw wrote:
| > I'm also aware of some cross-browser weirdness and
| combability issues you might run into with a vanilla JS
| project.
|
| That was the main reason that jQuery got popular if I
| remember correctly (though I have always been an 85% backend
| developer). I was under the impression that that isn't really
| an issue these days, but everyone is building overly complex
| monstrosities with React or whatever else is flavor of the
| month.
| lelandfe wrote:
| https://webkit.org/blog/12288/working-together-on-
| interop-20...
|
| The various browsers have gotten together and work awfully
| hard to fix outstanding quirks. You'll still encounter
| cross-browser oddities here and there, but it's generally
| more in the order of, "X browser hasn't added this method
| yet"
| [deleted]
| PrivateButts wrote:
| jQuery is like, comfort food for me? Used to use jQuery for
| everything and now the world's moved on. I wouldn't want to do
| a large project today in jQuery, but I kinda miss the simpler
| projects that I used to do all the time with a smaller toolbox.
| amflare wrote:
| Yes. Technically you could always use native JS in place of
| jQuery and have the same functionality. But jQuery's power came
| from abstracting away some of the messier and more complicated
| elements and giving developers a more intuitive set of tools.
| Some part of this are less necessary today than when jQuery v1
| came out (like `querySelectorAll()` vs `$()`), but other parts
| are still enormously helpful (like `$.ajax()`). So like always,
| it's a trade off. But it's still one that comes up as worth it
| as often as not.
| ssl232 wrote:
| Is jQuery able to use native browser functions internally if
| they're available? If so then there's probably not much of a
| penalty over using pure JavaScript, but a large benefit from
| the mature component ecosystem.
| udp wrote:
| I'm not sure $.ajax() is a good example now that fetch is
| widely supported.
| gabereiser wrote:
| `$.ajax()` has been replaced entirely by `fetch()` [0]. The
| only remaining use-case I can see for jquery is the animation
| capabilities but even that can be replaced with animejs [1].
|
| [0] https://developer.mozilla.org/en-
| US/docs/Web/API/Fetch_API/U...
|
| [1] https://animejs.com/
| Beltalowda wrote:
| I tried using fetch(). I naively passed an object as the
| POST form parameter and it sent the string "[object
| Object]" to the server as POST data.
|
| Apparently you need to use some special object type. Why
| doesn't the universal key/value type work for passing a
| key/values? Who knows - maybe there's a good reason, maybe
| not. I do know that sending [object Object] is literally
| never what anyone could possibly want and that almost any
| other design choice would be less idiotic.
|
| So I just use xmlHttpRequest or jQuery.ajax().
| xmlHttpRequest is kind of awkward, but it's straight-
| forward and you don't get nonsense like this.
|
| I also don't care much for promises, and fetch is pretty
| promise-heavy.
| gabereiser wrote:
| You tried using fetch() without looking at the
| documentation on how it's supposed to be used? It's
| pretty clear [0]. You are supposed to JSON stringify your
| JSON payload so it can be attached to the body (as a
| string). The reason being that the browser isn't
| responsible for determining what goes into the request,
| only that you can make one. JSON isn't the only option.
| It could be YAML. It could be base64. It could be null.
|
| [0] https://developer.mozilla.org/en-
| US/docs/Web/API/Fetch_API/U...
| amflare wrote:
| That's only mostly true. If you are working with anything
| that needs to support older browsers (which, for example,
| is unfortunately still a requirement in many medical,
| government, and financial sectors), then you can't use
| `fetch()`.
| LudwigNagasena wrote:
| Babel?
| duskwuff wrote:
| You can polyfill fetch() if that's a concern:
|
| https://github.com/github/fetch
| no_way wrote:
| You can use fetch polyfill which woyld be better choice
| since its easier to remove polyfill than refactor your
| whole site once you don't need to support those old
| browsers anymore.
| amflare wrote:
| Sure. I could also pull in axios or just bite the bullet
| and use the XMLHttpRequest API. The point isn't that
| jQuery is the only way to solve the problem, but rather
| that it still has a value proposition.
| LudwigNagasena wrote:
| Being a "polyfill" with idiosyncratic API doesn't sound
| like a good value proposition.
| progmetaldev wrote:
| I am still using jQuery because I have so many plugins such as
| calendars, photo galleries, video galleries, and file explorer
| type trees that are all progressively enhanced, it would be a
| ton of work to rebuild everything. I think jQuery is still does
| a great job for progressive enhancement of CMS/informational
| type websites.
| ericb wrote:
| One thing that gets forgotten about jQuery is that there's a
| tremendous library of very evolved components in its ecosystem.
| Sure, "you don't need jQuery" is true, but when you go hunting
| for components you'd rather not write yourself, man is there
| still some gravity there.
|
| You ask yourself, "do I feel like writing a calendar selector
| widget today?" Trade some vanity and JavaScript puritanism and
| the question becomes "what color should I style it?"
| pier25 wrote:
| jQuery is more popular than React by pretty much any metric you
| can find
| collyw wrote:
| for starting new projects?
| kbrannigan wrote:
| Beginers and aspiring sofware developers tends to use the
| most popular technology, evangelized by the biggest
| companies.
|
| Since they don't know any better, they equate MOST POPULAR
| with BEST.
|
| Sometimes all you need is a wheelbarrow, you don't need a
| tractor.
| jrochkind1 wrote:
| i don't intentionally write code using JQuery anymore, and find
| it not very inconvenient to avoid for the most part, even when
| writing "jquery style" JS -- which I do. Browser API's in
| recent browsers are good enough.
|
| But I'm still using some dependencies that need jquery.
|
| I honestly expect I'll never be able to get rid of it.
| tsian2 wrote:
| I find it much quicker to write and neater to read than vanilla
| JS. I optimise afterwards and might consider swapping it out
| but it's usually low down the list of performance issues.
| Although it can be a bigger issue if you don't know how select
| things and store those selections efficiently with it.
| yokoprime wrote:
| I only encounter it when maintaining old codebases. Never for
| anything new
| Alupis wrote:
| The API jQuery gives you is still so much nicer than regular
| javascript, even with modern ECMAScript 7+...
|
| While we're at it - Bootstrap (and similar css frameworks) are
| still much nicer to use than native CSS, even with modern CSS3
| and flexbox...
|
| It's almost like the designers for these native-API's look at
| what the community uses, and then decide to do something
| similar, but different just because.
| ww520 wrote:
| Yes. I do still use it.
| thejammahimself wrote:
| Yeah a good few years ago, before I had learnt about frameworks
| like React, I used JQuery for one of my projects. Once I
| learned about React, I decided to rewrite this project using
| that instead, and afterwards I felt that the React version was
| very obviously the superior version. I just feel like we now
| have better options, and I still really like React's way of
| handling state in a moreso functional way.
| smallmouth wrote:
| Apology accepted, and absolutely! Myself and two other
| developers just kicked off a very non-tivial, data-heavy
| application for a Dow 30 that will be used by a maximum of
| 12,000 users. Using jquery will help us avoid a lot of thinking
| and testing time with the whole "gee, how would I do that in
| vanilla, let me look that up" process.
| omgomgomgomg wrote:
| Sure jQuery as a selector engine has more or less been replaced,
| css has advanced etc.
|
| But the jQuery UI widgets are battle hardened and easier to
| deploy, case in point , date pickers, calendaries and well,
| slideshows.
|
| And you can kind of replicate some of reacts behaviour regarding
| state management.
|
| If all you need to do is keep state on a handful of elements,
| there is no need to develop in react.
|
| Infact, just like the jquery heydays, react is often overused,
| for the most simply web forms, menus, footers.
|
| And, no need for router and other state management tools.
|
| Might be a bit unpopular, but when its all said and done, its
| compiled to js either way, I kinda like jquery or vanilla js for
| the front end and node/express for the back end.
|
| The amount of react devs which struggle with css and vanilla js
| appears to be higher than during the jquery days.
| texxtxxet wrote:
| Why not components from a React library like Material UI?
|
| jQuery UI is "in a maintenance state" and "older long-standing
| bugs may not get fixed" I'm afraid
|
| https://blog.jqueryui.com/2022/07/jquery-ui-1-13-2-released/
| flatiron wrote:
| My job has a lot of little customers with little projects and
| some older ones were made with jquery and we keep on keeping
| on. Why not? Also if we have to make similar projects we branch
| from older ones. So some of our current development uses jquery
| which raises some eyebrows but nothing like using 95% battle
| hardened code than starting fresh because...
| Beltalowda wrote:
| I rather like jQuery as it just patches over so much of the DOM
| API, which offends my sensibilities of what a "good API" should
| look like. I don't think the jQuery API is perfect, but it's a
| lot better.
|
| But I never really liked jQuery UI, either as a user or
| developer. As a user, the whole "desktop semantics in your
| browser" is one of those things that was worth trying 15 years
| ago, but it mostly never really worked all that well, and
| pretty much everyone has dropped it.
|
| As a developer I feel jQuery UI is too complex for what it
| does, partly because of the above.
|
| At any rate, jQuery and jQuery UI are two entirely different
| projects.
| MuffinFlavored wrote:
| > date pickers
|
| <input type="date"> is too rough I'm guessing? I'm not exactly
| sure where it falls short personally.
| iambateman wrote:
| There's a million edge cases for dates that make it hard to
| use the bare-metal tools.
| Beltalowda wrote:
| I really dislike how most desktop browsers display them. Plus
| you can't easily do things like "display start date while
| selecting end date".
| forthorbor wrote:
| blowski wrote:
| The advantage of Vue, Svelte, and React is the neat decoupling of
| changing state and responding to those changes. jQuery always
| seemed to end up in long chains of callback hell.
| pantulis wrote:
| Because it hails from a different and terrible era. It's easy
| to forget the impact that jQuery had in front-end development.
| jabart wrote:
| JS in ~20020 - Use onclick handlers to respond to user
| interaction. JS in ~2004 - Use jQuery to decouple your JS from
| your HTML in separate files. JS in ~2008 - We invented our own
| onclick handler, embed your JS in your HTML it's fine now.
|
| _EDIT_ Spelling
| wackget wrote:
| "Decoupling" is not a phrase I'd personally use to describe a
| benefit of React.
|
| Every React example I've seen is a horrific-looking mixture of
| JavaScript, XML, and HTML all muddled together into a nasty-
| looking component system.
|
| When I was learning front-end development it was an absolute
| cardinal sin to mix markup, JavaScript, and styling together.
| Now that seems like the standard practice and I still can't
| look past it.
| agumonkey wrote:
| it's an object metaphor brought to the UI layer, you used to
| assemble trees of java widgets updated manually, now it's a
| tree of dom elements with semi infered update graphs
| ddmma wrote:
| Feels like Winamp but things eventually evolved on server side.
| Always welcome on my legacy .net project:)
| oefrha wrote:
| Just so happens I translated an old JS library from 2013 to
| modern TypeScript yesterday. It has jQuery, old-style "classes"
| with prototypes and everything. The language has changed so much
| in ten years it's barely recognizable.
| [deleted]
| xwdv wrote:
| Too little too late.
___________________________________________________________________
(page generated 2022-12-14 23:01 UTC)