4 ms·

As the maintainer of cash [0] I wouldn't recommend using these functions for almost anything, they aren't really alternatives for jQuery as they provide a very

As the maintainer of cash [0] I wouldn't recommend using these functions for almost anything, they aren't really alternatives for jQuery as they provide a very different API, just to give one example the proposed alternative for `$.fn.css`: - Doesn't automatically camel-case the property name. - Doesn't automatically vendor-prefix properties if needed. - Doesn't support getting/setting CSS variables. - Doesn't automatically add the `px` suffix to numeric values when appropriate. - Doesn't fail gracefully when dealing with non-element nodes (`node.nodeType !== 1`). IMHO there are too many details that you now have to think about when using such "native alternatives" that's not worth it. From my very unbiased opinion I think it makes more sense to just use cash, which only needs ~5kb when minified and gzipped, and can be even partially compiled to remove the stuff you don't need. [0] https://github.com/kenwheeler/cash https://github.com/kenwheeler/cash

Rumudiez 8y ago
> From my very biased opinion Fixed that for you. There are better ways to integrate with the DOM than jQuery nowadays. It’s not a good fit unless you’re just trying to tack on a dropdown menu onto a decade old Wordpress theme, IMO.
- dang 8y ago
  Can you please edit snarky swipes out of your comments here? This post would be just fine with just the last two sentences. https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html
- yoz-y 8y ago
  I'd say it's the opposite. These no-jQuery methods are good if you are "just trying to tack on a dropdown menu onto a decade old Wordpress theme", however if you want to manipulate DOM in a more complex manner and do not wish to pull in an entire frontend rendering library, then jQuery is perfectly fine. You will have/want to factorise these methods anyways because some of them are just ridiculously long. jQuery has already done that and at least it is very consistent.
- fabiospampinato 8y ago
  I actually meant "very biased", not "very unbiased"! Apologies, obviously I have some strong opinions on this since I maintain cash.
EB66 8y ago
I agree. I glanced through the list and noticed a couple problems myself too. Their `replaceWith` doesn't provide the functionality that jQuery offers -- it doesn't take into account event handlers bound to DOM elements. Also, their `extend` does a shallow merge, not a deep merge. I don't particularly understand the rush to rip jQuery out of everything. It seems like a lot of people are doing it just because it's the trending thing to do. There are some things that jQuery does very well -- even in today's world where modern web dev is dominated by SPA components. I'm the maintainer of https://github.com/elliotnb/observable-slim https://github.com/elliotnb/observable-slim and https://github.com/elliotnb/nimbly https://github.com/elliotnb/nimbly -- the latter of which is an SPA component framework whose core requires jQuery. It uses jQuery to update DOM nodes with `replaceWith`, merge deeply nested objects with `extend`, among other things. Nimbly components are not required to use jQuery -- only the framework core uses it. Aside from the eliminating the extra 69KB footprint from adding jQuery 3.1.1 slim min, I don't see any reason to rush to rip jQuery out of the Nimbly core. On the contrary, using jQuery helped us get the framework built faster and helped us keep the code expressive and easy-to-follow.
chrismorgan 8y ago
They’re often not exactly equivalent, but I don’t think that all of your points are reasonable. • 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.
- fabiospampinato 8y ago
  > • Camel-casing the property name: I can do that myself readily enough; 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 https://developer.mozilla.org/en-US/docs/Web/CSS/appearance
lucideer 8y ago
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.

Rumudiez 8y ago

> From my very biased opinion Fixed that for you. There are better ways to integrate with the DOM than jQuery nowadays. It’s not a good fit unless you’re just trying to tack on a dropdown menu onto a decade old Wordpress theme, IMO.

dang 8y ago
Can you please edit snarky swipes out of your comments here? This post would be just fine with just the last two sentences. https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html
yoz-y 8y ago
I'd say it's the opposite. These no-jQuery methods are good if you are "just trying to tack on a dropdown menu onto a decade old Wordpress theme", however if you want to manipulate DOM in a more complex manner and do not wish to pull in an entire frontend rendering library, then jQuery is perfectly fine. You will have/want to factorise these methods anyways because some of them are just ridiculously long. jQuery has already done that and at least it is very consistent.
fabiospampinato 8y ago
I actually meant "very biased", not "very unbiased"! Apologies, obviously I have some strong opinions on this since I maintain cash.

EB66 8y ago

I agree. I glanced through the list and noticed a couple problems myself too. Their `replaceWith` doesn't provide the functionality that jQuery offers -- it doesn't take into account event handlers bound to DOM elements. Also, their `extend` does a shallow merge, not a deep merge. I don't particularly understand the rush to rip jQuery out of everything. It seems like a lot of people are doing it just because it's the trending thing to do. There are some things that jQuery does very well -- even in today's world where modern web dev is dominated by SPA components. I'm the maintainer of https://github.com/elliotnb/observable-slim https://github.com/elliotnb/observable-slim and https://github.com/elliotnb/nimbly https://github.com/elliotnb/nimbly -- the latter of which is an SPA component framework whose core requires jQuery. It uses jQuery to update DOM nodes with `replaceWith`, merge deeply nested objects with `extend`, among other things. Nimbly components are not required to use jQuery -- only the framework core uses it. Aside from the eliminating the extra 69KB footprint from adding jQuery 3.1.1 slim min, I don't see any reason to rush to rip jQuery out of the Nimbly core. On the contrary, using jQuery helped us get the framework built faster and helped us keep the code expressive and easy-to-follow.

chrismorgan 8y ago

They’re often not exactly equivalent, but I don’t think that all of your points are reasonable. • 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.

fabiospampinato 8y ago
> • Camel-casing the property name: I can do that myself readily enough; 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 https://developer.mozilla.org/en-US/docs/Web/CSS/appearance

lucideer 8y ago

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.