I have used straight native JS on a couple of smaller personal projects just to get some familiarity with it. However, it's just muscle memory type of getting stuff done with $.ajax() for me.
Also, maybe 20 people use any of the code I write for manipulating DOM. I'm not a UI person. I'm a back end person that has to write front end stuff because nobody else does it.
await $.post({
url: '/my/url',
data: data
}).then(() => {});
await fetch('/my/url', {
method: 'POST',
headers: {
'Content-Type': 'application/json'
},
body: JSON.stringify(data)
}).then(() => {});
Of course if you load a bunch of code beforehand your code will be marginally better.
The fact is that you probably don’t need to send JSON anymore because fetch accepts the whole form as an object:
await fetch('/my/url', {
method: 'POST',
body: new FormData(form)
})That's exactly the point though. We use jQuery because it has an incredible easy and consistent interface that makes writing for the web so much more enjoyable. Selectors, events, chaining,... are all just nicer to work with than the vanilla counterparts. Same goes for all libraries and frameworks. :)
BTW: Your example is sending a "multipart/form-data". Not all API's will understand this, and will need JSON anyway.
Who’s talking about APIs? Most jQuery users I know just use jQuery to submit forms and load some JSON, both of which are covered by fetch without altering the headers manually.
What I’m saying is that it’s not fair to judge a tool for something you don’t have to do with it, namely sending JSON for everything. Fetch also supports native binary uploads, whereas most people base64 data when using $.ajax
> makes writing for the web so much more enjoyable
Writing? I agree. Actually making it work? No way. $('forn').hide() doesn’t work, but the browser will never tell you why (hint: wrong selector).
jQuery errors are often silent, and that’s good enough reason to abandon it.
i've spent years getting away from procedural, and switching to functions, classes/methods. now, we want to get away from that and go back to procedural?
that's all fine and dandy, but you're trying to have a new trick conversation with an old dog that just doesn't care. you're bringing some sort of logic to a conversation where it's not needed. it works for me. i don't get paid to make UI apps or write heavy code nonsense with server side JS. i use a proper back end language. JS can stay in the browser and manipulate the DOM thank you very much. i get paid to make heavy processing code that sometimes is helpful to have UI dashboards.
i can whip up a JQuery front end faster for my needs than most can even figure out what NPM librar[y|ies] they need to use
the point of await/async is you break down the callback nesting into a single set of procedural code. it doesn't mean all your code is procedural. just that what used to have to be a series of indented anonymous functions or spread all over the place named functions can now be an easy to read concise few lines of code all at the same indentation in a single spot. its an obvious net-win for readability and code maintainability. you are doing yourself no favors by not understanding/embracing it.
AFAIK, we are all still programming browser UI with Javascript. It is an imperative language, about as stateful as you can get.
Now, if you managed to do your frontends with Haskell or Prolog, I'd be interested on learning how.
$.ajax() returns a promise. If you're calling .done() / .error() on it to handle the results -- well, that's exactly how you work with promises.
.ajax({
success:function(result),
error:function(xhr),
}
fetch().then((e)=>function()) is even close to being the same, then we're just not even talking the same language
Boom, same syntax if that's what you prefer.
J/K, the error status handling is not the same and the auto-deserialization isn't present. Not hard to add but it's harder to argue not to use a lib instead of copy-pasting 114 lines of niceties into each project.
You mean like response.json()?
const response = await fetch(...)
Bam, now you have the response without needing callbacks.
response.ok; // false
response.status; // 404
Fetch returning null on a network error just seems the worst possible design, as you don't get any information about why it failed. Raising an error or rejecting the promise seems an appropriate choice for fetch. It failed to reach any server, so it cannot produce a Response object -- but it can raise an error with failure details.
https://survey.stackoverflow.co/2023/#section-most-popular-t...
Yea same, I am actively trying to get rid of jQuery, but my guess would be people get used to working with a tool and there just isn't enough desire or a business case to get rid of it as it would require a rewrite.
I would say that I doubt new projects are starting with jQuery but I know there are devs out there that know the jQuery way better than the vanilla javascript way to get things done.
And if you’re forced to leave 3.x over security or something (may happen in the future) then why not just move off then?
For their customers and users, it makes no difference.
I'm also in that camp and still use jQuery.
My current SaaS is an extension that doesn't have much UI code https://www.snipcss.com, and my next SaaS will be a chatgpt powered web automation extension that has a good amount of UI. Both use jQuery.
Edit: I didn't say why I don't just use vanilla with querySelectorAll - majn reasons are I like how I can attach events (attaching to parent while targeting dynamically added subelements), chaining functions, and it's just less code than vanilla
But I also know that a lot of the "low-cost" agencies are still using it. Probably because de the devs are used to using and don't want to bother to (re)learn things.
At least in my country, a lot of website are still using it (and very old, outdated versions at that).
So, whenever reasonable, I prefer to just add jQuery. Maybe there's something better, but the differences/improvements of what I've seen doesn't seem that great and jQuery works, so that's the point? I guess the younger kids never used it, but it's easy enough to pick up if you know standard JS.
Off the top of my head I'm thinking of complex boring stuff like WCAG-compliant carousels or whatever. The kind of libraries people tend to reach for because marketing wanted them, but are otherwise ignored.
Greenfield projects might not be using Jquery, but is anyone actually using those? ;)