jQuery 3.6.2(blog.jquery.com)
blog.jquery.com
jQuery 3.6.2
https://blog.jquery.com/2022/12/13/jquery-3-6-2-released/
117 comments
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.
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.
Josh Comeau and the jQ team should sit down together and create a state of the art, kickass UI component library with nifty buttons and similar cool ui elements.
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…
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/
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/
Why? Material's dead, adding React is adding a massive amount of bloat and build steps.
You need to have a reason to pay the price of React. Otherwise you're just being a sheep.
I say this using React and Material UI in a present project, from my perspective development for what is a pretty simple form UI is massively slowed down by using them.
Could have knocked out the whole site on my own in 1/2 the time using the 'old' stuff.
But now we've got a lovely loading spinner while it downloads everything it needs piecemeal and a bunch of basic browser functionality is broken, we've got 10x the amount of code, have to deal with a whole extra API layer and it's a nightmare to debug sitting there watching network calls instead of being able to step through the code in a proper debugger, brilliant stuff.
Completely worth it for that one datepicker we have.
You need to have a reason to pay the price of React. Otherwise you're just being a sheep.
I say this using React and Material UI in a present project, from my perspective development for what is a pretty simple form UI is massively slowed down by using them.
Could have knocked out the whole site on my own in 1/2 the time using the 'old' stuff.
But now we've got a lovely loading spinner while it downloads everything it needs piecemeal and a bunch of basic browser functionality is broken, we've got 10x the amount of code, have to deal with a whole extra API layer and it's a nightmare to debug sitting there watching network calls instead of being able to step through the code in a proper debugger, brilliant stuff.
Completely worth it for that one datepicker we have.
In my clients company they usually even implement admin crud UI as api + React and it takes them so much longer than just whipping up some forms in Rails. They just do this as a default state of doing things not because they actually need an extra api for anything.
[deleted]
Is Material dead? What replaced it?
> date pickers
<input type="date"> is too rough I'm guessing? I'm not exactly sure where it falls short personally.
<input type="date"> is too rough I'm guessing? I'm not exactly sure where it falls short personally.
There’s a million edge cases for dates that make it hard to use the bare-metal tools.
I really dislike how most desktop browsers display them. Plus you can't easily do things like "display start date while selecting end date".
I don't use much jQuery any more but I thought it papered over a few bugs in browser bugs (I vaguely recall jQuery having to work around a DOM selector bug in mobile Safari in the last seven or so years).
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.
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?"
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?"
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.
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.
> 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.
This is an understandable interpretation, but I think the real explanation is more nuanced (and more favorable). Web APIs do tend to be inspired by existing use cases like you say, and that’s a good thing. But from there they tend to be low level—in the sense that they’re designed for library authors, at least as much as they’re designed for end users—either as an explicit goal or as an implied general principle.
Taking inspiration from real usage is unambiguously great. Lower level APIs might feel more painful for end users (and can lead to dependency-itis which is a constant target of scorn here and all over). But the benefit is that these less friendly APIs are also well designed to be used in a wider variety of ways, without much influence on their own higher level interfaces.
More concretely, the DOM as designed allows jQuery and React to coexist and thrive for their own target audiences, in a way that would probably be much less likely if the DOM had been designed more like either one of them. This is similarly true for APIs like Intl (which I’ve used directly, and it’s fine… but it’s definitely better as a library target than for every day usage).
This is an understandable interpretation, but I think the real explanation is more nuanced (and more favorable). Web APIs do tend to be inspired by existing use cases like you say, and that’s a good thing. But from there they tend to be low level—in the sense that they’re designed for library authors, at least as much as they’re designed for end users—either as an explicit goal or as an implied general principle.
Taking inspiration from real usage is unambiguously great. Lower level APIs might feel more painful for end users (and can lead to dependency-itis which is a constant target of scorn here and all over). But the benefit is that these less friendly APIs are also well designed to be used in a wider variety of ways, without much influence on their own higher level interfaces.
More concretely, the DOM as designed allows jQuery and React to coexist and thrive for their own target audiences, in a way that would probably be much less likely if the DOM had been designed more like either one of them. This is similarly true for APIs like Intl (which I’ve used directly, and it’s fine… but it’s definitely better as a library target than for every day usage).
Of course there are technical reasons things are the way they are - but why does javascript have like 6 different ways to select an element? Why does everything have to start with verbose "document."? Why are the new functions so long in name and cumbersome to use?
In jQuery, you can select almost anything with just the constructor. It's simple... and clearly better.
> in the sense that they’re designed for library authors
Libraries shouldn't be necessary to write basic DOM manipulation code. Modern ECMAScript has been promised to do away with all the "hack" libraries like jQuery... and articles like "You might not need jQuery" sprang up in popularity based on new ECMAScript features.
But, modern ECMAScript is objectively harder to use, more clunky and verbose. Even the naming of functions is absurd... "querySelector()" instead of just "select()" or "get()"...
The problem with the javascript community is nobody actually knows javascript. No, people know whatever framework/lib they work with, which is not the same thing. It's that way because javascript... sucks to use.
In jQuery, you can select almost anything with just the constructor. It's simple... and clearly better.
> in the sense that they’re designed for library authors
Libraries shouldn't be necessary to write basic DOM manipulation code. Modern ECMAScript has been promised to do away with all the "hack" libraries like jQuery... and articles like "You might not need jQuery" sprang up in popularity based on new ECMAScript features.
But, modern ECMAScript is objectively harder to use, more clunky and verbose. Even the naming of functions is absurd... "querySelector()" instead of just "select()" or "get()"...
The problem with the javascript community is nobody actually knows javascript. No, people know whatever framework/lib they work with, which is not the same thing. It's that way because javascript... sucks to use.
> why does javascript have like 6 different ways to select an element?
Because all but one of them existed already when settled on the one that everyone almost universally prefers, but the others can’t be removed. You can just use the one you like and totally ignore the others.
> Why does everything have to start with verbose "document."?
Because it has to be namespaced to something, and the global document object is by far the best namespace available. You can destructure it once and even assign it to a global if you don’t like that reasoning.
> Why are the new functions so long in name and cumbersome to use?
Partly because people don’t like how things are so they do the global assignment thing and make sure no one can have nice things; partly because long names are self documenting which is often the best documentation they can guarantee at design time; partly because they expect people will never call these APIs directly.
> In jQuery, you can select almost anything with just the constructor. It's simple... and clearly better.
Clearly to you? I can think of a bunch of ways I’d rather access the current state of a document, and they can vary a lot depending on my task.
> Libraries shouldn't be necessary to write basic DOM manipulation code.
That’s a really odd position to take given you’re advocating the choices made by one!
> Modern ECMAScript has been promised to do away with all the "hack" libraries like jQuery... and articles like "You might not need jQuery" sprang up in popularity based on new ECMAScript features.
Modern ECMAScript didn’t make any of these claims, and didn’t set out to do any of the things jQuery does. ECMAScript has added some language features like let/const, modules, Symbol, classes, async/await. HTML added querySelector and a bunch of other DOM conveniences, as well as fetch. Browser vendors and other organizations have added other APIs for things people want to build applications on.
> The problem with the javascript community is nobody actually knows javascript. No, people know whatever framework/lib they work with, which is not the same thing. It's that way because javascript... sucks to use.
No, it’s that way because everyone wants JavaScript to be the thing they already shimmed it to be. You might be surprised by what it actually is. There are many problems with it of course, but it’s incredibly capable of being nicer to use than you seem to think.
As far as knowing JS, I’d highly recommend just spending some casual time reading MDN. Almost every time I do (which is fairly often) I discover something elegant that I either need immediately or could imagine being helpful soon.
If nothing else, it’s always a good insight into how the tools that do 95% of what I want get their job done.
Because all but one of them existed already when settled on the one that everyone almost universally prefers, but the others can’t be removed. You can just use the one you like and totally ignore the others.
> Why does everything have to start with verbose "document."?
Because it has to be namespaced to something, and the global document object is by far the best namespace available. You can destructure it once and even assign it to a global if you don’t like that reasoning.
> Why are the new functions so long in name and cumbersome to use?
Partly because people don’t like how things are so they do the global assignment thing and make sure no one can have nice things; partly because long names are self documenting which is often the best documentation they can guarantee at design time; partly because they expect people will never call these APIs directly.
> In jQuery, you can select almost anything with just the constructor. It's simple... and clearly better.
Clearly to you? I can think of a bunch of ways I’d rather access the current state of a document, and they can vary a lot depending on my task.
> Libraries shouldn't be necessary to write basic DOM manipulation code.
That’s a really odd position to take given you’re advocating the choices made by one!
> Modern ECMAScript has been promised to do away with all the "hack" libraries like jQuery... and articles like "You might not need jQuery" sprang up in popularity based on new ECMAScript features.
Modern ECMAScript didn’t make any of these claims, and didn’t set out to do any of the things jQuery does. ECMAScript has added some language features like let/const, modules, Symbol, classes, async/await. HTML added querySelector and a bunch of other DOM conveniences, as well as fetch. Browser vendors and other organizations have added other APIs for things people want to build applications on.
> The problem with the javascript community is nobody actually knows javascript. No, people know whatever framework/lib they work with, which is not the same thing. It's that way because javascript... sucks to use.
No, it’s that way because everyone wants JavaScript to be the thing they already shimmed it to be. You might be surprised by what it actually is. There are many problems with it of course, but it’s incredibly capable of being nicer to use than you seem to think.
As far as knowing JS, I’d highly recommend just spending some casual time reading MDN. Almost every time I do (which is fairly often) I discover something elegant that I either need immediately or could imagine being helpful soon.
If nothing else, it’s always a good insight into how the tools that do 95% of what I want get their job done.
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.
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.
Yeah I thought that many of the last few releases were security fixes more than anything.
> 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.
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.
I was jQuery’s target audience at its heyday and at least for me, the big thing it brought to the table was $ and what’s now called a “fluent API” ($ methods return $ instances unless they’re getters for primitives; it’s pretty much still my preferred way to explain the general concept of monads to people familiar with the pattern). Browser compatibility was just delicious icing on the cake.
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"
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"
Yes, the cross browser weirdness is nothing like it used to be.
The other raison d'être is the API, which is simply much better than even the latest DOM API. It's actually pretty remarkable that jQuery API feels spot on even after 16 years.
The other raison d'être is the API, which is simply much better than even the latest DOM API. It's actually pretty remarkable that jQuery API feels spot on even after 16 years.
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.
`$.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/
[0] https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API/U...
[1] https://animejs.com/
I tried using fetch(). I naïvely 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.
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.
> Why doesn't the universal key/value type work for passing a key/values?
Because there isn't one?
By "itself" (i.e. <form> tags without JS), the browser can POST using two different encoding formats: - Url encoding (similar to what you'd see in the URI, but as the body of the request) - multipart/form-data (a derivative of MIME, needed for file uploads)
What's it supposed to do if you passed an object containing a CryptoKey instance, a Blob and a ReadadbleStream??
We also have a ton more ways of encoding and sending data in a POST (which is just the HTTP method, it doesn't convey anything bar that there's probably a body and related headers attached we want the server to do something with).
JSON, XML, CSV, YAML to name but a few key/value formats.
Hell, maybe it's an S3 style endpoint and you just push the raw bytes to save.
fetch is... less "magic" by default. This makes it flexible, but means you have to put just a tiny bit of effort into it.
Or... just use Axios, I ain't your manager; I get by easily enough with a helper js that gets treeshaked out so that I can just call `postJSON(url, body, opts=null)`
Because there isn't one?
By "itself" (i.e. <form> tags without JS), the browser can POST using two different encoding formats: - Url encoding (similar to what you'd see in the URI, but as the body of the request) - multipart/form-data (a derivative of MIME, needed for file uploads)
What's it supposed to do if you passed an object containing a CryptoKey instance, a Blob and a ReadadbleStream??
We also have a ton more ways of encoding and sending data in a POST (which is just the HTTP method, it doesn't convey anything bar that there's probably a body and related headers attached we want the server to do something with).
JSON, XML, CSV, YAML to name but a few key/value formats.
Hell, maybe it's an S3 style endpoint and you just push the raw bytes to save.
fetch is... less "magic" by default. This makes it flexible, but means you have to put just a tiny bit of effort into it.
Or... just use Axios, I ain't your manager; I get by easily enough with a helper js that gets treeshaked out so that I can just call `postJSON(url, body, opts=null)`
You can default to "application/x-www-form-urlencoded" and use "multipart/form-data" if requested, which is essentially how HTML forms work. There's lots of reasonable behaviours to choose from and you can discus what the best possible approach is, including throwing an exception, but sending "[object Object]" is not one of the reasonable behaviours.
> Or... just use Axios, I ain't your manager; I get by easily enough with a helper js that gets treeshaked out so that I can just call `postJSON(url, body, opts=null)`
The fact that everyone "just" has to use a wrapper for a basic system API is exactly the problem, especially when this was supposed to be the new shiny thing that would replace the old cruft. Why do I have to add 4 dependencies + 44 "dev dependencies" just to make a HTTP request?
Plus, for my personal projects I want to avoid the "npm ecosystem", and I especially want to avoid any JS build system.
> Or... just use Axios, I ain't your manager; I get by easily enough with a helper js that gets treeshaked out so that I can just call `postJSON(url, body, opts=null)`
The fact that everyone "just" has to use a wrapper for a basic system API is exactly the problem, especially when this was supposed to be the new shiny thing that would replace the old cruft. Why do I have to add 4 dependencies + 44 "dev dependencies" just to make a HTTP request?
Plus, for my personal projects I want to avoid the "npm ecosystem", and I especially want to avoid any JS build system.
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...
[0] https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API/U...
It's not clear that it will do something completely idiotic if you mess up a parameter. The documentation didn't mention it, so I figured I'd try and see what happens.
This is the worst of dynamic languages: if you mess something up and you get an error: okay, fair. If you mess something up and you ignore it or do something insane: that's just stupid.
"Read the documentation from cover to cover to something as simple as sending a HTTP request" isn't really much of solution.
> 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.
The standard data type for POST is form data, so it could just default to that for objects.
Or it could throw an error.
Sending [object Object] is not reasonable behaviour in any shape or form. I guess it just calls the JS "to string" logic ("logic"), but spreading that to new APIs is just not a good design, especially when it's "hidden".
This is the worst of dynamic languages: if you mess something up and you get an error: okay, fair. If you mess something up and you ignore it or do something insane: that's just stupid.
"Read the documentation from cover to cover to something as simple as sending a HTTP request" isn't really much of solution.
> 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.
The standard data type for POST is form data, so it could just default to that for objects.
Or it could throw an error.
Sending [object Object] is not reasonable behaviour in any shape or form. I guess it just calls the JS "to string" logic ("logic"), but spreading that to new APIs is just not a good design, especially when it's "hidden".
> Why doesn't the universal key/value type work for passing a key/values?
Because form data (and the FormData object which is what you’re expected to use) is often not a map (in the sense of key -> value) but rather a set of entries (as in, still a key-value container, but the same key might be present multiple times). They definitely could have supported a POJO but I personally like this bit of type strictness (and it’s easily abstracted away if you prefer, in whatever way you prefer).
Because form data (and the FormData object which is what you’re expected to use) is often not a map (in the sense of key -> value) but rather a set of entries (as in, still a key-value container, but the same key might be present multiple times). They definitely could have supported a POJO but I personally like this bit of type strictness (and it’s easily abstracted away if you prefer, in whatever way you prefer).
CSS animations and the Web Animation API are also quite nice to use and quite powerful.
https://developer.mozilla.org/en-US/docs/Web/API/Web_Animati...
https://developer.mozilla.org/en-US/docs/Web/API/Web_Animati...
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()`.
You can polyfill fetch() if that's a concern:
https://github.com/github/fetch
https://github.com/github/fetch
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.
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.
Being a “polyfill” with idiosyncratic API doesn’t sound like a good value proposition.
Babel?
I’m not sure $.ajax() is a good example now that fetch is widely supported.
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.
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.
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.
I used jQuery earlier this year.
I am not a web developer I learnt HTML in the 90's (When Frames and Tables were the way to write web pages). I have not kept up to date with current State of the art in web development. I know enough about JavaScript to read source code and kind of understand what it is doing but don't know anything about best practices or the 'proper' way to write it.
I needed to throw together a simple webform to submit a date as one of the inputs. I was having problems getting it to work consistently across different browsers.
One of the issues I was having was I needed the date to be in the Australian date format (DD/MM/YYYY) but one browser (I can't remember which Edge maybe??) kept insisting on using US style dates MM/DD/YYYY it caused me a lot of frustration maybe I just didn't know the correct phrase to search google for but I could not work out how to make the browsers built in calendar picker force the date to be in a specific format.
So I just used the JQuery calendar picker took me two seconds and problem solved.
I am not a web developer I learnt HTML in the 90's (When Frames and Tables were the way to write web pages). I have not kept up to date with current State of the art in web development. I know enough about JavaScript to read source code and kind of understand what it is doing but don't know anything about best practices or the 'proper' way to write it.
I needed to throw together a simple webform to submit a date as one of the inputs. I was having problems getting it to work consistently across different browsers.
One of the issues I was having was I needed the date to be in the Australian date format (DD/MM/YYYY) but one browser (I can't remember which Edge maybe??) kept insisting on using US style dates MM/DD/YYYY it caused me a lot of frustration maybe I just didn't know the correct phrase to search google for but I could not work out how to make the browsers built in calendar picker force the date to be in a specific format.
So I just used the JQuery calendar picker took me two seconds and problem solved.
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.
Bootstrap 4 uses jquery, bootstrap 5 was released (not beta) May 5, 2021. So, anything started with Bootstrap 4 would use it.
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.
jQuery is more popular than React by pretty much any metric you can find
for starting new projects?
Yeah. There are probably more new projects started with Wordpress themes that use jQuery than React projects.
And it's not only WP. Plenty of big companies use it too. Amazon (the store) used it until a couple of months ago IIRC.
If you don't need a super sophisticated frontend, jQuery is still one of the best tools around.
People argue vanilla JS can do everything jQuery does, which is true for jQuery and any JS framework really, but they're really missing the point. With jQuery you can do express complex logic in a single line that would take many more lines in vanilla JS.
And it's not only WP. Plenty of big companies use it too. Amazon (the store) used it until a couple of months ago IIRC.
If you don't need a super sophisticated frontend, jQuery is still one of the best tools around.
People argue vanilla JS can do everything jQuery does, which is true for jQuery and any JS framework really, but they're really missing the point. With jQuery you can do express complex logic in a single line that would take many more lines in vanilla JS.
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.
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.
BEST is highly subjective. Most popular has a number of advantages- more developers, likely cheaper developers, bigger community but for most cases I am in agreement with you
[deleted]
It always could be done in JavaScript, jQuery is written on it after all.
It’s just that it’s a lot better and easier. The fact that we haven’t standardized on jQuery’s API is one of the greatest missed opportunities in the field.
It’s just that it’s a lot better and easier. The fact that we haven’t standardized on jQuery’s API is one of the greatest missed opportunities in the field.
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.
But I'm still using some dependencies that need jquery.
I honestly expect I'll never be able to get rid of it.
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.
Yep. It is the first package I install on a new project. Followed by React.
I only encounter it when maintaining old codebases. Never for anything new
Yes. I do still use it.
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.
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?”…
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.
you might like web components. Their main communication mechanism is leveraging custom events
Why couldn't you use both? I've never had issues with them together.
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.
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.
Tbh this is not a problem of react
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.
"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.
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.
Component-based UI libraries/frameworks and the resulting ability to compartmentalize different parts of the app make that adage irrelevant.
I agree with your opinion of React/JSX, but the single file components of Vue and Svelte are an absolute joy to work with.
I agree with your opinion of React/JSX, but the single file components of Vue and Svelte are an absolute joy to work with.
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
Because it hails from a different and terrible era. It's easy to forget the impact that jQuery had in front-end development.
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
EDIT Spelling
I super love jQuery.
As an infrastructure engineer with zero interest in Frontend trends, jQuery simply gets the job done.
As an infrastructure engineer with zero interest in Frontend trends, jQuery simply gets the job done.
Someone just today was complaining that css doesn’t have contains. Something as simple as that makes jquery useful. It’s also not a huge library and extremely powerful. It gets a bad rap.
Has does not have the same functionality as jquery contains.
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.
alpine.js could be an alternative to jQuery.
wonder if jQuery is still used for new projects these days.
Alpine.js has been a wonderful new tool in my arsenal.
I prefer lightweight tools that solve big problems while still staying small/simple. Alpine.js really hits that balance for me. The fact I'm able to drop it in without a single Node.js/etc build tooling is astounding (esbuild, rome, etc). I really prefer how it stays true to vanilla JS/general web development while also bringing modern attribute-driven reactivity to the table.
I prefer lightweight tools that solve big problems while still staying small/simple. Alpine.js really hits that balance for me. The fact I'm able to drop it in without a single Node.js/etc build tooling is astounding (esbuild, rome, etc). I really prefer how it stays true to vanilla JS/general web development while also bringing modern attribute-driven reactivity to the table.
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.
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.
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');
You don't need Array.from this works fine:
document.querySelectorAll('.age').forEach(el => el.style.display = 'none')
> With reactive frameworks you just bind visibility and styles to variables, refs or some central state
I fail to see the superiority of that approach after more than a decade.
To me, the success of React and the likes has more to do with team dynamics, hiring, etc.
I fail to see the superiority of that approach after more than a decade.
To me, the success of React and the likes has more to do with team dynamics, hiring, etc.
I easily see the superiority. The data controls the UI, instead of some random line of code that's very hard to find.
Essentially it's declarative programming, you declare your UI should look this way when the state is this, and that way when the state is that.
It's much easier to reason about than when you have a thousand random functions that can change the UI, often in ways that break each other.
Essentially it's declarative programming, you declare your UI should look this way when the state is this, and that way when the state is that.
It's much easier to reason about than when you have a thousand random functions that can change the UI, often in ways that break each other.
That’s what I meant by team dynamics.
I can separate concerns instead of multiple functions changing the same UI, but I can’t guarantee that everyone else will.
The conventions that React provides sidesteps the need for discipline and that I find useful.
Doesn’t mean that the approach in itself is better, IMO. and if you work alone, it’s clearly way too much trouble for little gain.
I can separate concerns instead of multiple functions changing the same UI, but I can’t guarantee that everyone else will.
The conventions that React provides sidesteps the need for discipline and that I find useful.
Doesn’t mean that the approach in itself is better, IMO. and if you work alone, it’s clearly way too much trouble for little gain.
I think that was to handle older browsers. https://caniuse.com/mdn-api_nodelist_foreach looks pretty good but it didn't used to.
[deleted]
Manipulating CSS properties via Javascript/jQuery often is a code smell for a cleaner alternative purely CSS-based solution:
some-selector .foo {
display: none;
}FYI, the collection returned by `querySelectorAll` has a `forEach` method, so no need for the `Array.from`
Things like "I want the first/last element" is still a PITA as far as I know, so lots of people use Array.from() wrappers. For all cases I used it, the performance impact seems negligible.
I don't know why querySelectorAll() doesn't just return an array.
I don't know why querySelectorAll() doesn't just return an array.
Supporting legacy Edge requires the conversation from NodeList to Array, sadly.
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.
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.
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/
[0]: https://openjsf.org/projects/
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.
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.
bug fixes & security updates? That's the beauty of jQuery: you don't need those. It's done
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.
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.
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).
It has changed a lot over time. Now native JS even has query selectors!
Still not all selectors that are in jQuery , I think :header is not yet native, not the selectors by attribute value.
You can select by attribute value. Even "starts with" selectors eg:
document.querySelectorAll('[name^="starts-with-this"]') document.querySelectorAll('[name*="contains-this"]')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)
Jquery runs existing jquery code, and people who have written jquery code for many years can leverage their expertise and experience.
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.
One of the senior devs at a place I worked at built his own react-like component system using jQuery and they had a couple apps foundationally upon it. I also wound up on a project to help out with a pretty recent greenfield Angular SPA. Turned out actually they just used the router from angular and ejected into jQuery for nearly all component/dom manipulation. Of course everyone else was rolling with it like it was cool or no big deal. PMs were happy with the team's velocity.
Times like that make me highly qustion my career choices; especially when their pay scale is similar.
Times like that make me highly qustion my career choices; especially when their pay scale is similar.
In this thread there is a lot of both "you should use this", and "you shouldn't use this". In the end, everyone should evaluate the options for themselves and use what works best for them.
I disagree. Just today I had headache again because of a legacy jQuery-based codebase.
The jQuery version is so old, it is a security risk.
A pure JavaScript codebase updates itself with each new browser release, so to say.
So my verdict: "you shouldn't use jQuery"
So my verdict: "you shouldn't use jQuery"
Main reason to use jQuery for small projects: the learning curve is like a dot.
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.
> 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.
> I've gotten in the bad habit of CSS vars for dynamic text
Can you elaborate on this trick?
Can you elaborate on this trick?
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).
I update the value of `--sale-text` to change all elements with that given classname to "25% off!" instead (for ex).
[deleted]
Feels like Winamp but things eventually evolved on server side. Always welcome on my legacy .net project:)
jQuery is awesome, use it in most of my projects. Its easy to read.
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.