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 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 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 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.
[0] https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API/U...
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.
[0] https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API/U...
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".
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)`
> 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.
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).
https://developer.mozilla.org/en-US/docs/Web/API/Web_Animati...
But I'm still using some dependencies that need jquery.
I honestly expect I'll never be able to get rid of it.
It always surprises me how many people think jquery is unnecessary now. Developers obviously value ergonomics, and jquery is vastly more ergonomic than vanilla JavaScript. It's like saying Kotlin is useless because you can do all that shit in Java.
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.
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.
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.
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).
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.
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 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.
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.