What we need in 2021 is not this site, it's a youmightnotneedreact.com
And of course in 2021 you could build the site using Vue with GraphQL and a CDN deployment pipeline with auto scaling :)
Kubernetes, docker, nuxtjs, mongo
You might not need jQuery (2014)
111–120 of 241 posts
Re: You might not need jQuery (2014)
#112Now only if someone could combine the snippets on the right hand side in an easy-to-use library. Oh wait...
no no no... what we need to do is break them down so that each line is a separate library composed of a single function with its own independent dependency tree and test suite, then build another library out of that, all written in a language that compiles to javascript, and publish it to a proprietary package manager. If we're really clever we can probably get it up to several megabytes, require three languages and…
Then i would only consider it if it has an @types package I can pull
Re: You might not need jQuery (2014)
#113It's ironic that there's probably no bigger sales pitch for jQuery than this site. In every single example, the jQuery version is basically one or two lines of code, versus 10-15 lines for the alternative. (and the jQ version seems significantly easier on the eyes as well.) Also, jQuery supports promises and has for quite a while. This page hasn't aged well. I've come full circle and am now using jQuery again.
I agree this page hasn't aged well, but that's because it's stuck on IE10 as the support level it's targeting. If you don't need to target IE at all (only Edge), then everything becomes simpler. That's not always safe, but that's why you might not need jQuery... For reference: // JSON const data = await (await fetch('/my-url')).json(); // Post await fetch('/my-url', { method: 'POST', body: data }); // Request try { c…
Really thanks, but Android Chromium has support "fetch" too late (2020). Well, I can wait.
Re: You might not need jQuery (2014)
#114wow, no other proof is needed to user jQuery :)
Re: You might not need jQuery (2014)
#115It's ironic that there's probably no bigger sales pitch for jQuery than this site. In every single example, the jQuery version is basically one or two lines of code, versus 10-15 lines for the alternative. (and the jQ version seems significantly easier on the eyes as well.) Also, jQuery supports promises and has for quite a while. This page hasn't aged well. I've come full circle and am now using jQuery again.
> In every single example, the jQuery version is basically one or two lines of code, versus 10-15 lines for the alternative But isn't the point here that you can wrap the 10-15 lines into your own function which you can then call with just a single line of code? So you "might not need JQuery" because you can program it yourself following the examples given, and can choose which parts of it you need and want to packag…
But if I need to wrap around everything, I might was well just use jQuery.
Re: You might not need jQuery (2014)
#116Earlier quoted context omitted.
Somewhat true, but this was also old jQuery :) Even the old jQuery seems easier to read than the modern ES6 equivalent (IMO). jQuery: $(".classname").addClass("darktheme") ES6: document.querySelector(".classname").classList.add("darktheme")
There are quite a few more examples of this: $('.class').remove() $('.class').after(...) vs: var e = document.querySelector('.class') e.parentNode.removeChild(e) document.querySelector('.class').insertAdjacentElement('afterend', ...)
The modern DOM equivalent would look almost the same as the jQuery version:
document.querySelector(".class").remove();
document.querySelector(".class").after(...);Re: You might not need jQuery (2014)
#117Having used react and redux for several years now, I'm a bit burnt out on how bloated and silly the entire front end has become. If I could decide for myself, I probably would use raw DOM or jQuery at this point.
You have to consider the audience.
Because of bloated frameworks and slow convenience libraries the front end is a very low barrier of participation. The problem there is then that peoples’ entire careers and life worth are stacked around these fragile glass houses and the only thing they want is to avoid being exposed as a fraud.
Is writing a killer product without all the bullshit that impossible? No, clearly not, but that completely misses the point.
Re: You might not need jQuery (2014)
#118It's ironic that there's probably no bigger sales pitch for jQuery than this site. In every single example, the jQuery version is basically one or two lines of code, versus 10-15 lines for the alternative. (and the jQ version seems significantly easier on the eyes as well.) Also, jQuery supports promises and has for quite a while. This page hasn't aged well. I've come full circle and am now using jQuery again.
I agree this page hasn't aged well, but that's because it's stuck on IE10 as the support level it's targeting. If you don't need to target IE at all (only Edge), then everything becomes simpler. That's not always safe, but that's why you might not need jQuery... For reference: // JSON const data = await (await fetch('/my-url')).json(); // Post await fetch('/my-url', { method: 'POST', body: data }); // Request try { c…
Your fetch examples don't reject the promise if the server responds with error status code, like 404, which is probably not what you'd want. You'd need to handle that separately with something like
const resp = await fetch('/my-url')
if (!resp.ok) throw new Error(await resp.text())
const data = await resp.json()
> The Promise returned from fetch() won’t reject on HTTP error status even if the response is an HTTP 404 or 500. Instead, it will resolve normally (with ok status set to false), and it will only reject on network failure or if anything prevented the request from completing.
Re: You might not need jQuery (2014)
#119And yet, jQuery's AJAX related methods are more convenient than the native fetch() API.
And AFAIK not matched by any simple wrapper for the newer APIs (it's fashionable to go to heavier ones like axios).
I still grab jQuery into projects for the sheer convenience.
Re: You might not need jQuery (2014)
#120I’d be careful about premature optimization. If you can write your code 2x faster by using jQuery, by all means do it. Eventually, if needed, you could rewrite your JS to be free of jQuery, but it would not be a priority for me. Dev speed if more important than load speed for me.
What we need is a Jquery-to-VanillaJS transpiler.
Uh, what do you think jQuery is written in?