Looking back jquery was probably the only frontend framework that wasn't obsolete in 18 months. There is also value in keeping things the same over a decade or more so the old farts can still be productive without having to relearn everything every couple of years.
jQuery 4.0 99% Complete
41–47 of 47 posts
Re: jQuery 4.0 99% Complete
#42It has been a long time since I used jQuery. What exactly is the usecase today? Is it just syntactic sugar or has it changed significantly?
I think the main use case today is the dom traversal API. It makes operations like "add the 'error' class to all elements in the form" simple: $('#some-form').find('input').addClass('error') Obviously you can do this in vanilla JS, but it's more cumbersome so you'll probably end up rewriting your own less complete version of jquery. There is some value to using a well worn library with public documentation that other…
I can't really imagine willingly doing something nontrivial without a reactive framework these days. I'd be all for jQuery if I did want to do that though.
Re: jQuery 4.0 99% Complete
#43Earlier quoted context omitted.
Yeah. However, it does matter in interactive websites because if the js is light it'll load fast and execute fast and you'll have interactivity sooner. It may be the case that images can be loaded later or arent even visible on the home page. And fonts of course will be replaced once they are loaded and the defaults will be used while it loads so it's progressive in a way.
Interactive websites are slow because they are including 1 MB frontend frameworks... and use these bloated modern frameworks to set a class on an element.
Yes, I was just pointing out why having huge fonts/images isnt as big of a blocker as huge JS on today's JS heavy apps with "loading placeholders" and what not. The browser also does font replacement fairly smoothly.
Whether this whole bazaar is ideal or not is a separate issue :)
Re: jQuery 4.0 99% Complete
#44Earlier quoted context omitted.
I think the main use case today is the dom traversal API. It makes operations like "add the 'error' class to all elements in the form" simple: $('#some-form').find('input').addClass('error') Obviously you can do this in vanilla JS, but it's more cumbersome so you'll probably end up rewriting your own less complete version of jquery. There is some value to using a well worn library with public documentation that other…
Mostly off the top of my head: document.getElementById('some-form').getElementsByTagName('input').forEach(i => i.classList.add('error')) It is a little more verbose but it isn't that much more cumbersome today. That's also doing things "the right way" and not do-all selectors, but that option exists now, too: document.querySelectorAll('#some-form > input').forEach(i => i.classList.add('error')) If you want to make it…
However getElementById() can return null, thus that entire statement can error. In the old days you had to sprinkle your code with if checks when using the DOM API.
Re: jQuery 4.0 99% Complete
#45Earlier quoted context omitted.
Mostly off the top of my head: document.getElementById('some-form').getElementsByTagName('input').forEach(i => i.classList.add('error')) It is a little more verbose but it isn't that much more cumbersome today. That's also doing things "the right way" and not do-all selectors, but that option exists now, too: document.querySelectorAll('#some-form > input').forEach(i => i.classList.add('error')) If you want to make it…
However getElementById() can return null, thus that entire statement can error. In the old days you had to sprinkle your code with if checks when using the DOM API.
If you are requiring that element to be there for your script to work then that error is exactly what you want. Defensive programming is great and all, but sometimes your assumptions have to meet the road anyway and script errors are a perfect way to signal something went wrong (because that's what they are for).
Of course now we have additional defensive programming tools like `?.` and `??` operators.
Re: jQuery 4.0 99% Complete
#46Earlier quoted context omitted.
However getElementById() can return null, thus that entire statement can error. In the old days you had to sprinkle your code with if checks when using the DOM API.
If you are requiring that element to be there for your script to work then that error is exactly what you want. Defensive programming is great and all, but sometimes your assumptions have to meet the road anyway and script errors are a perfect way to signal something went wrong (because that's what they are for). Of course now we have additional defensive programming tools like `?.` and `??` operators.
It depends, if the page is very dynamic the element may or may not be there.
Point is that the DOM API version of the initial jQuery snippet are not equivalent. $() statement does a bit more than that.
This becomes obvious if the requirement are a bit more complex than the example, perhaps we want to chain more expression on at the end, then the DOM API version becomes more convoluted.
Re: jQuery 4.0 99% Complete
#47It has been a long time since I used jQuery. What exactly is the usecase today? Is it just syntactic sugar or has it changed significantly?
I think the main use case today is the dom traversal API. It makes operations like "add the 'error' class to all elements in the form" simple: $('#some-form').find('input').addClass('error') Obviously you can do this in vanilla JS, but it's more cumbersome so you'll probably end up rewriting your own less complete version of jquery. There is some value to using a well worn library with public documentation that other…
What's wrong with
for (const input of document.querySelectorAll('#some-form input') {
input.classList.add('error');
}
In fact, this has an even earlier baseline browser compatibility than
NodeList.prototype.forEach