Sure, but now you have to think about this, which makes those functions a bit less of a replacement for jQuery.
> • Vendor-prefixing properties: in the library we use for FastMail, we used to have vendor prefixing; but when we dropped support for IE<11
> Vendor-prefixing is basically a thing of the past; the only one that I found to still be relevant is `user-select`.
I think you still have to prefix the appearance [0] property too, I would guess probably a few more as well, as I think browsers sometimes implement a vendor-prefixed property before the implementation is stable enough, so I guess if you want to use something particularly new you might need to vendor-prefix it.
My point is that with jQuery you don't have to think about all this.
> • CSS variables: fair, but using `.setProperty('--foo', value)` and `.getPropertyValue('--foo')` is not onerous in those situations where you need to refer to a custom property.
Right, but now you have to remember to use different functions. If you want to abstract this away in a separate `css` function you'll find yourself basically reimplementing what jQuery or cash does (ensuring it works, it's performant etc.), perhaps it might have been better to spend that time improving your product instead.
> • Adding `px` suffix to numeric values when appropriate: I don’t actually want that.
> • Non-element nodes: why on earth would I want it to fail gracefully? I want it to throw an exception, because I evidently did the wrong thing.
Fair enough, but that's what jQuery does, maybe you want something else, maybe not something I would call a "jQuery alternative" in this context.
> I like efficiency, and I like correctness; for that reason, I like the fact that the native methods don’t do most fo these things automatically. I don’t want to inefficiently do most of those things.
I'm pretty sure the bottleneck of your app will basically never be the check for css variables or something like that. And the time spent to reimplement all/some of these functions might be better spent improving the app instead, to me this argument feels like saying: I like efficiency, I only write my apps in C, you can absolutely do that but by the time you reach a MVP I would have probably made a much better overall and maybe even more performance JS app, since while you'd be thinking about managing memory and all that I would have surely spent more time thinking about algorithmic improvements and performance optimization in general.
[0] https://developer.mozilla.org/en-US/docs/Web/CSS/appearance
No new properties are being prefixed; that technique is dead, and the only things prefixed are so for historical reasons.
• Camel-casing the property name: I can do that myself readily enough; remember this lets you deal in direct property access, so we’re talking things like `styles.backgroundColor` rather than what would otherwise be `.css('backgroundColor')`, where using the kebab-case is nicer. (I would issue one caution: the kebab-case `float` becomes the camel-case `cssFloat` because `float` was a reserved word; this is a little like how for becomes htmlFor and class className.)
• Vendor-prefixing properties: in the library we use for FastMail, we used to have vendor prefixing; but when we dropped support for IE<11 and other ancient browsers recently I steadily whittled that down until there was only one item left, and so I decided to just special-case that one item. Vendor-prefixing is basically a thing of the past; the only one that I found to still be relevant is `user-select`.
• CSS variables: fair, but using `.setProperty('--foo', value)` and `.getPropertyValue('--foo')` is not onerous in those situations where you need to refer to a custom property.
• Adding `px` suffix to numeric values when appropriate: I don’t actually want that. I’d much prefer it to throw an error if I tried to assign a number to something that wants a dimension, but that is unfortunately not possible; yet it’s likely that any incorrect code that I write will not work, and so I’ll notice. If I really am working in pixels, I prefer to do so deliberately.
• Non-element nodes: why on earth would I want it to fail gracefully? I want it to throw an exception, because I evidently did the wrong thing. Also, if using a more strongly typed language such as TypeScript, this pretty much becomes a non-issue.
Things like $.fn.css are completely generic, taking a single object and needing to act on it—and so most of these features make sense there. But in the concrete situations where you use such functions, you can reasonably do things like call different functions, instead of just passing one object; and I think that there, most of them are instead either misfeatures or not of value any more due to better browsers and possibly TypeScript.
I like efficiency, and I like correctness; for that reason, I like the fact that the native methods don’t do most fo these things automatically. I don’t want to inefficiently do most of those things.