2 ms·

This article says makes 2 competing claims A) jquery deals with inconsistent browser implementations, largely in older browsers B) replacing it with modern AP

This article says makes 2 competing claims A) jquery deals with inconsistent browser implementations, largely in older browsers B) replacing it with modern API calls made the website more usable for all users including those on older machines (and presumably OS’s) I don’t see how to square those.

zamadatix 4y ago
"Older" in those lines isn't fungible. E.g. jQuery's older browser would be IE 9 while Gov.uk's older browser would be IE 11 (they do have limited support for back to 8 though but it's not expected to be matching).
acdha 4y ago
The older browsers which shaped jQuery’s design aren’t in use any more but you’re still paying for the code which now largely duplicates built-in features. For example, if I use querySelectorAll I’m using the browser’s native CSS parser and getting a native NodeList back - all of the work is being done in some of the most optimized C++/Rust code in existence. If I use jQuery, there’s a lot of code which has to parse that selector, build data structures, etc. and some of that is working around limitations which haven’t been an issue since IE6 was released. It’s not as bad as a full virtual DOM, there are a lot of smart optimizations there but it’s still running a lot more non-native code & memory which inevitably adds up on a large project. On older devices with less RAM and memory, this is a lot more noticeable - especially if those are Android devices which started at half the equivalent iOS performance when they were new. The other problem you get is common to a lot of frameworks: it’s good that you can get a lot done but that means you can get s lot further without learning how it works underneath and by then you don’t want to revisit all of that code. This is especially easy to miss when your developers all use fast systems - React 3+ orders of magnitude slower isn’t noticeable on your $5k MacBook Pro but it might be when your grandfather tries to use that site on his 2011 PC, and by then you probably don’t want to do a messy refactoring on a large codebase.

zamadatix 4y ago

"Older" in those lines isn't fungible. E.g. jQuery's older browser would be IE 9 while Gov.uk's older browser would be IE 11 (they do have limited support for back to 8 though but it's not expected to be matching).

acdha 4y ago

The older browsers which shaped jQuery’s design aren’t in use any more but you’re still paying for the code which now largely duplicates built-in features. For example, if I use querySelectorAll I’m using the browser’s native CSS parser and getting a native NodeList back - all of the work is being done in some of the most optimized C++/Rust code in existence. If I use jQuery, there’s a lot of code which has to parse that selector, build data structures, etc. and some of that is working around limitations which haven’t been an issue since IE6 was released. It’s not as bad as a full virtual DOM, there are a lot of smart optimizations there but it’s still running a lot more non-native code & memory which inevitably adds up on a large project. On older devices with less RAM and memory, this is a lot more noticeable - especially if those are Android devices which started at half the equivalent iOS performance when they were new. The other problem you get is common to a lot of frameworks: it’s good that you can get a lot done but that means you can get s lot further without learning how it works underneath and by then you don’t want to revisit all of that code. This is especially easy to miss when your developers all use fast systems - React 3+ orders of magnitude slower isn’t noticeable on your $5k MacBook Pro but it might be when your grandfather tries to use that site on his 2011 PC, and by then you probably don’t want to do a messy refactoring on a large codebase.