4 ms·

I have to fully agree with chrismorgan here—to echo his breakdown of your points, it mostly comes down to strictness and explicitness. With the exception of CS

I have to fully agree with chrismorgan here—to echo his breakdown of your points, it mostly comes down to strictness and explicitness. With the exception of CSS var getters/setters (for which there are distinct getters/setters), all of your points champion things being done "automatically", by "magic", "loosely", rather than being strict. To reword: - Doesn't arbitrarily transform property names - Doesn't add extranous properties - Doesn't magically convert integers to strings - Doesn't silently hide logic errors on invalid nodeTypes This comes down to an essential philosophical difference, whereby the jQuery APIs favours automatic value transformations so devs don't need to understand the specific types of values being passed.

fabiospampinato 8y ago
I only made one example, another one might be `classList.add`, jQuery's `$.fn.addClass` accepts a string which may contain multiple space-separated classes, while the "native" version accepts multiple string arguments. That's a very different interface. > - Doesn't arbitrarily transform property names Ok, would you then prefer to reimplement the vendor-prefixing logic on your own or just not support browsers that only support the vendor-prefixed version of a property? I can see your point, and in some ways I agree with that "philosophy", but my point was that I wouldn't personally call these functions "jQuery alternative" in this context, as the 2 are pretty different beasts.
- lucideer 8y ago
  It's worded as "alternatives", not "equivalents", so API parity isn't a requirement. The fact that `classList.add` has a different interface to `$.fn.addClass` isn't really a big deal—this would be the case with most migrations from one API to another without matching interfaces. The question is of internal functionality—the only thing jQuery "adds" here is being lenient about the param type accepted.

fabiospampinato 8y ago

I only made one example, another one might be `classList.add`, jQuery's `$.fn.addClass` accepts a string which may contain multiple space-separated classes, while the "native" version accepts multiple string arguments. That's a very different interface. > - Doesn't arbitrarily transform property names Ok, would you then prefer to reimplement the vendor-prefixing logic on your own or just not support browsers that only support the vendor-prefixed version of a property? I can see your point, and in some ways I agree with that "philosophy", but my point was that I wouldn't personally call these functions "jQuery alternative" in this context, as the 2 are pretty different beasts.

lucideer 8y ago
It's worded as "alternatives", not "equivalents", so API parity isn't a requirement. The fact that `classList.add` has a different interface to `$.fn.addClass` isn't really a big deal—this would be the case with most migrations from one API to another without matching interfaces. The question is of internal functionality—the only thing jQuery "adds" here is being lenient about the param type accepted.